From loa@pi.nu Wed Aug 1 00:49: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 E1B5A21F86D3 for ; Wed, 1 Aug 2012 00:49:02 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSU+0PAg6H5V for ; Wed, 1 Aug 2012 00:49:02 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 422E121F867E for ; Wed, 1 Aug 2012 00:49:02 -0700 (PDT) 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) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 523662A8003; Wed, 1 Aug 2012 09:49:00 +0200 (CEST) Message-ID: <5018DF6C.2040408@pi.nu> Date: Wed, 01 Aug 2012 09:49:00 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <5003D2CD.4070306@pi.nu> In-Reply-To: <5003D2CD.4070306@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , "draft-zheng-mpls-ldp-hello-crypto-auth@tools.ietf.org" Subject: Re: [mpls] Poll for WG adoption for draft-zheng-mpls-ldp-hello-crypto-auth-05 - Closed 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, 01 Aug 2012 07:49:03 -0000 Working Group, this poll has been closed. We have accepted the draft as an mpls working group document. Could the authors please re-publish the draft with no other changes than file-name, date and version as: draft-ietf-mpls-ldp-hello-crypto-auth-01 /Loa (ass wg co-chair) On 2012-07-16 10:37, Loa Andersson wrote: > Working group, > > this is to start a two week poll on adopting > draft-zheng-mpls-ldp-hello-crypto-auth-05 > as an MPLS working group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). > > The poll ends July 31st, 2012. > > /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 loa@pi.nu Wed Aug 1 01:17: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 2B65121F865C for ; Wed, 1 Aug 2012 01:17:05 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jop2eryzSu2H for ; Wed, 1 Aug 2012 01:17:04 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id B650E21F85C3 for ; Wed, 1 Aug 2012 01:17:01 -0700 (PDT) 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) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 796B82A8003; Wed, 1 Aug 2012 10:17:00 +0200 (CEST) Message-ID: <5018E5FB.9040801@pi.nu> Date: Wed, 01 Aug 2012 10:16:59 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <5003D2CD.4070306@pi.nu> <5018DF6C.2040408@pi.nu> In-Reply-To: <5018DF6C.2040408@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , "draft-zheng-mpls-ldp-hello-crypto-auth@tools.ietf.org" Subject: Re: [mpls] Poll for WG adoption for draft-zheng-mpls-ldp-hello-crypto-auth-05 - Closed 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, 01 Aug 2012 08:17:07 -0000 All, I got the version number wrong it should be draft-ietf-mpls-ldp-hello-crypto-auth-00 /Loa On 2012-08-01 09:49, Loa Andersson wrote: > Working Group, > > this poll has been closed. > > We have accepted the draft as an mpls working group document. > > Could the authors please re-publish the draft with no other > changes than file-name, date and version as: > > draft-ietf-mpls-ldp-hello-crypto-auth-01 > > /Loa > (ass wg co-chair) > > On 2012-07-16 10:37, Loa Andersson wrote: >> Working group, >> >> this is to start a two week poll on adopting >> draft-zheng-mpls-ldp-hello-crypto-auth-05 >> as an MPLS working group document. >> >> Please send your comments (support/not support) to the mpls working >> group mailing list (mpls@ietf.org). >> >> The poll ends July 31st, 2012. >> >> /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 lizhong.jin@zte.com.cn Wed Aug 1 02:21: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 5201A21F8621 for ; Wed, 1 Aug 2012 02:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.352 X-Spam-Level: X-Spam-Status: No, score=-101.352 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyxd5WKk+E+w for ; Wed, 1 Aug 2012 02:21:45 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id DA90121F8620 for ; Wed, 1 Aug 2012 02:21:44 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 10723806486374; Wed, 1 Aug 2012 17:09:57 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 47492.2930047480; Wed, 1 Aug 2012 17:21:33 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q719LWLS005707; Wed, 1 Aug 2012 17:21:32 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: loa@pi.nu MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Wed, 1 Aug 2012 17:21:21 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-01 17:21:27, Serialize complete at 2012-08-01 17:21:27 Content-Type: multipart/alternative; boundary="=_alternative 0033683048257A4D_=" X-MAIL: mse01.zte.com.cn q719LWLS005707 Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] IPR poll draft-jin-mpls-mldp-leaf-discovery 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, 01 Aug 2012 09:21:46 -0000 This is a multipart message in MIME format. --=_alternative 0033683048257A4D_= Content-Type: text/plain; charset="US-ASCII" Hi Loa, Yes, there is IPR that was disclosed to IETF in below link. http://datatracker.ietf.org/ipr/1841/ Thanks Lizhong > > ------------------------------ > > Message: 4 > Date: Tue, 31 Jul 2012 14:29:55 +0200 > From: Loa Andersson > To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" > , Martin Vigoureux > , > draft-ietf-mpls-tp-security-framework@tools.ietf.org > Subject: [mpls] IPR poll draft-jin-mpls-mldp-leaf-discovery > Message-ID: <5017CFC3.9040702@pi.nu> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Working Group and authors; > > The wg chair are nearly ready to issue a poll to accept > draft-jin-mpls-mldp-leaf-discovery as a working group document, > we will run this IPR poll in parallel to the poll on making this > document a working group document. > > Are you aware of any IPR that applies to > draft-jin-mpls-mldp-leaf-discovery? > > 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 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 > > --=_alternative 0033683048257A4D_= Content-Type: text/html; charset="US-ASCII"
Hi Loa,
Yes, there is IPR that was disclosed to IETF in below link.
http://datatracker.ietf.org/ipr/1841/

Thanks
Lizhong


>
> ------------------------------
>
> Message: 4
> Date: Tue, 31 Jul 2012 14:29:55 +0200
> From: Loa Andersson <loa@pi.nu>
> To: "mpls@ietf.org" <mpls@ietf.org>,    "mpls-chairs@tools.ietf.org"
>    <mpls-chairs@tools.ietf.org>,   Martin Vigoureux
>    <martin.vigoureux@alcatel-lucent.com>,
>    draft-ietf-mpls-tp-security-framework@tools.ietf.org
> Subject: [mpls] IPR poll draft-jin-mpls-mldp-leaf-discovery
> Message-ID: <5017CFC3.9040702@pi.nu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Working Group and authors;
>
> The wg chair are nearly ready to issue a poll to accept
> draft-jin-mpls-mldp-leaf-discovery as a working group document,
> we will run this IPR poll in parallel to the poll on making this
> document a working group document.
>
> Are you aware of any IPR that applies to
> draft-jin-mpls-mldp-leaf-discovery?
>
> 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 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
>
> --=_alternative 0033683048257A4D_=-- From internet-drafts@ietf.org Wed Aug 1 02:43: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 3F7B721F8652; Wed, 1 Aug 2012 02:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.42 X-Spam-Level: X-Spam-Status: No, score=-102.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLe-mZlZj5Gi; Wed, 1 Aug 2012 02:43:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBEC21F8639; Wed, 1 Aug 2012 02:43:40 -0700 (PDT) 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.33 Message-ID: <20120801094340.30044.76894.idtracker@ietfa.amsl.com> Date: Wed, 01 Aug 2012 02:43:40 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-hello-crypto-auth-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: Wed, 01 Aug 2012 09:43:41 -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 Hello Cryptographic Authentication Author(s) : Lianshu Zheng Mach(Guoyi) Chen Manav Bhatia Filename : draft-ietf-mpls-ldp-hello-crypto-auth-00.txt Pages : 15 Date : 2012-08-01 Abstract: This document introduces a new optional Cryptographic Authentication TLV that LDP can use to secure its Hello messages. It secures the Hello messages against spoofing attacks and some well known attacks against the IP header. This document describes a mechanism to secure the LDP Hello messages using National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-hello-crypto-auth There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-hello-crypto-auth-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From loa@pi.nu Wed Aug 1 04:26: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 AD81821F861C for ; Wed, 1 Aug 2012 04:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuRBmS6OfJHl for ; Wed, 1 Aug 2012 04:26:21 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 077DD21F8608 for ; Wed, 1 Aug 2012 04:26:20 -0700 (PDT) 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) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 2F5232A8003; Wed, 1 Aug 2012 13:26:19 +0200 (CEST) Message-ID: <5019125A.4050400@pi.nu> Date: Wed, 01 Aug 2012 13:26:18 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.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-ldp-ip-pw-capability@tools.ietf.org Subject: [mpls] IPR poll on 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, 01 Aug 2012 11:26:21 -0000 Working Group and authors; draft-ietf-mpls-ldp-ip-pw-capability - the wg chair are nearly ready to request publication for this draft, but before we do so we need to make an IPR poll Are you aware of any IPR that applies to draft-ietf-mpls-ldp-ip-pw-capability? 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 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 internet-drafts@ietf.org Wed Aug 1 06:47: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 91C0F11E8125; Wed, 1 Aug 2012 06:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRV6DHuL1Ht3; Wed, 1 Aug 2012 06:47:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5215611E810E; Wed, 1 Aug 2012 06:47:44 -0700 (PDT) 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.33 Message-ID: <20120801134744.1086.7969.idtracker@ietfa.amsl.com> Date: Wed, 01 Aug 2012 06:47:44 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-seamless-mcast-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: Wed, 01 Aug 2012 13:47:45 -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 : Inter-Area P2MP Segmented LSPs Author(s) : Yakov Rekhter Rahul Aggarwal Filename : draft-ietf-mpls-seamless-mcast-05.txt Pages : 39 Date : 2012-08-01 Abstract: This document describes procedures for building inter-area point-to- multipoint (P2MP) segmented service LSPs by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and label distribution protocol. Within each IGP area the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress replication is used within an IGP area, then MP2P LDP LSPs or P2P RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may be BGP MVPN, VPLS multicast, or global table multicast over MPLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mcast There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-seamless-mcast-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-seamless-mcast-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From skraza@cisco.com Wed Aug 1 08:58: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 0C4D221F8836 for ; Wed, 1 Aug 2012 08:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.046 X-Spam-Level: X-Spam-Status: No, score=-10.046 tagged_above=-999 required=5 tests=[AWL=0.553, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwcyPn-+8R4T for ; Wed, 1 Aug 2012 08:58:30 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4307821F8835 for ; Wed, 1 Aug 2012 08:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=skraza@cisco.com; l=1484; q=dns/txt; s=iport; t=1343836710; x=1345046310; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=p8TlyfuqnTdAneagp7eaPiecK74SJW6MOf9EVyOXfj4=; b=JmAZk6XdeBlIUdQkcb93fIKcI71vS8KNYQg9a1sVAuyQWMsE6YwaUcwj V578ZJPcgqIW/kGmnE2WZzs8vbAsPXKSU2S1KdrW8Y1vxuP+/JA7GWB6k wuAqDWSheyC2V3FnzfaxxnNX20NiN8OvZzdSKI7yxu6jDcjMKP7oIvT4b g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAEJRGVCtJXG8/2dsb2JhbABFuRCBB4IiAQQBAQEPASc0BgUOBAEINisMCyUCBAENBSKHawucYaBNBASSTgOVR44ngWaCX4Ff X-IronPort-AV: E=Sophos;i="4.77,694,1336348800"; d="scan'208";a="107467882" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 01 Aug 2012 15:58:29 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q71FwTsC028864 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Aug 2012 15:58:29 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.180]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0298.004; Wed, 1 Aug 2012 10:56:14 -0500 From: "Kamran Raza (skraza)" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] IPR poll on draft-ietf-mpls-ldp-ip-pw-capability Thread-Index: AQHNb9h9nn6yGo+XJEqoPNQzf+1pUpdFLjSA Date: Wed, 1 Aug 2012 15:58:29 +0000 Message-ID: In-Reply-To: <5019125A.4050400@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [161.44.193.212] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19076.006 x-tm-as-result: No--40.325900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-ip-pw-capability@tools.ietf.org" Subject: Re: [mpls] IPR poll on 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, 01 Aug 2012 15:58:31 -0000 As an author: I am not aware of any IPR. Rgds, -- Kamran On 12-08-01 7:26 AM, "Loa Andersson" wrote: >Working Group and authors; > >draft-ietf-mpls-ldp-ip-pw-capability - the wg chair are nearly ready >to request publication for this draft, but before we do so we need >to make an IPR poll > >Are you aware of any IPR that applies to >draft-ietf-mpls-ldp-ip-pw-capability? > >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 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) > >--=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 Wed Aug 1 09:22: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 3B40911E8178; Wed, 1 Aug 2012 09:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFuxs9xyjEPi; Wed, 1 Aug 2012 09:22:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9795B11E8175; Wed, 1 Aug 2012 09:22:53 -0700 (PDT) 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.33 Message-ID: <20120801162253.8934.56382.idtracker@ietfa.amsl.com> Date: Wed, 01 Aug 2012 09:22:53 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-return-path-specified-lsp-ping-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: Wed, 01 Aug 2012 16:22:54 -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 : Return Path Specified LSP Ping Author(s) : Mach(Guoyi) Chen Wei Cao So Ning Frederic Jounay Simon Delord Filename : draft-ietf-mpls-return-path-specified-lsp-ping-06.txt Pages : 20 Date : 2012-08-01 Abstract: This document defines extensions to the failure-detection protocol for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) known as "LSP Ping" that allow selection of the LSP to use for the echo reply return path. Enforcing a specific return path can be used to verify bidirectional connectivity and also increase LSP ping robustness. It may also be used by Bidirectional Forwarding Detection (BFD) for MPLS bootstrap signaling thereby making BFD for MPLS more robust. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-return-path-specified-lsp-= ping There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-return-path-specified-lsp-ping-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-return-path-specified-ls= p-ping-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mach.chen@huawei.com Wed Aug 1 09:45: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 73DCD11E8150 for ; Wed, 1 Aug 2012 09:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.84 X-Spam-Level: X-Spam-Status: No, score=-3.84 tagged_above=-999 required=5 tests=[AWL=2.759, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1rtWL-DSEFB for ; Wed, 1 Aug 2012 09:45:44 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E1E2C11E8132 for ; Wed, 1 Aug 2012 09:45:37 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIP36756; Wed, 01 Aug 2012 08:45:37 -0800 (PST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 1 Aug 2012 09:43:29 -0700 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 1 Aug 2012 09:43:28 -0700 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.86]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 2 Aug 2012 00:43:25 +0800 From: Mach Chen To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] Closed: working group las call on draft-ietf-mpls-return-path-specified-lsp-ping-05.txt Thread-Index: AQHNawsXwQF41bKh+kiMdkLJdm+haZdFLoqq Date: Wed, 1 Aug 2012 16:43:24 +0000 Message-ID: References: <4FFAF2E6.9030508@pi.nu>,<501103B7.7070503@pi.nu> In-Reply-To: <501103B7.7070503@pi.nu> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Closed: working group las call on draft-ietf-mpls-return-path-specified-lsp-ping-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: Wed, 01 Aug 2012 16:45:45 -0000 Hi Loa,=0A= =0A= We have just uploaded a new version (http://tools.ietf.org/html/draft-ietf-= mpls-return-path-specified-lsp-ping-06) that had addressed the WG Last Call= comments. =0A= =0A= Here is the diff since last version: http://tools.ietf.org/rfcdiff?url2=3Dd= raft-ietf-mpls-return-path-specified-lsp-ping-06.txt=0A= =0A= Many thanks,=0A= Mach=0A= ________________________________________=0A= From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] on behalf of Loa Anders= son [loa@pi.nu]=0A= Sent: Thursday, July 26, 2012 16:45=0A= To: mpls@ietf.org=0A= Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-return-path-specified-lsp-p= ing@tools.ietf.org=0A= Subject: [mpls] Closed: working group las call on draft-ietf-mpls-ret= urn-path-specified-lsp-ping-05.txt=0A= =0A= Working Group,=0A= =0A= this working group last call is closed.=0A= =0A= There have been comments that the authors need to address and publish a=0A= new version of the document.=0A= =0A= /Loa=0A= =0A= On 2012-07-09 17:04, Loa Andersson wrote:=0A= > Working Group,=0A= >=0A= > this is to start a working group last call on=0A= >=0A= > draft-ietf-mpls-return-path-specified-lsp-ping-05.txt=0A= >=0A= > Please send your comments to the MPLS wg mailing list (mpls@ietf.org).=0A= >=0A= > This working group last call July 23, 2012.=0A= >=0A= > Please note that there is an IPR disclosure against this draft.=0A= >=0A= > /Loa=0A= > for the MPLS working group co-chairs=0A= =0A= --=0A= =0A= =0A= Loa Andersson email: loa.andersson@ericsson.com=0A= Sr Strategy and Standards Manager loa@pi.nu=0A= Ericsson Inc phone: +46 10 717 52 13=0A= +46 767 72 92 13=0A= _______________________________________________=0A= mpls mailing list=0A= mpls@ietf.org=0A= https://www.ietf.org/mailman/listinfo/mpls=0A= From loa@pi.nu Wed Aug 1 09:50: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 011E711E8151 for ; Wed, 1 Aug 2012 09:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0mwu3Nl3-lT for ; Wed, 1 Aug 2012 09:50:54 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5F511E8117 for ; Wed, 1 Aug 2012 09:50:54 -0700 (PDT) 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) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 3AD4C2A8003; Wed, 1 Aug 2012 18:50:52 +0200 (CEST) Message-ID: <50195E6B.1010307@pi.nu> Date: Wed, 01 Aug 2012 18:50:51 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Mach Chen References: <4FFAF2E6.9030508@pi.nu>, <501103B7.7070503@pi.nu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Closed: working group las call on draft-ietf-mpls-return-path-specified-lsp-ping-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: Wed, 01 Aug 2012 16:50:55 -0000 Mach, have you verified with the people making the comments that they agree that there comments have been addressed??? /Loa On 2012-08-01 18:43, Mach Chen wrote: > Hi Loa, > > We have just uploaded a new version (http://tools.ietf.org/html/draft-ietf-mpls-return-path-specified-lsp-ping-06) that had addressed the WG Last Call comments. > > Here is the diff since last version: http://tools.ietf.org/rfcdiff?url2=draft-ietf-mpls-return-path-specified-lsp-ping-06.txt > > Many thanks, > Mach > ________________________________________ > From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] on behalf of Loa Andersson [loa@pi.nu] > Sent: Thursday, July 26, 2012 16:45 > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org > Subject: [mpls] Closed: working group las call on draft-ietf-mpls-return-path-specified-lsp-ping-05.txt > > Working Group, > > this working group last call is closed. > > There have been comments that the authors need to address and publish a > new version of the document. > > /Loa > > On 2012-07-09 17:04, Loa Andersson wrote: >> Working Group, >> >> this is to start a working group last call on >> >> draft-ietf-mpls-return-path-specified-lsp-ping-05.txt >> >> Please send your comments to the MPLS wg mailing list (mpls@ietf.org). >> >> This working group last call July 23, 2012. >> >> Please note that there is an IPR disclosure against this draft. >> >> /Loa >> for the MPLS working group 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 > -- 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 sriganeshkini@gmail.com Wed Aug 1 10:23:19 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 0537611E8378 for ; Wed, 1 Aug 2012 10:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5QLBNh2dV7U for ; Wed, 1 Aug 2012 10:23:18 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1B27411E836D for ; Wed, 1 Aug 2012 10:23:17 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so7819758vcb.31 for ; Wed, 01 Aug 2012 10:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=voImvTkY9+I+Q7U5UWm+OWW6GtJROkdQSmWJ/MwxOdE=; b=Emxm25+Ox6hrIgJdF/5Bs86Poq6DYXZTpDppvyROpQ0wcE0jiiJSY/8YPL47Nto3BY Ag8v8MDk7t2VEEUbTzS/3oBvAGnuR8K/cWZJNOGv9yMQ6YuFtCzfEFEwfqn/IUEQfqk/ Js6OU4jlZnxj4RS4xAqahUL373xc38PcnlY7RBN5u1K96r5JfEneY31g/C7c9OoHhrJ/ Se1TXY+uG+t7l4P8R5jVssDjwIFW1q86OBt7PhmNYHmM9lhtzSn2+QwvqFs4Tr2j+mGw M3tAivKoDiGYXHcxUhsdoNEfAIxORxaIxjYT/97ccy2kmacsF9G5/VmJDj8P6C5lpxxP Gyyg== Received: by 10.58.2.232 with SMTP id 8mr6522382vex.45.1343841796462; Wed, 01 Aug 2012 10:23:16 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.220.148.68 with HTTP; Wed, 1 Aug 2012 10:22:45 -0700 (PDT) In-Reply-To: References: From: Sriganesh Kini Date: Wed, 1 Aug 2012 10:22:46 -0700 X-Google-Sender-Auth: _4SKTtktqVftd-uoRutzGyxmOZs Message-ID: To: Lizhong Jin Content-Type: multipart/alternative; boundary=047d7b2e54a0e9990a04c6378c70 Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] IPR poll draft-jin-mpls-mldp-leaf-discovery 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, 01 Aug 2012 17:23:19 -0000 --047d7b2e54a0e9990a04c6378c70 Content-Type: text/plain; charset=UTF-8 I am not aware of any other IPR on this draft. On Wed, Aug 1, 2012 at 2:21 AM, Lizhong Jin wrote: > > Hi Loa, > Yes, there is IPR that was disclosed to IETF in below link. > http://datatracker.ietf.org/ipr/1841/ > > Thanks > Lizhong > > > > > > ------------------------------ > > > > Message: 4 > > Date: Tue, 31 Jul 2012 14:29:55 +0200 > > From: Loa Andersson > > To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" > > , Martin Vigoureux > > , > > draft-ietf-mpls-tp-security-framework@tools.ietf.org > > Subject: [mpls] IPR poll draft-jin-mpls-mldp-leaf-discovery > > Message-ID: <5017CFC3.9040702@pi.nu> > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > > Working Group and authors; > > > > The wg chair are nearly ready to issue a poll to accept > > draft-jin-mpls-mldp-leaf-discovery as a working group document, > > we will run this IPR poll in parallel to the poll on making this > > document a working group document. > > > > Are you aware of any IPR that applies to > > draft-jin-mpls-mldp-leaf-discovery? > > > > 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 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 > > -- - Sri --047d7b2e54a0e9990a04c6378c70 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am not aware of any other IPR on this draft.

On Wed, Aug 1, 2012 at 2:21 AM, Lizhong Jin <lizhong.jin@zte.co= m.cn> wrote:

Hi Loa,
Yes, there is IPR that was disclosed to IETF in below link.
http://datatracker.ietf.org/ipr/1841/

Thanks
Lizhong


>
> ------------------------------
>
> Message: 4
> Date: Tue, 31 Jul 2012 14:29:55 +0200
> From: Loa Andersson <loa@pi.nu>
> To: "mpls@ietf= .org" <mpls@= ietf.org>, =C2=A0 =C2=A0"mpls-chairs@tools.ietf.org"
> =C2=A0 =C2=A0<mpls-chairs@tools.ietf.org>, =C2=A0 Martin Vigoureux
> =C2=A0 =C2=A0<martin.vigoureux@alcatel-lucent.com>,
> =C2=A0 =C2=A0draft-ietf-mpls-tp-security-framework@tool= s.ietf.org
> Subject: [mpls] IPR poll draft-jin-mpls-mldp-leaf-discovery
> Message-ID: <5017CFC3.9040702@pi.nu>
> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed

>
> Working Group and authors;
>
> The wg chair are nearly ready to issue a poll to accept
> draft-jin-mpls-mldp-leaf-discovery as a working group document,
> we will run this IPR poll in parallel to the poll on making this
> document a working group document.
>
> Are you aware of any IPR that applies to
> draft-jin-mpls-mldp-leaf-discovery?
>
> 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<= br> > IPR. 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 =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: loa.andersson@ericsson.com
> Sr Strategy and Standards Manager =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loa@pi.nu
> 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=A0phone: +46 10 717 52 13
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 +46 767 72 92 13
>
>

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




--
- Sri --047d7b2e54a0e9990a04c6378c70-- From wwwrun@rfc-editor.org Wed Aug 1 12:16: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 A4C9021F8829 for ; Wed, 1 Aug 2012 12:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.286 X-Spam-Level: X-Spam-Status: No, score=-102.286 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PJck-ebN-kk for ; Wed, 1 Aug 2012 12:16:07 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 08EAE21F8826 for ; Wed, 1 Aug 2012 12:16:06 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 66311B1E002; Wed, 1 Aug 2012 12:15:28 -0700 (PDT) To: ssaxena@cisco.com, swallow@cisco.com, zali@cisco.com, adrian@olddog.co.uk, yasukawa.seisho@lab.ntt.co.jp, thomas.nadeau@ca.com, stbryant@cisco.com, adrian@olddog.co.uk, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net From: RFC Errata System Message-Id: <20120801191528.66311B1E002@rfc-editor.org> Date: Wed, 1 Aug 2012 12:15:28 -0700 (PDT) Cc: mustapha.aissaoui@alcatel-lucent.com, mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] [Technical Errata Reported] RFC6425 (3306) 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, 01 Aug 2012 19:16:07 -0000 The following errata report has been submitted for RFC6425, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6425&eid=3306 -------------------------------------- Type: Technical Reported by: Mustapha Aissaoui Section: 3.1.1 Original Text ------------- 3.1.1 Identifying a P2MP MPLS TE LSP [RFC4379] defines how an MPLS TE LSP under test may be identified in an echo request. A Target FEC Stack TLV is used to carry either an RSVP IPv4 Session or an RSVP IPv6 Session sub-TLV. In order to identify the P2MP MPLS TE LSP under test, the echo request message MUST carry a Target FEC Stack TLV, and this MUST carry exactly one of two new sub-TLVs: either an RSVP P2MP IPv4 Session sub-TLV or an RSVP P2MP IPv6 Session sub-TLV. These sub-TLVs carry fields from the RSVP-TE P2MP SESSION and SENDER_TEMPLATE objects [RFC4875] and so provide sufficient information to uniquely identify the LSP. The new sub-TLVs are assigned Sub-Type identifiers as follows, and are described in the following sections. Sub-Type # Length Value Field ---------- ------ ----------- 17 20 RSVP P2MP IPv4 Session 18 56 RSVP P2MP IPv6 Session Corrected Text -------------- 3.1.1. Identifying a P2MP MPLS TE LSP [RFC4379] defines how an MPLS TE LSP under test may be identified in an echo request. A Target FEC Stack TLV is used to carry either an RSVP IPv4 Session or an RSVP IPv6 Session sub-TLV. In order to identify the P2MP MPLS TE LSP under test, the echo request message MUST carry a Target FEC Stack TLV, and this MUST carry exactly one of two new sub-TLVs: either an RSVP P2MP IPv4 Session sub-TLV or an RSVP P2MP IPv6 Session sub-TLV. These sub-TLVs carry fields from the RSVP-TE P2MP SESSION and SENDER_TEMPLATE objects [RFC4875] and so provide sufficient information to uniquely identify the LSP. The new sub-TLVs are assigned Sub-Type identifiers as follows, and are described in the following sections. Sub-Type # Length Value Field ---------- ------ ----------- 17 20 RSVP P2MP IPv4 Session 18 44 RSVP P2MP IPv6 Session Notes ----- Dear authors of RFC 6425, I believe the length of the "RSVP P2MP IPv6 Session Sub-TLV" in Section 3.1.1 should be 44 bytes and not 56 bytes to match the format shown in Section 3.1.1.2. It may be the 56 byte figure was copied over from RFC 4379 which uses a 16-byte "IPv6 tunnel end point address" as the top field in the sub-TLV in the case of an IPv6 P2P RSVP session. With an IPv6 P2MP RSVP session that field is replaced with the P2MP-ID which is a 4-byte field only. Mustapha. 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. -------------------------------------- RFC6425 (draft-ietf-mpls-p2mp-lsp-ping-18) -------------------------------------- Title : Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping Publication Date : November 2011 Author(s) : S. Saxena, Ed., G. Swallow, Z. Ali, A. Farrel, S. Yasukawa, T. Nadeau Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From lizhong.jin@zte.com.cn Wed Aug 1 18:40: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 D686511E8141 for ; Wed, 1 Aug 2012 18:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.373 X-Spam-Level: X-Spam-Status: No, score=-101.373 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIFCRz+P7Bm7 for ; Wed, 1 Aug 2012 18:40:51 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id B234211E8136 for ; Wed, 1 Aug 2012 18:40:50 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 10723806486374; Thu, 2 Aug 2012 09:29:25 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 23705.2930047480; Thu, 2 Aug 2012 09:40:35 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q721efGO084766; Thu, 2 Aug 2012 09:40:41 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) To: loa@pi.nu MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Thu, 2 Aug 2012 09:40:26 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-02 09:40:35, Serialize complete at 2012-08-02 09:40:35 Content-Type: multipart/alternative; boundary="=_alternative 000936FF48257A4E_=" X-MAIL: mse02.zte.com.cn q721efGO084766 Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-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, 02 Aug 2012 01:40:52 -0000 This is a multipart message in MIME format. --=_alternative 000936FF48257A4E_= Content-Type: text/plain; charset="US-ASCII" Yes, support as co-author. Lizhong > > > ------------------------------ > > Message: 3 > Date: Tue, 31 Jul 2012 14:11:16 +0200 > From: Loa Andersson > To: "mpls@ietf.org" , Martin Vigoureux > > Cc: "mpls-chairs@tools.ietf.org" > Subject: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-04 > Message-ID: <5017CB64.9070507@pi.nu> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Working group, > > this is to start a two week poll on adopting > draft-jin-mpls-mldp-leaf-discovery-04 > as an MPLS working group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). > > This poll ends August 17, 2012. > > /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 > > --=_alternative 000936FF48257A4E_= Content-Type: text/html; charset="US-ASCII"
Yes, support as co-author.

Lizhong

>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 31 Jul 2012 14:11:16 +0200
> From: Loa Andersson <loa@pi.nu>
> To: "mpls@ietf.org" <mpls@ietf.org>,    Martin Vigoureux
>    <martin.vigoureux@alcatel-lucent.com>
> Cc: "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>
> Subject: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-04
> Message-ID: <5017CB64.9070507@pi.nu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Working group,
>
> this is to start a two week poll on adopting
> draft-jin-mpls-mldp-leaf-discovery-04
> as an MPLS working group document.
>
> Please send your comments (support/not support) to the mpls working
> group mailing list (mpls@ietf.org).
>
> This poll ends August 17, 2012.
>
> /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
>
>
  --=_alternative 000936FF48257A4E_=-- From kebo.liu@nsn.com Wed Aug 1 19:10: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 BC43711E80EF for ; Wed, 1 Aug 2012 19:10:31 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7X+y1-36yGe for ; Wed, 1 Aug 2012 19:10:31 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id AF13E21F86F7 for ; Wed, 1 Aug 2012 19:10:14 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q722A3jm002606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Aug 2012 04:10:03 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q722A2Nh000682; Thu, 2 Aug 2012 04:10:02 +0200 Received: from CNBEEXC006.nsn-intra.net ([10.159.192.11]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Aug 2012 04:09:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD7053.C2B89DDD" Date: Thu, 2 Aug 2012 10:08:51 +0800 Message-ID: <93CE5B70F336A74BB298150C6B9906DCFC7730@CNBEEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-04 Thread-Index: Ac1wT+DBZpPxriOdQKigncTvbq7oIQAA80zw References: From: "Liu, Kebo (NSN - CN/Shanghai)" To: "ext Lizhong Jin" , X-OriginalArrivalTime: 02 Aug 2012 02:09:35.0912 (UTC) FILETIME=[DD300280:01CD7053] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 5953 X-purgate-ID: 151667::1343873406-000055D8-87CB5D47/0-0/0-0 Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-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, 02 Aug 2012 02:10:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD7053.C2B89DDD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, support as co-author.=20 BR Liu Kebo=20 >=20 >=20 > ------------------------------ >=20 > Message: 3 > Date: Tue, 31 Jul 2012 14:11:16 +0200 > From: Loa Andersson > To: "mpls@ietf.org" , Martin Vigoureux > > Cc: "mpls-chairs@tools.ietf.org" > Subject: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-04 > Message-ID: <5017CB64.9070507@pi.nu> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >=20 > Working group, >=20 > this is to start a two week poll on adopting > draft-jin-mpls-mldp-leaf-discovery-04 > as an MPLS working group document. >=20 > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). >=20 > This poll ends August 17, 2012. >=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 >=20 >=20 =20 ------_=_NextPart_001_01CD7053.C2B89DDD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, support = as co-author.

BR

Liu Kebo

> =
>
> ------------------------------
>
> = Message: 3
> Date: Tue, 31 Jul 2012 14:11:16 +0200
> From: = Loa Andersson <loa@pi.nu>
> = To: "mpls@ietf.org" = <mpls@ietf.org>,   =  Martin Vigoureux
>    <martin.vigoureux@alca= tel-lucent.com>
> Cc: "mpls-chairs@tools.ietf.org= " <mpls-chairs@tools.ietf.org= >
> Subject: [mpls] wg doc poll on = draft-jin-mpls-mldp-leaf-discovery-04
> Message-ID: <5017CB64.9070507@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-jin-mpls-mldp-leaf-discovery-04
> as an MPLS working group = document.
>
> Please send your comments (support/not = support) to the mpls working
> group mailing list (mpls@ietf.org).
>
> This = poll ends August 17, 2012.
>
> /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
>
>
 <= o:p>

------_=_NextPart_001_01CD7053.C2B89DDD-- From c-sai@bx.jp.nec.com Wed Aug 1 19:29: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 14C0311E819F for ; Wed, 1 Aug 2012 19:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWvuMiQinXhg for ; Wed, 1 Aug 2012 19:29:19 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by ietfa.amsl.com (Postfix) with ESMTP id 559E711E8199 for ; Wed, 1 Aug 2012 19:29:19 -0700 (PDT) Received: from mailgate3.nec.co.jp ([10.7.69.160]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id q722TIIf021188; Thu, 2 Aug 2012 11:29:18 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id q722TI328605; Thu, 2 Aug 2012 11:29:18 +0900 (JST) Received: from mail03.kamome.nec.co.jp (mail03.kamome.nec.co.jp [10.25.43.7]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id q722Slvx012680; Thu, 2 Aug 2012 11:29:17 +0900 (JST) Received: from kogoro.jp.nec.com ([10.26.220.12] [10.26.220.12]) by mail01b.kamome.nec.co.jp with ESMTP id BT-MMP-740022; Thu, 2 Aug 2012 11:28:38 +0900 Received: from vpcja157 ([10.38.16.157] [10.38.16.157]) by mail.jp.nec.com with ESMTPA id BT-MMP-19899; Thu, 2 Aug 2012 11:28:38 +0900 From: "Zhenlong Cui" To: References: <4FFC3316.3080302@pi.nu> <500ED60E.5000106@pi.nu> Date: Thu, 2 Aug 2012 11:28:38 +0900 Message-ID: <3AFBF670976B4A6DA30E62D2E7B90951@nsl.ad.nec.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <500ED60E.5000106@pi.nu> Thread-Index: Ac1pvqz03hHVGujoRIaJ2b+LpTgbhAGl6xoA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Cc: 'MPLS-TP ad hoc team' Subject: Re: [mpls] wg last call draft-ietf-mpls-tp-itu-t-identifiers-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: Thu, 02 Aug 2012 02:29:20 -0000 support best regards, Zhenlong > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Wednesday, July 25, 2012 2:06 AM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; MPLS-TP ad hoc team; draft-ietf-mpls-tp-itu-t-identifiers@tools.ietf.org > Subject: Re: [mpls] wg last call draft-ietf-mpls-tp-itu-t-identifiers-03 > > Working Group, > > this working group last call were supposed to end on July 22nd. > > However, we have not had one single comment on the draft during > the last call period. > > We are therefore extending the wg last call until August 10, 2012. > > We have also selected some members of the of the MPLS Review Team > whom we asked to review the draft and respond during the extended > working group last > call period. > > /Loa > for the MPLS wG co-charis > > On 2012-07-10 15:50, Loa Andersson wrote: > > Working Group, > > > > this is to start a working group last call on > > draft-ietf-mpls-tp-itu-t-identifiers-03. > > > > Please send your comments to the MPLS wg mailing list (mpls@ietf.org). > > > > We have done an IPR poll among the authors and on the mpls wg mailing > > list. All the authors has responded that they are not aware any IPR > > claims on this document. > > > > No IPR disclosures has been filed against this document. > > > > This working group last call would normally end July 22, 2012, but > > since we at that time are in the publication cut-off period prior to > > the Vancouver meeting this wg last call ends when the cut-off is > > lifted. > > > > /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 kireeti@juniper.net Thu Aug 2 09:53: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 A20F421E80AC for ; Thu, 2 Aug 2012 09:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W97aDZtDRvrQ for ; Thu, 2 Aug 2012 09:53:10 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF5311E8104 for ; Thu, 2 Aug 2012 09:53:10 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUBqwdulizHw4iNFPYDAbjLqAEwJZydgH@postini.com; Thu, 02 Aug 2012 09:53:10 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 2 Aug 2012 09:52:38 -0700 From: Kireeti Kompella To: "mpls@ietf.org" Date: Thu, 2 Aug 2012 09:52:37 -0700 Thread-Topic: LSP ping clarification Thread-Index: Ac1wzzki69ebl44gTwKXh4Oa5HwQVA== Message-ID: 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 Subject: [mpls] LSP ping clarification 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, 02 Aug 2012 16:53:11 -0000 Hi All, Since there have been some questions about how LSP ping works in the contex= t of entropy labels, and concerns about the mechanism, I thought I would ex= plain how LSP ping explores ECMP paths, what some of the limitations are, a= nd to what extent they can be overcome. To begin, LSP ping explores ECMP paths. It does so by finding a value for = a specific field while leaving the remaining fields used for load balancing= fixed (think partial derivatives) (okay, that probably wasn't helpful). I= n the IP case, this field is the IP dest address; in the label case, it is = the entropy label field. Example: for a packet that is part of an Ethernet= PW, assume all routers use as load balancing fields: outer label, entropy = label, PW label. The field that changes is the entropy label, and the rest= are kept constant. Note: since the ELI is a reserved label, it is not use= d for load balancing. Let's say the ping is from node X to node Y. X has one downstream, A. A h= as two downstreams, B1 and B2. B1 has two downstreams, C11 and C12; B2 has= three downstreams: C21, C22 and C23. Cij are connected to Y. To explore paths, X creates a label stack , where TL is the= label that goes from X via A to Y, and PL is the signaled PW label from X = to Y. In the payload (LSP ping packet), X inserts a description of a set S= of labels, typically including E, sets TTL=3D1 and sends the packet to A. X then changes E (and TTL) such that the resulting packet traverses each of= the 5 paths from X to Y. =20 Let's say that X chooses as the initial set of labels 20-24; A replies that= 20 and 21 go to B1 (i.e., if A got a label stack of , it = would send the packet to B1) and 22-24 go to B2. X then sends a packet wit= h label stack to B1 (by setting TTL=3D2, and inserts the = label set of {20, 21}. If all the stars line up, B1 could reply that an en= tropy label of 20 goes to C11, and 21 goes to C12. Similarly, X sends a pi= ng packet to B2 with label set {22, 23, 24}. So, if X was really lucky, an= initial label set of just five labels could be sufficient to explore the 5= paths. It is possible that no choice of entropy label will explore a particular pa= th. If A sent only packets with with odd E to B1, and B1 = sent all packets with with odd E to C11, there is no entr= opy label that would explore the path to C12. Highly unlikely, but possibl= e. It could also be that a very small set of labels explore the path to C1= 2; finding one such label might require that X sends different label sets t= o B1 over several iterations until it found one. In general, the more ECMP choices one has to be make to pick a particular p= ath, the harder it is to find a label to explore it. To sum up, the methodology is reasonably reasonable but not fool-proof. It= is up to X to pick adequate-sized label sets to explore paths: large enoug= h to expect non-empty replies, but not too large as to be unwieldy. It is = also up to X to retry a few times if it got back empty replies, but to thro= w up its hands (and report to the user/logging system) if it can't explore = some sub-dag of ECMP paths. I would be very happy to hear other approaches to exploring ECMPs. Proposed action item 1: reduce the OAM section to refer to a future draft t= hat explains the above. PAI 2: write said future draft. If acceptable, I will do both the above. If someone has a new/tweaked mech= anism that better addresses the problem of exploring paths, that should go = into this draft. Kireeti. From aldrin.ietf@gmail.com Thu Aug 2 10:02: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 A8D6921E80EE for ; Thu, 2 Aug 2012 10:02:56 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVFuz-zaN8H7 for ; Thu, 2 Aug 2012 10:02:55 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9094821E80E8 for ; Thu, 2 Aug 2012 10:02:54 -0700 (PDT) Received: by ggnc4 with SMTP id c4so9680672ggn.31 for ; Thu, 02 Aug 2012 10:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Ay7BXkju8s1zbHKnnSyiJFzB4VCUubjfuQRvmix4Mrc=; b=QCl2B0H6DXFUjXedlP2NA3YQb4NidFTUzqHsp+36+f84zsJn7TRJMTxNDkzExWj9hJ s/zP5JSFdjNjT3dK8IaJuCtpAmCphAUrmA4u/ixkj7KE3bUTqA2S/KkhMLM9HvJQ7vrr qCIgbtmKXcKh2N/HhzFCAMmBxAnQ2PxN6vWjnwv2HIer+fJx8GS/ozrbPjzBX9aQPlFv qi5um0gF90CEPKe3NaWBti56d6XG6XPruqEhT+QX1CDRNV1UwPOYJfXZN0+DfkedFIBh 2vdLaKeMR91fGgJzB6qM+Ae3qgkjwqA2gACFZOeL17KDPQOJUBtJb4aE3yxCo5XUgHJP 5neQ== Received: by 10.60.1.165 with SMTP id 5mr37879552oen.70.1343926974134; Thu, 02 Aug 2012 10:02:54 -0700 (PDT) Received: from dhcp-13d4.meeting.ietf.org (dhcp-13d4.meeting.ietf.org. [130.129.19.212]) by mx.google.com with ESMTPS id k8sm4952639oeh.9.2012.08.02.10.02.51 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Aug 2012 10:02:52 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Sam Aldrin In-Reply-To: Date: Thu, 2 Aug 2012 10:02:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <615DC110-7E05-49E2-9AB1-E9323C83F6FD@gmail.com> References: To: Kireeti Kompella X-Mailer: Apple Mail (2.1485) Cc: "mpls@ietf.org" Subject: Re: [mpls] LSP ping clarification 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, 02 Aug 2012 17:02:56 -0000 Hi Kireeti, =46rom high level perspective, it works. I have few thoughts which would make the solution robust. It also = involves without changing much of the existing format. Do you have some = time to discuss? Would be happy to share my input with you. cheers -sam On Aug 2, 2012, at 9:52 AM, Kireeti Kompella = wrote: > Hi All, >=20 > Since there have been some questions about how LSP ping works in the = context of entropy labels, and concerns about the mechanism, I thought I = would explain how LSP ping explores ECMP paths, what some of the = limitations are, and to what extent they can be overcome. >=20 > To begin, LSP ping explores ECMP paths. It does so by finding a value = for a specific field while leaving the remaining fields used for load = balancing fixed (think partial derivatives) (okay, that probably wasn't = helpful). In the IP case, this field is the IP dest address; in the = label case, it is the entropy label field. Example: for a packet that = is part of an Ethernet PW, assume all routers use as load balancing = fields: outer label, entropy label, PW label. The field that changes is = the entropy label, and the rest are kept constant. Note: since the ELI = is a reserved label, it is not used for load balancing. >=20 > Let's say the ping is from node X to node Y. X has one downstream, A. = A has two downstreams, B1 and B2. B1 has two downstreams, C11 and C12; = B2 has three downstreams: C21, C22 and C23. Cij are connected to Y. >=20 > To explore paths, X creates a label stack , where TL = is the label that goes from X via A to Y, and PL is the signaled PW = label from X to Y. In the payload (LSP ping packet), X inserts a = description of a set S of labels, typically including E, sets TTL=3D1 = and sends the packet to A. >=20 > X then changes E (and TTL) such that the resulting packet traverses = each of the 5 paths from X to Y. =20 >=20 > Let's say that X chooses as the initial set of labels 20-24; A replies = that 20 and 21 go to B1 (i.e., if A got a label stack of , it would send the packet to B1) and 22-24 go to B2. X then sends a = packet with label stack to B1 (by setting TTL=3D2, and = inserts the label set of {20, 21}. If all the stars line up, B1 could = reply that an entropy label of 20 goes to C11, and 21 goes to C12. = Similarly, X sends a ping packet to B2 with label set {22, 23, 24}. So, = if X was really lucky, an initial label set of just five labels could be = sufficient to explore the 5 paths. >=20 > It is possible that no choice of entropy label will explore a = particular path. If A sent only packets with with odd = E to B1, and B1 sent all packets with with odd E to = C11, there is no entropy label that would explore the path to C12. = Highly unlikely, but possible. It could also be that a very small set = of labels explore the path to C12; finding one such label might require = that X sends different label sets to B1 over several iterations until it = found one. >=20 > In general, the more ECMP choices one has to be make to pick a = particular path, the harder it is to find a label to explore it. >=20 > To sum up, the methodology is reasonably reasonable but not = fool-proof. It is up to X to pick adequate-sized label sets to explore = paths: large enough to expect non-empty replies, but not too large as to = be unwieldy. It is also up to X to retry a few times if it got back = empty replies, but to throw up its hands (and report to the user/logging = system) if it can't explore some sub-dag of ECMP paths. >=20 > I would be very happy to hear other approaches to exploring ECMPs. >=20 > Proposed action item 1: reduce the OAM section to refer to a future = draft that explains the above. >=20 > PAI 2: write said future draft. >=20 > If acceptable, I will do both the above. If someone has a new/tweaked = mechanism that better addresses the problem of exploring paths, that = should go into this draft. >=20 > Kireeti. >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From internet-drafts@ietf.org Thu Aug 2 11: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 A010611E80F9; Thu, 2 Aug 2012 11:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSPs28LAzyHq; Thu, 2 Aug 2012 11:10:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC45421F8592; Thu, 2 Aug 2012 11:10:39 -0700 (PDT) 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.33 Message-ID: <20120802181039.24873.30552.idtracker@ietfa.amsl.com> Date: Thu, 02 Aug 2012 11:10:39 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-dod-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, 02 Aug 2012 18:10:44 -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 Downstream-on-Demand in Seamless MPLS Author(s) : Thomas Beckhaus Bruno Decraene Kishore Tiruveedhula Maciek Konstantynowicz Luca Martini Filename : draft-ietf-mpls-ldp-dod-03.txt Pages : 33 Date : 2012-08-02 Abstract: Seamless MPLS design enables a single IP/MPLS network to scale over core, metro and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access, including high number of devices, their position in network topology and their compute and memory constraints that limit the amount of state access devices can hold.This can be achieved with LDP Downstream-on-Demand (LDP DoD) label advertisement. This document describes LDP DoD use cases and lists required LDP DoD procedures in the context of Seamless MPLS design. In addition, a new optional TLV type in the LDP label request message is defined for fast-up convergence. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-dod There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-dod-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-ldp-dod-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tnadeau@lucidvision.com Thu Aug 2 13:56: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 EFEFF11E8140 for ; Thu, 2 Aug 2012 13:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZlMaKHKAUtd for ; Thu, 2 Aug 2012 13:56:39 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8E07911E80E8 for ; Thu, 2 Aug 2012 13:56:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id F3150220E657 for ; Thu, 2 Aug 2012 16:56:37 -0400 (EDT) X-Virus-Scanned: amavisd-new at www.lucidvision.com Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3405S2WOztp for ; Thu, 2 Aug 2012 16:56:37 -0400 (EDT) Received: from tnadeau-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) by lucidvision.com (Postfix) with ESMTP id 8CB7D220E654 for ; Thu, 2 Aug 2012 16:56:37 -0400 (EDT) From: Thomas Nadeau Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <997267F9-C0CF-425C-98B9-55AD309223AF@lucidvision.com> Date: Thu, 2 Aug 2012 13:56:34 -0700 To: "mpls@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) X-Mailer: Apple Mail (2.1485) Subject: [mpls] Isocore MPLS 2012 Conference 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, 02 Aug 2012 20:56:40 -0000 The MPLS 2012 Conference (the 15th annual event) program is now posted = and is available at www.mpls2012.com, or=20 Tutorial (Sun): http://www.isocore.com/mpls2012/program/tutorials.htm=20 Technical sessions (Mon- Wed): = http://www.isocore.com/mpls2012/program/technical_sessions.htm=20 The conference will take place October 28- 31 in Washington DC and will = include an extensive four day program=20 consisting of tutorials, technical sessions, panels, and exhibits. The = key topics to be discussed at this year's=20 conference include: cloud computing, data centers, SDN (software = defined/driven networks), packet transport technologies, mobile backhaul, optical transport, MPLS-TP, and latest in = MPLS services. The conference hotel is the Marriott Wardman Park in Washington DC. = Please=20 note that there are only a limited number of rooms available this year = at a=20 reduced rate. Please make reservations at:=20 https://resweb.passkey.com/Resweb.do?mode=3Dwelcome_gi_new&groupID=3D85471= 86 _______________________________________________ TPC-MPLS2012-L mailing list TPC-MPLS2012-L@isocore.com http://isocore.com/mailman/listinfo/tpc-mpls2012-l_isocore.com From aldrin.ietf@gmail.com Thu Aug 2 14:38: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 892BA21E8095 for ; Thu, 2 Aug 2012 14:38:49 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmGCFxbKKCWc for ; Thu, 2 Aug 2012 14:38:48 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id C6EFE21E8043 for ; Thu, 2 Aug 2012 14:38:47 -0700 (PDT) Received: by yhq56 with SMTP id 56so5131yhq.31 for ; Thu, 02 Aug 2012 14:38:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=66loqcNGgTnBD/6R2cie2qYOUQoXHIbpEf2vi6PkM10=; b=fl+dl22MIXqmDI3LEH4D764U2Vm06Vig6GdJm/mjLAkx3nTcRpxFrFKkXe8Ws7rqcV uEJxKx/cS1fHuiqCVGzmkN12JpXFnTi9RzZUFbVHQmYLC04EdEHpZGCJsEaO7EqfvOqv PA9bYTAvi9bMJvxSAQ/1TPbh45h6KpODIGUeLj5JlOd5sqapMZxB5CFep0gekC6HnDDB l58yt7ad7GUc4rhn5RQSMVy4spAzRoayDiV94o7sqLVAvx531BBf4don7HD3Tku1suWd rUHRHmN6H/PfaBprNIRNZ2oycybrM5SxWzmhPaVTy4we2coVYRau/XTakzsOLCgpHcwO 0bXw== Received: by 10.50.160.168 with SMTP id xl8mr6239224igb.25.1343943526758; Thu, 02 Aug 2012 14:38:46 -0700 (PDT) Received: from ?IPv6:2001:df8::16:75e4:67d6:b459:80b4? ([2001:df8:0:16:75e4:67d6:b459:80b4]) by mx.google.com with ESMTPS id va9sm18693332igb.17.2012.08.02.14.38.44 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Aug 2012 14:38:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Sam Aldrin In-Reply-To: Date: Thu, 2 Aug 2012 14:38:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Kireeti Kompella X-Mailer: Apple Mail (2.1485) Cc: "mpls@ietf.org" Subject: Re: [mpls] LSP ping clarification 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, 02 Aug 2012 21:38:49 -0000 Kireeti, et al, The below mechanism is exactly how the present deployments are using to = monitor ECMP paths. The only caveat is, as there was no entropy label being present thus = far, the only way one could use was IP destination address (which is = local host address). Many hardware platforms have an issue with = destination address as local host address and in some cases the devices = need not be IP aware. Entropy label provides a clean way to make this work to monitor/diagnose = the ECMP paths. All one needs to do is use hash type 2 or 4 and choose = the multi path info appropriately. To Kireeti's statement "In general, the more ECMP choices one has to be = make to pick a particular path, the harder it is to find a label to = explore it.". Having implemented ECMP monitoring with LSP ping, I do not = think this is hard. Perfectly achievable and unless the load balance = algorithm on a h/w is 'extremely' sub-optimal, it is not that difficult = to find right hash to traverse each of the ECMP paths. RFC4379 provides = option to increase the size and range to extend the labels upon = exhaustion. I do not see a problem why ECMP OAM for MPLS LSP's cannot be achieved = with entropy label. I also do not see the need for a new draft or = extension as RFC4379 is well written and captures this case as well. But = if WG feels the need for an informational draft on how to achieve ECMP = monitoring in different cases with or without entropy label, glad to = write one. HTH, -sam On Aug 2, 2012, at 9:52 AM, Kireeti Kompella = wrote: > Hi All, >=20 > Since there have been some questions about how LSP ping works in the = context of entropy labels, and concerns about the mechanism, I thought I = would explain how LSP ping explores ECMP paths, what some of the = limitations are, and to what extent they can be overcome. >=20 > To begin, LSP ping explores ECMP paths. It does so by finding a value = for a specific field while leaving the remaining fields used for load = balancing fixed (think partial derivatives) (okay, that probably wasn't = helpful). In the IP case, this field is the IP dest address; in the = label case, it is the entropy label field. Example: for a packet that = is part of an Ethernet PW, assume all routers use as load balancing = fields: outer label, entropy label, PW label. The field that changes is = the entropy label, and the rest are kept constant. Note: since the ELI = is a reserved label, it is not used for load balancing. >=20 > Let's say the ping is from node X to node Y. X has one downstream, A. = A has two downstreams, B1 and B2. B1 has two downstreams, C11 and C12; = B2 has three downstreams: C21, C22 and C23. Cij are connected to Y. >=20 > To explore paths, X creates a label stack , where TL = is the label that goes from X via A to Y, and PL is the signaled PW = label from X to Y. In the payload (LSP ping packet), X inserts a = description of a set S of labels, typically including E, sets TTL=3D1 = and sends the packet to A. >=20 > X then changes E (and TTL) such that the resulting packet traverses = each of the 5 paths from X to Y. =20 >=20 > Let's say that X chooses as the initial set of labels 20-24; A replies = that 20 and 21 go to B1 (i.e., if A got a label stack of , it would send the packet to B1) and 22-24 go to B2. X then sends a = packet with label stack to B1 (by setting TTL=3D2, and = inserts the label set of {20, 21}. If all the stars line up, B1 could = reply that an entropy label of 20 goes to C11, and 21 goes to C12. = Similarly, X sends a ping packet to B2 with label set {22, 23, 24}. So, = if X was really lucky, an initial label set of just five labels could be = sufficient to explore the 5 paths. >=20 > It is possible that no choice of entropy label will explore a = particular path. If A sent only packets with with odd = E to B1, and B1 sent all packets with with odd E to = C11, there is no entropy label that would explore the path to C12. = Highly unlikely, but possible. It could also be that a very small set = of labels explore the path to C12; finding one such label might require = that X sends different label sets to B1 over several iterations until it = found one. >=20 > In general, the more ECMP choices one has to be make to pick a = particular path, the harder it is to find a label to explore it. >=20 > To sum up, the methodology is reasonably reasonable but not = fool-proof. It is up to X to pick adequate-sized label sets to explore = paths: large enough to expect non-empty replies, but not too large as to = be unwieldy. It is also up to X to retry a few times if it got back = empty replies, but to throw up its hands (and report to the user/logging = system) if it can't explore some sub-dag of ECMP paths. >=20 > I would be very happy to hear other approaches to exploring ECMPs. >=20 > Proposed action item 1: reduce the OAM section to refer to a future = draft that explains the above. >=20 > PAI 2: write said future draft. >=20 > If acceptable, I will do both the above. If someone has a new/tweaked = mechanism that better addresses the problem of exploring paths, that = should go into this draft. >=20 > Kireeti. >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From kvivek@broadcom.com Thu Aug 2 22:21: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 748B211E809B for ; Thu, 2 Aug 2012 22:21:56 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70-s5+EwCxD7 for ; Thu, 2 Aug 2012 22:21:55 -0700 (PDT) Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id D10CB21F8CD8 for ; Thu, 2 Aug 2012 22:21:54 -0700 (PDT) Received: from [10.16.192.232] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Thu, 02 Aug 2012 22:20:05 -0700 X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.10) by SJEXCHHUB02.corp.ad.broadcom.com (10.16.192.232) with Microsoft SMTP Server (TLS) id 8.2.247.2; Thu, 2 Aug 2012 22:21:41 -0700 Received: from SJEXCHMB09.corp.ad.broadcom.com ( [fe80::3da7:665e:cc78:181f]) by SJEXCHCAS04.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Thu, 2 Aug 2012 22:21:20 -0700 From: "Vivek Kumar" To: "mpls@ietf.org" Thread-Topic: mpls Digest, Vol 100, Issue 4 Thread-Index: AQHNcOFFS7i1gm2a2Emh4HJ9MsalpZdHi4lg Date: Fri, 3 Aug 2012 05:21:20 +0000 Message-ID: <3C086BA39C55B9418AE8FEA3F3EFDEC407597B@SJEXCHMB09.corp.ad.broadcom.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.75.111] MIME-Version: 1.0 X-WSS-ID: 7C05800F49815567558-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [mpls] mpls Digest, Vol 100, Issue 4 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, 03 Aug 2012 05:21:56 -0000 Hi Kireeti, =20 What about making some TTL/EXP field of ELI as magic value( say TTL=3D50= or EXP=3D7) to indicate that if ELI has TTL=3D50 or EXP=3D7 , the use EL v= alue directly to index one of ECMP member. For example , if ELI.TTL=3D50 , and EL=3D1 , then select first member of= ECMP group and if EL=3D2 , then next member and so on.. Not sure if it is possible to have this kind of magic value for TTL or E= XP . Let me know your feedback. Regards, Vivek -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of mpl= s-request@ietf.org Sent: Friday, August 03, 2012 12:31 AM To: mpls@ietf.org Subject: mpls Digest, Vol 100, Issue 4 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to=20 https://www.ietf.org/mailman/listinfo/mpls Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send mpls mailing list submissions to mpls@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/mpls or, via email, send a message with subject or body 'help' to mpls-request@ietf.org You can reach the person managing the list at mpls-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of mpls digest..." Today's Topics: 1. Re: LSP ping clarification (Sam Aldrin) 2. I-D Action: draft-ietf-mpls-ldp-dod-03.txt (internet-drafts@ietf.org) ---------------------------------------------------------------------- Message: 1 Date: Thu, 2 Aug 2012 10:02:51 -0700 From: Sam Aldrin To: Kireeti Kompella Cc: "mpls@ietf.org" Subject: Re: [mpls] LSP ping clarification Message-ID: <615DC110-7E05-49E2-9AB1-E9323C83F6FD@gmail.com> Content-Type: text/plain; charset=3Dus-ascii Hi Kireeti, >From high level perspective, it works. I have few thoughts which would make the solution robust. It also involves = without changing much of the existing format. Do you have some time to disc= uss? Would be happy to share my input with you. cheers -sam On Aug 2, 2012, at 9:52 AM, Kireeti Kompella wrote: > Hi All, >=20 > Since there have been some questions about how LSP ping works in the cont= ext of entropy labels, and concerns about the mechanism, I thought I would = explain how LSP ping explores ECMP paths, what some of the limitations are,= and to what extent they can be overcome. >=20 > To begin, LSP ping explores ECMP paths. It does so by finding a value fo= r a specific field while leaving the remaining fields used for load balanci= ng fixed (think partial derivatives) (okay, that probably wasn't helpful). = In the IP case, this field is the IP dest address; in the label case, it i= s the entropy label field. Example: for a packet that is part of an Ethern= et PW, assume all routers use as load balancing fields: outer label, entrop= y label, PW label. The field that changes is the entropy label, and the re= st are kept constant. Note: since the ELI is a reserved label, it is not u= sed for load balancing. >=20 > Let's say the ping is from node X to node Y. X has one downstream, A. A= has two downstreams, B1 and B2. B1 has two downstreams, C11 and C12; B2 h= as three downstreams: C21, C22 and C23. Cij are connected to Y. >=20 > To explore paths, X creates a label stack , where TL is t= he label that goes from X via A to Y, and PL is the signaled PW label from = X to Y. In the payload (LSP ping packet), X inserts a description of a set= S of labels, typically including E, sets TTL=3D1 and sends the packet to A= . >=20 > X then changes E (and TTL) such that the resulting packet traverses each = of the 5 paths from X to Y. =20 >=20 > Let's say that X chooses as the initial set of labels 20-24; A replies th= at 20 and 21 go to B1 (i.e., if A got a label stack of , i= t would send the packet to B1) and 22-24 go to B2. X then sends a packet w= ith label stack to B1 (by setting TTL=3D2, and inserts th= e label set of {20, 21}. If all the stars line up, B1 could reply that an = entropy label of 20 goes to C11, and 21 goes to C12. Similarly, X sends a = ping packet to B2 with label set {22, 23, 24}. So, if X was really lucky, = an initial label set of just five labels could be sufficient to explore the= 5 paths. >=20 > It is possible that no choice of entropy label will explore a particular = path. If A sent only packets with with odd E to B1, and B= 1 sent all packets with with odd E to C11, there is no en= tropy label that would explore the path to C12. Highly unlikely, but possi= ble. It could also be that a very small set of labels explore the path to = C12; finding one such label might require that X sends different label sets= to B1 over several iterations until it found one. >=20 > In general, the more ECMP choices one has to be make to pick a particular= path, the harder it is to find a label to explore it. >=20 > To sum up, the methodology is reasonably reasonable but not fool-proof. = It is up to X to pick adequate-sized label sets to explore paths: large eno= ugh to expect non-empty replies, but not too large as to be unwieldy. It i= s also up to X to retry a few times if it got back empty replies, but to th= row up its hands (and report to the user/logging system) if it can't explor= e some sub-dag of ECMP paths. >=20 > I would be very happy to hear other approaches to exploring ECMPs. >=20 > Proposed action item 1: reduce the OAM section to refer to a future draft= that explains the above. >=20 > PAI 2: write said future draft. >=20 > If acceptable, I will do both the above. If someone has a new/tweaked me= chanism that better addresses the problem of exploring paths, that should g= o into this draft. >=20 > Kireeti. >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls ------------------------------ Message: 2 Date: Thu, 02 Aug 2012 11:10:39 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-dod-03.txt Message-ID: <20120802181039.24873.30552.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=3D"utf-8" 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 Downstream-on-Demand in Seamless MPLS Author(s) : Thomas Beckhaus Bruno Decraene Kishore Tiruveedhula Maciek Konstantynowicz Luca Martini Filename : draft-ietf-mpls-ldp-dod-03.txt Pages : 33 Date : 2012-08-02 Abstract: Seamless MPLS design enables a single IP/MPLS network to scale over core, metro and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access, including high number of devices, their position in network topology and their compute and memory constraints that limit the amount of state access devices can hold.This can be achieved with LDP Downstream-on-Demand (LDP DoD) label advertisement. This document describes LDP DoD use cases and lists required LDP DoD procedures in the context of Seamless MPLS design. In addition, a new optional TLV type in the LDP label request message is defined for fast-up convergence. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-dod There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-dod-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-ldp-dod-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ------------------------------ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls End of mpls Digest, Vol 100, Issue 4 ************************************ From internet-drafts@ietf.org Fri Aug 3 09:41: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 5D70121F8E36; Fri, 3 Aug 2012 09:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hyjp+8LUC7T3; Fri, 3 Aug 2012 09:41:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF4821F8E3B; Fri, 3 Aug 2012 09:41:36 -0700 (PDT) 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.33 Message-ID: <20120803164136.29138.68432.idtracker@ietfa.amsl.com> Date: Fri, 03 Aug 2012 09:41:36 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-targeted-mldp-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: Fri, 03 Aug 2012 16:41:39 -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 : Using LDP Multipoint Extensions on Targeted LDP Sessions Author(s) : Maria Napierala Eric C. Rosen Filename : draft-ietf-mpls-targeted-mldp-00.txt Pages : 9 Date : 2012-08-03 Abstract: Label Distribution Protocol (LDP) can be used to set up Point-to-Multipoint (P2MP) and Multipoint-to-Multipoint (MP2MP) Label Switched Paths. The existing specification for this functionality assumes that a pair of LDP neighbors are directly connected. However, the LDP base specification allows for the case where a pair of LDP neighbors are not directly connected; the LDP session between such a pair of neighbors is known as a "Targeted LDP" session. This document provides the specification for using the LDP P2MP/MP2MP extensions over a Targeted LDP session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-targeted-mldp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-targeted-mldp-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Tina.Tsou.Zouting@huawei.com Fri Aug 3 10:54: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 3FBFD21F8E08 for ; Fri, 3 Aug 2012 10:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.994 X-Spam-Level: X-Spam-Status: No, score=-5.994 tagged_above=-999 required=5 tests=[AWL=0.605, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBfFD9KAQ5VF for ; Fri, 3 Aug 2012 10:54:24 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD2D21F8E01 for ; Fri, 3 Aug 2012 10:54:24 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIQ99948; Fri, 03 Aug 2012 09:54:23 -0800 (PST) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 3 Aug 2012 10:52:27 -0700 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.5]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Fri, 3 Aug 2012 10:52:22 -0700 From: Tina TSOU To: "mpls@ietf.org" Thread-Topic: New Version Notification for draft-manral-mpls-rfc3811bis-01.txt Thread-Index: AQHNcaCYVBU9Ln2RYEyOksJTbbZAxJdIXgGw Date: Fri, 3 Aug 2012 17:52:21 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.93] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [mpls] FW: New Version Notification for draft-manral-mpls-rfc3811bis-01.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: Fri, 03 Aug 2012 17:54:25 -0000 Rm9yIHlvdXIgY29tbWVudHMuDQoNClRpbmENCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnXSANClNlbnQ6IEZyaWRheSwgQXVndXN0IDAzLCAyMDEyIDEwOjUxIEFNDQpUbzog VGluYSBUU09VDQpDYzogdmlzaHdhcy5tYW5yYWxAaHAuY29tDQpTdWJqZWN0OiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW1hbnJhbC1tcGxzLXJmYzM4MTFiaXMtMDEudHh0DQoN Cg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LW1hbnJhbC1tcGxzLXJmYzM4MTFiaXMtMDEu dHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFQuIFRzb3UgYW5kIHBvc3Rl ZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1tYW5yYWwtbXBs cy1yZmMzODExYmlzDQpSZXZpc2lvbjoJIDAxDQpUaXRsZToJCSBEZWZpbml0aW9ucyBvZiBUZXh0 dWFsIENvbnZlbnRpb25zIChUQ3MpIGZvciBNdWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGluZyAo TVBMUykgTWFuYWdlbWVudA0KQ3JlYXRpb24gZGF0ZToJIDIwMTItMDgtMDMNCldHIElEOgkJIElu ZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAyMw0KVVJMOiAgICAgICAgICAg ICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tYW5yYWwtbXBscy1y ZmMzODExYmlzLTAxLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LW1hbnJhbC1tcGxzLXJmYzM4MTFiaXMNCkh0bWxpemVkOiAgICAgICAg aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFucmFsLW1wbHMtcmZjMzgxMWJpcy0w MQ0KRGlmZjogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1tYW5yYWwtbXBscy1yZmMzODExYmlzLTAxDQoNCkFic3RyYWN0Og0KICAgVGhpcyBtZW1vIGRl ZmluZXMgYSBNYW5hZ2VtZW50IEluZm9ybWF0aW9uIEJhc2UgKE1JQikgbW9kdWxlIHdoaWNoDQog ICBjb250YWlucyBUZXh0dWFsIENvbnZlbnRpb25zIHRvIHJlcHJlc2VudCBjb21tb25seSB1c2Vk IE11bHRpcHJvdG9jb2wNCiAgIExhYmVsIFN3aXRjaGluZyAoTVBMUykgbWFuYWdlbWVudCBpbmZv cm1hdGlvbi4gIFRoZSBpbnRlbnQgaXMgdGhhdA0KICAgdGhlc2UgVEVYVFVBTCBDT05WRU5USU9O UyAoVENzKSB3aWxsIGJlIGltcG9ydGVkIGFuZCB1c2VkIGluIE1QTFMNCiAgIHJlbGF0ZWQgTUlC IG1vZHVsZXMgdGhhdCB3b3VsZCBvdGhlcndpc2UgZGVmaW5lIHRoZWlyIG93bg0KICAgcmVwcmVz ZW50YXRpb25zLiAgVGhpcyBkb2N1bWVudCBvYnNvbGV0ZXMgUkZDMzgxMSBhcyBpdCBhZGRyZXNz ZXMgdGhlDQogICBuZWVkIHRvIHN1cHBvcnQgSVB2NiBleHRlbmRlZCBUdW5uZWxJRCdzIGJ5IGRl ZmluaW5nIGEgbmV3IFRDLQ0KICAgTXBsc05ld0V4dGVuZGVkVHVubmVsSUQgd2hpY2ggc3VnZ2Vz dHMgdXNpbmcgSVB2NCBhZGRyZXNzIG9mIHRoZQ0KICAgaW5ncmVzcyBvciBlZ3Jlc3MgTFNSIGZv ciB0aGUgdHVubmVsIGZvciBhbiBJUHY2IG5ldHdvcmsuDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From kvivek@broadcom.com Fri Aug 3 20:52: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 1F97221E803D for ; Fri, 3 Aug 2012 20:52:28 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiPI11hRz0hu for ; Fri, 3 Aug 2012 20:52:27 -0700 (PDT) Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 9937821E8034 for ; Fri, 3 Aug 2012 20:52:27 -0700 (PDT) Received: from [10.16.192.232] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Fri, 03 Aug 2012 20:50:43 -0700 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; Fri, 3 Aug 2012 20:52:21 -0700 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, 3 Aug 2012 20:52:00 -0700 From: "Vivek Kumar" To: "mpls@ietf.org" Thread-Topic: [mpls] LSP ping clarification Thread-Index: AQHNcfR/5m6AIS2yfkias41k6GWR/w== Date: Sat, 4 Aug 2012 03:51:59 +0000 Message-ID: <3C086BA39C55B9418AE8FEA3F3EFDEC4075D22@SJEXCHMB09.corp.ad.broadcom.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.240.253.129] MIME-Version: 1.0 X-WSS-ID: 7C02439949815883866-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [mpls] LSP ping clarification 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, 04 Aug 2012 03:52:28 -0000 Hi Kireeti/Sam, =20 What about making some TTL/EXP field of ELI as magic value( say TTL=3D25= 5 or EXP=3D7) to indicate that if ELI has TTL=3D255 or EXP=3D7 , the use EL= value directly to index one of ECMP member ( without doing hashing). For example , if ELI.TTL=3D255 , and EL=3D1 , then select first member o= f ECMP group and if EL=3D2 , then next member and so on.. Not sure if it is possible to have this kind of magic value for TTL or E= XP but anyway for ELI which is going to be reserved value it should not be = an issue. Let me know your feedback. Regards, Vivek=20 From aldrin.ietf@gmail.com Fri Aug 3 23:30: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 147DD21F8D5F for ; Fri, 3 Aug 2012 23:30:10 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBEaWITne8rI for ; Fri, 3 Aug 2012 23:30:09 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5EB21F8D69 for ; Fri, 3 Aug 2012 23:30:09 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so702968pbb.31 for ; Fri, 03 Aug 2012 23:30:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=m5+cdJEjwoGfvSM0tVrC8DUWVJ0hdap/9IFHbjmJ/Fg=; b=hvjCG/D2Pg7zKrh6Bz9ZJSR0g3SZaMOknCyfU+Ix1TxAyO17BoL3ywRpuV+7gVIwVl j4+ytlCjUojqrmmi341wrbyoHuycpd4qhEOdV8K3u4/8aYZA0Rw7aJ2B/Lje74iufZ9t 4wRR95B/3T/MYJ7yiCpYYWPIkJCxp9QAyVf6d3dIpf1V7qvyd7Jo/5CXWezablo2K4Yf h67T3QgmgQpbgwB21w9730HWg9xxJG06gFjiQ7f7gAwW/ejYWVOY+7Hgp1eOiAZ7Y2Tf V5VjGvylFwI3XmMH0B8WPWy5lVf8Dh7uWya5ClnwuPauGU1Wpu7ofzkUWYoyxEXx7JDe e+sg== Received: by 10.68.203.98 with SMTP id kp2mr2935330pbc.132.1344061808725; Fri, 03 Aug 2012 23:30:08 -0700 (PDT) Received: from dhcp-414c.meeting.ietf.org (dhcp-414c.meeting.ietf.org. [130.129.65.76]) by mx.google.com with ESMTPS id of4sm4423813pbb.51.2012.08.03.23.30.06 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Aug 2012 23:30:07 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Sam Aldrin In-Reply-To: <3C086BA39C55B9418AE8FEA3F3EFDEC4075D22@SJEXCHMB09.corp.ad.broadcom.com> Date: Fri, 3 Aug 2012 23:30:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <176B443F-4AA1-4F90-9936-3B1AF7A89919@gmail.com> References: <3C086BA39C55B9418AE8FEA3F3EFDEC4075D22@SJEXCHMB09.corp.ad.broadcom.com> To: "Vivek Kumar" X-Mailer: Apple Mail (2.1485) Cc: "mpls@ietf.org" Subject: Re: [mpls] LSP ping clarification 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, 04 Aug 2012 06:30:10 -0000 Vivek, Before thinking of new 'magic' fields, why do you think existing = RFC4379 do not work? As I eluded to in my email, existing model perfectly works without any = additional change. -sam On Aug 3, 2012, at 8:51 PM, "Vivek Kumar" wrote: > Hi Kireeti/Sam, >=20 > What about making some TTL/EXP field of ELI as magic value( say = TTL=3D255 or EXP=3D7) to indicate that if ELI has TTL=3D255 or EXP=3D7 , = the use EL value directly to index one of ECMP member ( without doing = hashing). > For example , if ELI.TTL=3D255 , and EL=3D1 , then select first = member of ECMP group and if EL=3D2 , then next member and so on.. >=20 > Not sure if it is possible to have this kind of magic value for TTL = or EXP but anyway for ELI which is going to be reserved value it should = not be an issue. > Let me know your feedback. >=20 > Regards, > Vivek=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From kvivek@broadcom.com Fri Aug 3 23:43: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 BED2A21F8D33 for ; Fri, 3 Aug 2012 23:43:54 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UT4k1JsJtU3o for ; Fri, 3 Aug 2012 23:43:54 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6D221F8D27 for ; Fri, 3 Aug 2012 23:43:54 -0700 (PDT) Received: from [10.16.192.224] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Fri, 03 Aug 2012 23:42:57 -0700 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; Fri, 3 Aug 2012 23:43:45 -0700 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, 3 Aug 2012 23:43:45 -0700 From: "Vivek Kumar" To: "Sam Aldrin" Thread-Topic: [mpls] LSP ping clarification Thread-Index: AQHNcfR/5m6AIS2yfkias41k6GWR/5dJpp2A//+L4vA= Date: Sat, 4 Aug 2012 06:43:44 +0000 Message-ID: <3C086BA39C55B9418AE8FEA3F3EFDEC4075E2D@SJEXCHMB09.corp.ad.broadcom.com> References: <3C086BA39C55B9418AE8FEA3F3EFDEC4075D22@SJEXCHMB09.corp.ad.broadcom.com> <176B443F-4AA1-4F90-9936-3B1AF7A89919@gmail.com> In-Reply-To: <176B443F-4AA1-4F90-9936-3B1AF7A89919@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.240.253.129] MIME-Version: 1.0 X-WSS-ID: 7C021BFB3MK16551302-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" Subject: Re: [mpls] LSP ping clarification 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, 04 Aug 2012 06:43:54 -0000 Hi Sam, Agreed. As you mentioned , RFC 4379 is well equipped to handle explorin= g all ECMP path. The only adv of having "new magic" field is that to traver= se all ECMP path , it does not have to be dependent on how efficient load b= alancing algo underlying hardware support . Do you see any value in it ? Regards, vivek -----Original Message----- From: Sam Aldrin [mailto:aldrin.ietf@gmail.com]=20 Sent: Saturday, August 04, 2012 12:00 PM To: Vivek Kumar Cc: mpls@ietf.org Subject: Re: [mpls] LSP ping clarification Vivek, Before thinking of new 'magic' fields, why do you think existing RFC4379 d= o not work? As I eluded to in my email, existing model perfectly works without any addi= tional change. -sam On Aug 3, 2012, at 8:51 PM, "Vivek Kumar" wrote: > Hi Kireeti/Sam, >=20 > What about making some TTL/EXP field of ELI as magic value( say TTL=3D2= 55 or EXP=3D7) to indicate that if ELI has TTL=3D255 or EXP=3D7 , the use E= L value directly to index one of ECMP member ( without doing hashing). > For example , if ELI.TTL=3D255 , and EL=3D1 , then select first member = of ECMP group and if EL=3D2 , then next member and so on.. >=20 > Not sure if it is possible to have this kind of magic value for TTL or = EXP but anyway for ELI which is going to be reserved value it should not be= an issue. > Let me know your feedback. >=20 > Regards, > Vivek=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From aldrin.ietf@gmail.com Fri Aug 3 23:48: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 8A0FC21E8037 for ; Fri, 3 Aug 2012 23:48:15 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oji0Kyb5lYuh for ; Fri, 3 Aug 2012 23:48:15 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 11E8421F87C3 for ; Fri, 3 Aug 2012 23:48:15 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so721903pbb.31 for ; Fri, 03 Aug 2012 23:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=vW2gQfGjm7S9mu6rOpysjXdaxEPXzoYI5hOnxFwvYDM=; b=o9v+hzMoY9dvzjTHTP8YlM06BDVhOWVEeA6Ss0iskS4KLl76i3PvX3RhMhIx+siaKk SbLmWr7VB4erolb0wc1ku03EVMRqTIjau2RWJlA4wmd8zzdYhM0/NH3Wyh0k4HdQ527g FGJrJPM23rQp6DhzW4KMQKzqil+LnMdD9k2ma51Pb8QW2ZHEkpYEfTFiUUoIq2PvbOjr h4S4lSJNrkEtbobTHjYP1CwE80Csl7DZIzkD3u49uS0niU44Ho2CY7H2AJbZsOc4/xZ0 mMtlw8qqJrNCq77GMlC3aqROrUjGT6xZTDZQ74fxzDFd0t2kRnft4COlzT8Cnwrtc+5v JyAw== Received: by 10.68.224.39 with SMTP id qz7mr3007290pbc.127.1344062894775; Fri, 03 Aug 2012 23:48:14 -0700 (PDT) Received: from dhcp-414c.meeting.ietf.org (dhcp-414c.meeting.ietf.org. [130.129.65.76]) by mx.google.com with ESMTPS id se9sm4458628pbc.25.2012.08.03.23.48.12 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Aug 2012 23:48:13 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Sam Aldrin In-Reply-To: <3C086BA39C55B9418AE8FEA3F3EFDEC4075E2D@SJEXCHMB09.corp.ad.broadcom.com> Date: Fri, 3 Aug 2012 23:48:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3844A186-2D4C-40F2-A14F-216C01254AB4@gmail.com> References: <3C086BA39C55B9418AE8FEA3F3EFDEC4075D22@SJEXCHMB09.corp.ad.broadcom.com> <176B443F-4AA1-4F90-9936-3B1AF7A89919@gmail.com> <3C086BA39C55B9418AE8FEA3F3EFDEC4075E2D@SJEXCHMB09.corp.ad.broadcom.com> To: "Vivek Kumar" X-Mailer: Apple Mail (2.1485) Cc: "mpls@ietf.org" Subject: Re: [mpls] LSP ping clarification 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, 04 Aug 2012 06:48:15 -0000 Vivek, I personally do not see any value other than imposing new meaning to = fields, when it is not needed in the first place. Unless you make a real = case where RFC cannot solve, but the new magic field can, it is not = worth the effort. -sam On Aug 3, 2012, at 11:43 PM, "Vivek Kumar" wrote: > Hi Sam, > Agreed. As you mentioned , RFC 4379 is well equipped to handle = exploring all ECMP path. The only adv of having "new magic" field is = that to traverse all ECMP path , it does not have to be dependent on how = efficient load balancing algo underlying hardware support . >=20 > Do you see any value in it ? >=20 > Regards, > vivek >=20 > -----Original Message----- > From: Sam Aldrin [mailto:aldrin.ietf@gmail.com]=20 > Sent: Saturday, August 04, 2012 12:00 PM > To: Vivek Kumar > Cc: mpls@ietf.org > Subject: Re: [mpls] LSP ping clarification >=20 > Vivek, >=20 > Before thinking of new 'magic' fields, why do you think existing = RFC4379 do not work? > As I eluded to in my email, existing model perfectly works without any = additional change. >=20 > -sam > On Aug 3, 2012, at 8:51 PM, "Vivek Kumar" wrote: >=20 >> Hi Kireeti/Sam, >>=20 >> What about making some TTL/EXP field of ELI as magic value( say = TTL=3D255 or EXP=3D7) to indicate that if ELI has TTL=3D255 or EXP=3D7 , = the use EL value directly to index one of ECMP member ( without doing = hashing). >> For example , if ELI.TTL=3D255 , and EL=3D1 , then select first = member of ECMP group and if EL=3D2 , then next member and so on.. >>=20 >> Not sure if it is possible to have this kind of magic value for TTL = or EXP but anyway for ELI which is going to be reserved value it should = not be an issue. >> Let me know your feedback. >>=20 >> Regards, >> Vivek=20 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 >=20 From kvivek@broadcom.com Fri Aug 3 23:55: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 5317A21E803A for ; Fri, 3 Aug 2012 23:55:53 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ko4yGeA2pHP for ; Fri, 3 Aug 2012 23:55:52 -0700 (PDT) Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7109821E8037 for ; Fri, 3 Aug 2012 23:55:52 -0700 (PDT) Received: from [10.16.192.224] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Fri, 03 Aug 2012 23:54:10 -0700 X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.10) by SJEXCHHUB01.corp.ad.broadcom.com (10.16.192.224) with Microsoft SMTP Server (TLS) id 8.2.247.2; Fri, 3 Aug 2012 23:55:47 -0700 Received: from SJEXCHMB09.corp.ad.broadcom.com ( [fe80::3da7:665e:cc78:181f]) by SJEXCHCAS04.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Fri, 3 Aug 2012 23:55:47 -0700 From: "Vivek Kumar" To: "Sam Aldrin" Thread-Topic: [mpls] LSP ping clarification Thread-Index: AQHNcfR/5m6AIS2yfkias41k6GWR/5dJpp2A//+L4vCAAHkqgP//i95Q Date: Sat, 4 Aug 2012 06:55:46 +0000 Message-ID: <3C086BA39C55B9418AE8FEA3F3EFDEC4075E4D@SJEXCHMB09.corp.ad.broadcom.com> References: <3C086BA39C55B9418AE8FEA3F3EFDEC4075D22@SJEXCHMB09.corp.ad.broadcom.com> <176B443F-4AA1-4F90-9936-3B1AF7A89919@gmail.com> <3C086BA39C55B9418AE8FEA3F3EFDEC4075E2D@SJEXCHMB09.corp.ad.broadcom.com> <3844A186-2D4C-40F2-A14F-216C01254AB4@gmail.com> In-Reply-To: <3844A186-2D4C-40F2-A14F-216C01254AB4@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.240.253.129] MIME-Version: 1.0 X-WSS-ID: 7C02189849815919230-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" Subject: Re: [mpls] LSP ping clarification 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, 04 Aug 2012 06:55:53 -0000 Hi Sam, Not aware of any real use case as of now. But RFC 4379 , section 4.1 sa= ys=20 " If several transit LSRs have ECMP, the ingress may attempt to compose these to exercise all possible paths. However, full coverage may not be possible. " =20 regards, Vivek -----Original Message----- From: Sam Aldrin [mailto:aldrin.ietf@gmail.com]=20 Sent: Saturday, August 04, 2012 12:18 PM To: Vivek Kumar Cc: mpls@ietf.org Subject: Re: [mpls] LSP ping clarification Vivek, I personally do not see any value other than imposing new meaning to fields= , when it is not needed in the first place. Unless you make a real case whe= re RFC cannot solve, but the new magic field can, it is not worth the effor= t. -sam On Aug 3, 2012, at 11:43 PM, "Vivek Kumar" wrote: > Hi Sam, > Agreed. As you mentioned , RFC 4379 is well equipped to handle explori= ng all ECMP path. The only adv of having "new magic" field is that to trave= rse all ECMP path , it does not have to be dependent on how efficient load = balancing algo underlying hardware support . >=20 > Do you see any value in it ? >=20 > Regards, > vivek >=20 > -----Original Message----- > From: Sam Aldrin [mailto:aldrin.ietf@gmail.com]=20 > Sent: Saturday, August 04, 2012 12:00 PM > To: Vivek Kumar > Cc: mpls@ietf.org > Subject: Re: [mpls] LSP ping clarification >=20 > Vivek, >=20 > Before thinking of new 'magic' fields, why do you think existing RFC4379= do not work? > As I eluded to in my email, existing model perfectly works without any ad= ditional change. >=20 > -sam > On Aug 3, 2012, at 8:51 PM, "Vivek Kumar" wrote: >=20 >> Hi Kireeti/Sam, >>=20 >> What about making some TTL/EXP field of ELI as magic value( say TTL=3D2= 55 or EXP=3D7) to indicate that if ELI has TTL=3D255 or EXP=3D7 , the use E= L value directly to index one of ECMP member ( without doing hashing). >> For example , if ELI.TTL=3D255 , and EL=3D1 , then select first member = of ECMP group and if EL=3D2 , then next member and so on.. >>=20 >> Not sure if it is possible to have this kind of magic value for TTL or = EXP but anyway for ELI which is going to be reserved value it should not be= an issue. >> Let me know your feedback. >>=20 >> Regards, >> Vivek=20 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 >=20 From loa@pi.nu Sat Aug 4 00:59:19 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 26CAD21F8771 for ; Sat, 4 Aug 2012 00:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zm+wgGPPEOB for ; Sat, 4 Aug 2012 00:59:18 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 7A34721F8770 for ; Sat, 4 Aug 2012 00:59:18 -0700 (PDT) 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) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id C25102A8003; Sat, 4 Aug 2012 09:59:13 +0200 (CEST) Message-ID: <501CD651.4090500@pi.nu> Date: Sat, 04 Aug 2012 09:59:13 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "mpls@ietf.org" , MPLS-TP ad hoc team , draft-ezy-mpls-tp-1ton-protection@tools.ietf.org, Martin Vigoureux , "mpls-chairs@tools.ietf.org" References: <5006FECC.9080700@pi.nu> In-Reply-To: <5006FECC.9080700@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] Poll for WG adoption for draft-ezy-mpls-tp-1ton-protection 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, 04 Aug 2012 07:59:19 -0000 Working Group, this poll has ended, and we have a new working group document! Could the authors please republish the document as draft-ietf-mpls-tp-1ton-protection-00.txt, without any other changes than dates, version number and file name. /Loa (mpls wg co-chair) On 2012-07-18 20:22, Loa Andersson wrote: > Working group, > > this is to start a two week poll on adopting > draft-ezy-mpls-tp-1ton-protection-00 > as an MPLS working group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). > > The poll ends August 3r, 2012. > > /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 adrian@olddog.co.uk Sat Aug 4 19:45: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 ADB4B21F86E2 for ; Sat, 4 Aug 2012 19:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5nZWN9nDlM5 for ; Sat, 4 Aug 2012 19:45:25 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 804D621F86DC for ; Sat, 4 Aug 2012 19:45:25 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q752jNTt013511 for ; Sun, 5 Aug 2012 03:45:24 +0100 Received: from 950129200 (m7e0f36d0.tmodns.net [208.54.15.126]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q752jKGd013473 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 5 Aug 2012 03:45:22 +0100 From: "Adrian Farrel" To: References: <20120803175117.7215.37834.idtracker@ietfa.amsl.com> In-Reply-To: <20120803175117.7215.37834.idtracker@ietfa.amsl.com> Date: Sun, 5 Aug 2012 03:45:18 +0100 Message-ID: <008101cd72b4$5c2f0ec0$148d2c40$@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: AQGENN1pUP4h3zqo7SoIUCA22jDsD5fc/PDQ Content-Language: en-gb Subject: [mpls] FW: I-D Action: draft-manral-mpls-rfc3811bis-01.txt 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: Sun, 05 Aug 2012 02:45:26 -0000 Hi, This revision seems to be in a mess wrt versioning and dates. It is not clear to me why the MIB module needs to be revised rather than creating a new MIB module to contain MplsNewExtendedTunnelID. *If* there is a need to open this module, why aren't you deprecating CR-LDP? It is impossible to tell from this document exactly what has changed and why. Although you list the original authors as Contributors and perpetuate the Acknowledgements from 3811, I wonder whether you have discussed this with those authors and considered acknowledging their work (to which you are making a very minor tweak). Adrian > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of internet-drafts@ietf.org > Sent: 03 August 2012 18:51 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-manral-mpls-rfc3811bis-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Definitions of Textual Conventions (TCs) for Multiprotocol > Label Switching (MPLS) Management > Author(s) : Vishwas Manral > T. Tsou > Filename : draft-manral-mpls-rfc3811bis-01.txt > Pages : 23 > Date : 2012-08-03 > > Abstract: > This memo defines a Management Information Base (MIB) module which > contains Textual Conventions to represent commonly used Multiprotocol > Label Switching (MPLS) management information. The intent is that > these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS > related MIB modules that would otherwise define their own > representations. This document obsoletes RFC3811 as it addresses the > need to support IPv6 extended TunnelID's by defining a new TC- > MplsNewExtendedTunnelID which suggests using IPv4 address of the > ingress or egress LSR for the tunnel for an IPv6 network. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-manral-mpls-rfc3811bis > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-manral-mpls-rfc3811bis-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-manral-mpls-rfc3811bis-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From wyaacov@gmail.com Mon Aug 6 05:28: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 57EC121F8617 for ; Mon, 6 Aug 2012 05:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pB1E-t5okBYd for ; Mon, 6 Aug 2012 05:28:03 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC2221F8647 for ; Mon, 6 Aug 2012 05:28:03 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2999263vbb.31 for ; Mon, 06 Aug 2012 05:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gNfxnY72q6Caz1B2o7GoFS638bx6zkpu34ffOQTb48E=; b=UsBDy8t0QdNa8Oy4abP7gDS9X8s10Tvt7M2hN0xzAvinLaf6yPracWgmdmn36EmXyd yqNiel1pEK+SMmxrzc6PjYofHb14lve3dIEwsI1gJQa1JNxsGld1P4xytL7CARrRgbGL Cgj0uSaYv+B1mrzGIe3XuX3/MOnKM4Wn/PKDKcZgi7vx6xz+rbaQ67ROcHG5fgBhHuYq H4+ouNKNzUQJLq/FaJoh8fLsKYSHoaRdl/w/bQEZtXE2kb6v1iMDNBOYpOUGwLY+Wrh1 N2DBqVoS0w0w8jgcgMwFbdX5Cg30Arx5Zjswq26Ws9PUGxKUmt3a2zLHBjeAehTDvVK8 FuNA== MIME-Version: 1.0 Received: by 10.58.133.73 with SMTP id pa9mr8820254veb.51.1344256082265; Mon, 06 Aug 2012 05:28:02 -0700 (PDT) Received: by 10.59.1.198 with HTTP; Mon, 6 Aug 2012 05:28:02 -0700 (PDT) In-Reply-To: <501CD651.4090500@pi.nu> References: <5006FECC.9080700@pi.nu> <501CD651.4090500@pi.nu> Date: Mon, 6 Aug 2012 15:28:02 +0300 Message-ID: From: Yaacov Weingarten To: Loa Andersson Content-Type: multipart/alternative; boundary=047d7b67423845459004c698026f Cc: "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" , draft-ezy-mpls-tp-1ton-protection@tools.ietf.org, MPLS-TP ad hoc team Subject: Re: [mpls] Poll for WG adoption for draft-ezy-mpls-tp-1ton-protection 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, 06 Aug 2012 12:28:04 -0000 --047d7b67423845459004c698026f Content-Type: text/plain; charset=ISO-8859-1 Action item completed! BR, yaacov On Sat, Aug 4, 2012 at 10:59 AM, Loa Andersson wrote: > Working Group, > > this poll has ended, and we have a new working group document! > > Could the authors please republish the document as > draft-ietf-mpls-tp-1ton-**protection-00.txt, without any other changes > than dates, version number and file name. > > /Loa > (mpls wg co-chair) > > > > On 2012-07-18 20:22, Loa Andersson wrote: > >> Working group, >> >> this is to start a two week poll on adopting >> draft-ezy-mpls-tp-1ton-**protection-00 >> as an MPLS working group document. >> >> Please send your comments (support/not support) to the mpls working >> group mailing list (mpls@ietf.org). >> >> The poll ends August 3r, 2012. >> >> /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 > --047d7b67423845459004c698026f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Action item completed!

BR,
ya= acov

On Sat, Aug 4, 2012 at 10:59 AM, Loa= Andersson <loa@pi.nu> wrote:
Working Group,

this poll has ended, and we have a new working group document!

Could the authors please republish the document as
draft-ietf-mpls-tp-1ton-protection-00.txt, without any other changes=
than dates, version number and file name.

/Loa
(mpls wg co-chair)



On 2012-07-18 20:22, Loa Andersson wrote:
Working group,

this is to start a two week poll on adopting
draft-ezy-mpls-tp-1ton-protection-00
as an MPLS working group document.

Please send your comments (support/not support) to the mpls working
group mailing list (mpls= @ietf.org).

The poll ends August 3r, 2012.

/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

--047d7b67423845459004c698026f-- From internet-drafts@ietf.org Mon Aug 6 05:31: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 ADCB321F8694; Mon, 6 Aug 2012 05:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXleqiUdaNrF; Mon, 6 Aug 2012 05:31:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A0F21F8688; Mon, 6 Aug 2012 05:31:10 -0700 (PDT) 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.33 Message-ID: <20120806123110.17171.86114.idtracker@ietfa.amsl.com> Date: Mon, 06 Aug 2012 05:31:10 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-1ton-protection-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, 06 Aug 2012 12:31: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-TP 1toN Protection Author(s) : Eric Osborne Fei Zhang Yaacov Weingarten Filename : draft-ietf-mpls-tp-1ton-protection-00.txt Pages : 36 Date : 2012-08-06 Abstract: As part of the Transport Profile for Multiprotocol Label Switching (MPLS-TP) there is a requirement to support 1:n linear protection for transport paths. This requirement is elaborated on in the MPLS-TP Survivability Framework document [SurvivFwk]. The basic protocol for linear protection was specified in the MPLS-TP Linear Protection document [LinProt] but is limited to 1+1 and 1:1 protection. This document extends the protocol defined there to address the additional functionality necessary to support scenarios of a single protection path preconfigured to provide protection of multiple transport paths between two joint endpoints. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-1ton-protection There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-1ton-protection-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From wyaacov@gmail.com Mon Aug 6 05:56: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 C52B421F8669 for ; Mon, 6 Aug 2012 05:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[AWL=0.945, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvpvHtzv9M0s for ; Mon, 6 Aug 2012 05:56:33 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7C00721F8647 for ; Mon, 6 Aug 2012 05:56:33 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so2997496vcb.31 for ; Mon, 06 Aug 2012 05:56:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=k0XEzHJs/q2HbsKuAJVYAjrRDW1Mk5fTf5K1RD3xbgU=; b=Us9ijhEaMWp+1WSyZXGWEfUxoyhRML5Mwnojh47ZwBkjmmVKwz+qaOQOzPP57YlvO+ /wLNelKP+EcX7ngnYWU6DFhyYj9YhkUy1Ah5WgCoOcy2EiKpR4P+cOGMEPiWN8r4kSWC O+mqfseH7G1lDSPvEzPRP6qB5wPmb9mYce3UUbBkKquDM7oJXR5MzDLSMFzDn3D4FPR5 hedQ0sN3srqWlYb4RLn5j4jRwHhO0Mzeck5sDisj3kfp1EvfwNUKM8kaxhWs4gjc62yM NMRJiFLvXxYdMdC7fboZqsEGlTuKL5uwrY4lM1eRfC4mN6TUHWioHRS1CtldYZG9NS+8 aUFg== MIME-Version: 1.0 Received: by 10.58.169.167 with SMTP id af7mr8853761vec.55.1344257792829; Mon, 06 Aug 2012 05:56:32 -0700 (PDT) Received: by 10.59.1.198 with HTTP; Mon, 6 Aug 2012 05:56:32 -0700 (PDT) In-Reply-To: References: Date: Mon, 6 Aug 2012 15:56:32 +0300 Message-ID: From: Yaacov Weingarten To: Pablo Frank Content-Type: multipart/alternative; boundary=047d7b86c4d63a698b04c6986886 Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-weingarten-mpls-smp-requirements-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, 06 Aug 2012 12:56:34 -0000 --047d7b86c4d63a698b04c6986886 Content-Type: text/plain; charset=ISO-8859-1 Hi, Thank you for your comments. Please see my comments inline below. BR, yaacov On Tue, Jul 17, 2012 at 11:51 PM, Pablo Frank wrote: > Good draft and certainly something that needs to be done before we can > start discussing specific solutions. > > Only a few comments / questions: > > - In 4.1.1, if one is operating in an MPLS-TP network that requires > exclusive use of the protection resources, doesn't this SHOULD requirement > become a MUST requirement? > yw>> Sorry - but could you explain more fully this comment. > - Nit: you might want to avoid using the "query" verb in the title of > 4.1.1 because it subtly suggests some kind of protocol messaging is > required. I would use the more generic verb "checking" or "verifying". > yw>> Sounds OK to me. > - In 4.3, there is no suggestion for what should happen if one or more > failing paths in an MPLS-TP network are of equal priority. I presume it > will be some kind of first-come, first-serve requirement but this will > bring up the question of how to break ties. > yw>> This could be resolved along the lines that it was addressed in the 1:n protection > - Also in 4.3, there is an allowance for a high priority path and a lower > priority path to temporarily share the protection resources while > preemption is taking place. Two questions: > > - Is the ingress node to the shared segment expected to discard excess > traffic now that the protection-path is temporarily oversubscribed? > > yw>> this would most probably follow standard MPLS behavior as described elsewhere > - If not, how do we ensure that other transport paths are unaffected? > > - The first paragraph of 4.4 appears to contradict 4.1.1. 4.4 seems to > suggest that one MUST switch the traffic onto the protection path first and > then get notified if there's not enough resources. That's probably okay in > the general case. But in an MPLS-TP network, I don't think it's a good > idea to blindly switch low priority traffic onto the protection path and > possibly disrupt a high priority path that is already using that resource. > yw>> This is dependent upon the actual mechanism that is developed by the WG. For example, one suggestion for the mechanism has notifications sent to lower priority working paths making the protection path unavailable if it is in use by a high-priority working path. > - In section 4.5, there's an attempt to define "protection switching time" > as not including preemption time. I don't think end-users really care > about "protection switching time". They care about recovery time and IMO, > that should also include fault detection time (although it doesn't per RFC > 5654) and any preemption time. > yw>> we do try to work within the accepted definitions of the IETF! > > regards, > Pablo > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --047d7b86c4d63a698b04c6986886 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Thank you for your comments. =A0Ple= ase see my comments inline below.

BR,
ya= acov

On Tue, Jul 17, 2012 at 11:51 PM, Pa= blo Frank <pabloisnot@gmail.com> wrote:
Good draft and certainly something that need= s to be done before we can start discussing specific solutions.

Only a few comments / questions:

- In 4.1.1, = if one is operating in an MPLS-TP network that requires exclusive use of th= e protection resources, doesn't this SHOULD requirement become a MUST r= equirement?

yw>> Sorry - but could you explain m= ore fully this comment.
=A0
- Nit: you might want to avoid using the "query" verb in the= title of 4.1.1 because it subtly suggests some kind of protocol messaging = is required. =A0I would use the more generic verb "checking" or &= quot;verifying".
yw>> Sounds OK to me.=A0
- In 4.3, there is no suggestion for what should happen if one or more= failing paths in an MPLS-TP network are of equal priority. =A0I presume it= will be some kind of first-come, first-serve requirement but this will bri= ng up the question of how to break ties.
yw>> This could be resolved along the lines that it= was addressed in the 1:n protection
=A0
- Also in 4.3, there is an allowance for a high priority path and a lo= wer priority path to temporarily share the protection resources while preem= ption is taking place. =A0Two questions:
- Is the ingress node to the shared segment expected to discard excess= traffic now that the protection-path is temporarily oversubscribed?
<= /blockquote>
yw>> this would most probably follow st= andard MPLS behavior as described elsewhere=A0
- If not, how do we ensure that other transport pa= ths are unaffected?
- The first paragraph of 4.4 appears to contradict 4.1.1.= =A04.4 seems to suggest that one MUST switch the traffic onto the protecti= on path first and then get notified if there's not enough resources. = =A0That's probably okay in the general case. =A0But in an MPLS-TP netwo= rk, I don't think it's a good idea to blindly switch low priority t= raffic onto the protection path and possibly disrupt a high priority path t= hat is already using that resource.
yw>> This is dependent upon the actual mechanism th= at is developed by the WG. =A0For example, one suggestion for the mechanism= has notifications sent to lower priority working paths making the protecti= on path unavailable if it is in use by a high-priority working path.
=A0
- In section 4.5, there's an attempt to define "protection sw= itching time" as not including preemption time. =A0I don't think e= nd-users really care about "protection switching time". =A0They c= are about recovery time and IMO, that should also include fault detection t= ime (although it doesn't per RFC 5654) and any preemption time.
yw>> we do try to work within the accepted definiti= ons of the IETF!=A0

regards,
Pablo


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


--047d7b86c4d63a698b04c6986886-- From vishwas.ietf@gmail.com Mon Aug 6 08:04: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 0653521F85A3 for ; Mon, 6 Aug 2012 08:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.575 X-Spam-Level: X-Spam-Status: No, score=-3.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4+yp8bEzAOx for ; Mon, 6 Aug 2012 08:04:50 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id D34A921F859A for ; Mon, 6 Aug 2012 08:04:49 -0700 (PDT) Received: by qadz3 with SMTP id z3so993393qad.10 for ; Mon, 06 Aug 2012 08:04:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nZAAJBEOCve6vNUAVOtvLyatBSBuD+SzBn7Brpd/bjo=; b=gEdGk/zxtebgoohGwoD0sBQgEhe9BSzdMMZTDk6g75JFXVGE4GF0wRrbLR3dAyCHh3 0FC2HCzdJluOLVyN/5IBo7P2G1Ec4VGtk92EfYTCo/RTBf6n1c2E4Tbd8DPpIGwjoUx/ nqCQmShvvnluhK7yOQFTzSHbwO/KgZkunJxSo0i72YX0xSVet8nhcvzZDpM2vGFLmrqW PtbpfMMRr0SeX2hnSMcx+3BhXAXZi/GHqWMfIT1AUmuU0i2SPcWrZXhuk+34xg8jElTU 0JY40Ucd6VTfB9jwJMDxE/DUn+k1sT6oM/BWo8phYXowO5CZvzNXsmZfDYQc0mSofHtM GewQ== MIME-Version: 1.0 Received: by 10.224.200.130 with SMTP id ew2mr18263512qab.92.1344265489209; Mon, 06 Aug 2012 08:04:49 -0700 (PDT) Received: by 10.229.211.209 with HTTP; Mon, 6 Aug 2012 08:04:49 -0700 (PDT) In-Reply-To: <008101cd72b4$5c2f0ec0$148d2c40$@olddog.co.uk> References: <20120803175117.7215.37834.idtracker@ietfa.amsl.com> <008101cd72b4$5c2f0ec0$148d2c40$@olddog.co.uk> Date: Mon, 6 Aug 2012 08:04:49 -0700 Message-ID: From: Vishwas Manral To: adrian@olddog.co.uk Content-Type: multipart/alternative; boundary=20cf300fac8bf7d90a04c69a322d Cc: mpls@ietf.org Subject: Re: [mpls] FW: I-D Action: draft-manral-mpls-rfc3811bis-01.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, 06 Aug 2012 15:04:51 -0000 --20cf300fac8bf7d90a04c69a322d Content-Type: text/plain; charset=ISO-8859-1 Hi Adrian, Thanks a lot for your comments. I agree the version number and dates in the MIB are messed up and will be corrected. We have section 4 to describe what has changed in the MIB and its effects, I guess that needs to clarified to clearly mention changes from the older MIB. However the bigger issue is the way we want to proceed with this? Here are the options I see: 1. There are a few ways to move forward like you mentioned, and I would love to hear what the WG has to say: a. Create a totally new MIB b. Add an object to the existing MIB c. Create a MIB with just the new Object 2. In my view deprecating CR-LDP does not solve the issue because, from RFC3209 (RSVP-TE). Deprecating CR-LDP could be a different exercise however: Extended Tunnel ID A 16-byte identifier used in the SESSION that remains constant over the life of the tunnel. Normally set to all zeros. Ingress nodes that wish to narrow the scope of a SESSION to the ingress-egress pair may place their IPv6 address here as a globally unique identifier. Thanks, Vishwas On Sat, Aug 4, 2012 at 7:45 PM, Adrian Farrel wrote: > Hi, > > > > This revision seems to be in a mess wrt versioning and dates. > > It is not clear to me why the MIB module needs to be revised rather than > creating a new MIB module to contain MplsNewExtendedTunnelID. > > *If* there is a need to open this module, why aren't you deprecating > CR-LDP? > > It is impossible to tell from this document exactly what has changed and > why. > > Although you list the original authors as Contributors and perpetuate the > Acknowledgements from 3811, I wonder whether you have discussed this with > those > authors and considered acknowledging their work (to which you are making a > very > minor tweak). > > Adrian > > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org [mailto: > i-d-announce-bounces@ietf.org] > > On Behalf Of internet-drafts@ietf.org > > Sent: 03 August 2012 18:51 > > To: i-d-announce@ietf.org > > Subject: I-D Action: draft-manral-mpls-rfc3811bis-01.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Definitions of Textual Conventions (TCs) for > Multiprotocol > > Label Switching (MPLS) Management > > Author(s) : Vishwas Manral > > T. Tsou > > Filename : draft-manral-mpls-rfc3811bis-01.txt > > Pages : 23 > > Date : 2012-08-03 > > > > Abstract: > > This memo defines a Management Information Base (MIB) module which > > contains Textual Conventions to represent commonly used Multiprotocol > > Label Switching (MPLS) management information. The intent is that > > these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS > > related MIB modules that would otherwise define their own > > representations. This document obsoletes RFC3811 as it addresses the > > need to support IPv6 extended TunnelID's by defining a new TC- > > MplsNewExtendedTunnelID which suggests using IPv4 address of the > > ingress or egress LSR for the tunnel for an IPv6 network. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-manral-mpls-rfc3811bis > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-manral-mpls-rfc3811bis-01 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-manral-mpls-rfc3811bis-01 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --20cf300fac8bf7d90a04c69a322d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Adrian,

Thanks a lot for your comments. I agree the version numbe= r and dates in the MIB are messed up and will be corrected.

We have = section 4 to describe what has changed in the MIB and its effects, I guess = that needs to clarified to clearly mention changes from the older MIB. Howe= ver the bigger issue is the way we want to proceed with this? Here are the = options I see:

1. There are a few ways to move forward like you mentioned, and I would= love to hear what the WG has to say:
a. Create a totally new MIB
b. = Add an object to the existing MIB
c. Create a MIB with just the new Obje= ct

2. In my view deprecating CR-LDP does not solve the issue because, from= RFC3209 (RSVP-TE). Deprecating CR-LDP could be a different exercise howeve= r:
      Extended Tunnel ID

         A 16-byte identifier used in the SESSION that remains constant
         over the life of the tunnel.  Normally set to all zeros.
         Ingress nodes that wish to narrow the scope of a SESSION to the
         ingress-egress pair may place their IPv6 address here as a
         globally unique identifier.

Thanks,
Vishwas

On Sat, Aug 4, 2012 at 7:45 PM, Adrian Farrel <a= drian@olddog.co.uk> wrote:
Hi,

<individual contributor mode>

This revision seems to be in a mess wrt versioning and dates.

It is not clear to me why the MIB module needs to be revised rather than creating a new MIB module to contain MplsNewExtendedTunnelID.

*If* there is a need to open this module, why aren't you deprecating CR= -LDP?

It is impossible to tell from this document exactly what has changed and wh= y.

Although you list the original authors as Contributors and perpetuate the Acknowledgements from 3811, I wonder whether you have discussed this with t= hose
authors and considered acknowledging their work (to which you are making a = very
minor tweak).

Adrian

> -----Original Message-----
> From: i-d-announce-bo= unces@ietf.org [mailto:i-d-announce-bounces@ietf.org]
> On Behalf Of internet-draf= ts@ietf.org
> Sent: 03 August 2012 18:51
> To: i-d-announce@ietf.org=
> Subject: I-D Action: draft-manral-mpls-rfc3811bis-01.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Definitions of Textual Convent= ions (TCs) for
Multiprotocol
> Label Switching (MPLS) Management
> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Vishwas Manral
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 T. Tsou
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-manral-mpls-rfc3811bis-01.= txt
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 23
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-08-03
>
> Abstract:
> =A0 =A0This memo defines a Management Information Base (MIB) module wh= ich
> =A0 =A0contains Textual Conventions to represent commonly used Multipr= otocol
> =A0 =A0Label Switching (MPLS) management information. =A0The intent is= that
> =A0 =A0these TEXTUAL CONVENTIONS (TCs) will be imported and used in MP= LS
> =A0 =A0related MIB modules that would otherwise define their own
> =A0 =A0representations. =A0This document obsoletes RFC3811 as it addre= sses the
> =A0 =A0need to support IPv6 extended TunnelID's by defining a new = TC-
> =A0 =A0MplsNewExtendedTunnelID which suggests using IPv4 address of th= e
> =A0 =A0ingress or egress LSR for the tunnel for an IPv6 network.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-manral-mpls-rf= c3811bis
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-manral-mpls-rfc3811bis-= 01
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-manral-= mpls-rfc3811bis-01
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

--20cf300fac8bf7d90a04c69a322d-- From kebo.liu@nsn.com Wed Aug 1 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 3960F11E811D for ; Wed, 1 Aug 2012 18:19:47 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gE1yD3YB2jxa for ; Wed, 1 Aug 2012 18:19:46 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 819F811E80FD for ; Wed, 1 Aug 2012 18:19:45 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q721JdMw031826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Aug 2012 03:19:39 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q721Jdkm000416; Thu, 2 Aug 2012 03:19:39 +0200 Received: from CNBEEXC006.nsn-intra.net ([10.159.192.11]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Aug 2012 03:19:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD704C.C8CE8C79" Date: Thu, 2 Aug 2012 09:18:55 +0800 Message-ID: <93CE5B70F336A74BB298150C6B9906DCFC76C2@CNBEEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] IPR poll draft-jin-mpls-mldp-leaf-discovery Thread-Index: Ac1wSi1aEGsBQoRoSwmXQ+5ICjyHkQAAUYlQ References: From: "Liu, Kebo (NSN - CN/Shanghai)" To: "ext Lizhong Jin" , , , , , X-OriginalArrivalTime: 02 Aug 2012 01:19:37.0299 (UTC) FILETIME=[E1DFFA30:01CD704C] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 10462 X-purgate-ID: 151667::1343870379-00002E58-E334CD3D/0-0/0-0 X-Mailman-Approved-At: Mon, 06 Aug 2012 09:26:26 -0700 Subject: Re: [mpls] IPR poll draft-jin-mpls-mldp-leaf-discovery 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, 02 Aug 2012 01:19:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD704C.C8CE8C79 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andersson, I am NOT aware of any IPR that applies to draft-jin-mpls-mldp-leaf-discovery as the author. BR. Liu Kebo. >=20 > ------------------------------ >=20 > Message: 4 > Date: Tue, 31 Jul 2012 14:29:55 +0200 > From: Loa Andersson > > To: "mpls@ietf.org " >, "mpls-chairs@tools.ietf.org " > >, Martin Vigoureux > >, > draft-ietf-mpls-tp-security-framework@tools.ietf.org =20 > Subject: [mpls] IPR poll draft-jin-mpls-mldp-leaf-discovery > Message-ID: <5017CFC3.9040702@pi.nu > > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed=20 >=20 > Working Group and authors; >=20 > The wg chair are nearly ready to issue a poll to accept > draft-jin-mpls-mldp-leaf-discovery as a working group document, > we will run this IPR poll in parallel to the poll on making this > document a working group document. >=20 > Are you aware of any IPR that applies to > draft-jin-mpls-mldp-leaf-discovery? >=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 documents 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 > Thanks, Loa > (as MPLS WG co-chair) >=20 > --=20 >=20 >=20 > Loa Andersson email: loa.andersson@ericsson.com =20 > Sr Strategy and Standards Manager loa@pi.nu =20 > Ericsson Inc phone: +46 10 717 52 13 =20 > +46 767 72 92 13 =20 >=20 >=20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --=20 - Sri ------_=_NextPart_001_01CD704C.C8CE8C79 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Andersson,

I am NOT aware of any = IPR that applies to draft-jin-mpls-mldp-leaf-discovery as the = author.

BR.

Liu = Kebo.
> =
> ------------------------------
>
> Message: = 4
> Date: Tue, 31 Jul 2012 14:29:55 +0200
> From: Loa = Andersson <loa@pi.nu>
> To: = "mpls@ietf.org" <mpls@ietf.org>,   =  "mpls-chairs@tools.ietf.org"
> =    <mpls-chairs@tools.ietf.org>,   = Martin Vigoureux
>    <martin.vigoureux@alcatel-lucen= t.com>,
>   =  draft-ietf-mpls-tp-security-fr= amework@tools.ietf.org
> Subject: [mpls] IPR = poll draft-jin-mpls-mldp-leaf-discovery
> Message-ID: = <5017CFC3.9040702@pi.nu<= /a>>
> = Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed =

>
> = Working Group and authors;
>
> The wg chair are nearly = ready to issue a poll to accept
> = draft-jin-mpls-mldp-leaf-discovery as a working group document,
> = we will run this IPR poll in parallel to the poll on making this
> = document a working group document.
>
> Are you aware of any = IPR that applies to
> draft-jin-mpls-mldp-leaf-discovery?
> =
> 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 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

<= br>

--
- Sri

------_=_NextPart_001_01CD704C.C8CE8C79-- From erosen@cisco.com Mon Aug 6 11:48: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 908AA11E80A6 for ; Mon, 6 Aug 2012 11:48:12 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZVSYLEHUIZj for ; Mon, 6 Aug 2012 11:48:11 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B493D11E808A for ; Mon, 6 Aug 2012 11:48:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=erosen@cisco.com; l=3369; q=dns/txt; s=iport; t=1344278891; x=1345488491; h=to:cc:subject:in-reply-to:reply-to:date:message-id:from; bh=yaR1U/val8cNUcfdN8POyAaaGSitexal1DmPGYh6WlU=; b=MAhYTIbr9CcW69wRUmj8H9MefpMhvsJ1JB+D4K+TKhSTYNs8Po5jtWxS oXqbV9hEBjO4ZmCNKk5sLFWrRhp0+brSvEgtTbJudH2PymO8coQRXQRd1 ++3z163PUHKhTjvEmQAt3nF4DMSX4HiS0SC9LQarOM4zR0mCIKFAymuL9 8=; X-IronPort-AV: E=Sophos;i="4.77,720,1336348800"; d="scan'208";a="108895738" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 06 Aug 2012 18:48:11 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q76ImAUE021959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Aug 2012 18:48:11 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id q76Im9Cd008846; Mon, 6 Aug 2012 14:48:10 -0400 To: Loa Andersson In-reply-to: Your message of Tue, 31 Jul 2012 14:11:16 +0200. <5017CB64.9070507@pi.nu> Date: Mon, 06 Aug 2012 14:48:09 -0400 Message-ID: <8845.1344278889@erosen-linux> From: Eric Rosen Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 18:48:12 -0000 > this is to start a two week poll on adopting > draft-jin-mpls-mldp-leaf-discovery-04 as an MPLS working group document. No, do not support. Applications that use BGP-based auto-discovery and/or signaling, e.g., MVPN, already seem to have adequate mechanisms for discovering leaf nodes. E.g., MVPN has the "Leaf Info Required" bit in PMSI Tunnel Attribute to indicate when the tunnel root wants to know who all the leafs are, and the Leaf A-D route is used by the leafs to reply to the root. A Leaf A-D route also carries an RT to constrain distribution of the route to the root node. The draft defines a new AFI/SAFI, whose NLRI consists of an mLDP FEC element and a leaf node address. There is certainly no need for this in MVPN, as it just duplicates existing functionality, in a less general way, and with no comparable method of constraining distribution. The MVPN BGP signaling allows a root node to determine which leaf nodes need to receive which customer data streams. In theory, this information could be used to assign two different data streams to the same tunnel, if, e.g., the same set of leaf nodes need to receive both streams. (Whether this is actually useful in practice is arguable.) However, the signaling proposed in this draft only allows the root node to determine the leaf nodes who have joined a particular mLDP LSP. It doesn't convey any information about why a particular leaf node has joined a particular LSP, so it's not really useful if one is trying to decide whether two data streams should be sent on the same tunnel. I just don't see the use case for the draft's BGP mechanism. I think the T-LDP mechanism is similarly problematic. If an application is not already using T-LDP for signaling, I don't think it makes much sense to require that each leaf node initiate a new T-LDP session to each root node. For security reasons, one usually doesn't accept T-LDP sessions from just anyone; the set of possible T-LDP peers is either configured, or is auto-discovered (via some BGP-based mechanism). If BGP auto-discovery is already being used, the T-LDP mechanism would not be needed, but if BGP auto-discovery is not being used, we wouldn't want to require that each potential root node be configured with the addresses of all the potential leaf nodes. We do have to remember that, in receiver-driven multicast, the fact that the root node doesn't know all the leaf nodes is considered to be a scalability advantage. Also, I'm not at all sure what the root node would do with the information that two P2MP LSPs have the same set of leaf nodes. This fact by itself does not mean that the two tunnels could be replaced by a single tunnel. Even if it did, LDP has no mechanism for replacing one tunnel with another. I don't think it's worthwhile setting up a whole bunch of new TCP connections (and T-Hello adjacencies) just to convey a small amount of not-very-useful information. In summary: - I don't really see what the use case is; - Existing BGP A-D mechanisms for MVPN are better at providing the information an application really needs, and are better at constraining the distribution of the information; - The T-LDP mechanism raises security issues and overhead issues, and it is not clear what to do with the information it conveys. From tnadeau@juniper.net Mon Aug 6 12:21: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 32ADF11E80FE for ; Mon, 6 Aug 2012 12:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.43 X-Spam-Level: X-Spam-Status: No, score=-6.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76zLiL3cJ7QF for ; Mon, 6 Aug 2012 12:21:49 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 6806C11E80FF for ; Mon, 6 Aug 2012 12:21:45 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUCAZRJegJTu7iofAj2/RNHCZMCtdE6kO@postini.com; Mon, 06 Aug 2012 12:21:49 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 6 Aug 2012 12:19:22 -0700 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Aug 2012 12:19:22 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 6 Aug 2012 15:19:16 -0400 From: Thomas Nadeau To: "erosen@cisco.com" Date: Mon, 6 Aug 2012 15:19:16 -0400 Thread-Topic: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-04 Thread-Index: Ac10CF6uUF6QJgtHS/6cW6ti+FarjA== Message-ID: <8438F69D-2524-4177-A257-9E0DA74A3E67@juniper.net> References: <8845.1344278889@erosen-linux> In-Reply-To: <8845.1344278889@erosen-linux> 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 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-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: Mon, 06 Aug 2012 19:21:50 -0000 +1 On Aug 6, 2012, at 2:48 PM, "Eric Rosen" wrote: >=20 >> this is to start a two week poll on adopting >> draft-jin-mpls-mldp-leaf-discovery-04 as an MPLS working group document. >=20 > No, do not support. >=20 > Applications that use BGP-based auto-discovery and/or signaling, e.g., MV= PN, > already seem to have adequate mechanisms for discovering leaf nodes. E.g= ., > MVPN has the "Leaf Info Required" bit in PMSI Tunnel Attribute to indicat= e > when the tunnel root wants to know who all the leafs are, and the Leaf A-= D > route is used by the leafs to reply to the root. A Leaf A-D route also > carries an RT to constrain distribution of the route to the root node. T= he > draft defines a new AFI/SAFI, whose NLRI consists of an mLDP FEC element = and > a leaf node address. There is certainly no need for this in MVPN, as it > just duplicates existing functionality, in a less general way, and with n= o > comparable method of constraining distribution. >=20 > The MVPN BGP signaling allows a root node to determine which leaf nodes n= eed > to receive which customer data streams. In theory, this information coul= d > be used to assign two different data streams to the same tunnel, if, e.g.= , > the same set of leaf nodes need to receive both streams. (Whether this i= s > actually useful in practice is arguable.) However, the signaling propose= d > in this draft only allows the root node to determine the leaf nodes who h= ave > joined a particular mLDP LSP. It doesn't convey any information about wh= y a > particular leaf node has joined a particular LSP, so it's not really usef= ul > if one is trying to decide whether two data streams should be sent on the > same tunnel. >=20 > I just don't see the use case for the draft's BGP mechanism. >=20 > I think the T-LDP mechanism is similarly problematic. If an application = is > not already using T-LDP for signaling, I don't think it makes much sense = to > require that each leaf node initiate a new T-LDP session to each root nod= e. > For security reasons, one usually doesn't accept T-LDP sessions from just > anyone; the set of possible T-LDP peers is either configured, or is > auto-discovered (via some BGP-based mechanism). If BGP auto-discovery is > already being used, the T-LDP mechanism would not be needed, but if BGP > auto-discovery is not being used, we wouldn't want to require that each > potential root node be configured with the addresses of all the potential > leaf nodes. >=20 > We do have to remember that, in receiver-driven multicast, the fact that = the > root node doesn't know all the leaf nodes is considered to be a scalabili= ty > advantage. >=20 > Also, I'm not at all sure what the root node would do with the informatio= n > that two P2MP LSPs have the same set of leaf nodes. This fact by itself > does not mean that the two tunnels could be replaced by a single tunnel. > Even if it did, LDP has no mechanism for replacing one tunnel with anothe= r. > I don't think it's worthwhile setting up a whole bunch of new TCP > connections (and T-Hello adjacencies) just to convey a small amount of > not-very-useful information. >=20 > In summary: >=20 > - I don't really see what the use case is; >=20 > - Existing BGP A-D mechanisms for MVPN are better at providing the > information an application really needs, and are better at constraining > the distribution of the information; >=20 > - The T-LDP mechanism raises security issues and overhead issues, and > it is not clear what to do with the information it conveys. >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From erosen@cisco.com Mon Aug 6 12:51: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 C94B521E809E for ; Mon, 6 Aug 2012 12:51:08 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQRjlJpgUalX for ; Mon, 6 Aug 2012 12:51:08 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0D25321E809D for ; Mon, 6 Aug 2012 12:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=erosen@cisco.com; l=1895; q=dns/txt; s=iport; t=1344282668; x=1345492268; h=to:cc:subject:in-reply-to:reply-to:date:message-id:from; bh=CVle12WIQyFBA7Ep1NDA+v8exERynkCTtpQNf24y73w=; b=d9WqIZCZVEl5JpDo4lNjFdbPlDf+ZHX0vlpss33MtCoIHPfUr+1xiv1q os5srnRLlhOt0GJHAP0DiQfU9IXNsRhJBBMDXEZx8YTzjfIZ1XwBYEbXt 5Z31CfAN8ZKWIE77jLmGd1I3fqI+FEG+96GnRH3s7zZTCkHSxnfgOt1pg Y=; X-IronPort-AV: E=Sophos;i="4.77,720,1336348800"; d="scan'208";a="54252089" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 06 Aug 2012 19:51:07 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q76Jp6ea018106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Aug 2012 19:51:06 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id q76Jp4Mt009399; Mon, 6 Aug 2012 15:51:05 -0400 To: Xuxiaohu In-reply-to: Your message of Mon, 30 Jul 2012 18:03:44 -0000. <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753B3A1@szxeml525-mbx.china.huawei.com> Date: Mon, 06 Aug 2012 15:51:04 -0400 Message-ID: <9398.1344282664@erosen-linux> From: Eric Rosen Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on MPLS-in-UDP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 19:51:09 -0000 > As for MPLS-in-GRE or MPLS-in-L2TPv3, it requires P routers to be capable > of performing hash calculations on the specific "load-balancing > field" contained in the encapsulating header (e.g., L2TPv3 session ID > field or GRE key field). Such requirement can not be met by some P routers > which could only perform hash calulations on the five tuple of TCP/UDP > packets. MPLS-in-UDP is only proposed to be used in such specific cases. I see the logic of this argument. On the other hand, we already have three standardized MPLS-in-IP encapsulations, each of which has been argued to have an important advantage over the other two. I don't think any of them has really caught on though. There's also been work on MPLS-in-IPsec, which similarly has failed to generate much interest in practice. After a dozen years, do we really think there's going to be a lot of interest in yet another MPLS-in-IP encapsulation? Note that each new encapsulation impacts the data plane of the PE routers, and the draft requires that each encapsulation header have a "source port" field whose value is a computed hash of the TCP/UDP header of the payload. This is not something that is completely trivial to implement. A few miscellaneous technical comments. Re the IANA Considerations: > Two distinct UDP destination port numbers indicating MPLS unicast > and MPLS multicast respectively need to be assigned by IANA. Since RFC 5332 we do not have codepoints for "MPLS unicast" and "MPLS multicast". Sections 4-8 of RFC 5332 allocate codepoints for a variety of encapsulating protocols, you should take a look at that. Do you expect to support MVPN over the UDP encapsulation? To get an idea of what the Security Area ADs are likely to require with regard to the Security Considerations, please look at the Security Considerations section of RFC 4023. From wim.henderickx@alcatel-lucent.com Mon Aug 6 12:56: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 6659821E8051 for ; Mon, 6 Aug 2012 12:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.668 X-Spam-Level: X-Spam-Status: No, score=-9.668 tagged_above=-999 required=5 tests=[AWL=0.581, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUQi8HPOBs-u for ; Mon, 6 Aug 2012 12:56:35 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6146B21E804A for ; Mon, 6 Aug 2012 12:56:35 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q76JuWQN024703 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 6 Aug 2012 21:56:32 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 6 Aug 2012 21:56:31 +0200 From: "Henderickx, Wim (Wim)" To: "erosen@cisco.com" , Loa Andersson Date: Mon, 6 Aug 2012 21:56:32 +0200 Thread-Topic: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-04 Thread-Index: Ac10BA0VA7vHb+QWRhOdOeewzEMGhgACUUPw Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6702E16ECD6A@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: Your message of Tue, 31 Jul 2012 14:11:16 +0200. <5017CB64.9070507@pi.nu> <8845.1344278889@erosen-linux> In-Reply-To: <8845.1344278889@erosen-linux> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-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: Mon, 06 Aug 2012 19:56:36 -0000 +1, I believe the additional complexities to link this mechanism to multipl= e applications is more complex than optimizing the P2MP/MP2MP LSP resources= which might be shared with multiple applications. -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Eri= c Rosen Sent: maandag 6 augustus 2012 20:48 To: Loa Andersson Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org Subject: Re: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-04 > this is to start a two week poll on adopting > draft-jin-mpls-mldp-leaf-discovery-04 as an MPLS working group document. No, do not support. Applications that use BGP-based auto-discovery and/or signaling, e.g., MVPN= , already seem to have adequate mechanisms for discovering leaf nodes. E.g., MVPN has the "Leaf Info Required" bit in PMSI Tunnel Attribute to indicate when the tunnel root wants to know who all the leafs are, and the Leaf A-D route is used by the leafs to reply to the root. A Leaf A-D route also carries an RT to constrain distribution of the route to the root node. The draft defines a new AFI/SAFI, whose NLRI consists of an mLDP FEC element an= d a leaf node address. There is certainly no need for this in MVPN, as it just duplicates existing functionality, in a less general way, and with no comparable method of constraining distribution. The MVPN BGP signaling allows a root node to determine which leaf nodes nee= d to receive which customer data streams. In theory, this information could be used to assign two different data streams to the same tunnel, if, e.g., the same set of leaf nodes need to receive both streams. (Whether this is actually useful in practice is arguable.) However, the signaling proposed in this draft only allows the root node to determine the leaf nodes who hav= e joined a particular mLDP LSP. It doesn't convey any information about why = a particular leaf node has joined a particular LSP, so it's not really useful if one is trying to decide whether two data streams should be sent on the same tunnel. I just don't see the use case for the draft's BGP mechanism. I think the T-LDP mechanism is similarly problematic. If an application is not already using T-LDP for signaling, I don't think it makes much sense to require that each leaf node initiate a new T-LDP session to each root node. For security reasons, one usually doesn't accept T-LDP sessions from just anyone; the set of possible T-LDP peers is either configured, or is auto-discovered (via some BGP-based mechanism). If BGP auto-discovery is already being used, the T-LDP mechanism would not be needed, but if BGP auto-discovery is not being used, we wouldn't want to require that each potential root node be configured with the addresses of all the potential leaf nodes. We do have to remember that, in receiver-driven multicast, the fact that th= e root node doesn't know all the leaf nodes is considered to be a scalability advantage. Also, I'm not at all sure what the root node would do with the information that two P2MP LSPs have the same set of leaf nodes. This fact by itself does not mean that the two tunnels could be replaced by a single tunnel. Even if it did, LDP has no mechanism for replacing one tunnel with another. I don't think it's worthwhile setting up a whole bunch of new TCP connections (and T-Hello adjacencies) just to convey a small amount of not-very-useful information. In summary: - I don't really see what the use case is; - Existing BGP A-D mechanisms for MVPN are better at providing the information an application really needs, and are better at constraining the distribution of the information; - The T-LDP mechanism raises security issues and overhead issues, and it is not clear what to do with the information it conveys. =20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From pranjal.dutta@alcatel-lucent.com Mon Aug 6 13:03: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 C8A3821E8056 for ; Mon, 6 Aug 2012 13:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.432 X-Spam-Level: X-Spam-Status: No, score=-9.432 tagged_above=-999 required=5 tests=[AWL=1.167, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31tnpXZgGow2 for ; Mon, 6 Aug 2012 13:03:10 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1711F11E80A4 for ; Mon, 6 Aug 2012 13:03:10 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q76K35SK007155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Aug 2012 15:03:07 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q76K33Bm015557 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 7 Aug 2012 01:33:04 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Tue, 7 Aug 2012 01:33:03 +0530 From: "Dutta, Pranjal K (Pranjal)" To: "erosen@cisco.com" , Loa Andersson Date: Tue, 7 Aug 2012 01:33:00 +0530 Thread-Topic: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-04 Thread-Index: Ac10BAx/wy1iuFmwRGeUkZk9cjF2rQACeYeg Message-ID: References: Your message of Tue, 31 Jul 2012 14:11:16 +0200. <5017CB64.9070507@pi.nu> <8845.1344278889@erosen-linux> In-Reply-To: <8845.1344278889@erosen-linux> 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-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-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: Mon, 06 Aug 2012 20:03:10 -0000 +1.=20 T-LDP is not the right choice for building an explicit relationship between= root and leaf nodes.=20 Scalability on mLdp comes from the fact that leaves and roots are decoupled= in control plane, with no explicit dependency.=20 Esp, since the draft describes VPLS-Mcast as problem context, there are sol= utions adopted in L2VPN/PWE3 to avoid full-mesh of T-LDP.=20 Thanks, Pranjal -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Eri= c Rosen Sent: Monday, August 06, 2012 11:48 AM To: Loa Andersson Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org Subject: Re: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-04 > this is to start a two week poll on adopting > draft-jin-mpls-mldp-leaf-discovery-04 as an MPLS working group document. No, do not support. Applications that use BGP-based auto-discovery and/or signaling, e.g., MVPN= , already seem to have adequate mechanisms for discovering leaf nodes. E.g., MVPN has the "Leaf Info Required" bit in PMSI Tunnel Attribute to indicate when the tunnel root wants to know who all the leafs are, and the Leaf A-D route is used by the leafs to reply to the root. A Leaf A-D route also carries an RT to constrain distribution of the route to the root node. The draft defines a new AFI/SAFI, whose NLRI consists of an mLDP FEC element an= d a leaf node address. There is certainly no need for this in MVPN, as it just duplicates existing functionality, in a less general way, and with no comparable method of constraining distribution. The MVPN BGP signaling allows a root node to determine which leaf nodes nee= d to receive which customer data streams. In theory, this information could be used to assign two different data streams to the same tunnel, if, e.g., the same set of leaf nodes need to receive both streams. (Whether this is actually useful in practice is arguable.) However, the signaling proposed in this draft only allows the root node to determine the leaf nodes who hav= e joined a particular mLDP LSP. It doesn't convey any information about why = a particular leaf node has joined a particular LSP, so it's not really useful if one is trying to decide whether two data streams should be sent on the same tunnel. I just don't see the use case for the draft's BGP mechanism. I think the T-LDP mechanism is similarly problematic. If an application is not already using T-LDP for signaling, I don't think it makes much sense to require that each leaf node initiate a new T-LDP session to each root node. For security reasons, one usually doesn't accept T-LDP sessions from just anyone; the set of possible T-LDP peers is either configured, or is auto-discovered (via some BGP-based mechanism). If BGP auto-discovery is already being used, the T-LDP mechanism would not be needed, but if BGP auto-discovery is not being used, we wouldn't want to require that each potential root node be configured with the addresses of all the potential leaf nodes. We do have to remember that, in receiver-driven multicast, the fact that th= e root node doesn't know all the leaf nodes is considered to be a scalability advantage. Also, I'm not at all sure what the root node would do with the information that two P2MP LSPs have the same set of leaf nodes. This fact by itself does not mean that the two tunnels could be replaced by a single tunnel. Even if it did, LDP has no mechanism for replacing one tunnel with another. I don't think it's worthwhile setting up a whole bunch of new TCP connections (and T-Hello adjacencies) just to convey a small amount of not-very-useful information. In summary: - I don't really see what the use case is; - Existing BGP A-D mechanisms for MVPN are better at providing the information an application really needs, and are better at constraining the distribution of the information; - The T-LDP mechanism raises security issues and overhead issues, and it is not clear what to do with the information it conveys. =20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From tnadeau@juniper.net Mon Aug 6 17:43: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 6C57D21F8673 for ; Mon, 6 Aug 2012 17:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.437 X-Spam-Level: X-Spam-Status: No, score=-6.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orC2EeekeR69 for ; Mon, 6 Aug 2012 17:43:35 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id D239F21F8681 for ; Mon, 6 Aug 2012 17:43:29 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUCBkpZ5dnQgQQm586abv/jxzVdQAH+LX@postini.com; Mon, 06 Aug 2012 17:43:35 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 6 Aug 2012 17:42:40 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 6 Aug 2012 20:42:39 -0400 From: Thomas Nadeau To: "erosen@cisco.com" , Xuxiaohu Date: Mon, 6 Aug 2012 20:42:36 -0400 Thread-Topic: [mpls] Comments on MPLS-in-UDP Thread-Index: Ac10NYtsFQof0vq/TsG2wWbiGAPYpw== Message-ID: In-Reply-To: <9398.1344282664@erosen-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on 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: Tue, 07 Aug 2012 00:43:36 -0000 On 8/6/12 3:51 PM, "Eric Rosen" wrote: > >> As for MPLS-in-GRE or MPLS-in-L2TPv3, it requires P routers to be >>capable >> of performing hash calculations on the specific "load-balancing >> field" contained in the encapsulating header (e.g., L2TPv3 session ID >> field or GRE key field). Such requirement can not be met by some P >>routers >> which could only perform hash calulations on the five tuple of TCP/UDP >> packets. MPLS-in-UDP is only proposed to be used in such specific cases. > >I see the logic of this argument. On the other hand, we already have three >standardized MPLS-in-IP encapsulations, each of which has been argued to >have an important advantage over the other two. I don't think any of them >has really caught on though. There's also been work on MPLS-in-IPsec, >which >similarly has failed to generate much interest in practice. After a dozen >years, do we really think there's going to be a lot of interest in yet >another MPLS-in-IP encapsulation? > >Note that each new encapsulation impacts the data plane of the PE routers, >and the draft requires that each encapsulation header have a "source port" >field whose value is a computed hash of the TCP/UDP header of the payload. >This is not something that is completely trivial to implement. TOM: This was basically the argument made against the draft last week at the meeting. I did not hear any convincing technical or otherwise convincing reasoning as to why we should get behind yet another encap scheme. Perhaps the draft's authors can ellaborate here on the list? --Tom > >A few miscellaneous technical comments. > >Re the IANA Considerations: > >> Two distinct UDP destination port numbers indicating MPLS unicast >> and MPLS multicast respectively need to be assigned by IANA. > >Since RFC 5332 we do not have codepoints for "MPLS unicast" and "MPLS >multicast". Sections 4-8 of RFC 5332 allocate codepoints for a variety of >encapsulating protocols, you should take a look at that. > >Do you expect to support MVPN over the UDP encapsulation? > >To get an idea of what the Security Area ADs are likely to require with >regard to the Security Considerations, please look at the Security >Considerations section of RFC 4023. > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From koike.yoshinori@lab.ntt.co.jp Mon Aug 6 21:17: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 145AB21F85D0 for ; Mon, 6 Aug 2012 21:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.51 X-Spam-Level: X-Spam-Status: No, score=0.51 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjo06sKS119J for ; Mon, 6 Aug 2012 21:17:00 -0700 (PDT) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA2D21F845C for ; Mon, 6 Aug 2012 21:16:59 -0700 (PDT) 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 q774GpP1022673; Tue, 7 Aug 2012 13:16:51 +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 699BCE00EF; Tue, 7 Aug 2012 13:16:51 +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 5E5B3E00EE; Tue, 7 Aug 2012 13:16:51 +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 q774GomO014098; Tue, 7 Aug 2012 13:16:50 +0900 Message-ID: <502096F5.6080105@lab.ntt.co.jp> Date: Tue, 07 Aug 2012 13:17:57 +0900 From: Yoshinori Koike User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Eric Osborne (eosborne)" References: <50054B8C.3030806@pi.nu> <50128960.3080409@lab.ntt.co.jp> <20ECF67871905846A80F77F8F4A275720F4F39F2@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A275720F4F39F2@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" Subject: Re: [mpls] Proposed response to Liaison on Linear Protection Switching 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, 07 Aug 2012 04:17:01 -0000 Hi Eric, My apology for being late to reply to you. Thank you very much for the clarification and detailed explanations. I'm sorry for my previous ambiguous question but I have one more question for clarification on A4). Is it correct that "one management document" is referring to an IETF document such as draft-ietf-mpls-tp-psc-mib-xx.txt which will be made in IETF in near future for RFC6378(PSC) based on RFC6639? Thank you for your confirmation in advance. Best regards, Yoshinori (2012/07/31 20:17), Eric Osborne (eosborne) wrote: > Hi Yoshinori- > > Thank you for your questions, I believe you've identified some confusing language in our original proposed response. I have included both your questions and our answers below. Please let us know whether these answer your questions or whether you require further clarification, and we will update the LS response as necessary. > > > > eric > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Yoshinori Koike >> Sent: Friday, July 27, 2012 8:28 AM >> To: mpls@ietf.org >> Subject: Re: [mpls] Proposed response to Liaison on Linear Protection >> Switching >> >> Hello Yacoov and Mr. Osborne, >> >> Thank you very much for preparing the draft liaison to ITU-T. >> >> I'm sorry for these late questions, but I have a few questions for >> clarification on the draft liaison. >> >> Q1) According to the item 1, it is written that the priority order "FS >> over SF-P" was defined also for consistency with the IETF Recovery >> terminology in RFC 4427. Could you be more specific about which part of >> the document can be referred, please? >> >> I have checked RFC4427 and I thought it might refer to the following >> part, but if "command" means internal command(not external command), it >> may imply that SF-P(internal command) could be prioritized. >> >> -------------- >> D. Forced switch-over for normal traffic: >> >> A switch-over action, initiated externally, that switches normal >> traffic to the recovery LSP/span, unless an equal or higher priority >> switch-over command is in effect. >> --------------- >> > > A1) Please refer to RFC4427, section 4.13 parts D/E. In particular: > > - part D defines "Forced switch-over for normal traffic", which is executed " unless an equal or higher priority switch-over command is in effect" > - part E defines " Manual switch-over for normal traffic", which is executed " unless a fault condition exists ... or an equal or higher priority switch-over command is in effect." > > Thus, RFC4427 differentiates between switch-over commands, i.e. lockout of protection, forced switch, manual switch, etc, and fault conditions, i.e. SF-W, SF-P, etc. Since an FS is executed unless there is a precluding switch-over command, and since MS is executed unless there is a precluding switch-over command or a fault condition, the FS must be executed even in the face of a fault condition. This requires that FS take precedence over SF-P. > >> Q2) Regarding item 1, there is a description that 'we note that in PSC >> the FS can be reverted provided one of the paths is active'. Could you >> explain more details about the meaning of this sentence, please? Does >> this mean that, for example, SF-P(with a working path is active) >> overrides FS depending on an implementation, which isn't compliant with >> the priority order of PSC? >> > > A2) We agree that the wording is perhaps unclear. It may make sense to simply remove that sentence, or we could rephrase it. > > The logic behind FS and SF-P priorities doesn't change. When an FS is removed, a node processes its remaining inputs and acts accordingly. > > First consider the case where FS is active but no other inputs are present. When FS is active, traffic is switched from W to P. When FS is removed, traffic reverts to W. > > Now consider the case where both FS and SF-P are active. There are two ways this can happen: the operator configures FS and then sees SF-P from the network, or the operator sees SF-P from the network and then configures FS. The outcome is the same in either case but the latter case seems far less likely, so let's examine the first case. When the operator configures FS, traffic is bridged into P. When P fails, the traffic is simply dropped, as it cannot be transmitted. This obeys the logic of prioritizing FS over SF-P. Should the operator wish to avoid this case, they should configure MS rather than FS. > > Given that explanation, do you have any suggestions about how to handle the text? Should we remove the sentence, or rewrite it? > >> Q3) Regarding the description in item 2, 'This feature may be used for >> future optimizations by different implementations.', could you be more >> specific about this sentence, please? I would like to know what kind of >> optimization will be achieved and how differently PSC will be implemented. >> > > A3) We believe that changing the text to state - "this behavior may be used by the operators to optimize their network operations, based on more complete status information..." would more clearly state the intention. > > We had no intention of implying that there would be different implementations of PSC, but rather that the more complete network status information provided by PSC, would allow the systems to react in a more efficient manner to protection switching situations.' > >> Q4) Regarding the description 'because it was felt that this be best >> specified in a management document' in item 6, does the "a management >> document" include both characteristics of equipment functional blocks >> and equipment management aspect? >> > > A4) The IETF tends to standardize management behaviors which are required for interoperability between devices. This differs from the ITU, which publishes "equipment recommendations" that provide equipment functional blocks and management commands and messages that are generated. If the ITU feels that these definitions are necessary for their equipment definitions then it is their prerogative to document them there. I believe that this is in keeping with the spirit of the work-split between the IETF and the ITU on MPLS-TP. > >> Just a very minor comment is, regarding Annex B of RFC6378, it is >> written on page 43 actually, although the table of contents point to >> page 44. >> > > Thank you for this. We will remove explicit page number references and simply refer to sections, including this reference to Appendix (not Annex) B. > -- Yoshinori Koike koike.yoshinori@lab.ntt.co.jp From xuxiaohu@huawei.com Tue Aug 7 02:42: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 85E4B21F859C for ; Tue, 7 Aug 2012 02:42:39 -0700 (PDT) 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.826, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJSg+BKzODyD for ; Tue, 7 Aug 2012 02:42:37 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 10A8F21F852C for ; Tue, 7 Aug 2012 02:42:37 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIP00385; Tue, 07 Aug 2012 01:42:30 -0800 (PST) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 7 Aug 2012 02:39:30 -0700 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 7 Aug 2012 02:39:33 -0700 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.5]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Tue, 7 Aug 2012 17:39:25 +0800 From: Xuxiaohu To: "erosen@cisco.com" Thread-Topic: Comments on MPLS-in-UDP Thread-Index: AQHNdAzUtdwdCzXyaEe3xLHRR7iIc5dOB+Tg Date: Tue, 7 Aug 2012 09:39:24 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753EB93@szxeml525-mbx.china.huawei.com> References: Your message of Mon, 30 Jul 2012 18:03:44 -0000. <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753B3A1@szxeml525-mbx.china.huawei.com> <9398.1344282664@erosen-linux> In-Reply-To: <9398.1344282664@erosen-linux> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.24] 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] Comments on 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: Tue, 07 Aug 2012 09:42:40 -0000 SGkgRXJpYywNCg0KVGhhbmtzIGEgbG90IGZvciB5b3VyIGluc2lnaHRmdWwgY29tbWVudHMgYW5k IHN1Z2dlc3Rpb25zLiBQbGVhc2Ugc2VlIG15IHJlc3BvbnNlIGlubGluZS4NCg0KPiAtLS0tLdPK vP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBFcmljIFJvc2VuIFttYWlsdG86ZXJvc2VuQGNpc2NvLmNv bV0NCj4gt6LLzcqxvOQ6IDIwMTLE6jjUwjfI1SAzOjUxDQo+IMrVvP7IyzogWHV4aWFvaHUNCj4g s63LzTogZXJvc2VuQGNpc2NvLmNvbTsgbXBsc0BpZXRmLm9yZw0KPiDW98ziOiBSZTogQ29tbWVu dHMgb24gTVBMUy1pbi1VRFANCj4gDQo+IA0KPiA+IEFzIGZvciBNUExTLWluLUdSRSBvciBNUExT LWluLUwyVFB2MywgaXQgcmVxdWlyZXMgUCByb3V0ZXJzIHRvIGJlIGNhcGFibGUNCj4gPiBvZiBw ZXJmb3JtaW5nIGhhc2ggY2FsY3VsYXRpb25zIG9uIHRoZSBzcGVjaWZpYyAibG9hZC1iYWxhbmNp bmcNCj4gPiBmaWVsZCIgY29udGFpbmVkIGluIHRoZSBlbmNhcHN1bGF0aW5nIGhlYWRlciAoZS5n LiwgTDJUUHYzIHNlc3Npb24gSUQNCj4gPiBmaWVsZCBvciBHUkUga2V5IGZpZWxkKS4gIFN1Y2gg cmVxdWlyZW1lbnQgY2FuIG5vdCBiZSBtZXQgYnkgc29tZSBQIHJvdXRlcnMNCj4gPiB3aGljaCBj b3VsZCBvbmx5IHBlcmZvcm0gaGFzaCBjYWx1bGF0aW9ucyBvbiB0aGUgZml2ZSB0dXBsZSBvZiBU Q1AvVURQDQo+ID4gcGFja2V0cy4gTVBMUy1pbi1VRFAgaXMgb25seSBwcm9wb3NlZCB0byBiZSB1 c2VkIGluIHN1Y2ggc3BlY2lmaWMgY2FzZXMuDQo+IA0KPiBJIHNlZSB0aGUgbG9naWMgb2YgdGhp cyBhcmd1bWVudC4gT24gdGhlIG90aGVyIGhhbmQsIHdlIGFscmVhZHkgaGF2ZSB0aHJlZQ0KPiBz dGFuZGFyZGl6ZWQgTVBMUy1pbi1JUCBlbmNhcHN1bGF0aW9ucywgZWFjaCBvZiB3aGljaCBoYXMg YmVlbiBhcmd1ZWQgdG8NCj4gaGF2ZSBhbiBpbXBvcnRhbnQgYWR2YW50YWdlIG92ZXIgdGhlIG90 aGVyIHR3by4gIEkgZG9uJ3QgdGhpbmsgYW55IG9mIHRoZW0NCj4gaGFzIHJlYWxseSBjYXVnaHQg b24gdGhvdWdoLiAgVGhlcmUncyBhbHNvIGJlZW4gd29yayBvbiBNUExTLWluLUlQc2VjLCB3aGlj aA0KPiBzaW1pbGFybHkgaGFzIGZhaWxlZCB0byBnZW5lcmF0ZSBtdWNoIGludGVyZXN0IGluIHBy YWN0aWNlLiAgQWZ0ZXIgYSBkb3plbg0KPiB5ZWFycywgZG8gd2UgcmVhbGx5IHRoaW5rIHRoZXJl J3MgZ29pbmcgdG8gYmUgYSBsb3Qgb2YgaW50ZXJlc3QgaW4geWV0DQo+IGFub3RoZXIgTVBMUy1p bi1JUCBlbmNhcHN1bGF0aW9uPw0KDQpBcyBmb3Igc2VydmljZSBwcm92aWRlciBiYWNrYm9uZXMs IG1vc3Qgb2YgdGhlbSBhcmUgY2FwYWJsZSBvZiBNUExTIGZvcndhcmRpbmcgYW5kIHRoZXJlZm9y ZSBpdCdzIHVuZGVyc3RhbmRhYmxlIHRoYXQgTVBMUy1pbi1JUCBlbmNhcHN1bGF0aW9ucyBhcmUg bm90IHBvcHVsYXIuIEhvd2V2ZXIsIGluIGNsb3VkIGRhdGEgY2VudGVyIG5ldHdvcmsgZW52aXJv bm1lbnRzLCBzb21lIGRhdGEgY2VudGVyIG9wZXJhdG9ycyBjaG9vc2UgdG8gdXNlIElQLCByYXRo ZXIgdGhhbiBNUExTIGluIHRoZSB1bmRlcmx5aW5nIG5ldHdvcmsgZHVlIHRvIGNlcnRhaW4gcmVh c29ucy4gSW4gYWRkaXRpb24sIE1QTFMtYmFzZWQgTDJWUE4gYW5kIEwzVlBOIHRlY2hub2xvZ2ll cyBhcmUgY29uc2lkZXJlZCB0byBiZSB1c2VkIGFzIHNjYWxhYmxlIGRhdGEgY2VudGVyIG5ldHdv cmsgc29sdXRpb25zIHRvIHN1cHBvcnQgbXVsdGktdGVuYW5jeS4gSW4gdGhpcyBjYXNlLCBNUExT LWluLUlQIGVuY2Fwc3VsYXRpb25zIHdvdWxkIGJlIHVzZWZ1bC4gVG8gcGVyZm9ybSBmaW5lLWdy YWluZWQgbG9hZC1iYWxhbmNpbmcgb3ZlciBMQUcgYW5kIEVDTVAgcGF0aHMgaW4gdGhlIHVuZGVy bHlpbmcgbmV0d29yaywgdGhlIE1QTFMtaW4tSVAgZW5jYXBzdWxhdGlvbiBoZWFkZXIgc2hvdWxk IGNvbnRhaW4gYW4gZW50cnkgZmllbGQgc28gdGhhdCB0aGUgdW5kZXJseWluZyBuZXR3b3JrIGNv dWxkIGFjaGlldmUgYSBmaW5lLWdyYWluZWQgbG9hZC1iYWxhbmNpbmcgb2YgdGhlIGVuY2Fwc3Vs YXRlZCB0cmFmZmljLiBXaXRoIHRoZSBNUExTLWluLVVEUCBlbmNhcHN1bGF0aW9uLCB0aGUgc291 cmNlIHBvcnQgZmllbGQgY291bGQgYmUgZGlyZWN0bHkgdXNlZCBhcyBhbiBlbnRyeSBmaWVsZCwg YW5kIG1vc3QgaW1wb3J0YW50bHksIG1vc3Qgcm91dGVycyBhbmQgbGF5ZXIzIHN3aXRjaGVzIGhh dmUgYWxyZWFkeSBiZWVuIGFibGUgdG8gcGVyZm9ybSBoYXNoIGNhbGN1bGF0aW9ucyBvbiB0aGUg Zml2ZSB0dXBsZSBvZiBVRFAgcGFja2V0cy4NCg0KPiBOb3RlIHRoYXQgZWFjaCBuZXcgZW5jYXBz dWxhdGlvbiBpbXBhY3RzIHRoZSBkYXRhIHBsYW5lIG9mIHRoZSBQRSByb3V0ZXJzLA0KPiBhbmQg dGhlIGRyYWZ0IHJlcXVpcmVzIHRoYXQgZWFjaCBlbmNhcHN1bGF0aW9uIGhlYWRlciBoYXZlIGEg InNvdXJjZSBwb3J0Ig0KPiBmaWVsZCB3aG9zZSB2YWx1ZSBpcyBhIGNvbXB1dGVkIGhhc2ggb2Yg dGhlIFRDUC9VRFAgaGVhZGVyIG9mIHRoZSBwYXlsb2FkLg0KPiBUaGlzIGlzIG5vdCBzb21ldGhp bmcgdGhhdCBpcyBjb21wbGV0ZWx5IHRyaXZpYWwgdG8gaW1wbGVtZW50Lg0KDQpBcyBmb3IgdGhl IGltcGxlbWVudGF0aW9uIGRpZmZpY3VsdHkgb2YgUEUgcm91dGVycywgaXQgc2VlbXMgdGhlcmUg aXMgbm8gYmlnIGRpZmZlcmVuY2UgYmV0d2VlbiBmaWxsaW5nIGEgaGFzaCB2YWx1ZSBpbiB0aGUg R1JFIGtleSBmaWVsZCAob3IgTDJUUHYzIHNlc3Npb24gSUQgZmllbGQpIGFuZCBmaWxsaW5nIGlu IGEgaGFzaCB2YWx1ZSBpbiB0aGUgVURQIHNvdXJjZSBwb3J0IGZpZWxkLCBJTUhPLg0KDQo+IEEg ZmV3IG1pc2NlbGxhbmVvdXMgdGVjaG5pY2FsIGNvbW1lbnRzLg0KPiANCj4gUmUgdGhlIElBTkEg Q29uc2lkZXJhdGlvbnM6DQo+IA0KPiA+ICAgVHdvIGRpc3RpbmN0IFVEUCBkZXN0aW5hdGlvbiBw b3J0IG51bWJlcnMgaW5kaWNhdGluZyBNUExTIHVuaWNhc3QNCj4gPiAgIGFuZCBNUExTIG11bHRp Y2FzdCByZXNwZWN0aXZlbHkgbmVlZCB0byBiZSBhc3NpZ25lZCBieSBJQU5BLg0KPiANCj4gU2lu Y2UgUkZDIDUzMzIgd2UgZG8gbm90IGhhdmUgY29kZXBvaW50cyBmb3IgIk1QTFMgdW5pY2FzdCIg YW5kICJNUExTDQo+IG11bHRpY2FzdCIuICBTZWN0aW9ucyA0LTggb2YgUkZDIDUzMzIgYWxsb2Nh dGUgY29kZXBvaW50cyBmb3IgYSB2YXJpZXR5IG9mDQo+IGVuY2Fwc3VsYXRpbmcgcHJvdG9jb2xz LCB5b3Ugc2hvdWxkIHRha2UgYSBsb29rIGF0IHRoYXQuDQoNClRoYW5rcyBhIGxvdCBmb3IgcmVt aW5kaW5nIG1lIG9mIFJGQzUzMzIuIFRoZSBjb3JyZXNwb25kaW5nIHRleHQgd291bGQgYmUgY2hh bmdlZCBhcyBmb2xsb3cgIiBUd28gZGlzdGluY3QgVURQIGRlc3RpbmF0aW9uIHBvcnQgbnVtYmVy cyBpbmRpY2F0aW5nIE1QTFMgYW5kIE1QTFMgd2l0aCB1cHN0cmVhbS1hc3NpZ25lZCBsYWJlbCBy ZXNwZWN0aXZlbHkgbmVlZCB0byBiZSBhc3NpZ25lZCBieSBJQU5BLi4uICIgIElzIHRoYXQgT0s/ DQoNCj4gRG8geW91IGV4cGVjdCB0byBzdXBwb3J0IE1WUE4gb3ZlciB0aGUgVURQIGVuY2Fwc3Vs YXRpb24/DQoNCklmIGRhdGEgY2VudGVyIG9wZXJhdG9ycyB3YW50IHRvIHVzZSBNVlBOIGluIHRo ZWlyIGRhdGEgY2VudGVycywgdGhleSBjb3VsZCB1c2UgTVBMUy1pbi1VRFAgZW5jYXBzdWxhdGlv biBmb3IgVlBOIHVuaWNhc3QgdHJhZmZpYyBhbmQgVlBOIG11bHRpY2FzdCB0cmFmZmljLg0KDQo+ IFRvIGdldCBhbiBpZGVhIG9mIHdoYXQgdGhlIFNlY3VyaXR5IEFyZWEgQURzIGFyZSBsaWtlbHkg dG8gcmVxdWlyZSB3aXRoDQo+IHJlZ2FyZCB0byB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMs IHBsZWFzZSBsb29rIGF0IHRoZSBTZWN1cml0eQ0KPiBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIG9m IFJGQyA0MDIzLg0KDQpJdKGvcyBhIHZlcnkgdXNlZnVsIHJlZmVyZW5jZS4gV2UgY28tYXV0aG9y cyB3b3VsZCBhZGQgbW9yZSBkZXRhaWxlZCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBpbiB0aGUg bmV4dCByZXZpc2lvbi4NCg0KVGhhbmtzIGFnYWluIGZvciB5b3VyIGluc2lnaHQgY29tbWVudHMg YW5kIHN1Z2dlc3Rpb25zLiANCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQo= From eosborne@cisco.com Tue Aug 7 03:45: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 9924721F86A4 for ; Tue, 7 Aug 2012 03:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAxlK1XcPLVb for ; Tue, 7 Aug 2012 03:45:03 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 35D0721F86A2 for ; Tue, 7 Aug 2012 03:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=8206; q=dns/txt; s=iport; t=1344336303; x=1345545903; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KGz0PoMmS8K03Y50HJrltpzdLPMZSl3WMDVCDorAjAM=; b=cs/Z45JosISdo3BvSxshTV3LxAACm3SsyFENQyheD33EZ+Jpubv4Uiw4 lLvDJM3nabqgczCoP9WuL+LWWwTlfJYxhskyLMrbk88yYoSXN5fau7Hrb mmSzGIr7CPNClmuk/1q/TGvmAfUq65DhaY4SS9saTTKGTjugYWA5r22Hb c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALbwIFCtJV2b/2dsb2JhbABFuUeBB4IgAQEBBBIBJz8MBAIBCBEEAQEBChQJBzIUCQgCBA4FCBqHa5s4oEOLD4YNYAOjboFmgl8 X-IronPort-AV: E=Sophos;i="4.77,726,1336348800"; d="scan'208";a="109111859" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 07 Aug 2012 10:45:02 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q77Aj2tQ015838 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Aug 2012 10:45:02 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0298.004; Tue, 7 Aug 2012 05:45:02 -0500 From: "Eric Osborne (eosborne)" To: Yoshinori Koike Thread-Topic: [mpls] Proposed response to Liaison on Linear Protection Switching Thread-Index: AQHNdFN+FHabxJadOEChZxnYcNc7UZdOJxbA Date: Tue, 7 Aug 2012 10:45:01 +0000 Message-ID: <20ECF67871905846A80F77F8F4A275720F538F80@xmb-rcd-x09.cisco.com> References: <50054B8C.3030806@pi.nu> <50128960.3080409@lab.ntt.co.jp> <20ECF67871905846A80F77F8F4A275720F4F39F2@xmb-rcd-x09.cisco.com> <502096F5.6080105@lab.ntt.co.jp> In-Reply-To: <502096F5.6080105@lab.ntt.co.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.23.87] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19090.005 x-tm-as-result: No--53.972300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Proposed response to Liaison on Linear Protection Switching 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, 07 Aug 2012 10:45:04 -0000 Hi Yoshinori- The MIB certainly is a management document. In my experience the MIB is = about all the IETF tends to standardize for management documents of protoco= ls. However, given the unique shared nature of the MPLS-TP work, if the IT= U feels it would like more equipment-specific recommendations it seems to b= e well within their purview to write them, and if others in the IETF feel a= dditional management documents are necessary, there is no restriction on su= bmitting a draft. I'm not sure if this answers your question - does it hel= p? Also, are you referring to a specific document or to a hypothetical futur= e document? I could not find draft-ietf-mpls-tp-psc-mib. Perhaps you mean= draft-smiler-mpls-tp-linear-protection-mib? eric > -----Original Message----- > From: Yoshinori Koike [mailto:koike.yoshinori@lab.ntt.co.jp] > Sent: Tuesday, August 07, 2012 12:18 AM > To: Eric Osborne (eosborne) > Cc: mpls@ietf.org; koike.yoshinori@lab.ntt.co.jp > Subject: Re: [mpls] Proposed response to Liaison on Linear Protection > Switching >=20 > Hi Eric, >=20 > My apology for being late to reply to you. Thank you very much for the > clarification and detailed explanations. >=20 > I'm sorry for my previous ambiguous question but I have one more > question for clarification on A4). Is it correct that "one management > document" is referring to an IETF document such as > draft-ietf-mpls-tp-psc-mib-xx.txt which will be made in IETF in near > future for RFC6378(PSC) based on RFC6639? >=20 > Thank you for your confirmation in advance. >=20 > Best regards, >=20 > Yoshinori >=20 > (2012/07/31 20:17), Eric Osborne (eosborne) wrote: > > Hi Yoshinori- > > > > Thank you for your questions, I believe you've identified some confus= ing > language in our original proposed response. I have included both your > questions and our answers below. Please let us know whether these answer > your questions or whether you require further clarification, and we will > update the LS response as necessary. > > > > > > > > eric > > > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > >> Yoshinori Koike > >> Sent: Friday, July 27, 2012 8:28 AM > >> To: mpls@ietf.org > >> Subject: Re: [mpls] Proposed response to Liaison on Linear Protection > >> Switching > >> > >> Hello Yacoov and Mr. Osborne, > >> > >> Thank you very much for preparing the draft liaison to ITU-T. > >> > >> I'm sorry for these late questions, but I have a few questions for > >> clarification on the draft liaison. > >> > >> Q1) According to the item 1, it is written that the priority order "FS > >> over SF-P" was defined also for consistency with the IETF Recovery > >> terminology in RFC 4427. Could you be more specific about which part o= f > >> the document can be referred, please? > >> > >> I have checked RFC4427 and I thought it might refer to the following > >> part, but if "command" means internal command(not external command), > it > >> may imply that SF-P(internal command) could be prioritized. > >> > >> -------------- > >> D. Forced switch-over for normal traffic: > >> > >> A switch-over action, initiated externally, that switches normal > >> traffic to the recovery LSP/span, unless an equal or higher priority > >> switch-over command is in effect. > >> --------------- > >> > > > > A1) Please refer to RFC4427, section 4.13 parts D/E. In particular: > > > > - part D defines "Forced switch-over for normal traffic", which is exec= uted " > unless an equal or higher priority switch-over command is in effect" > > - part E defines " Manual switch-over for normal traffic", which is exe= cuted > " unless a fault condition exists ... or an equal or higher priority swi= tch-over > command is in effect." > > > > Thus, RFC4427 differentiates between switch-over commands, i.e. lockout > of protection, forced switch, manual switch, etc, and fault conditions, = i.e. SF- > W, SF-P, etc. Since an FS is executed unless there is a precluding switc= h-over > command, and since MS is executed unless there is a precluding switch-ove= r > command or a fault condition, the FS must be executed even in the face of= a > fault condition. This requires that FS take precedence over SF-P. > > > >> Q2) Regarding item 1, there is a description that 'we note that in PSC > >> the FS can be reverted provided one of the paths is active'. Could you > >> explain more details about the meaning of this sentence, please? Does > >> this mean that, for example, SF-P(with a working path is active) > >> overrides FS depending on an implementation, which isn't compliant wit= h > >> the priority order of PSC? > >> > > > > A2) We agree that the wording is perhaps unclear. It may make sense to > simply remove that sentence, or we could rephrase it. > > > > The logic behind FS and SF-P priorities doesn't change. When an FS is > removed, a node processes its remaining inputs and acts accordingly. > > > > First consider the case where FS is active but no other inputs are pres= ent. > When FS is active, traffic is switched from W to P. When FS is removed, > traffic reverts to W. > > > > Now consider the case where both FS and SF-P are active. There are two > ways this can happen: the operator configures FS and then sees SF-P from > the network, or the operator sees SF-P from the network and then > configures FS. The outcome is the same in either case but the latter cas= e > seems far less likely, so let's examine the first case. When the operato= r > configures FS, traffic is bridged into P. When P fails, the traffic is s= imply > dropped, as it cannot be transmitted. This obeys the logic of prioritizi= ng FS > over SF-P. Should the operator wish to avoid this case, they should conf= igure > MS rather than FS. > > > > Given that explanation, do you have any suggestions about how to handle > the text? Should we remove the sentence, or rewrite it? > > > >> Q3) Regarding the description in item 2, 'This feature may be used for > >> future optimizations by different implementations.', could you be more > >> specific about this sentence, please? I would like to know what kind o= f > >> optimization will be achieved and how differently PSC will be > implemented. > >> > > > > A3) We believe that changing the text to state - "this behavior may be = used > by the operators to optimize their network operations, based on more > complete status information..." would more clearly state the intention. > > > > We had no intention of implying that there would be different > implementations of PSC, but rather that the more complete network status > information provided by PSC, would allow the systems to react in a more > efficient manner to protection switching situations.' > > > >> Q4) Regarding the description 'because it was felt that this be best > >> specified in a management document' in item 6, does the "a management > >> document" include both characteristics of equipment functional blocks > >> and equipment management aspect? > >> > > > > A4) The IETF tends to standardize management behaviors which are > required for interoperability between devices. This differs from the ITU= , > which publishes "equipment recommendations" that provide equipment > functional blocks and management commands and messages that are > generated. If the ITU feels that these definitions are necessary for the= ir > equipment definitions then it is their prerogative to document them there= . I > believe that this is in keeping with the spirit of the work-split between= the > IETF and the ITU on MPLS-TP. > > > >> Just a very minor comment is, regarding Annex B of RFC6378, it is > >> written on page 43 actually, although the table of contents point to > >> page 44. > >> > > > > Thank you for this. We will remove explicit page number references and > simply refer to sections, including this reference to Appendix (not Annex= ) B. > > >=20 >=20 > -- > Yoshinori Koike > koike.yoshinori@lab.ntt.co.jp From koike.yoshinori@lab.ntt.co.jp Tue Aug 7 05:42: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 2AFEC21F8668 for ; Tue, 7 Aug 2012 05:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.51 X-Spam-Level: X-Spam-Status: No, score=0.51 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJHPlSfNl9VU for ; Tue, 7 Aug 2012 05:42:27 -0700 (PDT) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1FD21F8653 for ; Tue, 7 Aug 2012 05:42:27 -0700 (PDT) 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 q77CgMvc004402; Tue, 7 Aug 2012 21:42:22 +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 0F96DE00F2; Tue, 7 Aug 2012 21:42:22 +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 03E98E00F1; Tue, 7 Aug 2012 21:42:22 +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 q77CgL9Y015166; Tue, 7 Aug 2012 21:42:21 +0900 Message-ID: <50210D70.9010806@lab.ntt.co.jp> Date: Tue, 07 Aug 2012 21:43:28 +0900 From: Yoshinori Koike User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Eric Osborne (eosborne)" References: <50054B8C.3030806@pi.nu> <50128960.3080409@lab.ntt.co.jp> <20ECF67871905846A80F77F8F4A275720F4F39F2@xmb-rcd-x09.cisco.com> <502096F5.6080105@lab.ntt.co.jp> <20ECF67871905846A80F77F8F4A275720F538F80@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A275720F538F80@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" Subject: Re: [mpls] Proposed response to Liaison on Linear Protection Switching 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, 07 Aug 2012 12:42:29 -0000 Hi Eric, Thank you very much for the information and your view. I assumed a hypothetical document, actually. I think I understood the meaning of answer to item 6. Thank you again for your clarification. Best regards, Yoshinori (2012/08/07 19:45), Eric Osborne (eosborne) wrote: > Hi Yoshinori- > > The MIB certainly is a management document. In my experience the MIB is about all the IETF tends to standardize for management documents of protocols. However, given the unique shared nature of the MPLS-TP work, if the ITU feels it would like more equipment-specific recommendations it seems to be well within their purview to write them, and if others in the IETF feel additional management documents are necessary, there is no restriction on submitting a draft. I'm not sure if this answers your question - does it help? > > Also, are you referring to a specific document or to a hypothetical future document? I could not find draft-ietf-mpls-tp-psc-mib. Perhaps you mean draft-smiler-mpls-tp-linear-protection-mib? > > > > > eric > > >> -----Original Message----- >> From: Yoshinori Koike [mailto:koike.yoshinori@lab.ntt.co.jp] >> Sent: Tuesday, August 07, 2012 12:18 AM >> To: Eric Osborne (eosborne) >> Cc: mpls@ietf.org; koike.yoshinori@lab.ntt.co.jp >> Subject: Re: [mpls] Proposed response to Liaison on Linear Protection >> Switching >> >> Hi Eric, >> >> My apology for being late to reply to you. Thank you very much for the >> clarification and detailed explanations. >> >> I'm sorry for my previous ambiguous question but I have one more >> question for clarification on A4). Is it correct that "one management >> document" is referring to an IETF document such as >> draft-ietf-mpls-tp-psc-mib-xx.txt which will be made in IETF in near >> future for RFC6378(PSC) based on RFC6639? >> >> Thank you for your confirmation in advance. >> >> Best regards, >> >> Yoshinori >> >> (2012/07/31 20:17), Eric Osborne (eosborne) wrote: >>> Hi Yoshinori- >>> >>> Thank you for your questions, I believe you've identified some confusing >> language in our original proposed response. I have included both your >> questions and our answers below. Please let us know whether these answer >> your questions or whether you require further clarification, and we will >> update the LS response as necessary. >>> >>> >>> >>> eric >>> >>>> -----Original Message----- >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >> Of >>>> Yoshinori Koike >>>> Sent: Friday, July 27, 2012 8:28 AM >>>> To: mpls@ietf.org >>>> Subject: Re: [mpls] Proposed response to Liaison on Linear Protection >>>> Switching >>>> >>>> Hello Yacoov and Mr. Osborne, >>>> >>>> Thank you very much for preparing the draft liaison to ITU-T. >>>> >>>> I'm sorry for these late questions, but I have a few questions for >>>> clarification on the draft liaison. >>>> >>>> Q1) According to the item 1, it is written that the priority order "FS >>>> over SF-P" was defined also for consistency with the IETF Recovery >>>> terminology in RFC 4427. Could you be more specific about which part of >>>> the document can be referred, please? >>>> >>>> I have checked RFC4427 and I thought it might refer to the following >>>> part, but if "command" means internal command(not external command), >> it >>>> may imply that SF-P(internal command) could be prioritized. >>>> >>>> -------------- >>>> D. Forced switch-over for normal traffic: >>>> >>>> A switch-over action, initiated externally, that switches normal >>>> traffic to the recovery LSP/span, unless an equal or higher priority >>>> switch-over command is in effect. >>>> --------------- >>>> >>> >>> A1) Please refer to RFC4427, section 4.13 parts D/E. In particular: >>> >>> - part D defines "Forced switch-over for normal traffic", which is executed " >> unless an equal or higher priority switch-over command is in effect" >>> - part E defines " Manual switch-over for normal traffic", which is executed >> " unless a fault condition exists ... or an equal or higher priority switch-over >> command is in effect." >>> >>> Thus, RFC4427 differentiates between switch-over commands, i.e. lockout >> of protection, forced switch, manual switch, etc, and fault conditions, i.e. SF- >> W, SF-P, etc. Since an FS is executed unless there is a precluding switch-over >> command, and since MS is executed unless there is a precluding switch-over >> command or a fault condition, the FS must be executed even in the face of a >> fault condition. This requires that FS take precedence over SF-P. >>> >>>> Q2) Regarding item 1, there is a description that 'we note that in PSC >>>> the FS can be reverted provided one of the paths is active'. Could you >>>> explain more details about the meaning of this sentence, please? Does >>>> this mean that, for example, SF-P(with a working path is active) >>>> overrides FS depending on an implementation, which isn't compliant with >>>> the priority order of PSC? >>>> >>> >>> A2) We agree that the wording is perhaps unclear. It may make sense to >> simply remove that sentence, or we could rephrase it. >>> >>> The logic behind FS and SF-P priorities doesn't change. When an FS is >> removed, a node processes its remaining inputs and acts accordingly. >>> >>> First consider the case where FS is active but no other inputs are present. >> When FS is active, traffic is switched from W to P. When FS is removed, >> traffic reverts to W. >>> >>> Now consider the case where both FS and SF-P are active. There are two >> ways this can happen: the operator configures FS and then sees SF-P from >> the network, or the operator sees SF-P from the network and then >> configures FS. The outcome is the same in either case but the latter case >> seems far less likely, so let's examine the first case. When the operator >> configures FS, traffic is bridged into P. When P fails, the traffic is simply >> dropped, as it cannot be transmitted. This obeys the logic of prioritizing FS >> over SF-P. Should the operator wish to avoid this case, they should configure >> MS rather than FS. >>> >>> Given that explanation, do you have any suggestions about how to handle >> the text? Should we remove the sentence, or rewrite it? >>> >>>> Q3) Regarding the description in item 2, 'This feature may be used for >>>> future optimizations by different implementations.', could you be more >>>> specific about this sentence, please? I would like to know what kind of >>>> optimization will be achieved and how differently PSC will be >> implemented. >>>> >>> >>> A3) We believe that changing the text to state - "this behavior may be used >> by the operators to optimize their network operations, based on more >> complete status information..." would more clearly state the intention. >>> >>> We had no intention of implying that there would be different >> implementations of PSC, but rather that the more complete network status >> information provided by PSC, would allow the systems to react in a more >> efficient manner to protection switching situations.' >>> >>>> Q4) Regarding the description 'because it was felt that this be best >>>> specified in a management document' in item 6, does the "a management >>>> document" include both characteristics of equipment functional blocks >>>> and equipment management aspect? >>>> >>> >>> A4) The IETF tends to standardize management behaviors which are >> required for interoperability between devices. This differs from the ITU, >> which publishes "equipment recommendations" that provide equipment >> functional blocks and management commands and messages that are >> generated. If the ITU feels that these definitions are necessary for their >> equipment definitions then it is their prerogative to document them there. I >> believe that this is in keeping with the spirit of the work-split between the >> IETF and the ITU on MPLS-TP. >>> >>>> Just a very minor comment is, regarding Annex B of RFC6378, it is >>>> written on page 43 actually, although the table of contents point to >>>> page 44. >>>> >>> >>> Thank you for this. We will remove explicit page number references and >> simply refer to sections, including this reference to Appendix (not Annex) B. >>> >> >> >> -- >> Yoshinori Koike >> koike.yoshinori@lab.ntt.co.jp > > -- Yoshinori Koike koike.yoshinori@lab.ntt.co.jp From tnadeau@juniper.net Tue Aug 7 06:04: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 666B121F867E for ; Tue, 7 Aug 2012 06:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.871 X-Spam-Level: X-Spam-Status: No, score=-3.871 tagged_above=-999 required=5 tests=[AWL=-2.414, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jm2oKLqjVJuV for ; Tue, 7 Aug 2012 06:04:22 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 750B621F8678 for ; Tue, 7 Aug 2012 06:04:20 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUCESU/kMgX02EvKVyBbWRtZ9rdeR0kmO@postini.com; Tue, 07 Aug 2012 06:04:22 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 7 Aug 2012 06:03:14 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 7 Aug 2012 09:03:13 -0400 From: Thomas Nadeau To: Xuxiaohu , "erosen@cisco.com" Date: Tue, 7 Aug 2012 09:03:11 -0400 Thread-Topic: [mpls] Comments on MPLS-in-UDP Thread-Index: Ac10nQBmPZRZ/A8FRtWiumhnrHXgXA== Message-ID: In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753EB93@szxeml525-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on 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: Tue, 07 Aug 2012 13:04:23 -0000 DQoNCk9uIDgvNy8xMiA1OjM5IEFNLCAiWHV4aWFvaHUiIDx4dXhpYW9odUBodWF3ZWkuY29tPiB3 cm90ZToNCg0KPkhpIEVyaWMsDQo+DQo+VGhhbmtzIGEgbG90IGZvciB5b3VyIGluc2lnaHRmdWwg Y29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zLiBQbGVhc2Ugc2VlIG15DQo+cmVzcG9uc2UgaW5saW5l Lg0KPg0KPj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+PiC3orz+yMs6IEVyaWMgUm9zZW4gW21haWx0 bzplcm9zZW5AY2lzY28uY29tXQ0KPj4gt6LLzcqxvOQ6IDIwMTLE6jjUwjfI1SAzOjUxDQo+PiDK 1bz+yMs6IFh1eGlhb2h1DQo+PiCzrcvNOiBlcm9zZW5AY2lzY28uY29tOyBtcGxzQGlldGYub3Jn DQo+PiDW98ziOiBSZTogQ29tbWVudHMgb24gTVBMUy1pbi1VRFANCj4+IA0KPj4gDQo+PiA+IEFz IGZvciBNUExTLWluLUdSRSBvciBNUExTLWluLUwyVFB2MywgaXQgcmVxdWlyZXMgUCByb3V0ZXJz IHRvIGJlDQo+PmNhcGFibGUNCj4+ID4gb2YgcGVyZm9ybWluZyBoYXNoIGNhbGN1bGF0aW9ucyBv biB0aGUgc3BlY2lmaWMgImxvYWQtYmFsYW5jaW5nDQo+PiA+IGZpZWxkIiBjb250YWluZWQgaW4g dGhlIGVuY2Fwc3VsYXRpbmcgaGVhZGVyIChlLmcuLCBMMlRQdjMgc2Vzc2lvbiBJRA0KPj4gPiBm aWVsZCBvciBHUkUga2V5IGZpZWxkKS4gIFN1Y2ggcmVxdWlyZW1lbnQgY2FuIG5vdCBiZSBtZXQg Ynkgc29tZSBQDQo+PnJvdXRlcnMNCj4+ID4gd2hpY2ggY291bGQgb25seSBwZXJmb3JtIGhhc2gg Y2FsdWxhdGlvbnMgb24gdGhlIGZpdmUgdHVwbGUgb2YgVENQL1VEUA0KPj4gPiBwYWNrZXRzLiBN UExTLWluLVVEUCBpcyBvbmx5IHByb3Bvc2VkIHRvIGJlIHVzZWQgaW4gc3VjaCBzcGVjaWZpYw0K Pj5jYXNlcy4NCj4+IA0KPj4gSSBzZWUgdGhlIGxvZ2ljIG9mIHRoaXMgYXJndW1lbnQuIE9uIHRo ZSBvdGhlciBoYW5kLCB3ZSBhbHJlYWR5IGhhdmUNCj4+dGhyZWUNCj4+IHN0YW5kYXJkaXplZCBN UExTLWluLUlQIGVuY2Fwc3VsYXRpb25zLCBlYWNoIG9mIHdoaWNoIGhhcyBiZWVuIGFyZ3VlZCB0 bw0KPj4gaGF2ZSBhbiBpbXBvcnRhbnQgYWR2YW50YWdlIG92ZXIgdGhlIG90aGVyIHR3by4gIEkg ZG9uJ3QgdGhpbmsgYW55IG9mDQo+PnRoZW0NCj4+IGhhcyByZWFsbHkgY2F1Z2h0IG9uIHRob3Vn aC4gIFRoZXJlJ3MgYWxzbyBiZWVuIHdvcmsgb24gTVBMUy1pbi1JUHNlYywNCj4+d2hpY2gNCj4+ IHNpbWlsYXJseSBoYXMgZmFpbGVkIHRvIGdlbmVyYXRlIG11Y2ggaW50ZXJlc3QgaW4gcHJhY3Rp Y2UuICBBZnRlciBhDQo+PmRvemVuDQo+PiB5ZWFycywgZG8gd2UgcmVhbGx5IHRoaW5rIHRoZXJl J3MgZ29pbmcgdG8gYmUgYSBsb3Qgb2YgaW50ZXJlc3QgaW4geWV0DQo+PiBhbm90aGVyIE1QTFMt aW4tSVAgZW5jYXBzdWxhdGlvbj8NCj4NCj5BcyBmb3Igc2VydmljZSBwcm92aWRlciBiYWNrYm9u ZXMsIG1vc3Qgb2YgdGhlbSBhcmUgY2FwYWJsZSBvZiBNUExTDQo+Zm9yd2FyZGluZyBhbmQgdGhl cmVmb3JlIGl0J3MgdW5kZXJzdGFuZGFibGUgdGhhdCBNUExTLWluLUlQDQo+ZW5jYXBzdWxhdGlv bnMgYXJlIG5vdCBwb3B1bGFyLiBIb3dldmVyLCBpbiBjbG91ZCBkYXRhIGNlbnRlciBuZXR3b3Jr DQo+ZW52aXJvbm1lbnRzLCBzb21lIGRhdGEgY2VudGVyIG9wZXJhdG9ycyBjaG9vc2UgdG8gdXNl IElQLCByYXRoZXIgdGhhbg0KPk1QTFMgaW4gdGhlIHVuZGVybHlpbmcgbmV0d29yayBkdWUgdG8g Y2VydGFpbiByZWFzb25zLiBJbiBhZGRpdGlvbiwNCj5NUExTLWJhc2VkIEwyVlBOIGFuZCBMM1ZQ TiB0ZWNobm9sb2dpZXMgYXJlIGNvbnNpZGVyZWQgdG8gYmUgdXNlZCBhcw0KPnNjYWxhYmxlIGRh dGEgY2VudGVyIG5ldHdvcmsgc29sdXRpb25zIHRvIHN1cHBvcnQgbXVsdGktdGVuYW5jeS4gSW4g dGhpcw0KPmNhc2UsIE1QTFMtaW4tSVAgZW5jYXBzdWxhdGlvbnMgd291bGQgYmUgdXNlZnVsLg0K DQpUT006IEknZCBsaWtlIHRvIGhlYXIgZnJvbSBhbnkgZGF0YSBjZW50ZXIgc2VydmljZSBwcm92 aWRlcnMgYXMgdG8gdGhpcw0KcG9pbnQuICBBcyBFcmljIG1lbnRpb25lZCBlYXJsaWVyLCB0aGVy ZSBhcmUgYSBudW1iZXIgb2YgZW5jYXBzdWxhdGlvbnMNCmF2YWlsYWJsZSBhbHJlYWR5IHdoaWNo IGhhdmUgbWlsZCAoYXQgYmVzdCkgYWRvcHRpb24gcmF0ZXMuICBJdCB3b3VsZCBzZWVtDQp0byBt ZSB0aGF0IHdlIHdvdWxkIG5lZWQgc29tZSBwcmV0dHkgZ29vZCBvcGVyYXRpb25hbCByZXF1aXJl bWVudCBkZW1hbmQNCnRvIG1ha2UgdXAgeWV0IGFub3RoZXIgb25lIG90aGVyIHRoYW4ganVzdCBt YWtpbmcgZm9yIHNvbWUgbmVhdCB3b3JrIGZvcg0Kc29tZSBwZW9wbGUgdG8gZG8gaW4gc3RhbmRh cmRzIGxhbmQuDQoNCgktLVRvbQ0KDQoNCg0KPlRvIHBlcmZvcm0gZmluZS1ncmFpbmVkIGxvYWQt YmFsYW5jaW5nIG92ZXIgTEFHIGFuZCBFQ01QIHBhdGhzIGluIHRoZQ0KPnVuZGVybHlpbmcgbmV0 d29yaywgdGhlIE1QTFMtaW4tSVAgZW5jYXBzdWxhdGlvbiBoZWFkZXIgc2hvdWxkIGNvbnRhaW4g YW4NCj5lbnRyeSBmaWVsZCBzbyB0aGF0IHRoZSB1bmRlcmx5aW5nIG5ldHdvcmsgY291bGQgYWNo aWV2ZSBhIGZpbmUtZ3JhaW5lZA0KPmxvYWQtYmFsYW5jaW5nIG9mIHRoZSBlbmNhcHN1bGF0ZWQg dHJhZmZpYy4gV2l0aCB0aGUgTVBMUy1pbi1VRFANCj5lbmNhcHN1bGF0aW9uLCB0aGUgc291cmNl IHBvcnQgZmllbGQgY291bGQgYmUgZGlyZWN0bHkgdXNlZCBhcyBhbiBlbnRyeQ0KPmZpZWxkLCBh bmQgbW9zdCBpbXBvcnRhbnRseSwgbW9zdCByb3V0ZXJzIGFuZCBsYXllcjMgc3dpdGNoZXMgaGF2 ZQ0KPmFscmVhZHkgYmVlbiBhYmxlIHRvIHBlcmZvcm0gaGFzaCBjYWxjdWxhdGlvbnMgb24gdGhl IGZpdmUgdHVwbGUgb2YgVURQDQo+cGFja2V0cy4NCj4NCj4+IE5vdGUgdGhhdCBlYWNoIG5ldyBl bmNhcHN1bGF0aW9uIGltcGFjdHMgdGhlIGRhdGEgcGxhbmUgb2YgdGhlIFBFDQo+PnJvdXRlcnMs DQo+PiBhbmQgdGhlIGRyYWZ0IHJlcXVpcmVzIHRoYXQgZWFjaCBlbmNhcHN1bGF0aW9uIGhlYWRl ciBoYXZlIGEgInNvdXJjZQ0KPj5wb3J0Ig0KPj4gZmllbGQgd2hvc2UgdmFsdWUgaXMgYSBjb21w dXRlZCBoYXNoIG9mIHRoZSBUQ1AvVURQIGhlYWRlciBvZiB0aGUNCj4+cGF5bG9hZC4NCj4+IFRo aXMgaXMgbm90IHNvbWV0aGluZyB0aGF0IGlzIGNvbXBsZXRlbHkgdHJpdmlhbCB0byBpbXBsZW1l bnQuDQo+DQo+QXMgZm9yIHRoZSBpbXBsZW1lbnRhdGlvbiBkaWZmaWN1bHR5IG9mIFBFIHJvdXRl cnMsIGl0IHNlZW1zIHRoZXJlIGlzIG5vDQo+YmlnIGRpZmZlcmVuY2UgYmV0d2VlbiBmaWxsaW5n IGEgaGFzaCB2YWx1ZSBpbiB0aGUgR1JFIGtleSBmaWVsZCAob3INCj5MMlRQdjMgc2Vzc2lvbiBJ RCBmaWVsZCkgYW5kIGZpbGxpbmcgaW4gYSBoYXNoIHZhbHVlIGluIHRoZSBVRFAgc291cmNlDQo+ cG9ydCBmaWVsZCwgSU1ITy4NCj4NCj4+IEEgZmV3IG1pc2NlbGxhbmVvdXMgdGVjaG5pY2FsIGNv bW1lbnRzLg0KPj4gDQo+PiBSZSB0aGUgSUFOQSBDb25zaWRlcmF0aW9uczoNCj4+IA0KPj4gPiAg IFR3byBkaXN0aW5jdCBVRFAgZGVzdGluYXRpb24gcG9ydCBudW1iZXJzIGluZGljYXRpbmcgTVBM UyB1bmljYXN0DQo+PiA+ICAgYW5kIE1QTFMgbXVsdGljYXN0IHJlc3BlY3RpdmVseSBuZWVkIHRv IGJlIGFzc2lnbmVkIGJ5IElBTkEuDQo+PiANCj4+IFNpbmNlIFJGQyA1MzMyIHdlIGRvIG5vdCBo YXZlIGNvZGVwb2ludHMgZm9yICJNUExTIHVuaWNhc3QiIGFuZCAiTVBMUw0KPj4gbXVsdGljYXN0 Ii4gIFNlY3Rpb25zIDQtOCBvZiBSRkMgNTMzMiBhbGxvY2F0ZSBjb2RlcG9pbnRzIGZvciBhIHZh cmlldHkNCj4+b2YNCj4+IGVuY2Fwc3VsYXRpbmcgcHJvdG9jb2xzLCB5b3Ugc2hvdWxkIHRha2Ug YSBsb29rIGF0IHRoYXQuDQo+DQo+VGhhbmtzIGEgbG90IGZvciByZW1pbmRpbmcgbWUgb2YgUkZD NTMzMi4gVGhlIGNvcnJlc3BvbmRpbmcgdGV4dCB3b3VsZCBiZQ0KPmNoYW5nZWQgYXMgZm9sbG93 ICIgVHdvIGRpc3RpbmN0IFVEUCBkZXN0aW5hdGlvbiBwb3J0IG51bWJlcnMgaW5kaWNhdGluZw0K Pk1QTFMgYW5kIE1QTFMgd2l0aCB1cHN0cmVhbS1hc3NpZ25lZCBsYWJlbCByZXNwZWN0aXZlbHkg bmVlZCB0byBiZQ0KPmFzc2lnbmVkIGJ5IElBTkEuLi4gIiAgSXMgdGhhdCBPSz8NCj4NCj4+IERv IHlvdSBleHBlY3QgdG8gc3VwcG9ydCBNVlBOIG92ZXIgdGhlIFVEUCBlbmNhcHN1bGF0aW9uPw0K Pg0KPklmIGRhdGEgY2VudGVyIG9wZXJhdG9ycyB3YW50IHRvIHVzZSBNVlBOIGluIHRoZWlyIGRh dGEgY2VudGVycywgdGhleQ0KPmNvdWxkIHVzZSBNUExTLWluLVVEUCBlbmNhcHN1bGF0aW9uIGZv ciBWUE4gdW5pY2FzdCB0cmFmZmljIGFuZCBWUE4NCj5tdWx0aWNhc3QgdHJhZmZpYy4NCj4NCj4+ IFRvIGdldCBhbiBpZGVhIG9mIHdoYXQgdGhlIFNlY3VyaXR5IEFyZWEgQURzIGFyZSBsaWtlbHkg dG8gcmVxdWlyZSB3aXRoDQo+PiByZWdhcmQgdG8gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25z LCBwbGVhc2UgbG9vayBhdCB0aGUgU2VjdXJpdHkNCj4+IENvbnNpZGVyYXRpb25zIHNlY3Rpb24g b2YgUkZDIDQwMjMuDQo+DQo+SXShr3MgYSB2ZXJ5IHVzZWZ1bCByZWZlcmVuY2UuIFdlIGNvLWF1 dGhvcnMgd291bGQgYWRkIG1vcmUgZGV0YWlsZWQNCj5zZWN1cml0eSBjb25zaWRlcmF0aW9ucyBp biB0aGUgbmV4dCByZXZpc2lvbi4NCj4NCj5UaGFua3MgYWdhaW4gZm9yIHlvdXIgaW5zaWdodCBj b21tZW50cyBhbmQgc3VnZ2VzdGlvbnMuDQo+DQo+QmVzdCByZWdhcmRzLA0KPlhpYW9odQ0KPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+bXBscyBtYWls aW5nIGxpc3QNCj5tcGxzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tcGxzDQoNCg== From davarish@yahoo.com Tue Aug 7 07:31: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 D4C4021F84E4 for ; Tue, 7 Aug 2012 07:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.903 X-Spam-Level: X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6COGp2jme--4 for ; Tue, 7 Aug 2012 07:31:03 -0700 (PDT) Received: from nm5-vm0.bullet.mail.bf1.yahoo.com (nm5-vm0.bullet.mail.bf1.yahoo.com [98.139.213.150]) by ietfa.amsl.com (Postfix) with ESMTP id 0B23321F85A8 for ; Tue, 7 Aug 2012 07:31:02 -0700 (PDT) Received: from [98.139.212.149] by nm5.bullet.mail.bf1.yahoo.com with NNFMP; 07 Aug 2012 14:30:53 -0000 Received: from [98.139.212.248] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 07 Aug 2012 14:30:53 -0000 Received: from [127.0.0.1] by omp1057.mail.bf1.yahoo.com with NNFMP; 07 Aug 2012 14:30:53 -0000 X-Yahoo-Newman-Id: 696961.45149.bm@omp1057.mail.bf1.yahoo.com Received: (qmail 99628 invoked from network); 7 Aug 2012 14:30:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=DKIM-Signature:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:In-Reply-To:Mime-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=1ZxC8nLTwUgoOLXeuHxzQVDQhYP96PbmXbTa/EAtxmtCSr9b9gDn77O8Xgw1tCsNtTB39OsaFJU7nCibLcWJGcBlumOP9xAf4WzuFvHBUk7zW9b2khbn4/tJpO0y5JXmtwMDDIc2e8PmDOHoc33CfnuIItGz8IuzCdwTN8WWAEA= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1344349853; bh=qGm9S0fUpzP7ehHNXX/NZEDlSjme2xDiCeDjIdkYRSA=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:In-Reply-To:Mime-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=EviABdfoQGgi3AcyfQHth/q3QjM8QW88CUVSry+unkTbYl9e4m3Vejub9XPVuaA7ABqk2fPIl6eu0Hpp9epJ0yWWNj0eP08VFn1D4+Bu39m4WlIFAnS5vPcXUC2QUaJ+4MN79iadnnk6tFtXOlfWWIebb3LrPyHRyLNgyJXkh1Y= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: zkSU0UcVM1nn6LJsiQLqIalneU5b2xf_G7RTSGSwBM0zCjH PuK6KzyKRwJoX_0eGn71hTxk4EXbDlLI7eKI10lXMJYo__WYxPLrXgXx9p9J RwSQwU0tAxCoML7Xr.k2V3_IGcnrfv8vY0NtnIIqHO3WQLOCExjiwXwliie9 C2Rti4y5VJYAtnqjuKSIFiGnISghFBIMmDvcije2UsJbd6uCqkKBhpm8Ljr2 zUTDSe8x0qWW0u73wBZCmn2Au8ZUlj.RHLIJfpXmcGyWmvJOaMkl8MH_Uydu v8k9Vg6OENZzdbJknfznlPed2cZ_PudkD7KRO2akuyF_vu1GcU1H7xqvgQQX Hux25AQ.okXLlU2P2OdXT6BKeq8D3pGxEKAJHsOFFqMdlyi6Pcq68Zt_BARV oPLJUtbZ6DGQpGws0Ix8.xseN4C9vdUY4k7bqO.DU7Ko17MpU_ggiK5BhTOJ IKZGKqIM- X-Yahoo-SMTP: ygPrP9CswBCWPbPtKJlJyLY0KMlg Received: from [192.168.0.105] (davarish@98.248.36.11 with xymcookie) by smtp117-mob.biz.mail.bf1.yahoo.com with SMTP; 07 Aug 2012 07:30:53 -0700 PDT References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753B3A1@szxeml525-mbx.china.huawei.com> <9398.1344282664@erosen-linux> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753EB93@szxeml525-mbx.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753EB93@szxeml525-mbx.china.huawei.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <46A79867-CE88-4F03-BF6E-667471C26B79@yahoo.com> X-Mailer: iPhone Mail (9B206) From: "S. Davari" Date: Tue, 7 Aug 2012 07:30:50 -0700 To: Xuxiaohu Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on 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: Tue, 07 Aug 2012 14:31:07 -0000 Hi Xiaohu, The complexity of=20 Regards, Shahram On Aug 7, 2012, at 2:39 AM, Xuxiaohu wrote: > Hi Eric, >=20 > Thanks a lot for your insightful comments and suggestions. Please see my r= esponse inline. >=20 >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Eric Rosen [mailto:erosen@cisco.com] >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B48=E6=9C=887=E6=97=A5 3= :51 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu >> =E6=8A=84=E9=80=81: erosen@cisco.com; mpls@ietf.org >> =E4=B8=BB=E9=A2=98: Re: Comments on MPLS-in-UDP >>=20 >>=20 >>> As for MPLS-in-GRE or MPLS-in-L2TPv3, it requires P routers to be capabl= e >>> of performing hash calculations on the specific "load-balancing >>> field" contained in the encapsulating header (e.g., L2TPv3 session ID >>> field or GRE key field). Such requirement can not be met by some P rout= ers >>> which could only perform hash calulations on the five tuple of TCP/UDP >>> packets. MPLS-in-UDP is only proposed to be used in such specific cases.= >>=20 >> I see the logic of this argument. On the other hand, we already have thre= e >> standardized MPLS-in-IP encapsulations, each of which has been argued to >> have an important advantage over the other two. I don't think any of the= m >> has really caught on though. There's also been work on MPLS-in-IPsec, wh= ich >> similarly has failed to generate much interest in practice. After a doze= n >> years, do we really think there's going to be a lot of interest in yet >> another MPLS-in-IP encapsulation? >=20 > As for service provider backbones, most of them are capable of MPLS forwar= ding and therefore it's understandable that MPLS-in-IP encapsulations are no= t popular. However, in cloud data center network environments, some data cen= ter operators choose to use IP, rather than MPLS in the underlying network d= ue to certain reasons. In addition, MPLS-based L2VPN and L3VPN technologies a= re considered to be used as scalable data center network solutions to suppor= t multi-tenancy. In this case, MPLS-in-IP encapsulations would be useful. To= perform fine-grained load-balancing over LAG and ECMP paths in the underlyi= ng network, the MPLS-in-IP encapsulation header should contain an entry fiel= d so that the underlying network could achieve a fine-grained load-balancing= of the encapsulated traffic. With the MPLS-in-UDP encapsulation, the source= port field could be directly used as an entry field, and most importantly, m= ost routers and layer3 switches have already been able to perform hash calcu= lations on the five tuple of UDP packets. >=20 >> Note that each new encapsulation impacts the data plane of the PE routers= , >> and the draft requires that each encapsulation header have a "source port= " >> field whose value is a computed hash of the TCP/UDP header of the payload= . >> This is not something that is completely trivial to implement. >=20 > As for the implementation difficulty of PE routers, it seems there is no b= ig difference between filling a hash value in the GRE key field (or L2TPv3 s= ession ID field) and filling in a hash value in the UDP source port field, I= MHO. >=20 >> A few miscellaneous technical comments. >>=20 >> Re the IANA Considerations: >>=20 >>> Two distinct UDP destination port numbers indicating MPLS unicast >>> and MPLS multicast respectively need to be assigned by IANA. >>=20 >> Since RFC 5332 we do not have codepoints for "MPLS unicast" and "MPLS >> multicast". Sections 4-8 of RFC 5332 allocate codepoints for a variety o= f >> encapsulating protocols, you should take a look at that. >=20 > Thanks a lot for reminding me of RFC5332. The corresponding text would be c= hanged as follow " Two distinct UDP destination port numbers indicating MPLS= and MPLS with upstream-assigned label respectively need to be assigned by I= ANA... " Is that OK? >=20 >> Do you expect to support MVPN over the UDP encapsulation? >=20 > If data center operators want to use MVPN in their data centers, they coul= d use MPLS-in-UDP encapsulation for VPN unicast traffic and VPN multicast tr= affic. >=20 >> To get an idea of what the Security Area ADs are likely to require with >> regard to the Security Considerations, please look at the Security >> Considerations section of RFC 4023. >=20 > It=E2=80=99s a very useful reference. We co-authors would add more detaile= d security considerations in the next revision. >=20 > Thanks again for your insight comments and suggestions.=20 >=20 > Best regards, > Xiaohu > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From davarish@yahoo.com Tue Aug 7 07:37: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 2803421F86EA for ; Tue, 7 Aug 2012 07:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.753 X-Spam-Level: X-Spam-Status: No, score=-0.753 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrPX8L0cak-Y for ; Tue, 7 Aug 2012 07:37:02 -0700 (PDT) Received: from nm30.bullet.mail.bf1.yahoo.com (nm30.bullet.mail.bf1.yahoo.com [98.139.212.189]) by ietfa.amsl.com (Postfix) with ESMTP id 3748D21F86DF for ; Tue, 7 Aug 2012 07:37:02 -0700 (PDT) Received: from [98.139.212.148] by nm30.bullet.mail.bf1.yahoo.com with NNFMP; 07 Aug 2012 14:37:01 -0000 Received: from [98.139.212.243] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 07 Aug 2012 14:37:01 -0000 Received: from [127.0.0.1] by omp1052.mail.bf1.yahoo.com with NNFMP; 07 Aug 2012 14:37:01 -0000 X-Yahoo-Newman-Id: 643468.39273.bm@omp1052.mail.bf1.yahoo.com Received: (qmail 10877 invoked from network); 7 Aug 2012 14:37:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=DKIM-Signature:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Subject:References:From:Content-Transfer-Encoding:Content-Type:In-Reply-To:Message-Id:Date:Cc:To:Mime-Version:X-Mailer; b=v/J/9bvo84+UBMLTJ6WpLgJgYt92X4n1JxENN2ltsR0IAFflntlarcbGpiyrutjOA4og8IPmLdICI0NRICCRAVs3NNiU+pKbyaA4wNxPweLrhw7J8gjpXTMRXkFEzS9nfgeVUm5o0/QhOpR2JrmFG5cbRXKNOA2Mt9N/5jEcfv8= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1344350221; bh=1+ScOT+IjIfg1bDODlaUMfjDwt36kIlsJAcDKkkpqu4=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Subject:References:From:Content-Transfer-Encoding:Content-Type:In-Reply-To:Message-Id:Date:Cc:To:Mime-Version:X-Mailer; b=PHYitMcDRKSsVZF8aKlJ4zR/4zJDWvCvITGztX2C2XJCcYG3uMSpYr1mjLX0eLN84zFip13EezYvFkyf822qwHIxfm+yw9jiOZabao/BI92bq6EqGrUVQq2R2my+4H3fOqXRrd0+V3A8/jXoVVj9JoakJ/5VX5gAleTsbpjp/d8= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: kKBTBTsVM1mAhX6GQy3DJo8avt2Bfwhx27pvCiDFs9wNUCa HV_tyriGFYd_3MnBnSEQQAAkVCbQF3yQE_jBppDPIc_FltbNrK6PeIzzo_5c hcutuEQbWkHASYresAAvQtBDLNr7M9h56FJcHV3D3_GvoGZHwPJM9ndnKggZ HJjUponHYNAc555cppzD3cwJXV5njr9l.kxWhph5_eLqw2t4QzB82IkWXurk 1PNemmIvM5eCmdAAULMqt6x2tMNqbO177jG1AaPidt7IrAjc7lCnsiOfZkct mPeuV5AYBJhCBcNkaGR_p1UyWe3cjp3w9Mtj6EyQU0X63EdhsSk1omuUtbSn wBxPGKc0BUkGsPL4uD3YeYTWFZF0xgXh6PGOOZKDKnqRKsOPZRcuM8uB9n7G HmGxEArGfvkoicy3u0hpZiPVjrflzDt8uuKcykp_8jT.MdLbftKMRHlXJyrW eEJvzc6_s1A-- X-Yahoo-SMTP: ygPrP9CswBCWPbPtKJlJyLY0KMlg Received: from [10.2.149.65] (davarish@198.228.213.198 with xymcookie) by smtp103-mob.biz.mail.bf1.yahoo.com with SMTP; 07 Aug 2012 07:37:00 -0700 PDT References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753B3A1@szxeml525-mbx.china.huawei.com> <9398.1344282664@erosen-linux> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753EB93@szxeml525-mbx.china.huawei.com> From: "S. Davari" Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753EB93@szxeml525-mbx.china.huawei.com> Message-Id: <7E541697-B01D-4B77-960B-4E454EB9F34D@yahoo.com> Date: Tue, 7 Aug 2012 07:35:52 -0700 To: Xuxiaohu Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (9B206) Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on 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: Tue, 07 Aug 2012 14:37:03 -0000 Hi Xiaohu The complexity of computing the GRE key is same as UDP source. However route= rs are available that do GRE Key calculations while You need new hardware fo= r your proposal. Also data center architectures are now leaning toward VXLAN and NVGRE.=20 Regards, Shahram On Aug 7, 2012, at 2:39 AM, Xuxiaohu wrote: > Hi Eric, >=20 > Thanks a lot for your insightful comments and suggestions. Please see my r= esponse inline. >=20 >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Eric Rosen [mailto:erosen@cisco.com] >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B48=E6=9C=887=E6=97=A5 3= :51 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu >> =E6=8A=84=E9=80=81: erosen@cisco.com; mpls@ietf.org >> =E4=B8=BB=E9=A2=98: Re: Comments on MPLS-in-UDP >>=20 >>=20 >>> As for MPLS-in-GRE or MPLS-in-L2TPv3, it requires P routers to be capabl= e >>> of performing hash calculations on the specific "load-balancing >>> field" contained in the encapsulating header (e.g., L2TPv3 session ID >>> field or GRE key field). Such requirement can not be met by some P rout= ers >>> which could only perform hash calulations on the five tuple of TCP/UDP >>> packets. MPLS-in-UDP is only proposed to be used in such specific cases.= >>=20 >> I see the logic of this argument. On the other hand, we already have thre= e >> standardized MPLS-in-IP encapsulations, each of which has been argued to >> have an important advantage over the other two. I don't think any of the= m >> has really caught on though. There's also been work on MPLS-in-IPsec, wh= ich >> similarly has failed to generate much interest in practice. After a doze= n >> years, do we really think there's going to be a lot of interest in yet >> another MPLS-in-IP encapsulation? >=20 > As for service provider backbones, most of them are capable of MPLS forwar= ding and therefore it's understandable that MPLS-in-IP encapsulations are no= t popular. However, in cloud data center network environments, some data cen= ter operators choose to use IP, rather than MPLS in the underlying network d= ue to certain reasons. In addition, MPLS-based L2VPN and L3VPN technologies a= re considered to be used as scalable data center network solutions to suppor= t multi-tenancy. In this case, MPLS-in-IP encapsulations would be useful. To= perform fine-grained load-balancing over LAG and ECMP paths in the underlyi= ng network, the MPLS-in-IP encapsulation header should contain an entry fiel= d so that the underlying network could achieve a fine-grained load-balancing= of the encapsulated traffic. With the MPLS-in-UDP encapsulation, the source= port field could be directly used as an entry field, and most importantly, m= ost routers and layer3 switches have already been able to perform hash calcu= lations on the five tuple of UDP packets. >=20 >> Note that each new encapsulation impacts the data plane of the PE routers= , >> and the draft requires that each encapsulation header have a "source port= " >> field whose value is a computed hash of the TCP/UDP header of the payload= . >> This is not something that is completely trivial to implement. >=20 > As for the implementation difficulty of PE routers, it seems there is no b= ig difference between filling a hash value in the GRE key field (or L2TPv3 s= ession ID field) and filling in a hash value in the UDP source port field, I= MHO. >=20 >> A few miscellaneous technical comments. >>=20 >> Re the IANA Considerations: >>=20 >>> Two distinct UDP destination port numbers indicating MPLS unicast >>> and MPLS multicast respectively need to be assigned by IANA. >>=20 >> Since RFC 5332 we do not have codepoints for "MPLS unicast" and "MPLS >> multicast". Sections 4-8 of RFC 5332 allocate codepoints for a variety o= f >> encapsulating protocols, you should take a look at that. >=20 > Thanks a lot for reminding me of RFC5332. The corresponding text would be c= hanged as follow " Two distinct UDP destination port numbers indicating MPLS= and MPLS with upstream-assigned label respectively need to be assigned by I= ANA... " Is that OK? >=20 >> Do you expect to support MVPN over the UDP encapsulation? >=20 > If data center operators want to use MVPN in their data centers, they coul= d use MPLS-in-UDP encapsulation for VPN unicast traffic and VPN multicast tr= affic. >=20 >> To get an idea of what the Security Area ADs are likely to require with >> regard to the Security Considerations, please look at the Security >> Considerations section of RFC 4023. >=20 > It=E2=80=99s a very useful reference. We co-authors would add more detaile= d security considerations in the next revision. >=20 > Thanks again for your insight comments and suggestions.=20 >=20 > Best regards, > Xiaohu > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From lizhong.jin@zte.com.cn Tue Aug 7 07:56: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 1569B21F8736 for ; Tue, 7 Aug 2012 07:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.091 X-Spam-Level: X-Spam-Status: No, score=-101.091 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTvUpr3zQlTd for ; Tue, 7 Aug 2012 07:56:12 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id F299B21F8732 for ; Tue, 7 Aug 2012 07:56:11 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 10723806486374; Tue, 7 Aug 2012 22:44:00 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 35944.5335797074; Tue, 7 Aug 2012 22:56:06 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q77Eu3o7054357; Tue, 7 Aug 2012 22:56:03 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: erosen@cisco.com, tnadeau@juniper.net MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Tue, 7 Aug 2012 22:55:21 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-07 22:56:02, Serialize complete at 2012-08-07 22:56:02 Content-Type: multipart/alternative; boundary="=_alternative 0052093148257A53_=" X-MAIL: mse01.zte.com.cn q77Eu3o7054357 Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-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: Tue, 07 Aug 2012 14:56:14 -0000 This is a multipart message in MIME format. --=_alternative 0052093148257A53_= Content-Type: text/plain; charset="US-ASCII" Hi Eric, I believe there is some misunderstanding about the use case. Please see inline below. Thanks Lizhong > Date: Mon, 06 Aug 2012 14:48:09 -0400 > From: Eric Rosen > To: Loa Andersson > Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" > > Subject: Re: [mpls] wg doc poll on > draft-jin-mpls-mldp-leaf-discovery-04 > Message-ID: <8845.1344278889@erosen-linux> > > > > this is to start a two week poll on adopting > > draft-jin-mpls-mldp-leaf-discovery-04 as an MPLS working group document. > > No, do not support. > > Applications that use BGP-based auto-discovery and/or signaling, e.g., MVPN, > already seem to have adequate mechanisms for discovering leaf nodes. E.g., > MVPN has the "Leaf Info Required" bit in PMSI Tunnel Attribute to indicate > when the tunnel root wants to know who all the leafs are, and the Leaf A-D > route is used by the leafs to reply to the root. A Leaf A-D route also > carries an RT to constrain distribution of the route to the root node. The > draft defines a new AFI/SAFI, whose NLRI consists of an mLDP FEC element and > a leaf node address. There is certainly no need for this in MVPN, as it > just duplicates existing functionality, in a less general way, and with no > comparable method of constraining distribution. > > The MVPN BGP signaling allows a root node to determine which leaf nodes need > to receive which customer data streams. In theory, this information could > be used to assign two different data streams to the same tunnel, if, e.g., > the same set of leaf nodes need to receive both streams. (Whether this is > actually useful in practice is arguable.) However, the signaling proposed > in this draft only allows the root node to determine the leaf nodes who have > joined a particular mLDP LSP. It doesn't convey any information about why a > particular leaf node has joined a particular LSP, so it's not really useful > if one is trying to decide whether two data streams should be sent on the > same tunnel. > > I just don't see the use case for the draft's BGP mechanism. [Lizhong] The leaf discovery mechanism is not to complement MVPN. MVPN has Leaf A-D route to find the VPN membership, and MVPN is a root initiated application. The leaf discovery mechanism is useful for root initiated application to aggregate tunnels from leaf initiated application. For example, how to let MVPN to aggregate the mLDP tunnel generated by in-band signaling? Leaf A-D could not find the membership of other application. The leaf discovery mechamisn is trying to solve this issue. Section 2 paragraph 2 gives out a more detail example. > > I think the T-LDP mechanism is similarly problematic. If an application is > not already using T-LDP for signaling, I don't think it makes much sense to > require that each leaf node initiate a new T-LDP session to each root node. > For security reasons, one usually doesn't accept T-LDP sessions from just > anyone; the set of possible T-LDP peers is either configured, or is > auto-discovered (via some BGP-based mechanism). If BGP auto-discovery is > already being used, the T-LDP mechanism would not be needed, but if BGP > auto-discovery is not being used, we wouldn't want to require that each > potential root node be configured with the addresses of all the potential > leaf nodes. [Lizhong] in section 4, we say: the root initiated application with LDP as the main signaling mechanism, e.g, P2MP PW [I-D.ietf-pwe3-p2mp-pw], would use leaf discovery mechanism based on T-LDP, while application with MP-BGP as main signaling mechanism, e.g, VPLS Multicast[I-D.ietf-l2vpn-vpls-mcast], L3VPN Multicast [RFC6513] may use leaf discovery mechanism based on MP-BGP. That means we did not require to configure much additional T-LDP session for leaf discovery, but mostly rely on the already existing T-LDP session provided by the application. > > We do have to remember that, in receiver-driven multicast, the fact that the > root node doesn't know all the leaf nodes is considered to be a scalability > advantage. [Lizhong] leaf discovery did not introduce much additional new T-LDP session, but mostly rely on the existing T-LDP session provided by the application. See section 5 for the scalability discussion. > > Also, I'm not at all sure what the root node would do with the information > that two P2MP LSPs have the same set of leaf nodes. This fact by itself > does not mean that the two tunnels could be replaced by a single tunnel. > Even if it did, LDP has no mechanism for replacing one tunnel with another. > I don't think it's worthwhile setting up a whole bunch of new TCP > connections (and T-Hello adjacencies) just to convey a small amount of > not-very-useful information. [Lizhong] this is not to replace two tunnels into one, but when creating new service, the root node has the capability to aggregate existing tunnel instead of creating an additional one. > > In summary: > > - I don't really see what the use case is; > > - Existing BGP A-D mechanisms for MVPN are better at providing the > information an application really needs, and are better at constraining > the distribution of the information; > > - The T-LDP mechanism raises security issues and overhead issues, and > it is not clear what to do with the information it conveys. > > > > > > ------------------------------ > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > End of mpls Digest, Vol 100, Issue 9 > ************************************ > --=_alternative 0052093148257A53_= Content-Type: text/html; charset="US-ASCII"
Hi Eric,
I believe there is some misunderstanding about the use case. Please see inline below.

Thanks
Lizhong


> Date: Mon, 06 Aug 2012 14:48:09 -0400
> From: Eric Rosen <erosen@cisco.com>
> To: Loa Andersson <loa@pi.nu>
> Cc: "mpls@ietf.org" <mpls@ietf.org>,   "mpls-chairs@tools.ietf.org"
>    <mpls-chairs@tools.ietf.org>
> Subject: Re: [mpls] wg doc poll on
>    draft-jin-mpls-mldp-leaf-discovery-04
> Message-ID: <8845.1344278889@erosen-linux>
>
>
> > this is to start a two week poll on adopting
> > draft-jin-mpls-mldp-leaf-discovery-04 as an MPLS working group document.
>
> No, do not support.
>
> Applications that use BGP-based auto-discovery and/or signaling, e.g., MVPN,
> already seem to have adequate mechanisms for discovering leaf nodes.  E.g.,
> MVPN has the "Leaf Info Required" bit in PMSI Tunnel Attribute to indicate
> when the tunnel root wants to know who all the leafs are, and the Leaf A-D
> route  is used by the leafs to reply to the root.  A Leaf A-D route also
> carries an RT to constrain distribution of the route to the root node.  The
> draft defines a new AFI/SAFI, whose NLRI consists of an mLDP FEC element and
> a leaf node address.  There is certainly no need for this in MVPN, as it
> just duplicates existing functionality, in a less general way, and with no
> comparable method of constraining distribution.
>
> The MVPN BGP signaling allows a root node to determine which leaf nodes need
> to receive which customer data streams.  In theory, this information could
> be used to assign two different data streams to the same tunnel, if, e.g.,
> the same set of leaf nodes need to receive both streams.  (Whether this is
> actually useful in practice is arguable.)  However, the signaling proposed
> in this draft only allows the root node to determine the leaf nodes who have
> joined a particular mLDP LSP.  It doesn't convey any information about why a
> particular leaf node has joined a particular LSP, so it's not really useful
> if one is trying to decide whether two data streams should be sent on the
> same tunnel.
>
> I just don't see the use case for the draft's BGP mechanism.
[Lizhong] The leaf discovery mechanism is not to complement MVPN. MVPN has Leaf A-D route to find the VPN membership, and MVPN is a root initiated application. The leaf discovery mechanism is useful for root initiated application to aggregate tunnels from leaf initiated application. For example, how to let MVPN to aggregate the mLDP tunnel generated by in-band signaling? Leaf A-D could not find the membership of other application. The leaf discovery mechamisn is trying to solve this issue. Section 2 paragraph 2 gives out a more detail example.

>
> I think the T-LDP mechanism is similarly problematic.  If an application is
> not already using T-LDP for signaling, I don't think it makes much sense to
> require that each leaf node initiate a new T-LDP session to each root node.
> For security reasons, one usually doesn't accept T-LDP sessions from just
> anyone; the set of possible T-LDP peers is either configured, or is
> auto-discovered (via some BGP-based mechanism).  If BGP auto-discovery is
> already being used, the T-LDP mechanism would not be needed, but if BGP
> auto-discovery is not being used, we wouldn't want to require that each
> potential root node be configured with the addresses of all the potential
> leaf nodes.
[Lizhong] in section 4, we say: the root initiated application with LDP as the
   main signaling mechanism, e.g, P2MP PW [I-D.ietf-pwe3-p2mp-pw], would
   use leaf discovery mechanism based on T-LDP, while application with
   MP-BGP as main signaling mechanism, e.g, VPLS
   Multicast[I-D.ietf-l2vpn-vpls-mcast], L3VPN Multicast [RFC6513] may
   use leaf discovery mechanism based on MP-BGP.
That means we did not require to configure much additional T-LDP session for leaf discovery, but mostly rely on the already existing T-LDP session provided by the application.

>
> We do have to remember that, in receiver-driven multicast, the fact that the
> root node doesn't know all the leaf nodes is considered to be a scalability
> advantage.
[Lizhong] leaf discovery did not introduce much additional new T-LDP session, but mostly rely on the existing T-LDP session provided by the application. See section 5 for the scalability discussion.

>
> Also, I'm not at all sure what the root node would do with the information
> that two P2MP LSPs have the same set of leaf nodes.  This fact by itself
> does not mean that the two tunnels could be replaced by a single tunnel.
> Even if it did, LDP has no mechanism for replacing one tunnel with another.
> I don't think it's worthwhile setting up a whole bunch of new TCP
> connections (and T-Hello adjacencies) just to convey a small amount of
> not-very-useful information.
[Lizhong] this is not to replace two tunnels into one, but when creating new service, the root node has the capability to aggregate existing tunnel instead of creating an additional one.

>
> In summary:
>
> - I don't really see what the use case is;
>
> - Existing BGP A-D mechanisms for MVPN are better at providing the
>   information an application really needs, and are better at constraining
>   the distribution of the information;
>
> - The T-LDP mechanism raises security issues and overhead issues, and
>   it is not clear what to do with the information it conveys.
>  
>
>
>
>
> ------------------------------
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
>
> End of mpls Digest, Vol 100, Issue 9
> ************************************
>
--=_alternative 0052093148257A53_=-- From eosborne@cisco.com Tue Aug 7 08:08: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 EF9EC21F8752 for ; Tue, 7 Aug 2012 08:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.513 X-Spam-Level: X-Spam-Status: No, score=-10.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hao6WxmMqUlb for ; Tue, 7 Aug 2012 08:08:05 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9B63921F8751 for ; Tue, 7 Aug 2012 08:08:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=1082; q=dns/txt; s=iport; t=1344352085; x=1345561685; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=r07j/K0q26No60399SjJy4lAKaVwBUWkEGWwLjrhydI=; b=L9X8Sn2IZEHdMtkJLQZNmC29IpeS+cB8u+O5pdUhvvW9dOrbDZ0Jk/e0 n+EbBpx/YusCmHL5O7jiyp8bv+KhRbhfqI1Rvr7tGabApPzQDLGONQnwB gUtWp1ig/8KcnTsNVNkEs28K+3fASj8EhSO3VN9lxUXSiPrgCmtpOsBll Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMYuIVCtJXG+/2dsb2JhbABFuUaBB4IgAQEBAwESASc/EAIBCCIUEDIlAgQBDQ0ah2UGm12gV5EcYAOjboFmgl8 X-IronPort-AV: E=Sophos;i="4.77,727,1336348800"; d="scan'208";a="108983335" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 07 Aug 2012 15:08:05 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q77F854w002323 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Aug 2012 15:08:05 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0298.004; Tue, 7 Aug 2012 10:08:05 -0500 From: "Eric Osborne (eosborne)" To: Xuxiaohu , "Eric Rosen (erosen)" Thread-Topic: Comments on MPLS-in-UDP Thread-Index: AQHNdIEAkfCDwjMvAUa1dYjrrKc2pZdOc4cA Date: Tue, 7 Aug 2012 15:08:04 +0000 Message-ID: <20ECF67871905846A80F77F8F4A275720F5396EC@xmb-rcd-x09.cisco.com> References: Your message of Mon, 30 Jul 2012 18:03:44 -0000. <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753B3A1@szxeml525-mbx.china.huawei.com> <9398.1344282664@erosen-linux> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753EB93@szxeml525-mbx.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753EB93@szxeml525-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.23.87] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19090.005 x-tm-as-result: No--41.538800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on 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: Tue, 07 Aug 2012 15:08:07 -0000 [please note...different Eric] ... > > Note that each new encapsulation impacts the data plane of the PE > routers, > > and the draft requires that each encapsulation header have a "source po= rt" > > field whose value is a computed hash of the TCP/UDP header of the > payload. > > This is not something that is completely trivial to implement. >=20 > As for the implementation difficulty of PE routers, it seems there is no = big > difference between filling a hash value in the GRE key field (or L2TPv3 > session ID field) and filling in a hash value in the UDP source port fiel= d, IMHO. What happens if the UDP source port you generate is an ephemeral number alr= eady in use? I realize that the draft doesn't specify a particular hashing= algorithm but collisions are unavoidable. Does the hardware that's imposi= ng the hashed source port now need to track allocated source ports by all a= pplications on the PE? I could see some on-router firewalls choking on a p= acket that shared a source port with some other application. eric From lamberto.sterling@gmail.com Tue Aug 7 08:10: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 DB11021F8665 for ; Tue, 7 Aug 2012 08:10:36 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joY-DSfxHAIp for ; Tue, 7 Aug 2012 08:10:36 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id E09FC21F85C3 for ; Tue, 7 Aug 2012 08:10:35 -0700 (PDT) Received: by qadz3 with SMTP id z3so1763657qad.10 for ; Tue, 07 Aug 2012 08:10:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=sPogerdGga+LtxTmBhyWW1XbvAfBha1l6VZdFKMgSf0=; b=zMHFZ4DuSN/vyyQclE6nddV6g0k4CLBaiuHHGr54LFLzJpNt75tgtqtItHQBCfyfQs 3/J1utiXOd8wVMXbLK3tB+49JUS2APhK60hNurTKxrHkETvNbFjPdvIUQbI74AVstVis LBGZFt848lMKOfvLSuoPY1Ec9fIxL2oZzRSKCM3O2zOjCo3nNKmnEoh3qwJgpN+e4oic tYtaNxf9yc8xatmykHWekyrBQL5vwp7o09L+Bx14InEV9jJ5Z09Uos7Myxm/kiRTAxF+ o1plJm3oc8p2ThslaR02kGt6Vn0vi93cf9lkTQb2ouOrB4t00tAGidQLfY5Ezq9GY8TB ladA== MIME-Version: 1.0 Received: by 10.60.172.202 with SMTP id be10mr25060033oec.53.1344352235300; Tue, 07 Aug 2012 08:10:35 -0700 (PDT) Received: by 10.76.20.69 with HTTP; Tue, 7 Aug 2012 08:10:35 -0700 (PDT) Date: Tue, 7 Aug 2012 17:10:35 +0200 Message-ID: From: Lamberto Sterling To: mpls@ietf.org, Loa Andersson , mpls-chairs@tools.ietf.org Content-Type: multipart/alternative; boundary=bcaec54a35d27026dc04c6ae6535 Subject: Re: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-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: Tue, 07 Aug 2012 15:10:37 -0000 --bcaec54a35d27026dc04c6ae6535 Content-Type: text/plain; charset=ISO-8859-1 Support. Most of our multicast apps are BGP signaling, and suggest to remove T-LDP mechanism since has some scalability issue as Eric pointed out. BR. Lamberto > ------------------------------ > Date: Tue, 31 Jul 2012 14:11:16 +0200 > From: Loa Andersson > To: "mpls@ietf.org" , Martin Vigoureux > > Cc: "mpls-chairs@tools.ietf.org" > Subject: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-04 > Message-ID: <5017CB64.9070507@pi.nu> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Working group, > > this is to start a two week poll on adopting > draft-jin-mpls-mldp-leaf-discovery-04 > as an MPLS working group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). > > This poll ends August 17, 2012. > > /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 > > --bcaec54a35d27026dc04c6ae6535 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Support. Most of our multicast apps are BGP signaling, and suggest to = remove T-LDP mechanism since has some scalability issue as Eric pointed out= .
=A0
BR.
Lamberto
=A0

=A0
------------------------------
Dat= e: Tue, 31 Jul 2012 14:11:16 +0200
From: Loa Andersson <loa@pi.nu>
To: "mpls@ietf.org" <mpls@ietf.org>, =A0 =A0Martin Vigoureux=
=A0 =A0 =A0 =A0 <martin.vigoureux@alcatel-lucent.com>
Cc: "mpls-chairs@tools.i= etf.org" <mpls-ch= airs@tools.ietf.org>
Subject: [mpls] wg doc poll on draft-jin-mpl= s-mldp-leaf-discovery-04
Message-ID: <5017CB64.9070507@= pi.nu>
Content-Type: text/plain; charset=3DISO-8859-1; format=3Df= lowed

Working group,

this is to start a two week poll on adop= ting
draft-jin-mpls-mldp-leaf-discovery-04
as an MPLS working group document.=

Please send your comments (support/not support) to the mpls working=
group mailing list (mpls@ietf.org)= .

This poll ends August 17, 2012.

/Loa
(mpls wg co-chair)
--=


Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 e= mail: loa.andersson@ericsson.= 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

--bcaec54a35d27026dc04c6ae6535-- From erosen@cisco.com Tue Aug 7 08:42: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 A145E21F8741 for ; Tue, 7 Aug 2012 08:42:16 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4-vKT5Isrkn for ; Tue, 7 Aug 2012 08:42:15 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id A870E21F85EA for ; Tue, 7 Aug 2012 08:42:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=erosen@cisco.com; l=2371; q=dns/txt; s=iport; t=1344354135; x=1345563735; h=to:cc:subject:in-reply-to:reply-to:date:message-id:from; bh=T9C+PjJvocC9XiZWR71OVt1s3O2nbzxKzat8WH09GdY=; b=AvaE05JwinxOKibflBIna3lD6/7hkCVDZO+E0DqcXmmLxUTQOX93tClA tmZ7Ut4olh9aHn67W/K3doYyJVHVShmPe2+DKtk4pb7KOUlbspqw3YXZj vzJGN0r2ZKN0p7dfxMniEJ6u66x8vTqq+bTy5xW206ue5LJ0/MgPSQ+d0 c=; X-IronPort-AV: E=Sophos;i="4.77,727,1336348800"; d="scan'208";a="51226557" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 07 Aug 2012 15:42:15 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q77FgEhO023636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Aug 2012 15:42:15 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id q77FgDXi020571; Tue, 7 Aug 2012 11:42:13 -0400 To: Lizhong Jin In-reply-to: Your message of Tue, 07 Aug 2012 22:55:21 +0800. Date: Tue, 07 Aug 2012 11:42:13 -0400 Message-ID: <20570.1344354133@erosen-linux> From: Eric Rosen Cc: mpls-chairs@tools.ietf.org, mpls@ietf.org Subject: Re: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 15:42:16 -0000 > The leaf discovery mechanism is not to complement MVPN > The leaf discovery mechanism is useful for root initiated application to > aggregate tunnels from leaf initiated application. For example, how to let > MVPN to aggregate the mLDP tunnel generated by in-band signaling? I'm confused by these two sentences, as the second mentions the use of mldp leaf discovery by MVPN, but the first says that you dont' intend the two mechanisms to be used together. However, let's assume for now that there is no MVPN here, just some mLDP in-band signaling. So suppose PE2, PE3, and PE4 join an mLDP tunnel rooted at PE1. Say the tunnel is identified by the mLDP FEC element > (this is a case of in-band signaling).. Now PE2, PE3, and PE4 join another mLDP tunnel rooted at PE1, say > (another case of in-band signaling). PE1 sees that the two tunnels have exactly the same set of leaf nodes. So what is PE1 supposed to do? > the root node has the capability to aggregate existing tunnel instead of > creating an additional one. A few questions: - How does it do this? There doesn't seem to be any mechanism to do this. * What will cause PE2,PE3,PE4 to expect (S2,G2) traffic on the > tunnel? * What will cause the teardown of the partially set up tunnel at the P routers and PE routers? - How does the root node's aggregation strategy respond to dynamically changing sets of leaf nodes? (Remember the leaf nodes join and leave the LSP one at a time.) - How does the root node even know that the leaf nodes can correctly handle traffic from an aggregated tunnel? I don't think any of this can be done without some application-layer signaling between the root and leaf nodes. But if there is application-layer signaling between the root and leaf nodes, why doesn't that provide all the necessary auto-discovery? > leaf discovery did not introduce much additional new T-LDP session, but > mostly rely on the existing T-LDP session provided by the application. If you want to focus on a use case where there is already T-LDP signaling for some application, you have to show that some requirement is not met by the existing T-LDP signaling for that application. - From kireeti@juniper.net Tue Aug 7 09:27: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 850EB11E8087 for ; Tue, 7 Aug 2012 09:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1lf9B5xJMm7 for ; Tue, 7 Aug 2012 09:27:27 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id BD8A111E8072 for ; Tue, 7 Aug 2012 09:27:26 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUCFB7AbEubiCq39P64vIP8UCA1jFyuFj@postini.com; Tue, 07 Aug 2012 09:27:26 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 7 Aug 2012 09:26:40 -0700 From: Kireeti Kompella To: Sam Aldrin Date: Tue, 7 Aug 2012 09:26:40 -0700 Thread-Topic: [mpls] LSP ping clarification Thread-Index: Ac10uWzBPe16+Q/SRU2nmqD670yY1w== Message-ID: References: <3C086BA39C55B9418AE8FEA3F3EFDEC4075D22@SJEXCHMB09.corp.ad.broadcom.com> <176B443F-4AA1-4F90-9936-3B1AF7A89919@gmail.com> In-Reply-To: <176B443F-4AA1-4F90-9936-3B1AF7A89919@gmail.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 Cc: "mpls@ietf.org" Subject: Re: [mpls] LSP ping clarification 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, 07 Aug 2012 16:27:28 -0000 On Aug 3, 2012, at 23:30 , Sam Aldrin wrote: > Vivek, >=20 > Before thinking of new 'magic' fields, why do you think existing RFC4379= do not work? > As I eluded to in my email, existing model perfectly works without any ad= ditional change. Thanks, Sam -- my thoughts exactly. Perhaps not perfectly, but certainly w= ell enough. Besides, the magic value approach certainly doesn't work. If you want to e= xercise the fifth member of a bundle (ECMP or LAG) (i.e., EL =3D 5), you'll= be choosing the fifth member of every hop to get to where you want, which = unfortunately won't be where you want. Kireeti. > -sam > On Aug 3, 2012, at 8:51 PM, "Vivek Kumar" wrote: >=20 >> Hi Kireeti/Sam, >>=20 >> What about making some TTL/EXP field of ELI as magic value( say TTL=3D2= 55 or EXP=3D7) to indicate that if ELI has TTL=3D255 or EXP=3D7 , the use E= L value directly to index one of ECMP member ( without doing hashing). >> For example , if ELI.TTL=3D255 , and EL=3D1 , then select first member = of ECMP group and if EL=3D2 , then next member and so on.. >>=20 >> Not sure if it is possible to have this kind of magic value for TTL or = EXP but anyway for ELI which is going to be reserved value it should not be= an issue. >> Let me know your feedback. >>=20 >> Regards, >> Vivek=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 Aug 7 16:46: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 56FE511E80FA for ; Tue, 7 Aug 2012 16:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.086 X-Spam-Level: X-Spam-Status: No, score=-5.086 tagged_above=-999 required=5 tests=[AWL=-0.908, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PveA4PbhwIJD for ; Tue, 7 Aug 2012 16:45:59 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBC311E80F3 for ; Tue, 7 Aug 2012 16:45:59 -0700 (PDT) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Tue, 07 Aug 2012 16:44:37 -0700 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, 7 Aug 2012 16:45:47 -0700 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, 7 Aug 2012 16:45:27 -0700 From: "Shahram Davari" To: "mpls@ietf.org" Thread-Topic: draft-ietf-mpls-tp-use-cases-and-design-02 Thread-Index: Ac109rZq2Pfvls9SQTu4EKif2qQJBQ== Date: Tue, 7 Aug 2012 23:45:25 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F2806E252@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.16.65.57] MIME-Version: 1.0 X-WSS-ID: 7C3F77EF3NK13036541-01-01 Content-Type: multipart/related; boundary=_011_4A6CE49E6084B141B15C0713B8993F2806E252SJEXCHMB12corpadb_; type="multipart/alternative" Subject: [mpls] draft-ietf-mpls-tp-use-cases-and-design-02 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, 07 Aug 2012 23:46:00 -0000 --_011_4A6CE49E6084B141B15C0713B8993F2806E252SJEXCHMB12corpadb_ Content-Type: multipart/alternative; boundary=_000_4A6CE49E6084B141B15C0713B8993F2806E252SJEXCHMB12corpadb_ Content-Transfer-Encoding: 7bit --_000_4A6CE49E6084B141B15C0713B8993F2806E252SJEXCHMB12corpadb_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, I am not sure it is late or not, but I found a discrepancy between This dra= ft and RFC5960. This draft says PHP is optional for MPLS-TP, while RFC5960= says PHP MUST not be used. Is there any way to correct this before IESG publication? Thank you, [Description: Description: Description: Description: Description: Descripti= on: Description: Description: Description: Description: cid:image009.jpg@01= CD505E.7B800DB0] Shahram Davari | Technical Director, Network Switching Group Broadcom Corporation | (O) 408-922-7436 | (M) 408-660-5695 [Description: Description: Description: Description: Description: Descripti= on: Description: Description: Description: Description: Description: Descri= ption: image005][Description: Des= cription: Description: Description: Description: Description: Description: = Description: Description: Description: Description: Description: image002]<= http://twitter.com/#!/broadcom>[Description: Description: Description: Desc= ription: Description: Description: Description: Description: Description: D= escription: Description: Description: image003][Description: Description: Description: Description: Description: De= scription: Description: Description: Description: Description: Description:= Description: image004][Description: Description: Description: Descri= ption: Description: Description: Description: Description: Description: Des= cription: Description: Description: image006][Description: Description: Description: Description: De= scription: Description: Description: Description: Description: Description:= Description: Description: image008][Description= : Description: Description: Description: Description: Description: Descript= ion: Description: Description: Description: Description: Description: image= 007] --_000_4A6CE49E6084B141B15C0713B8993F2806E252SJEXCHMB12corpadb_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Hi,

 

I am not sure it is late or not, but I found a discr= epancy between This draft and  RFC5960. This draft says PHP is optiona= l for MPLS-TP, while RFC5960 says PHP MUST not be used.

 

Is there any way to correct this before IESG publica= tion?

 

Thank you,<= /span>

 

 

3D"Descriptio=

 

Shahram Davari | Technical Director, Network Switching Group
Broadcom Corporation | (O) 408-922-7436 | (M) 408-660-5695<= /p>

 

=3D"Description:3D"Descripti=3D"Des=<= !--[if gte vml 1]> 3D"Description:3D"Description:3D"Description:3D"Description: &= nbsp;       

 

 

 

 

--_000_4A6CE49E6084B141B15C0713B8993F2806E252SJEXCHMB12corpadb_-- --_011_4A6CE49E6084B141B15C0713B8993F2806E252SJEXCHMB12corpadb_ Content-Type: image/jpeg; name=image001.jpg Content-Description: image001.jpg Content-Disposition: inline; filename=image001.jpg; size=35434; creation-date="Tue, 07 Aug 2012 23:45:25 GMT"; modification-date="Tue, 07 Aug 2012 23:45:25 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4RSrRXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUAAAABAAAAYgEbAAUAAAABAAAA agEoAAMAAAABAAIAAAExAAIAAAAeAAAAcgEyAAIAAAAUAAAAkIdpAAQAAAABAAAApAAAANAADqYA AAAnEAAOpgAAACcQQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2gAMjAxMjowNjoxNSAxNjox Njo0OAAAA6ABAAMAAAABAAEAAKACAAQAAAABAAABCKADAAQAAAABAAAAOgAAAAAAAAAGAQMAAwAA AAEABgAAARoABQAAAAEAAAEeARsABQAAAAEAAAEmASgAAwAAAAEAAgAAAgEABAAAAAEAAAEuAgIA BAAAAAEAABN1AAAAAAAAAEgAAAABAAAASAAAAAH/2P/iDFhJQ0NfUFJPRklMRQABAQAADEhMaW5v AhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAAAAAAAAAA AAAAAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQAAAIEAAAA FHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRtZGQAAALE AAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAAJHRlY2gA AAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAAQ29weXJp Z2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJzUkdCIElF QzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAA AAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeFAAAY2lhZ WiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAA AAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29s b3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29s b3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxSZWZlcmVu Y2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVmZXJlbmNl IFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlWAFAAAABX H+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBjdXJ2AAAA AAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABtAHIAdwB8 AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsBAQEHAQ0B EwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHBAckB0QHZ AeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsECywLVAuAC 6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQTBCAELQQ7 BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYFtQXFBdUF 5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZB6wHvwfS B+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J5Qn7ChEK Jwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1DI4MpwzA DNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14Peg+WD7MP zw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLDEuMTAxMj E0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwWjxayFtYW +hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqeGsUa7BsU GzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMfPh9pH5Qf vx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQfJE0kfCSr JNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWspnSnQKgIq NSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9aL5Evxy/+ MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1wjX9Njc2 cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8JzxlPKQ84z0i PWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31DwEQDREdE ikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtTS5pL4kwq THJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19TqlP2VEJU j1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1XIZc1l0n XXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1lkmXnZj1m kmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8eb3hv0XAr cIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5iXnnekZ6 pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQdhICE44VH hauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaPnpAGkG6Q 1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtCm6+cHJyJ nPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSp N6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYB tnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD 1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+ 0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4Dbg veFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M 8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+S/7c/23/ ///tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8V GBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4O DhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgA IwCgAwEiAAIRAQMRAf/dAAQACv/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUB AQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJx gTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePz RieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYF NQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNU oxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//a AAwDAQACEQMRAD8A9Re1vJA+JMIZcAfa8DzDz+Rwc1GeYEyGjxd/qEPc48Oe74AAf9Mf9+SUptzg AXDc09xH97mf9JAxesdMy82/BxshtmVi/wA/UJluu06kbX7HeyzZ/N/4RG2O3A7XT3JDf++FrlxH 1aeWdZxM5oh3VW55J8dt3q6/9tpspUYjv/6L/wB02eX5eOTHmmSQccbhX7/DPL6v+p4cj3ySCzIB 0f7T49kXlOay6SSSSlKL3hvOpPDRyVE2SdtY3u8ew/rOQ5kF4dp+fb/3ypJS7nPMyYj6UGGt/rP+ k5yh+kkbXODjwOSR47H/AEG/11KD7QG6811+H/CWJaQZ9zSYce73fuN/kJKY+vkMiQ2xp4Ils/8A Vf5/82pNy5Gtbh5iCPyhOGFziHGT/hT2/k1D+SnfSRqzj93/AMikpk29juxb8Qp8qqDEjuO3+u3/ AF/0X84ptsLT8e3+v53+r0lNhJMCHAEag8J0lKSTFwBidfBJJT//0O4+ufVsro31bzupYbR9qpa1 tDiA4h9j2UBwYZ3bPU9RcC768fXk1OcxxczGl/2j7I0V3V2X1YeFY7e5jn03Odb+kwW+r/wP6Oy5 eldT6f1PLsZ9k6k/Bp2lttbKmPc6T9Jltvupdt/cVP8A5o4VbfVxcnKp6gIP283Pssc4cfaK7HfZ 7mf6Sr0kCT0H4s0MeIxBnm4Sf0YwlPh/2p/V/wDjXvPFV/Xr6w+tY/0hkZF4uxn9LZh2RhZTXGrC rfktbbbm2X1MtzMmn/RU2ekxVMf6ydatf0ijplNDM/GxiacL7I8l+W/KuxMyqfY3Apdi1fbMm176 fT/8893f0z619Q2Yefl41OCHg3XYnqsyLWN/wbtx9On1v8J6b1r9VwD1Hp92G25+M60ey6okOa4H cx3tLdzdw97N3vQu79O21pMBAxj7wqZ9ft8Uowh8nFL5eP0Tyej/AL986b9devuoys71W1Fj/SzM CzCtLelt9b7OzIvzGN/XbWUfp7aLP+t0/o7GKtZ9evrnhbB6TsrHbXea8sY3pHJZYMgdKz7aCG/Z m78Sy/0v0fq4q7lmB9bspjcXPzcfGxwALMjCD/tNgHt+ncPSxnP/ANJUz/i0rPqnj0H1+l5OTg5U 7nXMtdZvd/3ZpyXPqyP/AANLiPSP26JOHFHSWePEdvbjLJj/AOqT9HD/AIEMqT6r9Uv6h0PFuy7z bmtrYMwlgqi5zGZLq9lldbfZVkVfzX6NaZcD9Jwd/WdP/QrG1yrYFOdRSa83MOdcXEi01tpIbA/R +lU6v8737lak8Q773j/vqcPsYJAAkCQkB+lHi4Zf4/BJcgkajc0dj7GD+z9JKSfdO4j886Mb/VH5 3+v6RNGsxr2Ja5x/znpO0ILuexsI/wCjWxJCtIJkhjvpPP0nn91qeHbhAAfHtb2Y3x/rJ2te4yJn /SP7f1GIjGBogd9STyT5pKU1oY0NHZSSSSUxfWx/0hPgeD96AcV4+hZ8ngH8m1WUklNQOyaT72yw 8ubLo/lfvIjX7xO6QeDOn/R2f9UjobqW7tzPa48xwfiElLNj4eQgf9TKmDHw+5R9w5/Cf70+vYH7 o/6pJT//0fVUl8qpJKfqpJfKqSSn6qSXyqkkp+p7PoH6P9rhCZtnXb/1uf8Avq+XUklP1G/Z2/6e 6E9HJ/m/7H/fl8tpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp//Z/+0dyFBo b3Rvc2hvcCAzLjAAOEJJTQQEAAAAAAAvHAFaAAMbJUccAVoAAxslRxwBWgADGyVHHAFaAAMbJUcc AVoAAxslRxwCAAACAAAAOEJJTQQlAAAAAAAQbrNy3vn/dsPQ3CJIvyt90zhCSU0EOgAAAAAAjQAA ABAAAAABAAAAAAALcHJpbnRPdXRwdXQAAAAEAAAAAFBzdFNib29sAQAAAABJbnRlZW51bQAAAABJ bnRlAAAAAENscm0AAAAPcHJpbnRTaXh0ZWVuQml0Ym9vbAAAAAALcHJpbnRlck5hbWVURVhUAAAA DABwAHIAdAAtAGkAcgB2AC0AMAA3ADIAAAA4QklNBDsAAAAAAbIAAAAQAAAAAQAAAAAAEnByaW50 T3V0cHV0T3B0aW9ucwAAABIAAAAAQ3B0bmJvb2wAAAAAAENsYnJib29sAAAAAABSZ3NNYm9vbAAA AAAAQ3JuQ2Jvb2wAAAAAAENudENib29sAAAAAABMYmxzYm9vbAAAAAAATmd0dmJvb2wAAAAAAEVt bERib29sAAAAAABJbnRyYm9vbAAAAAAAQmNrZ09iamMAAAABAAAAAAAAUkdCQwAAAAMAAAAAUmQg IGRvdWJAb+AAAAAAAAAAAABHcm4gZG91YkBv4AAAAAAAAAAAAEJsICBkb3ViQG/gAAAAAAAAAAAA QnJkVFVudEYjUmx0AAAAAAAAAAAAAAAAQmxkIFVudEYjUmx0AAAAAAAAAAAAAAAAUnNsdFVudEYj UHhsQFgAAAAAAAAAAAAKdmVjdG9yRGF0YWJvb2wBAAAAAFBnUHNlbnVtAAAAAFBnUHMAAAAAUGdQ QwAAAABMZWZ0VW50RiNSbHQAAAAAAAAAAAAAAABUb3AgVW50RiNSbHQAAAAAAAAAAAAAAABTY2wg VW50RiNQcmNAWQAAAAAAADhCSU0D7QAAAAAAEABgAAAAAQABAGAAAAABAAE4QklNBCYAAAAAAA4A AAAAAAAAAAAAP4AAADhCSU0D8gAAAAAACgAA////////AAA4QklNBA0AAAAAAAQAAABaOEJJTQQZ AAAAAAAEAAAAHjhCSU0D8wAAAAAACQAAAAAAAAAAAQA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAA CgABAAAAAAAAAAE4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAA AAEAMgAAAAEAWgAAAAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAAAHAAAP////// //////////////////////8D6AAAAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAOEJJTQQAAAAA AAACABA4QklNBAIAAAAAACIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOEJJTQQw AAAAAAARAQEBAQEBAQEBAQEBAQEBAQEAOEJJTQQtAAAAAAAGAAEAAAAiOEJJTQQIAAAAAAAQAAAA AQAAAkAAAAJAAAAAADhCSU0EHgAAAAAABAAAAAA4QklNBBoAAAAAA2EAAAAGAAAAAAAAAAAAAAA6 AAABCAAAABYAMwA5ADEAMwAwAF8AZAAwADQALQAyAC4ANwA1AGkAbgBfADkANgBkAHAAaQAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAABCAAAADoAAAAAAAAAAAAAAAAAAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAQAAAAAQAAAAAAAG51bGwAAAACAAAABmJvdW5kc09iamMAAAABAAAAAAAA UmN0MQAAAAQAAAAAVG9wIGxvbmcAAAAAAAAAAExlZnRsb25nAAAAAAAAAABCdG9tbG9uZwAAADoA AAAAUmdodGxvbmcAAAEIAAAABnNsaWNlc1ZsTHMAAAABT2JqYwAAAAEAAAAAAAVzbGljZQAAABIA AAAHc2xpY2VJRGxvbmcAAAAAAAAAB2dyb3VwSURsb25nAAAAAAAAAAZvcmlnaW5lbnVtAAAADEVT bGljZU9yaWdpbgAAAA1hdXRvR2VuZXJhdGVkAAAAAFR5cGVlbnVtAAAACkVTbGljZVR5cGUAAAAA SW1nIAAAAAZib3VuZHNPYmpjAAAAAQAAAAAAAFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABM ZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAA6AAAAAFJnaHRsb25nAAABCAAAAAN1cmxURVhUAAAA AQAAAAAAAG51bGxURVhUAAAAAQAAAAAAAE1zZ2VURVhUAAAAAQAAAAAABmFsdFRhZ1RFWFQAAAAB AAAAAAAOY2VsbFRleHRJc0hUTUxib29sAQAAAAhjZWxsVGV4dFRFWFQAAAABAAAAAAAJaG9yekFs aWduZW51bQAAAA9FU2xpY2VIb3J6QWxpZ24AAAAHZGVmYXVsdAAAAAl2ZXJ0QWxpZ25lbnVtAAAA D0VTbGljZVZlcnRBbGlnbgAAAAdkZWZhdWx0AAAAC2JnQ29sb3JUeXBlZW51bQAAABFFU2xpY2VC R0NvbG9yVHlwZQAAAABOb25lAAAACXRvcE91dHNldGxvbmcAAAAAAAAACmxlZnRPdXRzZXRsb25n AAAAAAAAAAxib3R0b21PdXRzZXRsb25nAAAAAAAAAAtyaWdodE91dHNldGxvbmcAAAAAADhCSU0E KAAAAAAADAAAAAI/8AAAAAAAADhCSU0EFAAAAAAABAAAACY4QklNBAwAAAAAE5EAAAABAAAAoAAA ACMAAAHgAABBoAAAE3UAGAAB/9j/4gxYSUNDX1BST0ZJTEUAAQEAAAxITGlubwIQAABtbnRyUkdC IFhZWiAHzgACAAkABgAxAABhY3NwTVNGVAAAAABJRUMgc1JHQgAAAAAAAAAAAAAAAAAA9tYAAQAA AADTLUhQICAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABFj cHJ0AAABUAAAADNkZXNjAAABhAAAAGx3dHB0AAAB8AAAABRia3B0AAACBAAAABRyWFlaAAACGAAA ABRnWFlaAAACLAAAABRiWFlaAAACQAAAABRkbW5kAAACVAAAAHBkbWRkAAACxAAAAIh2dWVkAAAD TAAAAIZ2aWV3AAAD1AAAACRsdW1pAAAD+AAAABRtZWFzAAAEDAAAACR0ZWNoAAAEMAAAAAxyVFJD AAAEPAAACAxnVFJDAAAEPAAACAxiVFJDAAAEPAAACAx0ZXh0AAAAAENvcHlyaWdodCAoYykgMTk5 OCBIZXdsZXR0LVBhY2thcmQgQ29tcGFueQAAZGVzYwAAAAAAAAASc1JHQiBJRUM2MTk2Ni0yLjEA AAAAAAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAPNRAAEAAAABFsxYWVogAAAAAAAAAAAAAAAA AAAAAFhZWiAAAAAAAABvogAAOPUAAAOQWFlaIAAAAAAAAGKZAAC3hQAAGNpYWVogAAAAAAAAJKAA AA+EAAC2z2Rlc2MAAAAAAAAAFklFQyBodHRwOi8vd3d3LmllYy5jaAAAAAAAAAAAAAAAFklFQyBo dHRwOi8vd3d3LmllYy5jaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABkZXNjAAAAAAAAAC5JRUMgNjE5NjYtMi4xIERlZmF1bHQgUkdCIGNvbG91ciBzcGFjZSAt IHNSR0IAAAAAAAAAAAAAAC5JRUMgNjE5NjYtMi4xIERlZmF1bHQgUkdCIGNvbG91ciBzcGFjZSAt IHNSR0IAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZGVzYwAAAAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcg Q29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAALFJlZmVyZW5jZSBWaWV3aW5nIENv bmRpdGlvbiBpbiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHZpZXcAAAAA ABOk/gAUXy4AEM8UAAPtzAAEEwsAA1yeAAAAAVhZWiAAAAAAAEwJVgBQAAAAVx/nbWVhcwAAAAAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAo8AAAACc2lnIAAAAABDUlQgY3VydgAAAAAAAAQAAAAABQAK AA8AFAAZAB4AIwAoAC0AMgA3ADsAQABFAEoATwBUAFkAXgBjAGgAbQByAHcAfACBAIYAiwCQAJUA mgCfAKQAqQCuALIAtwC8AMEAxgDLANAA1QDbAOAA5QDrAPAA9gD7AQEBBwENARMBGQEfASUBKwEy ATgBPgFFAUwBUgFZAWABZwFuAXUBfAGDAYsBkgGaAaEBqQGxAbkBwQHJAdEB2QHhAekB8gH6AgMC DAIUAh0CJgIvAjgCQQJLAlQCXQJnAnECegKEAo4CmAKiAqwCtgLBAssC1QLgAusC9QMAAwsDFgMh Ay0DOANDA08DWgNmA3IDfgOKA5YDogOuA7oDxwPTA+AD7AP5BAYEEwQgBC0EOwRIBFUEYwRxBH4E jASaBKgEtgTEBNME4QTwBP4FDQUcBSsFOgVJBVgFZwV3BYYFlgWmBbUFxQXVBeUF9gYGBhYGJwY3 BkgGWQZqBnsGjAadBq8GwAbRBuMG9QcHBxkHKwc9B08HYQd0B4YHmQesB78H0gflB/gICwgfCDII RghaCG4IggiWCKoIvgjSCOcI+wkQCSUJOglPCWQJeQmPCaQJugnPCeUJ+woRCicKPQpUCmoKgQqY Cq4KxQrcCvMLCwsiCzkLUQtpC4ALmAuwC8gL4Qv5DBIMKgxDDFwMdQyODKcMwAzZDPMNDQ0mDUAN Wg10DY4NqQ3DDd4N+A4TDi4OSQ5kDn8Omw62DtIO7g8JDyUPQQ9eD3oPlg+zD88P7BAJECYQQxBh EH4QmxC5ENcQ9RETETERTxFtEYwRqhHJEegSBxImEkUSZBKEEqMSwxLjEwMTIxNDE2MTgxOkE8UT 5RQGFCcUSRRqFIsUrRTOFPAVEhU0FVYVeBWbFb0V4BYDFiYWSRZsFo8WshbWFvoXHRdBF2UXiReu F9IX9xgbGEAYZRiKGK8Y1Rj6GSAZRRlrGZEZtxndGgQaKhpRGncanhrFGuwbFBs7G2MbihuyG9oc AhwqHFIcexyjHMwc9R0eHUcdcB2ZHcMd7B4WHkAeah6UHr4e6R8THz4faR+UH78f6iAVIEEgbCCY IMQg8CEcIUghdSGhIc4h+yInIlUigiKvIt0jCiM4I2YjlCPCI/AkHyRNJHwkqyTaJQklOCVoJZcl xyX3JicmVyaHJrcm6CcYJ0kneierJ9woDSg/KHEooijUKQYpOClrKZ0p0CoCKjUqaCqbKs8rAis2 K2krnSvRLAUsOSxuLKIs1y0MLUEtdi2rLeEuFi5MLoIuty7uLyQvWi+RL8cv/jA1MGwwpDDbMRIx SjGCMbox8jIqMmMymzLUMw0zRjN/M7gz8TQrNGU0njTYNRM1TTWHNcI1/TY3NnI2rjbpNyQ3YDec N9c4FDhQOIw4yDkFOUI5fzm8Ofk6Njp0OrI67zstO2s7qjvoPCc8ZTykPOM9Ij1hPaE94D4gPmA+ oD7gPyE/YT+iP+JAI0BkQKZA50EpQWpBrEHuQjBCckK1QvdDOkN9Q8BEA0RHRIpEzkUSRVVFmkXe RiJGZ0arRvBHNUd7R8BIBUhLSJFI10kdSWNJqUnwSjdKfUrESwxLU0uaS+JMKkxyTLpNAk1KTZNN 3E4lTm5Ot08AT0lPk0/dUCdQcVC7UQZRUFGbUeZSMVJ8UsdTE1NfU6pT9lRCVI9U21UoVXVVwlYP VlxWqVb3V0RXklfgWC9YfVjLWRpZaVm4WgdaVlqmWvVbRVuVW+VcNVyGXNZdJ114XcleGl5sXr1f D19hX7NgBWBXYKpg/GFPYaJh9WJJYpxi8GNDY5dj62RAZJRk6WU9ZZJl52Y9ZpJm6Gc9Z5Nn6Wg/ aJZo7GlDaZpp8WpIap9q92tPa6dr/2xXbK9tCG1gbbluEm5rbsRvHm94b9FwK3CGcOBxOnGVcfBy S3KmcwFzXXO4dBR0cHTMdSh1hXXhdj52m3b4d1Z3s3gReG54zHkqeYl553pGeqV7BHtje8J8IXyB fOF9QX2hfgF+Yn7CfyN/hH/lgEeAqIEKgWuBzYIwgpKC9INXg7qEHYSAhOOFR4Wrhg6GcobXhzuH n4gEiGmIzokziZmJ/opkisqLMIuWi/yMY4zKjTGNmI3/jmaOzo82j56QBpBukNaRP5GokhGSepLj k02TtpQglIqU9JVflcmWNJaflwqXdZfgmEyYuJkkmZCZ/JpomtWbQpuvnByciZz3nWSd0p5Anq6f HZ+Ln/qgaaDYoUehtqImopajBqN2o+akVqTHpTilqaYapoum/adup+CoUqjEqTepqaocqo+rAqt1 q+msXKzQrUStuK4trqGvFq+LsACwdbDqsWCx1rJLssKzOLOutCW0nLUTtYq2AbZ5tvC3aLfguFm4 0blKucK6O7q1uy67p7whvJu9Fb2Pvgq+hL7/v3q/9cBwwOzBZ8Hjwl/C28NYw9TEUcTOxUvFyMZG xsPHQce/yD3IvMk6ybnKOMq3yzbLtsw1zLXNNc21zjbOts83z7jQOdC60TzRvtI/0sHTRNPG1EnU y9VO1dHWVdbY11zX4Nhk2OjZbNnx2nba+9uA3AXcit0Q3ZbeHN6i3ynfr+A24L3hROHM4lPi2+Nj 4+vkc+T85YTmDeaW5x/nqegy6LzpRunQ6lvq5etw6/vshu0R7ZzuKO6070DvzPBY8OXxcvH/8ozz GfOn9DT0wvVQ9d72bfb794r4Gfio+Tj5x/pX+uf7d/wH/Jj9Kf26/kv+3P9t////7QAMQWRvYmVf Q00AAf/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACMAoAMBIgACEQED EQH/3QAEAAr/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APUXtbyQPiTCGXAH2vA8w8/kcHNRnmBMho8Xf6hD3OPDnu+AAH/TH/fklKbc4AFw3NPcR/e5n/SQ MXrHTMvNvwcbIbZlYv8AP1CZbrtOpG1+x3ss2fzf+ERtjtwO109yQ3/vha5cR9WnlnWcTOaId1Vu eSfHbd6uv/babKVGI7/+i/8AdNnl+Xjkx5pkkHHG4V+/wzy+r/qeHI98kgsyAdH+0+PZF5Tmsukk kkpSi94bzqTw0clRNknbWN7vHsP6zkOZBeHafn2/98qSUu5zzMmI+lBhrf6z/pOcofpJG1zg48Dk keOx/wBBv9dSg+0BuvNdfh/wliWkGfc0mHHu937jf5CSmPr5DIkNsaeCJbP/AFX+f/NqTcuRrW4e Ygj8oThhc4hxk/4U9v5NQ/kp30kas4/d/wDIpKZNvY7sW/EKfKqgxI7jt/rt/wBf9F/OKbbC0/Ht /r+d/q9JTYSTAhwBGoPCdJSkkxcAYnXwSSU//9DuPrn1bK6N9W87qWG0faqWtbQ4gOIfY9lAcGGd 2z1PUXAu+vH15NTnMcXMxpf9o+yNFd1dl9WHhWO3uY59NznW/pMFvq/8D+jsuXpXU+n9Ty7GfZOp PwadpbbWypj3Ok/SZbb7qXbf3FT/AOaOFW31cXJyqeoCD9vNz7LHOHH2iux32e5n+kq9JAk9B+LN DHiMQZ5uEn9GMJT4f9qf1f8A417zxVf16+sPrWP9IZGReLsZ/S2YdkYWU1xqwq35LW225tl9TLcz Jp/0VNnpMVTH+snWrX9Io6ZTQzPxsYmnC+yPJflvyrsTMqn2NwKXYtX2zJte+n0//PPd39M+tfUN mHn5eNTgh4N12J6rMi1jf8G7cfTp9b/Cem9a/VcA9R6fdhtufjOtHsuqJDmuB3Md7S3c3cPezd70 Lu/TttaTAQMY+8KmfX7fFKMIfJxS+Xj9E8no/wC/fOm/XXr7qMrO9VtRY/0szAswrS3pbfW+zsyL 8xjf121lH6e2iz/rdP6OxirWfXr654Wwek7Kx213mvLGN6RyWWDIHSs+2ghv2Zu/Esv9L9H6uKu5 ZgfW7KY3Fz83HxscACzIwg/7TYB7fp3D0sZz/wDSVM/4tKz6p49B9fpeTk4OVO51zLXWb3f92acl z6sj/wADS4j0j9uiThxR0lnjxHb24yyY/wDqk/Rw/wCBDKk+q/VL+odDxbsu825ra2DMJYKoucxm S6vZZXW32VZFX81+jWmXA/ScHf1nT/0Kxtcq2BTnUUmvNzDnXFxItNbaSGwP0fpVOr/O9+5WpPEO +94/76nD7GCQAJAkJAfpR4uGX+PwSXIJGo3NHY+xg/s/SSkn3TuI/POjG/1R+d/r+kTRrMa9iWuc f856TtCC7nsbCP8Ao1sSQrSCZIY76Tz9J5/danh24QAHx7W9mN8f6ydrXuMiZ/0j+39RiIxgaIHf Uk8k+aSlNaGNDR2UkkklMX1sf9IT4Hg/egHFePoWfJ4B/JtVlJJTUDsmk+9ssPLmy6P5X7yI1+8T ukHgzp/0dn/VI6G6lu7cz2uPMcH4hJSzY+HkIH/Uypgx8PuUfcOfwn+9Pr2B+6P+qSU//9H1VJfK qSSn6qSXyqkkp+qkl8qpJKfqez6B+j/a4QmbZ12/9bn/AL6vl1JJT9Rv2dv+nuhPRyf5v+x/35fL aSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKf/2QA4QklNBCEAAAAAAFUAAAAB AQAAAA8AQQBkAG8AYgBlACAAUABoAG8AdABvAHMAaABvAHAAAAATAEEAZABvAGIAZQAgAFAAaABv AHQAbwBzAGgAbwBwACAAQwBTADUAAAABADhCSU0PoAAAAAABHG1hbmlJUkZSAAABEDhCSU1BbkRz AAAA8AAAABAAAAABAAAAAAAAbnVsbAAAAAMAAAAAQUZTdGxvbmcAAAAAAAAAAEZySW5WbExzAAAA AU9iamMAAAABAAAAAAAAbnVsbAAAAAMAAAAARnJJRGxvbmd4CbGJAAAAAEZyRGxsb25nAAAD6AAA AABGckdBZG91YkBWgAAAAAAAAAAAAEZTdHNWbExzAAAAAU9iamMAAAABAAAAAAAAbnVsbAAAAAQA AAAARnNJRGxvbmcAAAAAAAAAAEFGcm1sb25nAAAAAAAAAABGc0ZyVmxMcwAAAAFsb25neAmxiQAA AABMQ250bG9uZwAAAAEAADhCSU1Sb2xsAAAACAAAAAAAAAAAOEJJTQ+hAAAAAAAcbWZyaQAAAAIA AAAQAAAAAQAAAAAAAAABAAAAADhCSU0EBgAAAAAABwAIAAAAAQEA/+EmSGh0dHA6Ly9ucy5hZG9i ZS5jb20veGFwLzEuMC8APD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6 TlRjemtjOWQiPz4gPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0i QWRvYmUgWE1QIENvcmUgNS4wLWMwNjAgNjEuMTM0Nzc3LCAyMDEwLzAyLzEyLTE3OjMyOjAwICAg ICAgICAiPiA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjIt cmRmLXN5bnRheC1ucyMiPiA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4bXA9 Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcv ZGMvZWxlbWVudHMvMS4xLyIgeG1sbnM6eG1wTU09Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEu MC9tbS8iIHhtbG5zOnN0RXZ0PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvc1R5cGUvUmVz b3VyY2VFdmVudCMiIHhtbG5zOnN0UmVmPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvc1R5 cGUvUmVzb3VyY2VSZWYjIiB4bWxuczpwaG90b3Nob3A9Imh0dHA6Ly9ucy5hZG9iZS5jb20vcGhv dG9zaG9wLzEuMC8iIHhtbG5zOnhtcFJpZ2h0cz0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4w L3JpZ2h0cy8iIHhtbG5zOkV4dGVuc2lzRm9udFNlbnNlPSJodHRwOi8vd3d3LmV4dGVuc2lzLmNv bS9tZXRhL0ZvbnRTZW5zZS8iIHhtcDpDcmVhdG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIENTNSBN YWNpbnRvc2giIHhtcDpDcmVhdGVEYXRlPSIyMDEyLTA2LTEyVDE3OjAyOjQ4LTA3OjAwIiB4bXA6 TWV0YWRhdGFEYXRlPSIyMDEyLTA2LTE1VDE2OjE2OjQ4LTA3OjAwIiB4bXA6TW9kaWZ5RGF0ZT0i MjAxMi0wNi0xNVQxNjoxNjo0OC0wNzowMCIgZGM6Zm9ybWF0PSJpbWFnZS9qcGVnIiB4bXBNTTpJ bnN0YW5jZUlEPSJ4bXAuaWlkOkE2NzIxMzBCMzAyMDY4MTE5N0E1QzA4QzdBOUMwODY3IiB4bXBN TTpEb2N1bWVudElEPSJ4bXAuZGlkOkUxNkY4NzM3MzUyMDY4MTE5NDU3RDEzMkQxRDVFMkU3IiB4 bXBNTTpPcmlnaW5hbERvY3VtZW50SUQ9InhtcC5kaWQ6RTM2Rjg3MzczNTIwNjgxMTk0NTdEMTMy RDFENUUyRTciIHBob3Rvc2hvcDpDb2xvck1vZGU9IjMiIHBob3Rvc2hvcDpJQ0NQcm9maWxlPSJz UkdCIElFQzYxOTY2LTIuMSIgeG1wUmlnaHRzOk1hcmtlZD0iRmFsc2UiPiA8eG1wTU06SGlzdG9y eT4gPHJkZjpTZXE+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJjcmVhdGVkIiBzdEV2dDppbnN0YW5j ZUlEPSJ4bXAuaWlkOkUzNkY4NzM3MzUyMDY4MTE5NDU3RDEzMkQxRDVFMkU3IiBzdEV2dDp3aGVu PSIyMDEyLTA2LTEyVDE3OjAyOjQ4LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBQ aG90b3Nob3AgQ1M1IE1hY2ludG9zaCIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0 RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6RTQ2Rjg3MzczNTIwNjgxMTk0NTdEMTMyRDFENUUyRTci IHN0RXZ0OndoZW49IjIwMTItMDYtMTJUMTc6MDM6MjMtMDc6MDAiIHN0RXZ0OnNvZnR3YXJlQWdl bnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgTWFjaW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDxy ZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDpFNTZG ODczNzM1MjA2ODExOTQ1N0QxMzJEMUQ1RTJFNyIgc3RFdnQ6d2hlbj0iMjAxMi0wNi0xMlQxNzow NjoxMy0wNzowMCIgc3RFdnQ6c29mdHdhcmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNp bnRvc2giIHN0RXZ0OmNoYW5nZWQ9Ii8iLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249InNhdmVkIiBz dEV2dDppbnN0YW5jZUlEPSJ4bXAuaWlkOkU2NkY4NzM3MzUyMDY4MTE5NDU3RDEzMkQxRDVFMkU3 IiBzdEV2dDp3aGVuPSIyMDEyLTA2LTEyVDE3OjA3OjE5LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFn ZW50PSJBZG9iZSBQaG90b3Nob3AgQ1M1IE1hY2ludG9zaCIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8 cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6RTc2 Rjg3MzczNTIwNjgxMTk0NTdEMTMyRDFENUUyRTciIHN0RXZ0OndoZW49IjIwMTItMDYtMTJUMTc6 MDk6NTAtMDc6MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgTWFj aW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIg c3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDowMTgwMTE3NDA3MjA2ODExQjFBNENFMDczQzY3M0Q2 MCIgc3RFdnQ6d2hlbj0iMjAxMi0wNi0xM1QwOTozMjoyNS0wNzowMCIgc3RFdnQ6c29mdHdhcmVB Z2VudD0iQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2giIHN0RXZ0OmNoYW5nZWQ9Ii8iLz4g PHJkZjpsaSBzdEV2dDphY3Rpb249InNhdmVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAuaWlkOjAy ODAxMTc0MDcyMDY4MTFCMUE0Q0UwNzNDNjczRDYwIiBzdEV2dDp3aGVuPSIyMDEyLTA2LTEzVDA5 OjQ3OjQ5LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBQaG90b3Nob3AgQ1M1IE1h Y2ludG9zaCIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQi IHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6MDM4MDExNzQwNzIwNjgxMUIxQTRDRTA3M0M2NzNE NjAiIHN0RXZ0OndoZW49IjIwMTItMDYtMTNUMDk6NTE6MTctMDc6MDAiIHN0RXZ0OnNvZnR3YXJl QWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgTWFjaW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIvIi8+ IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDpE ODJERkUyQTE1MjA2ODExQjFBNENFMDczQzY3M0Q2MCIgc3RFdnQ6d2hlbj0iMjAxMi0wNi0xM1Qx MToxMDozNS0wNzowMCIgc3RFdnQ6c29mdHdhcmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9wIENTNSBN YWNpbnRvc2giIHN0RXZ0OmNoYW5nZWQ9Ii8iLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249InNhdmVk IiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAuaWlkOjA2RkU2QzkyMUQyMDY4MTE4RjYyRUFGRTIwMjBF M0M2IiBzdEV2dDp3aGVuPSIyMDEyLTA2LTE0VDExOjU3OjIwLTA3OjAwIiBzdEV2dDpzb2Z0d2Fy ZUFnZW50PSJBZG9iZSBQaG90b3Nob3AgQ1M1IE1hY2ludG9zaCIgc3RFdnQ6Y2hhbmdlZD0iLyIv PiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6 MDdGRTZDOTIxRDIwNjgxMThGNjJFQUZFMjAyMEUzQzYiIHN0RXZ0OndoZW49IjIwMTItMDYtMTRU MTE6NTc6MjAtMDc6MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUg TWFjaW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZl ZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDowOEZFNkM5MjFEMjA2ODExOEY2MkVBRkUyMDIw RTNDNiIgc3RFdnQ6d2hlbj0iMjAxMi0wNi0xNFQxMTo1ODoyNi0wNzowMCIgc3RFdnQ6c29mdHdh cmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2giIHN0RXZ0OmNoYW5nZWQ9Ii8i Lz4gPHJkZjpsaSBzdEV2dDphY3Rpb249InNhdmVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAuaWlk OjA5RkU2QzkyMUQyMDY4MTE4RjYyRUFGRTIwMjBFM0M2IiBzdEV2dDp3aGVuPSIyMDEyLTA2LTE0 VDExOjU5OjA5LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBQaG90b3Nob3AgQ1M1 IE1hY2ludG9zaCIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2 ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6MEFGRTZDOTIxRDIwNjgxMThGNjJFQUZFMjAy MEUzQzYiIHN0RXZ0OndoZW49IjIwMTItMDYtMTRUMTE6NTk6MjctMDc6MDAiIHN0RXZ0OnNvZnR3 YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgTWFjaW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIv Ii8+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlp ZDozMUM2OTQxQTJBMjA2ODExOEY2MkVBRkUyMDIwRTNDNiIgc3RFdnQ6d2hlbj0iMjAxMi0wNi0x NFQxNToyNjoxOC0wNzowMCIgc3RFdnQ6c29mdHdhcmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9wIENT NSBNYWNpbnRvc2giIHN0RXZ0OmNoYW5nZWQ9Ii8iLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249InNh dmVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAuaWlkOkYzMTUzRDIzMTkyMDY4MTE5N0E1QzA4QzdB OUMwODY3IiBzdEV2dDp3aGVuPSIyMDEyLTA2LTE1VDEyOjE4OjI0LTA3OjAwIiBzdEV2dDpzb2Z0 d2FyZUFnZW50PSJBZG9iZSBQaG90b3Nob3AgQ1M1IE1hY2ludG9zaCIgc3RFdnQ6Y2hhbmdlZD0i LyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5p aWQ6RjQxNTNEMjMxOTIwNjgxMTk3QTVDMDhDN0E5QzA4NjciIHN0RXZ0OndoZW49IjIwMTItMDYt MTVUMTI6MTg6MjQtMDc6MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBD UzUgTWFjaW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJz YXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDowRTQ2QzEwRDFGMjA2ODExOTdBNUMwOEM3 QTlDMDg2NyIgc3RFdnQ6d2hlbj0iMjAxMi0wNi0xNVQxNDozMDoxOC0wNzowMCIgc3RFdnQ6c29m dHdhcmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2giIHN0RXZ0OmNoYW5nZWQ9 Ii8iLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249InNhdmVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAu aWlkOjBGNDZDMTBEMUYyMDY4MTE5N0E1QzA4QzdBOUMwODY3IiBzdEV2dDp3aGVuPSIyMDEyLTA2 LTE1VDE0OjMwOjE4LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBQaG90b3Nob3Ag Q1M1IE1hY2ludG9zaCIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0i c2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6QTQ3MjEzMEIzMDIwNjgxMTk3QTVDMDhD N0E5QzA4NjciIHN0RXZ0OndoZW49IjIwMTItMDYtMTVUMTY6MTE6NDUtMDc6MDAiIHN0RXZ0OnNv ZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgTWFjaW50b3NoIiBzdEV2dDpjaGFuZ2Vk PSIvIi8+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1w LmlpZDpBNTcyMTMwQjMwMjA2ODExOTdBNUMwOEM3QTlDMDg2NyIgc3RFdnQ6d2hlbj0iMjAxMi0w Ni0xNVQxNjoxNjo0OC0wNzowMCIgc3RFdnQ6c29mdHdhcmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9w IENTNSBNYWNpbnRvc2giIHN0RXZ0OmNoYW5nZWQ9Ii8iLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249 ImNvbnZlcnRlZCIgc3RFdnQ6cGFyYW1ldGVycz0iZnJvbSBhcHBsaWNhdGlvbi92bmQuYWRvYmUu cGhvdG9zaG9wIHRvIGltYWdlL2pwZWciLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249ImRlcml2ZWQi IHN0RXZ0OnBhcmFtZXRlcnM9ImNvbnZlcnRlZCBmcm9tIGFwcGxpY2F0aW9uL3ZuZC5hZG9iZS5w aG90b3Nob3AgdG8gaW1hZ2UvanBlZyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0 RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6QTY3MjEzMEIzMDIwNjgxMTk3QTVDMDhDN0E5QzA4Njci IHN0RXZ0OndoZW49IjIwMTItMDYtMTVUMTY6MTY6NDgtMDc6MDAiIHN0RXZ0OnNvZnR3YXJlQWdl bnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgTWFjaW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDwv cmRmOlNlcT4gPC94bXBNTTpIaXN0b3J5PiA8eG1wTU06RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFu Y2VJRD0ieG1wLmlpZDpBNTcyMTMwQjMwMjA2ODExOTdBNUMwOEM3QTlDMDg2NyIgc3RSZWY6ZG9j dW1lbnRJRD0ieG1wLmRpZDpFMTZGODczNzM1MjA2ODExOTQ1N0QxMzJEMUQ1RTJFNyIgc3RSZWY6 b3JpZ2luYWxEb2N1bWVudElEPSJ4bXAuZGlkOkUzNkY4NzM3MzUyMDY4MTE5NDU3RDEzMkQxRDVF MkU3Ii8+IDxwaG90b3Nob3A6VGV4dExheWVycz4gPHJkZjpCYWc+IDxyZGY6bGkgcGhvdG9zaG9w OkxheWVyTmFtZT0iRm9sbG93IEJyb2FkY29tIG9uIFR3aXR0ZXIsIEZhY2Vib29rLCBHb29nbGUr LCBMaW5rZWRJbiBhbmQgWW91IiBwaG90b3Nob3A6TGF5ZXJUZXh0PSJGb2xsb3cgQnJvYWRjb20g b24gVHdpdHRlciwgRmFjZWJvb2ssIEdvb2dsZSssIExpbmtlZEluIGFuZCBZb3VUdWJlIFN0YXkg Q29ubmVjdGVkOiBSZWFkIHRoZSBCcm9hZGNvbSBDb25uZWN0ZWQgQmxvZyIvPiA8cmRmOmxpIHBo b3Rvc2hvcDpMYXllck5hbWU9IlRBTEVOVCBBQ1FVSVNJVElPTiIgcGhvdG9zaG9wOkxheWVyVGV4 dD0iVEFMRU5UIEFDUVVJU0lUSU9OIi8+IDwvcmRmOkJhZz4gPC9waG90b3Nob3A6VGV4dExheWVy cz4gPEV4dGVuc2lzRm9udFNlbnNlOnNsdWc+IDxyZGY6QmFnPiA8cmRmOmxpIEV4dGVuc2lzRm9u dFNlbnNlOkZvbnRTZW5zZV8xLjJfQ2hlY2tzdW09IjIxNjk2MTE2MDMiIEV4dGVuc2lzRm9udFNl bnNlOlZlcnNpb249IjUuMDEuMiIgRXh0ZW5zaXNGb250U2Vuc2U6RmFtaWx5PSJBcmlhbCIgRXh0 ZW5zaXNGb250U2Vuc2U6T3V0bGluZUZpbGVTaXplPSIwIiBFeHRlbnNpc0ZvbnRTZW5zZTpLZXJu aW5nQ2hlY2tzdW09IjAiIEV4dGVuc2lzRm9udFNlbnNlOkZvdW5kcnk9Ik1vbm90eXBlIFR5cG9n cmFwaHkiIEV4dGVuc2lzRm9udFNlbnNlOkZvbnRLaW5kPSJPcGVuVHlwZSAtIFRUIiBFeHRlbnNp c0ZvbnRTZW5zZTpDaGVja3N1bT0iMjE2OTYxMTYwMyIgRXh0ZW5zaXNGb250U2Vuc2U6UG9zdFNj cmlwdE5hbWU9IkFyaWFsTVQiLz4gPHJkZjpsaSBFeHRlbnNpc0ZvbnRTZW5zZTpGb250U2Vuc2Vf MS4yX0NoZWNrc3VtPSIyMzY3MTYxNzI2IiBFeHRlbnNpc0ZvbnRTZW5zZTpWZXJzaW9uPSIwMDEu MDA2IiBFeHRlbnNpc0ZvbnRTZW5zZTpGYW1pbHk9IkhlbHZldGljYSIgRXh0ZW5zaXNGb250U2Vu c2U6T3V0bGluZUZpbGVTaXplPSIyOTc1MyIgRXh0ZW5zaXNGb250U2Vuc2U6S2VybmluZ0NoZWNr c3VtPSIxMzg5MzQiIEV4dGVuc2lzRm9udFNlbnNlOkZvdW5kcnk9IkFkb2JlIFN5c3RlbXMiIEV4 dGVuc2lzRm9udFNlbnNlOkZvbnRLaW5kPSJQb3N0U2NyaXB0IiBFeHRlbnNpc0ZvbnRTZW5zZTpD aGVja3N1bT0iMjM2NzE2MTcyNiIgRXh0ZW5zaXNGb250U2Vuc2U6UG9zdFNjcmlwdE5hbWU9Ikhl bHZldGljYSIvPiA8cmRmOmxpIEV4dGVuc2lzRm9udFNlbnNlOkZvbnRTZW5zZV8xLjJfQ2hlY2tz dW09IjE1NTIyNjEyNzEiIEV4dGVuc2lzRm9udFNlbnNlOlZlcnNpb249IjUuMDEuMiIgRXh0ZW5z aXNGb250U2Vuc2U6RmFtaWx5PSJBcmlhbCIgRXh0ZW5zaXNGb250U2Vuc2U6T3V0bGluZUZpbGVT aXplPSIwIiBFeHRlbnNpc0ZvbnRTZW5zZTpLZXJuaW5nQ2hlY2tzdW09IjAiIEV4dGVuc2lzRm9u dFNlbnNlOkZvdW5kcnk9Ik1vbm90eXBlIFR5cG9ncmFwaHkiIEV4dGVuc2lzRm9udFNlbnNlOkZv bnRLaW5kPSJPcGVuVHlwZSAtIFRUIiBFeHRlbnNpc0ZvbnRTZW5zZTpDaGVja3N1bT0iMTU1MjI2 MTI3MSIgRXh0ZW5zaXNGb250U2Vuc2U6UG9zdFNjcmlwdE5hbWU9IkFyaWFsLUJvbGRNVCIvPiA8 L3JkZjpCYWc+IDwvRXh0ZW5zaXNGb250U2Vuc2U6c2x1Zz4gPC9yZGY6RGVzY3JpcHRpb24+IDwv cmRmOlJERj4gPC94OnhtcG1ldGE+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPD94cGFja2V0IGVuZD0idyI/Pv/iDFhJQ0NfUFJPRklMRQABAQAA DEhMaW5vAhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAA AAAAAAAAAAABAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQA AAIEAAAAFHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRt ZGQAAALEAAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAA JHRlY2gAAAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAA Q29weXJpZ2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJz UkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEW zFhZWiAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeF AAAY2lhZWiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNo AAAAAAAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBS R0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBS R0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxS ZWZlcmVuY2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVm ZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlW AFAAAABXH+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBj dXJ2AAAAAAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABt AHIAdwB8AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsB AQEHAQ0BEwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHB AckB0QHZAeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsEC ywLVAuAC6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQT BCAELQQ7BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYF tQXFBdUF5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZ B6wHvwfSB+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J 5Qn7ChEKJwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1 DI4MpwzADNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14P eg+WD7MPzw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLD EuMTAxMjE0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwW jxayFtYW+hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqe GsUa7BsUGzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMf Ph9pH5Qfvx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQf JE0kfCSrJNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWsp nSnQKgIqNSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9a L5Evxy/+MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1 wjX9Njc2cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8Jzxl PKQ84z0iPWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31D wEQDREdEikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtT S5pL4kwqTHJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19T qlP2VEJUj1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1 XIZc1l0nXXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1l kmXnZj1mkmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8e b3hv0XArcIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5 iXnnekZ6pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQd hICE44VHhauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaP npAGkG6Q1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtC m6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n 4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSc tRO1irYBtnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePC X8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA5 0LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLf Kd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o 7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+ S/7c/23////uAA5BZG9iZQBkQAAAAAH/2wCEAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQECAgICAgICAgICAgMDAwMDAwMDAwMBAQEBAQEBAQEBAQICAQICAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA//AABEIADoBCAMBEQAC EQEDEQH/3QAEACH/xAGiAAAABgIDAQAAAAAAAAAAAAAHCAYFBAkDCgIBAAsBAAAGAwEBAQAAAAAA AAAAAAYFBAMHAggBCQAKCxAAAgEDBAEDAwIDAwMCBgl1AQIDBBEFEgYhBxMiAAgxFEEyIxUJUUIW YSQzF1JxgRhikSVDobHwJjRyChnB0TUn4VM2gvGSokRUc0VGN0djKFVWVxqywtLi8mSDdJOEZaOz w9PjKThm83UqOTpISUpYWVpnaGlqdnd4eXqFhoeIiYqUlZaXmJmapKWmp6ipqrS1tre4ubrExcbH yMnK1NXW19jZ2uTl5ufo6er09fb3+Pn6EQACAQMCBAQDBQQEBAYGBW0BAgMRBCESBTEGACITQVEH MmEUcQhCgSORFVKhYhYzCbEkwdFDcvAX4YI0JZJTGGNE8aKyJjUZVDZFZCcKc4OTRnTC0uLyVWV1 VjeEhaOzw9Pj8ykalKS0xNTk9JWltcXV5fUoR1dmOHaGlqa2xtbm9md3h5ent8fX5/dIWGh4iJio uMjY6Pg5SVlpeYmZqbnJ2en5KjpKWmp6ipqqusra6vr/2gAMAwEAAhEDEQA/AN92txOPlvLU1mVp wOSYdwZqiQcAcJT5CKPm30t9f8T7917pNSxbeR3EWf3RG4AuabMbkrlQG3KiZq6FtVvqQfrx73+X WvzPUH+NU9I1qbsanRg2kQ7vx+PSEsCF8SSwRbYqbliAC0kjBj+f0+/fl178+nyDceTgiWbJYday iI/4u+1ak52jItq1y0CxQZaO4/swx1QH5b8+/U69XpR47KY7L0/3WMraetg1FGaCQMYpB+qKePiS CdDwyOFdTwQD711vqf7917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v 3XumrLZqgw0UT1kjtNUuYaKiponqa+vnA1eCio4g01RIByxA0ovqYqoJ9+690mchlM4lOa7J1uP2 djmdY4YniXN5+oke/jhjWORsfFWyW9NPDFkGc/pb8e99az0nq6o3XFRyZBdwZXB46IkjIbrk2nRy zFwBCq4eg2hU1BSSThY5J6epP0K6jYbx6dez69R03bvnF0hravF0GcxUektlq4RbFDKSwGiPNV88 0zPYaNVLTh7/AOt79QevXqnrJRd07Zey5nHbg29IqxNO+Qxc0tJEKjV9u/no/PKYZ9J0MYlDWNuB f37T17UOlrjt9bOywH2G5cNMxAIieuhp57EXv9vUtDPx+fTx+feqH069UdKlHSRVeN1dGF1dGDKw P0KspII96631y9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//Q39JG 0DUI3kYDhUC6j/gC7Igv/iQPfuvdM09TuJiRRYnGov4kyOYmif8A2EFFi65W4HN5Vtf8/T3vHXs9 RCN4sSGTa7RE2aMtlCWQ/VC5jK3K8X0W/wAPx79jrWek5Pg6tJmqpNmUENSeWyGy9xNjMrIeCTIJ 6TbkUxB40y1MiMPrwSvv1fn178uk1Uhkr45xPVnM+mGmfJQw7R3kwtZYKXLeBdrbwVQCFp5UMZIu XJ97691q9d//AM5/5e9b/NnfGOwWdwyfG/pfuqHqjdmxp9gbaCbiotv5nLYTcdRmtySY3Kbyxu6M 2Nt5WemOOr4qOFqVNNPKius0W7jzbudvvVwsTD93QzaCukGtCQatTVU0YihpjgfPtr7T/cM9lua/ u68q3W92Nw3u7zBy6dyt7v6qdGhaeKKaBY7ZZVtGhh+oto5hNEzsZG/UjLJ4e3jFLFPFHNBJHNDK iyRSxOskUsbgMkkciEo6OpuCCQR7lDriX1k9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173 7r3Sey+caknjxWLgXJZ6qj8kFDrKQUlPrWNsjlZ1VzR0ERbjgyTMNEasb231qvTGVh25Mksvk3Lv bMxiKMeiKaWJGBkjp1PkjwW26F21OeRexYyzsNXuP2de/wAPXGSNMHNS5LL33HvLJa6bGUdMBHHD qCtUUuGgmLR4zF0y2apq5PWygGRiTHGPf4Ovf4esdRH/AAqWkyeaVdw7xrmaLB4qnJWjopjGPNFi IZtS0VHTI16rISjylP1EAxw+/de/w9YqiB6Cto5K1YNz76rleXHUzBo8TgYNQWarpoW8v8LxVGTp apYNWVb2QMSQie/wde/w9M+Z25DlaxcV5DnN5eOCrrNyVRZKTalOzjx/aUEMnhgWoDP4KDk1SgtU u6gs3v8AB1qn7egprtmU82QbGiGlrBBWPjTm55Xhx+UrKWqp6gY3bry00mNwWZEc8sD0kzyYwyR+ ONC2sRWr1qnWel2ZiqBJJoZq2mWjlaCqrJarIYpMfUTHUtPuShopWqtsV9iBHXItZjJEs3jVSp9+ r1ug6VVHQ5ajm8cOa3RFPTx/cyUL5WurapKZrWr2xcde9LuTHMbXqcbNGUBCml1XUe/Ide6EHF5/ JoKYTVEGShqgBSSySU/jyJF7pjcxTw0lK9WoBH2tVT082oEa2sW91630uKKvp65HaFmDxN46inlU xVFNLa5iqIW9Ub2Nx+GHKkgg+9db6me/de697917r3v3Xuve/de697917r3v3Xuve/de6//R38Zm nAtTxxu/4aaQxxj/AF9CSOf9YD/Y+/de6ZZcXmaxj9zuGejiP+6MNRUdMSP9S9VkI8pUH/g0fiJ/ w+nvf5de6TFVHsinleCu3Fkq+tU/uUq7t3BXVge9uMVjMkwidibAJApP0H9Pfs+nWsevXCT+60h8 kFBvsk3Xy0VN2JQFdNiGjYGj1I4P6kurjgkj37Py691DrKigFPJA+fzVPSSJolx++trZCtwcikD0 TVeRxeNqZLagGb751H1IPvf5de60Icnt6Tsj4kfMDvxaN3GV+ZfT2ZFfFQ414qenyOC+Qk9XSLVz LDm8ZDV1PY9G7RIggqWhiLqGgGmC2T6nad4v6ZN5Ga/aJa/POsV/L06+m2y3Icn++vsD7YiTTHb+ 326waO+haObYghNCyEom3yhSSdIdxq7xXdU+NXYGVy/RvSW9qGV2h3t0/wBb71mxtVRSwRVUO4tm 4XNTZD+G0lLGyQMtaXavxMGhS16ugjfUVmjb5fqLCxn/AI4Ub9qg/L1+XXzn+62yf1Z90fcnlzTT 937/ALhbU9PAu5oqfE/8PHU3+mPHo2+D3di814IS32GQqIjNDRVMsLisiXhqjFVtPJLQ5elUjl6e R9H0cI11CunQCr0qveut9e9+691737r3Xvfuvde9+6910zKqlmIVVBZmYgKqgXJJPAAHv3Xuke+d rc4zUu0xG9OGaOp3PURmTFU9rqwxMd0/jlWtuGQikQ/qkYgxndKcetceHUYS0+BeXB7egbNbnrSl VkKismLsjygIuW3LkI0JghEY/ZgRQzqvjgRUF09x48OvfZx69+1tgFI/LuHeWcCli5EdTXvD6fLL pEkeG27jWlPAHjiDWUSTP6/cfs69w+3rohdtWrKstuHeecH2sEcVonqjGTL9lQRsXTE7fxxfXLIb hV9cjSSsur3H7OvcPt69b+7aHI5AjObyzzLSU0MF4/uJB+5HisWjhzj8FjtXkmlYcKDNKS5A9+/w de4fb1xZanbtOEjaLL723NLp8r+Radp4lZmkKFnkpNubfhlJVAQSLC5mmJb3H7Ovf4esc1HJjoqf aWGqpmzGY8uSz2cfT95DRyMIsjmpWAKJkK6QCnoktojt6R44Cvv3zPXvl0rkw2LTFLhPsaZ8UtMt J9jJGstO0CgemRJA3kJI1Fmuxb1E3596630gsttnJYx46vHyV2Rp6WMxUtTTtHLufEUty7UeurPg 3bgxzejqyahRzG8kmm1q9a6SUE0Jip4o4qc05qiKWlpKh6DHjJj9b7VyNS0dZszcim5bE1pSGViU RrF3b3WunSOrDGdnkpZXq5hR1j1sBoMdl6z06cZurH6NW2t02t4axUWGdtNrgpGPdb6dYK4pJHIt VPSzQSpj6bIZIEVWNrG8bJtvdyKf8opakkfa1l2D6gVcsVeXXXuhAxWUTJwyaonpa2kk+2yNBKbz UVWEVzGWsBLDIjh4pV9MsbBh/Qa6306e/de697917r3v3Xuve/de6wLUwyO0cciysps4jOsIf6Oy 3VD/AIEg+/de6z+/de6//9LfqqVyEoKUklNSA/WomjaqkA/OinWSCPV/Qs5A/wBSfz7r3VePye/m Nfy7fh72HQ9V/Lz5a9c9adj5TauN3vR7K7CzmRhnn2rlslmcRjcz/AMJjJMOKOtyO36yKMTxtMRA SfSQzbr1qnQb77/nY/ypepKDYkuV+ZHQ9Fiuyto/372DX4rdGPfb+49oruTcezJM/jq/HRzQTY+n 3ds/K4uUxJI8WQxtTTsokglVPfn178ulxu3+a98D9ndBbe+Ue5fmf8WdvdC7vy2V2/tPf9H2EN+R bm3HgoYajO7XwGC26KHcma3ZgKaqilyGKpKSauoklQzRoro59jreep2Q+efxp7Y+E/bfyu6p+Xvx 0zXRW3trbsw2X7qlfJUmwtnbnkoYsRQYvesv8Yy+c2nkkzG4MarUtTi6ivKVkLR0c/nhSRmdXeCZ IqeIUIFeFSMVwcV+R+zo75YvNu27mTl7cN5SRtogvoJJxGA0hhSVGlEal4gXKBgoMkYLUBdPiGu9 R9R9D9NfyVt77i378vvh+2xvk78jNv1nR3yRx3ZG+h09nMvtStx1BWbL/itb1HQbin3FHH1DvaKS nFE8cFRRAFktUFAPb8qXsfL19tbzRfVyTK6kFtAA0cTo1A0DcFPl8+umHNX36PbrefvX+2fvZt+w b8nIWz8v3FhcwvDarfPLOL86oolv2tniDy2hrJPGw0zHQxWLVbN/Lr+W3xNzvwu2zQ7Z+Xfxl7Po PjH1pRw93bm697LhqNs9cYTa8OSSj3bvXFbnptm7r2jgxgsSzruOGloQxp5mZahYXlYX7TazWW22 dpcMpljQKStSMcKEgHhTiB1gV76c6cu+43u/7hc+cqWt1BsO77lJdRJcoiTqZqPIJEilnQHxS5Gi VwQQcfCBU+OP8zr+X78udzb02V8e/lZ1J2duvZWPym593bZoczFR5dcDg/E2Z3nT4XdNHtaj7C2r hFljepz2H+1rKRXQzSMWVmMOonp1P6O/nCfy9e6u1qjo3pn5tdHdidiU0OQmpNswbqqsric9T4nH VeYycmzt31lFj6rNpjMPj56uqNMc5FSUsMkry+NGdfYPW89CDsv+cH/Lv3x0r2l8icL8nusMj0l0 jldp4TtntDDZ18ttDY2V33kqfD7OocxKtHS5+KbcmVqkp6Qfw4eaUkLcq+nXXvy6OD0v8mOivkR1 ptHuPpXsbD9hdX78o6zIbP3rhabLphc/RUGUr8LWVVBNkMdRSNDT5bF1FOxZF/chYfj3rr1R0Jn9 8cEw/wAnkyNcx4EePwWcr31cWDfa46VYr3+rlVH1JA59+p16o64nL7grfTituSUqm9q3cVXBQQj6 WeOhoGyWRlIB/RKtNci2ofX3vr2fTplyVPioHibe2eGYqHbXS7fp6eSKgmYXIWm2xRPXZHMsCeBU NV2IBAU+/fZ177enO+4s2qw0sT7Tw+kIZ5Vp5Nw1EIAASkpF81DhY2T6PKZp1HHijYXHsfn17PUK kraWlSTCbGo4a6oWeX+IZaaSabFUdW1vuKrK5Qs9RmssWtqhjkeZjYSPEtm9++3r3yHWXVS7YbwR fcbj3hmVV31si11eEkZRPUMimDDbfoHlYKABFELqgklaz+4/Z17h9vXarHtmN8tlnbM7qzLJSRRU ifu1UvqlgweDglb/ACXF0vLu7kCwaedvqR7jgde/w9dLp2+ku4M/av3LlSlFTUlAGmca/XS7dwMc zKfChQvNKRGJGDTS6EUBPcfs69/h67QvgIJ9wZ2+Q3HlfFR09DQgyaGbVJRbcwysLmJZAXlmbT5G DTSFI1Cx++Xl17/D08bfxU+PhqKvIvHPm8tKKzLVEVzEsgXRT0FKzAOKDGQWiiBtqs0hGuRr+P8A Lrw/n0oPeut9e9+690l83tPGZozT6TRZCaD7eWtp44XFVCOVpspRVEctDlqQNz46iN9P1Qo1mG69 ap0E+bwW7cAHmXHyZykjgNManFxnI1DUFjegq8VWyyVeTxWktahqHqhGCTDVwEhfe8HrWR0lafem PMrU0sqw1KQCj+3yEdVPeiIYSYXJwVMa1mYwTa7Ikkf8RoXYtCamO7e90PWq9K7GbjEFRSVlA7TT QLFTQJLVxyyVmPmlcw7bylaZXgqpBJqOGyesxTsDBIySM4fVOt16GCDcuBnoYcicrQ09LMpYNWVM NG8TI3jlhqI6l43gqIJQUkRgGRwVIB916tXrAN14abjHy1OXY/oOHoazIwP9OfvqaF8eim/DNKqn +vvdOtV67kyOYkQyLQUmGpx9anN1kTyKObH7LHyyQtcc+qqjI/pf6a631Ejanqv87W1+4X/440MY gxfNxp1QmGikQn8T1Ep976108RtPFGvmWixdKnpSJHV3A5spfTDTwk/6lQ/+v711vpyRldQVJKn6 Egi4/qLgXB9+691//9Pfiq6XJ1hMa5H+GwHgmhgilrWB/pU1iTU8Nx/SBmH4YHn37r3XzQ/513W3 yW7e/nPfODdW3vjn8193bVxfx7pPj58cdwdZfBmD5XYrfu+JuqtlY+rwM03aNBFiNo7Hy+7ty7pv vHa38W3NhJVhOKpS0rvT+690T74/fywP5lGW7E39T/7LXX9A7p+BP8sDtrelJRdt/FnL977E7ezz YvcPY8vUOw8D2dtvd2y8/wDIHsGo78rJIoYoa0YLcdFWrR0oNJBH7917p4+FfxR7A+FPcP8ALx+T vzZ/lmfMr5GfFmp6M7oy0nTm1Omdw9pyYr5DZDtDurrnE/3t603XT7d27trM5VcJt3Kpi8maOpfH zY6ugFfNRrG3uvdR+uvgd/NL3zHkPh1tv+XN36nXHyk+R2J+dnePxwxObpfjXtTH9NbOq8qOv+hI O7e2MVSdedSblq8XuXIVNTjq/wDiVfAkG2ZjQNXUL0sfuvdRJtgfK9/5cH8ur4j9vfBT5h5va3QH 8xvv7f3eO19l/GPs7K7urelMPTdFZ7H/AMImfEYzB56s3NUdt9gUeKMtdBSyzUBAqYYmMre690vf l3/K5/mE949c/wAwP+YF8dPgV3p8Uuiu7+9Ordr7X+FWL6+qtu9qZ/44Y2jzm69zb8zvQ+DoY9wU +PwfZeydlZeqSlx8zGuyuQqIJJqGiq6p/de6NZ8qOhs587Ojvkl2R/L0/kfdw/Eqk6o+OXWvV3V3 eG7Id9dGd890bIh3RtTH9m9R7Q+MmxKeHqvvXOZDYuWzqZHOoMruKvwVCkFTVy1UlJj039nWuirb 86E7V+S+yfiLvz4Vfy4PkT8RsF/LQ+H26sj3f3Fu3oqt683V3t8q9uYCjjO0tqV20dvVO5u5Mzub tzApGkdU0udig3BlDWw0FJApPuvfn1XpX/y/P5lPX/x57p6Wofj78g8d01n9nfFX5a7owrdM9itm N47+nw1Hsba/XuLmo9qwPkc3gKv5D5XKZLBsKh6Kk28Zp1jqqQn3rrfX0n/5P249zdffGbr74Z5L or5XdOVHwz6A+LOyNzdi9i9Y4aj6o7d7D3703iN+9jHpmuEOR3PuKk2ZuiumgzAMSJQVVbHBqdwx XfWura/43KBeo3pkKVT6SKjZNTj5wxU8KtfjhpkT8hkax4I9+61+fXmqcTVC1XuLfedDAHwY/F5m jgcEXsJdrYHFsISRb9yYrzZmPv35Drf7enLHLUUaum2NkJjDObzV+aqKLF+clgTLP9k2XzNZIoJN p0jLEAah9R77T177B1iylPSxhG3xudJUmJMOBx5kxVBUgg/s/Y001Rm85wpBjeV4nsf2R9PfvsHX vtPU+GfN5CGOkwONTa+JjVYo6/JUkcdaIV404rbyhUpRp4V6wxlD9adx79jr3UWCoxuEmq8Xtylm 3DuSeRWyc8lR5ZVn0kpPuTNsjxUUcSNdIADIFNoYNP09x48Ovf4espSl2438Yzc75vdGSBpKVKWn BqJT/nRhtuUDOxpaJLBpWZ/Vby1ElgCvuPDh17h9vXJF/hIn3ZuudP4iYzS0VDTGSpgxUFTIgixO KiVRJkMrXyqgllCeSeSyIFjUA++Q698z1Mw+Mq6qs/vHnYgmTkiaLG44lZItv0EhJNOjK7xyZSrW xq51PNhGh8a+rx9B1759Kr3rrfXvfuvde9+691737r3XvfuvdNuRw+Jy6eLK4zH5KPSVC11HT1QU Hn0+aN9HPPFrHn36tOvdBjmOk9nZDVLjVrMDUlSB9lMKiickhrT0FeKiKSLUAdCNGCQPdtR60VHQ cjYe+tgVP3mNig3Bih4zUth6akpsl44I1hjkaklpZ6lZ1TUWanMryFiXP597qD1qhHStwm5UzETH z19W6MRNFLubedF9sF/UlVLiduvDG6MAbO6mxN7j3rrwPS0o5MUGSULs+Cb6LNWZWoylWjDTrCyZ Kloqo2uCeV5Fj/Uaz1vpRpU+YevLmUWt48RQNbjjTq05GYcfkMv9eB711vqTFEFYPTY6R5QOKvJT Hyf64eRqqrX/AFtKD/W/HutdShUCJtNRVJJMfpT00ZLD/DxqZZmH+JsP9b37rfX/1N135aZr5L7a 6V3HnPibsjbPZ3dlNkNvR7b2PvHIUmG21ksdU5yhg3HPXZCo3v12Ulx+BknmhAzFNqlQALKbRlBu cm4RWcj7XAkl5UUVsAiorxZeAr5j8+pT9mdp9p979wNq273s5nvtn9vHinM91aIzzo6xOYAqpaXr EPMEVqW70UnKfEKb8v0t/O5+ZTx7H7i3D1V8FuqnCx7sbqTMUlXuTdNJK+iYUsmzuw+xtz5OYxOy yUdRuXCY+oiZhL5CFUhOS15x3ciG8ljs7bz0HJ+zSzk/ZrUHrO/bOd/7vX2BR9/5A2fePcPnLjb/ ALxiZYIGGQX+qsrGBBWhWVbG7mRgNGkVPTk/8hWm6wo497/GD5j97dbd94+IV8W8szWY9NvZ3OJL NUSxV0OzqTb+48XisqZPHN5qzM6FeRpIqlWMR3/UoWw8bbt2mjvRnUaUJ+emhAP2t9h4dNL/AHkM vN878v8Au97Fcubt7bStoNrErmaGEgKChummgkkjpqXTFa1IUK8JAcYsV/Nl+R/wnqh1T/Mz+Nm+ qzL4t3o8D310vjsBWbd7LpYo3FNXw4/JV+1tkVuQqPGss0lBk6GWJJQk2LpZY2R9LzPuG0H6bmHb 3LjhJGBR/nQkLX7CPmoPV7z7lntX7/wnnP7pXuvt0djMA02z7o8yz2DEjUheNLi7RFqVQTQTKxUt HeTIwZQJqO9vkX/OI+W3VFJ8eIO+egvhr1RKJ+xt6x5/LbEq8/TzV9Lktz02ZyeyM+2Hqt1Z+ixl PiMNi6evycmO8k1c5WF6gRoje3/Ne6WosBPBtMXxtUrXNTUqaajQKoBNMtwr1IsXt17W/cX9lOdJ /c+TlvmX333oUsbQwx3awsEaO3aKO7h8VbeF5Hubq4eGBZ6R26guseraTVVRVVVCqoCqqgBVUCwV QLAAAcD3JHXHsksSSak9azHf+/fk3/Kz+fW5PkLnh3X3b8Ge4UzMmQw8e6NwbtxPX0m6J6fLZDA4 yjz+Ul27tDcW0N20vlwq1BpKauwE7UUNQj/cNTx5fT7jy3vcl8/jTbNLWoqWC1yQKmilW+GtAVwD xp1q9tOW/aT74n3bNq9sdt/q/wAv/eI2IxBJTbw20l6LcNGk0jQxie5gubZtN0U8SSK8QXDxMvhC URdy/wA5ve/yuj/0Qfy8viX2b2J2PuVRj6ndPcOE29R7P2DHUEJ/Hcxj9s7o3HgFgplYtFVZfNYu ip5whdKkHwOpbm6fcSLbYNtle5b8TgBV+ZoSPzZgPt4dBGx+4Jyv7Rxvzh96j3k2bb+T7bvFrt0k z3F6Vz4Mb3FvBNqJwY7a1uJWXVpaIjxFY5/5HPYPdFEvYvzQ+WPa/bPb2VpVqK+g2LkMZBhdm1bR gxY/btRvXG5Klz2MxsjELTUlJtmAJdYVXjV4cnS348fet2lkuzntppX5CoOPsCj5dVk/vCNi9spB yz93P2K2PauQ4DoDXayG6ulXAlm+nljIkZQKtPPeSE9zyMcBNbe+OX83T4PSVuL+Jfa+3PmD05E7 wU/WnaMiUme2qsrqwpa/Z29904GvwHjWRhoxGf8At6mzSmmRmUDy7bzXsrFNtuUu7TyWQ0I/3plp T+i9Dx0jp6+93fuL/eOgS/8AeXky/wCQuexmW92pGkinpxqba0uBIz0FTcba0sY0oty6gnqwb4Q7 /wDnn2LmOwR8vvjv1D09SY2g2/Lsf/QrvigxGey+SqZ8r/eOPOYTF919kQ/5HTw0jIKyHGgtKxDT ciI+2e43+ZpxvVjFCoA0aCDU5rWkj8Men59YtfeE5W+6zy7Z8rv93T3J3rf72WWcXy30UkYhRVi8 Ax69q26pdjKGo0tAq4Ti1h4q6+lIWbJ9jY0AgGCr23itwxpYm6/dYPCZiVvwC7VDrbm97n2e/s6x i/b12c4LETb5r6cPzGDtP7OoADfXTW4uUMpAIv4xf8e/fl1qvz68ajFTkrVbg7AzgIBEVHi81RRM rLqA8+1tvYdPGy/QvLY/S5N7+/Idb/b1Px0clG7NtzYn2MswtLk81U0GMee/9qompnzOdqWH9Jol J+lx9R77T178uu8lEYo0m3nuuGippLquIxMrYSlqWPAgNR55c9k5T9NEMsKyXsYjwB77B177T1lo 6mvlpkoNoYCHCYxPTHk8vRtjqVFJ9ctDt9Pt8nVyMOQaj7RGJ1amtY++09e+wdYlkxG362UI9bur eNVEqyKpgqcsYnbUkb6fBj9uYfXyA328Btf1yfX3H7Ovf4enbH4WrnrI81uKSGpycWv+HUFMzvi8 EkgZHFJ5FjasyEkbaZKuRFcqSsaxoWDe+zr329Kj3rrfXvfuvde9+691737r3Xvfuvde9+691737 r3Xvfuvde9+690jNxbHw+ekFciLjczEdUOVpYovKWH6RVxMPHWICB+r1i3pYc32CR1qnTFTHcWBI hy0tWadTZcjRVxlpXS/p1/xqLKR0rEfUSPSxKSAhP49g9e6VUFXUSIrvUZoK4upTH4+cEH8rNRQV lObH8gke/db6k3ST9UGarD/qZb0qE/0ZHehgP+xFveuvdSEWqjjIhp6HGQgXLSESuP6s0UPhhB/x Mrc/X37r3X//1d/j37r3Xvfuvde9+691gqaamrKealrKeCqpaiNoqimqYo56eeJxZ4poZVaOWNwb FWBBHvRAIIIqOnIpZYJEmglZJlNQykggjgQRkEeo65xRRU8UUEEUcMEMaRQwxIscUUUahI4oo0Cp HHGigKoAAAsPewAAABjqru8rvJI5aRiSSTUknJJJySTkk9ZPfuq9e9+691FoqChxlLFRY2jpcfRQ a/DSUVPDSUsPkkeaTxU8CRxR+SWRmawF2Yk8n3oKqgBQAOnri5uLuZ7i6neWdqVZ2LMaAAVYkk0A AFTwAHUr3vpnpmyeAxeWeOeqpytZApWmyVJNNQ5OlB5Igr6R4apIy3JTUY2t6lI9+r16nSbr9sZS ZVSaXCbqp4gPBT7qxsMdfDpNx4c5jKcrCR+GNE8lwCWJvfdetU6bBR1dBcfwre+HC8+XB5+LcmNU 6vUKehylVV1KL/tK0CrbkC9/fuvdd/xd4QQ28dyUpAF/49sk07AA6SA6bdxEEjM5sGXUrW9N7E+/ fl178+sn8YU6lfsWIHxebRT4bHJVqgIOsRTQ1LWP0IMZNzYc+/fl17/bdYzU4ipA+43JvzOg8iPH Y/L0qMLm6mbamAxQRbrpJeQW4BNzz78uvfmepuPiFJKZdvbCenqZOGy2cqKDGySggqfNViTM7hks v18kHIPH59+/Pr32Dp2OHzuSv/Gs61LTE/8AFt23HJjQy8eipzE0k2Ul/PqpzRnnkG3PuvdPuOxe OxNP9rjaOCigLGR1gjCmWVra5p5OZKieS3qkcs7Hkk+9db6n+/de697917r3v3Xuve/de697917r 3v3Xuve/de697917r3v3Xuve/de697917r3v3XumtsNji7SRQNSSMSzPQTz0DMx/tSCjlhWU8f2w wP59+6913/C1/NdkytrafvpR/resWlv/AI6r+/de67GIx+oPJT/cupur1ss9cyn+qmsknKkfi1rf j37r3X//1t/j37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+ 691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3 Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//2Q== --_011_4A6CE49E6084B141B15C0713B8993F2806E252SJEXCHMB12corpadb_ Content-Type: image/gif; name=image002.gif Content-Description: image002.gif Content-Disposition: inline; filename=image002.gif; size=1408; creation-date="Tue, 07 Aug 2012 23:45:25 GMT"; modification-date="Tue, 07 Aug 2012 23:45:25 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhGQAZAHcAMSH/C01TT0ZGSUNFOS4wFQAAAAlwSFlzAAAOxAAADsQBlSsOGwAh/wtJQ0NS R0JHMTAxMgAh/wtNU09GRklDRTkuMCwAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADqYAAA OpgAABdvkl/FRgAh/wtNU09GRklDRTkuMBgAAAAMbXNPUE1TT0ZGSUNFOS4wzfpCa7cALAAAAAAZ ABkAhwBpngBqnxR/rgF0pgBvogBwowp5qRZ+rQNxpABvowBuogR2pwBzpQBxpAN1pgBtoQVxpAJy pRB8qwV2pwBuoRR+rBV+rABypQJ0pgBypA97qgZ2pwBsoQd3qABxowN1pwN2pwR1pxF+rhmBrxyI tR2Jth6ItRWCsh2ItR2HtR6JtjF1lD12kCd5nSOPvSeKtTOSuiCLuDeDpSaRvjuGpjOPtjeRuCaR vzqGpzmSuTyUuieIszWQuDyGpiKLuTiFpiKMuyCItCGDriGKuCKJtimTwCyWwiyZxy6WwUmBmkaZ vUOYvUCawVKlyFWnyUmhxVCgw2KeuH6yx3C41We00mi00mez0mm103W82Gq102m002231WWz0m23 1Gu102u202641G221G693Gu21G+51XC51m631Wy31GKx0WOy0WOx0W641XG51nO92mGuznS51XzA 2nvA2n3B24GTnI2Zno6ZnoyYnZafo5qxu5mstI6lr4+msI6lsI2kr42kroGxxIKzxoa2x4/C1ozG 3JHI3ZDI3JDI3onA1oLE3YLD3ITC24HB2o7B14/B15TE2YPK5o7N5InJ4YvO6I7L443S7Y7S64vN 5YzP6oLG4YrO6YHG4I/S64TH4Z/P457P45TK4KK1vam2u6SzuKSzuau1uaStsqitsKrM2rHY6LLZ 6a/Y6MfX3dvd38PGx8zNzcDc6cXf6sLd6cTe6sXe6sfj79vu9cLg7dTn8NDk7t/t9N7t9Nrq8svi 7Ozt7uzs7PT6/Ofx9unz9/n8/fb5/Pr9/eDt9Pr8/efx9+fy9+vr6/r6+ujo6P///wECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwj/AJkJHEiwoMGDqwQNIlSoocOHDQ0dOtWL IKhHkBDBicOxo0eOciJJkuJLICs5k6ZQqcKypcuWVq4kooRHYKhKWKxk2cmzp88rWiz9ESjq0pYr PLlw8cm0CiZAAkdl6oI0ixdFir4w7VlFE1RmojaBQVolzK9fXaps3VmFUyCBecSMIVPGjJlOns5U QcMFTRo1VNZMYeOlTRSBelwIeMGkiRtUqa4sovVJVS1bb5w8gTEihgyBe2YMIECggAFgwQ5AYSbs Fi5mrxAkIKCABA3QMxYwYNDAQS5dD2owgwUhwq5hEgrwLnGbWWjdvCfkylXABjNGACjEIlZBeQPm oG9AzW8gnbp1RgEIyBLWfXnz57vJFytWnVmj9LOMtf+OQyCf3PFNcAwyBeTAjCPp8cKMBd6V0B8z fQDIwAUY6KBDBhoosUMDGfCwxAYZLNeDQBFCt9sDDzCQAQcJ7KbAAxfEV8KIzOgh3m445qgjjt/R 6EcRHYS445C7eeDDDwKRAkQQBQhJZI4eGGBEEgIls8IRJnTwAQhcdukllyGIgMQJpQzUCgtCDIHC mmy2SQIKKahARAtzKEPQMqbQoScdddSxJ5+A2nGHKwcVaihBAQEAOw== --_011_4A6CE49E6084B141B15C0713B8993F2806E252SJEXCHMB12corpadb_ Content-Type: image/png; name=image003.png Content-Description: image003.png Content-Disposition: inline; filename=image003.png; size=3853; creation-date="Tue, 07 Aug 2012 23:45:25 GMT"; modification-date="Tue, 07 Aug 2012 23:45:25 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAZCAIAAABLixI0AAAACXBIWXMAAA7EAAAOxAGVKw4bAAAK T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3 AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+ 5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk 5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd 0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA 4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5 h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+ Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY /R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1 mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/ 0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5 hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9 rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7 vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO 32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21 e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i /suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8 IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq YAAAOpgAABdvkl/FRgAABDhJREFUeNqsVTtvHGUUPed+Mzu762eMTUKUOA8lSBilSIIl8hCvAokG mjTQQEEFEiUVBb+BKkJIFCkgUgqQiIgoKAJIUUBWQIGERxIlspM4Nthe7+7sY757KHZjb3iIhk9T jL7RHJ1z7r3nUhL+p5NsvH07v3x5qV7JSiAhEAD/5SeBxmartWWo8vT20fGhSu+akmKMJ89f6uw6 UEXR6EYHCAgiSP4DkABA5RBCSO6trJwYrs88uq/P6+yFufbeQ2yu/7DeiYILXakSzIGOKwsPAPYs EQTh4XKYnpw4c2v97elWuVxO2u32pTyZVPfSWrvnXDWxl3cOPz6WReni7+1ztxsiDOwRIiGBgIj5 ZpFavfzIzrkfrxw9fDDpFkUsirVO0XFPjFF4fd/YgfFSQzDipR3JWMlO3aiVbJNXj5kEo5baxd4R W16rATCSkjouhzqu6aH0wHjpboF7heY7+iPiqanKSGrrhTcLNQtvu7vkgiAHCleUywUgISBAkgsR mswMQM0VARfWXBOBx6cqS60iMbqw2I7X1jsBIOCSgxtNlUjqxFgGyI0aoeXIBQEpAeDEzuHBSn6z lL9/bc0AkiQ6cof6dVzMW6o1Fhp5OUnangGIQFcwYDXip7ZSIgARaAsTgcemKldrnU/nay53j57Y fr+PRbLlfi9vR7QfG00A1CPqQk/IagR7igAXrkvPjnB2ovTelaZRQ8GEvpqk538wpsFMNBJA7qpH GCAgarBPIYBgFCywREsDgxk3/CJpNDOTYGYA2hF5IRIV49TmmMGF3RmHibN36oFmBjOz+72cADDQ jIEE+7xarmaUA9vKeG4kDBq/2okfXF///E5jKA1RCuQGWAKARiODGdDHake0Ihwo/K/jeKtZfLWc w5iQcDej0TZ5ETDSSJHB+rxaUSKWuvgl98FU2j+WnTy87c25xWv1Tk8gBzX2+qT3YaUrABWiVqhs uJ7r16ZvGO/AeOBbO9JXd4+9c3kpIc34oF+kkUakwW40urWuHxkN39Vix5H8LXNudnWzpV3VpBSC QUaQ/aSzfuSRJIOxEXV6ob63zFe2pqMBeVRz4KlH7c64p8yr9a56w0waSRBAIsDNKsF6BammduZ2 MzV7bXp4diRbKVQMuEVgMuVK1z9aaJSDuVQKJBklAEkpTYtmfXs1G0oaXTEBy4GnbzfnasUzk+U9 1ZAZB/pLF1biZ3fz5Y6SwFah6WraKHy8kgFIsiw7mrYutoqDk8O/reW5YORwsIVWPLXQTMwCjexn SXQV7gGqBBpsTzUd37Ll56+/nH3hiX7ed7vddz/8+M6h56e3TkkiLRjNEAxmMMIIAe5wwR3R4S4C zSLevHD+jV3V40ee7GMByPP8k3NffL+4WoDWzx5avyj9FSJJgqD7a5APBb14bHZmZmZzD23YURRF jLEfwP91SGZZNnjz5wCK81KNPiIliQAAAABJRU5ErkJggg== --_011_4A6CE49E6084B141B15C0713B8993F2806E252SJEXCHMB12corpadb_ Content-Type: image/png; name=image004.png Content-Description: image004.png Content-Disposition: inline; filename=image004.png; size=3749; creation-date="Tue, 07 Aug 2012 23:45:25 GMT"; modification-date="Tue, 07 Aug 2012 23:45:25 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAZCAIAAABLixI0AAAACXBIWXMAAA7EAAAOxAGVKw4bAAAK T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3 AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+ 5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk 5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd 0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA 4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5 h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+ Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY /R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1 mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/ 0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5 hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9 rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7 vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO 32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21 e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i /suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8 IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq YAAAOpgAABdvkl/FRgAAA9BJREFUeNqslc1rXFUYxt/nfc+5985kzIclpk0tCQl1CLRpFy5iQYR2 URFEEcS13fgHCN26FtyJblwJggilCxEUFypWRYTa0KQaaPNh0wxkzOSrmU7v3HPO6+Le+Wgx1IVn NffOOb/3ed7n3HOgqvQ/DdP9tbPX/HWhvnfQSpLkvxXQrO2qk0NnqsfyZ+TLrt9YuHa7dGS4EtS3 M/9kDJEASWwOUtjm0ttvvgQAqpqm6Yef/35iYnpjc3drNw2Ha3JenQ9d0UMVO3280nTx9MDaxfNz hohuLi4NjIzX6jt3N5tW8O8YUDsLYyNJdWJkdDiJLKvqj/P1hTvbs9Wx+TsHF8+TIaL9+03Voc3G A9VwmL92O1QnBt957WQSS/flrZXd5Xv37zdTBYreM3P6MGu3nc8C8LgcIoSg1vBbFyb6QUQUfHDO pakjDb0cffDee+c8QFTwQEQAiDTNwuyJwaNHSvnkVuq/+mm9sZeubOyDgg8+BC1YqqGdtoNqUEUe UlcVNHPabLlS0ts9P9+sf/b1chJLpWRE2PvQbrcLlnN+dXV9s9GUKCmVEmutGCPCAEKgqfFKOTGT xwa6rErJvHh2LI7k1u366tqW8S1qNXoenQ+7uwetdM8YyyLGWGONMSZzdOmVuXNnj/a3ae7U6Nyp USJ69/3a3Xtbx0fLCbhggYjBYqzxAhYiOKfOOSXfSr3zh25dMcYYy2IooKsLABMEDLAAIAgAIo5h rv/RaLb8s2OV0yefzhHL63tLazvW8Ob2Q2stwKCOLiUlFoAJBAiYCQwwgWODL75d3T/I3rgw2WV9 91vtg0/nK2WJLcdxTBB0Pea6AAEAZrAULGIASWIDSZxEXWuRNZWBUqXEqiFzDmAl9J8TIHDHIxel CiIAyit35nbqEQAlMKGPBTDA4PwPAfIQGOjUoB4LYLBhZlUPKMDoZxEYzESaU0Dcpw7MAPd9PQAg uRYgPNL7jsd8MIiJJQfla3LYI6giaCoMdnWpkrVGRKgwn+cgfZkqQR7rF5goKJitMSElImIiKieW NIyPVjKnRdUi2aJ3BLGmx4qMEDER+0BxZAafKnuXFrrOzM58cvXK1My5zFFtKw2aa0YeIEGiCH/+ lX50taYhgHRpbT+ORCkMVaKZqeG/tx+8MBP3zvvvf7j28ZWVyeeeZzHOEbEAhpgZBhAIO480Cxq8 Bm9FrSjIR5Y2avVxc+O9y5eiKEL3yllcXPzym18ae5kIq5IP+QGW753iZiBSyudrAMMKna4+8/qr L5fL5Z6u7kjTNF/2xGsNgDFGpNfHfwYAQFicrB4gTtcAAAAASUVORK5CYII= --_011_4A6CE49E6084B141B15C0713B8993F2806E252SJEXCHMB12corpadb_ Content-Type: image/png; name=image005.png Content-Description: image005.png Content-Disposition: inline; filename=image005.png; size=3902; creation-date="Tue, 07 Aug 2012 23:45:25 GMT"; modification-date="Tue, 07 Aug 2012 23:45:25 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAZCAIAAABLixI0AAAACXBIWXMAAA7EAAAOxAGVKw4bAAAK T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3 AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+ 5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk 5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd 0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA 4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5 h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+ Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY /R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1 mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/ 0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5 hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9 rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7 vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO 32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21 e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i /suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8 IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq YAAAOpgAABdvkl/FRgAABGlJREFUeNqslV9sFEUcx38zu/dv7+pde+1dbZGYtrRgY8WKsWmLxIgx 8oQPxsQXX8REjApEQozRJ1+QxDTUqFUeJEajJiZGjIYCpQjYitJSKE1aiqHtdWnT+7+319vdmd/P h20PQqqBxMnnYWdmf9/5/mZ+O8uICP6nppafzIvDhfOnS/Nzd6+tBgLB1s0V23eolVEAYK6v9E/f Z8+dXpaoMOCM3aWWQGIMQsFg7NW9vvoHOACUErOZswMFITWFexlDIf4NFcDLWBlN4QpArlDI9B8j IpWI8mN/lYRUgTIO+Ftaqzc/5tGCd1i4OfRbYeRCzX0VRJQxi/5HtpRSS5WZJQ9jlsDC1bGoEFxK aVm2IDJDkcbd+6x0aubLz6aOfJyenAhvaAlvaDHmbmQmJ4yRC9GKEBIhERHUdm6NNG9yu5yBJLIs i0spbcdGorY9B/SBfu9iIhLUqjyKMdg/d+o4EcU7uhfPnKwKBd1IJCJYOZ7yCCI5jqMSESIhker3 Zy8OuzEAEPB5F/t/ru3oVAPa+udfTP34neWI6PbnAKAKwB+tiTRDFgAA5PQUX0wQkQoA0rbcxRTG EW+VhEeK5KWR2o7uSFPLvO0AQKR502o1aK4cANiZjD0zvVJfdiqZvjRCjm3o8/5YjRqqcAN8qlpK LgGiv7KKAAJez0xfDwAsW87GN/enJ65kjv0gCkbRyHsde52rRURCOCClt25d7uoo50wJaExReEBj uSxJsTD8u72gKz4vAMjlomkUHCNfvKnbc38DAEqUjAEAd7UkESFufPmVdMGUSLZpWvl8LpEgIchx xj/tweRiUU8U9YSVSdv5XHpi3NQTEmkForIWkCTHyEcamx/a805WQrFkF0s2xuvrurcNvfu2sjBP BIjk4vd65z4/bAyecLuEhJJW9guBJNHxl3a2vvZWXde2+7uezE1PAUC4qfnsvt18YV5VFXn7FcCY oioA4A5KIg5wK0ckDDGc6j108oUdv+x8xjby1W2PZq9NSn2WK2zV0NpIQkkIq3sPbr15FMWjKEBU 17kVCLVY3FG8qhTsP792QkJ2my+J6GILgUQTR48QohaLdx7sgXi9LUT5hTXBsi8EQiJb9dQ83hlu bNLitbnr046R94RC4YbGroM9V/p6F8+cUlVlTV+SiGP5LiRAhKe/+FofOjf5zVE7uQQA17/9Slv/ YMf7H2jx2va9B4YNIzvyJ+dsrRwB2WpNIBEiXu7rvXz4kMykFIW7lOZnB9/YNdP/KyC17XrdFs7a OdJKjhwA1OqYAnBj4ATjXBKVQSK0SqM9H5oLuhaL+apjt8+6CKSSRBbQGGMcACId3Z6AfxnJFFJI vKMBY0tjoySlFovfMWVJmXOEByj41LOcc2ZZVjKZHD/Vn/rkIyubdvAefkucgY8xb/sTzfvfa2ho YFLKfD6v6/rstancH+dFaunutRhjvofb69q31NfXx2IxRkSWZWWz2XQ6bZqm4zj3pOX3+8PhcDQa DQaD/wwA2uRn79BoYwAAAAAASUVORK5CYII= --_011_4A6CE49E6084B141B15C0713B8993F2806E252SJEXCHMB12corpadb_ Content-Type: image/png; name=image006.png Content-Description: image006.png Content-Disposition: inline; filename=image006.png; size=4048; creation-date="Tue, 07 Aug 2012 23:45:25 GMT"; modification-date="Tue, 07 Aug 2012 23:45:25 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAZCAYAAADE6YVjAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAK T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3 AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+ 5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk 5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd 0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA 4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5 h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+ Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY /R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1 mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/ 0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5 hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9 rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7 vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO 32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21 e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i /suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8 IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq YAAAOpgAABdvkl/FRgAABPtJREFUeNqklktsVdcVhr+1z7n3XNsXjKu4KK4boZYAsYqSGlAUBhHt JGEAaSgZVGr6SFLFHaCo7YxRKwZ9zPrIQ3kI1UhWCx1UkVAgSUFVW5UUW0auHeoOrDoP+jBGvg/f c8/Ze6/dwbn3FgKDFJb062hvaa3/rMe/9xY6pqrfB77uvd/CHZgxBhH5LfADY8wlAAHw3p93zu3L sowoihCR2yZxzhFFEUmSrAFfiOP4Etbab7Tb7bC2thbyPA/W2mCtDYcPHw6Tk5PhzJkzYf/+/b39 j4NWqxXq9Xqw1s4CxKr6pXaWUalUAAghADA+Ps709AybN29mZGSkt/9xLI5jsjzHOffA6rVrw8Z7 P+S97/alh/vGxrhw4c+8884F9u3bx5EjRzhw4ADHjh1jbm6OgwcPMjU1xdGjR2/w6yKOIqx1JOXy 54xqIGhAP4K9e/fSarVYWlpiYKDK/Pw8hw4d4ty5c1jraDabZFlGq9W6yVc1AIJXj/eK0aCEW6A6 MMDY2BibNm1iePgu6vU6Y2Nj1Ot1nLM0Go0eya38NShBAyEosXpFNeBVb6ptmqYMDQ1hbRH0+m+t ViNN2zSb67f0LeIqYIhza8nynCRJbhrdNE0B6Ovrp1arMTU1Ra1W65GcP38OESHojUMRCDjvsLlF jBB777F5TpbnAIhID1u33gsCO3bsYOfOnRw/fpyJiQn6+vsZHBwkLpUYHR3FOUcIAQ2hN4XOOZyz RFGMfHjln79vtVoPV6vVQrGXZjGnTiLNJgjI0hK0WmAMEsdQKiOVBOnrg2oV2b4DtmwhrK7iowj7 +JcJ1WqHxBHH0Rdj7z1dmH//i+Q7z9FLXgREkCiCOEbimFAuIUmCqVaRoU9gBIz3mF27MaOfovab U6RPfq0XU0SIr5/t5OxZIjFUF97t1ddfvEj61DfBOtBA+elvEe3ZQ/t730XSDJrrhLUaunIV7rmH /pX/sP4RzRjv/7cAiKKI/Omn0MVFdHER+5MfF2Us1IpRRYISj34a06gjq1cx5QRxjjA3h1y5cgOB 91pk4jsAiI2BmRmk0SjWg4NU/jqPf+klZPduwvQ0ZnwXyeQkevo0/o9/oPTDHxVZnziBLiz04nlV RHxBEryiXpFOJr1+dI5uANNZiwhhZgb+vohs2078xBOE2VkQMA/cj7z2WqGRLkSIvXp80OIICAHf GcG4037tlEo790IADAGtN4oSBpDxzxf6mJ3FZ228elR9US6VQvG+w5o5R9NaADZ0BJY6xwYgV08c Ak49JQ1Y9ZS6Sp++SPb66yCGPE3pxvSq4AVTNKhgzZylmWc086zILihph9Ts2o0PSu49MjIC27bh g5J98D5y9wiVZyfQz36GZju9rvFFRrH3incFczupYF0RtH9hAYDa8j+ovHkW36ij9QbZ8jKyME+0 cZBrp06RXX6XuwYGALh68tdkNsd7JbcWEUF9QP5yceaEde6r5XKJaHUV99y3Cc31275+o8ceJ3pm gmazSX9/P5cvXx6W02+ceXR4+JNvtNbXqfT1Ie8tk039krD+/xPFO++n/JUnabdTjBhMFP3poQf3 PCxA/Nbb51/csHHDM+12G1W9o4dECIGkXEY1/O3kyV898vOf/fS9brTkF8+/8Ni927Y/G0VmI+EO 3kQirKysvPm7t9965dVXXl4GwvW/bIAEKHWfSrdpHsgA29347wAa+pFmyNu48AAAAABJRU5ErkJg gg== --_011_4A6CE49E6084B141B15C0713B8993F2806E252SJEXCHMB12corpadb_ Content-Type: image/png; name=image007.png Content-Description: image007.png Content-Disposition: inline; filename=image007.png; size=4184; creation-date="Tue, 07 Aug 2012 23:45:25 GMT"; modification-date="Tue, 07 Aug 2012 23:45:25 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAZCAYAAADE6YVjAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAK T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3 AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+ 5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk 5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd 0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA 4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5 h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+ Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY /R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1 mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/ 0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5 hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9 rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7 vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO 32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21 e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i /suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8 IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq YAAAOpgAABdvkl/FRgAABYNJREFUeNqcln2MnFUVxn/nvu/MO++8M9ttt7PbLl2bFmy70BYsDWKl hS6iqxS6WBMoFAkBEhKJmKxR1Aj4WQwx1rRaIF1TjApS04i6pFi+6bYQ6+IHtRZYFWvZXXe7ndmd mff7Xv/otqgEm/Ekz73/Peee+zz3nCsAy7yZ/GD5ZSs6ijNurxp9UYpxAUPjIRZSL4p66XfHR394 1eCeA5Ex2AAXzWpb3zaj+Sf/MEneYLAaohVMnGCiCETQOYeymAs6S3NuvbFjya19fz/8sLTnvNKe VetfjbNWq6eFgqjGEgQhVluJ/OoL0dU6/v5BKvU6NUtoNlL76MDjy+zVs+Z+qJDLtdaSmKIo0gaK MGFEZmEHpW9+FrttNgB683aKTzwPeQeVyXiXl+ats1ud/NwYgycK3agCxtB823XYrS2c+P6P0OVJ nOVLUJkM8eN7iZtsCplsh9IYAyANEJswwtQDVN4lu2gBydFhKn27sOfNobCui6ZPXoPdVsIkCakx RjV08lRjkgTnvEXkVi5F+wHJ0bew2ltxli+h/uzL+Pt+i9Xawsw7bwKtwXDSXWJZCALaMF3YO0Mb sBQtvbfgda8BoP7MAWpPH8A5v5PZX76D8oOPoJo89PEyydFhlOMABjsZGdNVjlBsmYUqFsDJIkqB TOc7uWCCkKYb1uN1r8HfP4jV3ES+6wPoWp3qr56hsK6L0rc+B8D4XfdzYveTVNOYeGQM20Qx/tER MsfGME4WybuI56LyLuI6SDaL2DYmSXFXrcAEIeN3bwElzNmxGa/7Ut7aeCe1X+8ju3gh9af3U+t/ lgQIdIohwkYEsS0QhYkT0hOTMFE5qXEcIFYWcXOYMCA5NorTeQ46CJkaeApnayet998Fohjfug1F HrCwcjkQEAWkgtICqRhSMSQKUltIbUUimsK1V5O9+HyiWpU4DinvegKUMPsbvVjzF2IvmAdAVC6j pYDOe+h8jkRBMs2pATvFEKOJp02sjUH7NfIXLKXj0e9S3XeQ17quA3H45493U7jmCmZ8bC2dr78E GYvKnucpD/wGcs7pdidAgiHCoDEojSEWiJQhTGPCOMR67wKmhv7G1MBBCpesxLvqcoKoju/XOLLx U4zueJRweITRHY/w2qZPE6UJsYJYzDuQAnY6ncD3fXJennO2fJ3Sxh7Gf9bPm/dtY+kvd3LWl+5g eHc/pZ5u2q7v4c839yLZDOlUFbEtJJuBf+sXb1eiScWgEiBIItT8uZz78z7abr6WpF6nddPHmTh0 mGMPP0ZhxTI6dz3IuY89wKyejyDz51KbrBDlMkQZi1A0oZjTCKb3SAwpBpWYlFAM5+3cwsy1q3i1 9x4O9d4LwJLvbWbshQPEE2XaPnElwfAoA10bmHhjiNhzCJUhEP0uOJkoEYO1OONevCDW3e7MZto/ vBZxssy7YQPVN/5KyyXvJ9s+h5GnngMRXly/ieN/OASee9qR74ZEDD6aI2kwYCdiiPMOf3poJwuv 30Dpsg9yeHsfg1/4Gj1/HKC4+Gyeu/E24vIUYaWCPSNPYs7crw0QokkElMao0BImgyovf/U+AFre t5w1P+3D6ziLV769ldGhIabqU8RuFp+UQM4MX1J80aQYsSfR1UQ0oZfj9T1PsugX/Zx99ZUAvPjF exj8zjasoosW9R8O+l+hgJrRGIFQ9KTlGx2udPO3VEhtrTWVob8w/9LV7O39PAcfeAhV8NCWkGLO qMMpVEUzoVMcS0x/ffJeAVidL3zlCq9wd0WniDZ4xSK18XFs1234u5JgMECzsnihXtu2tzb1mVMD 0VmWy91+oevelFPyniRJlVhWA+Py7UeokDTQ+s3fB8GuV3x/OzD53zTtrlKl6Wv9f0P7Wo8BI6dE /NcAQhbE7cZc9jcAAAAASUVORK5CYII= --_011_4A6CE49E6084B141B15C0713B8993F2806E252SJEXCHMB12corpadb_ Content-Type: image/png; name=image008.png Content-Description: image008.png Content-Disposition: inline; filename=image008.png; size=4129; creation-date="Tue, 07 Aug 2012 23:45:25 GMT"; modification-date="Tue, 07 Aug 2012 23:45:25 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAZCAYAAADE6YVjAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAK T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3 AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+ 5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk 5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd 0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA 4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5 h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+ Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY /R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1 mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/ 0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5 hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9 rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7 vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO 32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21 e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i /suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8 IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq YAAAOpgAABdvkl/FRgAABUxJREFUeNqklk9sVNcVxn/3zbw3HjODwVGBpKocBBlinOIumiiQJsiu J1GahD9JqrTAoqWC0kVLAi1Gatw4sruAgLuoIhZNm0VVlHhs6tDQAPkDVQAvqFRCqkCwOnIlaGrj EjP2m/fmzb33dDGD04g/dttP+hZv8c53v3O+8+6DKnpzuSdF5INSqWSDIJD/h1rrT8fGxl5pbW2t v1afDRs2rImiSCYmJsT3fQnDUIKZMggkiiIRESmXy1IMApmYmJByuSyDg4PH0+l0TSyVStXs37+/ t66u7gtKKVzXRSkHZ0ZUeJ6HiLBr1y4WLlzIbfW34TiKIAhYtGjRncPDwxfiDQ0Ni+bPX7Akisp4 novWBqW4NQRQEI+7jI+Ps3HjRgYGBrh8+TI9PT1Ya/E8D2stDzzwtTbHcZxarcsOCoyxWGsxZhpa i+t6oKBYDDhy5AgA+/bt4+zZs7iuh7WC1oZkMlnriIgYY8VWBWbCRCLB0bePkm1ro1Qqkc1mmT17 NqVSiY6OjopZEay1aKPFufbw3wicPHmCNatXc+zYMdavX8fddzdSW1tLNvswBw8e5NAfD1GTrMFa i1jBATDG3LSosRZjDU4sxqxUCteNc1cmw7x583Ach3PnzvHqq7/hypUrtLa2kE6n2dnezuTkJAKV d0WEIAwJw5CoXEYbUy38+dP/49Il2tt3sGnTJkZHRtm1ezfWWh5auZI5c+YSRRHDw39n+/btPP74 E2ht8H2fqBRJXETQWlPWGqn2UimFAlCKRCLB0NAQT65dSz6fryxuby/9Bw7Q0trKn44fp6fnF3R0 PM8777zN+ydO4HkJgiAAwFpLXKrtMsaglEJEPpfWRCJBz94e8vk8L+3Zgz/p09n5Atuee46fvdDJ N59+itdef41fvfJrtNaIUGlV9bBWLHFEpqKplEXE4jgOyWQSx4mhlOL8+fN4nseqVau5444vcubM GQYGfg/At9et468ffsjSpiZqk0l8368sEVREjOAIYK3B2Iobqm76cn307N3DRx+dI5PJEEURBw70 k5qV5OttbQAMDw/T2fkiv/3dfhRQKExMBeUarZiqE2sxxhBzYlhj2blzB/19fQDkcjm6un9OLtdL d1cXWhsOvfkmAIsX30Vt7SwcJ0YYlq4ZmIJSCmuFOIA1Fmss7iyPI4ffor+vj1WrVvPggw+x4Pbb aWlpYceOdrq7u+h4/qcAbN36LMual1EoFG769amIWOIinw0eYGhoCIBHHn2UZ575FqMjI2zZspl7 7vkyA2/8gcHBUzQ2NrJ8+QqKfvG6oNxQBGRKJIoiGhruBKA/l+Oxx57gnyMjvDEwQOFqgc2bt7C0 qQmtNX6xCLcQuIGTSrqKfpHlK1awdGkT7733Lj/58TbS6TQAmSVLKAYB/uQkM8VnIshUuqJyRE1N kj17e/jBlu+T630dgK/eey/r12/A9yen2jq9AigUIqLiqrrkuqxxHIdC4SoXhi7wy5dfZvDUKVzX oy2bJZlMEpWi6xJ0qztHKYXWRpyxsbFP/KL/aVlrXNfl6OHDPPujH/Ln06f5zne/x5q1a4nH4oRh WI369LRWCMIAJxYjn8//LRaG4UTdnDlfuv/+5feNj18lUZPg0sWLrGxpJZVKERQDjDGIFcTaaWmt pVQKicfjFAqFwt6Xdm+LAZz94Mzp+vr6xZlMpnHu3LlkH36E+fMXUI4ipr+LrxsFXsJjbOxfn3R3 vbj144/Pv/ufFeqam7/yjWXNzfe5rps0xgr/AxzHkdHRkYsnT7z/1vj4+F/gxmOMMfPx3syMrv5u APDvAQA0od/2coVKtQAAAABJRU5ErkJggg== --_011_4A6CE49E6084B141B15C0713B8993F2806E252SJEXCHMB12corpadb_-- From gregory.mirsky@ericsson.com Tue Aug 7 16:52: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 A884621F8667 for ; Tue, 7 Aug 2012 16:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.388 X-Spam-Level: X-Spam-Status: No, score=-5.388 tagged_above=-999 required=5 tests=[AWL=-1.210, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWNLW9wapjcu for ; Tue, 7 Aug 2012 16:52:30 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 43A0A21F8623 for ; Tue, 7 Aug 2012 16:52:30 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q77NqQQa020481; Tue, 7 Aug 2012 18:52:27 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 7 Aug 2012 19:52:22 -0400 From: Gregory Mirsky To: Shahram Davari , "mpls@ietf.org" Date: Tue, 7 Aug 2012 19:52:13 -0400 Thread-Topic: draft-ietf-mpls-tp-use-cases-and-design-02 Thread-Index: Ac109rZq2Pfvls9SQTu4EKif2qQJBQAAEw+w Message-ID: References: <4A6CE49E6084B141B15C0713B8993F2806E252@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F2806E252@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_011_FE60A4E52763E84B935532D7D9294FF139264F0E89EUSAACMS0715e_"; type="multipart/alternative" MIME-Version: 1.0 Subject: Re: [mpls] draft-ietf-mpls-tp-use-cases-and-design-02 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, 07 Aug 2012 23:52:31 -0000 --_011_FE60A4E52763E84B935532D7D9294FF139264F0E89EUSAACMS0715e_ Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF139264F0E89EUSAACMS0715e_" --_000_FE60A4E52763E84B935532D7D9294FF139264F0E89EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Shahram, I think that RFC 5960 says the same as draft but differently in the very la= st sentence of Section 3.1.1: "Penultimate Hop Popping (PHP) MUST be disabled by default on MPLS-TP LSPs.= " I read it that it might be explicitly enabled, hence it is optional. Regards, Greg ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Sha= hram Davari Sent: Tuesday, August 07, 2012 4:45 PM To: mpls@ietf.org Subject: [mpls] draft-ietf-mpls-tp-use-cases-and-design-02 Hi, I am not sure it is late or not, but I found a discrepancy between This dra= ft and RFC5960. This draft says PHP is optional for MPLS-TP, while RFC5960= says PHP MUST not be used. Is there any way to correct this before IESG publication? Thank you, [cid:429314723@07082012-0B28] Shahram Davari | Technical Director, Network Switching Group Broadcom Corporation | (O) 408-922-7436 | (M) 408-660-5695 [cid:429314723@07082012-0B2F][cid= :429314723@07082012-0B36][cid:429314723@070= 82012-0B3D][cid:429314723@07082012-0B44]= [cid:429314723@07082012-0B4B][cid:429314723@07082012-0B52][cid:4293= 14723@07082012-0B59] --_000_FE60A4E52763E84B935532D7D9294FF139264F0E89EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Shahram,
I think that RFC 5960 says the same as draft but=20 differently in the very last sentence of Section 3.1.1:
"Penultimate Hop Popping (PHP) MUST be disabled by= default=20 on MPLS-TP LSPs."
I read=20 it that it might be explicitly enabled, hence it is=20 optional.
 
    Regards,
      &= nbsp;=20 Greg
From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram=20 Davari
Sent: Tuesday, August 07, 2012 4:45 PM
To:=20 mpls@ietf.org
Subject: [mpls]=20 draft-ietf-mpls-tp-use-cases-and-design-02

Hi,

 

I am not sure it is late or not, but I found a discrep= ancy=20 between This draft and  RFC5960. This draft says PHP is optional for=20 MPLS-TP, while RFC5960 says PHP MUST not be used.

 

Is there any way to correct this before IESG=20 publication?

 

Thank you,

 

 

 

Shahram Davari= |=20 Technical Director, Network Switching Group
B= roadcom=20 Corporation | (O) 408-922-7436 | (M) 408-660-5695

 

3D"Description:3D"Description:3D"Description:3D"Description:3D"Description:3D"Description:  &n= bsp;      =20

 

 

 

 

--_000_FE60A4E52763E84B935532D7D9294FF139264F0E89EUSAACMS0715e_-- --_011_FE60A4E52763E84B935532D7D9294FF139264F0E89EUSAACMS0715e_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=35434; creation-date="Tue, 07 Aug 2012 23:52:14 GMT"; modification-date="Tue, 07 Aug 2012 23:52:14 GMT" Content-ID: <429314723@07082012-0B28> Content-Transfer-Encoding: base64 /9j/4RSrRXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUAAAABAAAAYgEbAAUAAAABAAAA agEoAAMAAAABAAIAAAExAAIAAAAeAAAAcgEyAAIAAAAUAAAAkIdpAAQAAAABAAAApAAAANAADqYA AAAnEAAOpgAAACcQQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2gAMjAxMjowNjoxNSAxNjox Njo0OAAAA6ABAAMAAAABAAEAAKACAAQAAAABAAABCKADAAQAAAABAAAAOgAAAAAAAAAGAQMAAwAA AAEABgAAARoABQAAAAEAAAEeARsABQAAAAEAAAEmASgAAwAAAAEAAgAAAgEABAAAAAEAAAEuAgIA BAAAAAEAABN1AAAAAAAAAEgAAAABAAAASAAAAAH/2P/iDFhJQ0NfUFJPRklMRQABAQAADEhMaW5v AhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAAAAAAAAAA AAAAAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQAAAIEAAAA FHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRtZGQAAALE AAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAAJHRlY2gA AAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAAQ29weXJp Z2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJzUkdCIElF QzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAA AAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeFAAAY2lhZ WiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAA AAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29s b3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29s b3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxSZWZlcmVu Y2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVmZXJlbmNl IFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlWAFAAAABX H+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBjdXJ2AAAA AAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABtAHIAdwB8 AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsBAQEHAQ0B EwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHBAckB0QHZ AeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsECywLVAuAC 6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQTBCAELQQ7 BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYFtQXFBdUF 5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZB6wHvwfS B+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J5Qn7ChEK Jwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1DI4MpwzA DNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14Peg+WD7MP zw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLDEuMTAxMj E0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwWjxayFtYW +hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqeGsUa7BsU GzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMfPh9pH5Qf vx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQfJE0kfCSr JNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWspnSnQKgIq NSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9aL5Evxy/+ MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1wjX9Njc2 cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8JzxlPKQ84z0i PWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31DwEQDREdE ikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtTS5pL4kwq THJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19TqlP2VEJU j1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1XIZc1l0n XXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1lkmXnZj1m kmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8eb3hv0XAr cIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5iXnnekZ6 pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQdhICE44VH hauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaPnpAGkG6Q 1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtCm6+cHJyJ nPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSp N6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYB tnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD 1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+ 0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4Dbg veFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M 8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+S/7c/23/ ///tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8V GBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4O DhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgA IwCgAwEiAAIRAQMRAf/dAAQACv/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUB AQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJx gTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePz RieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYF NQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNU oxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//a AAwDAQACEQMRAD8A9Re1vJA+JMIZcAfa8DzDz+Rwc1GeYEyGjxd/qEPc48Oe74AAf9Mf9+SUptzg AXDc09xH97mf9JAxesdMy82/BxshtmVi/wA/UJluu06kbX7HeyzZ/N/4RG2O3A7XT3JDf++FrlxH 1aeWdZxM5oh3VW55J8dt3q6/9tpspUYjv/6L/wB02eX5eOTHmmSQccbhX7/DPL6v+p4cj3ySCzIB 0f7T49kXlOay6SSSSlKL3hvOpPDRyVE2SdtY3u8ew/rOQ5kF4dp+fb/3ypJS7nPMyYj6UGGt/rP+ k5yh+kkbXODjwOSR47H/AEG/11KD7QG6811+H/CWJaQZ9zSYce73fuN/kJKY+vkMiQ2xp4Ils/8A Vf5/82pNy5Gtbh5iCPyhOGFziHGT/hT2/k1D+SnfSRqzj93/AMikpk29juxb8Qp8qqDEjuO3+u3/ AF/0X84ptsLT8e3+v53+r0lNhJMCHAEag8J0lKSTFwBidfBJJT//0O4+ufVsro31bzupYbR9qpa1 tDiA4h9j2UBwYZ3bPU9RcC768fXk1OcxxczGl/2j7I0V3V2X1YeFY7e5jn03Odb+kwW+r/wP6Oy5 eldT6f1PLsZ9k6k/Bp2lttbKmPc6T9Jltvupdt/cVP8A5o4VbfVxcnKp6gIP283Pssc4cfaK7HfZ 7mf6Sr0kCT0H4s0MeIxBnm4Sf0YwlPh/2p/V/wDjXvPFV/Xr6w+tY/0hkZF4uxn9LZh2RhZTXGrC rfktbbbm2X1MtzMmn/RU2ekxVMf6ydatf0ijplNDM/GxiacL7I8l+W/KuxMyqfY3Apdi1fbMm176 fT/8893f0z619Q2Yefl41OCHg3XYnqsyLWN/wbtx9On1v8J6b1r9VwD1Hp92G25+M60ey6okOa4H cx3tLdzdw97N3vQu79O21pMBAxj7wqZ9ft8Uowh8nFL5eP0Tyej/AL986b9devuoys71W1Fj/SzM CzCtLelt9b7OzIvzGN/XbWUfp7aLP+t0/o7GKtZ9evrnhbB6TsrHbXea8sY3pHJZYMgdKz7aCG/Z m78Sy/0v0fq4q7lmB9bspjcXPzcfGxwALMjCD/tNgHt+ncPSxnP/ANJUz/i0rPqnj0H1+l5OTg5U 7nXMtdZvd/3ZpyXPqyP/AANLiPSP26JOHFHSWePEdvbjLJj/AOqT9HD/AIEMqT6r9Uv6h0PFuy7z bmtrYMwlgqi5zGZLq9lldbfZVkVfzX6NaZcD9Jwd/WdP/QrG1yrYFOdRSa83MOdcXEi01tpIbA/R +lU6v8737lak8Q773j/vqcPsYJAAkCQkB+lHi4Zf4/BJcgkajc0dj7GD+z9JKSfdO4j886Mb/VH5 3+v6RNGsxr2Ja5x/znpO0ILuexsI/wCjWxJCtIJkhjvpPP0nn91qeHbhAAfHtb2Y3x/rJ2te4yJn /SP7f1GIjGBogd9STyT5pKU1oY0NHZSSSSUxfWx/0hPgeD96AcV4+hZ8ngH8m1WUklNQOyaT72yw 8ubLo/lfvIjX7xO6QeDOn/R2f9UjobqW7tzPa48xwfiElLNj4eQgf9TKmDHw+5R9w5/Cf70+vYH7 o/6pJT//0fVUl8qpJKfqpJfKqSSn6qSXyqkkp+p7PoH6P9rhCZtnXb/1uf8Avq+XUklP1G/Z2/6e 6E9HJ/m/7H/fl8tpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp//Z/+0dyFBo b3Rvc2hvcCAzLjAAOEJJTQQEAAAAAAAvHAFaAAMbJUccAVoAAxslRxwBWgADGyVHHAFaAAMbJUcc AVoAAxslRxwCAAACAAAAOEJJTQQlAAAAAAAQbrNy3vn/dsPQ3CJIvyt90zhCSU0EOgAAAAAAjQAA ABAAAAABAAAAAAALcHJpbnRPdXRwdXQAAAAEAAAAAFBzdFNib29sAQAAAABJbnRlZW51bQAAAABJ bnRlAAAAAENscm0AAAAPcHJpbnRTaXh0ZWVuQml0Ym9vbAAAAAALcHJpbnRlck5hbWVURVhUAAAA DABwAHIAdAAtAGkAcgB2AC0AMAA3ADIAAAA4QklNBDsAAAAAAbIAAAAQAAAAAQAAAAAAEnByaW50 T3V0cHV0T3B0aW9ucwAAABIAAAAAQ3B0bmJvb2wAAAAAAENsYnJib29sAAAAAABSZ3NNYm9vbAAA AAAAQ3JuQ2Jvb2wAAAAAAENudENib29sAAAAAABMYmxzYm9vbAAAAAAATmd0dmJvb2wAAAAAAEVt bERib29sAAAAAABJbnRyYm9vbAAAAAAAQmNrZ09iamMAAAABAAAAAAAAUkdCQwAAAAMAAAAAUmQg IGRvdWJAb+AAAAAAAAAAAABHcm4gZG91YkBv4AAAAAAAAAAAAEJsICBkb3ViQG/gAAAAAAAAAAAA QnJkVFVudEYjUmx0AAAAAAAAAAAAAAAAQmxkIFVudEYjUmx0AAAAAAAAAAAAAAAAUnNsdFVudEYj UHhsQFgAAAAAAAAAAAAKdmVjdG9yRGF0YWJvb2wBAAAAAFBnUHNlbnVtAAAAAFBnUHMAAAAAUGdQ QwAAAABMZWZ0VW50RiNSbHQAAAAAAAAAAAAAAABUb3AgVW50RiNSbHQAAAAAAAAAAAAAAABTY2wg VW50RiNQcmNAWQAAAAAAADhCSU0D7QAAAAAAEABgAAAAAQABAGAAAAABAAE4QklNBCYAAAAAAA4A AAAAAAAAAAAAP4AAADhCSU0D8gAAAAAACgAA////////AAA4QklNBA0AAAAAAAQAAABaOEJJTQQZ AAAAAAAEAAAAHjhCSU0D8wAAAAAACQAAAAAAAAAAAQA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAA CgABAAAAAAAAAAE4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAA AAEAMgAAAAEAWgAAAAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAAAHAAAP////// //////////////////////8D6AAAAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAOEJJTQQAAAAA AAACABA4QklNBAIAAAAAACIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOEJJTQQw AAAAAAARAQEBAQEBAQEBAQEBAQEBAQEAOEJJTQQtAAAAAAAGAAEAAAAiOEJJTQQIAAAAAAAQAAAA AQAAAkAAAAJAAAAAADhCSU0EHgAAAAAABAAAAAA4QklNBBoAAAAAA2EAAAAGAAAAAAAAAAAAAAA6 AAABCAAAABYAMwA5ADEAMwAwAF8AZAAwADQALQAyAC4ANwA1AGkAbgBfADkANgBkAHAAaQAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAABCAAAADoAAAAAAAAAAAAAAAAAAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAQAAAAAQAAAAAAAG51bGwAAAACAAAABmJvdW5kc09iamMAAAABAAAAAAAA UmN0MQAAAAQAAAAAVG9wIGxvbmcAAAAAAAAAAExlZnRsb25nAAAAAAAAAABCdG9tbG9uZwAAADoA AAAAUmdodGxvbmcAAAEIAAAABnNsaWNlc1ZsTHMAAAABT2JqYwAAAAEAAAAAAAVzbGljZQAAABIA AAAHc2xpY2VJRGxvbmcAAAAAAAAAB2dyb3VwSURsb25nAAAAAAAAAAZvcmlnaW5lbnVtAAAADEVT bGljZU9yaWdpbgAAAA1hdXRvR2VuZXJhdGVkAAAAAFR5cGVlbnVtAAAACkVTbGljZVR5cGUAAAAA SW1nIAAAAAZib3VuZHNPYmpjAAAAAQAAAAAAAFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABM ZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAA6AAAAAFJnaHRsb25nAAABCAAAAAN1cmxURVhUAAAA AQAAAAAAAG51bGxURVhUAAAAAQAAAAAAAE1zZ2VURVhUAAAAAQAAAAAABmFsdFRhZ1RFWFQAAAAB AAAAAAAOY2VsbFRleHRJc0hUTUxib29sAQAAAAhjZWxsVGV4dFRFWFQAAAABAAAAAAAJaG9yekFs aWduZW51bQAAAA9FU2xpY2VIb3J6QWxpZ24AAAAHZGVmYXVsdAAAAAl2ZXJ0QWxpZ25lbnVtAAAA D0VTbGljZVZlcnRBbGlnbgAAAAdkZWZhdWx0AAAAC2JnQ29sb3JUeXBlZW51bQAAABFFU2xpY2VC R0NvbG9yVHlwZQAAAABOb25lAAAACXRvcE91dHNldGxvbmcAAAAAAAAACmxlZnRPdXRzZXRsb25n AAAAAAAAAAxib3R0b21PdXRzZXRsb25nAAAAAAAAAAtyaWdodE91dHNldGxvbmcAAAAAADhCSU0E KAAAAAAADAAAAAI/8AAAAAAAADhCSU0EFAAAAAAABAAAACY4QklNBAwAAAAAE5EAAAABAAAAoAAA ACMAAAHgAABBoAAAE3UAGAAB/9j/4gxYSUNDX1BST0ZJTEUAAQEAAAxITGlubwIQAABtbnRyUkdC IFhZWiAHzgACAAkABgAxAABhY3NwTVNGVAAAAABJRUMgc1JHQgAAAAAAAAAAAAAAAAAA9tYAAQAA AADTLUhQICAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABFj cHJ0AAABUAAAADNkZXNjAAABhAAAAGx3dHB0AAAB8AAAABRia3B0AAACBAAAABRyWFlaAAACGAAA ABRnWFlaAAACLAAAABRiWFlaAAACQAAAABRkbW5kAAACVAAAAHBkbWRkAAACxAAAAIh2dWVkAAAD TAAAAIZ2aWV3AAAD1AAAACRsdW1pAAAD+AAAABRtZWFzAAAEDAAAACR0ZWNoAAAEMAAAAAxyVFJD AAAEPAAACAxnVFJDAAAEPAAACAxiVFJDAAAEPAAACAx0ZXh0AAAAAENvcHlyaWdodCAoYykgMTk5 OCBIZXdsZXR0LVBhY2thcmQgQ29tcGFueQAAZGVzYwAAAAAAAAASc1JHQiBJRUM2MTk2Ni0yLjEA AAAAAAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAPNRAAEAAAABFsxYWVogAAAAAAAAAAAAAAAA AAAAAFhZWiAAAAAAAABvogAAOPUAAAOQWFlaIAAAAAAAAGKZAAC3hQAAGNpYWVogAAAAAAAAJKAA AA+EAAC2z2Rlc2MAAAAAAAAAFklFQyBodHRwOi8vd3d3LmllYy5jaAAAAAAAAAAAAAAAFklFQyBo dHRwOi8vd3d3LmllYy5jaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABkZXNjAAAAAAAAAC5JRUMgNjE5NjYtMi4xIERlZmF1bHQgUkdCIGNvbG91ciBzcGFjZSAt IHNSR0IAAAAAAAAAAAAAAC5JRUMgNjE5NjYtMi4xIERlZmF1bHQgUkdCIGNvbG91ciBzcGFjZSAt IHNSR0IAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZGVzYwAAAAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcg Q29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAALFJlZmVyZW5jZSBWaWV3aW5nIENv bmRpdGlvbiBpbiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHZpZXcAAAAA ABOk/gAUXy4AEM8UAAPtzAAEEwsAA1yeAAAAAVhZWiAAAAAAAEwJVgBQAAAAVx/nbWVhcwAAAAAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAo8AAAACc2lnIAAAAABDUlQgY3VydgAAAAAAAAQAAAAABQAK AA8AFAAZAB4AIwAoAC0AMgA3ADsAQABFAEoATwBUAFkAXgBjAGgAbQByAHcAfACBAIYAiwCQAJUA mgCfAKQAqQCuALIAtwC8AMEAxgDLANAA1QDbAOAA5QDrAPAA9gD7AQEBBwENARMBGQEfASUBKwEy ATgBPgFFAUwBUgFZAWABZwFuAXUBfAGDAYsBkgGaAaEBqQGxAbkBwQHJAdEB2QHhAekB8gH6AgMC DAIUAh0CJgIvAjgCQQJLAlQCXQJnAnECegKEAo4CmAKiAqwCtgLBAssC1QLgAusC9QMAAwsDFgMh Ay0DOANDA08DWgNmA3IDfgOKA5YDogOuA7oDxwPTA+AD7AP5BAYEEwQgBC0EOwRIBFUEYwRxBH4E jASaBKgEtgTEBNME4QTwBP4FDQUcBSsFOgVJBVgFZwV3BYYFlgWmBbUFxQXVBeUF9gYGBhYGJwY3 BkgGWQZqBnsGjAadBq8GwAbRBuMG9QcHBxkHKwc9B08HYQd0B4YHmQesB78H0gflB/gICwgfCDII RghaCG4IggiWCKoIvgjSCOcI+wkQCSUJOglPCWQJeQmPCaQJugnPCeUJ+woRCicKPQpUCmoKgQqY Cq4KxQrcCvMLCwsiCzkLUQtpC4ALmAuwC8gL4Qv5DBIMKgxDDFwMdQyODKcMwAzZDPMNDQ0mDUAN Wg10DY4NqQ3DDd4N+A4TDi4OSQ5kDn8Omw62DtIO7g8JDyUPQQ9eD3oPlg+zD88P7BAJECYQQxBh EH4QmxC5ENcQ9RETETERTxFtEYwRqhHJEegSBxImEkUSZBKEEqMSwxLjEwMTIxNDE2MTgxOkE8UT 5RQGFCcUSRRqFIsUrRTOFPAVEhU0FVYVeBWbFb0V4BYDFiYWSRZsFo8WshbWFvoXHRdBF2UXiReu F9IX9xgbGEAYZRiKGK8Y1Rj6GSAZRRlrGZEZtxndGgQaKhpRGncanhrFGuwbFBs7G2MbihuyG9oc AhwqHFIcexyjHMwc9R0eHUcdcB2ZHcMd7B4WHkAeah6UHr4e6R8THz4faR+UH78f6iAVIEEgbCCY IMQg8CEcIUghdSGhIc4h+yInIlUigiKvIt0jCiM4I2YjlCPCI/AkHyRNJHwkqyTaJQklOCVoJZcl xyX3JicmVyaHJrcm6CcYJ0kneierJ9woDSg/KHEooijUKQYpOClrKZ0p0CoCKjUqaCqbKs8rAis2 K2krnSvRLAUsOSxuLKIs1y0MLUEtdi2rLeEuFi5MLoIuty7uLyQvWi+RL8cv/jA1MGwwpDDbMRIx SjGCMbox8jIqMmMymzLUMw0zRjN/M7gz8TQrNGU0njTYNRM1TTWHNcI1/TY3NnI2rjbpNyQ3YDec N9c4FDhQOIw4yDkFOUI5fzm8Ofk6Njp0OrI67zstO2s7qjvoPCc8ZTykPOM9Ij1hPaE94D4gPmA+ oD7gPyE/YT+iP+JAI0BkQKZA50EpQWpBrEHuQjBCckK1QvdDOkN9Q8BEA0RHRIpEzkUSRVVFmkXe RiJGZ0arRvBHNUd7R8BIBUhLSJFI10kdSWNJqUnwSjdKfUrESwxLU0uaS+JMKkxyTLpNAk1KTZNN 3E4lTm5Ot08AT0lPk0/dUCdQcVC7UQZRUFGbUeZSMVJ8UsdTE1NfU6pT9lRCVI9U21UoVXVVwlYP VlxWqVb3V0RXklfgWC9YfVjLWRpZaVm4WgdaVlqmWvVbRVuVW+VcNVyGXNZdJ114XcleGl5sXr1f D19hX7NgBWBXYKpg/GFPYaJh9WJJYpxi8GNDY5dj62RAZJRk6WU9ZZJl52Y9ZpJm6Gc9Z5Nn6Wg/ aJZo7GlDaZpp8WpIap9q92tPa6dr/2xXbK9tCG1gbbluEm5rbsRvHm94b9FwK3CGcOBxOnGVcfBy S3KmcwFzXXO4dBR0cHTMdSh1hXXhdj52m3b4d1Z3s3gReG54zHkqeYl553pGeqV7BHtje8J8IXyB fOF9QX2hfgF+Yn7CfyN/hH/lgEeAqIEKgWuBzYIwgpKC9INXg7qEHYSAhOOFR4Wrhg6GcobXhzuH n4gEiGmIzokziZmJ/opkisqLMIuWi/yMY4zKjTGNmI3/jmaOzo82j56QBpBukNaRP5GokhGSepLj k02TtpQglIqU9JVflcmWNJaflwqXdZfgmEyYuJkkmZCZ/JpomtWbQpuvnByciZz3nWSd0p5Anq6f HZ+Ln/qgaaDYoUehtqImopajBqN2o+akVqTHpTilqaYapoum/adup+CoUqjEqTepqaocqo+rAqt1 q+msXKzQrUStuK4trqGvFq+LsACwdbDqsWCx1rJLssKzOLOutCW0nLUTtYq2AbZ5tvC3aLfguFm4 0blKucK6O7q1uy67p7whvJu9Fb2Pvgq+hL7/v3q/9cBwwOzBZ8Hjwl/C28NYw9TEUcTOxUvFyMZG xsPHQce/yD3IvMk6ybnKOMq3yzbLtsw1zLXNNc21zjbOts83z7jQOdC60TzRvtI/0sHTRNPG1EnU y9VO1dHWVdbY11zX4Nhk2OjZbNnx2nba+9uA3AXcit0Q3ZbeHN6i3ynfr+A24L3hROHM4lPi2+Nj 4+vkc+T85YTmDeaW5x/nqegy6LzpRunQ6lvq5etw6/vshu0R7ZzuKO6070DvzPBY8OXxcvH/8ozz GfOn9DT0wvVQ9d72bfb794r4Gfio+Tj5x/pX+uf7d/wH/Jj9Kf26/kv+3P9t////7QAMQWRvYmVf Q00AAf/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACMAoAMBIgACEQED EQH/3QAEAAr/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APUXtbyQPiTCGXAH2vA8w8/kcHNRnmBMho8Xf6hD3OPDnu+AAH/TH/fklKbc4AFw3NPcR/e5n/SQ MXrHTMvNvwcbIbZlYv8AP1CZbrtOpG1+x3ss2fzf+ERtjtwO109yQ3/vha5cR9WnlnWcTOaId1Vu eSfHbd6uv/babKVGI7/+i/8AdNnl+Xjkx5pkkHHG4V+/wzy+r/qeHI98kgsyAdH+0+PZF5Tmsukk kkpSi94bzqTw0clRNknbWN7vHsP6zkOZBeHafn2/98qSUu5zzMmI+lBhrf6z/pOcofpJG1zg48Dk keOx/wBBv9dSg+0BuvNdfh/wliWkGfc0mHHu937jf5CSmPr5DIkNsaeCJbP/AFX+f/NqTcuRrW4e Ygj8oThhc4hxk/4U9v5NQ/kp30kas4/d/wDIpKZNvY7sW/EKfKqgxI7jt/rt/wBf9F/OKbbC0/Ht /r+d/q9JTYSTAhwBGoPCdJSkkxcAYnXwSSU//9DuPrn1bK6N9W87qWG0faqWtbQ4gOIfY9lAcGGd 2z1PUXAu+vH15NTnMcXMxpf9o+yNFd1dl9WHhWO3uY59NznW/pMFvq/8D+jsuXpXU+n9Ty7GfZOp PwadpbbWypj3Ok/SZbb7qXbf3FT/AOaOFW31cXJyqeoCD9vNz7LHOHH2iux32e5n+kq9JAk9B+LN DHiMQZ5uEn9GMJT4f9qf1f8A417zxVf16+sPrWP9IZGReLsZ/S2YdkYWU1xqwq35LW225tl9TLcz Jp/0VNnpMVTH+snWrX9Io6ZTQzPxsYmnC+yPJflvyrsTMqn2NwKXYtX2zJte+n0//PPd39M+tfUN mHn5eNTgh4N12J6rMi1jf8G7cfTp9b/Cem9a/VcA9R6fdhtufjOtHsuqJDmuB3Md7S3c3cPezd70 Lu/TttaTAQMY+8KmfX7fFKMIfJxS+Xj9E8no/wC/fOm/XXr7qMrO9VtRY/0szAswrS3pbfW+zsyL 8xjf121lH6e2iz/rdP6OxirWfXr654Wwek7Kx213mvLGN6RyWWDIHSs+2ghv2Zu/Esv9L9H6uKu5 ZgfW7KY3Fz83HxscACzIwg/7TYB7fp3D0sZz/wDSVM/4tKz6p49B9fpeTk4OVO51zLXWb3f92acl z6sj/wADS4j0j9uiThxR0lnjxHb24yyY/wDqk/Rw/wCBDKk+q/VL+odDxbsu825ra2DMJYKoucxm S6vZZXW32VZFX81+jWmXA/ScHf1nT/0Kxtcq2BTnUUmvNzDnXFxItNbaSGwP0fpVOr/O9+5WpPEO +94/76nD7GCQAJAkJAfpR4uGX+PwSXIJGo3NHY+xg/s/SSkn3TuI/POjG/1R+d/r+kTRrMa9iWuc f856TtCC7nsbCP8Ao1sSQrSCZIY76Tz9J5/danh24QAHx7W9mN8f6ydrXuMiZ/0j+39RiIxgaIHf Uk8k+aSlNaGNDR2UkkklMX1sf9IT4Hg/egHFePoWfJ4B/JtVlJJTUDsmk+9ssPLmy6P5X7yI1+8T ukHgzp/0dn/VI6G6lu7cz2uPMcH4hJSzY+HkIH/Uypgx8PuUfcOfwn+9Pr2B+6P+qSU//9H1VJfK qSSn6qSXyqkkp+qkl8qpJKfqez6B+j/a4QmbZ12/9bn/AL6vl1JJT9Rv2dv+nuhPRyf5v+x/35fL aSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKf/2QA4QklNBCEAAAAAAFUAAAAB AQAAAA8AQQBkAG8AYgBlACAAUABoAG8AdABvAHMAaABvAHAAAAATAEEAZABvAGIAZQAgAFAAaABv AHQAbwBzAGgAbwBwACAAQwBTADUAAAABADhCSU0PoAAAAAABHG1hbmlJUkZSAAABEDhCSU1BbkRz AAAA8AAAABAAAAABAAAAAAAAbnVsbAAAAAMAAAAAQUZTdGxvbmcAAAAAAAAAAEZySW5WbExzAAAA AU9iamMAAAABAAAAAAAAbnVsbAAAAAMAAAAARnJJRGxvbmd4CbGJAAAAAEZyRGxsb25nAAAD6AAA AABGckdBZG91YkBWgAAAAAAAAAAAAEZTdHNWbExzAAAAAU9iamMAAAABAAAAAAAAbnVsbAAAAAQA AAAARnNJRGxvbmcAAAAAAAAAAEFGcm1sb25nAAAAAAAAAABGc0ZyVmxMcwAAAAFsb25neAmxiQAA AABMQ250bG9uZwAAAAEAADhCSU1Sb2xsAAAACAAAAAAAAAAAOEJJTQ+hAAAAAAAcbWZyaQAAAAIA AAAQAAAAAQAAAAAAAAABAAAAADhCSU0EBgAAAAAABwAIAAAAAQEA/+EmSGh0dHA6Ly9ucy5hZG9i ZS5jb20veGFwLzEuMC8APD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6 TlRjemtjOWQiPz4gPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0i QWRvYmUgWE1QIENvcmUgNS4wLWMwNjAgNjEuMTM0Nzc3LCAyMDEwLzAyLzEyLTE3OjMyOjAwICAg ICAgICAiPiA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjIt cmRmLXN5bnRheC1ucyMiPiA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4bXA9 Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcv ZGMvZWxlbWVudHMvMS4xLyIgeG1sbnM6eG1wTU09Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEu MC9tbS8iIHhtbG5zOnN0RXZ0PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvc1R5cGUvUmVz b3VyY2VFdmVudCMiIHhtbG5zOnN0UmVmPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvc1R5 cGUvUmVzb3VyY2VSZWYjIiB4bWxuczpwaG90b3Nob3A9Imh0dHA6Ly9ucy5hZG9iZS5jb20vcGhv dG9zaG9wLzEuMC8iIHhtbG5zOnhtcFJpZ2h0cz0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4w L3JpZ2h0cy8iIHhtbG5zOkV4dGVuc2lzRm9udFNlbnNlPSJodHRwOi8vd3d3LmV4dGVuc2lzLmNv bS9tZXRhL0ZvbnRTZW5zZS8iIHhtcDpDcmVhdG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIENTNSBN YWNpbnRvc2giIHhtcDpDcmVhdGVEYXRlPSIyMDEyLTA2LTEyVDE3OjAyOjQ4LTA3OjAwIiB4bXA6 TWV0YWRhdGFEYXRlPSIyMDEyLTA2LTE1VDE2OjE2OjQ4LTA3OjAwIiB4bXA6TW9kaWZ5RGF0ZT0i MjAxMi0wNi0xNVQxNjoxNjo0OC0wNzowMCIgZGM6Zm9ybWF0PSJpbWFnZS9qcGVnIiB4bXBNTTpJ bnN0YW5jZUlEPSJ4bXAuaWlkOkE2NzIxMzBCMzAyMDY4MTE5N0E1QzA4QzdBOUMwODY3IiB4bXBN TTpEb2N1bWVudElEPSJ4bXAuZGlkOkUxNkY4NzM3MzUyMDY4MTE5NDU3RDEzMkQxRDVFMkU3IiB4 bXBNTTpPcmlnaW5hbERvY3VtZW50SUQ9InhtcC5kaWQ6RTM2Rjg3MzczNTIwNjgxMTk0NTdEMTMy RDFENUUyRTciIHBob3Rvc2hvcDpDb2xvck1vZGU9IjMiIHBob3Rvc2hvcDpJQ0NQcm9maWxlPSJz UkdCIElFQzYxOTY2LTIuMSIgeG1wUmlnaHRzOk1hcmtlZD0iRmFsc2UiPiA8eG1wTU06SGlzdG9y eT4gPHJkZjpTZXE+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJjcmVhdGVkIiBzdEV2dDppbnN0YW5j ZUlEPSJ4bXAuaWlkOkUzNkY4NzM3MzUyMDY4MTE5NDU3RDEzMkQxRDVFMkU3IiBzdEV2dDp3aGVu PSIyMDEyLTA2LTEyVDE3OjAyOjQ4LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBQ aG90b3Nob3AgQ1M1IE1hY2ludG9zaCIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0 RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6RTQ2Rjg3MzczNTIwNjgxMTk0NTdEMTMyRDFENUUyRTci IHN0RXZ0OndoZW49IjIwMTItMDYtMTJUMTc6MDM6MjMtMDc6MDAiIHN0RXZ0OnNvZnR3YXJlQWdl bnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgTWFjaW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDxy ZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDpFNTZG ODczNzM1MjA2ODExOTQ1N0QxMzJEMUQ1RTJFNyIgc3RFdnQ6d2hlbj0iMjAxMi0wNi0xMlQxNzow NjoxMy0wNzowMCIgc3RFdnQ6c29mdHdhcmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNp bnRvc2giIHN0RXZ0OmNoYW5nZWQ9Ii8iLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249InNhdmVkIiBz dEV2dDppbnN0YW5jZUlEPSJ4bXAuaWlkOkU2NkY4NzM3MzUyMDY4MTE5NDU3RDEzMkQxRDVFMkU3 IiBzdEV2dDp3aGVuPSIyMDEyLTA2LTEyVDE3OjA3OjE5LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFn ZW50PSJBZG9iZSBQaG90b3Nob3AgQ1M1IE1hY2ludG9zaCIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8 cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6RTc2 Rjg3MzczNTIwNjgxMTk0NTdEMTMyRDFENUUyRTciIHN0RXZ0OndoZW49IjIwMTItMDYtMTJUMTc6 MDk6NTAtMDc6MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgTWFj aW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIg c3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDowMTgwMTE3NDA3MjA2ODExQjFBNENFMDczQzY3M0Q2 MCIgc3RFdnQ6d2hlbj0iMjAxMi0wNi0xM1QwOTozMjoyNS0wNzowMCIgc3RFdnQ6c29mdHdhcmVB Z2VudD0iQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2giIHN0RXZ0OmNoYW5nZWQ9Ii8iLz4g PHJkZjpsaSBzdEV2dDphY3Rpb249InNhdmVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAuaWlkOjAy ODAxMTc0MDcyMDY4MTFCMUE0Q0UwNzNDNjczRDYwIiBzdEV2dDp3aGVuPSIyMDEyLTA2LTEzVDA5 OjQ3OjQ5LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBQaG90b3Nob3AgQ1M1IE1h Y2ludG9zaCIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQi IHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6MDM4MDExNzQwNzIwNjgxMUIxQTRDRTA3M0M2NzNE NjAiIHN0RXZ0OndoZW49IjIwMTItMDYtMTNUMDk6NTE6MTctMDc6MDAiIHN0RXZ0OnNvZnR3YXJl QWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgTWFjaW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIvIi8+ IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDpE ODJERkUyQTE1MjA2ODExQjFBNENFMDczQzY3M0Q2MCIgc3RFdnQ6d2hlbj0iMjAxMi0wNi0xM1Qx MToxMDozNS0wNzowMCIgc3RFdnQ6c29mdHdhcmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9wIENTNSBN YWNpbnRvc2giIHN0RXZ0OmNoYW5nZWQ9Ii8iLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249InNhdmVk IiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAuaWlkOjA2RkU2QzkyMUQyMDY4MTE4RjYyRUFGRTIwMjBF M0M2IiBzdEV2dDp3aGVuPSIyMDEyLTA2LTE0VDExOjU3OjIwLTA3OjAwIiBzdEV2dDpzb2Z0d2Fy ZUFnZW50PSJBZG9iZSBQaG90b3Nob3AgQ1M1IE1hY2ludG9zaCIgc3RFdnQ6Y2hhbmdlZD0iLyIv PiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6 MDdGRTZDOTIxRDIwNjgxMThGNjJFQUZFMjAyMEUzQzYiIHN0RXZ0OndoZW49IjIwMTItMDYtMTRU MTE6NTc6MjAtMDc6MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUg TWFjaW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZl ZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDowOEZFNkM5MjFEMjA2ODExOEY2MkVBRkUyMDIw RTNDNiIgc3RFdnQ6d2hlbj0iMjAxMi0wNi0xNFQxMTo1ODoyNi0wNzowMCIgc3RFdnQ6c29mdHdh cmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2giIHN0RXZ0OmNoYW5nZWQ9Ii8i Lz4gPHJkZjpsaSBzdEV2dDphY3Rpb249InNhdmVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAuaWlk OjA5RkU2QzkyMUQyMDY4MTE4RjYyRUFGRTIwMjBFM0M2IiBzdEV2dDp3aGVuPSIyMDEyLTA2LTE0 VDExOjU5OjA5LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBQaG90b3Nob3AgQ1M1 IE1hY2ludG9zaCIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2 ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6MEFGRTZDOTIxRDIwNjgxMThGNjJFQUZFMjAy MEUzQzYiIHN0RXZ0OndoZW49IjIwMTItMDYtMTRUMTE6NTk6MjctMDc6MDAiIHN0RXZ0OnNvZnR3 YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgTWFjaW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIv Ii8+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlp ZDozMUM2OTQxQTJBMjA2ODExOEY2MkVBRkUyMDIwRTNDNiIgc3RFdnQ6d2hlbj0iMjAxMi0wNi0x NFQxNToyNjoxOC0wNzowMCIgc3RFdnQ6c29mdHdhcmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9wIENT NSBNYWNpbnRvc2giIHN0RXZ0OmNoYW5nZWQ9Ii8iLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249InNh dmVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAuaWlkOkYzMTUzRDIzMTkyMDY4MTE5N0E1QzA4QzdB OUMwODY3IiBzdEV2dDp3aGVuPSIyMDEyLTA2LTE1VDEyOjE4OjI0LTA3OjAwIiBzdEV2dDpzb2Z0 d2FyZUFnZW50PSJBZG9iZSBQaG90b3Nob3AgQ1M1IE1hY2ludG9zaCIgc3RFdnQ6Y2hhbmdlZD0i LyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5p aWQ6RjQxNTNEMjMxOTIwNjgxMTk3QTVDMDhDN0E5QzA4NjciIHN0RXZ0OndoZW49IjIwMTItMDYt MTVUMTI6MTg6MjQtMDc6MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBD UzUgTWFjaW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJz YXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDowRTQ2QzEwRDFGMjA2ODExOTdBNUMwOEM3 QTlDMDg2NyIgc3RFdnQ6d2hlbj0iMjAxMi0wNi0xNVQxNDozMDoxOC0wNzowMCIgc3RFdnQ6c29m dHdhcmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2giIHN0RXZ0OmNoYW5nZWQ9 Ii8iLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249InNhdmVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAu aWlkOjBGNDZDMTBEMUYyMDY4MTE5N0E1QzA4QzdBOUMwODY3IiBzdEV2dDp3aGVuPSIyMDEyLTA2 LTE1VDE0OjMwOjE4LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBQaG90b3Nob3Ag Q1M1IE1hY2ludG9zaCIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0i c2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6QTQ3MjEzMEIzMDIwNjgxMTk3QTVDMDhD N0E5QzA4NjciIHN0RXZ0OndoZW49IjIwMTItMDYtMTVUMTY6MTE6NDUtMDc6MDAiIHN0RXZ0OnNv ZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgTWFjaW50b3NoIiBzdEV2dDpjaGFuZ2Vk PSIvIi8+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1w LmlpZDpBNTcyMTMwQjMwMjA2ODExOTdBNUMwOEM3QTlDMDg2NyIgc3RFdnQ6d2hlbj0iMjAxMi0w Ni0xNVQxNjoxNjo0OC0wNzowMCIgc3RFdnQ6c29mdHdhcmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9w IENTNSBNYWNpbnRvc2giIHN0RXZ0OmNoYW5nZWQ9Ii8iLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249 ImNvbnZlcnRlZCIgc3RFdnQ6cGFyYW1ldGVycz0iZnJvbSBhcHBsaWNhdGlvbi92bmQuYWRvYmUu cGhvdG9zaG9wIHRvIGltYWdlL2pwZWciLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249ImRlcml2ZWQi IHN0RXZ0OnBhcmFtZXRlcnM9ImNvbnZlcnRlZCBmcm9tIGFwcGxpY2F0aW9uL3ZuZC5hZG9iZS5w aG90b3Nob3AgdG8gaW1hZ2UvanBlZyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0 RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6QTY3MjEzMEIzMDIwNjgxMTk3QTVDMDhDN0E5QzA4Njci IHN0RXZ0OndoZW49IjIwMTItMDYtMTVUMTY6MTY6NDgtMDc6MDAiIHN0RXZ0OnNvZnR3YXJlQWdl bnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgTWFjaW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDwv cmRmOlNlcT4gPC94bXBNTTpIaXN0b3J5PiA8eG1wTU06RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFu Y2VJRD0ieG1wLmlpZDpBNTcyMTMwQjMwMjA2ODExOTdBNUMwOEM3QTlDMDg2NyIgc3RSZWY6ZG9j dW1lbnRJRD0ieG1wLmRpZDpFMTZGODczNzM1MjA2ODExOTQ1N0QxMzJEMUQ1RTJFNyIgc3RSZWY6 b3JpZ2luYWxEb2N1bWVudElEPSJ4bXAuZGlkOkUzNkY4NzM3MzUyMDY4MTE5NDU3RDEzMkQxRDVF MkU3Ii8+IDxwaG90b3Nob3A6VGV4dExheWVycz4gPHJkZjpCYWc+IDxyZGY6bGkgcGhvdG9zaG9w OkxheWVyTmFtZT0iRm9sbG93IEJyb2FkY29tIG9uIFR3aXR0ZXIsIEZhY2Vib29rLCBHb29nbGUr LCBMaW5rZWRJbiBhbmQgWW91IiBwaG90b3Nob3A6TGF5ZXJUZXh0PSJGb2xsb3cgQnJvYWRjb20g b24gVHdpdHRlciwgRmFjZWJvb2ssIEdvb2dsZSssIExpbmtlZEluIGFuZCBZb3VUdWJlIFN0YXkg Q29ubmVjdGVkOiBSZWFkIHRoZSBCcm9hZGNvbSBDb25uZWN0ZWQgQmxvZyIvPiA8cmRmOmxpIHBo b3Rvc2hvcDpMYXllck5hbWU9IlRBTEVOVCBBQ1FVSVNJVElPTiIgcGhvdG9zaG9wOkxheWVyVGV4 dD0iVEFMRU5UIEFDUVVJU0lUSU9OIi8+IDwvcmRmOkJhZz4gPC9waG90b3Nob3A6VGV4dExheWVy cz4gPEV4dGVuc2lzRm9udFNlbnNlOnNsdWc+IDxyZGY6QmFnPiA8cmRmOmxpIEV4dGVuc2lzRm9u dFNlbnNlOkZvbnRTZW5zZV8xLjJfQ2hlY2tzdW09IjIxNjk2MTE2MDMiIEV4dGVuc2lzRm9udFNl bnNlOlZlcnNpb249IjUuMDEuMiIgRXh0ZW5zaXNGb250U2Vuc2U6RmFtaWx5PSJBcmlhbCIgRXh0 ZW5zaXNGb250U2Vuc2U6T3V0bGluZUZpbGVTaXplPSIwIiBFeHRlbnNpc0ZvbnRTZW5zZTpLZXJu aW5nQ2hlY2tzdW09IjAiIEV4dGVuc2lzRm9udFNlbnNlOkZvdW5kcnk9Ik1vbm90eXBlIFR5cG9n cmFwaHkiIEV4dGVuc2lzRm9udFNlbnNlOkZvbnRLaW5kPSJPcGVuVHlwZSAtIFRUIiBFeHRlbnNp c0ZvbnRTZW5zZTpDaGVja3N1bT0iMjE2OTYxMTYwMyIgRXh0ZW5zaXNGb250U2Vuc2U6UG9zdFNj cmlwdE5hbWU9IkFyaWFsTVQiLz4gPHJkZjpsaSBFeHRlbnNpc0ZvbnRTZW5zZTpGb250U2Vuc2Vf MS4yX0NoZWNrc3VtPSIyMzY3MTYxNzI2IiBFeHRlbnNpc0ZvbnRTZW5zZTpWZXJzaW9uPSIwMDEu MDA2IiBFeHRlbnNpc0ZvbnRTZW5zZTpGYW1pbHk9IkhlbHZldGljYSIgRXh0ZW5zaXNGb250U2Vu c2U6T3V0bGluZUZpbGVTaXplPSIyOTc1MyIgRXh0ZW5zaXNGb250U2Vuc2U6S2VybmluZ0NoZWNr c3VtPSIxMzg5MzQiIEV4dGVuc2lzRm9udFNlbnNlOkZvdW5kcnk9IkFkb2JlIFN5c3RlbXMiIEV4 dGVuc2lzRm9udFNlbnNlOkZvbnRLaW5kPSJQb3N0U2NyaXB0IiBFeHRlbnNpc0ZvbnRTZW5zZTpD aGVja3N1bT0iMjM2NzE2MTcyNiIgRXh0ZW5zaXNGb250U2Vuc2U6UG9zdFNjcmlwdE5hbWU9Ikhl bHZldGljYSIvPiA8cmRmOmxpIEV4dGVuc2lzRm9udFNlbnNlOkZvbnRTZW5zZV8xLjJfQ2hlY2tz dW09IjE1NTIyNjEyNzEiIEV4dGVuc2lzRm9udFNlbnNlOlZlcnNpb249IjUuMDEuMiIgRXh0ZW5z aXNGb250U2Vuc2U6RmFtaWx5PSJBcmlhbCIgRXh0ZW5zaXNGb250U2Vuc2U6T3V0bGluZUZpbGVT aXplPSIwIiBFeHRlbnNpc0ZvbnRTZW5zZTpLZXJuaW5nQ2hlY2tzdW09IjAiIEV4dGVuc2lzRm9u dFNlbnNlOkZvdW5kcnk9Ik1vbm90eXBlIFR5cG9ncmFwaHkiIEV4dGVuc2lzRm9udFNlbnNlOkZv bnRLaW5kPSJPcGVuVHlwZSAtIFRUIiBFeHRlbnNpc0ZvbnRTZW5zZTpDaGVja3N1bT0iMTU1MjI2 MTI3MSIgRXh0ZW5zaXNGb250U2Vuc2U6UG9zdFNjcmlwdE5hbWU9IkFyaWFsLUJvbGRNVCIvPiA8 L3JkZjpCYWc+IDwvRXh0ZW5zaXNGb250U2Vuc2U6c2x1Zz4gPC9yZGY6RGVzY3JpcHRpb24+IDwv cmRmOlJERj4gPC94OnhtcG1ldGE+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPD94cGFja2V0IGVuZD0idyI/Pv/iDFhJQ0NfUFJPRklMRQABAQAA DEhMaW5vAhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAA AAAAAAAAAAABAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQA AAIEAAAAFHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRt ZGQAAALEAAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAA JHRlY2gAAAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAA Q29weXJpZ2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJz UkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEW zFhZWiAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeF AAAY2lhZWiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNo AAAAAAAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBS R0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBS R0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxS ZWZlcmVuY2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVm ZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlW AFAAAABXH+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBj dXJ2AAAAAAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABt AHIAdwB8AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsB AQEHAQ0BEwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHB AckB0QHZAeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsEC ywLVAuAC6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQT BCAELQQ7BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYF tQXFBdUF5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZ B6wHvwfSB+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J 5Qn7ChEKJwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1 DI4MpwzADNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14P eg+WD7MPzw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLD EuMTAxMjE0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwW jxayFtYW+hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqe GsUa7BsUGzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMf Ph9pH5Qfvx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQf JE0kfCSrJNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWsp nSnQKgIqNSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9a L5Evxy/+MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1 wjX9Njc2cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8Jzxl PKQ84z0iPWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31D wEQDREdEikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtT S5pL4kwqTHJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19T qlP2VEJUj1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1 XIZc1l0nXXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1l kmXnZj1mkmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8e b3hv0XArcIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5 iXnnekZ6pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQd hICE44VHhauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaP npAGkG6Q1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtC m6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n 4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSc tRO1irYBtnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePC X8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA5 0LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLf Kd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o 7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+ S/7c/23////uAA5BZG9iZQBkQAAAAAH/2wCEAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQECAgICAgICAgICAgMDAwMDAwMDAwMBAQEBAQEBAQEBAQICAQICAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA//AABEIADoBCAMBEQAC EQEDEQH/3QAEACH/xAGiAAAABgIDAQAAAAAAAAAAAAAHCAYFBAkDCgIBAAsBAAAGAwEBAQAAAAAA AAAAAAYFBAMHAggBCQAKCxAAAgEDBAEDAwIDAwMCBgl1AQIDBBEFEgYhBxMiAAgxFEEyIxUJUUIW YSQzF1JxgRhikSVDobHwJjRyChnB0TUn4VM2gvGSokRUc0VGN0djKFVWVxqywtLi8mSDdJOEZaOz w9PjKThm83UqOTpISUpYWVpnaGlqdnd4eXqFhoeIiYqUlZaXmJmapKWmp6ipqrS1tre4ubrExcbH yMnK1NXW19jZ2uTl5ufo6er09fb3+Pn6EQACAQMCBAQDBQQEBAYGBW0BAgMRBCESBTEGACITQVEH MmEUcQhCgSORFVKhYhYzCbEkwdFDcvAX4YI0JZJTGGNE8aKyJjUZVDZFZCcKc4OTRnTC0uLyVWV1 VjeEhaOzw9Pj8ykalKS0xNTk9JWltcXV5fUoR1dmOHaGlqa2xtbm9md3h5ent8fX5/dIWGh4iJio uMjY6Pg5SVlpeYmZqbnJ2en5KjpKWmp6ipqqusra6vr/2gAMAwEAAhEDEQA/AN92txOPlvLU1mVp wOSYdwZqiQcAcJT5CKPm30t9f8T7917pNSxbeR3EWf3RG4AuabMbkrlQG3KiZq6FtVvqQfrx73+X WvzPUH+NU9I1qbsanRg2kQ7vx+PSEsCF8SSwRbYqbliAC0kjBj+f0+/fl178+nyDceTgiWbJYday iI/4u+1ak52jItq1y0CxQZaO4/swx1QH5b8+/U69XpR47KY7L0/3WMraetg1FGaCQMYpB+qKePiS CdDwyOFdTwQD711vqf7917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v 3XumrLZqgw0UT1kjtNUuYaKiponqa+vnA1eCio4g01RIByxA0ovqYqoJ9+690mchlM4lOa7J1uP2 djmdY4YniXN5+oke/jhjWORsfFWyW9NPDFkGc/pb8e99az0nq6o3XFRyZBdwZXB46IkjIbrk2nRy zFwBCq4eg2hU1BSSThY5J6epP0K6jYbx6dez69R03bvnF0hravF0GcxUektlq4RbFDKSwGiPNV88 0zPYaNVLTh7/AOt79QevXqnrJRd07Zey5nHbg29IqxNO+Qxc0tJEKjV9u/no/PKYZ9J0MYlDWNuB f37T17UOlrjt9bOywH2G5cNMxAIieuhp57EXv9vUtDPx+fTx+feqH069UdKlHSRVeN1dGF1dGDKw P0KspII96631y9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//Q39JG 0DUI3kYDhUC6j/gC7Igv/iQPfuvdM09TuJiRRYnGov4kyOYmif8A2EFFi65W4HN5Vtf8/T3vHXs9 RCN4sSGTa7RE2aMtlCWQ/VC5jK3K8X0W/wAPx79jrWek5Pg6tJmqpNmUENSeWyGy9xNjMrIeCTIJ 6TbkUxB40y1MiMPrwSvv1fn178uk1Uhkr45xPVnM+mGmfJQw7R3kwtZYKXLeBdrbwVQCFp5UMZIu XJ97691q9d//AM5/5e9b/NnfGOwWdwyfG/pfuqHqjdmxp9gbaCbiotv5nLYTcdRmtySY3Kbyxu6M 2Nt5WemOOr4qOFqVNNPKius0W7jzbudvvVwsTD93QzaCukGtCQatTVU0YihpjgfPtr7T/cM9lua/ u68q3W92Nw3u7zBy6dyt7v6qdGhaeKKaBY7ZZVtGhh+oto5hNEzsZG/UjLJ4e3jFLFPFHNBJHNDK iyRSxOskUsbgMkkciEo6OpuCCQR7lDriX1k9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173 7r3Sey+caknjxWLgXJZ6qj8kFDrKQUlPrWNsjlZ1VzR0ERbjgyTMNEasb231qvTGVh25Mksvk3Lv bMxiKMeiKaWJGBkjp1PkjwW26F21OeRexYyzsNXuP2de/wAPXGSNMHNS5LL33HvLJa6bGUdMBHHD qCtUUuGgmLR4zF0y2apq5PWygGRiTHGPf4Ovf4esdRH/AAqWkyeaVdw7xrmaLB4qnJWjopjGPNFi IZtS0VHTI16rISjylP1EAxw+/de/w9YqiB6Cto5K1YNz76rleXHUzBo8TgYNQWarpoW8v8LxVGTp apYNWVb2QMSQie/wde/w9M+Z25DlaxcV5DnN5eOCrrNyVRZKTalOzjx/aUEMnhgWoDP4KDk1SgtU u6gs3v8AB1qn7egprtmU82QbGiGlrBBWPjTm55Xhx+UrKWqp6gY3bry00mNwWZEc8sD0kzyYwyR+ ONC2sRWr1qnWel2ZiqBJJoZq2mWjlaCqrJarIYpMfUTHUtPuShopWqtsV9iBHXItZjJEs3jVSp9+ r1ug6VVHQ5ajm8cOa3RFPTx/cyUL5WurapKZrWr2xcde9LuTHMbXqcbNGUBCml1XUe/Ide6EHF5/ JoKYTVEGShqgBSSySU/jyJF7pjcxTw0lK9WoBH2tVT082oEa2sW91630uKKvp65HaFmDxN46inlU xVFNLa5iqIW9Ub2Nx+GHKkgg+9db6me/de697917r3v3Xuve/de697917r3v3Xuve/de6//R38Zm nAtTxxu/4aaQxxj/AF9CSOf9YD/Y+/de6ZZcXmaxj9zuGejiP+6MNRUdMSP9S9VkI8pUH/g0fiJ/ w+nvf5de6TFVHsinleCu3Fkq+tU/uUq7t3BXVge9uMVjMkwidibAJApP0H9Pfs+nWsevXCT+60h8 kFBvsk3Xy0VN2JQFdNiGjYGj1I4P6kurjgkj37Py691DrKigFPJA+fzVPSSJolx++trZCtwcikD0 TVeRxeNqZLagGb751H1IPvf5de60Icnt6Tsj4kfMDvxaN3GV+ZfT2ZFfFQ414qenyOC+Qk9XSLVz LDm8ZDV1PY9G7RIggqWhiLqGgGmC2T6nad4v6ZN5Ga/aJa/POsV/L06+m2y3Icn++vsD7YiTTHb+ 326waO+haObYghNCyEom3yhSSdIdxq7xXdU+NXYGVy/RvSW9qGV2h3t0/wBb71mxtVRSwRVUO4tm 4XNTZD+G0lLGyQMtaXavxMGhS16ugjfUVmjb5fqLCxn/AI4Ub9qg/L1+XXzn+62yf1Z90fcnlzTT 937/ALhbU9PAu5oqfE/8PHU3+mPHo2+D3di814IS32GQqIjNDRVMsLisiXhqjFVtPJLQ5elUjl6e R9H0cI11CunQCr0qveut9e9+691737r3Xvfuvde9+6910zKqlmIVVBZmYgKqgXJJPAAHv3Xuke+d rc4zUu0xG9OGaOp3PURmTFU9rqwxMd0/jlWtuGQikQ/qkYgxndKcetceHUYS0+BeXB7egbNbnrSl VkKismLsjygIuW3LkI0JghEY/ZgRQzqvjgRUF09x48OvfZx69+1tgFI/LuHeWcCli5EdTXvD6fLL pEkeG27jWlPAHjiDWUSTP6/cfs69w+3rohdtWrKstuHeecH2sEcVonqjGTL9lQRsXTE7fxxfXLIb hV9cjSSsur3H7OvcPt69b+7aHI5AjObyzzLSU0MF4/uJB+5HisWjhzj8FjtXkmlYcKDNKS5A9+/w de4fb1xZanbtOEjaLL723NLp8r+Radp4lZmkKFnkpNubfhlJVAQSLC5mmJb3H7Ovf4esc1HJjoqf aWGqpmzGY8uSz2cfT95DRyMIsjmpWAKJkK6QCnoktojt6R44Cvv3zPXvl0rkw2LTFLhPsaZ8UtMt J9jJGstO0CgemRJA3kJI1Fmuxb1E3596630gsttnJYx46vHyV2Rp6WMxUtTTtHLufEUty7UeurPg 3bgxzejqyahRzG8kmm1q9a6SUE0Jip4o4qc05qiKWlpKh6DHjJj9b7VyNS0dZszcim5bE1pSGViU RrF3b3WunSOrDGdnkpZXq5hR1j1sBoMdl6z06cZurH6NW2t02t4axUWGdtNrgpGPdb6dYK4pJHIt VPSzQSpj6bIZIEVWNrG8bJtvdyKf8opakkfa1l2D6gVcsVeXXXuhAxWUTJwyaonpa2kk+2yNBKbz UVWEVzGWsBLDIjh4pV9MsbBh/Qa6306e/de697917r3v3Xuve/de6wLUwyO0cciysps4jOsIf6Oy 3VD/AIEg+/de6z+/de6//9LfqqVyEoKUklNSA/WomjaqkA/OinWSCPV/Qs5A/wBSfz7r3VePye/m Nfy7fh72HQ9V/Lz5a9c9adj5TauN3vR7K7CzmRhnn2rlslmcRjcz/AMJjJMOKOtyO36yKMTxtMRA SfSQzbr1qnQb77/nY/ypepKDYkuV+ZHQ9Fiuyto/372DX4rdGPfb+49oruTcezJM/jq/HRzQTY+n 3ds/K4uUxJI8WQxtTTsokglVPfn178ulxu3+a98D9ndBbe+Ue5fmf8WdvdC7vy2V2/tPf9H2EN+R bm3HgoYajO7XwGC26KHcma3ZgKaqilyGKpKSauoklQzRoro59jreep2Q+efxp7Y+E/bfyu6p+Xvx 0zXRW3trbsw2X7qlfJUmwtnbnkoYsRQYvesv8Yy+c2nkkzG4MarUtTi6ivKVkLR0c/nhSRmdXeCZ IqeIUIFeFSMVwcV+R+zo75YvNu27mTl7cN5SRtogvoJJxGA0hhSVGlEal4gXKBgoMkYLUBdPiGu9 R9R9D9NfyVt77i378vvh+2xvk78jNv1nR3yRx3ZG+h09nMvtStx1BWbL/itb1HQbin3FHH1DvaKS nFE8cFRRAFktUFAPb8qXsfL19tbzRfVyTK6kFtAA0cTo1A0DcFPl8+umHNX36PbrefvX+2fvZt+w b8nIWz8v3FhcwvDarfPLOL86oolv2tniDy2hrJPGw0zHQxWLVbN/Lr+W3xNzvwu2zQ7Z+Xfxl7Po PjH1pRw93bm697LhqNs9cYTa8OSSj3bvXFbnptm7r2jgxgsSzruOGloQxp5mZahYXlYX7TazWW22 dpcMpljQKStSMcKEgHhTiB1gV76c6cu+43u/7hc+cqWt1BsO77lJdRJcoiTqZqPIJEilnQHxS5Gi VwQQcfCBU+OP8zr+X78udzb02V8e/lZ1J2duvZWPym593bZoczFR5dcDg/E2Z3nT4XdNHtaj7C2r hFljepz2H+1rKRXQzSMWVmMOonp1P6O/nCfy9e6u1qjo3pn5tdHdidiU0OQmpNswbqqsric9T4nH VeYycmzt31lFj6rNpjMPj56uqNMc5FSUsMkry+NGdfYPW89CDsv+cH/Lv3x0r2l8icL8nusMj0l0 jldp4TtntDDZ18ttDY2V33kqfD7OocxKtHS5+KbcmVqkp6Qfw4eaUkLcq+nXXvy6OD0v8mOivkR1 ptHuPpXsbD9hdX78o6zIbP3rhabLphc/RUGUr8LWVVBNkMdRSNDT5bF1FOxZF/chYfj3rr1R0Jn9 8cEw/wAnkyNcx4EePwWcr31cWDfa46VYr3+rlVH1JA59+p16o64nL7grfTituSUqm9q3cVXBQQj6 WeOhoGyWRlIB/RKtNci2ofX3vr2fTplyVPioHibe2eGYqHbXS7fp6eSKgmYXIWm2xRPXZHMsCeBU NV2IBAU+/fZ177enO+4s2qw0sT7Tw+kIZ5Vp5Nw1EIAASkpF81DhY2T6PKZp1HHijYXHsfn17PUK kraWlSTCbGo4a6oWeX+IZaaSabFUdW1vuKrK5Qs9RmssWtqhjkeZjYSPEtm9++3r3yHWXVS7YbwR fcbj3hmVV31si11eEkZRPUMimDDbfoHlYKABFELqgklaz+4/Z17h9vXarHtmN8tlnbM7qzLJSRRU ifu1UvqlgweDglb/ACXF0vLu7kCwaedvqR7jgde/w9dLp2+ku4M/av3LlSlFTUlAGmca/XS7dwMc zKfChQvNKRGJGDTS6EUBPcfs69/h67QvgIJ9wZ2+Q3HlfFR09DQgyaGbVJRbcwysLmJZAXlmbT5G DTSFI1Cx++Xl17/D08bfxU+PhqKvIvHPm8tKKzLVEVzEsgXRT0FKzAOKDGQWiiBtqs0hGuRr+P8A Lrw/n0oPeut9e9+690l83tPGZozT6TRZCaD7eWtp44XFVCOVpspRVEctDlqQNz46iN9P1Qo1mG69 ap0E+bwW7cAHmXHyZykjgNManFxnI1DUFjegq8VWyyVeTxWktahqHqhGCTDVwEhfe8HrWR0lafem PMrU0sqw1KQCj+3yEdVPeiIYSYXJwVMa1mYwTa7Ikkf8RoXYtCamO7e90PWq9K7GbjEFRSVlA7TT QLFTQJLVxyyVmPmlcw7bylaZXgqpBJqOGyesxTsDBIySM4fVOt16GCDcuBnoYcicrQ09LMpYNWVM NG8TI3jlhqI6l43gqIJQUkRgGRwVIB916tXrAN14abjHy1OXY/oOHoazIwP9OfvqaF8eim/DNKqn +vvdOtV67kyOYkQyLQUmGpx9anN1kTyKObH7LHyyQtcc+qqjI/pf6a631Ejanqv87W1+4X/440MY gxfNxp1QmGikQn8T1Ep976108RtPFGvmWixdKnpSJHV3A5spfTDTwk/6lQ/+v711vpyRldQVJKn6 Egi4/qLgXB9+691//9Pfiq6XJ1hMa5H+GwHgmhgilrWB/pU1iTU8Nx/SBmH4YHn37r3XzQ/513W3 yW7e/nPfODdW3vjn8193bVxfx7pPj58cdwdZfBmD5XYrfu+JuqtlY+rwM03aNBFiNo7Hy+7ty7pv vHa38W3NhJVhOKpS0rvT+690T74/fywP5lGW7E39T/7LXX9A7p+BP8sDtrelJRdt/FnL977E7ezz YvcPY8vUOw8D2dtvd2y8/wDIHsGo78rJIoYoa0YLcdFWrR0oNJBH7917p4+FfxR7A+FPcP8ALx+T vzZ/lmfMr5GfFmp6M7oy0nTm1Omdw9pyYr5DZDtDurrnE/3t603XT7d27trM5VcJt3Kpi8maOpfH zY6ugFfNRrG3uvdR+uvgd/NL3zHkPh1tv+XN36nXHyk+R2J+dnePxwxObpfjXtTH9NbOq8qOv+hI O7e2MVSdedSblq8XuXIVNTjq/wDiVfAkG2ZjQNXUL0sfuvdRJtgfK9/5cH8ur4j9vfBT5h5va3QH 8xvv7f3eO19l/GPs7K7urelMPTdFZ7H/AMImfEYzB56s3NUdt9gUeKMtdBSyzUBAqYYmMre690vf l3/K5/mE949c/wAwP+YF8dPgV3p8Uuiu7+9Ordr7X+FWL6+qtu9qZ/44Y2jzm69zb8zvQ+DoY9wU +PwfZeydlZeqSlx8zGuyuQqIJJqGiq6p/de6NZ8qOhs587Ojvkl2R/L0/kfdw/Eqk6o+OXWvV3V3 eG7Id9dGd890bIh3RtTH9m9R7Q+MmxKeHqvvXOZDYuWzqZHOoMruKvwVCkFTVy1UlJj039nWuirb 86E7V+S+yfiLvz4Vfy4PkT8RsF/LQ+H26sj3f3Fu3oqt683V3t8q9uYCjjO0tqV20dvVO5u5Mzub tzApGkdU0udig3BlDWw0FJApPuvfn1XpX/y/P5lPX/x57p6Wofj78g8d01n9nfFX5a7owrdM9itm N47+nw1Hsba/XuLmo9qwPkc3gKv5D5XKZLBsKh6Kk28Zp1jqqQn3rrfX0n/5P249zdffGbr74Z5L or5XdOVHwz6A+LOyNzdi9i9Y4aj6o7d7D3703iN+9jHpmuEOR3PuKk2ZuiumgzAMSJQVVbHBqdwx XfWura/43KBeo3pkKVT6SKjZNTj5wxU8KtfjhpkT8hkax4I9+61+fXmqcTVC1XuLfedDAHwY/F5m jgcEXsJdrYHFsISRb9yYrzZmPv35Drf7enLHLUUaum2NkJjDObzV+aqKLF+clgTLP9k2XzNZIoJN p0jLEAah9R77T177B1iylPSxhG3xudJUmJMOBx5kxVBUgg/s/Y001Rm85wpBjeV4nsf2R9PfvsHX vtPU+GfN5CGOkwONTa+JjVYo6/JUkcdaIV404rbyhUpRp4V6wxlD9adx79jr3UWCoxuEmq8Xtylm 3DuSeRWyc8lR5ZVn0kpPuTNsjxUUcSNdIADIFNoYNP09x48Ovf4espSl2438Yzc75vdGSBpKVKWn BqJT/nRhtuUDOxpaJLBpWZ/Vby1ElgCvuPDh17h9vXJF/hIn3ZuudP4iYzS0VDTGSpgxUFTIgixO KiVRJkMrXyqgllCeSeSyIFjUA++Q698z1Mw+Mq6qs/vHnYgmTkiaLG44lZItv0EhJNOjK7xyZSrW xq51PNhGh8a+rx9B1759Kr3rrfXvfuvde9+691737r3XvfuvdNuRw+Jy6eLK4zH5KPSVC11HT1QU Hn0+aN9HPPFrHn36tOvdBjmOk9nZDVLjVrMDUlSB9lMKiickhrT0FeKiKSLUAdCNGCQPdtR60VHQ cjYe+tgVP3mNig3Bih4zUth6akpsl44I1hjkaklpZ6lZ1TUWanMryFiXP597qD1qhHStwm5UzETH z19W6MRNFLubedF9sF/UlVLiduvDG6MAbO6mxN7j3rrwPS0o5MUGSULs+Cb6LNWZWoylWjDTrCyZ Kloqo2uCeV5Fj/Uaz1vpRpU+YevLmUWt48RQNbjjTq05GYcfkMv9eB711vqTFEFYPTY6R5QOKvJT Hyf64eRqqrX/AFtKD/W/HutdShUCJtNRVJJMfpT00ZLD/DxqZZmH+JsP9b37rfX/1N135aZr5L7a 6V3HnPibsjbPZ3dlNkNvR7b2PvHIUmG21ksdU5yhg3HPXZCo3v12Ulx+BknmhAzFNqlQALKbRlBu cm4RWcj7XAkl5UUVsAiorxZeAr5j8+pT9mdp9p979wNq273s5nvtn9vHinM91aIzzo6xOYAqpaXr EPMEVqW70UnKfEKb8v0t/O5+ZTx7H7i3D1V8FuqnCx7sbqTMUlXuTdNJK+iYUsmzuw+xtz5OYxOy yUdRuXCY+oiZhL5CFUhOS15x3ciG8ljs7bz0HJ+zSzk/ZrUHrO/bOd/7vX2BR9/5A2fePcPnLjb/ ALxiZYIGGQX+qsrGBBWhWVbG7mRgNGkVPTk/8hWm6wo497/GD5j97dbd94+IV8W8szWY9NvZ3OJL NUSxV0OzqTb+48XisqZPHN5qzM6FeRpIqlWMR3/UoWw8bbt2mjvRnUaUJ+emhAP2t9h4dNL/AHkM vN878v8Au97Fcubt7bStoNrErmaGEgKChummgkkjpqXTFa1IUK8JAcYsV/Nl+R/wnqh1T/Mz+Nm+ qzL4t3o8D310vjsBWbd7LpYo3FNXw4/JV+1tkVuQqPGss0lBk6GWJJQk2LpZY2R9LzPuG0H6bmHb 3LjhJGBR/nQkLX7CPmoPV7z7lntX7/wnnP7pXuvt0djMA02z7o8yz2DEjUheNLi7RFqVQTQTKxUt HeTIwZQJqO9vkX/OI+W3VFJ8eIO+egvhr1RKJ+xt6x5/LbEq8/TzV9Lktz02ZyeyM+2Hqt1Z+ixl PiMNi6evycmO8k1c5WF6gRoje3/Ne6WosBPBtMXxtUrXNTUqaajQKoBNMtwr1IsXt17W/cX9lOdJ /c+TlvmX333oUsbQwx3awsEaO3aKO7h8VbeF5Hubq4eGBZ6R26guseraTVVRVVVCqoCqqgBVUCwV QLAAAcD3JHXHsksSSak9azHf+/fk3/Kz+fW5PkLnh3X3b8Ge4UzMmQw8e6NwbtxPX0m6J6fLZDA4 yjz+Ul27tDcW0N20vlwq1BpKauwE7UUNQj/cNTx5fT7jy3vcl8/jTbNLWoqWC1yQKmilW+GtAVwD xp1q9tOW/aT74n3bNq9sdt/q/wAv/eI2IxBJTbw20l6LcNGk0jQxie5gubZtN0U8SSK8QXDxMvhC URdy/wA5ve/yuj/0Qfy8viX2b2J2PuVRj6ndPcOE29R7P2DHUEJ/Hcxj9s7o3HgFgplYtFVZfNYu ip5whdKkHwOpbm6fcSLbYNtle5b8TgBV+ZoSPzZgPt4dBGx+4Jyv7Rxvzh96j3k2bb+T7bvFrt0k z3F6Vz4Mb3FvBNqJwY7a1uJWXVpaIjxFY5/5HPYPdFEvYvzQ+WPa/bPb2VpVqK+g2LkMZBhdm1bR gxY/btRvXG5Klz2MxsjELTUlJtmAJdYVXjV4cnS348fet2lkuzntppX5CoOPsCj5dVk/vCNi9spB yz93P2K2PauQ4DoDXayG6ulXAlm+nljIkZQKtPPeSE9zyMcBNbe+OX83T4PSVuL+Jfa+3PmD05E7 wU/WnaMiUme2qsrqwpa/Z29904GvwHjWRhoxGf8At6mzSmmRmUDy7bzXsrFNtuUu7TyWQ0I/3plp T+i9Dx0jp6+93fuL/eOgS/8AeXky/wCQuexmW92pGkinpxqba0uBIz0FTcba0sY0oty6gnqwb4Q7 /wDnn2LmOwR8vvjv1D09SY2g2/Lsf/QrvigxGey+SqZ8r/eOPOYTF919kQ/5HTw0jIKyHGgtKxDT ciI+2e43+ZpxvVjFCoA0aCDU5rWkj8Men59YtfeE5W+6zy7Z8rv93T3J3rf72WWcXy30UkYhRVi8 Ax69q26pdjKGo0tAq4Ti1h4q6+lIWbJ9jY0AgGCr23itwxpYm6/dYPCZiVvwC7VDrbm97n2e/s6x i/b12c4LETb5r6cPzGDtP7OoADfXTW4uUMpAIv4xf8e/fl1qvz68ajFTkrVbg7AzgIBEVHi81RRM rLqA8+1tvYdPGy/QvLY/S5N7+/Idb/b1Px0clG7NtzYn2MswtLk81U0GMee/9qompnzOdqWH9Jol J+lx9R77T178uu8lEYo0m3nuuGippLquIxMrYSlqWPAgNR55c9k5T9NEMsKyXsYjwB77B177T1lo 6mvlpkoNoYCHCYxPTHk8vRtjqVFJ9ctDt9Pt8nVyMOQaj7RGJ1amtY++09e+wdYlkxG362UI9bur eNVEqyKpgqcsYnbUkb6fBj9uYfXyA328Btf1yfX3H7Ovf4enbH4WrnrI81uKSGpycWv+HUFMzvi8 EkgZHFJ5FjasyEkbaZKuRFcqSsaxoWDe+zr329Kj3rrfXvfuvde9+691737r3Xvfuvde9+691737 r3Xvfuvde9+690jNxbHw+ekFciLjczEdUOVpYovKWH6RVxMPHWICB+r1i3pYc32CR1qnTFTHcWBI hy0tWadTZcjRVxlpXS/p1/xqLKR0rEfUSPSxKSAhP49g9e6VUFXUSIrvUZoK4upTH4+cEH8rNRQV lObH8gke/db6k3ST9UGarD/qZb0qE/0ZHehgP+xFveuvdSEWqjjIhp6HGQgXLSESuP6s0UPhhB/x Mrc/X37r3X//1d/j37r3Xvfuvde9+691gqaamrKealrKeCqpaiNoqimqYo56eeJxZ4poZVaOWNwb FWBBHvRAIIIqOnIpZYJEmglZJlNQykggjgQRkEeo65xRRU8UUEEUcMEMaRQwxIscUUUahI4oo0Cp HHGigKoAAAsPewAAABjqru8rvJI5aRiSSTUknJJJySTkk9ZPfuq9e9+691FoqChxlLFRY2jpcfRQ a/DSUVPDSUsPkkeaTxU8CRxR+SWRmawF2Yk8n3oKqgBQAOnri5uLuZ7i6neWdqVZ2LMaAAVYkk0A AFTwAHUr3vpnpmyeAxeWeOeqpytZApWmyVJNNQ5OlB5Igr6R4apIy3JTUY2t6lI9+r16nSbr9sZS ZVSaXCbqp4gPBT7qxsMdfDpNx4c5jKcrCR+GNE8lwCWJvfdetU6bBR1dBcfwre+HC8+XB5+LcmNU 6vUKehylVV1KL/tK0CrbkC9/fuvdd/xd4QQ28dyUpAF/49sk07AA6SA6bdxEEjM5sGXUrW9N7E+/ fl178+sn8YU6lfsWIHxebRT4bHJVqgIOsRTQ1LWP0IMZNzYc+/fl17/bdYzU4ipA+43JvzOg8iPH Y/L0qMLm6mbamAxQRbrpJeQW4BNzz78uvfmepuPiFJKZdvbCenqZOGy2cqKDGySggqfNViTM7hks v18kHIPH59+/Pr32Dp2OHzuSv/Gs61LTE/8AFt23HJjQy8eipzE0k2Ul/PqpzRnnkG3PuvdPuOxe OxNP9rjaOCigLGR1gjCmWVra5p5OZKieS3qkcs7Hkk+9db6n+/de697917r3v3Xuve/de697917r 3v3Xuve/de697917r3v3Xuve/de697917r3v3XumtsNji7SRQNSSMSzPQTz0DMx/tSCjlhWU8f2w wP59+6913/C1/NdkytrafvpR/resWlv/AI6r+/de67GIx+oPJT/cupur1ss9cyn+qmsknKkfi1rf j37r3X//1t/j37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+ 691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3 Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//2Q== --_011_FE60A4E52763E84B935532D7D9294FF139264F0E89EUSAACMS0715e_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=1408; creation-date="Tue, 07 Aug 2012 23:52:15 GMT"; modification-date="Tue, 07 Aug 2012 23:52:15 GMT" Content-ID: <429314723@07082012-0B2F> Content-Transfer-Encoding: base64 R0lGODlhGQAZAHcAMSH/C01TT0ZGSUNFOS4wFQAAAAlwSFlzAAAOxAAADsQBlSsOGwAh/wtJQ0NS R0JHMTAxMgAh/wtNU09GRklDRTkuMCwAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADqYAAA OpgAABdvkl/FRgAh/wtNU09GRklDRTkuMBgAAAAMbXNPUE1TT0ZGSUNFOS4wzfpCa7cALAAAAAAZ ABkAhwBpngBqnxR/rgF0pgBvogBwowp5qRZ+rQNxpABvowBuogR2pwBzpQBxpAN1pgBtoQVxpAJy pRB8qwV2pwBuoRR+rBV+rABypQJ0pgBypA97qgZ2pwBsoQd3qABxowN1pwN2pwR1pxF+rhmBrxyI tR2Jth6ItRWCsh2ItR2HtR6JtjF1lD12kCd5nSOPvSeKtTOSuiCLuDeDpSaRvjuGpjOPtjeRuCaR vzqGpzmSuTyUuieIszWQuDyGpiKLuTiFpiKMuyCItCGDriGKuCKJtimTwCyWwiyZxy6WwUmBmkaZ vUOYvUCawVKlyFWnyUmhxVCgw2KeuH6yx3C41We00mi00mez0mm103W82Gq102m002231WWz0m23 1Gu102u202641G221G693Gu21G+51XC51m631Wy31GKx0WOy0WOx0W641XG51nO92mGuznS51XzA 2nvA2n3B24GTnI2Zno6ZnoyYnZafo5qxu5mstI6lr4+msI6lsI2kr42kroGxxIKzxoa2x4/C1ozG 3JHI3ZDI3JDI3onA1oLE3YLD3ITC24HB2o7B14/B15TE2YPK5o7N5InJ4YvO6I7L443S7Y7S64vN 5YzP6oLG4YrO6YHG4I/S64TH4Z/P457P45TK4KK1vam2u6SzuKSzuau1uaStsqitsKrM2rHY6LLZ 6a/Y6MfX3dvd38PGx8zNzcDc6cXf6sLd6cTe6sXe6sfj79vu9cLg7dTn8NDk7t/t9N7t9Nrq8svi 7Ozt7uzs7PT6/Ofx9unz9/n8/fb5/Pr9/eDt9Pr8/efx9+fy9+vr6/r6+ujo6P///wECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwj/AJkJHEiwoMGDqwQNIlSoocOHDQ0dOtWL IKhHkBDBicOxo0eOciJJkuJLICs5k6ZQqcKypcuWVq4kooRHYKhKWKxk2cmzp88rWiz9ESjq0pYr PLlw8cm0CiZAAkdl6oI0ixdFir4w7VlFE1RmojaBQVolzK9fXaps3VmFUyCBecSMIVPGjJlOns5U QcMFTRo1VNZMYeOlTRSBelwIeMGkiRtUqa4sovVJVS1bb5w8gTEihgyBe2YMIECggAFgwQ5AYSbs Fi5mrxAkIKCABA3QMxYwYNDAQS5dD2owgwUhwq5hEgrwLnGbWWjdvCfkylXABjNGACjEIlZBeQPm oG9AzW8gnbp1RgEIyBLWfXnz57vJFytWnVmj9LOMtf+OQyCf3PFNcAwyBeTAjCPp8cKMBd6V0B8z fQDIwAUY6KBDBhoosUMDGfCwxAYZLNeDQBFCt9sDDzCQAQcJ7KbAAxfEV8KIzOgh3m445qgjjt/R 6EcRHYS445C7eeDDDwKRAkQQBQhJZI4eGGBEEgIls8IRJnTwAQhcdukllyGIgMQJpQzUCgtCDIHC mmy2SQIKKahARAtzKEPQMqbQoScdddSxJ5+A2nGHKwcVaihBAQEAOw== --_011_FE60A4E52763E84B935532D7D9294FF139264F0E89EUSAACMS0715e_ Content-Type: image/png; name="image003.png" Content-Description: image003.png Content-Disposition: inline; filename="image003.png"; size=3853; creation-date="Tue, 07 Aug 2012 23:52:15 GMT"; modification-date="Tue, 07 Aug 2012 23:52:15 GMT" Content-ID: <429314723@07082012-0B36> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAZCAIAAABLixI0AAAACXBIWXMAAA7EAAAOxAGVKw4bAAAK T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3 AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+ 5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk 5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd 0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA 4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5 h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+ Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY /R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1 mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/ 0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5 hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9 rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7 vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO 32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21 e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i /suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8 IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq YAAAOpgAABdvkl/FRgAABDhJREFUeNqsVTtvHGUUPed+Mzu762eMTUKUOA8lSBilSIIl8hCvAokG mjTQQEEFEiUVBb+BKkJIFCkgUgqQiIgoKAJIUUBWQIGERxIlspM4Nthe7+7sY757KHZjb3iIhk9T jL7RHJ1z7r3nUhL+p5NsvH07v3x5qV7JSiAhEAD/5SeBxmartWWo8vT20fGhSu+akmKMJ89f6uw6 UEXR6EYHCAgiSP4DkABA5RBCSO6trJwYrs88uq/P6+yFufbeQ2yu/7DeiYILXakSzIGOKwsPAPYs EQTh4XKYnpw4c2v97elWuVxO2u32pTyZVPfSWrvnXDWxl3cOPz6WReni7+1ztxsiDOwRIiGBgIj5 ZpFavfzIzrkfrxw9fDDpFkUsirVO0XFPjFF4fd/YgfFSQzDipR3JWMlO3aiVbJNXj5kEo5baxd4R W16rATCSkjouhzqu6aH0wHjpboF7heY7+iPiqanKSGrrhTcLNQtvu7vkgiAHCleUywUgISBAkgsR mswMQM0VARfWXBOBx6cqS60iMbqw2I7X1jsBIOCSgxtNlUjqxFgGyI0aoeXIBQEpAeDEzuHBSn6z lL9/bc0AkiQ6cof6dVzMW6o1Fhp5OUnangGIQFcwYDXip7ZSIgARaAsTgcemKldrnU/nay53j57Y fr+PRbLlfi9vR7QfG00A1CPqQk/IagR7igAXrkvPjnB2ovTelaZRQ8GEvpqk538wpsFMNBJA7qpH GCAgarBPIYBgFCywREsDgxk3/CJpNDOTYGYA2hF5IRIV49TmmMGF3RmHibN36oFmBjOz+72cADDQ jIEE+7xarmaUA9vKeG4kDBq/2okfXF///E5jKA1RCuQGWAKARiODGdDHake0Ihwo/K/jeKtZfLWc w5iQcDej0TZ5ETDSSJHB+rxaUSKWuvgl98FU2j+WnTy87c25xWv1Tk8gBzX2+qT3YaUrABWiVqhs uJ7r16ZvGO/AeOBbO9JXd4+9c3kpIc34oF+kkUakwW40urWuHxkN39Vix5H8LXNudnWzpV3VpBSC QUaQ/aSzfuSRJIOxEXV6ob63zFe2pqMBeVRz4KlH7c64p8yr9a56w0waSRBAIsDNKsF6BammduZ2 MzV7bXp4diRbKVQMuEVgMuVK1z9aaJSDuVQKJBklAEkpTYtmfXs1G0oaXTEBy4GnbzfnasUzk+U9 1ZAZB/pLF1biZ3fz5Y6SwFah6WraKHy8kgFIsiw7mrYutoqDk8O/reW5YORwsIVWPLXQTMwCjexn SXQV7gGqBBpsTzUd37Ll56+/nH3hiX7ed7vddz/8+M6h56e3TkkiLRjNEAxmMMIIAe5wwR3R4S4C zSLevHD+jV3V40ee7GMByPP8k3NffL+4WoDWzx5avyj9FSJJgqD7a5APBb14bHZmZmZzD23YURRF jLEfwP91SGZZNnjz5wCK81KNPiIliQAAAABJRU5ErkJggg== --_011_FE60A4E52763E84B935532D7D9294FF139264F0E89EUSAACMS0715e_ Content-Type: image/png; name="image004.png" Content-Description: image004.png Content-Disposition: inline; filename="image004.png"; size=3749; creation-date="Tue, 07 Aug 2012 23:52:16 GMT"; modification-date="Tue, 07 Aug 2012 23:52:16 GMT" Content-ID: <429314723@07082012-0B3D> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAZCAIAAABLixI0AAAACXBIWXMAAA7EAAAOxAGVKw4bAAAK T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3 AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+ 5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk 5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd 0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA 4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5 h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+ Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY /R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1 mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/ 0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5 hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9 rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7 vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO 32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21 e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i /suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8 IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq YAAAOpgAABdvkl/FRgAAA9BJREFUeNqslc1rXFUYxt/nfc+5985kzIclpk0tCQl1CLRpFy5iQYR2 URFEEcS13fgHCN26FtyJblwJggilCxEUFypWRYTa0KQaaPNh0wxkzOSrmU7v3HPO6+Le+Wgx1IVn NffOOb/3ed7n3HOgqvQ/DdP9tbPX/HWhvnfQSpLkvxXQrO2qk0NnqsfyZ+TLrt9YuHa7dGS4EtS3 M/9kDJEASWwOUtjm0ttvvgQAqpqm6Yef/35iYnpjc3drNw2Ha3JenQ9d0UMVO3280nTx9MDaxfNz hohuLi4NjIzX6jt3N5tW8O8YUDsLYyNJdWJkdDiJLKvqj/P1hTvbs9Wx+TsHF8+TIaL9+03Voc3G A9VwmL92O1QnBt957WQSS/flrZXd5Xv37zdTBYreM3P6MGu3nc8C8LgcIoSg1vBbFyb6QUQUfHDO pakjDb0cffDee+c8QFTwQEQAiDTNwuyJwaNHSvnkVuq/+mm9sZeubOyDgg8+BC1YqqGdtoNqUEUe UlcVNHPabLlS0ts9P9+sf/b1chJLpWRE2PvQbrcLlnN+dXV9s9GUKCmVEmutGCPCAEKgqfFKOTGT xwa6rErJvHh2LI7k1u366tqW8S1qNXoenQ+7uwetdM8YyyLGWGONMSZzdOmVuXNnj/a3ae7U6Nyp USJ69/3a3Xtbx0fLCbhggYjBYqzxAhYiOKfOOSXfSr3zh25dMcYYy2IooKsLABMEDLAAIAgAIo5h rv/RaLb8s2OV0yefzhHL63tLazvW8Ob2Q2stwKCOLiUlFoAJBAiYCQwwgWODL75d3T/I3rgw2WV9 91vtg0/nK2WJLcdxTBB0Pea6AAEAZrAULGIASWIDSZxEXWuRNZWBUqXEqiFzDmAl9J8TIHDHIxel CiIAyit35nbqEQAlMKGPBTDA4PwPAfIQGOjUoB4LYLBhZlUPKMDoZxEYzESaU0Dcpw7MAPd9PQAg uRYgPNL7jsd8MIiJJQfla3LYI6giaCoMdnWpkrVGRKgwn+cgfZkqQR7rF5goKJitMSElImIiKieW NIyPVjKnRdUi2aJ3BLGmx4qMEDER+0BxZAafKnuXFrrOzM58cvXK1My5zFFtKw2aa0YeIEGiCH/+ lX50taYhgHRpbT+ORCkMVaKZqeG/tx+8MBP3zvvvf7j28ZWVyeeeZzHOEbEAhpgZBhAIO480Cxq8 Bm9FrSjIR5Y2avVxc+O9y5eiKEL3yllcXPzym18ae5kIq5IP+QGW753iZiBSyudrAMMKna4+8/qr L5fL5Z6u7kjTNF/2xGsNgDFGpNfHfwYAQFicrB4gTtcAAAAASUVORK5CYII= --_011_FE60A4E52763E84B935532D7D9294FF139264F0E89EUSAACMS0715e_ Content-Type: image/png; name="image005.png" Content-Description: image005.png Content-Disposition: inline; filename="image005.png"; size=3902; creation-date="Tue, 07 Aug 2012 23:52:17 GMT"; modification-date="Tue, 07 Aug 2012 23:52:17 GMT" Content-ID: <429314723@07082012-0B44> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAZCAIAAABLixI0AAAACXBIWXMAAA7EAAAOxAGVKw4bAAAK T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3 AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+ 5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk 5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd 0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA 4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5 h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+ Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY /R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1 mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/ 0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5 hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9 rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7 vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO 32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21 e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i /suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8 IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq YAAAOpgAABdvkl/FRgAABGlJREFUeNqslV9sFEUcx38zu/dv7+pde+1dbZGYtrRgY8WKsWmLxIgx 8oQPxsQXX8REjApEQozRJ1+QxDTUqFUeJEajJiZGjIYCpQjYitJSKE1aiqHtdWnT+7+319vdmd/P h20PQqqBxMnnYWdmf9/5/mZ+O8uICP6nppafzIvDhfOnS/Nzd6+tBgLB1s0V23eolVEAYK6v9E/f Z8+dXpaoMOCM3aWWQGIMQsFg7NW9vvoHOACUErOZswMFITWFexlDIf4NFcDLWBlN4QpArlDI9B8j IpWI8mN/lYRUgTIO+Ftaqzc/5tGCd1i4OfRbYeRCzX0VRJQxi/5HtpRSS5WZJQ9jlsDC1bGoEFxK aVm2IDJDkcbd+6x0aubLz6aOfJyenAhvaAlvaDHmbmQmJ4yRC9GKEBIhERHUdm6NNG9yu5yBJLIs i0spbcdGorY9B/SBfu9iIhLUqjyKMdg/d+o4EcU7uhfPnKwKBd1IJCJYOZ7yCCI5jqMSESIhker3 Zy8OuzEAEPB5F/t/ru3oVAPa+udfTP34neWI6PbnAKAKwB+tiTRDFgAA5PQUX0wQkQoA0rbcxRTG EW+VhEeK5KWR2o7uSFPLvO0AQKR502o1aK4cANiZjD0zvVJfdiqZvjRCjm3o8/5YjRqqcAN8qlpK LgGiv7KKAAJez0xfDwAsW87GN/enJ65kjv0gCkbRyHsde52rRURCOCClt25d7uoo50wJaExReEBj uSxJsTD8u72gKz4vAMjlomkUHCNfvKnbc38DAEqUjAEAd7UkESFufPmVdMGUSLZpWvl8LpEgIchx xj/tweRiUU8U9YSVSdv5XHpi3NQTEmkForIWkCTHyEcamx/a805WQrFkF0s2xuvrurcNvfu2sjBP BIjk4vd65z4/bAyecLuEhJJW9guBJNHxl3a2vvZWXde2+7uezE1PAUC4qfnsvt18YV5VFXn7FcCY oioA4A5KIg5wK0ckDDGc6j108oUdv+x8xjby1W2PZq9NSn2WK2zV0NpIQkkIq3sPbr15FMWjKEBU 17kVCLVY3FG8qhTsP792QkJ2my+J6GILgUQTR48QohaLdx7sgXi9LUT5hTXBsi8EQiJb9dQ83hlu bNLitbnr046R94RC4YbGroM9V/p6F8+cUlVlTV+SiGP5LiRAhKe/+FofOjf5zVE7uQQA17/9Slv/ YMf7H2jx2va9B4YNIzvyJ+dsrRwB2WpNIBEiXu7rvXz4kMykFIW7lOZnB9/YNdP/KyC17XrdFs7a OdJKjhwA1OqYAnBj4ATjXBKVQSK0SqM9H5oLuhaL+apjt8+6CKSSRBbQGGMcACId3Z6AfxnJFFJI vKMBY0tjoySlFovfMWVJmXOEByj41LOcc2ZZVjKZHD/Vn/rkIyubdvAefkucgY8xb/sTzfvfa2ho YFLKfD6v6/rstancH+dFaunutRhjvofb69q31NfXx2IxRkSWZWWz2XQ6bZqm4zj3pOX3+8PhcDQa DQaD/wwA2uRn79BoYwAAAAAASUVORK5CYII= --_011_FE60A4E52763E84B935532D7D9294FF139264F0E89EUSAACMS0715e_ Content-Type: image/png; name="image006.png" Content-Description: image006.png Content-Disposition: inline; filename="image006.png"; size=4048; creation-date="Tue, 07 Aug 2012 23:52:18 GMT"; modification-date="Tue, 07 Aug 2012 23:52:18 GMT" Content-ID: <429314723@07082012-0B4B> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAZCAYAAADE6YVjAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAK T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3 AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+ 5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk 5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd 0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA 4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5 h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+ Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY /R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1 mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/ 0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5 hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9 rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7 vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO 32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21 e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i /suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8 IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq YAAAOpgAABdvkl/FRgAABPtJREFUeNqklktsVdcVhr+1z7n3XNsXjKu4KK4boZYAsYqSGlAUBhHt JGEAaSgZVGr6SFLFHaCo7YxRKwZ9zPrIQ3kI1UhWCx1UkVAgSUFVW5UUW0auHeoOrDoP+jBGvg/f c8/Ze6/dwbn3FgKDFJb062hvaa3/rMe/9xY6pqrfB77uvd/CHZgxBhH5LfADY8wlAAHw3p93zu3L sowoihCR2yZxzhFFEUmSrAFfiOP4Etbab7Tb7bC2thbyPA/W2mCtDYcPHw6Tk5PhzJkzYf/+/b39 j4NWqxXq9Xqw1s4CxKr6pXaWUalUAAghADA+Ps709AybN29mZGSkt/9xLI5jsjzHOffA6rVrw8Z7 P+S97/alh/vGxrhw4c+8884F9u3bx5EjRzhw4ADHjh1jbm6OgwcPMjU1xdGjR2/w6yKOIqx1JOXy 54xqIGhAP4K9e/fSarVYWlpiYKDK/Pw8hw4d4ty5c1jraDabZFlGq9W6yVc1AIJXj/eK0aCEW6A6 MMDY2BibNm1iePgu6vU6Y2Nj1Ot1nLM0Go0eya38NShBAyEosXpFNeBVb6ptmqYMDQ1hbRH0+m+t ViNN2zSb67f0LeIqYIhza8nynCRJbhrdNE0B6Ovrp1arMTU1Ra1W65GcP38OESHojUMRCDjvsLlF jBB777F5TpbnAIhID1u33gsCO3bsYOfOnRw/fpyJiQn6+vsZHBwkLpUYHR3FOUcIAQ2hN4XOOZyz RFGMfHjln79vtVoPV6vVQrGXZjGnTiLNJgjI0hK0WmAMEsdQKiOVBOnrg2oV2b4DtmwhrK7iowj7 +JcJ1WqHxBHH0Rdj7z1dmH//i+Q7z9FLXgREkCiCOEbimFAuIUmCqVaRoU9gBIz3mF27MaOfovab U6RPfq0XU0SIr5/t5OxZIjFUF97t1ddfvEj61DfBOtBA+elvEe3ZQ/t730XSDJrrhLUaunIV7rmH /pX/sP4RzRjv/7cAiKKI/Omn0MVFdHER+5MfF2Us1IpRRYISj34a06gjq1cx5QRxjjA3h1y5cgOB 91pk4jsAiI2BmRmk0SjWg4NU/jqPf+klZPduwvQ0ZnwXyeQkevo0/o9/oPTDHxVZnziBLiz04nlV RHxBEryiXpFOJr1+dI5uANNZiwhhZgb+vohs2078xBOE2VkQMA/cj7z2WqGRLkSIvXp80OIICAHf GcG4037tlEo790IADAGtN4oSBpDxzxf6mJ3FZ228elR9US6VQvG+w5o5R9NaADZ0BJY6xwYgV08c Ak49JQ1Y9ZS6Sp++SPb66yCGPE3pxvSq4AVTNKhgzZylmWc086zILihph9Ts2o0PSu49MjIC27bh g5J98D5y9wiVZyfQz36GZju9rvFFRrH3incFczupYF0RtH9hAYDa8j+ovHkW36ij9QbZ8jKyME+0 cZBrp06RXX6XuwYGALh68tdkNsd7JbcWEUF9QP5yceaEde6r5XKJaHUV99y3Cc31275+o8ceJ3pm gmazSX9/P5cvXx6W02+ceXR4+JNvtNbXqfT1Ie8tk039krD+/xPFO++n/JUnabdTjBhMFP3poQf3 PCxA/Nbb51/csHHDM+12G1W9o4dECIGkXEY1/O3kyV898vOf/fS9brTkF8+/8Ni927Y/G0VmI+EO 3kQirKysvPm7t9965dVXXl4GwvW/bIAEKHWfSrdpHsgA29347wAa+pFmyNu48AAAAABJRU5ErkJg gg== --_011_FE60A4E52763E84B935532D7D9294FF139264F0E89EUSAACMS0715e_ Content-Type: image/png; name="image007.png" Content-Description: image007.png Content-Disposition: inline; filename="image007.png"; size=4184; creation-date="Tue, 07 Aug 2012 23:52:18 GMT"; modification-date="Tue, 07 Aug 2012 23:52:18 GMT" Content-ID: <429314723@07082012-0B52> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAZCAYAAADE6YVjAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAK T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3 AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+ 5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk 5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd 0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA 4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5 h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+ Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY /R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1 mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/ 0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5 hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9 rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7 vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO 32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21 e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i /suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8 IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq YAAAOpgAABdvkl/FRgAABYNJREFUeNqcln2MnFUVxn/nvu/MO++8M9ttt7PbLl2bFmy70BYsDWKl hS6iqxS6WBMoFAkBEhKJmKxR1Aj4WQwx1rRaIF1TjApS04i6pFi+6bYQ6+IHtRZYFWvZXXe7ndmd mff7Xv/otqgEm/Ekz73/Peee+zz3nCsAy7yZ/GD5ZSs6ijNurxp9UYpxAUPjIRZSL4p66XfHR394 1eCeA5Ex2AAXzWpb3zaj+Sf/MEneYLAaohVMnGCiCETQOYeymAs6S3NuvbFjya19fz/8sLTnvNKe VetfjbNWq6eFgqjGEgQhVluJ/OoL0dU6/v5BKvU6NUtoNlL76MDjy+zVs+Z+qJDLtdaSmKIo0gaK MGFEZmEHpW9+FrttNgB683aKTzwPeQeVyXiXl+ats1ud/NwYgycK3agCxtB823XYrS2c+P6P0OVJ nOVLUJkM8eN7iZtsCplsh9IYAyANEJswwtQDVN4lu2gBydFhKn27sOfNobCui6ZPXoPdVsIkCakx RjV08lRjkgTnvEXkVi5F+wHJ0bew2ltxli+h/uzL+Pt+i9Xawsw7bwKtwXDSXWJZCALaMF3YO0Mb sBQtvbfgda8BoP7MAWpPH8A5v5PZX76D8oOPoJo89PEyydFhlOMABjsZGdNVjlBsmYUqFsDJIkqB TOc7uWCCkKYb1uN1r8HfP4jV3ES+6wPoWp3qr56hsK6L0rc+B8D4XfdzYveTVNOYeGQM20Qx/tER MsfGME4WybuI56LyLuI6SDaL2DYmSXFXrcAEIeN3bwElzNmxGa/7Ut7aeCe1X+8ju3gh9af3U+t/ lgQIdIohwkYEsS0QhYkT0hOTMFE5qXEcIFYWcXOYMCA5NorTeQ46CJkaeApnayet998Fohjfug1F HrCwcjkQEAWkgtICqRhSMSQKUltIbUUimsK1V5O9+HyiWpU4DinvegKUMPsbvVjzF2IvmAdAVC6j pYDOe+h8jkRBMs2pATvFEKOJp02sjUH7NfIXLKXj0e9S3XeQ17quA3H45493U7jmCmZ8bC2dr78E GYvKnucpD/wGcs7pdidAgiHCoDEojSEWiJQhTGPCOMR67wKmhv7G1MBBCpesxLvqcoKoju/XOLLx U4zueJRweITRHY/w2qZPE6UJsYJYzDuQAnY6ncD3fXJennO2fJ3Sxh7Gf9bPm/dtY+kvd3LWl+5g eHc/pZ5u2q7v4c839yLZDOlUFbEtJJuBf+sXb1eiScWgEiBIItT8uZz78z7abr6WpF6nddPHmTh0 mGMPP0ZhxTI6dz3IuY89wKyejyDz51KbrBDlMkQZi1A0oZjTCKb3SAwpBpWYlFAM5+3cwsy1q3i1 9x4O9d4LwJLvbWbshQPEE2XaPnElwfAoA10bmHhjiNhzCJUhEP0uOJkoEYO1OONevCDW3e7MZto/ vBZxssy7YQPVN/5KyyXvJ9s+h5GnngMRXly/ieN/OASee9qR74ZEDD6aI2kwYCdiiPMOf3poJwuv 30Dpsg9yeHsfg1/4Gj1/HKC4+Gyeu/E24vIUYaWCPSNPYs7crw0QokkElMao0BImgyovf/U+AFre t5w1P+3D6ziLV769ldGhIabqU8RuFp+UQM4MX1J80aQYsSfR1UQ0oZfj9T1PsugX/Zx99ZUAvPjF exj8zjasoosW9R8O+l+hgJrRGIFQ9KTlGx2udPO3VEhtrTWVob8w/9LV7O39PAcfeAhV8NCWkGLO qMMpVEUzoVMcS0x/ffJeAVidL3zlCq9wd0WniDZ4xSK18XFs1234u5JgMECzsnihXtu2tzb1mVMD 0VmWy91+oevelFPyniRJlVhWA+Py7UeokDTQ+s3fB8GuV3x/OzD53zTtrlKl6Wv9f0P7Wo8BI6dE /NcAQhbE7cZc9jcAAAAASUVORK5CYII= --_011_FE60A4E52763E84B935532D7D9294FF139264F0E89EUSAACMS0715e_ Content-Type: image/png; name="image008.png" Content-Description: image008.png Content-Disposition: inline; filename="image008.png"; size=4129; creation-date="Tue, 07 Aug 2012 23:52:19 GMT"; modification-date="Tue, 07 Aug 2012 23:52:19 GMT" Content-ID: <429314723@07082012-0B59> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAZCAYAAADE6YVjAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAK T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3 AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+ 5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk 5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd 0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA 4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5 h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+ Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY /R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1 mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/ 0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5 hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9 rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7 vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO 32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21 e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i /suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8 IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq YAAAOpgAABdvkl/FRgAABUxJREFUeNqklk9sVNcVxn/3zbw3HjODwVGBpKocBBlinOIumiiQJsiu J1GahD9JqrTAoqWC0kVLAi1Gatw4sruAgLuoIhZNm0VVlHhs6tDQAPkDVQAvqFRCqkCwOnIlaGrj EjP2m/fmzb33dDGD04g/dttP+hZv8c53v3O+8+6DKnpzuSdF5INSqWSDIJD/h1rrT8fGxl5pbW2t v1afDRs2rImiSCYmJsT3fQnDUIKZMggkiiIRESmXy1IMApmYmJByuSyDg4PH0+l0TSyVStXs37+/ t66u7gtKKVzXRSkHZ0ZUeJ6HiLBr1y4WLlzIbfW34TiKIAhYtGjRncPDwxfiDQ0Ni+bPX7Akisp4 novWBqW4NQRQEI+7jI+Ps3HjRgYGBrh8+TI9PT1Ya/E8D2stDzzwtTbHcZxarcsOCoyxWGsxZhpa i+t6oKBYDDhy5AgA+/bt4+zZs7iuh7WC1oZkMlnriIgYY8VWBWbCRCLB0bePkm1ro1Qqkc1mmT17 NqVSiY6OjopZEay1aKPFufbw3wicPHmCNatXc+zYMdavX8fddzdSW1tLNvswBw8e5NAfD1GTrMFa i1jBATDG3LSosRZjDU4sxqxUCteNc1cmw7x583Ach3PnzvHqq7/hypUrtLa2kE6n2dnezuTkJAKV d0WEIAwJw5CoXEYbUy38+dP/49Il2tt3sGnTJkZHRtm1ezfWWh5auZI5c+YSRRHDw39n+/btPP74 E2ht8H2fqBRJXETQWlPWGqn2UimFAlCKRCLB0NAQT65dSz6fryxuby/9Bw7Q0trKn44fp6fnF3R0 PM8777zN+ydO4HkJgiAAwFpLXKrtMsaglEJEPpfWRCJBz94e8vk8L+3Zgz/p09n5Atuee46fvdDJ N59+itdef41fvfJrtNaIUGlV9bBWLHFEpqKplEXE4jgOyWQSx4mhlOL8+fN4nseqVau5444vcubM GQYGfg/At9et468ffsjSpiZqk0l8368sEVREjOAIYK3B2Iobqm76cn307N3DRx+dI5PJEEURBw70 k5qV5OttbQAMDw/T2fkiv/3dfhRQKExMBeUarZiqE2sxxhBzYlhj2blzB/19fQDkcjm6un9OLtdL d1cXWhsOvfkmAIsX30Vt7SwcJ0YYlq4ZmIJSCmuFOIA1Fmss7iyPI4ffor+vj1WrVvPggw+x4Pbb aWlpYceOdrq7u+h4/qcAbN36LMual1EoFG769amIWOIinw0eYGhoCIBHHn2UZ575FqMjI2zZspl7 7vkyA2/8gcHBUzQ2NrJ8+QqKfvG6oNxQBGRKJIoiGhruBKA/l+Oxx57gnyMjvDEwQOFqgc2bt7C0 qQmtNX6xCLcQuIGTSrqKfpHlK1awdGkT7733Lj/58TbS6TQAmSVLKAYB/uQkM8VnIshUuqJyRE1N kj17e/jBlu+T630dgK/eey/r12/A9yen2jq9AigUIqLiqrrkuqxxHIdC4SoXhi7wy5dfZvDUKVzX oy2bJZlMEpWi6xJ0qztHKYXWRpyxsbFP/KL/aVlrXNfl6OHDPPujH/Ln06f5zne/x5q1a4nH4oRh WI369LRWCMIAJxYjn8//LRaG4UTdnDlfuv/+5feNj18lUZPg0sWLrGxpJZVKERQDjDGIFcTaaWmt pVQKicfjFAqFwt6Xdm+LAZz94Mzp+vr6xZlMpnHu3LlkH36E+fMXUI4ipr+LrxsFXsJjbOxfn3R3 vbj144/Pv/ufFeqam7/yjWXNzfe5rps0xgr/AxzHkdHRkYsnT7z/1vj4+F/gxmOMMfPx3syMrv5u APDvAQA0od/2coVKtQAAAABJRU5ErkJggg== --_011_FE60A4E52763E84B935532D7D9294FF139264F0E89EUSAACMS0715e_-- From xuxiaohu@huawei.com Tue Aug 7 18:17: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 0542311E80FA for ; Tue, 7 Aug 2012 18:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=-0.508, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWmklg66RoWN for ; Tue, 7 Aug 2012 18:17:50 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 30E2811E80D2 for ; Tue, 7 Aug 2012 18:17:50 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIP56879; Tue, 07 Aug 2012 17:17:49 -0800 (PST) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 7 Aug 2012 18:16:11 -0700 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 7 Aug 2012 18:16:14 -0700 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.5]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Wed, 8 Aug 2012 09:15:45 +0800 From: Xuxiaohu To: "Eric Osborne (eosborne)" , "Eric Rosen (erosen)" Thread-Topic: Comments on MPLS-in-UDP Thread-Index: AQHNdAzUtdwdCzXyaEe3xLHRR7iIc5dOB+Tg///myACAAS1rQA== Date: Wed, 8 Aug 2012 01:15:45 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753EE7F@szxeml525-mbx.china.huawei.com> References: Your message of Mon, 30 Jul 2012 18:03:44 -0000. <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753B3A1@szxeml525-mbx.china.huawei.com> <9398.1344282664@erosen-linux> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753EB93@szxeml525-mbx.china.huawei.com> <20ECF67871905846A80F77F8F4A275720F5396EC@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A275720F5396EC@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.99.24] 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] Comments on 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: Wed, 08 Aug 2012 01:17:51 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogRXJpYyBPc2Jvcm5lIChlb3Nib3Ju ZSkgW21haWx0bzplb3Nib3JuZUBjaXNjby5jb21dDQo+ILeiy83KsbzkOiAyMDEyxOo41MI3yNUg MjM6MDgNCj4gytW8/sjLOiBYdXhpYW9odTsgRXJpYyBSb3NlbiAoZXJvc2VuKQ0KPiCzrcvNOiBt cGxzQGlldGYub3JnDQo+INb3zOI6IFJFOiBDb21tZW50cyBvbiBNUExTLWluLVVEUA0KPiANCj4g W3BsZWFzZSBub3RlLi4uZGlmZmVyZW50IEVyaWNdDQo+IA0KPiAuLi4NCj4gDQo+ID4gPiBOb3Rl IHRoYXQgZWFjaCBuZXcgZW5jYXBzdWxhdGlvbiBpbXBhY3RzIHRoZSBkYXRhIHBsYW5lIG9mIHRo ZSBQRQ0KPiA+IHJvdXRlcnMsDQo+ID4gPiBhbmQgdGhlIGRyYWZ0IHJlcXVpcmVzIHRoYXQgZWFj aCBlbmNhcHN1bGF0aW9uIGhlYWRlciBoYXZlIGEgInNvdXJjZSBwb3J0Ig0KPiA+ID4gZmllbGQg d2hvc2UgdmFsdWUgaXMgYSBjb21wdXRlZCBoYXNoIG9mIHRoZSBUQ1AvVURQIGhlYWRlciBvZiB0 aGUNCj4gPiBwYXlsb2FkLg0KPiA+ID4gVGhpcyBpcyBub3Qgc29tZXRoaW5nIHRoYXQgaXMgY29t cGxldGVseSB0cml2aWFsIHRvIGltcGxlbWVudC4NCj4gPg0KPiA+IEFzIGZvciB0aGUgaW1wbGVt ZW50YXRpb24gZGlmZmljdWx0eSBvZiBQRSByb3V0ZXJzLCBpdCBzZWVtcyB0aGVyZSBpcyBubyBi aWcNCj4gPiBkaWZmZXJlbmNlIGJldHdlZW4gZmlsbGluZyBhIGhhc2ggdmFsdWUgaW4gdGhlIEdS RSBrZXkgZmllbGQgKG9yIEwyVFB2Mw0KPiA+IHNlc3Npb24gSUQgZmllbGQpIGFuZCBmaWxsaW5n IGluIGEgaGFzaCB2YWx1ZSBpbiB0aGUgVURQIHNvdXJjZSBwb3J0IGZpZWxkLCBJTUhPLg0KPiAN Cj4gDQo+IA0KPiBXaGF0IGhhcHBlbnMgaWYgdGhlIFVEUCBzb3VyY2UgcG9ydCB5b3UgZ2VuZXJh dGUgaXMgYW4gZXBoZW1lcmFsIG51bWJlcg0KPiBhbHJlYWR5IGluIHVzZT8gIEkgcmVhbGl6ZSB0 aGF0IHRoZSBkcmFmdCBkb2Vzbid0IHNwZWNpZnkgYSBwYXJ0aWN1bGFyIGhhc2hpbmcNCj4gYWxn b3JpdGhtIGJ1dCBjb2xsaXNpb25zIGFyZSB1bmF2b2lkYWJsZS4gIERvZXMgdGhlIGhhcmR3YXJl IHRoYXQncyBpbXBvc2luZw0KPiB0aGUgaGFzaGVkIHNvdXJjZSBwb3J0IG5vdyBuZWVkIHRvIHRy YWNrIGFsbG9jYXRlZCBzb3VyY2UgcG9ydHMgYnkgYWxsDQo+IGFwcGxpY2F0aW9ucyBvbiB0aGUg UEU/ICBJIGNvdWxkIHNlZSBzb21lIG9uLXJvdXRlciBmaXJld2FsbHMgY2hva2luZyBvbiBhDQo+ IHBhY2tldCB0aGF0IHNoYXJlZCBhIHNvdXJjZSBwb3J0IHdpdGggc29tZSBvdGhlciBhcHBsaWNh dGlvbi4NCg0KSGkgRXJpYywNCg0KSXQncyBhbiBpbnRlcmVzdGluZyBxdWVzdGlvbi4gQXMgc2Fp ZCBpbiBzZWN0aW9uIDM6ICIgVG8gZW5zdXJlIHRoYXQgdGhlIHNvdXJjZSBwb3J0IG51bWJlciBp cyBhbHdheXMgaW4gdGhlIHJhbmdlIDQ5MTUyIHRvIDY1NTM1IHdoaWNoIGlzIHJlcXVpcmVkIGlu IHNvbWUgY2FzZXMsIGluc3RlYWQgb2YgY2FsY3VsYXRpbmcgYSAxNi1iaXQgaGFzaCwgdGhlIGlu Z3Jlc3MgUEUgcm91dGVyIHdvdWxkIGNhbGN1bGF0ZSBhIDE0LWJpdCBoYXNoIGFuZCB1c2UgdGhv c2UgMTQgYml0cyBhcyB0aGUgbGVhc3Qgc2lnbmlmaWNhbnQgYml0cyBvZiB0aGUgc291cmNlIHBv cnQgZmllbGQgd2hpbGUgdGhlIG1vc3Qgc2lnbmlmaWNhbnQgdHdvIGJpdHMgd291bGQgYmUgc2V0 IHRvIGJpbmFyeSAxMS4iICBDYW4gdGhpcyB0cmljayBkZWFsIHdpdGggdGhlIGFib3ZlIGNvbmNl cm4geW91IG1lbnRpb25lZD8NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4gDQo+IA0KPiAN Cj4gZXJpYw0K From xuxiaohu@huawei.com Tue Aug 7 18:31: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 4C0CA11E80F2 for ; Tue, 7 Aug 2012 18:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.525 X-Spam-Level: X-Spam-Status: No, score=-4.525 tagged_above=-999 required=5 tests=[AWL=1.474, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+-ZDLAX17tH for ; Tue, 7 Aug 2012 18:31:09 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6783711E80DF for ; Tue, 7 Aug 2012 18:31:09 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AIZ38698; Tue, 07 Aug 2012 17:31:09 -0800 (PST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 7 Aug 2012 18:28:34 -0700 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 7 Aug 2012 18:28:37 -0700 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.5]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Wed, 8 Aug 2012 09:28:28 +0800 From: Xuxiaohu To: "S. Davari" Thread-Topic: [mpls] Comments on MPLS-in-UDP Thread-Index: AQHNdAzUtdwdCzXyaEe3xLHRR7iIc5dOB+Tg///dyQCAATkNsA== Date: Wed, 8 Aug 2012 01:28:28 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753EE95@szxeml525-mbx.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753B3A1@szxeml525-mbx.china.huawei.com> <9398.1344282664@erosen-linux> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753EB93@szxeml525-mbx.china.huawei.com> <7E541697-B01D-4B77-960B-4E454EB9F34D@yahoo.com> In-Reply-To: <7E541697-B01D-4B77-960B-4E454EB9F34D@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.99.24] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on 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: Wed, 08 Aug 2012 01:31:10 -0000 DQoNCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IFMuIERhdmFyaSBbbWFp bHRvOmRhdmFyaXNoQHlhaG9vLmNvbV0NCj4g5Y+R6YCB5pe26Ze0OiAyMDEy5bm0OOaciDfml6Ug MjI6MzYNCj4g5pS25Lu25Lq6OiBYdXhpYW9odQ0KPiDmioTpgIE6IGVyb3NlbkBjaXNjby5jb207 IG1wbHNAaWV0Zi5vcmcNCj4g5Li76aKYOiBSZTogW21wbHNdIENvbW1lbnRzIG9uIE1QTFMtaW4t VURQDQo+IA0KPiBIaSBYaWFvaHUNCj4gDQo+IFRoZSBjb21wbGV4aXR5IG9mIGNvbXB1dGluZyB0 aGUgR1JFIGtleSBpcyBzYW1lIGFzIFVEUCBzb3VyY2UuIEhvd2V2ZXINCj4gcm91dGVycyBhcmUg YXZhaWxhYmxlIHRoYXQgZG8gR1JFIEtleSBjYWxjdWxhdGlvbnMgd2hpbGUgWW91IG5lZWQgbmV3 DQo+IGhhcmR3YXJlIGZvciB5b3VyIHByb3Bvc2FsLg0KDQpIaSBTaGFocmFtLA0KDQpUaGUgYXBw cm9hY2ggb2YgdXNpbmcgdGhlIEdSRSBrZXkgZmllbGQgYXMgYW4gZW50cnkgZmllbGQgcmVsaWVz IG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgY29yZSByb3V0ZXJzIGFyZSBjYXBhYmxlIG9mIHBlcmZv cm1pbmcgaGFzaCBjYWxjdWxhdGlvbnMgb24gdGhlIEdSRSBrZXkgZmllbGQuIEhvd2V2ZXIsIHN1 Y2ggY2FwYWJpbGl0eSBpcyBub3Qgd2lkZWx5IHN1cHBvcnRlZCBhcyBmYXIgYXMgSSBrbm93LiBJ biBjb250cmFzdCwgcGVyZm9ybWluZyBoYXNoIGNhbGN1bGF0aW9ucyBvbiB0aGUgZml2ZS10dXBs ZSBvZiBUQ1AvVURQIHBhY2tldHMgaXMgYSBkZWZhdWx0IGZlYXR1cmUgZm9yIG1vc3Qgcm91dGVy cy9sYXllcjMgc3dpdGNoZXMuDQoNCj4gQWxzbyBkYXRhIGNlbnRlciBhcmNoaXRlY3R1cmVzIGFy ZSBub3cgbGVhbmluZyB0b3dhcmQgVlhMQU4gYW5kIE5WR1JFLg0KDQpJdCdzIGp1c3Qgb25lIHBv c3NpYmxlIG9wdGlvbiBidXQgbm90IHRoZSBvbmx5IG9wdGlvbiwgaXNu4oCZdCBpdD8NCg0KQmVz dCByZWdhcmRzLA0KWGlhb2h1DQoNCj4gUmVnYXJkcywNCj4gU2hhaHJhbQ0KPiANCj4gDQo+IE9u IEF1ZyA3LCAyMDEyLCBhdCAyOjM5IEFNLCBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbT4g d3JvdGU6DQo+IA0KPiA+IEhpIEVyaWMsDQo+ID4NCj4gPiBUaGFua3MgYSBsb3QgZm9yIHlvdXIg aW5zaWdodGZ1bCBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMuIFBsZWFzZSBzZWUgbXkNCj4gcmVz cG9uc2UgaW5saW5lLg0KPiA+DQo+ID4+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4gPj4g5Y+R 5Lu25Lq6OiBFcmljIFJvc2VuIFttYWlsdG86ZXJvc2VuQGNpc2NvLmNvbV0NCj4gPj4g5Y+R6YCB 5pe26Ze0OiAyMDEy5bm0OOaciDfml6UgMzo1MQ0KPiA+PiDmlLbku7bkuro6IFh1eGlhb2h1DQo+ ID4+IOaKhOmAgTogZXJvc2VuQGNpc2NvLmNvbTsgbXBsc0BpZXRmLm9yZw0KPiA+PiDkuLvpopg6 IFJlOiBDb21tZW50cyBvbiBNUExTLWluLVVEUA0KPiA+Pg0KPiA+Pg0KPiA+Pj4gQXMgZm9yIE1Q TFMtaW4tR1JFIG9yIE1QTFMtaW4tTDJUUHYzLCBpdCByZXF1aXJlcyBQIHJvdXRlcnMgdG8gYmUg Y2FwYWJsZQ0KPiA+Pj4gb2YgcGVyZm9ybWluZyBoYXNoIGNhbGN1bGF0aW9ucyBvbiB0aGUgc3Bl Y2lmaWMgImxvYWQtYmFsYW5jaW5nDQo+ID4+PiBmaWVsZCIgY29udGFpbmVkIGluIHRoZSBlbmNh cHN1bGF0aW5nIGhlYWRlciAoZS5nLiwgTDJUUHYzIHNlc3Npb24gSUQNCj4gPj4+IGZpZWxkIG9y IEdSRSBrZXkgZmllbGQpLiAgU3VjaCByZXF1aXJlbWVudCBjYW4gbm90IGJlIG1ldCBieSBzb21l IFANCj4gcm91dGVycw0KPiA+Pj4gd2hpY2ggY291bGQgb25seSBwZXJmb3JtIGhhc2ggY2FsdWxh dGlvbnMgb24gdGhlIGZpdmUgdHVwbGUgb2YgVENQL1VEUA0KPiA+Pj4gcGFja2V0cy4gTVBMUy1p bi1VRFAgaXMgb25seSBwcm9wb3NlZCB0byBiZSB1c2VkIGluIHN1Y2ggc3BlY2lmaWMgY2FzZXMu DQo+ID4+DQo+ID4+IEkgc2VlIHRoZSBsb2dpYyBvZiB0aGlzIGFyZ3VtZW50LiBPbiB0aGUgb3Ro ZXIgaGFuZCwgd2UgYWxyZWFkeSBoYXZlIHRocmVlDQo+ID4+IHN0YW5kYXJkaXplZCBNUExTLWlu LUlQIGVuY2Fwc3VsYXRpb25zLCBlYWNoIG9mIHdoaWNoIGhhcyBiZWVuIGFyZ3VlZCB0bw0KPiA+ PiBoYXZlIGFuIGltcG9ydGFudCBhZHZhbnRhZ2Ugb3ZlciB0aGUgb3RoZXIgdHdvLiAgSSBkb24n dCB0aGluayBhbnkgb2YgdGhlbQ0KPiA+PiBoYXMgcmVhbGx5IGNhdWdodCBvbiB0aG91Z2guICBU aGVyZSdzIGFsc28gYmVlbiB3b3JrIG9uIE1QTFMtaW4tSVBzZWMsDQo+IHdoaWNoDQo+ID4+IHNp bWlsYXJseSBoYXMgZmFpbGVkIHRvIGdlbmVyYXRlIG11Y2ggaW50ZXJlc3QgaW4gcHJhY3RpY2Uu ICBBZnRlciBhIGRvemVuDQo+ID4+IHllYXJzLCBkbyB3ZSByZWFsbHkgdGhpbmsgdGhlcmUncyBn b2luZyB0byBiZSBhIGxvdCBvZiBpbnRlcmVzdCBpbiB5ZXQNCj4gPj4gYW5vdGhlciBNUExTLWlu LUlQIGVuY2Fwc3VsYXRpb24/DQo+ID4NCj4gPiBBcyBmb3Igc2VydmljZSBwcm92aWRlciBiYWNr Ym9uZXMsIG1vc3Qgb2YgdGhlbSBhcmUgY2FwYWJsZSBvZiBNUExTDQo+IGZvcndhcmRpbmcgYW5k IHRoZXJlZm9yZSBpdCdzIHVuZGVyc3RhbmRhYmxlIHRoYXQgTVBMUy1pbi1JUCBlbmNhcHN1bGF0 aW9ucw0KPiBhcmUgbm90IHBvcHVsYXIuIEhvd2V2ZXIsIGluIGNsb3VkIGRhdGEgY2VudGVyIG5l dHdvcmsgZW52aXJvbm1lbnRzLCBzb21lDQo+IGRhdGEgY2VudGVyIG9wZXJhdG9ycyBjaG9vc2Ug dG8gdXNlIElQLCByYXRoZXIgdGhhbiBNUExTIGluIHRoZSB1bmRlcmx5aW5nDQo+IG5ldHdvcmsg ZHVlIHRvIGNlcnRhaW4gcmVhc29ucy4gSW4gYWRkaXRpb24sIE1QTFMtYmFzZWQgTDJWUE4gYW5k IEwzVlBODQo+IHRlY2hub2xvZ2llcyBhcmUgY29uc2lkZXJlZCB0byBiZSB1c2VkIGFzIHNjYWxh YmxlIGRhdGEgY2VudGVyIG5ldHdvcmsNCj4gc29sdXRpb25zIHRvIHN1cHBvcnQgbXVsdGktdGVu YW5jeS4gSW4gdGhpcyBjYXNlLCBNUExTLWluLUlQIGVuY2Fwc3VsYXRpb25zDQo+IHdvdWxkIGJl IHVzZWZ1bC4gVG8gcGVyZm9ybSBmaW5lLWdyYWluZWQgbG9hZC1iYWxhbmNpbmcgb3ZlciBMQUcg YW5kIEVDTVANCj4gcGF0aHMgaW4gdGhlIHVuZGVybHlpbmcgbmV0d29yaywgdGhlIE1QTFMtaW4t SVAgZW5jYXBzdWxhdGlvbiBoZWFkZXIgc2hvdWxkDQo+IGNvbnRhaW4gYW4gZW50cnkgZmllbGQg c28gdGhhdCB0aGUgdW5kZXJseWluZyBuZXR3b3JrIGNvdWxkIGFjaGlldmUgYQ0KPiBmaW5lLWdy YWluZWQgbG9hZC1iYWxhbmNpbmcgb2YgdGhlIGVuY2Fwc3VsYXRlZCB0cmFmZmljLiBXaXRoIHRo ZSBNUExTLWluLVVEUA0KPiBlbmNhcHN1bGF0aW9uLCB0aGUgc291cmNlIHBvcnQgZmllbGQgY291 bGQgYmUgZGlyZWN0bHkgdXNlZCBhcyBhbiBlbnRyeSBmaWVsZCwgYW5kDQo+IG1vc3QgaW1wb3J0 YW50bHksIG1vc3Qgcm91dGVycyBhbmQgbGF5ZXIzIHN3aXRjaGVzIGhhdmUgYWxyZWFkeSBiZWVu IGFibGUgdG8NCj4gcGVyZm9ybSBoYXNoIGNhbGN1bGF0aW9ucyBvbiB0aGUgZml2ZSB0dXBsZSBv ZiBVRFAgcGFja2V0cy4NCj4gPg0KPiA+PiBOb3RlIHRoYXQgZWFjaCBuZXcgZW5jYXBzdWxhdGlv biBpbXBhY3RzIHRoZSBkYXRhIHBsYW5lIG9mIHRoZSBQRSByb3V0ZXJzLA0KPiA+PiBhbmQgdGhl IGRyYWZ0IHJlcXVpcmVzIHRoYXQgZWFjaCBlbmNhcHN1bGF0aW9uIGhlYWRlciBoYXZlIGEgInNv dXJjZSBwb3J0Ig0KPiA+PiBmaWVsZCB3aG9zZSB2YWx1ZSBpcyBhIGNvbXB1dGVkIGhhc2ggb2Yg dGhlIFRDUC9VRFAgaGVhZGVyIG9mIHRoZSBwYXlsb2FkLg0KPiA+PiBUaGlzIGlzIG5vdCBzb21l dGhpbmcgdGhhdCBpcyBjb21wbGV0ZWx5IHRyaXZpYWwgdG8gaW1wbGVtZW50Lg0KPiA+DQo+ID4g QXMgZm9yIHRoZSBpbXBsZW1lbnRhdGlvbiBkaWZmaWN1bHR5IG9mIFBFIHJvdXRlcnMsIGl0IHNl ZW1zIHRoZXJlIGlzIG5vIGJpZw0KPiBkaWZmZXJlbmNlIGJldHdlZW4gZmlsbGluZyBhIGhhc2gg dmFsdWUgaW4gdGhlIEdSRSBrZXkgZmllbGQgKG9yIEwyVFB2MyBzZXNzaW9uDQo+IElEIGZpZWxk KSBhbmQgZmlsbGluZyBpbiBhIGhhc2ggdmFsdWUgaW4gdGhlIFVEUCBzb3VyY2UgcG9ydCBmaWVs ZCwgSU1ITy4NCj4gPg0KPiA+PiBBIGZldyBtaXNjZWxsYW5lb3VzIHRlY2huaWNhbCBjb21tZW50 cy4NCj4gPj4NCj4gPj4gUmUgdGhlIElBTkEgQ29uc2lkZXJhdGlvbnM6DQo+ID4+DQo+ID4+PiAg VHdvIGRpc3RpbmN0IFVEUCBkZXN0aW5hdGlvbiBwb3J0IG51bWJlcnMgaW5kaWNhdGluZyBNUExT IHVuaWNhc3QNCj4gPj4+ICBhbmQgTVBMUyBtdWx0aWNhc3QgcmVzcGVjdGl2ZWx5IG5lZWQgdG8g YmUgYXNzaWduZWQgYnkgSUFOQS4NCj4gPj4NCj4gPj4gU2luY2UgUkZDIDUzMzIgd2UgZG8gbm90 IGhhdmUgY29kZXBvaW50cyBmb3IgIk1QTFMgdW5pY2FzdCIgYW5kICJNUExTDQo+ID4+IG11bHRp Y2FzdCIuICBTZWN0aW9ucyA0LTggb2YgUkZDIDUzMzIgYWxsb2NhdGUgY29kZXBvaW50cyBmb3Ig YSB2YXJpZXR5IG9mDQo+ID4+IGVuY2Fwc3VsYXRpbmcgcHJvdG9jb2xzLCB5b3Ugc2hvdWxkIHRh a2UgYSBsb29rIGF0IHRoYXQuDQo+ID4NCj4gPiBUaGFua3MgYSBsb3QgZm9yIHJlbWluZGluZyBt ZSBvZiBSRkM1MzMyLiBUaGUgY29ycmVzcG9uZGluZyB0ZXh0IHdvdWxkIGJlDQo+IGNoYW5nZWQg YXMgZm9sbG93ICIgVHdvIGRpc3RpbmN0IFVEUCBkZXN0aW5hdGlvbiBwb3J0IG51bWJlcnMgaW5k aWNhdGluZyBNUExTDQo+IGFuZCBNUExTIHdpdGggdXBzdHJlYW0tYXNzaWduZWQgbGFiZWwgcmVz cGVjdGl2ZWx5IG5lZWQgdG8gYmUgYXNzaWduZWQgYnkNCj4gSUFOQS4uLiAiICBJcyB0aGF0IE9L Pw0KPiA+DQo+ID4+IERvIHlvdSBleHBlY3QgdG8gc3VwcG9ydCBNVlBOIG92ZXIgdGhlIFVEUCBl bmNhcHN1bGF0aW9uPw0KPiA+DQo+ID4gSWYgZGF0YSBjZW50ZXIgb3BlcmF0b3JzIHdhbnQgdG8g dXNlIE1WUE4gaW4gdGhlaXIgZGF0YSBjZW50ZXJzLCB0aGV5IGNvdWxkDQo+IHVzZSBNUExTLWlu LVVEUCBlbmNhcHN1bGF0aW9uIGZvciBWUE4gdW5pY2FzdCB0cmFmZmljIGFuZCBWUE4gbXVsdGlj YXN0DQo+IHRyYWZmaWMuDQo+ID4NCj4gPj4gVG8gZ2V0IGFuIGlkZWEgb2Ygd2hhdCB0aGUgU2Vj dXJpdHkgQXJlYSBBRHMgYXJlIGxpa2VseSB0byByZXF1aXJlIHdpdGgNCj4gPj4gcmVnYXJkIHRv IHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucywgcGxlYXNlIGxvb2sgYXQgdGhlIFNlY3VyaXR5 DQo+ID4+IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gb2YgUkZDIDQwMjMuDQo+ID4NCj4gPiBJdOKA mXMgYSB2ZXJ5IHVzZWZ1bCByZWZlcmVuY2UuIFdlIGNvLWF1dGhvcnMgd291bGQgYWRkIG1vcmUg ZGV0YWlsZWQgc2VjdXJpdHkNCj4gY29uc2lkZXJhdGlvbnMgaW4gdGhlIG5leHQgcmV2aXNpb24u DQo+ID4NCj4gPiBUaGFua3MgYWdhaW4gZm9yIHlvdXIgaW5zaWdodCBjb21tZW50cyBhbmQgc3Vn Z2VzdGlvbnMuDQo+ID4NCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gWGlhb2h1DQo+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBtcGxzIG1haWxp bmcgbGlzdA0KPiA+IG1wbHNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHMNCg== From lizhong.jin@zte.com.cn Tue Aug 7 18:37: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 1D2D111E80DF for ; Tue, 7 Aug 2012 18:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.397 X-Spam-Level: X-Spam-Status: No, score=-101.397 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pY6PAjhE4A1T for ; Tue, 7 Aug 2012 18:37:00 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 9235B11E80D2 for ; Tue, 7 Aug 2012 18:36:59 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 10723806486374; Wed, 8 Aug 2012 09:24:21 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 65237.5335797074; Wed, 8 Aug 2012 09:36:48 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q781amR6018177; Wed, 8 Aug 2012 09:36:48 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: <20570.1344354133@erosen-linux> To: erosen@cisco.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Wed, 8 Aug 2012 09:36:04 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-08 09:36:45, Serialize complete at 2012-08-08 09:36:45 Content-Type: multipart/alternative; boundary="=_alternative 0008DC4448257A54_=" X-MAIL: mse01.zte.com.cn q781amR6018177 Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-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, 08 Aug 2012 01:37:01 -0000 This is a multipart message in MIME format. --=_alternative 0008DC4448257A54_= Content-Type: text/plain; charset="US-ASCII" Hi Eric, See inline below. Hope the clarification helps. Thanks Lizhong Eric Rosen wrote 2012/08/07 23:42:13: > > The leaf discovery mechanism is not to complement MVPN > > > The leaf discovery mechanism is useful for root initiated application to > > aggregate tunnels from leaf initiated application. For example, how to let > > MVPN to aggregate the mLDP tunnel generated by in-band signaling? > > I'm confused by these two sentences, as the second mentions the use of mldp > leaf discovery by MVPN, but the first says that you dont' intend the two > mechanisms to be used together. However, let's assume for now that there is > no MVPN here, just some mLDP in-band signaling. > > So suppose PE2, PE3, and PE4 join an mLDP tunnel rooted at PE1. Say the > tunnel is identified by the mLDP FEC element value=> (this is a case of in-band signaling).. > > Now PE2, PE3, and PE4 join another mLDP tunnel rooted at PE1, say > > (another case of in-band signaling). > > PE1 sees that the two tunnels have exactly the same set of leaf nodes. So > what is PE1 supposed to do? [Lizhong] PE1 have the tunnel >. Then when PE1 initiates new MVPN service, and has leaf member PE2, PE3, PE4, then PE1 is not necessary to initiate new mLDP tunnel, but directly aggreate to tunnel > for MVPN service. If PE1 does not have the leaf information of tunnel >, then PE1 could not aggregate MVPN service to that tunnel. And Leaf A-D route in MVPN could not help PE1 to find the leaf information of tunnel >. That means two different kind of applications could share one tunnel which is this draft trying to solve. > > > the root node has the capability to aggregate existing tunnel instead of > > creating an additional one. > > A few questions: > > - How does it do this? There doesn't seem to be any mechanism to do this. > > * What will cause PE2,PE3,PE4 to expect (S2,G2) traffic on the opaque value=> tunnel? > > * What will cause the teardown of the partially set up tunnel > at the P routers and PE routers? > > - How does the root node's aggregation strategy respond to dynamically > changing sets of leaf nodes? (Remember the leaf nodes join and leave the > LSP one at a time.) > > - How does the root node even know that the leaf nodes can correctly handle > traffic from an aggregated tunnel? > > I don't think any of this can be done without some application-layer > signaling between the root and leaf nodes. But if there is > application-layer signaling between the root and leaf nodes, why doesn't > that provide all the necessary auto-discovery? [Lizhong] as stated above, this draft did not try to help aggregate tunnel > and >, but help to aggregate tunnels from different kinds of applications, or to let leaf initiated application and root initiated application to share one tunnel. E.g, enable MVPN to use tunnel >. > > > leaf discovery did not introduce much additional new T-LDP session, but > > mostly rely on the existing T-LDP session provided by the application. > > If you want to focus on a use case where there is already T-LDP signaling > for some application, you have to show that some requirement is not met by > the existing T-LDP signaling for that application. > > > > > > > > > - > --=_alternative 0008DC4448257A54_= Content-Type: text/html; charset="US-ASCII"
Hi Eric,
See inline below. Hope the clarification helps.

Thanks
Lizhong
 

Eric Rosen <erosen@cisco.com> wrote 2012/08/07 23:42:13:

> > The leaf discovery mechanism is not to complement MVPN
>
> > The leaf discovery mechanism is useful for root initiated application to
> > aggregate tunnels from leaf initiated application. For example, how to let
> > MVPN to aggregate the mLDP tunnel generated by in-band signaling?
>
> I'm confused by these two sentences, as the second mentions the use of mldp
> leaf discovery by MVPN, but the first says that you dont' intend the two
> mechanisms to be used together.  However, let's assume for now that there is
> no MVPN here, just some mLDP in-band signaling.
>
> So suppose PE2, PE3, and PE4 join an mLDP tunnel rooted at PE1.  Say the
> tunnel is identified by the mLDP FEC element <root=PE1, opaque
> value=<S1,G1>> (this is a case of in-band signaling)..
>
> Now PE2, PE3, and PE4 join another mLDP tunnel rooted at PE1, say
> <root=PE1,opaque value=<S2,G2>> (another case of in-band signaling).
>
> PE1 sees that the two tunnels have exactly the same set of leaf nodes.  So
> what is PE1 supposed to do?
[Lizhong] PE1 have the tunnel <root=PE1, opaque value=<S1,G1>>. Then when PE1 initiates new MVPN service, and has leaf member PE2, PE3, PE4, then PE1 is not necessary to initiate new mLDP tunnel, but directly aggreate to tunnel <root=PE1, opaque value=<S1,G1>> for MVPN service. If PE1 does not have the leaf information of tunnel <root=PE1, opaque value=<S1,G1>>, then PE1 could not aggregate MVPN service to that tunnel. And Leaf A-D route in MVPN could not help PE1 to find the leaf information of tunnel <root=PE1, opaque value=<S1,G1>>. That means two different kind of applications could share one tunnel which is this draft trying to solve.

>
> > the root node has the capability to aggregate existing tunnel instead of
> > creating an additional one.
>
> A few questions:
>
> - How does it do this?  There doesn't seem to be any mechanism to do this.
>
>   * What will cause PE2,PE3,PE4 to expect (S2,G2) traffic on the <root=PE1,
>     opaque value=<S1,G1>> tunnel?
>
>   * What will cause the teardown of the partially set up tunnel <PE1,S2,G2>
>     at the P routers and PE routers?
>
> - How does the root node's aggregation strategy respond to dynamically
>   changing sets of leaf nodes?  (Remember the leaf nodes join and leave the
>   LSP one at a time.)
>
> - How does the root node even know that the leaf nodes can correctly handle
>   traffic from an aggregated tunnel?
>
> I don't think any of this can be done without some application-layer
> signaling between the root and leaf nodes.  But if there is
> application-layer signaling between the root and leaf nodes, why doesn't
> that provide all the necessary auto-discovery?
[Lizhong] as stated above, this draft did not try to help aggregate tunnel <root=PE1, opaque value=<S1,G1>> and <root=PE1, opaque value=<S2,G2>>, but help to aggregate tunnels from different kinds of applications, or to let leaf initiated application and root initiated application to share one tunnel. E.g, enable MVPN to use tunnel <root=PE1, opaque value=<S1,G1>>.

>
> > leaf discovery did not introduce much additional new T-LDP session, but
> > mostly rely on the existing T-LDP session provided by the application.
>
> If you want to focus on a use case where there is already T-LDP signaling
> for some application, you have to show that some requirement is not met by
> the existing T-LDP signaling for that application.
>
>
>
>
>  
>
>  
>
> -  
>
--=_alternative 0008DC4448257A54_=-- From lufang@cisco.com Tue Aug 7 18: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 CEE1511E80D2 for ; Tue, 7 Aug 2012 18:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.941 X-Spam-Level: X-Spam-Status: No, score=-8.941 tagged_above=-999 required=5 tests=[AWL=-0.763, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNo90CUw0MuW for ; Tue, 7 Aug 2012 18:56:48 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9FA11E80F2 for ; Tue, 7 Aug 2012 18:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=106365; q=dns/txt; s=iport; t=1344391007; x=1345600607; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/RsXUI2ABlZNfHhl/vUB04uZfZMp8pFt2lSLxYFt+wg=; b=Dsi/f2rG7ACZdw49643HtcdyMJn2wKCvut35dZb8aCfajWPxYZPeU/vg KKIFa42wCm4hb8v3NfC5TuCJTFEQR6ad4XUyrWVenFHuJACX7TDZxE6cL 6imbCEu0arkyhAgV8xJsSrOGDNvniUine5rGdEdYLdoPo+9CVXKJfOPnc w=; X-Files: image001.jpg, image009.gif, image010.png, image011.png, image012.png, image013.png, image014.png, image015.png : 35434, 1408, 3853, 3749, 3902, 4048, 4184, 4129 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAP3FIVCtJXG//2dsb2JhbABCA4JKrkQBiFiBB4IgAQEBBAUNARIIATYVEAIBCBEEAQEGAQEBAggOBwcCBRAGBwIMFAkIAQEEAQ0EAQgGFIdrC5pUoFuLD4M/gkFgA4xZgx8BAU6GFIIlim2BZoJf X-IronPort-AV: E=Sophos;i="4.77,730,1336348800"; d="gif'147?png'147,150?jpg'147,150,145?scan'147,150,145,208,217,147,150,145"; a="109401598" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 08 Aug 2012 01:56:46 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q781ukNc016044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Aug 2012 01:56:46 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.155]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0298.004; Tue, 7 Aug 2012 20:56:46 -0500 From: "Luyuan Fang (lufang)" To: Shahram Davari , "mpls@ietf.org" Thread-Topic: draft-ietf-mpls-tp-use-cases-and-design-02 Thread-Index: Ac109rZq2Pfvls9SQTu4EKif2qQJBQACDt+Q Date: Wed, 8 Aug 2012 01:56:44 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD930F4C9E61@xmb-rcd-x03.cisco.com> References: <4A6CE49E6084B141B15C0713B8993F2806E252@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F2806E252@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-cr-puzzleid: {C4E59303-6A1E-436D-B2FB-8F2F8CDCB239} x-cr-hashedpuzzle: siI= AOQL CMCG DZsL EwQ5 IXft OUh/ Reeo SFhL SHfE UTa0 Vwe9 YRg7 bIHt cMYm ede4; 3; ZABhAHYAYQByAGkAQABiAHIAbwBhAGQAYwBvAG0ALgBjAG8AbQA7AGwAbwBhAEAAcABpAC4AbgB1ADsAbQBwAGwAcwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {C4E59303-6A1E-436D-B2FB-8F2F8CDCB239}; bAB1AGYAYQBuAGcAQABjAGkAcwBjAG8ALgBjAG8AbQA=; Wed, 08 Aug 2012 01:56:28 GMT; UgBFADoAIABkAHIAYQBmAHQALQBpAGUAdABmAC0AbQBwAGwAcwAtAHQAcAAtAHUAcwBlAC0AYwBhAHMAZQBzAC0AYQBuAGQALQBkAGUAcwBpAGcAbgAtADAAMgA= x-originating-ip: [10.155.34.128] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19092.001 x-tm-as-result: No--48.651000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/related; boundary="_011_0DB8F45437AB844CBB5102F807A0AD930F4C9E61xmbrcdx03ciscoc_"; type="multipart/alternative" MIME-Version: 1.0 Subject: Re: [mpls] draft-ietf-mpls-tp-use-cases-and-design-02 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, 08 Aug 2012 01:56:49 -0000 --_011_0DB8F45437AB844CBB5102F807A0AD930F4C9E61xmbrcdx03ciscoc_ Content-Type: multipart/alternative; boundary="_000_0DB8F45437AB844CBB5102F807A0AD930F4C9E61xmbrcdx03ciscoc_" --_000_0DB8F45437AB844CBB5102F807A0AD930F4C9E61xmbrcdx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Shahram, It is a valid point, thanks. We can replace "PHP as optional" with "PHP must be disabled by default". I assume we can make the change through RFC editing process, Loa can help t= o confirm if OK. Thanks, Luyuan From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Sha= hram Davari Sent: Tuesday, August 07, 2012 4:45 PM To: mpls@ietf.org Subject: [mpls] draft-ietf-mpls-tp-use-cases-and-design-02 Hi, I am not sure it is late or not, but I found a discrepancy between This dra= ft and RFC5960. This draft says PHP is optional for MPLS-TP, while RFC5960= says PHP MUST not be used. Is there any way to correct this before IESG publication? Thank you, [Description: Description: Description: Description: Description: Descripti= on: Description: Description: Description: Description: cid:image009.jpg@01= CD505E.7B800DB0] Shahram Davari | Technical Director, Network Switching Group Broadcom Corporation | (O) 408-922-7436 | (M) 408-660-5695 [Description: Description: Description: Description: Description: Descripti= on: Description: Description: Description: Description: Description: Descri= ption: image005][Description: Des= cription: Description: Description: Description: Description: Description: = Description: Description: Description: Description: Description: image002]<= http://twitter.com/#!/broadcom>[Description: Description: Description: Desc= ription: Description: Description: Description: Description: Description: D= escription: Description: Description: image003][Description: Description: Description: Description: Description: De= scription: Description: Description: Description: Description: Description:= Description: image004][Description: Description: Description: Descri= ption: Description: Description: Description: Description: Description: Des= cription: Description: Description: image006][Description: Description: Description: Description: De= scription: Description: Description: Description: Description: Description:= Description: Description: image008][Description= : Description: Description: Description: Description: Description: Descript= ion: Description: Description: Description: Description: Description: image= 007] --_000_0DB8F45437AB844CBB5102F807A0AD930F4C9E61xmbrcdx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Shahram,

 

It is a valid point, t= hanks.

We can replace “= PHP as optional” with “PHP must be disabled by default”.<= o:p>

 

I assume we can make t= he change through RFC editing process, Loa can help to confirm if OK.<= /o:p>

 

Thanks,

Luyuan

 

From: mpls-bou= nces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari
Sent: Tuesday, August 07, 2012 4:45 PM
To: mpls@ietf.org
Subject: [mpls] draft-ietf-mpls-tp-use-cases-and-design-02

 

Hi,

 

I am not sure it is late or not, but I found a discr= epancy between This draft and  RFC5960. This draft says PHP is optiona= l for MPLS-TP, while RFC5960 says PHP MUST not be used.

 

Is there any way to correct this before IESG publica= tion?

 

Thank you,<= /span>

 

 

3D"Descriptio=

 

Shahram Davari | Technical Director, Network Switching Group
Broadcom Corporation | (O) 408-922-7436 | (M) 408-660-5695<= /p>

 

3D"Description:3D==3D"Description:3D"Description:<= img border=3D"0" width=3D"25" height=3D"25" src=3D"cid:image013.png@01CD74C= 4.B5406240" alt=3D"Description: Description: Description: Description: Desc= ription: Description: Description: Description: Description: Description: D= escription: Description: image006" v:shapes=3D"Picture_x0020_4">= 3D"Des=3D"Descripti=   &nb= sp;     

 

 

 

 

--_000_0DB8F45437AB844CBB5102F807A0AD930F4C9E61xmbrcdx03ciscoc_-- --_011_0DB8F45437AB844CBB5102F807A0AD930F4C9E61xmbrcdx03ciscoc_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=35434; creation-date="Wed, 08 Aug 2012 01:56:41 GMT"; modification-date="Wed, 08 Aug 2012 01:56:41 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4RSrRXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUAAAABAAAAYgEbAAUAAAABAAAA agEoAAMAAAABAAIAAAExAAIAAAAeAAAAcgEyAAIAAAAUAAAAkIdpAAQAAAABAAAApAAAANAADqYA AAAnEAAOpgAAACcQQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2gAMjAxMjowNjoxNSAxNjox Njo0OAAAA6ABAAMAAAABAAEAAKACAAQAAAABAAABCKADAAQAAAABAAAAOgAAAAAAAAAGAQMAAwAA AAEABgAAARoABQAAAAEAAAEeARsABQAAAAEAAAEmASgAAwAAAAEAAgAAAgEABAAAAAEAAAEuAgIA BAAAAAEAABN1AAAAAAAAAEgAAAABAAAASAAAAAH/2P/iDFhJQ0NfUFJPRklMRQABAQAADEhMaW5v AhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAAAAAAAAAA AAAAAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQAAAIEAAAA FHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRtZGQAAALE AAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAAJHRlY2gA AAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAAQ29weXJp Z2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJzUkdCIElF QzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAA AAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeFAAAY2lhZ WiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAA AAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29s b3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29s b3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxSZWZlcmVu Y2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVmZXJlbmNl IFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlWAFAAAABX H+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBjdXJ2AAAA AAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABtAHIAdwB8 AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsBAQEHAQ0B EwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHBAckB0QHZ AeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsECywLVAuAC 6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQTBCAELQQ7 BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYFtQXFBdUF 5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZB6wHvwfS B+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J5Qn7ChEK Jwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1DI4MpwzA DNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14Peg+WD7MP zw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLDEuMTAxMj E0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwWjxayFtYW +hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqeGsUa7BsU GzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMfPh9pH5Qf vx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQfJE0kfCSr JNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWspnSnQKgIq NSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9aL5Evxy/+ MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1wjX9Njc2 cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8JzxlPKQ84z0i PWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31DwEQDREdE ikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtTS5pL4kwq THJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19TqlP2VEJU j1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1XIZc1l0n XXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1lkmXnZj1m kmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8eb3hv0XAr cIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5iXnnekZ6 pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQdhICE44VH hauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaPnpAGkG6Q 1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtCm6+cHJyJ nPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSp N6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYB tnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD 1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+ 0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4Dbg veFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M 8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+S/7c/23/ ///tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8V GBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4O DhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgA IwCgAwEiAAIRAQMRAf/dAAQACv/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUB AQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJx gTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePz RieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYF NQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNU oxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//a AAwDAQACEQMRAD8A9Re1vJA+JMIZcAfa8DzDz+Rwc1GeYEyGjxd/qEPc48Oe74AAf9Mf9+SUptzg AXDc09xH97mf9JAxesdMy82/BxshtmVi/wA/UJluu06kbX7HeyzZ/N/4RG2O3A7XT3JDf++FrlxH 1aeWdZxM5oh3VW55J8dt3q6/9tpspUYjv/6L/wB02eX5eOTHmmSQccbhX7/DPL6v+p4cj3ySCzIB 0f7T49kXlOay6SSSSlKL3hvOpPDRyVE2SdtY3u8ew/rOQ5kF4dp+fb/3ypJS7nPMyYj6UGGt/rP+ k5yh+kkbXODjwOSR47H/AEG/11KD7QG6811+H/CWJaQZ9zSYce73fuN/kJKY+vkMiQ2xp4Ils/8A Vf5/82pNy5Gtbh5iCPyhOGFziHGT/hT2/k1D+SnfSRqzj93/AMikpk29juxb8Qp8qqDEjuO3+u3/ AF/0X84ptsLT8e3+v53+r0lNhJMCHAEag8J0lKSTFwBidfBJJT//0O4+ufVsro31bzupYbR9qpa1 tDiA4h9j2UBwYZ3bPU9RcC768fXk1OcxxczGl/2j7I0V3V2X1YeFY7e5jn03Odb+kwW+r/wP6Oy5 eldT6f1PLsZ9k6k/Bp2lttbKmPc6T9Jltvupdt/cVP8A5o4VbfVxcnKp6gIP283Pssc4cfaK7HfZ 7mf6Sr0kCT0H4s0MeIxBnm4Sf0YwlPh/2p/V/wDjXvPFV/Xr6w+tY/0hkZF4uxn9LZh2RhZTXGrC rfktbbbm2X1MtzMmn/RU2ekxVMf6ydatf0ijplNDM/GxiacL7I8l+W/KuxMyqfY3Apdi1fbMm176 fT/8893f0z619Q2Yefl41OCHg3XYnqsyLWN/wbtx9On1v8J6b1r9VwD1Hp92G25+M60ey6okOa4H cx3tLdzdw97N3vQu79O21pMBAxj7wqZ9ft8Uowh8nFL5eP0Tyej/AL986b9devuoys71W1Fj/SzM CzCtLelt9b7OzIvzGN/XbWUfp7aLP+t0/o7GKtZ9evrnhbB6TsrHbXea8sY3pHJZYMgdKz7aCG/Z m78Sy/0v0fq4q7lmB9bspjcXPzcfGxwALMjCD/tNgHt+ncPSxnP/ANJUz/i0rPqnj0H1+l5OTg5U 7nXMtdZvd/3ZpyXPqyP/AANLiPSP26JOHFHSWePEdvbjLJj/AOqT9HD/AIEMqT6r9Uv6h0PFuy7z bmtrYMwlgqi5zGZLq9lldbfZVkVfzX6NaZcD9Jwd/WdP/QrG1yrYFOdRSa83MOdcXEi01tpIbA/R +lU6v8737lak8Q773j/vqcPsYJAAkCQkB+lHi4Zf4/BJcgkajc0dj7GD+z9JKSfdO4j886Mb/VH5 3+v6RNGsxr2Ja5x/znpO0ILuexsI/wCjWxJCtIJkhjvpPP0nn91qeHbhAAfHtb2Y3x/rJ2te4yJn /SP7f1GIjGBogd9STyT5pKU1oY0NHZSSSSUxfWx/0hPgeD96AcV4+hZ8ngH8m1WUklNQOyaT72yw 8ubLo/lfvIjX7xO6QeDOn/R2f9UjobqW7tzPa48xwfiElLNj4eQgf9TKmDHw+5R9w5/Cf70+vYH7 o/6pJT//0fVUl8qpJKfqpJfKqSSn6qSXyqkkp+p7PoH6P9rhCZtnXb/1uf8Avq+XUklP1G/Z2/6e 6E9HJ/m/7H/fl8tpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp//Z/+0dyFBo b3Rvc2hvcCAzLjAAOEJJTQQEAAAAAAAvHAFaAAMbJUccAVoAAxslRxwBWgADGyVHHAFaAAMbJUcc AVoAAxslRxwCAAACAAAAOEJJTQQlAAAAAAAQbrNy3vn/dsPQ3CJIvyt90zhCSU0EOgAAAAAAjQAA ABAAAAABAAAAAAALcHJpbnRPdXRwdXQAAAAEAAAAAFBzdFNib29sAQAAAABJbnRlZW51bQAAAABJ bnRlAAAAAENscm0AAAAPcHJpbnRTaXh0ZWVuQml0Ym9vbAAAAAALcHJpbnRlck5hbWVURVhUAAAA DABwAHIAdAAtAGkAcgB2AC0AMAA3ADIAAAA4QklNBDsAAAAAAbIAAAAQAAAAAQAAAAAAEnByaW50 T3V0cHV0T3B0aW9ucwAAABIAAAAAQ3B0bmJvb2wAAAAAAENsYnJib29sAAAAAABSZ3NNYm9vbAAA AAAAQ3JuQ2Jvb2wAAAAAAENudENib29sAAAAAABMYmxzYm9vbAAAAAAATmd0dmJvb2wAAAAAAEVt bERib29sAAAAAABJbnRyYm9vbAAAAAAAQmNrZ09iamMAAAABAAAAAAAAUkdCQwAAAAMAAAAAUmQg IGRvdWJAb+AAAAAAAAAAAABHcm4gZG91YkBv4AAAAAAAAAAAAEJsICBkb3ViQG/gAAAAAAAAAAAA QnJkVFVudEYjUmx0AAAAAAAAAAAAAAAAQmxkIFVudEYjUmx0AAAAAAAAAAAAAAAAUnNsdFVudEYj UHhsQFgAAAAAAAAAAAAKdmVjdG9yRGF0YWJvb2wBAAAAAFBnUHNlbnVtAAAAAFBnUHMAAAAAUGdQ QwAAAABMZWZ0VW50RiNSbHQAAAAAAAAAAAAAAABUb3AgVW50RiNSbHQAAAAAAAAAAAAAAABTY2wg VW50RiNQcmNAWQAAAAAAADhCSU0D7QAAAAAAEABgAAAAAQABAGAAAAABAAE4QklNBCYAAAAAAA4A AAAAAAAAAAAAP4AAADhCSU0D8gAAAAAACgAA////////AAA4QklNBA0AAAAAAAQAAABaOEJJTQQZ AAAAAAAEAAAAHjhCSU0D8wAAAAAACQAAAAAAAAAAAQA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAA CgABAAAAAAAAAAE4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAA AAEAMgAAAAEAWgAAAAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAAAHAAAP////// //////////////////////8D6AAAAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAOEJJTQQAAAAA AAACABA4QklNBAIAAAAAACIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOEJJTQQw AAAAAAARAQEBAQEBAQEBAQEBAQEBAQEAOEJJTQQtAAAAAAAGAAEAAAAiOEJJTQQIAAAAAAAQAAAA AQAAAkAAAAJAAAAAADhCSU0EHgAAAAAABAAAAAA4QklNBBoAAAAAA2EAAAAGAAAAAAAAAAAAAAA6 AAABCAAAABYAMwA5ADEAMwAwAF8AZAAwADQALQAyAC4ANwA1AGkAbgBfADkANgBkAHAAaQAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAABCAAAADoAAAAAAAAAAAAAAAAAAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAQAAAAAQAAAAAAAG51bGwAAAACAAAABmJvdW5kc09iamMAAAABAAAAAAAA UmN0MQAAAAQAAAAAVG9wIGxvbmcAAAAAAAAAAExlZnRsb25nAAAAAAAAAABCdG9tbG9uZwAAADoA AAAAUmdodGxvbmcAAAEIAAAABnNsaWNlc1ZsTHMAAAABT2JqYwAAAAEAAAAAAAVzbGljZQAAABIA AAAHc2xpY2VJRGxvbmcAAAAAAAAAB2dyb3VwSURsb25nAAAAAAAAAAZvcmlnaW5lbnVtAAAADEVT bGljZU9yaWdpbgAAAA1hdXRvR2VuZXJhdGVkAAAAAFR5cGVlbnVtAAAACkVTbGljZVR5cGUAAAAA SW1nIAAAAAZib3VuZHNPYmpjAAAAAQAAAAAAAFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABM ZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAA6AAAAAFJnaHRsb25nAAABCAAAAAN1cmxURVhUAAAA AQAAAAAAAG51bGxURVhUAAAAAQAAAAAAAE1zZ2VURVhUAAAAAQAAAAAABmFsdFRhZ1RFWFQAAAAB AAAAAAAOY2VsbFRleHRJc0hUTUxib29sAQAAAAhjZWxsVGV4dFRFWFQAAAABAAAAAAAJaG9yekFs aWduZW51bQAAAA9FU2xpY2VIb3J6QWxpZ24AAAAHZGVmYXVsdAAAAAl2ZXJ0QWxpZ25lbnVtAAAA D0VTbGljZVZlcnRBbGlnbgAAAAdkZWZhdWx0AAAAC2JnQ29sb3JUeXBlZW51bQAAABFFU2xpY2VC R0NvbG9yVHlwZQAAAABOb25lAAAACXRvcE91dHNldGxvbmcAAAAAAAAACmxlZnRPdXRzZXRsb25n AAAAAAAAAAxib3R0b21PdXRzZXRsb25nAAAAAAAAAAtyaWdodE91dHNldGxvbmcAAAAAADhCSU0E KAAAAAAADAAAAAI/8AAAAAAAADhCSU0EFAAAAAAABAAAACY4QklNBAwAAAAAE5EAAAABAAAAoAAA ACMAAAHgAABBoAAAE3UAGAAB/9j/4gxYSUNDX1BST0ZJTEUAAQEAAAxITGlubwIQAABtbnRyUkdC IFhZWiAHzgACAAkABgAxAABhY3NwTVNGVAAAAABJRUMgc1JHQgAAAAAAAAAAAAAAAAAA9tYAAQAA AADTLUhQICAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABFj cHJ0AAABUAAAADNkZXNjAAABhAAAAGx3dHB0AAAB8AAAABRia3B0AAACBAAAABRyWFlaAAACGAAA ABRnWFlaAAACLAAAABRiWFlaAAACQAAAABRkbW5kAAACVAAAAHBkbWRkAAACxAAAAIh2dWVkAAAD TAAAAIZ2aWV3AAAD1AAAACRsdW1pAAAD+AAAABRtZWFzAAAEDAAAACR0ZWNoAAAEMAAAAAxyVFJD AAAEPAAACAxnVFJDAAAEPAAACAxiVFJDAAAEPAAACAx0ZXh0AAAAAENvcHlyaWdodCAoYykgMTk5 OCBIZXdsZXR0LVBhY2thcmQgQ29tcGFueQAAZGVzYwAAAAAAAAASc1JHQiBJRUM2MTk2Ni0yLjEA AAAAAAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAPNRAAEAAAABFsxYWVogAAAAAAAAAAAAAAAA AAAAAFhZWiAAAAAAAABvogAAOPUAAAOQWFlaIAAAAAAAAGKZAAC3hQAAGNpYWVogAAAAAAAAJKAA AA+EAAC2z2Rlc2MAAAAAAAAAFklFQyBodHRwOi8vd3d3LmllYy5jaAAAAAAAAAAAAAAAFklFQyBo dHRwOi8vd3d3LmllYy5jaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABkZXNjAAAAAAAAAC5JRUMgNjE5NjYtMi4xIERlZmF1bHQgUkdCIGNvbG91ciBzcGFjZSAt IHNSR0IAAAAAAAAAAAAAAC5JRUMgNjE5NjYtMi4xIERlZmF1bHQgUkdCIGNvbG91ciBzcGFjZSAt IHNSR0IAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZGVzYwAAAAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcg Q29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAALFJlZmVyZW5jZSBWaWV3aW5nIENv bmRpdGlvbiBpbiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHZpZXcAAAAA ABOk/gAUXy4AEM8UAAPtzAAEEwsAA1yeAAAAAVhZWiAAAAAAAEwJVgBQAAAAVx/nbWVhcwAAAAAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAo8AAAACc2lnIAAAAABDUlQgY3VydgAAAAAAAAQAAAAABQAK AA8AFAAZAB4AIwAoAC0AMgA3ADsAQABFAEoATwBUAFkAXgBjAGgAbQByAHcAfACBAIYAiwCQAJUA mgCfAKQAqQCuALIAtwC8AMEAxgDLANAA1QDbAOAA5QDrAPAA9gD7AQEBBwENARMBGQEfASUBKwEy ATgBPgFFAUwBUgFZAWABZwFuAXUBfAGDAYsBkgGaAaEBqQGxAbkBwQHJAdEB2QHhAekB8gH6AgMC DAIUAh0CJgIvAjgCQQJLAlQCXQJnAnECegKEAo4CmAKiAqwCtgLBAssC1QLgAusC9QMAAwsDFgMh Ay0DOANDA08DWgNmA3IDfgOKA5YDogOuA7oDxwPTA+AD7AP5BAYEEwQgBC0EOwRIBFUEYwRxBH4E jASaBKgEtgTEBNME4QTwBP4FDQUcBSsFOgVJBVgFZwV3BYYFlgWmBbUFxQXVBeUF9gYGBhYGJwY3 BkgGWQZqBnsGjAadBq8GwAbRBuMG9QcHBxkHKwc9B08HYQd0B4YHmQesB78H0gflB/gICwgfCDII RghaCG4IggiWCKoIvgjSCOcI+wkQCSUJOglPCWQJeQmPCaQJugnPCeUJ+woRCicKPQpUCmoKgQqY Cq4KxQrcCvMLCwsiCzkLUQtpC4ALmAuwC8gL4Qv5DBIMKgxDDFwMdQyODKcMwAzZDPMNDQ0mDUAN Wg10DY4NqQ3DDd4N+A4TDi4OSQ5kDn8Omw62DtIO7g8JDyUPQQ9eD3oPlg+zD88P7BAJECYQQxBh EH4QmxC5ENcQ9RETETERTxFtEYwRqhHJEegSBxImEkUSZBKEEqMSwxLjEwMTIxNDE2MTgxOkE8UT 5RQGFCcUSRRqFIsUrRTOFPAVEhU0FVYVeBWbFb0V4BYDFiYWSRZsFo8WshbWFvoXHRdBF2UXiReu F9IX9xgbGEAYZRiKGK8Y1Rj6GSAZRRlrGZEZtxndGgQaKhpRGncanhrFGuwbFBs7G2MbihuyG9oc AhwqHFIcexyjHMwc9R0eHUcdcB2ZHcMd7B4WHkAeah6UHr4e6R8THz4faR+UH78f6iAVIEEgbCCY IMQg8CEcIUghdSGhIc4h+yInIlUigiKvIt0jCiM4I2YjlCPCI/AkHyRNJHwkqyTaJQklOCVoJZcl xyX3JicmVyaHJrcm6CcYJ0kneierJ9woDSg/KHEooijUKQYpOClrKZ0p0CoCKjUqaCqbKs8rAis2 K2krnSvRLAUsOSxuLKIs1y0MLUEtdi2rLeEuFi5MLoIuty7uLyQvWi+RL8cv/jA1MGwwpDDbMRIx SjGCMbox8jIqMmMymzLUMw0zRjN/M7gz8TQrNGU0njTYNRM1TTWHNcI1/TY3NnI2rjbpNyQ3YDec N9c4FDhQOIw4yDkFOUI5fzm8Ofk6Njp0OrI67zstO2s7qjvoPCc8ZTykPOM9Ij1hPaE94D4gPmA+ oD7gPyE/YT+iP+JAI0BkQKZA50EpQWpBrEHuQjBCckK1QvdDOkN9Q8BEA0RHRIpEzkUSRVVFmkXe RiJGZ0arRvBHNUd7R8BIBUhLSJFI10kdSWNJqUnwSjdKfUrESwxLU0uaS+JMKkxyTLpNAk1KTZNN 3E4lTm5Ot08AT0lPk0/dUCdQcVC7UQZRUFGbUeZSMVJ8UsdTE1NfU6pT9lRCVI9U21UoVXVVwlYP VlxWqVb3V0RXklfgWC9YfVjLWRpZaVm4WgdaVlqmWvVbRVuVW+VcNVyGXNZdJ114XcleGl5sXr1f D19hX7NgBWBXYKpg/GFPYaJh9WJJYpxi8GNDY5dj62RAZJRk6WU9ZZJl52Y9ZpJm6Gc9Z5Nn6Wg/ aJZo7GlDaZpp8WpIap9q92tPa6dr/2xXbK9tCG1gbbluEm5rbsRvHm94b9FwK3CGcOBxOnGVcfBy S3KmcwFzXXO4dBR0cHTMdSh1hXXhdj52m3b4d1Z3s3gReG54zHkqeYl553pGeqV7BHtje8J8IXyB fOF9QX2hfgF+Yn7CfyN/hH/lgEeAqIEKgWuBzYIwgpKC9INXg7qEHYSAhOOFR4Wrhg6GcobXhzuH n4gEiGmIzokziZmJ/opkisqLMIuWi/yMY4zKjTGNmI3/jmaOzo82j56QBpBukNaRP5GokhGSepLj k02TtpQglIqU9JVflcmWNJaflwqXdZfgmEyYuJkkmZCZ/JpomtWbQpuvnByciZz3nWSd0p5Anq6f HZ+Ln/qgaaDYoUehtqImopajBqN2o+akVqTHpTilqaYapoum/adup+CoUqjEqTepqaocqo+rAqt1 q+msXKzQrUStuK4trqGvFq+LsACwdbDqsWCx1rJLssKzOLOutCW0nLUTtYq2AbZ5tvC3aLfguFm4 0blKucK6O7q1uy67p7whvJu9Fb2Pvgq+hL7/v3q/9cBwwOzBZ8Hjwl/C28NYw9TEUcTOxUvFyMZG xsPHQce/yD3IvMk6ybnKOMq3yzbLtsw1zLXNNc21zjbOts83z7jQOdC60TzRvtI/0sHTRNPG1EnU y9VO1dHWVdbY11zX4Nhk2OjZbNnx2nba+9uA3AXcit0Q3ZbeHN6i3ynfr+A24L3hROHM4lPi2+Nj 4+vkc+T85YTmDeaW5x/nqegy6LzpRunQ6lvq5etw6/vshu0R7ZzuKO6070DvzPBY8OXxcvH/8ozz GfOn9DT0wvVQ9d72bfb794r4Gfio+Tj5x/pX+uf7d/wH/Jj9Kf26/kv+3P9t////7QAMQWRvYmVf Q00AAf/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACMAoAMBIgACEQED EQH/3QAEAAr/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APUXtbyQPiTCGXAH2vA8w8/kcHNRnmBMho8Xf6hD3OPDnu+AAH/TH/fklKbc4AFw3NPcR/e5n/SQ MXrHTMvNvwcbIbZlYv8AP1CZbrtOpG1+x3ss2fzf+ERtjtwO109yQ3/vha5cR9WnlnWcTOaId1Vu eSfHbd6uv/babKVGI7/+i/8AdNnl+Xjkx5pkkHHG4V+/wzy+r/qeHI98kgsyAdH+0+PZF5Tmsukk kkpSi94bzqTw0clRNknbWN7vHsP6zkOZBeHafn2/98qSUu5zzMmI+lBhrf6z/pOcofpJG1zg48Dk keOx/wBBv9dSg+0BuvNdfh/wliWkGfc0mHHu937jf5CSmPr5DIkNsaeCJbP/AFX+f/NqTcuRrW4e Ygj8oThhc4hxk/4U9v5NQ/kp30kas4/d/wDIpKZNvY7sW/EKfKqgxI7jt/rt/wBf9F/OKbbC0/Ht /r+d/q9JTYSTAhwBGoPCdJSkkxcAYnXwSSU//9DuPrn1bK6N9W87qWG0faqWtbQ4gOIfY9lAcGGd 2z1PUXAu+vH15NTnMcXMxpf9o+yNFd1dl9WHhWO3uY59NznW/pMFvq/8D+jsuXpXU+n9Ty7GfZOp PwadpbbWypj3Ok/SZbb7qXbf3FT/AOaOFW31cXJyqeoCD9vNz7LHOHH2iux32e5n+kq9JAk9B+LN DHiMQZ5uEn9GMJT4f9qf1f8A417zxVf16+sPrWP9IZGReLsZ/S2YdkYWU1xqwq35LW225tl9TLcz Jp/0VNnpMVTH+snWrX9Io6ZTQzPxsYmnC+yPJflvyrsTMqn2NwKXYtX2zJte+n0//PPd39M+tfUN mHn5eNTgh4N12J6rMi1jf8G7cfTp9b/Cem9a/VcA9R6fdhtufjOtHsuqJDmuB3Md7S3c3cPezd70 Lu/TttaTAQMY+8KmfX7fFKMIfJxS+Xj9E8no/wC/fOm/XXr7qMrO9VtRY/0szAswrS3pbfW+zsyL 8xjf121lH6e2iz/rdP6OxirWfXr654Wwek7Kx213mvLGN6RyWWDIHSs+2ghv2Zu/Esv9L9H6uKu5 ZgfW7KY3Fz83HxscACzIwg/7TYB7fp3D0sZz/wDSVM/4tKz6p49B9fpeTk4OVO51zLXWb3f92acl z6sj/wADS4j0j9uiThxR0lnjxHb24yyY/wDqk/Rw/wCBDKk+q/VL+odDxbsu825ra2DMJYKoucxm S6vZZXW32VZFX81+jWmXA/ScHf1nT/0Kxtcq2BTnUUmvNzDnXFxItNbaSGwP0fpVOr/O9+5WpPEO +94/76nD7GCQAJAkJAfpR4uGX+PwSXIJGo3NHY+xg/s/SSkn3TuI/POjG/1R+d/r+kTRrMa9iWuc f856TtCC7nsbCP8Ao1sSQrSCZIY76Tz9J5/danh24QAHx7W9mN8f6ydrXuMiZ/0j+39RiIxgaIHf Uk8k+aSlNaGNDR2UkkklMX1sf9IT4Hg/egHFePoWfJ4B/JtVlJJTUDsmk+9ssPLmy6P5X7yI1+8T ukHgzp/0dn/VI6G6lu7cz2uPMcH4hJSzY+HkIH/Uypgx8PuUfcOfwn+9Pr2B+6P+qSU//9H1VJfK qSSn6qSXyqkkp+qkl8qpJKfqez6B+j/a4QmbZ12/9bn/AL6vl1JJT9Rv2dv+nuhPRyf5v+x/35fL aSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKf/2QA4QklNBCEAAAAAAFUAAAAB AQAAAA8AQQBkAG8AYgBlACAAUABoAG8AdABvAHMAaABvAHAAAAATAEEAZABvAGIAZQAgAFAAaABv AHQAbwBzAGgAbwBwACAAQwBTADUAAAABADhCSU0PoAAAAAABHG1hbmlJUkZSAAABEDhCSU1BbkRz AAAA8AAAABAAAAABAAAAAAAAbnVsbAAAAAMAAAAAQUZTdGxvbmcAAAAAAAAAAEZySW5WbExzAAAA AU9iamMAAAABAAAAAAAAbnVsbAAAAAMAAAAARnJJRGxvbmd4CbGJAAAAAEZyRGxsb25nAAAD6AAA AABGckdBZG91YkBWgAAAAAAAAAAAAEZTdHNWbExzAAAAAU9iamMAAAABAAAAAAAAbnVsbAAAAAQA AAAARnNJRGxvbmcAAAAAAAAAAEFGcm1sb25nAAAAAAAAAABGc0ZyVmxMcwAAAAFsb25neAmxiQAA AABMQ250bG9uZwAAAAEAADhCSU1Sb2xsAAAACAAAAAAAAAAAOEJJTQ+hAAAAAAAcbWZyaQAAAAIA AAAQAAAAAQAAAAAAAAABAAAAADhCSU0EBgAAAAAABwAIAAAAAQEA/+EmSGh0dHA6Ly9ucy5hZG9i ZS5jb20veGFwLzEuMC8APD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6 TlRjemtjOWQiPz4gPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0i QWRvYmUgWE1QIENvcmUgNS4wLWMwNjAgNjEuMTM0Nzc3LCAyMDEwLzAyLzEyLTE3OjMyOjAwICAg ICAgICAiPiA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjIt cmRmLXN5bnRheC1ucyMiPiA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4bXA9 Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcv ZGMvZWxlbWVudHMvMS4xLyIgeG1sbnM6eG1wTU09Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEu MC9tbS8iIHhtbG5zOnN0RXZ0PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvc1R5cGUvUmVz b3VyY2VFdmVudCMiIHhtbG5zOnN0UmVmPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvc1R5 cGUvUmVzb3VyY2VSZWYjIiB4bWxuczpwaG90b3Nob3A9Imh0dHA6Ly9ucy5hZG9iZS5jb20vcGhv dG9zaG9wLzEuMC8iIHhtbG5zOnhtcFJpZ2h0cz0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4w L3JpZ2h0cy8iIHhtbG5zOkV4dGVuc2lzRm9udFNlbnNlPSJodHRwOi8vd3d3LmV4dGVuc2lzLmNv bS9tZXRhL0ZvbnRTZW5zZS8iIHhtcDpDcmVhdG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIENTNSBN YWNpbnRvc2giIHhtcDpDcmVhdGVEYXRlPSIyMDEyLTA2LTEyVDE3OjAyOjQ4LTA3OjAwIiB4bXA6 TWV0YWRhdGFEYXRlPSIyMDEyLTA2LTE1VDE2OjE2OjQ4LTA3OjAwIiB4bXA6TW9kaWZ5RGF0ZT0i MjAxMi0wNi0xNVQxNjoxNjo0OC0wNzowMCIgZGM6Zm9ybWF0PSJpbWFnZS9qcGVnIiB4bXBNTTpJ bnN0YW5jZUlEPSJ4bXAuaWlkOkE2NzIxMzBCMzAyMDY4MTE5N0E1QzA4QzdBOUMwODY3IiB4bXBN TTpEb2N1bWVudElEPSJ4bXAuZGlkOkUxNkY4NzM3MzUyMDY4MTE5NDU3RDEzMkQxRDVFMkU3IiB4 bXBNTTpPcmlnaW5hbERvY3VtZW50SUQ9InhtcC5kaWQ6RTM2Rjg3MzczNTIwNjgxMTk0NTdEMTMy RDFENUUyRTciIHBob3Rvc2hvcDpDb2xvck1vZGU9IjMiIHBob3Rvc2hvcDpJQ0NQcm9maWxlPSJz UkdCIElFQzYxOTY2LTIuMSIgeG1wUmlnaHRzOk1hcmtlZD0iRmFsc2UiPiA8eG1wTU06SGlzdG9y eT4gPHJkZjpTZXE+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJjcmVhdGVkIiBzdEV2dDppbnN0YW5j ZUlEPSJ4bXAuaWlkOkUzNkY4NzM3MzUyMDY4MTE5NDU3RDEzMkQxRDVFMkU3IiBzdEV2dDp3aGVu PSIyMDEyLTA2LTEyVDE3OjAyOjQ4LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBQ aG90b3Nob3AgQ1M1IE1hY2ludG9zaCIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0 RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6RTQ2Rjg3MzczNTIwNjgxMTk0NTdEMTMyRDFENUUyRTci IHN0RXZ0OndoZW49IjIwMTItMDYtMTJUMTc6MDM6MjMtMDc6MDAiIHN0RXZ0OnNvZnR3YXJlQWdl bnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgTWFjaW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDxy ZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDpFNTZG ODczNzM1MjA2ODExOTQ1N0QxMzJEMUQ1RTJFNyIgc3RFdnQ6d2hlbj0iMjAxMi0wNi0xMlQxNzow NjoxMy0wNzowMCIgc3RFdnQ6c29mdHdhcmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNp bnRvc2giIHN0RXZ0OmNoYW5nZWQ9Ii8iLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249InNhdmVkIiBz dEV2dDppbnN0YW5jZUlEPSJ4bXAuaWlkOkU2NkY4NzM3MzUyMDY4MTE5NDU3RDEzMkQxRDVFMkU3 IiBzdEV2dDp3aGVuPSIyMDEyLTA2LTEyVDE3OjA3OjE5LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFn ZW50PSJBZG9iZSBQaG90b3Nob3AgQ1M1IE1hY2ludG9zaCIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8 cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6RTc2 Rjg3MzczNTIwNjgxMTk0NTdEMTMyRDFENUUyRTciIHN0RXZ0OndoZW49IjIwMTItMDYtMTJUMTc6 MDk6NTAtMDc6MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgTWFj aW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIg c3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDowMTgwMTE3NDA3MjA2ODExQjFBNENFMDczQzY3M0Q2 MCIgc3RFdnQ6d2hlbj0iMjAxMi0wNi0xM1QwOTozMjoyNS0wNzowMCIgc3RFdnQ6c29mdHdhcmVB Z2VudD0iQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2giIHN0RXZ0OmNoYW5nZWQ9Ii8iLz4g PHJkZjpsaSBzdEV2dDphY3Rpb249InNhdmVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAuaWlkOjAy ODAxMTc0MDcyMDY4MTFCMUE0Q0UwNzNDNjczRDYwIiBzdEV2dDp3aGVuPSIyMDEyLTA2LTEzVDA5 OjQ3OjQ5LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBQaG90b3Nob3AgQ1M1IE1h Y2ludG9zaCIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQi IHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6MDM4MDExNzQwNzIwNjgxMUIxQTRDRTA3M0M2NzNE NjAiIHN0RXZ0OndoZW49IjIwMTItMDYtMTNUMDk6NTE6MTctMDc6MDAiIHN0RXZ0OnNvZnR3YXJl QWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgTWFjaW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIvIi8+ IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDpE ODJERkUyQTE1MjA2ODExQjFBNENFMDczQzY3M0Q2MCIgc3RFdnQ6d2hlbj0iMjAxMi0wNi0xM1Qx MToxMDozNS0wNzowMCIgc3RFdnQ6c29mdHdhcmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9wIENTNSBN YWNpbnRvc2giIHN0RXZ0OmNoYW5nZWQ9Ii8iLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249InNhdmVk IiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAuaWlkOjA2RkU2QzkyMUQyMDY4MTE4RjYyRUFGRTIwMjBF M0M2IiBzdEV2dDp3aGVuPSIyMDEyLTA2LTE0VDExOjU3OjIwLTA3OjAwIiBzdEV2dDpzb2Z0d2Fy ZUFnZW50PSJBZG9iZSBQaG90b3Nob3AgQ1M1IE1hY2ludG9zaCIgc3RFdnQ6Y2hhbmdlZD0iLyIv PiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6 MDdGRTZDOTIxRDIwNjgxMThGNjJFQUZFMjAyMEUzQzYiIHN0RXZ0OndoZW49IjIwMTItMDYtMTRU MTE6NTc6MjAtMDc6MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUg TWFjaW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZl ZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDowOEZFNkM5MjFEMjA2ODExOEY2MkVBRkUyMDIw RTNDNiIgc3RFdnQ6d2hlbj0iMjAxMi0wNi0xNFQxMTo1ODoyNi0wNzowMCIgc3RFdnQ6c29mdHdh cmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2giIHN0RXZ0OmNoYW5nZWQ9Ii8i Lz4gPHJkZjpsaSBzdEV2dDphY3Rpb249InNhdmVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAuaWlk OjA5RkU2QzkyMUQyMDY4MTE4RjYyRUFGRTIwMjBFM0M2IiBzdEV2dDp3aGVuPSIyMDEyLTA2LTE0 VDExOjU5OjA5LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBQaG90b3Nob3AgQ1M1 IE1hY2ludG9zaCIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2 ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6MEFGRTZDOTIxRDIwNjgxMThGNjJFQUZFMjAy MEUzQzYiIHN0RXZ0OndoZW49IjIwMTItMDYtMTRUMTE6NTk6MjctMDc6MDAiIHN0RXZ0OnNvZnR3 YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgTWFjaW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIv Ii8+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlp ZDozMUM2OTQxQTJBMjA2ODExOEY2MkVBRkUyMDIwRTNDNiIgc3RFdnQ6d2hlbj0iMjAxMi0wNi0x NFQxNToyNjoxOC0wNzowMCIgc3RFdnQ6c29mdHdhcmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9wIENT NSBNYWNpbnRvc2giIHN0RXZ0OmNoYW5nZWQ9Ii8iLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249InNh dmVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAuaWlkOkYzMTUzRDIzMTkyMDY4MTE5N0E1QzA4QzdB OUMwODY3IiBzdEV2dDp3aGVuPSIyMDEyLTA2LTE1VDEyOjE4OjI0LTA3OjAwIiBzdEV2dDpzb2Z0 d2FyZUFnZW50PSJBZG9iZSBQaG90b3Nob3AgQ1M1IE1hY2ludG9zaCIgc3RFdnQ6Y2hhbmdlZD0i LyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5p aWQ6RjQxNTNEMjMxOTIwNjgxMTk3QTVDMDhDN0E5QzA4NjciIHN0RXZ0OndoZW49IjIwMTItMDYt MTVUMTI6MTg6MjQtMDc6MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBD UzUgTWFjaW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJz YXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDowRTQ2QzEwRDFGMjA2ODExOTdBNUMwOEM3 QTlDMDg2NyIgc3RFdnQ6d2hlbj0iMjAxMi0wNi0xNVQxNDozMDoxOC0wNzowMCIgc3RFdnQ6c29m dHdhcmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2giIHN0RXZ0OmNoYW5nZWQ9 Ii8iLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249InNhdmVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAu aWlkOjBGNDZDMTBEMUYyMDY4MTE5N0E1QzA4QzdBOUMwODY3IiBzdEV2dDp3aGVuPSIyMDEyLTA2 LTE1VDE0OjMwOjE4LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBQaG90b3Nob3Ag Q1M1IE1hY2ludG9zaCIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0i c2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6QTQ3MjEzMEIzMDIwNjgxMTk3QTVDMDhD N0E5QzA4NjciIHN0RXZ0OndoZW49IjIwMTItMDYtMTVUMTY6MTE6NDUtMDc6MDAiIHN0RXZ0OnNv ZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgTWFjaW50b3NoIiBzdEV2dDpjaGFuZ2Vk PSIvIi8+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1w LmlpZDpBNTcyMTMwQjMwMjA2ODExOTdBNUMwOEM3QTlDMDg2NyIgc3RFdnQ6d2hlbj0iMjAxMi0w Ni0xNVQxNjoxNjo0OC0wNzowMCIgc3RFdnQ6c29mdHdhcmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9w IENTNSBNYWNpbnRvc2giIHN0RXZ0OmNoYW5nZWQ9Ii8iLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249 ImNvbnZlcnRlZCIgc3RFdnQ6cGFyYW1ldGVycz0iZnJvbSBhcHBsaWNhdGlvbi92bmQuYWRvYmUu cGhvdG9zaG9wIHRvIGltYWdlL2pwZWciLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249ImRlcml2ZWQi IHN0RXZ0OnBhcmFtZXRlcnM9ImNvbnZlcnRlZCBmcm9tIGFwcGxpY2F0aW9uL3ZuZC5hZG9iZS5w aG90b3Nob3AgdG8gaW1hZ2UvanBlZyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0 RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6QTY3MjEzMEIzMDIwNjgxMTk3QTVDMDhDN0E5QzA4Njci IHN0RXZ0OndoZW49IjIwMTItMDYtMTVUMTY6MTY6NDgtMDc6MDAiIHN0RXZ0OnNvZnR3YXJlQWdl bnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgTWFjaW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDwv cmRmOlNlcT4gPC94bXBNTTpIaXN0b3J5PiA8eG1wTU06RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFu Y2VJRD0ieG1wLmlpZDpBNTcyMTMwQjMwMjA2ODExOTdBNUMwOEM3QTlDMDg2NyIgc3RSZWY6ZG9j dW1lbnRJRD0ieG1wLmRpZDpFMTZGODczNzM1MjA2ODExOTQ1N0QxMzJEMUQ1RTJFNyIgc3RSZWY6 b3JpZ2luYWxEb2N1bWVudElEPSJ4bXAuZGlkOkUzNkY4NzM3MzUyMDY4MTE5NDU3RDEzMkQxRDVF MkU3Ii8+IDxwaG90b3Nob3A6VGV4dExheWVycz4gPHJkZjpCYWc+IDxyZGY6bGkgcGhvdG9zaG9w OkxheWVyTmFtZT0iRm9sbG93IEJyb2FkY29tIG9uIFR3aXR0ZXIsIEZhY2Vib29rLCBHb29nbGUr LCBMaW5rZWRJbiBhbmQgWW91IiBwaG90b3Nob3A6TGF5ZXJUZXh0PSJGb2xsb3cgQnJvYWRjb20g b24gVHdpdHRlciwgRmFjZWJvb2ssIEdvb2dsZSssIExpbmtlZEluIGFuZCBZb3VUdWJlIFN0YXkg Q29ubmVjdGVkOiBSZWFkIHRoZSBCcm9hZGNvbSBDb25uZWN0ZWQgQmxvZyIvPiA8cmRmOmxpIHBo b3Rvc2hvcDpMYXllck5hbWU9IlRBTEVOVCBBQ1FVSVNJVElPTiIgcGhvdG9zaG9wOkxheWVyVGV4 dD0iVEFMRU5UIEFDUVVJU0lUSU9OIi8+IDwvcmRmOkJhZz4gPC9waG90b3Nob3A6VGV4dExheWVy cz4gPEV4dGVuc2lzRm9udFNlbnNlOnNsdWc+IDxyZGY6QmFnPiA8cmRmOmxpIEV4dGVuc2lzRm9u dFNlbnNlOkZvbnRTZW5zZV8xLjJfQ2hlY2tzdW09IjIxNjk2MTE2MDMiIEV4dGVuc2lzRm9udFNl bnNlOlZlcnNpb249IjUuMDEuMiIgRXh0ZW5zaXNGb250U2Vuc2U6RmFtaWx5PSJBcmlhbCIgRXh0 ZW5zaXNGb250U2Vuc2U6T3V0bGluZUZpbGVTaXplPSIwIiBFeHRlbnNpc0ZvbnRTZW5zZTpLZXJu aW5nQ2hlY2tzdW09IjAiIEV4dGVuc2lzRm9udFNlbnNlOkZvdW5kcnk9Ik1vbm90eXBlIFR5cG9n cmFwaHkiIEV4dGVuc2lzRm9udFNlbnNlOkZvbnRLaW5kPSJPcGVuVHlwZSAtIFRUIiBFeHRlbnNp c0ZvbnRTZW5zZTpDaGVja3N1bT0iMjE2OTYxMTYwMyIgRXh0ZW5zaXNGb250U2Vuc2U6UG9zdFNj cmlwdE5hbWU9IkFyaWFsTVQiLz4gPHJkZjpsaSBFeHRlbnNpc0ZvbnRTZW5zZTpGb250U2Vuc2Vf MS4yX0NoZWNrc3VtPSIyMzY3MTYxNzI2IiBFeHRlbnNpc0ZvbnRTZW5zZTpWZXJzaW9uPSIwMDEu MDA2IiBFeHRlbnNpc0ZvbnRTZW5zZTpGYW1pbHk9IkhlbHZldGljYSIgRXh0ZW5zaXNGb250U2Vu c2U6T3V0bGluZUZpbGVTaXplPSIyOTc1MyIgRXh0ZW5zaXNGb250U2Vuc2U6S2VybmluZ0NoZWNr c3VtPSIxMzg5MzQiIEV4dGVuc2lzRm9udFNlbnNlOkZvdW5kcnk9IkFkb2JlIFN5c3RlbXMiIEV4 dGVuc2lzRm9udFNlbnNlOkZvbnRLaW5kPSJQb3N0U2NyaXB0IiBFeHRlbnNpc0ZvbnRTZW5zZTpD aGVja3N1bT0iMjM2NzE2MTcyNiIgRXh0ZW5zaXNGb250U2Vuc2U6UG9zdFNjcmlwdE5hbWU9Ikhl bHZldGljYSIvPiA8cmRmOmxpIEV4dGVuc2lzRm9udFNlbnNlOkZvbnRTZW5zZV8xLjJfQ2hlY2tz dW09IjE1NTIyNjEyNzEiIEV4dGVuc2lzRm9udFNlbnNlOlZlcnNpb249IjUuMDEuMiIgRXh0ZW5z aXNGb250U2Vuc2U6RmFtaWx5PSJBcmlhbCIgRXh0ZW5zaXNGb250U2Vuc2U6T3V0bGluZUZpbGVT aXplPSIwIiBFeHRlbnNpc0ZvbnRTZW5zZTpLZXJuaW5nQ2hlY2tzdW09IjAiIEV4dGVuc2lzRm9u dFNlbnNlOkZvdW5kcnk9Ik1vbm90eXBlIFR5cG9ncmFwaHkiIEV4dGVuc2lzRm9udFNlbnNlOkZv bnRLaW5kPSJPcGVuVHlwZSAtIFRUIiBFeHRlbnNpc0ZvbnRTZW5zZTpDaGVja3N1bT0iMTU1MjI2 MTI3MSIgRXh0ZW5zaXNGb250U2Vuc2U6UG9zdFNjcmlwdE5hbWU9IkFyaWFsLUJvbGRNVCIvPiA8 L3JkZjpCYWc+IDwvRXh0ZW5zaXNGb250U2Vuc2U6c2x1Zz4gPC9yZGY6RGVzY3JpcHRpb24+IDwv cmRmOlJERj4gPC94OnhtcG1ldGE+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPD94cGFja2V0IGVuZD0idyI/Pv/iDFhJQ0NfUFJPRklMRQABAQAA DEhMaW5vAhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAA AAAAAAAAAAABAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQA AAIEAAAAFHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRt ZGQAAALEAAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAA JHRlY2gAAAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAA Q29weXJpZ2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJz UkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEW zFhZWiAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeF AAAY2lhZWiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNo AAAAAAAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBS R0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBS R0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxS ZWZlcmVuY2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVm ZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlW AFAAAABXH+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBj dXJ2AAAAAAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABt AHIAdwB8AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsB AQEHAQ0BEwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHB AckB0QHZAeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsEC ywLVAuAC6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQT BCAELQQ7BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYF tQXFBdUF5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZ B6wHvwfSB+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J 5Qn7ChEKJwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1 DI4MpwzADNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14P eg+WD7MPzw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLD EuMTAxMjE0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwW jxayFtYW+hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqe GsUa7BsUGzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMf Ph9pH5Qfvx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQf JE0kfCSrJNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWsp nSnQKgIqNSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9a L5Evxy/+MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1 wjX9Njc2cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8Jzxl PKQ84z0iPWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31D wEQDREdEikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtT S5pL4kwqTHJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19T qlP2VEJUj1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1 XIZc1l0nXXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1l kmXnZj1mkmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8e b3hv0XArcIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5 iXnnekZ6pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQd hICE44VHhauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaP npAGkG6Q1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtC m6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n 4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSc tRO1irYBtnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePC X8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA5 0LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLf Kd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o 7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+ S/7c/23////uAA5BZG9iZQBkQAAAAAH/2wCEAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQECAgICAgICAgICAgMDAwMDAwMDAwMBAQEBAQEBAQEBAQICAQICAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA//AABEIADoBCAMBEQAC EQEDEQH/3QAEACH/xAGiAAAABgIDAQAAAAAAAAAAAAAHCAYFBAkDCgIBAAsBAAAGAwEBAQAAAAAA AAAAAAYFBAMHAggBCQAKCxAAAgEDBAEDAwIDAwMCBgl1AQIDBBEFEgYhBxMiAAgxFEEyIxUJUUIW YSQzF1JxgRhikSVDobHwJjRyChnB0TUn4VM2gvGSokRUc0VGN0djKFVWVxqywtLi8mSDdJOEZaOz w9PjKThm83UqOTpISUpYWVpnaGlqdnd4eXqFhoeIiYqUlZaXmJmapKWmp6ipqrS1tre4ubrExcbH yMnK1NXW19jZ2uTl5ufo6er09fb3+Pn6EQACAQMCBAQDBQQEBAYGBW0BAgMRBCESBTEGACITQVEH MmEUcQhCgSORFVKhYhYzCbEkwdFDcvAX4YI0JZJTGGNE8aKyJjUZVDZFZCcKc4OTRnTC0uLyVWV1 VjeEhaOzw9Pj8ykalKS0xNTk9JWltcXV5fUoR1dmOHaGlqa2xtbm9md3h5ent8fX5/dIWGh4iJio uMjY6Pg5SVlpeYmZqbnJ2en5KjpKWmp6ipqqusra6vr/2gAMAwEAAhEDEQA/AN92txOPlvLU1mVp wOSYdwZqiQcAcJT5CKPm30t9f8T7917pNSxbeR3EWf3RG4AuabMbkrlQG3KiZq6FtVvqQfrx73+X WvzPUH+NU9I1qbsanRg2kQ7vx+PSEsCF8SSwRbYqbliAC0kjBj+f0+/fl178+nyDceTgiWbJYday iI/4u+1ak52jItq1y0CxQZaO4/swx1QH5b8+/U69XpR47KY7L0/3WMraetg1FGaCQMYpB+qKePiS CdDwyOFdTwQD711vqf7917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v 3XumrLZqgw0UT1kjtNUuYaKiponqa+vnA1eCio4g01RIByxA0ovqYqoJ9+690mchlM4lOa7J1uP2 djmdY4YniXN5+oke/jhjWORsfFWyW9NPDFkGc/pb8e99az0nq6o3XFRyZBdwZXB46IkjIbrk2nRy zFwBCq4eg2hU1BSSThY5J6epP0K6jYbx6dez69R03bvnF0hravF0GcxUektlq4RbFDKSwGiPNV88 0zPYaNVLTh7/AOt79QevXqnrJRd07Zey5nHbg29IqxNO+Qxc0tJEKjV9u/no/PKYZ9J0MYlDWNuB f37T17UOlrjt9bOywH2G5cNMxAIieuhp57EXv9vUtDPx+fTx+feqH069UdKlHSRVeN1dGF1dGDKw P0KspII96631y9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//Q39JG 0DUI3kYDhUC6j/gC7Igv/iQPfuvdM09TuJiRRYnGov4kyOYmif8A2EFFi65W4HN5Vtf8/T3vHXs9 RCN4sSGTa7RE2aMtlCWQ/VC5jK3K8X0W/wAPx79jrWek5Pg6tJmqpNmUENSeWyGy9xNjMrIeCTIJ 6TbkUxB40y1MiMPrwSvv1fn178uk1Uhkr45xPVnM+mGmfJQw7R3kwtZYKXLeBdrbwVQCFp5UMZIu XJ97691q9d//AM5/5e9b/NnfGOwWdwyfG/pfuqHqjdmxp9gbaCbiotv5nLYTcdRmtySY3Kbyxu6M 2Nt5WemOOr4qOFqVNNPKius0W7jzbudvvVwsTD93QzaCukGtCQatTVU0YihpjgfPtr7T/cM9lua/ u68q3W92Nw3u7zBy6dyt7v6qdGhaeKKaBY7ZZVtGhh+oto5hNEzsZG/UjLJ4e3jFLFPFHNBJHNDK iyRSxOskUsbgMkkciEo6OpuCCQR7lDriX1k9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173 7r3Sey+caknjxWLgXJZ6qj8kFDrKQUlPrWNsjlZ1VzR0ERbjgyTMNEasb231qvTGVh25Mksvk3Lv bMxiKMeiKaWJGBkjp1PkjwW26F21OeRexYyzsNXuP2de/wAPXGSNMHNS5LL33HvLJa6bGUdMBHHD qCtUUuGgmLR4zF0y2apq5PWygGRiTHGPf4Ovf4esdRH/AAqWkyeaVdw7xrmaLB4qnJWjopjGPNFi IZtS0VHTI16rISjylP1EAxw+/de/w9YqiB6Cto5K1YNz76rleXHUzBo8TgYNQWarpoW8v8LxVGTp apYNWVb2QMSQie/wde/w9M+Z25DlaxcV5DnN5eOCrrNyVRZKTalOzjx/aUEMnhgWoDP4KDk1SgtU u6gs3v8AB1qn7egprtmU82QbGiGlrBBWPjTm55Xhx+UrKWqp6gY3bry00mNwWZEc8sD0kzyYwyR+ ONC2sRWr1qnWel2ZiqBJJoZq2mWjlaCqrJarIYpMfUTHUtPuShopWqtsV9iBHXItZjJEs3jVSp9+ r1ug6VVHQ5ajm8cOa3RFPTx/cyUL5WurapKZrWr2xcde9LuTHMbXqcbNGUBCml1XUe/Ide6EHF5/ JoKYTVEGShqgBSSySU/jyJF7pjcxTw0lK9WoBH2tVT082oEa2sW91630uKKvp65HaFmDxN46inlU xVFNLa5iqIW9Ub2Nx+GHKkgg+9db6me/de697917r3v3Xuve/de697917r3v3Xuve/de6//R38Zm nAtTxxu/4aaQxxj/AF9CSOf9YD/Y+/de6ZZcXmaxj9zuGejiP+6MNRUdMSP9S9VkI8pUH/g0fiJ/ w+nvf5de6TFVHsinleCu3Fkq+tU/uUq7t3BXVge9uMVjMkwidibAJApP0H9Pfs+nWsevXCT+60h8 kFBvsk3Xy0VN2JQFdNiGjYGj1I4P6kurjgkj37Py691DrKigFPJA+fzVPSSJolx++trZCtwcikD0 TVeRxeNqZLagGb751H1IPvf5de60Icnt6Tsj4kfMDvxaN3GV+ZfT2ZFfFQ414qenyOC+Qk9XSLVz LDm8ZDV1PY9G7RIggqWhiLqGgGmC2T6nad4v6ZN5Ga/aJa/POsV/L06+m2y3Icn++vsD7YiTTHb+ 326waO+haObYghNCyEom3yhSSdIdxq7xXdU+NXYGVy/RvSW9qGV2h3t0/wBb71mxtVRSwRVUO4tm 4XNTZD+G0lLGyQMtaXavxMGhS16ugjfUVmjb5fqLCxn/AI4Ub9qg/L1+XXzn+62yf1Z90fcnlzTT 937/ALhbU9PAu5oqfE/8PHU3+mPHo2+D3di814IS32GQqIjNDRVMsLisiXhqjFVtPJLQ5elUjl6e R9H0cI11CunQCr0qveut9e9+691737r3Xvfuvde9+6910zKqlmIVVBZmYgKqgXJJPAAHv3Xuke+d rc4zUu0xG9OGaOp3PURmTFU9rqwxMd0/jlWtuGQikQ/qkYgxndKcetceHUYS0+BeXB7egbNbnrSl VkKismLsjygIuW3LkI0JghEY/ZgRQzqvjgRUF09x48OvfZx69+1tgFI/LuHeWcCli5EdTXvD6fLL pEkeG27jWlPAHjiDWUSTP6/cfs69w+3rohdtWrKstuHeecH2sEcVonqjGTL9lQRsXTE7fxxfXLIb hV9cjSSsur3H7OvcPt69b+7aHI5AjObyzzLSU0MF4/uJB+5HisWjhzj8FjtXkmlYcKDNKS5A9+/w de4fb1xZanbtOEjaLL723NLp8r+Radp4lZmkKFnkpNubfhlJVAQSLC5mmJb3H7Ovf4esc1HJjoqf aWGqpmzGY8uSz2cfT95DRyMIsjmpWAKJkK6QCnoktojt6R44Cvv3zPXvl0rkw2LTFLhPsaZ8UtMt J9jJGstO0CgemRJA3kJI1Fmuxb1E3596630gsttnJYx46vHyV2Rp6WMxUtTTtHLufEUty7UeurPg 3bgxzejqyahRzG8kmm1q9a6SUE0Jip4o4qc05qiKWlpKh6DHjJj9b7VyNS0dZszcim5bE1pSGViU RrF3b3WunSOrDGdnkpZXq5hR1j1sBoMdl6z06cZurH6NW2t02t4axUWGdtNrgpGPdb6dYK4pJHIt VPSzQSpj6bIZIEVWNrG8bJtvdyKf8opakkfa1l2D6gVcsVeXXXuhAxWUTJwyaonpa2kk+2yNBKbz UVWEVzGWsBLDIjh4pV9MsbBh/Qa6306e/de697917r3v3Xuve/de6wLUwyO0cciysps4jOsIf6Oy 3VD/AIEg+/de6z+/de6//9LfqqVyEoKUklNSA/WomjaqkA/OinWSCPV/Qs5A/wBSfz7r3VePye/m Nfy7fh72HQ9V/Lz5a9c9adj5TauN3vR7K7CzmRhnn2rlslmcRjcz/AMJjJMOKOtyO36yKMTxtMRA SfSQzbr1qnQb77/nY/ypepKDYkuV+ZHQ9Fiuyto/372DX4rdGPfb+49oruTcezJM/jq/HRzQTY+n 3ds/K4uUxJI8WQxtTTsokglVPfn178ulxu3+a98D9ndBbe+Ue5fmf8WdvdC7vy2V2/tPf9H2EN+R bm3HgoYajO7XwGC26KHcma3ZgKaqilyGKpKSauoklQzRoro59jreep2Q+efxp7Y+E/bfyu6p+Xvx 0zXRW3trbsw2X7qlfJUmwtnbnkoYsRQYvesv8Yy+c2nkkzG4MarUtTi6ivKVkLR0c/nhSRmdXeCZ IqeIUIFeFSMVwcV+R+zo75YvNu27mTl7cN5SRtogvoJJxGA0hhSVGlEal4gXKBgoMkYLUBdPiGu9 R9R9D9NfyVt77i378vvh+2xvk78jNv1nR3yRx3ZG+h09nMvtStx1BWbL/itb1HQbin3FHH1DvaKS nFE8cFRRAFktUFAPb8qXsfL19tbzRfVyTK6kFtAA0cTo1A0DcFPl8+umHNX36PbrefvX+2fvZt+w b8nIWz8v3FhcwvDarfPLOL86oolv2tniDy2hrJPGw0zHQxWLVbN/Lr+W3xNzvwu2zQ7Z+Xfxl7Po PjH1pRw93bm697LhqNs9cYTa8OSSj3bvXFbnptm7r2jgxgsSzruOGloQxp5mZahYXlYX7TazWW22 dpcMpljQKStSMcKEgHhTiB1gV76c6cu+43u/7hc+cqWt1BsO77lJdRJcoiTqZqPIJEilnQHxS5Gi VwQQcfCBU+OP8zr+X78udzb02V8e/lZ1J2duvZWPym593bZoczFR5dcDg/E2Z3nT4XdNHtaj7C2r hFljepz2H+1rKRXQzSMWVmMOonp1P6O/nCfy9e6u1qjo3pn5tdHdidiU0OQmpNswbqqsric9T4nH VeYycmzt31lFj6rNpjMPj56uqNMc5FSUsMkry+NGdfYPW89CDsv+cH/Lv3x0r2l8icL8nusMj0l0 jldp4TtntDDZ18ttDY2V33kqfD7OocxKtHS5+KbcmVqkp6Qfw4eaUkLcq+nXXvy6OD0v8mOivkR1 ptHuPpXsbD9hdX78o6zIbP3rhabLphc/RUGUr8LWVVBNkMdRSNDT5bF1FOxZF/chYfj3rr1R0Jn9 8cEw/wAnkyNcx4EePwWcr31cWDfa46VYr3+rlVH1JA59+p16o64nL7grfTituSUqm9q3cVXBQQj6 WeOhoGyWRlIB/RKtNci2ofX3vr2fTplyVPioHibe2eGYqHbXS7fp6eSKgmYXIWm2xRPXZHMsCeBU NV2IBAU+/fZ177enO+4s2qw0sT7Tw+kIZ5Vp5Nw1EIAASkpF81DhY2T6PKZp1HHijYXHsfn17PUK kraWlSTCbGo4a6oWeX+IZaaSabFUdW1vuKrK5Qs9RmssWtqhjkeZjYSPEtm9++3r3yHWXVS7YbwR fcbj3hmVV31si11eEkZRPUMimDDbfoHlYKABFELqgklaz+4/Z17h9vXarHtmN8tlnbM7qzLJSRRU ifu1UvqlgweDglb/ACXF0vLu7kCwaedvqR7jgde/w9dLp2+ku4M/av3LlSlFTUlAGmca/XS7dwMc zKfChQvNKRGJGDTS6EUBPcfs69/h67QvgIJ9wZ2+Q3HlfFR09DQgyaGbVJRbcwysLmJZAXlmbT5G DTSFI1Cx++Xl17/D08bfxU+PhqKvIvHPm8tKKzLVEVzEsgXRT0FKzAOKDGQWiiBtqs0hGuRr+P8A Lrw/n0oPeut9e9+690l83tPGZozT6TRZCaD7eWtp44XFVCOVpspRVEctDlqQNz46iN9P1Qo1mG69 ap0E+bwW7cAHmXHyZykjgNManFxnI1DUFjegq8VWyyVeTxWktahqHqhGCTDVwEhfe8HrWR0lafem PMrU0sqw1KQCj+3yEdVPeiIYSYXJwVMa1mYwTa7Ikkf8RoXYtCamO7e90PWq9K7GbjEFRSVlA7TT QLFTQJLVxyyVmPmlcw7bylaZXgqpBJqOGyesxTsDBIySM4fVOt16GCDcuBnoYcicrQ09LMpYNWVM NG8TI3jlhqI6l43gqIJQUkRgGRwVIB916tXrAN14abjHy1OXY/oOHoazIwP9OfvqaF8eim/DNKqn +vvdOtV67kyOYkQyLQUmGpx9anN1kTyKObH7LHyyQtcc+qqjI/pf6a631Ejanqv87W1+4X/440MY gxfNxp1QmGikQn8T1Ep976108RtPFGvmWixdKnpSJHV3A5spfTDTwk/6lQ/+v711vpyRldQVJKn6 Egi4/qLgXB9+691//9Pfiq6XJ1hMa5H+GwHgmhgilrWB/pU1iTU8Nx/SBmH4YHn37r3XzQ/513W3 yW7e/nPfODdW3vjn8193bVxfx7pPj58cdwdZfBmD5XYrfu+JuqtlY+rwM03aNBFiNo7Hy+7ty7pv vHa38W3NhJVhOKpS0rvT+690T74/fywP5lGW7E39T/7LXX9A7p+BP8sDtrelJRdt/FnL977E7ezz YvcPY8vUOw8D2dtvd2y8/wDIHsGo78rJIoYoa0YLcdFWrR0oNJBH7917p4+FfxR7A+FPcP8ALx+T vzZ/lmfMr5GfFmp6M7oy0nTm1Omdw9pyYr5DZDtDurrnE/3t603XT7d27trM5VcJt3Kpi8maOpfH zY6ugFfNRrG3uvdR+uvgd/NL3zHkPh1tv+XN36nXHyk+R2J+dnePxwxObpfjXtTH9NbOq8qOv+hI O7e2MVSdedSblq8XuXIVNTjq/wDiVfAkG2ZjQNXUL0sfuvdRJtgfK9/5cH8ur4j9vfBT5h5va3QH 8xvv7f3eO19l/GPs7K7urelMPTdFZ7H/AMImfEYzB56s3NUdt9gUeKMtdBSyzUBAqYYmMre690vf l3/K5/mE949c/wAwP+YF8dPgV3p8Uuiu7+9Ordr7X+FWL6+qtu9qZ/44Y2jzm69zb8zvQ+DoY9wU +PwfZeydlZeqSlx8zGuyuQqIJJqGiq6p/de6NZ8qOhs587Ojvkl2R/L0/kfdw/Eqk6o+OXWvV3V3 eG7Id9dGd890bIh3RtTH9m9R7Q+MmxKeHqvvXOZDYuWzqZHOoMruKvwVCkFTVy1UlJj039nWuirb 86E7V+S+yfiLvz4Vfy4PkT8RsF/LQ+H26sj3f3Fu3oqt683V3t8q9uYCjjO0tqV20dvVO5u5Mzub tzApGkdU0udig3BlDWw0FJApPuvfn1XpX/y/P5lPX/x57p6Wofj78g8d01n9nfFX5a7owrdM9itm N47+nw1Hsba/XuLmo9qwPkc3gKv5D5XKZLBsKh6Kk28Zp1jqqQn3rrfX0n/5P249zdffGbr74Z5L or5XdOVHwz6A+LOyNzdi9i9Y4aj6o7d7D3703iN+9jHpmuEOR3PuKk2ZuiumgzAMSJQVVbHBqdwx XfWura/43KBeo3pkKVT6SKjZNTj5wxU8KtfjhpkT8hkax4I9+61+fXmqcTVC1XuLfedDAHwY/F5m jgcEXsJdrYHFsISRb9yYrzZmPv35Drf7enLHLUUaum2NkJjDObzV+aqKLF+clgTLP9k2XzNZIoJN p0jLEAah9R77T177B1iylPSxhG3xudJUmJMOBx5kxVBUgg/s/Y001Rm85wpBjeV4nsf2R9PfvsHX vtPU+GfN5CGOkwONTa+JjVYo6/JUkcdaIV404rbyhUpRp4V6wxlD9adx79jr3UWCoxuEmq8Xtylm 3DuSeRWyc8lR5ZVn0kpPuTNsjxUUcSNdIADIFNoYNP09x48Ovf4espSl2438Yzc75vdGSBpKVKWn BqJT/nRhtuUDOxpaJLBpWZ/Vby1ElgCvuPDh17h9vXJF/hIn3ZuudP4iYzS0VDTGSpgxUFTIgixO KiVRJkMrXyqgllCeSeSyIFjUA++Q698z1Mw+Mq6qs/vHnYgmTkiaLG44lZItv0EhJNOjK7xyZSrW xq51PNhGh8a+rx9B1759Kr3rrfXvfuvde9+691737r3XvfuvdNuRw+Jy6eLK4zH5KPSVC11HT1QU Hn0+aN9HPPFrHn36tOvdBjmOk9nZDVLjVrMDUlSB9lMKiickhrT0FeKiKSLUAdCNGCQPdtR60VHQ cjYe+tgVP3mNig3Bih4zUth6akpsl44I1hjkaklpZ6lZ1TUWanMryFiXP597qD1qhHStwm5UzETH z19W6MRNFLubedF9sF/UlVLiduvDG6MAbO6mxN7j3rrwPS0o5MUGSULs+Cb6LNWZWoylWjDTrCyZ Kloqo2uCeV5Fj/Uaz1vpRpU+YevLmUWt48RQNbjjTq05GYcfkMv9eB711vqTFEFYPTY6R5QOKvJT Hyf64eRqqrX/AFtKD/W/HutdShUCJtNRVJJMfpT00ZLD/DxqZZmH+JsP9b37rfX/1N135aZr5L7a 6V3HnPibsjbPZ3dlNkNvR7b2PvHIUmG21ksdU5yhg3HPXZCo3v12Ulx+BknmhAzFNqlQALKbRlBu cm4RWcj7XAkl5UUVsAiorxZeAr5j8+pT9mdp9p979wNq273s5nvtn9vHinM91aIzzo6xOYAqpaXr EPMEVqW70UnKfEKb8v0t/O5+ZTx7H7i3D1V8FuqnCx7sbqTMUlXuTdNJK+iYUsmzuw+xtz5OYxOy yUdRuXCY+oiZhL5CFUhOS15x3ciG8ljs7bz0HJ+zSzk/ZrUHrO/bOd/7vX2BR9/5A2fePcPnLjb/ ALxiZYIGGQX+qsrGBBWhWVbG7mRgNGkVPTk/8hWm6wo497/GD5j97dbd94+IV8W8szWY9NvZ3OJL NUSxV0OzqTb+48XisqZPHN5qzM6FeRpIqlWMR3/UoWw8bbt2mjvRnUaUJ+emhAP2t9h4dNL/AHkM vN878v8Au97Fcubt7bStoNrErmaGEgKChummgkkjpqXTFa1IUK8JAcYsV/Nl+R/wnqh1T/Mz+Nm+ qzL4t3o8D310vjsBWbd7LpYo3FNXw4/JV+1tkVuQqPGss0lBk6GWJJQk2LpZY2R9LzPuG0H6bmHb 3LjhJGBR/nQkLX7CPmoPV7z7lntX7/wnnP7pXuvt0djMA02z7o8yz2DEjUheNLi7RFqVQTQTKxUt HeTIwZQJqO9vkX/OI+W3VFJ8eIO+egvhr1RKJ+xt6x5/LbEq8/TzV9Lktz02ZyeyM+2Hqt1Z+ixl PiMNi6evycmO8k1c5WF6gRoje3/Ne6WosBPBtMXxtUrXNTUqaajQKoBNMtwr1IsXt17W/cX9lOdJ /c+TlvmX333oUsbQwx3awsEaO3aKO7h8VbeF5Hubq4eGBZ6R26guseraTVVRVVVCqoCqqgBVUCwV QLAAAcD3JHXHsksSSak9azHf+/fk3/Kz+fW5PkLnh3X3b8Ge4UzMmQw8e6NwbtxPX0m6J6fLZDA4 yjz+Ul27tDcW0N20vlwq1BpKauwE7UUNQj/cNTx5fT7jy3vcl8/jTbNLWoqWC1yQKmilW+GtAVwD xp1q9tOW/aT74n3bNq9sdt/q/wAv/eI2IxBJTbw20l6LcNGk0jQxie5gubZtN0U8SSK8QXDxMvhC URdy/wA5ve/yuj/0Qfy8viX2b2J2PuVRj6ndPcOE29R7P2DHUEJ/Hcxj9s7o3HgFgplYtFVZfNYu ip5whdKkHwOpbm6fcSLbYNtle5b8TgBV+ZoSPzZgPt4dBGx+4Jyv7Rxvzh96j3k2bb+T7bvFrt0k z3F6Vz4Mb3FvBNqJwY7a1uJWXVpaIjxFY5/5HPYPdFEvYvzQ+WPa/bPb2VpVqK+g2LkMZBhdm1bR gxY/btRvXG5Klz2MxsjELTUlJtmAJdYVXjV4cnS348fet2lkuzntppX5CoOPsCj5dVk/vCNi9spB yz93P2K2PauQ4DoDXayG6ulXAlm+nljIkZQKtPPeSE9zyMcBNbe+OX83T4PSVuL+Jfa+3PmD05E7 wU/WnaMiUme2qsrqwpa/Z29904GvwHjWRhoxGf8At6mzSmmRmUDy7bzXsrFNtuUu7TyWQ0I/3plp T+i9Dx0jp6+93fuL/eOgS/8AeXky/wCQuexmW92pGkinpxqba0uBIz0FTcba0sY0oty6gnqwb4Q7 /wDnn2LmOwR8vvjv1D09SY2g2/Lsf/QrvigxGey+SqZ8r/eOPOYTF919kQ/5HTw0jIKyHGgtKxDT ciI+2e43+ZpxvVjFCoA0aCDU5rWkj8Men59YtfeE5W+6zy7Z8rv93T3J3rf72WWcXy30UkYhRVi8 Ax69q26pdjKGo0tAq4Ti1h4q6+lIWbJ9jY0AgGCr23itwxpYm6/dYPCZiVvwC7VDrbm97n2e/s6x i/b12c4LETb5r6cPzGDtP7OoADfXTW4uUMpAIv4xf8e/fl1qvz68ajFTkrVbg7AzgIBEVHi81RRM rLqA8+1tvYdPGy/QvLY/S5N7+/Idb/b1Px0clG7NtzYn2MswtLk81U0GMee/9qompnzOdqWH9Jol J+lx9R77T178uu8lEYo0m3nuuGippLquIxMrYSlqWPAgNR55c9k5T9NEMsKyXsYjwB77B177T1lo 6mvlpkoNoYCHCYxPTHk8vRtjqVFJ9ctDt9Pt8nVyMOQaj7RGJ1amtY++09e+wdYlkxG362UI9bur eNVEqyKpgqcsYnbUkb6fBj9uYfXyA328Btf1yfX3H7Ovf4enbH4WrnrI81uKSGpycWv+HUFMzvi8 EkgZHFJ5FjasyEkbaZKuRFcqSsaxoWDe+zr329Kj3rrfXvfuvde9+691737r3Xvfuvde9+691737 r3Xvfuvde9+690jNxbHw+ekFciLjczEdUOVpYovKWH6RVxMPHWICB+r1i3pYc32CR1qnTFTHcWBI hy0tWadTZcjRVxlpXS/p1/xqLKR0rEfUSPSxKSAhP49g9e6VUFXUSIrvUZoK4upTH4+cEH8rNRQV lObH8gke/db6k3ST9UGarD/qZb0qE/0ZHehgP+xFveuvdSEWqjjIhp6HGQgXLSESuP6s0UPhhB/x Mrc/X37r3X//1d/j37r3Xvfuvde9+691gqaamrKealrKeCqpaiNoqimqYo56eeJxZ4poZVaOWNwb FWBBHvRAIIIqOnIpZYJEmglZJlNQykggjgQRkEeo65xRRU8UUEEUcMEMaRQwxIscUUUahI4oo0Cp HHGigKoAAAsPewAAABjqru8rvJI5aRiSSTUknJJJySTkk9ZPfuq9e9+691FoqChxlLFRY2jpcfRQ a/DSUVPDSUsPkkeaTxU8CRxR+SWRmawF2Yk8n3oKqgBQAOnri5uLuZ7i6neWdqVZ2LMaAAVYkk0A AFTwAHUr3vpnpmyeAxeWeOeqpytZApWmyVJNNQ5OlB5Igr6R4apIy3JTUY2t6lI9+r16nSbr9sZS ZVSaXCbqp4gPBT7qxsMdfDpNx4c5jKcrCR+GNE8lwCWJvfdetU6bBR1dBcfwre+HC8+XB5+LcmNU 6vUKehylVV1KL/tK0CrbkC9/fuvdd/xd4QQ28dyUpAF/49sk07AA6SA6bdxEEjM5sGXUrW9N7E+/ fl178+sn8YU6lfsWIHxebRT4bHJVqgIOsRTQ1LWP0IMZNzYc+/fl17/bdYzU4ipA+43JvzOg8iPH Y/L0qMLm6mbamAxQRbrpJeQW4BNzz78uvfmepuPiFJKZdvbCenqZOGy2cqKDGySggqfNViTM7hks v18kHIPH59+/Pr32Dp2OHzuSv/Gs61LTE/8AFt23HJjQy8eipzE0k2Ul/PqpzRnnkG3PuvdPuOxe OxNP9rjaOCigLGR1gjCmWVra5p5OZKieS3qkcs7Hkk+9db6n+/de697917r3v3Xuve/de697917r 3v3Xuve/de697917r3v3Xuve/de697917r3v3XumtsNji7SRQNSSMSzPQTz0DMx/tSCjlhWU8f2w wP59+6913/C1/NdkytrafvpR/resWlv/AI6r+/de67GIx+oPJT/cupur1ss9cyn+qmsknKkfi1rf j37r3X//1t/j37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+ 691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3 Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//2Q== --_011_0DB8F45437AB844CBB5102F807A0AD930F4C9E61xmbrcdx03ciscoc_ Content-Type: image/gif; name="image009.gif" Content-Description: image009.gif Content-Disposition: inline; filename="image009.gif"; size=1408; creation-date="Wed, 08 Aug 2012 01:56:42 GMT"; modification-date="Wed, 08 Aug 2012 01:56:42 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhGQAZAHcAMSH/C01TT0ZGSUNFOS4wFQAAAAlwSFlzAAAOxAAADsQBlSsOGwAh/wtJQ0NS R0JHMTAxMgAh/wtNU09GRklDRTkuMCwAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADqYAAA OpgAABdvkl/FRgAh/wtNU09GRklDRTkuMBgAAAAMbXNPUE1TT0ZGSUNFOS4wzfpCa7cALAAAAAAZ ABkAhwBpngBqnxR/rgF0pgBvogBwowp5qRZ+rQNxpABvowBuogR2pwBzpQBxpAN1pgBtoQVxpAJy pRB8qwV2pwBuoRR+rBV+rABypQJ0pgBypA97qgZ2pwBsoQd3qABxowN1pwN2pwR1pxF+rhmBrxyI tR2Jth6ItRWCsh2ItR2HtR6JtjF1lD12kCd5nSOPvSeKtTOSuiCLuDeDpSaRvjuGpjOPtjeRuCaR vzqGpzmSuTyUuieIszWQuDyGpiKLuTiFpiKMuyCItCGDriGKuCKJtimTwCyWwiyZxy6WwUmBmkaZ vUOYvUCawVKlyFWnyUmhxVCgw2KeuH6yx3C41We00mi00mez0mm103W82Gq102m002231WWz0m23 1Gu102u202641G221G693Gu21G+51XC51m631Wy31GKx0WOy0WOx0W641XG51nO92mGuznS51XzA 2nvA2n3B24GTnI2Zno6ZnoyYnZafo5qxu5mstI6lr4+msI6lsI2kr42kroGxxIKzxoa2x4/C1ozG 3JHI3ZDI3JDI3onA1oLE3YLD3ITC24HB2o7B14/B15TE2YPK5o7N5InJ4YvO6I7L443S7Y7S64vN 5YzP6oLG4YrO6YHG4I/S64TH4Z/P457P45TK4KK1vam2u6SzuKSzuau1uaStsqitsKrM2rHY6LLZ 6a/Y6MfX3dvd38PGx8zNzcDc6cXf6sLd6cTe6sXe6sfj79vu9cLg7dTn8NDk7t/t9N7t9Nrq8svi 7Ozt7uzs7PT6/Ofx9unz9/n8/fb5/Pr9/eDt9Pr8/efx9+fy9+vr6/r6+ujo6P///wECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwj/AJkJHEiwoMGDqwQNIlSoocOHDQ0dOtWL IKhHkBDBicOxo0eOciJJkuJLICs5k6ZQqcKypcuWVq4kooRHYKhKWKxk2cmzp88rWiz9ESjq0pYr PLlw8cm0CiZAAkdl6oI0ixdFir4w7VlFE1RmojaBQVolzK9fXaps3VmFUyCBecSMIVPGjJlOns5U QcMFTRo1VNZMYeOlTRSBelwIeMGkiRtUqa4sovVJVS1bb5w8gTEihgyBe2YMIECggAFgwQ5AYSbs Fi5mrxAkIKCABA3QMxYwYNDAQS5dD2owgwUhwq5hEgrwLnGbWWjdvCfkylXABjNGACjEIlZBeQPm oG9AzW8gnbp1RgEIyBLWfXnz57vJFytWnVmj9LOMtf+OQyCf3PFNcAwyBeTAjCPp8cKMBd6V0B8z fQDIwAUY6KBDBhoosUMDGfCwxAYZLNeDQBFCt9sDDzCQAQcJ7KbAAxfEV8KIzOgh3m445qgjjt/R 6EcRHYS445C7eeDDDwKRAkQQBQhJZI4eGGBEEgIls8IRJnTwAQhcdukllyGIgMQJpQzUCgtCDIHC mmy2SQIKKahARAtzKEPQMqbQoScdddSxJ5+A2nGHKwcVaihBAQEAOw== --_011_0DB8F45437AB844CBB5102F807A0AD930F4C9E61xmbrcdx03ciscoc_ Content-Type: image/png; name="image010.png" Content-Description: image010.png Content-Disposition: inline; filename="image010.png"; size=3853; creation-date="Wed, 08 Aug 2012 01:56:42 GMT"; modification-date="Wed, 08 Aug 2012 01:56:42 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAZCAIAAABLixI0AAAACXBIWXMAAA7EAAAOxAGVKw4bAAAK T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3 AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+ 5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk 5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd 0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA 4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5 h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+ Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY /R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1 mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/ 0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5 hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9 rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7 vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO 32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21 e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i /suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8 IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq YAAAOpgAABdvkl/FRgAABDhJREFUeNqsVTtvHGUUPed+Mzu762eMTUKUOA8lSBilSIIl8hCvAokG mjTQQEEFEiUVBb+BKkJIFCkgUgqQiIgoKAJIUUBWQIGERxIlspM4Nthe7+7sY757KHZjb3iIhk9T jL7RHJ1z7r3nUhL+p5NsvH07v3x5qV7JSiAhEAD/5SeBxmartWWo8vT20fGhSu+akmKMJ89f6uw6 UEXR6EYHCAgiSP4DkABA5RBCSO6trJwYrs88uq/P6+yFufbeQ2yu/7DeiYILXakSzIGOKwsPAPYs EQTh4XKYnpw4c2v97elWuVxO2u32pTyZVPfSWrvnXDWxl3cOPz6WReni7+1ztxsiDOwRIiGBgIj5 ZpFavfzIzrkfrxw9fDDpFkUsirVO0XFPjFF4fd/YgfFSQzDipR3JWMlO3aiVbJNXj5kEo5baxd4R W16rATCSkjouhzqu6aH0wHjpboF7heY7+iPiqanKSGrrhTcLNQtvu7vkgiAHCleUywUgISBAkgsR mswMQM0VARfWXBOBx6cqS60iMbqw2I7X1jsBIOCSgxtNlUjqxFgGyI0aoeXIBQEpAeDEzuHBSn6z lL9/bc0AkiQ6cof6dVzMW6o1Fhp5OUnangGIQFcwYDXip7ZSIgARaAsTgcemKldrnU/nay53j57Y fr+PRbLlfi9vR7QfG00A1CPqQk/IagR7igAXrkvPjnB2ovTelaZRQ8GEvpqk538wpsFMNBJA7qpH GCAgarBPIYBgFCywREsDgxk3/CJpNDOTYGYA2hF5IRIV49TmmMGF3RmHibN36oFmBjOz+72cADDQ jIEE+7xarmaUA9vKeG4kDBq/2okfXF///E5jKA1RCuQGWAKARiODGdDHake0Ihwo/K/jeKtZfLWc w5iQcDej0TZ5ETDSSJHB+rxaUSKWuvgl98FU2j+WnTy87c25xWv1Tk8gBzX2+qT3YaUrABWiVqhs uJ7r16ZvGO/AeOBbO9JXd4+9c3kpIc34oF+kkUakwW40urWuHxkN39Vix5H8LXNudnWzpV3VpBSC QUaQ/aSzfuSRJIOxEXV6ob63zFe2pqMBeVRz4KlH7c64p8yr9a56w0waSRBAIsDNKsF6BammduZ2 MzV7bXp4diRbKVQMuEVgMuVK1z9aaJSDuVQKJBklAEkpTYtmfXs1G0oaXTEBy4GnbzfnasUzk+U9 1ZAZB/pLF1biZ3fz5Y6SwFah6WraKHy8kgFIsiw7mrYutoqDk8O/reW5YORwsIVWPLXQTMwCjexn SXQV7gGqBBpsTzUd37Ll56+/nH3hiX7ed7vddz/8+M6h56e3TkkiLRjNEAxmMMIIAe5wwR3R4S4C zSLevHD+jV3V40ee7GMByPP8k3NffL+4WoDWzx5avyj9FSJJgqD7a5APBb14bHZmZmZzD23YURRF jLEfwP91SGZZNnjz5wCK81KNPiIliQAAAABJRU5ErkJggg== --_011_0DB8F45437AB844CBB5102F807A0AD930F4C9E61xmbrcdx03ciscoc_ Content-Type: image/png; name="image011.png" Content-Description: image011.png Content-Disposition: inline; filename="image011.png"; size=3749; creation-date="Wed, 08 Aug 2012 01:56:42 GMT"; modification-date="Wed, 08 Aug 2012 01:56:42 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAZCAIAAABLixI0AAAACXBIWXMAAA7EAAAOxAGVKw4bAAAK T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3 AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+ 5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk 5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd 0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA 4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5 h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+ Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY /R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1 mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/ 0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5 hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9 rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7 vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO 32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21 e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i /suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8 IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq YAAAOpgAABdvkl/FRgAAA9BJREFUeNqslc1rXFUYxt/nfc+5985kzIclpk0tCQl1CLRpFy5iQYR2 URFEEcS13fgHCN26FtyJblwJggilCxEUFypWRYTa0KQaaPNh0wxkzOSrmU7v3HPO6+Le+Wgx1IVn NffOOb/3ed7n3HOgqvQ/DdP9tbPX/HWhvnfQSpLkvxXQrO2qk0NnqsfyZ+TLrt9YuHa7dGS4EtS3 M/9kDJEASWwOUtjm0ttvvgQAqpqm6Yef/35iYnpjc3drNw2Ha3JenQ9d0UMVO3280nTx9MDaxfNz hohuLi4NjIzX6jt3N5tW8O8YUDsLYyNJdWJkdDiJLKvqj/P1hTvbs9Wx+TsHF8+TIaL9+03Voc3G A9VwmL92O1QnBt957WQSS/flrZXd5Xv37zdTBYreM3P6MGu3nc8C8LgcIoSg1vBbFyb6QUQUfHDO pakjDb0cffDee+c8QFTwQEQAiDTNwuyJwaNHSvnkVuq/+mm9sZeubOyDgg8+BC1YqqGdtoNqUEUe UlcVNHPabLlS0ts9P9+sf/b1chJLpWRE2PvQbrcLlnN+dXV9s9GUKCmVEmutGCPCAEKgqfFKOTGT xwa6rErJvHh2LI7k1u366tqW8S1qNXoenQ+7uwetdM8YyyLGWGONMSZzdOmVuXNnj/a3ae7U6Nyp USJ69/3a3Xtbx0fLCbhggYjBYqzxAhYiOKfOOSXfSr3zh25dMcYYy2IooKsLABMEDLAAIAgAIo5h rv/RaLb8s2OV0yefzhHL63tLazvW8Ob2Q2stwKCOLiUlFoAJBAiYCQwwgWODL75d3T/I3rgw2WV9 91vtg0/nK2WJLcdxTBB0Pea6AAEAZrAULGIASWIDSZxEXWuRNZWBUqXEqiFzDmAl9J8TIHDHIxel CiIAyit35nbqEQAlMKGPBTDA4PwPAfIQGOjUoB4LYLBhZlUPKMDoZxEYzESaU0Dcpw7MAPd9PQAg uRYgPNL7jsd8MIiJJQfla3LYI6giaCoMdnWpkrVGRKgwn+cgfZkqQR7rF5goKJitMSElImIiKieW NIyPVjKnRdUi2aJ3BLGmx4qMEDER+0BxZAafKnuXFrrOzM58cvXK1My5zFFtKw2aa0YeIEGiCH/+ lX50taYhgHRpbT+ORCkMVaKZqeG/tx+8MBP3zvvvf7j28ZWVyeeeZzHOEbEAhpgZBhAIO480Cxq8 Bm9FrSjIR5Y2avVxc+O9y5eiKEL3yllcXPzym18ae5kIq5IP+QGW753iZiBSyudrAMMKna4+8/qr L5fL5Z6u7kjTNF/2xGsNgDFGpNfHfwYAQFicrB4gTtcAAAAASUVORK5CYII= --_011_0DB8F45437AB844CBB5102F807A0AD930F4C9E61xmbrcdx03ciscoc_ Content-Type: image/png; name="image012.png" Content-Description: image012.png Content-Disposition: inline; filename="image012.png"; size=3902; creation-date="Wed, 08 Aug 2012 01:56:42 GMT"; modification-date="Wed, 08 Aug 2012 01:56:42 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAZCAIAAABLixI0AAAACXBIWXMAAA7EAAAOxAGVKw4bAAAK T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3 AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+ 5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk 5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd 0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA 4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5 h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+ Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY /R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1 mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/ 0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5 hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9 rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7 vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO 32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21 e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i /suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8 IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq YAAAOpgAABdvkl/FRgAABGlJREFUeNqslV9sFEUcx38zu/dv7+pde+1dbZGYtrRgY8WKsWmLxIgx 8oQPxsQXX8REjApEQozRJ1+QxDTUqFUeJEajJiZGjIYCpQjYitJSKE1aiqHtdWnT+7+319vdmd/P h20PQqqBxMnnYWdmf9/5/mZ+O8uICP6nppafzIvDhfOnS/Nzd6+tBgLB1s0V23eolVEAYK6v9E/f Z8+dXpaoMOCM3aWWQGIMQsFg7NW9vvoHOACUErOZswMFITWFexlDIf4NFcDLWBlN4QpArlDI9B8j IpWI8mN/lYRUgTIO+Ftaqzc/5tGCd1i4OfRbYeRCzX0VRJQxi/5HtpRSS5WZJQ9jlsDC1bGoEFxK aVm2IDJDkcbd+6x0aubLz6aOfJyenAhvaAlvaDHmbmQmJ4yRC9GKEBIhERHUdm6NNG9yu5yBJLIs i0spbcdGorY9B/SBfu9iIhLUqjyKMdg/d+o4EcU7uhfPnKwKBd1IJCJYOZ7yCCI5jqMSESIhker3 Zy8OuzEAEPB5F/t/ru3oVAPa+udfTP34neWI6PbnAKAKwB+tiTRDFgAA5PQUX0wQkQoA0rbcxRTG EW+VhEeK5KWR2o7uSFPLvO0AQKR502o1aK4cANiZjD0zvVJfdiqZvjRCjm3o8/5YjRqqcAN8qlpK LgGiv7KKAAJez0xfDwAsW87GN/enJ65kjv0gCkbRyHsde52rRURCOCClt25d7uoo50wJaExReEBj uSxJsTD8u72gKz4vAMjlomkUHCNfvKnbc38DAEqUjAEAd7UkESFufPmVdMGUSLZpWvl8LpEgIchx xj/tweRiUU8U9YSVSdv5XHpi3NQTEmkForIWkCTHyEcamx/a805WQrFkF0s2xuvrurcNvfu2sjBP BIjk4vd65z4/bAyecLuEhJJW9guBJNHxl3a2vvZWXde2+7uezE1PAUC4qfnsvt18YV5VFXn7FcCY oioA4A5KIg5wK0ckDDGc6j108oUdv+x8xjby1W2PZq9NSn2WK2zV0NpIQkkIq3sPbr15FMWjKEBU 17kVCLVY3FG8qhTsP792QkJ2my+J6GILgUQTR48QohaLdx7sgXi9LUT5hTXBsi8EQiJb9dQ83hlu bNLitbnr046R94RC4YbGroM9V/p6F8+cUlVlTV+SiGP5LiRAhKe/+FofOjf5zVE7uQQA17/9Slv/ YMf7H2jx2va9B4YNIzvyJ+dsrRwB2WpNIBEiXu7rvXz4kMykFIW7lOZnB9/YNdP/KyC17XrdFs7a OdJKjhwA1OqYAnBj4ATjXBKVQSK0SqM9H5oLuhaL+apjt8+6CKSSRBbQGGMcACId3Z6AfxnJFFJI vKMBY0tjoySlFovfMWVJmXOEByj41LOcc2ZZVjKZHD/Vn/rkIyubdvAefkucgY8xb/sTzfvfa2ho YFLKfD6v6/rstancH+dFaunutRhjvofb69q31NfXx2IxRkSWZWWz2XQ6bZqm4zj3pOX3+8PhcDQa DQaD/wwA2uRn79BoYwAAAAAASUVORK5CYII= --_011_0DB8F45437AB844CBB5102F807A0AD930F4C9E61xmbrcdx03ciscoc_ Content-Type: image/png; name="image013.png" Content-Description: image013.png Content-Disposition: inline; filename="image013.png"; size=4048; creation-date="Wed, 08 Aug 2012 01:56:42 GMT"; modification-date="Wed, 08 Aug 2012 01:56:42 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAZCAYAAADE6YVjAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAK T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3 AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+ 5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk 5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd 0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA 4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5 h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+ Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY /R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1 mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/ 0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5 hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9 rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7 vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO 32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21 e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i /suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8 IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq YAAAOpgAABdvkl/FRgAABPtJREFUeNqklktsVdcVhr+1z7n3XNsXjKu4KK4boZYAsYqSGlAUBhHt JGEAaSgZVGr6SFLFHaCo7YxRKwZ9zPrIQ3kI1UhWCx1UkVAgSUFVW5UUW0auHeoOrDoP+jBGvg/f c8/Ze6/dwbn3FgKDFJb062hvaa3/rMe/9xY6pqrfB77uvd/CHZgxBhH5LfADY8wlAAHw3p93zu3L sowoihCR2yZxzhFFEUmSrAFfiOP4Etbab7Tb7bC2thbyPA/W2mCtDYcPHw6Tk5PhzJkzYf/+/b39 j4NWqxXq9Xqw1s4CxKr6pXaWUalUAAghADA+Ps709AybN29mZGSkt/9xLI5jsjzHOffA6rVrw8Z7 P+S97/alh/vGxrhw4c+8884F9u3bx5EjRzhw4ADHjh1jbm6OgwcPMjU1xdGjR2/w6yKOIqx1JOXy 54xqIGhAP4K9e/fSarVYWlpiYKDK/Pw8hw4d4ty5c1jraDabZFlGq9W6yVc1AIJXj/eK0aCEW6A6 MMDY2BibNm1iePgu6vU6Y2Nj1Ot1nLM0Go0eya38NShBAyEosXpFNeBVb6ptmqYMDQ1hbRH0+m+t ViNN2zSb67f0LeIqYIhza8nynCRJbhrdNE0B6Ovrp1arMTU1Ra1W65GcP38OESHojUMRCDjvsLlF jBB777F5TpbnAIhID1u33gsCO3bsYOfOnRw/fpyJiQn6+vsZHBwkLpUYHR3FOUcIAQ2hN4XOOZyz RFGMfHjln79vtVoPV6vVQrGXZjGnTiLNJgjI0hK0WmAMEsdQKiOVBOnrg2oV2b4DtmwhrK7iowj7 +JcJ1WqHxBHH0Rdj7z1dmH//i+Q7z9FLXgREkCiCOEbimFAuIUmCqVaRoU9gBIz3mF27MaOfovab U6RPfq0XU0SIr5/t5OxZIjFUF97t1ddfvEj61DfBOtBA+elvEe3ZQ/t730XSDJrrhLUaunIV7rmH /pX/sP4RzRjv/7cAiKKI/Omn0MVFdHER+5MfF2Us1IpRRYISj34a06gjq1cx5QRxjjA3h1y5cgOB 91pk4jsAiI2BmRmk0SjWg4NU/jqPf+klZPduwvQ0ZnwXyeQkevo0/o9/oPTDHxVZnziBLiz04nlV RHxBEryiXpFOJr1+dI5uANNZiwhhZgb+vohs2078xBOE2VkQMA/cj7z2WqGRLkSIvXp80OIICAHf GcG4037tlEo790IADAGtN4oSBpDxzxf6mJ3FZ228elR9US6VQvG+w5o5R9NaADZ0BJY6xwYgV08c Ak49JQ1Y9ZS6Sp++SPb66yCGPE3pxvSq4AVTNKhgzZylmWc086zILihph9Ts2o0PSu49MjIC27bh g5J98D5y9wiVZyfQz36GZju9rvFFRrH3incFczupYF0RtH9hAYDa8j+ovHkW36ij9QbZ8jKyME+0 cZBrp06RXX6XuwYGALh68tdkNsd7JbcWEUF9QP5yceaEde6r5XKJaHUV99y3Cc31275+o8ceJ3pm gmazSX9/P5cvXx6W02+ceXR4+JNvtNbXqfT1Ie8tk039krD+/xPFO++n/JUnabdTjBhMFP3poQf3 PCxA/Nbb51/csHHDM+12G1W9o4dECIGkXEY1/O3kyV898vOf/fS9brTkF8+/8Ni927Y/G0VmI+EO 3kQirKysvPm7t9965dVXXl4GwvW/bIAEKHWfSrdpHsgA29347wAa+pFmyNu48AAAAABJRU5ErkJg gg== --_011_0DB8F45437AB844CBB5102F807A0AD930F4C9E61xmbrcdx03ciscoc_ Content-Type: image/png; name="image014.png" Content-Description: image014.png Content-Disposition: inline; filename="image014.png"; size=4184; creation-date="Wed, 08 Aug 2012 01:56:43 GMT"; modification-date="Wed, 08 Aug 2012 01:56:43 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAZCAYAAADE6YVjAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAK T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3 AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+ 5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk 5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd 0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA 4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5 h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+ Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY /R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1 mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/ 0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5 hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9 rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7 vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO 32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21 e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i /suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8 IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq YAAAOpgAABdvkl/FRgAABYNJREFUeNqcln2MnFUVxn/nvu/MO++8M9ttt7PbLl2bFmy70BYsDWKl hS6iqxS6WBMoFAkBEhKJmKxR1Aj4WQwx1rRaIF1TjApS04i6pFi+6bYQ6+IHtRZYFWvZXXe7ndmd mff7Xv/otqgEm/Ekz73/Peee+zz3nCsAy7yZ/GD5ZSs6ijNurxp9UYpxAUPjIRZSL4p66XfHR394 1eCeA5Ex2AAXzWpb3zaj+Sf/MEneYLAaohVMnGCiCETQOYeymAs6S3NuvbFjya19fz/8sLTnvNKe VetfjbNWq6eFgqjGEgQhVluJ/OoL0dU6/v5BKvU6NUtoNlL76MDjy+zVs+Z+qJDLtdaSmKIo0gaK MGFEZmEHpW9+FrttNgB683aKTzwPeQeVyXiXl+ats1ud/NwYgycK3agCxtB823XYrS2c+P6P0OVJ nOVLUJkM8eN7iZtsCplsh9IYAyANEJswwtQDVN4lu2gBydFhKn27sOfNobCui6ZPXoPdVsIkCakx RjV08lRjkgTnvEXkVi5F+wHJ0bew2ltxli+h/uzL+Pt+i9Xawsw7bwKtwXDSXWJZCALaMF3YO0Mb sBQtvbfgda8BoP7MAWpPH8A5v5PZX76D8oOPoJo89PEyydFhlOMABjsZGdNVjlBsmYUqFsDJIkqB TOc7uWCCkKYb1uN1r8HfP4jV3ES+6wPoWp3qr56hsK6L0rc+B8D4XfdzYveTVNOYeGQM20Qx/tER MsfGME4WybuI56LyLuI6SDaL2DYmSXFXrcAEIeN3bwElzNmxGa/7Ut7aeCe1X+8ju3gh9af3U+t/ lgQIdIohwkYEsS0QhYkT0hOTMFE5qXEcIFYWcXOYMCA5NorTeQ46CJkaeApnayet998Fohjfug1F HrCwcjkQEAWkgtICqRhSMSQKUltIbUUimsK1V5O9+HyiWpU4DinvegKUMPsbvVjzF2IvmAdAVC6j pYDOe+h8jkRBMs2pATvFEKOJp02sjUH7NfIXLKXj0e9S3XeQ17quA3H45493U7jmCmZ8bC2dr78E GYvKnucpD/wGcs7pdidAgiHCoDEojSEWiJQhTGPCOMR67wKmhv7G1MBBCpesxLvqcoKoju/XOLLx U4zueJRweITRHY/w2qZPE6UJsYJYzDuQAnY6ncD3fXJennO2fJ3Sxh7Gf9bPm/dtY+kvd3LWl+5g eHc/pZ5u2q7v4c839yLZDOlUFbEtJJuBf+sXb1eiScWgEiBIItT8uZz78z7abr6WpF6nddPHmTh0 mGMPP0ZhxTI6dz3IuY89wKyejyDz51KbrBDlMkQZi1A0oZjTCKb3SAwpBpWYlFAM5+3cwsy1q3i1 9x4O9d4LwJLvbWbshQPEE2XaPnElwfAoA10bmHhjiNhzCJUhEP0uOJkoEYO1OONevCDW3e7MZto/ vBZxssy7YQPVN/5KyyXvJ9s+h5GnngMRXly/ieN/OASee9qR74ZEDD6aI2kwYCdiiPMOf3poJwuv 30Dpsg9yeHsfg1/4Gj1/HKC4+Gyeu/E24vIUYaWCPSNPYs7crw0QokkElMao0BImgyovf/U+AFre t5w1P+3D6ziLV769ldGhIabqU8RuFp+UQM4MX1J80aQYsSfR1UQ0oZfj9T1PsugX/Zx99ZUAvPjF exj8zjasoosW9R8O+l+hgJrRGIFQ9KTlGx2udPO3VEhtrTWVob8w/9LV7O39PAcfeAhV8NCWkGLO qMMpVEUzoVMcS0x/ffJeAVidL3zlCq9wd0WniDZ4xSK18XFs1234u5JgMECzsnihXtu2tzb1mVMD 0VmWy91+oevelFPyniRJlVhWA+Py7UeokDTQ+s3fB8GuV3x/OzD53zTtrlKl6Wv9f0P7Wo8BI6dE /NcAQhbE7cZc9jcAAAAASUVORK5CYII= --_011_0DB8F45437AB844CBB5102F807A0AD930F4C9E61xmbrcdx03ciscoc_ Content-Type: image/png; name="image015.png" Content-Description: image015.png Content-Disposition: inline; filename="image015.png"; size=4129; creation-date="Wed, 08 Aug 2012 01:56:43 GMT"; modification-date="Wed, 08 Aug 2012 01:56:43 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAZCAYAAADE6YVjAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAK T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3 AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+ 5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk 5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd 0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA 4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5 h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+ Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY /R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1 mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/ 0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5 hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9 rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7 vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO 32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21 e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i /suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8 IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq YAAAOpgAABdvkl/FRgAABUxJREFUeNqklk9sVNcVxn/3zbw3HjODwVGBpKocBBlinOIumiiQJsiu J1GahD9JqrTAoqWC0kVLAi1Gatw4sruAgLuoIhZNm0VVlHhs6tDQAPkDVQAvqFRCqkCwOnIlaGrj EjP2m/fmzb33dDGD04g/dttP+hZv8c53v3O+8+6DKnpzuSdF5INSqWSDIJD/h1rrT8fGxl5pbW2t v1afDRs2rImiSCYmJsT3fQnDUIKZMggkiiIRESmXy1IMApmYmJByuSyDg4PH0+l0TSyVStXs37+/ t66u7gtKKVzXRSkHZ0ZUeJ6HiLBr1y4WLlzIbfW34TiKIAhYtGjRncPDwxfiDQ0Ni+bPX7Akisp4 novWBqW4NQRQEI+7jI+Ps3HjRgYGBrh8+TI9PT1Ya/E8D2stDzzwtTbHcZxarcsOCoyxWGsxZhpa i+t6oKBYDDhy5AgA+/bt4+zZs7iuh7WC1oZkMlnriIgYY8VWBWbCRCLB0bePkm1ro1Qqkc1mmT17 NqVSiY6OjopZEay1aKPFufbw3wicPHmCNatXc+zYMdavX8fddzdSW1tLNvswBw8e5NAfD1GTrMFa i1jBATDG3LSosRZjDU4sxqxUCteNc1cmw7x583Ach3PnzvHqq7/hypUrtLa2kE6n2dnezuTkJAKV d0WEIAwJw5CoXEYbUy38+dP/49Il2tt3sGnTJkZHRtm1ezfWWh5auZI5c+YSRRHDw39n+/btPP74 E2ht8H2fqBRJXETQWlPWGqn2UimFAlCKRCLB0NAQT65dSz6fryxuby/9Bw7Q0trKn44fp6fnF3R0 PM8777zN+ydO4HkJgiAAwFpLXKrtMsaglEJEPpfWRCJBz94e8vk8L+3Zgz/p09n5Atuee46fvdDJ N59+itdef41fvfJrtNaIUGlV9bBWLHFEpqKplEXE4jgOyWQSx4mhlOL8+fN4nseqVau5444vcubM GQYGfg/At9et468ffsjSpiZqk0l8368sEVREjOAIYK3B2Iobqm76cn307N3DRx+dI5PJEEURBw70 k5qV5OttbQAMDw/T2fkiv/3dfhRQKExMBeUarZiqE2sxxhBzYlhj2blzB/19fQDkcjm6un9OLtdL d1cXWhsOvfkmAIsX30Vt7SwcJ0YYlq4ZmIJSCmuFOIA1Fmss7iyPI4ffor+vj1WrVvPggw+x4Pbb aWlpYceOdrq7u+h4/qcAbN36LMual1EoFG769amIWOIinw0eYGhoCIBHHn2UZ575FqMjI2zZspl7 7vkyA2/8gcHBUzQ2NrJ8+QqKfvG6oNxQBGRKJIoiGhruBKA/l+Oxx57gnyMjvDEwQOFqgc2bt7C0 qQmtNX6xCLcQuIGTSrqKfpHlK1awdGkT7733Lj/58TbS6TQAmSVLKAYB/uQkM8VnIshUuqJyRE1N kj17e/jBlu+T630dgK/eey/r12/A9yen2jq9AigUIqLiqrrkuqxxHIdC4SoXhi7wy5dfZvDUKVzX oy2bJZlMEpWi6xJ0qztHKYXWRpyxsbFP/KL/aVlrXNfl6OHDPPujH/Ln06f5zne/x5q1a4nH4oRh WI369LRWCMIAJxYjn8//LRaG4UTdnDlfuv/+5feNj18lUZPg0sWLrGxpJZVKERQDjDGIFcTaaWmt pVQKicfjFAqFwt6Xdm+LAZz94Mzp+vr6xZlMpnHu3LlkH36E+fMXUI4ipr+LrxsFXsJjbOxfn3R3 vbj144/Pv/ufFeqam7/yjWXNzfe5rps0xgr/AxzHkdHRkYsnT7z/1vj4+F/gxmOMMfPx3syMrv5u APDvAQA0od/2coVKtQAAAABJRU5ErkJggg== --_011_0DB8F45437AB844CBB5102F807A0AD930F4C9E61xmbrcdx03ciscoc_-- From adrian@olddog.co.uk Wed Aug 8 01: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 30ABA11E80AD for ; Wed, 8 Aug 2012 01:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[AWL=-0.704, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9ghD60KCIY5 for ; Wed, 8 Aug 2012 01:13:46 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id DCFDD21F861E for ; Wed, 8 Aug 2012 01:13:42 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q788DXXo007265; Wed, 8 Aug 2012 09:13:33 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q788DTe0007212 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Aug 2012 09:13:30 +0100 From: "Adrian Farrel" To: "'Luyuan Fang \(lufang\)'" , "'Shahram Davari'" , References: <4A6CE49E6084B141B15C0713B8993F2806E252@SJEXCHMB12.corp.ad.broadcom.com> <0DB8F45437AB844CBB5102F807A0AD930F4C9E61@xmb-rcd-x03.cisco.com> In-Reply-To: <0DB8F45437AB844CBB5102F807A0AD930F4C9E61@xmb-rcd-x03.cisco.com> Date: Wed, 8 Aug 2012 09:13:29 +0100 Message-ID: <023301cd753d$b1f3eb60$15dbc220$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0234_01CD7546.13BF3130" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIXHBJEF8FkHEwJftuC9PLCnW2MvQH5310olqx0JKA= Content-Language: en-gb Subject: Re: [mpls] draft-ietf-mpls-tp-use-cases-and-design-02 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, 08 Aug 2012 08:13:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0234_01CD7546.13BF3130 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0235_01CD7546.13BF3130" ------=_NextPart_001_0235_01CD7546.13BF3130 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I will include this point in my AD review and you can fix it in the respin that will be needed. A From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Luyuan Fang (lufang) Sent: 08 August 2012 02:57 To: Shahram Davari; mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-tp-use-cases-and-design-02 Shahram, It is a valid point, thanks. We can replace "PHP as optional" with "PHP must be disabled by default". I assume we can make the change through RFC editing process, Loa can help to confirm if OK. Thanks, Luyuan From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari Sent: Tuesday, August 07, 2012 4:45 PM To: mpls@ietf.org Subject: [mpls] draft-ietf-mpls-tp-use-cases-and-design-02 Hi, I am not sure it is late or not, but I found a discrepancy between This draft and RFC5960. This draft says PHP is optional for MPLS-TP, while RFC5960 says PHP MUST not be used. Is there any way to correct this before IESG publication? Thank you, Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: cid:image009.jpg@01CD505E.7B800DB0 Shahram Davari | Technical Director, Network Switching Group Broadcom Corporation | (O) 408-922-7436 | (M) 408-660-5695 Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: image005 Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: image002 Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: image003 Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: image004 Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: image006 Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: image008 Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: image007 ------=_NextPart_001_0235_01CD7546.13BF3130 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I will include this = point in my AD review and you can fix it in the respin that will be = needed.

 

A

 

From: = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Luyuan Fang (lufang)
Sent: 08 August 2012 = 02:57
To: Shahram Davari; mpls@ietf.org
Subject: Re: = [mpls] = draft-ietf-mpls-tp-use-cases-and-design-02

 

Shahram,

 

It is a valid point, = thanks.

We can replace “PHP as = optional” with “PHP must be disabled by = default”.

 

I assume we can make the change = through RFC editing process, Loa can help to confirm if = OK.

 

Thanks,

Luyuan

 <= /p>

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On = Behalf Of Shahram Davari
Sent: Tuesday, August 07, 2012 = 4:45 PM
To: mpls@ietf.org
Subject: [mpls] = draft-ietf-mpls-tp-use-cases-and-design-02

 

Hi,

 

I = am not sure it is late or not, but I found a discrepancy between This = draft and  RFC5960. This draft says PHP is optional for MPLS-TP, = while RFC5960 says PHP MUST not be used.

 

Is there any way to correct this = before IESG publication?

 

Thank = you,

 <= /p>

 

3D"Description:

 

Shahram Davari | Technical = Director, Network Switching Group
Broadcom Corporation | (O) 408-922-7436 | = (M) 408-660-5695

 

3D"Description:3D"Description:3D"Description:3D"Description:3D"Description:3D"Description:3D"Description:          =

 <= /p>

 <= /p>

 

 

------=_NextPart_001_0235_01CD7546.13BF3130-- ------=_NextPart_000_0234_01CD7546.13BF3130 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4RSrRXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUAAAABAAAAYgEbAAUAAAABAAAA agEoAAMAAAABAAIAAAExAAIAAAAeAAAAcgEyAAIAAAAUAAAAkIdpAAQAAAABAAAApAAAANAADqYA AAAnEAAOpgAAACcQQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2gAMjAxMjowNjoxNSAxNjox Njo0OAAAA6ABAAMAAAABAAEAAKACAAQAAAABAAABCKADAAQAAAABAAAAOgAAAAAAAAAGAQMAAwAA AAEABgAAARoABQAAAAEAAAEeARsABQAAAAEAAAEmASgAAwAAAAEAAgAAAgEABAAAAAEAAAEuAgIA BAAAAAEAABN1AAAAAAAAAEgAAAABAAAASAAAAAH/2P/iDFhJQ0NfUFJPRklMRQABAQAADEhMaW5v AhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAAAAAAAAAA AAAAAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQAAAIEAAAA FHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRtZGQAAALE AAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAAJHRlY2gA AAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAAQ29weXJp Z2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJzUkdCIElF QzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAA AAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeFAAAY2lhZ WiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAA AAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29s b3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29s b3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxSZWZlcmVu Y2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVmZXJlbmNl IFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlWAFAAAABX H+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBjdXJ2AAAA AAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABtAHIAdwB8 AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsBAQEHAQ0B EwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHBAckB0QHZ AeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsECywLVAuAC 6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQTBCAELQQ7 BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYFtQXFBdUF 5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZB6wHvwfS B+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J5Qn7ChEK Jwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1DI4MpwzA DNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14Peg+WD7MP zw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLDEuMTAxMj E0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwWjxayFtYW +hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqeGsUa7BsU GzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMfPh9pH5Qf vx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQfJE0kfCSr JNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWspnSnQKgIq NSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9aL5Evxy/+ MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1wjX9Njc2 cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8JzxlPKQ84z0i PWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31DwEQDREdE ikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtTS5pL4kwq THJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19TqlP2VEJU j1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1XIZc1l0n XXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1lkmXnZj1m kmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8eb3hv0XAr cIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5iXnnekZ6 pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQdhICE44VH hauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaPnpAGkG6Q 1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtCm6+cHJyJ nPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSp N6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYB tnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD 1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+ 0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4Dbg veFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M 8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+S/7c/23/ ///tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8V GBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4O DhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgA IwCgAwEiAAIRAQMRAf/dAAQACv/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUB AQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJx gTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePz RieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYF NQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNU oxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//a AAwDAQACEQMRAD8A9Re1vJA+JMIZcAfa8DzDz+Rwc1GeYEyGjxd/qEPc48Oe74AAf9Mf9+SUptzg AXDc09xH97mf9JAxesdMy82/BxshtmVi/wA/UJluu06kbX7HeyzZ/N/4RG2O3A7XT3JDf++FrlxH 1aeWdZxM5oh3VW55J8dt3q6/9tpspUYjv/6L/wB02eX5eOTHmmSQccbhX7/DPL6v+p4cj3ySCzIB 0f7T49kXlOay6SSSSlKL3hvOpPDRyVE2SdtY3u8ew/rOQ5kF4dp+fb/3ypJS7nPMyYj6UGGt/rP+ k5yh+kkbXODjwOSR47H/AEG/11KD7QG6811+H/CWJaQZ9zSYce73fuN/kJKY+vkMiQ2xp4Ils/8A Vf5/82pNy5Gtbh5iCPyhOGFziHGT/hT2/k1D+SnfSRqzj93/AMikpk29juxb8Qp8qqDEjuO3+u3/ AF/0X84ptsLT8e3+v53+r0lNhJMCHAEag8J0lKSTFwBidfBJJT//0O4+ufVsro31bzupYbR9qpa1 tDiA4h9j2UBwYZ3bPU9RcC768fXk1OcxxczGl/2j7I0V3V2X1YeFY7e5jn03Odb+kwW+r/wP6Oy5 eldT6f1PLsZ9k6k/Bp2lttbKmPc6T9Jltvupdt/cVP8A5o4VbfVxcnKp6gIP283Pssc4cfaK7HfZ 7mf6Sr0kCT0H4s0MeIxBnm4Sf0YwlPh/2p/V/wDjXvPFV/Xr6w+tY/0hkZF4uxn9LZh2RhZTXGrC rfktbbbm2X1MtzMmn/RU2ekxVMf6ydatf0ijplNDM/GxiacL7I8l+W/KuxMyqfY3Apdi1fbMm176 fT/8893f0z619Q2Yefl41OCHg3XYnqsyLWN/wbtx9On1v8J6b1r9VwD1Hp92G25+M60ey6okOa4H cx3tLdzdw97N3vQu79O21pMBAxj7wqZ9ft8Uowh8nFL5eP0Tyej/AL986b9devuoys71W1Fj/SzM CzCtLelt9b7OzIvzGN/XbWUfp7aLP+t0/o7GKtZ9evrnhbB6TsrHbXea8sY3pHJZYMgdKz7aCG/Z m78Sy/0v0fq4q7lmB9bspjcXPzcfGxwALMjCD/tNgHt+ncPSxnP/ANJUz/i0rPqnj0H1+l5OTg5U 7nXMtdZvd/3ZpyXPqyP/AANLiPSP26JOHFHSWePEdvbjLJj/AOqT9HD/AIEMqT6r9Uv6h0PFuy7z bmtrYMwlgqi5zGZLq9lldbfZVkVfzX6NaZcD9Jwd/WdP/QrG1yrYFOdRSa83MOdcXEi01tpIbA/R +lU6v8737lak8Q773j/vqcPsYJAAkCQkB+lHi4Zf4/BJcgkajc0dj7GD+z9JKSfdO4j886Mb/VH5 3+v6RNGsxr2Ja5x/znpO0ILuexsI/wCjWxJCtIJkhjvpPP0nn91qeHbhAAfHtb2Y3x/rJ2te4yJn /SP7f1GIjGBogd9STyT5pKU1oY0NHZSSSSUxfWx/0hPgeD96AcV4+hZ8ngH8m1WUklNQOyaT72yw 8ubLo/lfvIjX7xO6QeDOn/R2f9UjobqW7tzPa48xwfiElLNj4eQgf9TKmDHw+5R9w5/Cf70+vYH7 o/6pJT//0fVUl8qpJKfqpJfKqSSn6qSXyqkkp+p7PoH6P9rhCZtnXb/1uf8Avq+XUklP1G/Z2/6e 6E9HJ/m/7H/fl8tpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp//Z/+0dyFBo b3Rvc2hvcCAzLjAAOEJJTQQEAAAAAAAvHAFaAAMbJUccAVoAAxslRxwBWgADGyVHHAFaAAMbJUcc AVoAAxslRxwCAAACAAAAOEJJTQQlAAAAAAAQbrNy3vn/dsPQ3CJIvyt90zhCSU0EOgAAAAAAjQAA ABAAAAABAAAAAAALcHJpbnRPdXRwdXQAAAAEAAAAAFBzdFNib29sAQAAAABJbnRlZW51bQAAAABJ bnRlAAAAAENscm0AAAAPcHJpbnRTaXh0ZWVuQml0Ym9vbAAAAAALcHJpbnRlck5hbWVURVhUAAAA DABwAHIAdAAtAGkAcgB2AC0AMAA3ADIAAAA4QklNBDsAAAAAAbIAAAAQAAAAAQAAAAAAEnByaW50 T3V0cHV0T3B0aW9ucwAAABIAAAAAQ3B0bmJvb2wAAAAAAENsYnJib29sAAAAAABSZ3NNYm9vbAAA AAAAQ3JuQ2Jvb2wAAAAAAENudENib29sAAAAAABMYmxzYm9vbAAAAAAATmd0dmJvb2wAAAAAAEVt bERib29sAAAAAABJbnRyYm9vbAAAAAAAQmNrZ09iamMAAAABAAAAAAAAUkdCQwAAAAMAAAAAUmQg IGRvdWJAb+AAAAAAAAAAAABHcm4gZG91YkBv4AAAAAAAAAAAAEJsICBkb3ViQG/gAAAAAAAAAAAA QnJkVFVudEYjUmx0AAAAAAAAAAAAAAAAQmxkIFVudEYjUmx0AAAAAAAAAAAAAAAAUnNsdFVudEYj UHhsQFgAAAAAAAAAAAAKdmVjdG9yRGF0YWJvb2wBAAAAAFBnUHNlbnVtAAAAAFBnUHMAAAAAUGdQ QwAAAABMZWZ0VW50RiNSbHQAAAAAAAAAAAAAAABUb3AgVW50RiNSbHQAAAAAAAAAAAAAAABTY2wg VW50RiNQcmNAWQAAAAAAADhCSU0D7QAAAAAAEABgAAAAAQABAGAAAAABAAE4QklNBCYAAAAAAA4A AAAAAAAAAAAAP4AAADhCSU0D8gAAAAAACgAA////////AAA4QklNBA0AAAAAAAQAAABaOEJJTQQZ AAAAAAAEAAAAHjhCSU0D8wAAAAAACQAAAAAAAAAAAQA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAA CgABAAAAAAAAAAE4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAA AAEAMgAAAAEAWgAAAAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAAAHAAAP////// //////////////////////8D6AAAAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAOEJJTQQAAAAA AAACABA4QklNBAIAAAAAACIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOEJJTQQw AAAAAAARAQEBAQEBAQEBAQEBAQEBAQEAOEJJTQQtAAAAAAAGAAEAAAAiOEJJTQQIAAAAAAAQAAAA AQAAAkAAAAJAAAAAADhCSU0EHgAAAAAABAAAAAA4QklNBBoAAAAAA2EAAAAGAAAAAAAAAAAAAAA6 AAABCAAAABYAMwA5ADEAMwAwAF8AZAAwADQALQAyAC4ANwA1AGkAbgBfADkANgBkAHAAaQAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAABCAAAADoAAAAAAAAAAAAAAAAAAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAQAAAAAQAAAAAAAG51bGwAAAACAAAABmJvdW5kc09iamMAAAABAAAAAAAA UmN0MQAAAAQAAAAAVG9wIGxvbmcAAAAAAAAAAExlZnRsb25nAAAAAAAAAABCdG9tbG9uZwAAADoA AAAAUmdodGxvbmcAAAEIAAAABnNsaWNlc1ZsTHMAAAABT2JqYwAAAAEAAAAAAAVzbGljZQAAABIA AAAHc2xpY2VJRGxvbmcAAAAAAAAAB2dyb3VwSURsb25nAAAAAAAAAAZvcmlnaW5lbnVtAAAADEVT bGljZU9yaWdpbgAAAA1hdXRvR2VuZXJhdGVkAAAAAFR5cGVlbnVtAAAACkVTbGljZVR5cGUAAAAA SW1nIAAAAAZib3VuZHNPYmpjAAAAAQAAAAAAAFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABM ZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAA6AAAAAFJnaHRsb25nAAABCAAAAAN1cmxURVhUAAAA AQAAAAAAAG51bGxURVhUAAAAAQAAAAAAAE1zZ2VURVhUAAAAAQAAAAAABmFsdFRhZ1RFWFQAAAAB AAAAAAAOY2VsbFRleHRJc0hUTUxib29sAQAAAAhjZWxsVGV4dFRFWFQAAAABAAAAAAAJaG9yekFs aWduZW51bQAAAA9FU2xpY2VIb3J6QWxpZ24AAAAHZGVmYXVsdAAAAAl2ZXJ0QWxpZ25lbnVtAAAA D0VTbGljZVZlcnRBbGlnbgAAAAdkZWZhdWx0AAAAC2JnQ29sb3JUeXBlZW51bQAAABFFU2xpY2VC R0NvbG9yVHlwZQAAAABOb25lAAAACXRvcE91dHNldGxvbmcAAAAAAAAACmxlZnRPdXRzZXRsb25n AAAAAAAAAAxib3R0b21PdXRzZXRsb25nAAAAAAAAAAtyaWdodE91dHNldGxvbmcAAAAAADhCSU0E KAAAAAAADAAAAAI/8AAAAAAAADhCSU0EFAAAAAAABAAAACY4QklNBAwAAAAAE5EAAAABAAAAoAAA ACMAAAHgAABBoAAAE3UAGAAB/9j/4gxYSUNDX1BST0ZJTEUAAQEAAAxITGlubwIQAABtbnRyUkdC IFhZWiAHzgACAAkABgAxAABhY3NwTVNGVAAAAABJRUMgc1JHQgAAAAAAAAAAAAAAAAAA9tYAAQAA AADTLUhQICAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABFj cHJ0AAABUAAAADNkZXNjAAABhAAAAGx3dHB0AAAB8AAAABRia3B0AAACBAAAABRyWFlaAAACGAAA ABRnWFlaAAACLAAAABRiWFlaAAACQAAAABRkbW5kAAACVAAAAHBkbWRkAAACxAAAAIh2dWVkAAAD TAAAAIZ2aWV3AAAD1AAAACRsdW1pAAAD+AAAABRtZWFzAAAEDAAAACR0ZWNoAAAEMAAAAAxyVFJD AAAEPAAACAxnVFJDAAAEPAAACAxiVFJDAAAEPAAACAx0ZXh0AAAAAENvcHlyaWdodCAoYykgMTk5 OCBIZXdsZXR0LVBhY2thcmQgQ29tcGFueQAAZGVzYwAAAAAAAAASc1JHQiBJRUM2MTk2Ni0yLjEA AAAAAAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAPNRAAEAAAABFsxYWVogAAAAAAAAAAAAAAAA AAAAAFhZWiAAAAAAAABvogAAOPUAAAOQWFlaIAAAAAAAAGKZAAC3hQAAGNpYWVogAAAAAAAAJKAA AA+EAAC2z2Rlc2MAAAAAAAAAFklFQyBodHRwOi8vd3d3LmllYy5jaAAAAAAAAAAAAAAAFklFQyBo dHRwOi8vd3d3LmllYy5jaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABkZXNjAAAAAAAAAC5JRUMgNjE5NjYtMi4xIERlZmF1bHQgUkdCIGNvbG91ciBzcGFjZSAt IHNSR0IAAAAAAAAAAAAAAC5JRUMgNjE5NjYtMi4xIERlZmF1bHQgUkdCIGNvbG91ciBzcGFjZSAt IHNSR0IAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZGVzYwAAAAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcg Q29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAALFJlZmVyZW5jZSBWaWV3aW5nIENv bmRpdGlvbiBpbiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHZpZXcAAAAA ABOk/gAUXy4AEM8UAAPtzAAEEwsAA1yeAAAAAVhZWiAAAAAAAEwJVgBQAAAAVx/nbWVhcwAAAAAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAo8AAAACc2lnIAAAAABDUlQgY3VydgAAAAAAAAQAAAAABQAK AA8AFAAZAB4AIwAoAC0AMgA3ADsAQABFAEoATwBUAFkAXgBjAGgAbQByAHcAfACBAIYAiwCQAJUA mgCfAKQAqQCuALIAtwC8AMEAxgDLANAA1QDbAOAA5QDrAPAA9gD7AQEBBwENARMBGQEfASUBKwEy ATgBPgFFAUwBUgFZAWABZwFuAXUBfAGDAYsBkgGaAaEBqQGxAbkBwQHJAdEB2QHhAekB8gH6AgMC DAIUAh0CJgIvAjgCQQJLAlQCXQJnAnECegKEAo4CmAKiAqwCtgLBAssC1QLgAusC9QMAAwsDFgMh Ay0DOANDA08DWgNmA3IDfgOKA5YDogOuA7oDxwPTA+AD7AP5BAYEEwQgBC0EOwRIBFUEYwRxBH4E jASaBKgEtgTEBNME4QTwBP4FDQUcBSsFOgVJBVgFZwV3BYYFlgWmBbUFxQXVBeUF9gYGBhYGJwY3 BkgGWQZqBnsGjAadBq8GwAbRBuMG9QcHBxkHKwc9B08HYQd0B4YHmQesB78H0gflB/gICwgfCDII RghaCG4IggiWCKoIvgjSCOcI+wkQCSUJOglPCWQJeQmPCaQJugnPCeUJ+woRCicKPQpUCmoKgQqY Cq4KxQrcCvMLCwsiCzkLUQtpC4ALmAuwC8gL4Qv5DBIMKgxDDFwMdQyODKcMwAzZDPMNDQ0mDUAN Wg10DY4NqQ3DDd4N+A4TDi4OSQ5kDn8Omw62DtIO7g8JDyUPQQ9eD3oPlg+zD88P7BAJECYQQxBh EH4QmxC5ENcQ9RETETERTxFtEYwRqhHJEegSBxImEkUSZBKEEqMSwxLjEwMTIxNDE2MTgxOkE8UT 5RQGFCcUSRRqFIsUrRTOFPAVEhU0FVYVeBWbFb0V4BYDFiYWSRZsFo8WshbWFvoXHRdBF2UXiReu F9IX9xgbGEAYZRiKGK8Y1Rj6GSAZRRlrGZEZtxndGgQaKhpRGncanhrFGuwbFBs7G2MbihuyG9oc AhwqHFIcexyjHMwc9R0eHUcdcB2ZHcMd7B4WHkAeah6UHr4e6R8THz4faR+UH78f6iAVIEEgbCCY IMQg8CEcIUghdSGhIc4h+yInIlUigiKvIt0jCiM4I2YjlCPCI/AkHyRNJHwkqyTaJQklOCVoJZcl xyX3JicmVyaHJrcm6CcYJ0kneierJ9woDSg/KHEooijUKQYpOClrKZ0p0CoCKjUqaCqbKs8rAis2 K2krnSvRLAUsOSxuLKIs1y0MLUEtdi2rLeEuFi5MLoIuty7uLyQvWi+RL8cv/jA1MGwwpDDbMRIx SjGCMbox8jIqMmMymzLUMw0zRjN/M7gz8TQrNGU0njTYNRM1TTWHNcI1/TY3NnI2rjbpNyQ3YDec N9c4FDhQOIw4yDkFOUI5fzm8Ofk6Njp0OrI67zstO2s7qjvoPCc8ZTykPOM9Ij1hPaE94D4gPmA+ oD7gPyE/YT+iP+JAI0BkQKZA50EpQWpBrEHuQjBCckK1QvdDOkN9Q8BEA0RHRIpEzkUSRVVFmkXe RiJGZ0arRvBHNUd7R8BIBUhLSJFI10kdSWNJqUnwSjdKfUrESwxLU0uaS+JMKkxyTLpNAk1KTZNN 3E4lTm5Ot08AT0lPk0/dUCdQcVC7UQZRUFGbUeZSMVJ8UsdTE1NfU6pT9lRCVI9U21UoVXVVwlYP VlxWqVb3V0RXklfgWC9YfVjLWRpZaVm4WgdaVlqmWvVbRVuVW+VcNVyGXNZdJ114XcleGl5sXr1f D19hX7NgBWBXYKpg/GFPYaJh9WJJYpxi8GNDY5dj62RAZJRk6WU9ZZJl52Y9ZpJm6Gc9Z5Nn6Wg/ aJZo7GlDaZpp8WpIap9q92tPa6dr/2xXbK9tCG1gbbluEm5rbsRvHm94b9FwK3CGcOBxOnGVcfBy S3KmcwFzXXO4dBR0cHTMdSh1hXXhdj52m3b4d1Z3s3gReG54zHkqeYl553pGeqV7BHtje8J8IXyB fOF9QX2hfgF+Yn7CfyN/hH/lgEeAqIEKgWuBzYIwgpKC9INXg7qEHYSAhOOFR4Wrhg6GcobXhzuH n4gEiGmIzokziZmJ/opkisqLMIuWi/yMY4zKjTGNmI3/jmaOzo82j56QBpBukNaRP5GokhGSepLj k02TtpQglIqU9JVflcmWNJaflwqXdZfgmEyYuJkkmZCZ/JpomtWbQpuvnByciZz3nWSd0p5Anq6f HZ+Ln/qgaaDYoUehtqImopajBqN2o+akVqTHpTilqaYapoum/adup+CoUqjEqTepqaocqo+rAqt1 q+msXKzQrUStuK4trqGvFq+LsACwdbDqsWCx1rJLssKzOLOutCW0nLUTtYq2AbZ5tvC3aLfguFm4 0blKucK6O7q1uy67p7whvJu9Fb2Pvgq+hL7/v3q/9cBwwOzBZ8Hjwl/C28NYw9TEUcTOxUvFyMZG xsPHQce/yD3IvMk6ybnKOMq3yzbLtsw1zLXNNc21zjbOts83z7jQOdC60TzRvtI/0sHTRNPG1EnU y9VO1dHWVdbY11zX4Nhk2OjZbNnx2nba+9uA3AXcit0Q3ZbeHN6i3ynfr+A24L3hROHM4lPi2+Nj 4+vkc+T85YTmDeaW5x/nqegy6LzpRunQ6lvq5etw6/vshu0R7ZzuKO6070DvzPBY8OXxcvH/8ozz GfOn9DT0wvVQ9d72bfb794r4Gfio+Tj5x/pX+uf7d/wH/Jj9Kf26/kv+3P9t////7QAMQWRvYmVf Q00AAf/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACMAoAMBIgACEQED EQH/3QAEAAr/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APUXtbyQPiTCGXAH2vA8w8/kcHNRnmBMho8Xf6hD3OPDnu+AAH/TH/fklKbc4AFw3NPcR/e5n/SQ MXrHTMvNvwcbIbZlYv8AP1CZbrtOpG1+x3ss2fzf+ERtjtwO109yQ3/vha5cR9WnlnWcTOaId1Vu eSfHbd6uv/babKVGI7/+i/8AdNnl+Xjkx5pkkHHG4V+/wzy+r/qeHI98kgsyAdH+0+PZF5Tmsukk kkpSi94bzqTw0clRNknbWN7vHsP6zkOZBeHafn2/98qSUu5zzMmI+lBhrf6z/pOcofpJG1zg48Dk keOx/wBBv9dSg+0BuvNdfh/wliWkGfc0mHHu937jf5CSmPr5DIkNsaeCJbP/AFX+f/NqTcuRrW4e Ygj8oThhc4hxk/4U9v5NQ/kp30kas4/d/wDIpKZNvY7sW/EKfKqgxI7jt/rt/wBf9F/OKbbC0/Ht /r+d/q9JTYSTAhwBGoPCdJSkkxcAYnXwSSU//9DuPrn1bK6N9W87qWG0faqWtbQ4gOIfY9lAcGGd 2z1PUXAu+vH15NTnMcXMxpf9o+yNFd1dl9WHhWO3uY59NznW/pMFvq/8D+jsuXpXU+n9Ty7GfZOp PwadpbbWypj3Ok/SZbb7qXbf3FT/AOaOFW31cXJyqeoCD9vNz7LHOHH2iux32e5n+kq9JAk9B+LN DHiMQZ5uEn9GMJT4f9qf1f8A417zxVf16+sPrWP9IZGReLsZ/S2YdkYWU1xqwq35LW225tl9TLcz Jp/0VNnpMVTH+snWrX9Io6ZTQzPxsYmnC+yPJflvyrsTMqn2NwKXYtX2zJte+n0//PPd39M+tfUN mHn5eNTgh4N12J6rMi1jf8G7cfTp9b/Cem9a/VcA9R6fdhtufjOtHsuqJDmuB3Md7S3c3cPezd70 Lu/TttaTAQMY+8KmfX7fFKMIfJxS+Xj9E8no/wC/fOm/XXr7qMrO9VtRY/0szAswrS3pbfW+zsyL 8xjf121lH6e2iz/rdP6OxirWfXr654Wwek7Kx213mvLGN6RyWWDIHSs+2ghv2Zu/Esv9L9H6uKu5 ZgfW7KY3Fz83HxscACzIwg/7TYB7fp3D0sZz/wDSVM/4tKz6p49B9fpeTk4OVO51zLXWb3f92acl z6sj/wADS4j0j9uiThxR0lnjxHb24yyY/wDqk/Rw/wCBDKk+q/VL+odDxbsu825ra2DMJYKoucxm S6vZZXW32VZFX81+jWmXA/ScHf1nT/0Kxtcq2BTnUUmvNzDnXFxItNbaSGwP0fpVOr/O9+5WpPEO +94/76nD7GCQAJAkJAfpR4uGX+PwSXIJGo3NHY+xg/s/SSkn3TuI/POjG/1R+d/r+kTRrMa9iWuc f856TtCC7nsbCP8Ao1sSQrSCZIY76Tz9J5/danh24QAHx7W9mN8f6ydrXuMiZ/0j+39RiIxgaIHf Uk8k+aSlNaGNDR2UkkklMX1sf9IT4Hg/egHFePoWfJ4B/JtVlJJTUDsmk+9ssPLmy6P5X7yI1+8T ukHgzp/0dn/VI6G6lu7cz2uPMcH4hJSzY+HkIH/Uypgx8PuUfcOfwn+9Pr2B+6P+qSU//9H1VJfK qSSn6qSXyqkkp+qkl8qpJKfqez6B+j/a4QmbZ12/9bn/AL6vl1JJT9Rv2dv+nuhPRyf5v+x/35fL aSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKf/2QA4QklNBCEAAAAAAFUAAAAB AQAAAA8AQQBkAG8AYgBlACAAUABoAG8AdABvAHMAaABvAHAAAAATAEEAZABvAGIAZQAgAFAAaABv AHQAbwBzAGgAbwBwACAAQwBTADUAAAABADhCSU0PoAAAAAABHG1hbmlJUkZSAAABEDhCSU1BbkRz AAAA8AAAABAAAAABAAAAAAAAbnVsbAAAAAMAAAAAQUZTdGxvbmcAAAAAAAAAAEZySW5WbExzAAAA AU9iamMAAAABAAAAAAAAbnVsbAAAAAMAAAAARnJJRGxvbmd4CbGJAAAAAEZyRGxsb25nAAAD6AAA AABGckdBZG91YkBWgAAAAAAAAAAAAEZTdHNWbExzAAAAAU9iamMAAAABAAAAAAAAbnVsbAAAAAQA AAAARnNJRGxvbmcAAAAAAAAAAEFGcm1sb25nAAAAAAAAAABGc0ZyVmxMcwAAAAFsb25neAmxiQAA AABMQ250bG9uZwAAAAEAADhCSU1Sb2xsAAAACAAAAAAAAAAAOEJJTQ+hAAAAAAAcbWZyaQAAAAIA AAAQAAAAAQAAAAAAAAABAAAAADhCSU0EBgAAAAAABwAIAAAAAQEA/+EmSGh0dHA6Ly9ucy5hZG9i ZS5jb20veGFwLzEuMC8APD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6 TlRjemtjOWQiPz4gPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0i QWRvYmUgWE1QIENvcmUgNS4wLWMwNjAgNjEuMTM0Nzc3LCAyMDEwLzAyLzEyLTE3OjMyOjAwICAg ICAgICAiPiA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjIt cmRmLXN5bnRheC1ucyMiPiA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4bXA9 Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcv ZGMvZWxlbWVudHMvMS4xLyIgeG1sbnM6eG1wTU09Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEu MC9tbS8iIHhtbG5zOnN0RXZ0PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvc1R5cGUvUmVz b3VyY2VFdmVudCMiIHhtbG5zOnN0UmVmPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvc1R5 cGUvUmVzb3VyY2VSZWYjIiB4bWxuczpwaG90b3Nob3A9Imh0dHA6Ly9ucy5hZG9iZS5jb20vcGhv dG9zaG9wLzEuMC8iIHhtbG5zOnhtcFJpZ2h0cz0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4w L3JpZ2h0cy8iIHhtbG5zOkV4dGVuc2lzRm9udFNlbnNlPSJodHRwOi8vd3d3LmV4dGVuc2lzLmNv bS9tZXRhL0ZvbnRTZW5zZS8iIHhtcDpDcmVhdG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIENTNSBN YWNpbnRvc2giIHhtcDpDcmVhdGVEYXRlPSIyMDEyLTA2LTEyVDE3OjAyOjQ4LTA3OjAwIiB4bXA6 TWV0YWRhdGFEYXRlPSIyMDEyLTA2LTE1VDE2OjE2OjQ4LTA3OjAwIiB4bXA6TW9kaWZ5RGF0ZT0i MjAxMi0wNi0xNVQxNjoxNjo0OC0wNzowMCIgZGM6Zm9ybWF0PSJpbWFnZS9qcGVnIiB4bXBNTTpJ bnN0YW5jZUlEPSJ4bXAuaWlkOkE2NzIxMzBCMzAyMDY4MTE5N0E1QzA4QzdBOUMwODY3IiB4bXBN TTpEb2N1bWVudElEPSJ4bXAuZGlkOkUxNkY4NzM3MzUyMDY4MTE5NDU3RDEzMkQxRDVFMkU3IiB4 bXBNTTpPcmlnaW5hbERvY3VtZW50SUQ9InhtcC5kaWQ6RTM2Rjg3MzczNTIwNjgxMTk0NTdEMTMy RDFENUUyRTciIHBob3Rvc2hvcDpDb2xvck1vZGU9IjMiIHBob3Rvc2hvcDpJQ0NQcm9maWxlPSJz UkdCIElFQzYxOTY2LTIuMSIgeG1wUmlnaHRzOk1hcmtlZD0iRmFsc2UiPiA8eG1wTU06SGlzdG9y eT4gPHJkZjpTZXE+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJjcmVhdGVkIiBzdEV2dDppbnN0YW5j ZUlEPSJ4bXAuaWlkOkUzNkY4NzM3MzUyMDY4MTE5NDU3RDEzMkQxRDVFMkU3IiBzdEV2dDp3aGVu PSIyMDEyLTA2LTEyVDE3OjAyOjQ4LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBQ aG90b3Nob3AgQ1M1IE1hY2ludG9zaCIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0 RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6RTQ2Rjg3MzczNTIwNjgxMTk0NTdEMTMyRDFENUUyRTci IHN0RXZ0OndoZW49IjIwMTItMDYtMTJUMTc6MDM6MjMtMDc6MDAiIHN0RXZ0OnNvZnR3YXJlQWdl bnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgTWFjaW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDxy ZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDpFNTZG ODczNzM1MjA2ODExOTQ1N0QxMzJEMUQ1RTJFNyIgc3RFdnQ6d2hlbj0iMjAxMi0wNi0xMlQxNzow NjoxMy0wNzowMCIgc3RFdnQ6c29mdHdhcmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNp bnRvc2giIHN0RXZ0OmNoYW5nZWQ9Ii8iLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249InNhdmVkIiBz dEV2dDppbnN0YW5jZUlEPSJ4bXAuaWlkOkU2NkY4NzM3MzUyMDY4MTE5NDU3RDEzMkQxRDVFMkU3 IiBzdEV2dDp3aGVuPSIyMDEyLTA2LTEyVDE3OjA3OjE5LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFn ZW50PSJBZG9iZSBQaG90b3Nob3AgQ1M1IE1hY2ludG9zaCIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8 cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6RTc2 Rjg3MzczNTIwNjgxMTk0NTdEMTMyRDFENUUyRTciIHN0RXZ0OndoZW49IjIwMTItMDYtMTJUMTc6 MDk6NTAtMDc6MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgTWFj aW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIg c3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDowMTgwMTE3NDA3MjA2ODExQjFBNENFMDczQzY3M0Q2 MCIgc3RFdnQ6d2hlbj0iMjAxMi0wNi0xM1QwOTozMjoyNS0wNzowMCIgc3RFdnQ6c29mdHdhcmVB Z2VudD0iQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2giIHN0RXZ0OmNoYW5nZWQ9Ii8iLz4g PHJkZjpsaSBzdEV2dDphY3Rpb249InNhdmVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAuaWlkOjAy ODAxMTc0MDcyMDY4MTFCMUE0Q0UwNzNDNjczRDYwIiBzdEV2dDp3aGVuPSIyMDEyLTA2LTEzVDA5 OjQ3OjQ5LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBQaG90b3Nob3AgQ1M1IE1h Y2ludG9zaCIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQi IHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6MDM4MDExNzQwNzIwNjgxMUIxQTRDRTA3M0M2NzNE NjAiIHN0RXZ0OndoZW49IjIwMTItMDYtMTNUMDk6NTE6MTctMDc6MDAiIHN0RXZ0OnNvZnR3YXJl QWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgTWFjaW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIvIi8+ IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDpE ODJERkUyQTE1MjA2ODExQjFBNENFMDczQzY3M0Q2MCIgc3RFdnQ6d2hlbj0iMjAxMi0wNi0xM1Qx MToxMDozNS0wNzowMCIgc3RFdnQ6c29mdHdhcmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9wIENTNSBN YWNpbnRvc2giIHN0RXZ0OmNoYW5nZWQ9Ii8iLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249InNhdmVk IiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAuaWlkOjA2RkU2QzkyMUQyMDY4MTE4RjYyRUFGRTIwMjBF M0M2IiBzdEV2dDp3aGVuPSIyMDEyLTA2LTE0VDExOjU3OjIwLTA3OjAwIiBzdEV2dDpzb2Z0d2Fy ZUFnZW50PSJBZG9iZSBQaG90b3Nob3AgQ1M1IE1hY2ludG9zaCIgc3RFdnQ6Y2hhbmdlZD0iLyIv PiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6 MDdGRTZDOTIxRDIwNjgxMThGNjJFQUZFMjAyMEUzQzYiIHN0RXZ0OndoZW49IjIwMTItMDYtMTRU MTE6NTc6MjAtMDc6MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUg TWFjaW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZl ZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDowOEZFNkM5MjFEMjA2ODExOEY2MkVBRkUyMDIw RTNDNiIgc3RFdnQ6d2hlbj0iMjAxMi0wNi0xNFQxMTo1ODoyNi0wNzowMCIgc3RFdnQ6c29mdHdh cmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2giIHN0RXZ0OmNoYW5nZWQ9Ii8i Lz4gPHJkZjpsaSBzdEV2dDphY3Rpb249InNhdmVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAuaWlk OjA5RkU2QzkyMUQyMDY4MTE4RjYyRUFGRTIwMjBFM0M2IiBzdEV2dDp3aGVuPSIyMDEyLTA2LTE0 VDExOjU5OjA5LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBQaG90b3Nob3AgQ1M1 IE1hY2ludG9zaCIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2 ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6MEFGRTZDOTIxRDIwNjgxMThGNjJFQUZFMjAy MEUzQzYiIHN0RXZ0OndoZW49IjIwMTItMDYtMTRUMTE6NTk6MjctMDc6MDAiIHN0RXZ0OnNvZnR3 YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgTWFjaW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIv Ii8+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlp ZDozMUM2OTQxQTJBMjA2ODExOEY2MkVBRkUyMDIwRTNDNiIgc3RFdnQ6d2hlbj0iMjAxMi0wNi0x NFQxNToyNjoxOC0wNzowMCIgc3RFdnQ6c29mdHdhcmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9wIENT NSBNYWNpbnRvc2giIHN0RXZ0OmNoYW5nZWQ9Ii8iLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249InNh dmVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAuaWlkOkYzMTUzRDIzMTkyMDY4MTE5N0E1QzA4QzdB OUMwODY3IiBzdEV2dDp3aGVuPSIyMDEyLTA2LTE1VDEyOjE4OjI0LTA3OjAwIiBzdEV2dDpzb2Z0 d2FyZUFnZW50PSJBZG9iZSBQaG90b3Nob3AgQ1M1IE1hY2ludG9zaCIgc3RFdnQ6Y2hhbmdlZD0i LyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5p aWQ6RjQxNTNEMjMxOTIwNjgxMTk3QTVDMDhDN0E5QzA4NjciIHN0RXZ0OndoZW49IjIwMTItMDYt MTVUMTI6MTg6MjQtMDc6MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBD UzUgTWFjaW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJz YXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDowRTQ2QzEwRDFGMjA2ODExOTdBNUMwOEM3 QTlDMDg2NyIgc3RFdnQ6d2hlbj0iMjAxMi0wNi0xNVQxNDozMDoxOC0wNzowMCIgc3RFdnQ6c29m dHdhcmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2giIHN0RXZ0OmNoYW5nZWQ9 Ii8iLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249InNhdmVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAu aWlkOjBGNDZDMTBEMUYyMDY4MTE5N0E1QzA4QzdBOUMwODY3IiBzdEV2dDp3aGVuPSIyMDEyLTA2 LTE1VDE0OjMwOjE4LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBQaG90b3Nob3Ag Q1M1IE1hY2ludG9zaCIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0i c2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6QTQ3MjEzMEIzMDIwNjgxMTk3QTVDMDhD N0E5QzA4NjciIHN0RXZ0OndoZW49IjIwMTItMDYtMTVUMTY6MTE6NDUtMDc6MDAiIHN0RXZ0OnNv ZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgTWFjaW50b3NoIiBzdEV2dDpjaGFuZ2Vk PSIvIi8+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1w LmlpZDpBNTcyMTMwQjMwMjA2ODExOTdBNUMwOEM3QTlDMDg2NyIgc3RFdnQ6d2hlbj0iMjAxMi0w Ni0xNVQxNjoxNjo0OC0wNzowMCIgc3RFdnQ6c29mdHdhcmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9w IENTNSBNYWNpbnRvc2giIHN0RXZ0OmNoYW5nZWQ9Ii8iLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249 ImNvbnZlcnRlZCIgc3RFdnQ6cGFyYW1ldGVycz0iZnJvbSBhcHBsaWNhdGlvbi92bmQuYWRvYmUu cGhvdG9zaG9wIHRvIGltYWdlL2pwZWciLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249ImRlcml2ZWQi IHN0RXZ0OnBhcmFtZXRlcnM9ImNvbnZlcnRlZCBmcm9tIGFwcGxpY2F0aW9uL3ZuZC5hZG9iZS5w aG90b3Nob3AgdG8gaW1hZ2UvanBlZyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0 RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6QTY3MjEzMEIzMDIwNjgxMTk3QTVDMDhDN0E5QzA4Njci IHN0RXZ0OndoZW49IjIwMTItMDYtMTVUMTY6MTY6NDgtMDc6MDAiIHN0RXZ0OnNvZnR3YXJlQWdl bnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgTWFjaW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDwv cmRmOlNlcT4gPC94bXBNTTpIaXN0b3J5PiA8eG1wTU06RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFu Y2VJRD0ieG1wLmlpZDpBNTcyMTMwQjMwMjA2ODExOTdBNUMwOEM3QTlDMDg2NyIgc3RSZWY6ZG9j dW1lbnRJRD0ieG1wLmRpZDpFMTZGODczNzM1MjA2ODExOTQ1N0QxMzJEMUQ1RTJFNyIgc3RSZWY6 b3JpZ2luYWxEb2N1bWVudElEPSJ4bXAuZGlkOkUzNkY4NzM3MzUyMDY4MTE5NDU3RDEzMkQxRDVF MkU3Ii8+IDxwaG90b3Nob3A6VGV4dExheWVycz4gPHJkZjpCYWc+IDxyZGY6bGkgcGhvdG9zaG9w OkxheWVyTmFtZT0iRm9sbG93IEJyb2FkY29tIG9uIFR3aXR0ZXIsIEZhY2Vib29rLCBHb29nbGUr LCBMaW5rZWRJbiBhbmQgWW91IiBwaG90b3Nob3A6TGF5ZXJUZXh0PSJGb2xsb3cgQnJvYWRjb20g b24gVHdpdHRlciwgRmFjZWJvb2ssIEdvb2dsZSssIExpbmtlZEluIGFuZCBZb3VUdWJlIFN0YXkg Q29ubmVjdGVkOiBSZWFkIHRoZSBCcm9hZGNvbSBDb25uZWN0ZWQgQmxvZyIvPiA8cmRmOmxpIHBo b3Rvc2hvcDpMYXllck5hbWU9IlRBTEVOVCBBQ1FVSVNJVElPTiIgcGhvdG9zaG9wOkxheWVyVGV4 dD0iVEFMRU5UIEFDUVVJU0lUSU9OIi8+IDwvcmRmOkJhZz4gPC9waG90b3Nob3A6VGV4dExheWVy cz4gPEV4dGVuc2lzRm9udFNlbnNlOnNsdWc+IDxyZGY6QmFnPiA8cmRmOmxpIEV4dGVuc2lzRm9u dFNlbnNlOkZvbnRTZW5zZV8xLjJfQ2hlY2tzdW09IjIxNjk2MTE2MDMiIEV4dGVuc2lzRm9udFNl bnNlOlZlcnNpb249IjUuMDEuMiIgRXh0ZW5zaXNGb250U2Vuc2U6RmFtaWx5PSJBcmlhbCIgRXh0 ZW5zaXNGb250U2Vuc2U6T3V0bGluZUZpbGVTaXplPSIwIiBFeHRlbnNpc0ZvbnRTZW5zZTpLZXJu aW5nQ2hlY2tzdW09IjAiIEV4dGVuc2lzRm9udFNlbnNlOkZvdW5kcnk9Ik1vbm90eXBlIFR5cG9n cmFwaHkiIEV4dGVuc2lzRm9udFNlbnNlOkZvbnRLaW5kPSJPcGVuVHlwZSAtIFRUIiBFeHRlbnNp c0ZvbnRTZW5zZTpDaGVja3N1bT0iMjE2OTYxMTYwMyIgRXh0ZW5zaXNGb250U2Vuc2U6UG9zdFNj cmlwdE5hbWU9IkFyaWFsTVQiLz4gPHJkZjpsaSBFeHRlbnNpc0ZvbnRTZW5zZTpGb250U2Vuc2Vf MS4yX0NoZWNrc3VtPSIyMzY3MTYxNzI2IiBFeHRlbnNpc0ZvbnRTZW5zZTpWZXJzaW9uPSIwMDEu MDA2IiBFeHRlbnNpc0ZvbnRTZW5zZTpGYW1pbHk9IkhlbHZldGljYSIgRXh0ZW5zaXNGb250U2Vu c2U6T3V0bGluZUZpbGVTaXplPSIyOTc1MyIgRXh0ZW5zaXNGb250U2Vuc2U6S2VybmluZ0NoZWNr c3VtPSIxMzg5MzQiIEV4dGVuc2lzRm9udFNlbnNlOkZvdW5kcnk9IkFkb2JlIFN5c3RlbXMiIEV4 dGVuc2lzRm9udFNlbnNlOkZvbnRLaW5kPSJQb3N0U2NyaXB0IiBFeHRlbnNpc0ZvbnRTZW5zZTpD aGVja3N1bT0iMjM2NzE2MTcyNiIgRXh0ZW5zaXNGb250U2Vuc2U6UG9zdFNjcmlwdE5hbWU9Ikhl bHZldGljYSIvPiA8cmRmOmxpIEV4dGVuc2lzRm9udFNlbnNlOkZvbnRTZW5zZV8xLjJfQ2hlY2tz dW09IjE1NTIyNjEyNzEiIEV4dGVuc2lzRm9udFNlbnNlOlZlcnNpb249IjUuMDEuMiIgRXh0ZW5z aXNGb250U2Vuc2U6RmFtaWx5PSJBcmlhbCIgRXh0ZW5zaXNGb250U2Vuc2U6T3V0bGluZUZpbGVT aXplPSIwIiBFeHRlbnNpc0ZvbnRTZW5zZTpLZXJuaW5nQ2hlY2tzdW09IjAiIEV4dGVuc2lzRm9u dFNlbnNlOkZvdW5kcnk9Ik1vbm90eXBlIFR5cG9ncmFwaHkiIEV4dGVuc2lzRm9udFNlbnNlOkZv bnRLaW5kPSJPcGVuVHlwZSAtIFRUIiBFeHRlbnNpc0ZvbnRTZW5zZTpDaGVja3N1bT0iMTU1MjI2 MTI3MSIgRXh0ZW5zaXNGb250U2Vuc2U6UG9zdFNjcmlwdE5hbWU9IkFyaWFsLUJvbGRNVCIvPiA8 L3JkZjpCYWc+IDwvRXh0ZW5zaXNGb250U2Vuc2U6c2x1Zz4gPC9yZGY6RGVzY3JpcHRpb24+IDwv cmRmOlJERj4gPC94OnhtcG1ldGE+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPD94cGFja2V0IGVuZD0idyI/Pv/iDFhJQ0NfUFJPRklMRQABAQAA DEhMaW5vAhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAA AAAAAAAAAAABAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQA AAIEAAAAFHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRt ZGQAAALEAAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAA JHRlY2gAAAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAA Q29weXJpZ2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJz UkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEW zFhZWiAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeF AAAY2lhZWiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNo AAAAAAAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBS R0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBS R0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxS ZWZlcmVuY2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVm ZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlW AFAAAABXH+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBj dXJ2AAAAAAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABt AHIAdwB8AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsB AQEHAQ0BEwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHB AckB0QHZAeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsEC ywLVAuAC6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQT BCAELQQ7BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYF tQXFBdUF5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZ B6wHvwfSB+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J 5Qn7ChEKJwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1 DI4MpwzADNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14P eg+WD7MPzw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLD EuMTAxMjE0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwW jxayFtYW+hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqe GsUa7BsUGzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMf Ph9pH5Qfvx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQf JE0kfCSrJNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWsp nSnQKgIqNSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9a L5Evxy/+MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1 wjX9Njc2cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8Jzxl PKQ84z0iPWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31D wEQDREdEikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtT S5pL4kwqTHJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19T qlP2VEJUj1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1 XIZc1l0nXXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1l kmXnZj1mkmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8e b3hv0XArcIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5 iXnnekZ6pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQd hICE44VHhauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaP npAGkG6Q1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtC m6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n 4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSc tRO1irYBtnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePC X8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA5 0LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLf Kd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o 7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+ S/7c/23////uAA5BZG9iZQBkQAAAAAH/2wCEAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQECAgICAgICAgICAgMDAwMDAwMDAwMBAQEBAQEBAQEBAQICAQICAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA//AABEIADoBCAMBEQAC EQEDEQH/3QAEACH/xAGiAAAABgIDAQAAAAAAAAAAAAAHCAYFBAkDCgIBAAsBAAAGAwEBAQAAAAAA AAAAAAYFBAMHAggBCQAKCxAAAgEDBAEDAwIDAwMCBgl1AQIDBBEFEgYhBxMiAAgxFEEyIxUJUUIW YSQzF1JxgRhikSVDobHwJjRyChnB0TUn4VM2gvGSokRUc0VGN0djKFVWVxqywtLi8mSDdJOEZaOz w9PjKThm83UqOTpISUpYWVpnaGlqdnd4eXqFhoeIiYqUlZaXmJmapKWmp6ipqrS1tre4ubrExcbH yMnK1NXW19jZ2uTl5ufo6er09fb3+Pn6EQACAQMCBAQDBQQEBAYGBW0BAgMRBCESBTEGACITQVEH MmEUcQhCgSORFVKhYhYzCbEkwdFDcvAX4YI0JZJTGGNE8aKyJjUZVDZFZCcKc4OTRnTC0uLyVWV1 VjeEhaOzw9Pj8ykalKS0xNTk9JWltcXV5fUoR1dmOHaGlqa2xtbm9md3h5ent8fX5/dIWGh4iJio uMjY6Pg5SVlpeYmZqbnJ2en5KjpKWmp6ipqqusra6vr/2gAMAwEAAhEDEQA/AN92txOPlvLU1mVp wOSYdwZqiQcAcJT5CKPm30t9f8T7917pNSxbeR3EWf3RG4AuabMbkrlQG3KiZq6FtVvqQfrx73+X WvzPUH+NU9I1qbsanRg2kQ7vx+PSEsCF8SSwRbYqbliAC0kjBj+f0+/fl178+nyDceTgiWbJYday iI/4u+1ak52jItq1y0CxQZaO4/swx1QH5b8+/U69XpR47KY7L0/3WMraetg1FGaCQMYpB+qKePiS CdDwyOFdTwQD711vqf7917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v 3XumrLZqgw0UT1kjtNUuYaKiponqa+vnA1eCio4g01RIByxA0ovqYqoJ9+690mchlM4lOa7J1uP2 djmdY4YniXN5+oke/jhjWORsfFWyW9NPDFkGc/pb8e99az0nq6o3XFRyZBdwZXB46IkjIbrk2nRy zFwBCq4eg2hU1BSSThY5J6epP0K6jYbx6dez69R03bvnF0hravF0GcxUektlq4RbFDKSwGiPNV88 0zPYaNVLTh7/AOt79QevXqnrJRd07Zey5nHbg29IqxNO+Qxc0tJEKjV9u/no/PKYZ9J0MYlDWNuB f37T17UOlrjt9bOywH2G5cNMxAIieuhp57EXv9vUtDPx+fTx+feqH069UdKlHSRVeN1dGF1dGDKw P0KspII96631y9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//Q39JG 0DUI3kYDhUC6j/gC7Igv/iQPfuvdM09TuJiRRYnGov4kyOYmif8A2EFFi65W4HN5Vtf8/T3vHXs9 RCN4sSGTa7RE2aMtlCWQ/VC5jK3K8X0W/wAPx79jrWek5Pg6tJmqpNmUENSeWyGy9xNjMrIeCTIJ 6TbkUxB40y1MiMPrwSvv1fn178uk1Uhkr45xPVnM+mGmfJQw7R3kwtZYKXLeBdrbwVQCFp5UMZIu XJ97691q9d//AM5/5e9b/NnfGOwWdwyfG/pfuqHqjdmxp9gbaCbiotv5nLYTcdRmtySY3Kbyxu6M 2Nt5WemOOr4qOFqVNNPKius0W7jzbudvvVwsTD93QzaCukGtCQatTVU0YihpjgfPtr7T/cM9lua/ u68q3W92Nw3u7zBy6dyt7v6qdGhaeKKaBY7ZZVtGhh+oto5hNEzsZG/UjLJ4e3jFLFPFHNBJHNDK iyRSxOskUsbgMkkciEo6OpuCCQR7lDriX1k9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173 7r3Sey+caknjxWLgXJZ6qj8kFDrKQUlPrWNsjlZ1VzR0ERbjgyTMNEasb231qvTGVh25Mksvk3Lv bMxiKMeiKaWJGBkjp1PkjwW26F21OeRexYyzsNXuP2de/wAPXGSNMHNS5LL33HvLJa6bGUdMBHHD qCtUUuGgmLR4zF0y2apq5PWygGRiTHGPf4Ovf4esdRH/AAqWkyeaVdw7xrmaLB4qnJWjopjGPNFi IZtS0VHTI16rISjylP1EAxw+/de/w9YqiB6Cto5K1YNz76rleXHUzBo8TgYNQWarpoW8v8LxVGTp apYNWVb2QMSQie/wde/w9M+Z25DlaxcV5DnN5eOCrrNyVRZKTalOzjx/aUEMnhgWoDP4KDk1SgtU u6gs3v8AB1qn7egprtmU82QbGiGlrBBWPjTm55Xhx+UrKWqp6gY3bry00mNwWZEc8sD0kzyYwyR+ ONC2sRWr1qnWel2ZiqBJJoZq2mWjlaCqrJarIYpMfUTHUtPuShopWqtsV9iBHXItZjJEs3jVSp9+ r1ug6VVHQ5ajm8cOa3RFPTx/cyUL5WurapKZrWr2xcde9LuTHMbXqcbNGUBCml1XUe/Ide6EHF5/ JoKYTVEGShqgBSSySU/jyJF7pjcxTw0lK9WoBH2tVT082oEa2sW91630uKKvp65HaFmDxN46inlU xVFNLa5iqIW9Ub2Nx+GHKkgg+9db6me/de697917r3v3Xuve/de697917r3v3Xuve/de6//R38Zm nAtTxxu/4aaQxxj/AF9CSOf9YD/Y+/de6ZZcXmaxj9zuGejiP+6MNRUdMSP9S9VkI8pUH/g0fiJ/ w+nvf5de6TFVHsinleCu3Fkq+tU/uUq7t3BXVge9uMVjMkwidibAJApP0H9Pfs+nWsevXCT+60h8 kFBvsk3Xy0VN2JQFdNiGjYGj1I4P6kurjgkj37Py691DrKigFPJA+fzVPSSJolx++trZCtwcikD0 TVeRxeNqZLagGb751H1IPvf5de60Icnt6Tsj4kfMDvxaN3GV+ZfT2ZFfFQ414qenyOC+Qk9XSLVz LDm8ZDV1PY9G7RIggqWhiLqGgGmC2T6nad4v6ZN5Ga/aJa/POsV/L06+m2y3Icn++vsD7YiTTHb+ 326waO+haObYghNCyEom3yhSSdIdxq7xXdU+NXYGVy/RvSW9qGV2h3t0/wBb71mxtVRSwRVUO4tm 4XNTZD+G0lLGyQMtaXavxMGhS16ugjfUVmjb5fqLCxn/AI4Ub9qg/L1+XXzn+62yf1Z90fcnlzTT 937/ALhbU9PAu5oqfE/8PHU3+mPHo2+D3di814IS32GQqIjNDRVMsLisiXhqjFVtPJLQ5elUjl6e R9H0cI11CunQCr0qveut9e9+691737r3Xvfuvde9+6910zKqlmIVVBZmYgKqgXJJPAAHv3Xuke+d rc4zUu0xG9OGaOp3PURmTFU9rqwxMd0/jlWtuGQikQ/qkYgxndKcetceHUYS0+BeXB7egbNbnrSl VkKismLsjygIuW3LkI0JghEY/ZgRQzqvjgRUF09x48OvfZx69+1tgFI/LuHeWcCli5EdTXvD6fLL pEkeG27jWlPAHjiDWUSTP6/cfs69w+3rohdtWrKstuHeecH2sEcVonqjGTL9lQRsXTE7fxxfXLIb hV9cjSSsur3H7OvcPt69b+7aHI5AjObyzzLSU0MF4/uJB+5HisWjhzj8FjtXkmlYcKDNKS5A9+/w de4fb1xZanbtOEjaLL723NLp8r+Radp4lZmkKFnkpNubfhlJVAQSLC5mmJb3H7Ovf4esc1HJjoqf aWGqpmzGY8uSz2cfT95DRyMIsjmpWAKJkK6QCnoktojt6R44Cvv3zPXvl0rkw2LTFLhPsaZ8UtMt J9jJGstO0CgemRJA3kJI1Fmuxb1E3596630gsttnJYx46vHyV2Rp6WMxUtTTtHLufEUty7UeurPg 3bgxzejqyahRzG8kmm1q9a6SUE0Jip4o4qc05qiKWlpKh6DHjJj9b7VyNS0dZszcim5bE1pSGViU RrF3b3WunSOrDGdnkpZXq5hR1j1sBoMdl6z06cZurH6NW2t02t4axUWGdtNrgpGPdb6dYK4pJHIt VPSzQSpj6bIZIEVWNrG8bJtvdyKf8opakkfa1l2D6gVcsVeXXXuhAxWUTJwyaonpa2kk+2yNBKbz UVWEVzGWsBLDIjh4pV9MsbBh/Qa6306e/de697917r3v3Xuve/de6wLUwyO0cciysps4jOsIf6Oy 3VD/AIEg+/de6z+/de6//9LfqqVyEoKUklNSA/WomjaqkA/OinWSCPV/Qs5A/wBSfz7r3VePye/m Nfy7fh72HQ9V/Lz5a9c9adj5TauN3vR7K7CzmRhnn2rlslmcRjcz/AMJjJMOKOtyO36yKMTxtMRA SfSQzbr1qnQb77/nY/ypepKDYkuV+ZHQ9Fiuyto/372DX4rdGPfb+49oruTcezJM/jq/HRzQTY+n 3ds/K4uUxJI8WQxtTTsokglVPfn178ulxu3+a98D9ndBbe+Ue5fmf8WdvdC7vy2V2/tPf9H2EN+R bm3HgoYajO7XwGC26KHcma3ZgKaqilyGKpKSauoklQzRoro59jreep2Q+efxp7Y+E/bfyu6p+Xvx 0zXRW3trbsw2X7qlfJUmwtnbnkoYsRQYvesv8Yy+c2nkkzG4MarUtTi6ivKVkLR0c/nhSRmdXeCZ IqeIUIFeFSMVwcV+R+zo75YvNu27mTl7cN5SRtogvoJJxGA0hhSVGlEal4gXKBgoMkYLUBdPiGu9 R9R9D9NfyVt77i378vvh+2xvk78jNv1nR3yRx3ZG+h09nMvtStx1BWbL/itb1HQbin3FHH1DvaKS nFE8cFRRAFktUFAPb8qXsfL19tbzRfVyTK6kFtAA0cTo1A0DcFPl8+umHNX36PbrefvX+2fvZt+w b8nIWz8v3FhcwvDarfPLOL86oolv2tniDy2hrJPGw0zHQxWLVbN/Lr+W3xNzvwu2zQ7Z+Xfxl7Po PjH1pRw93bm697LhqNs9cYTa8OSSj3bvXFbnptm7r2jgxgsSzruOGloQxp5mZahYXlYX7TazWW22 dpcMpljQKStSMcKEgHhTiB1gV76c6cu+43u/7hc+cqWt1BsO77lJdRJcoiTqZqPIJEilnQHxS5Gi VwQQcfCBU+OP8zr+X78udzb02V8e/lZ1J2duvZWPym593bZoczFR5dcDg/E2Z3nT4XdNHtaj7C2r hFljepz2H+1rKRXQzSMWVmMOonp1P6O/nCfy9e6u1qjo3pn5tdHdidiU0OQmpNswbqqsric9T4nH VeYycmzt31lFj6rNpjMPj56uqNMc5FSUsMkry+NGdfYPW89CDsv+cH/Lv3x0r2l8icL8nusMj0l0 jldp4TtntDDZ18ttDY2V33kqfD7OocxKtHS5+KbcmVqkp6Qfw4eaUkLcq+nXXvy6OD0v8mOivkR1 ptHuPpXsbD9hdX78o6zIbP3rhabLphc/RUGUr8LWVVBNkMdRSNDT5bF1FOxZF/chYfj3rr1R0Jn9 8cEw/wAnkyNcx4EePwWcr31cWDfa46VYr3+rlVH1JA59+p16o64nL7grfTituSUqm9q3cVXBQQj6 WeOhoGyWRlIB/RKtNci2ofX3vr2fTplyVPioHibe2eGYqHbXS7fp6eSKgmYXIWm2xRPXZHMsCeBU NV2IBAU+/fZ177enO+4s2qw0sT7Tw+kIZ5Vp5Nw1EIAASkpF81DhY2T6PKZp1HHijYXHsfn17PUK kraWlSTCbGo4a6oWeX+IZaaSabFUdW1vuKrK5Qs9RmssWtqhjkeZjYSPEtm9++3r3yHWXVS7YbwR fcbj3hmVV31si11eEkZRPUMimDDbfoHlYKABFELqgklaz+4/Z17h9vXarHtmN8tlnbM7qzLJSRRU ifu1UvqlgweDglb/ACXF0vLu7kCwaedvqR7jgde/w9dLp2+ku4M/av3LlSlFTUlAGmca/XS7dwMc zKfChQvNKRGJGDTS6EUBPcfs69/h67QvgIJ9wZ2+Q3HlfFR09DQgyaGbVJRbcwysLmJZAXlmbT5G DTSFI1Cx++Xl17/D08bfxU+PhqKvIvHPm8tKKzLVEVzEsgXRT0FKzAOKDGQWiiBtqs0hGuRr+P8A Lrw/n0oPeut9e9+690l83tPGZozT6TRZCaD7eWtp44XFVCOVpspRVEctDlqQNz46iN9P1Qo1mG69 ap0E+bwW7cAHmXHyZykjgNManFxnI1DUFjegq8VWyyVeTxWktahqHqhGCTDVwEhfe8HrWR0lafem PMrU0sqw1KQCj+3yEdVPeiIYSYXJwVMa1mYwTa7Ikkf8RoXYtCamO7e90PWq9K7GbjEFRSVlA7TT QLFTQJLVxyyVmPmlcw7bylaZXgqpBJqOGyesxTsDBIySM4fVOt16GCDcuBnoYcicrQ09LMpYNWVM NG8TI3jlhqI6l43gqIJQUkRgGRwVIB916tXrAN14abjHy1OXY/oOHoazIwP9OfvqaF8eim/DNKqn +vvdOtV67kyOYkQyLQUmGpx9anN1kTyKObH7LHyyQtcc+qqjI/pf6a631Ejanqv87W1+4X/440MY gxfNxp1QmGikQn8T1Ep976108RtPFGvmWixdKnpSJHV3A5spfTDTwk/6lQ/+v711vpyRldQVJKn6 Egi4/qLgXB9+691//9Pfiq6XJ1hMa5H+GwHgmhgilrWB/pU1iTU8Nx/SBmH4YHn37r3XzQ/513W3 yW7e/nPfODdW3vjn8193bVxfx7pPj58cdwdZfBmD5XYrfu+JuqtlY+rwM03aNBFiNo7Hy+7ty7pv vHa38W3NhJVhOKpS0rvT+690T74/fywP5lGW7E39T/7LXX9A7p+BP8sDtrelJRdt/FnL977E7ezz YvcPY8vUOw8D2dtvd2y8/wDIHsGo78rJIoYoa0YLcdFWrR0oNJBH7917p4+FfxR7A+FPcP8ALx+T vzZ/lmfMr5GfFmp6M7oy0nTm1Omdw9pyYr5DZDtDurrnE/3t603XT7d27trM5VcJt3Kpi8maOpfH zY6ugFfNRrG3uvdR+uvgd/NL3zHkPh1tv+XN36nXHyk+R2J+dnePxwxObpfjXtTH9NbOq8qOv+hI O7e2MVSdedSblq8XuXIVNTjq/wDiVfAkG2ZjQNXUL0sfuvdRJtgfK9/5cH8ur4j9vfBT5h5va3QH 8xvv7f3eO19l/GPs7K7urelMPTdFZ7H/AMImfEYzB56s3NUdt9gUeKMtdBSyzUBAqYYmMre690vf l3/K5/mE949c/wAwP+YF8dPgV3p8Uuiu7+9Ordr7X+FWL6+qtu9qZ/44Y2jzm69zb8zvQ+DoY9wU +PwfZeydlZeqSlx8zGuyuQqIJJqGiq6p/de6NZ8qOhs587Ojvkl2R/L0/kfdw/Eqk6o+OXWvV3V3 eG7Id9dGd890bIh3RtTH9m9R7Q+MmxKeHqvvXOZDYuWzqZHOoMruKvwVCkFTVy1UlJj039nWuirb 86E7V+S+yfiLvz4Vfy4PkT8RsF/LQ+H26sj3f3Fu3oqt683V3t8q9uYCjjO0tqV20dvVO5u5Mzub tzApGkdU0udig3BlDWw0FJApPuvfn1XpX/y/P5lPX/x57p6Wofj78g8d01n9nfFX5a7owrdM9itm N47+nw1Hsba/XuLmo9qwPkc3gKv5D5XKZLBsKh6Kk28Zp1jqqQn3rrfX0n/5P249zdffGbr74Z5L or5XdOVHwz6A+LOyNzdi9i9Y4aj6o7d7D3703iN+9jHpmuEOR3PuKk2ZuiumgzAMSJQVVbHBqdwx XfWura/43KBeo3pkKVT6SKjZNTj5wxU8KtfjhpkT8hkax4I9+61+fXmqcTVC1XuLfedDAHwY/F5m jgcEXsJdrYHFsISRb9yYrzZmPv35Drf7enLHLUUaum2NkJjDObzV+aqKLF+clgTLP9k2XzNZIoJN p0jLEAah9R77T177B1iylPSxhG3xudJUmJMOBx5kxVBUgg/s/Y001Rm85wpBjeV4nsf2R9PfvsHX vtPU+GfN5CGOkwONTa+JjVYo6/JUkcdaIV404rbyhUpRp4V6wxlD9adx79jr3UWCoxuEmq8Xtylm 3DuSeRWyc8lR5ZVn0kpPuTNsjxUUcSNdIADIFNoYNP09x48Ovf4espSl2438Yzc75vdGSBpKVKWn BqJT/nRhtuUDOxpaJLBpWZ/Vby1ElgCvuPDh17h9vXJF/hIn3ZuudP4iYzS0VDTGSpgxUFTIgixO KiVRJkMrXyqgllCeSeSyIFjUA++Q698z1Mw+Mq6qs/vHnYgmTkiaLG44lZItv0EhJNOjK7xyZSrW xq51PNhGh8a+rx9B1759Kr3rrfXvfuvde9+691737r3XvfuvdNuRw+Jy6eLK4zH5KPSVC11HT1QU Hn0+aN9HPPFrHn36tOvdBjmOk9nZDVLjVrMDUlSB9lMKiickhrT0FeKiKSLUAdCNGCQPdtR60VHQ cjYe+tgVP3mNig3Bih4zUth6akpsl44I1hjkaklpZ6lZ1TUWanMryFiXP597qD1qhHStwm5UzETH z19W6MRNFLubedF9sF/UlVLiduvDG6MAbO6mxN7j3rrwPS0o5MUGSULs+Cb6LNWZWoylWjDTrCyZ Kloqo2uCeV5Fj/Uaz1vpRpU+YevLmUWt48RQNbjjTq05GYcfkMv9eB711vqTFEFYPTY6R5QOKvJT Hyf64eRqqrX/AFtKD/W/HutdShUCJtNRVJJMfpT00ZLD/DxqZZmH+JsP9b37rfX/1N135aZr5L7a 6V3HnPibsjbPZ3dlNkNvR7b2PvHIUmG21ksdU5yhg3HPXZCo3v12Ulx+BknmhAzFNqlQALKbRlBu cm4RWcj7XAkl5UUVsAiorxZeAr5j8+pT9mdp9p979wNq273s5nvtn9vHinM91aIzzo6xOYAqpaXr EPMEVqW70UnKfEKb8v0t/O5+ZTx7H7i3D1V8FuqnCx7sbqTMUlXuTdNJK+iYUsmzuw+xtz5OYxOy yUdRuXCY+oiZhL5CFUhOS15x3ciG8ljs7bz0HJ+zSzk/ZrUHrO/bOd/7vX2BR9/5A2fePcPnLjb/ ALxiZYIGGQX+qsrGBBWhWVbG7mRgNGkVPTk/8hWm6wo497/GD5j97dbd94+IV8W8szWY9NvZ3OJL NUSxV0OzqTb+48XisqZPHN5qzM6FeRpIqlWMR3/UoWw8bbt2mjvRnUaUJ+emhAP2t9h4dNL/AHkM vN878v8Au97Fcubt7bStoNrErmaGEgKChummgkkjpqXTFa1IUK8JAcYsV/Nl+R/wnqh1T/Mz+Nm+ qzL4t3o8D310vjsBWbd7LpYo3FNXw4/JV+1tkVuQqPGss0lBk6GWJJQk2LpZY2R9LzPuG0H6bmHb 3LjhJGBR/nQkLX7CPmoPV7z7lntX7/wnnP7pXuvt0djMA02z7o8yz2DEjUheNLi7RFqVQTQTKxUt HeTIwZQJqO9vkX/OI+W3VFJ8eIO+egvhr1RKJ+xt6x5/LbEq8/TzV9Lktz02ZyeyM+2Hqt1Z+ixl PiMNi6evycmO8k1c5WF6gRoje3/Ne6WosBPBtMXxtUrXNTUqaajQKoBNMtwr1IsXt17W/cX9lOdJ /c+TlvmX333oUsbQwx3awsEaO3aKO7h8VbeF5Hubq4eGBZ6R26guseraTVVRVVVCqoCqqgBVUCwV QLAAAcD3JHXHsksSSak9azHf+/fk3/Kz+fW5PkLnh3X3b8Ge4UzMmQw8e6NwbtxPX0m6J6fLZDA4 yjz+Ul27tDcW0N20vlwq1BpKauwE7UUNQj/cNTx5fT7jy3vcl8/jTbNLWoqWC1yQKmilW+GtAVwD xp1q9tOW/aT74n3bNq9sdt/q/wAv/eI2IxBJTbw20l6LcNGk0jQxie5gubZtN0U8SSK8QXDxMvhC URdy/wA5ve/yuj/0Qfy8viX2b2J2PuVRj6ndPcOE29R7P2DHUEJ/Hcxj9s7o3HgFgplYtFVZfNYu ip5whdKkHwOpbm6fcSLbYNtle5b8TgBV+ZoSPzZgPt4dBGx+4Jyv7Rxvzh96j3k2bb+T7bvFrt0k z3F6Vz4Mb3FvBNqJwY7a1uJWXVpaIjxFY5/5HPYPdFEvYvzQ+WPa/bPb2VpVqK+g2LkMZBhdm1bR gxY/btRvXG5Klz2MxsjELTUlJtmAJdYVXjV4cnS348fet2lkuzntppX5CoOPsCj5dVk/vCNi9spB yz93P2K2PauQ4DoDXayG6ulXAlm+nljIkZQKtPPeSE9zyMcBNbe+OX83T4PSVuL+Jfa+3PmD05E7 wU/WnaMiUme2qsrqwpa/Z29904GvwHjWRhoxGf8At6mzSmmRmUDy7bzXsrFNtuUu7TyWQ0I/3plp T+i9Dx0jp6+93fuL/eOgS/8AeXky/wCQuexmW92pGkinpxqba0uBIz0FTcba0sY0oty6gnqwb4Q7 /wDnn2LmOwR8vvjv1D09SY2g2/Lsf/QrvigxGey+SqZ8r/eOPOYTF919kQ/5HTw0jIKyHGgtKxDT ciI+2e43+ZpxvVjFCoA0aCDU5rWkj8Men59YtfeE5W+6zy7Z8rv93T3J3rf72WWcXy30UkYhRVi8 Ax69q26pdjKGo0tAq4Ti1h4q6+lIWbJ9jY0AgGCr23itwxpYm6/dYPCZiVvwC7VDrbm97n2e/s6x i/b12c4LETb5r6cPzGDtP7OoADfXTW4uUMpAIv4xf8e/fl1qvz68ajFTkrVbg7AzgIBEVHi81RRM rLqA8+1tvYdPGy/QvLY/S5N7+/Idb/b1Px0clG7NtzYn2MswtLk81U0GMee/9qompnzOdqWH9Jol J+lx9R77T178uu8lEYo0m3nuuGippLquIxMrYSlqWPAgNR55c9k5T9NEMsKyXsYjwB77B177T1lo 6mvlpkoNoYCHCYxPTHk8vRtjqVFJ9ctDt9Pt8nVyMOQaj7RGJ1amtY++09e+wdYlkxG362UI9bur eNVEqyKpgqcsYnbUkb6fBj9uYfXyA328Btf1yfX3H7Ovf4enbH4WrnrI81uKSGpycWv+HUFMzvi8 EkgZHFJ5FjasyEkbaZKuRFcqSsaxoWDe+zr329Kj3rrfXvfuvde9+691737r3Xvfuvde9+691737 r3Xvfuvde9+690jNxbHw+ekFciLjczEdUOVpYovKWH6RVxMPHWICB+r1i3pYc32CR1qnTFTHcWBI hy0tWadTZcjRVxlpXS/p1/xqLKR0rEfUSPSxKSAhP49g9e6VUFXUSIrvUZoK4upTH4+cEH8rNRQV lObH8gke/db6k3ST9UGarD/qZb0qE/0ZHehgP+xFveuvdSEWqjjIhp6HGQgXLSESuP6s0UPhhB/x Mrc/X37r3X//1d/j37r3Xvfuvde9+691gqaamrKealrKeCqpaiNoqimqYo56eeJxZ4poZVaOWNwb FWBBHvRAIIIqOnIpZYJEmglZJlNQykggjgQRkEeo65xRRU8UUEEUcMEMaRQwxIscUUUahI4oo0Cp HHGigKoAAAsPewAAABjqru8rvJI5aRiSSTUknJJJySTkk9ZPfuq9e9+691FoqChxlLFRY2jpcfRQ a/DSUVPDSUsPkkeaTxU8CRxR+SWRmawF2Yk8n3oKqgBQAOnri5uLuZ7i6neWdqVZ2LMaAAVYkk0A AFTwAHUr3vpnpmyeAxeWeOeqpytZApWmyVJNNQ5OlB5Igr6R4apIy3JTUY2t6lI9+r16nSbr9sZS ZVSaXCbqp4gPBT7qxsMdfDpNx4c5jKcrCR+GNE8lwCWJvfdetU6bBR1dBcfwre+HC8+XB5+LcmNU 6vUKehylVV1KL/tK0CrbkC9/fuvdd/xd4QQ28dyUpAF/49sk07AA6SA6bdxEEjM5sGXUrW9N7E+/ fl178+sn8YU6lfsWIHxebRT4bHJVqgIOsRTQ1LWP0IMZNzYc+/fl17/bdYzU4ipA+43JvzOg8iPH Y/L0qMLm6mbamAxQRbrpJeQW4BNzz78uvfmepuPiFJKZdvbCenqZOGy2cqKDGySggqfNViTM7hks v18kHIPH59+/Pr32Dp2OHzuSv/Gs61LTE/8AFt23HJjQy8eipzE0k2Ul/PqpzRnnkG3PuvdPuOxe OxNP9rjaOCigLGR1gjCmWVra5p5OZKieS3qkcs7Hkk+9db6n+/de697917r3v3Xuve/de697917r 3v3Xuve/de697917r3v3Xuve/de697917r3v3XumtsNji7SRQNSSMSzPQTz0DMx/tSCjlhWU8f2w wP59+6913/C1/NdkytrafvpR/resWlv/AI6r+/de67GIx+oPJT/cupur1ss9cyn+qmsknKkfi1rf j37r3X//1t/j37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+ 691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3 Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//2Q== ------=_NextPart_000_0234_01CD7546.13BF3130 Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhGQAZAHcAMSH/C01TT0ZGSUNFOS4wFQAAAAlwSFlzAAAOxAAADsQBlSsOGwAh/wtJQ0NS R0JHMTAxMgAh/wtNU09GRklDRTkuMCwAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADqYAAA OpgAABdvkl/FRgAh/wtNU09GRklDRTkuMBgAAAAMbXNPUE1TT0ZGSUNFOS4wzfpCa7cALAAAAAAZ ABkAhwBpngBqnxR/rgF0pgBvogBwowp5qRZ+rQNxpABvowBuogR2pwBzpQBxpAN1pgBtoQVxpAJy pRB8qwV2pwBuoRR+rBV+rABypQJ0pgBypA97qgZ2pwBsoQd3qABxowN1pwN2pwR1pxF+rhmBrxyI tR2Jth6ItRWCsh2ItR2HtR6JtjF1lD12kCd5nSOPvSeKtTOSuiCLuDeDpSaRvjuGpjOPtjeRuCaR vzqGpzmSuTyUuieIszWQuDyGpiKLuTiFpiKMuyCItCGDriGKuCKJtimTwCyWwiyZxy6WwUmBmkaZ vUOYvUCawVKlyFWnyUmhxVCgw2KeuH6yx3C41We00mi00mez0mm103W82Gq102m002231WWz0m23 1Gu102u202641G221G693Gu21G+51XC51m631Wy31GKx0WOy0WOx0W641XG51nO92mGuznS51XzA 2nvA2n3B24GTnI2Zno6ZnoyYnZafo5qxu5mstI6lr4+msI6lsI2kr42kroGxxIKzxoa2x4/C1ozG 3JHI3ZDI3JDI3onA1oLE3YLD3ITC24HB2o7B14/B15TE2YPK5o7N5InJ4YvO6I7L443S7Y7S64vN 5YzP6oLG4YrO6YHG4I/S64TH4Z/P457P45TK4KK1vam2u6SzuKSzuau1uaStsqitsKrM2rHY6LLZ 6a/Y6MfX3dvd38PGx8zNzcDc6cXf6sLd6cTe6sXe6sfj79vu9cLg7dTn8NDk7t/t9N7t9Nrq8svi 7Ozt7uzs7PT6/Ofx9unz9/n8/fb5/Pr9/eDt9Pr8/efx9+fy9+vr6/r6+ujo6P///wECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwj/AJkJHEiwoMGDqwQNIlSoocOHDQ0dOtWL IKhHkBDBicOxo0eOciJJkuJLICs5k6ZQqcKypcuWVq4kooRHYKhKWKxk2cmzp88rWiz9ESjq0pYr PLlw8cm0CiZAAkdl6oI0ixdFir4w7VlFE1RmojaBQVolzK9fXaps3VmFUyCBecSMIVPGjJlOns5U QcMFTRo1VNZMYeOlTRSBelwIeMGkiRtUqa4sovVJVS1bb5w8gTEihgyBe2YMIECggAFgwQ5AYSbs Fi5mrxAkIKCABA3QMxYwYNDAQS5dD2owgwUhwq5hEgrwLnGbWWjdvCfkylXABjNGACjEIlZBeQPm oG9AzW8gnbp1RgEIyBLWfXnz57vJFytWnVmj9LOMtf+OQyCf3PFNcAwyBeTAjCPp8cKMBd6V0B8z fQDIwAUY6KBDBhoosUMDGfCwxAYZLNeDQBFCt9sDDzCQAQcJ7KbAAxfEV8KIzOgh3m445qgjjt/R 6EcRHYS445C7eeDDDwKRAkQQBQhJZI4eGGBEEgIls8IRJnTwAQhcdukllyGIgMQJpQzUCgtCDIHC mmy2SQIKKahARAtzKEPQMqbQoScdddSxJ5+A2nGHKwcVaihBAQEAOw== ------=_NextPart_000_0234_01CD7546.13BF3130 Content-Type: image/png; name="image003.png" Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAABkAAAAZCAIAAABLixI0AAAACXBIWXMAAA7EAAAOxAGVKw4bAAAK T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3 AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+ 5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk 5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd 0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA 4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5 h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+ Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY /R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1 mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/ 0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5 hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9 rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7 vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO 32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21 e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i /suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8 IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq YAAAOpgAABdvkl/FRgAABDhJREFUeNqsVTtvHGUUPed+Mzu762eMTUKUOA8lSBilSIIl8hCvAokG mjTQQEEFEiUVBb+BKkJIFCkgUgqQiIgoKAJIUUBWQIGERxIlspM4Nthe7+7sY757KHZjb3iIhk9T jL7RHJ1z7r3nUhL+p5NsvH07v3x5qV7JSiAhEAD/5SeBxmartWWo8vT20fGhSu+akmKMJ89f6uw6 UEXR6EYHCAgiSP4DkABA5RBCSO6trJwYrs88uq/P6+yFufbeQ2yu/7DeiYILXakSzIGOKwsPAPYs EQTh4XKYnpw4c2v97elWuVxO2u32pTyZVPfSWrvnXDWxl3cOPz6WReni7+1ztxsiDOwRIiGBgIj5 ZpFavfzIzrkfrxw9fDDpFkUsirVO0XFPjFF4fd/YgfFSQzDipR3JWMlO3aiVbJNXj5kEo5baxd4R W16rATCSkjouhzqu6aH0wHjpboF7heY7+iPiqanKSGrrhTcLNQtvu7vkgiAHCleUywUgISBAkgsR mswMQM0VARfWXBOBx6cqS60iMbqw2I7X1jsBIOCSgxtNlUjqxFgGyI0aoeXIBQEpAeDEzuHBSn6z lL9/bc0AkiQ6cof6dVzMW6o1Fhp5OUnangGIQFcwYDXip7ZSIgARaAsTgcemKldrnU/nay53j57Y fr+PRbLlfi9vR7QfG00A1CPqQk/IagR7igAXrkvPjnB2ovTelaZRQ8GEvpqk538wpsFMNBJA7qpH GCAgarBPIYBgFCywREsDgxk3/CJpNDOTYGYA2hF5IRIV49TmmMGF3RmHibN36oFmBjOz+72cADDQ jIEE+7xarmaUA9vKeG4kDBq/2okfXF///E5jKA1RCuQGWAKARiODGdDHake0Ihwo/K/jeKtZfLWc w5iQcDej0TZ5ETDSSJHB+rxaUSKWuvgl98FU2j+WnTy87c25xWv1Tk8gBzX2+qT3YaUrABWiVqhs uJ7r16ZvGO/AeOBbO9JXd4+9c3kpIc34oF+kkUakwW40urWuHxkN39Vix5H8LXNudnWzpV3VpBSC QUaQ/aSzfuSRJIOxEXV6ob63zFe2pqMBeVRz4KlH7c64p8yr9a56w0waSRBAIsDNKsF6BammduZ2 MzV7bXp4diRbKVQMuEVgMuVK1z9aaJSDuVQKJBklAEkpTYtmfXs1G0oaXTEBy4GnbzfnasUzk+U9 1ZAZB/pLF1biZ3fz5Y6SwFah6WraKHy8kgFIsiw7mrYutoqDk8O/reW5YORwsIVWPLXQTMwCjexn SXQV7gGqBBpsTzUd37Ll56+/nH3hiX7ed7vddz/8+M6h56e3TkkiLRjNEAxmMMIIAe5wwR3R4S4C zSLevHD+jV3V40ee7GMByPP8k3NffL+4WoDWzx5avyj9FSJJgqD7a5APBb14bHZmZmZzD23YURRF jLEfwP91SGZZNnjz5wCK81KNPiIliQAAAABJRU5ErkJggg== ------=_NextPart_000_0234_01CD7546.13BF3130 Content-Type: image/png; name="image004.png" Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAABkAAAAZCAIAAABLixI0AAAACXBIWXMAAA7EAAAOxAGVKw4bAAAK T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3 AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+ 5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk 5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd 0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA 4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5 h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+ Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY /R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1 mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/ 0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5 hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9 rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7 vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO 32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21 e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i /suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8 IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq YAAAOpgAABdvkl/FRgAAA9BJREFUeNqslc1rXFUYxt/nfc+5985kzIclpk0tCQl1CLRpFy5iQYR2 URFEEcS13fgHCN26FtyJblwJggilCxEUFypWRYTa0KQaaPNh0wxkzOSrmU7v3HPO6+Le+Wgx1IVn NffOOb/3ed7n3HOgqvQ/DdP9tbPX/HWhvnfQSpLkvxXQrO2qk0NnqsfyZ+TLrt9YuHa7dGS4EtS3 M/9kDJEASWwOUtjm0ttvvgQAqpqm6Yef/35iYnpjc3drNw2Ha3JenQ9d0UMVO3280nTx9MDaxfNz hohuLi4NjIzX6jt3N5tW8O8YUDsLYyNJdWJkdDiJLKvqj/P1hTvbs9Wx+TsHF8+TIaL9+03Voc3G A9VwmL92O1QnBt957WQSS/flrZXd5Xv37zdTBYreM3P6MGu3nc8C8LgcIoSg1vBbFyb6QUQUfHDO pakjDb0cffDee+c8QFTwQEQAiDTNwuyJwaNHSvnkVuq/+mm9sZeubOyDgg8+BC1YqqGdtoNqUEUe UlcVNHPabLlS0ts9P9+sf/b1chJLpWRE2PvQbrcLlnN+dXV9s9GUKCmVEmutGCPCAEKgqfFKOTGT xwa6rErJvHh2LI7k1u366tqW8S1qNXoenQ+7uwetdM8YyyLGWGONMSZzdOmVuXNnj/a3ae7U6Nyp USJ69/3a3Xtbx0fLCbhggYjBYqzxAhYiOKfOOSXfSr3zh25dMcYYy2IooKsLABMEDLAAIAgAIo5h rv/RaLb8s2OV0yefzhHL63tLazvW8Ob2Q2stwKCOLiUlFoAJBAiYCQwwgWODL75d3T/I3rgw2WV9 91vtg0/nK2WJLcdxTBB0Pea6AAEAZrAULGIASWIDSZxEXWuRNZWBUqXEqiFzDmAl9J8TIHDHIxel CiIAyit35nbqEQAlMKGPBTDA4PwPAfIQGOjUoB4LYLBhZlUPKMDoZxEYzESaU0Dcpw7MAPd9PQAg uRYgPNL7jsd8MIiJJQfla3LYI6giaCoMdnWpkrVGRKgwn+cgfZkqQR7rF5goKJitMSElImIiKieW NIyPVjKnRdUi2aJ3BLGmx4qMEDER+0BxZAafKnuXFrrOzM58cvXK1My5zFFtKw2aa0YeIEGiCH/+ lX50taYhgHRpbT+ORCkMVaKZqeG/tx+8MBP3zvvvf7j28ZWVyeeeZzHOEbEAhpgZBhAIO480Cxq8 Bm9FrSjIR5Y2avVxc+O9y5eiKEL3yllcXPzym18ae5kIq5IP+QGW753iZiBSyudrAMMKna4+8/qr L5fL5Z6u7kjTNF/2xGsNgDFGpNfHfwYAQFicrB4gTtcAAAAASUVORK5CYII= ------=_NextPart_000_0234_01CD7546.13BF3130 Content-Type: image/png; name="image005.png" Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAABkAAAAZCAIAAABLixI0AAAACXBIWXMAAA7EAAAOxAGVKw4bAAAK T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3 AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+ 5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk 5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd 0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA 4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5 h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+ Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY /R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1 mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/ 0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5 hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9 rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7 vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO 32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21 e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i /suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8 IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq YAAAOpgAABdvkl/FRgAABGlJREFUeNqslV9sFEUcx38zu/dv7+pde+1dbZGYtrRgY8WKsWmLxIgx 8oQPxsQXX8REjApEQozRJ1+QxDTUqFUeJEajJiZGjIYCpQjYitJSKE1aiqHtdWnT+7+319vdmd/P h20PQqqBxMnnYWdmf9/5/mZ+O8uICP6nppafzIvDhfOnS/Nzd6+tBgLB1s0V23eolVEAYK6v9E/f Z8+dXpaoMOCM3aWWQGIMQsFg7NW9vvoHOACUErOZswMFITWFexlDIf4NFcDLWBlN4QpArlDI9B8j IpWI8mN/lYRUgTIO+Ftaqzc/5tGCd1i4OfRbYeRCzX0VRJQxi/5HtpRSS5WZJQ9jlsDC1bGoEFxK aVm2IDJDkcbd+6x0aubLz6aOfJyenAhvaAlvaDHmbmQmJ4yRC9GKEBIhERHUdm6NNG9yu5yBJLIs i0spbcdGorY9B/SBfu9iIhLUqjyKMdg/d+o4EcU7uhfPnKwKBd1IJCJYOZ7yCCI5jqMSESIhker3 Zy8OuzEAEPB5F/t/ru3oVAPa+udfTP34neWI6PbnAKAKwB+tiTRDFgAA5PQUX0wQkQoA0rbcxRTG EW+VhEeK5KWR2o7uSFPLvO0AQKR502o1aK4cANiZjD0zvVJfdiqZvjRCjm3o8/5YjRqqcAN8qlpK LgGiv7KKAAJez0xfDwAsW87GN/enJ65kjv0gCkbRyHsde52rRURCOCClt25d7uoo50wJaExReEBj uSxJsTD8u72gKz4vAMjlomkUHCNfvKnbc38DAEqUjAEAd7UkESFufPmVdMGUSLZpWvl8LpEgIchx xj/tweRiUU8U9YSVSdv5XHpi3NQTEmkForIWkCTHyEcamx/a805WQrFkF0s2xuvrurcNvfu2sjBP BIjk4vd65z4/bAyecLuEhJJW9guBJNHxl3a2vvZWXde2+7uezE1PAUC4qfnsvt18YV5VFXn7FcCY oioA4A5KIg5wK0ckDDGc6j108oUdv+x8xjby1W2PZq9NSn2WK2zV0NpIQkkIq3sPbr15FMWjKEBU 17kVCLVY3FG8qhTsP792QkJ2my+J6GILgUQTR48QohaLdx7sgXi9LUT5hTXBsi8EQiJb9dQ83hlu bNLitbnr046R94RC4YbGroM9V/p6F8+cUlVlTV+SiGP5LiRAhKe/+FofOjf5zVE7uQQA17/9Slv/ YMf7H2jx2va9B4YNIzvyJ+dsrRwB2WpNIBEiXu7rvXz4kMykFIW7lOZnB9/YNdP/KyC17XrdFs7a OdJKjhwA1OqYAnBj4ATjXBKVQSK0SqM9H5oLuhaL+apjt8+6CKSSRBbQGGMcACId3Z6AfxnJFFJI vKMBY0tjoySlFovfMWVJmXOEByj41LOcc2ZZVjKZHD/Vn/rkIyubdvAefkucgY8xb/sTzfvfa2ho YFLKfD6v6/rstancH+dFaunutRhjvofb69q31NfXx2IxRkSWZWWz2XQ6bZqm4zj3pOX3+8PhcDQa DQaD/wwA2uRn79BoYwAAAAAASUVORK5CYII= ------=_NextPart_000_0234_01CD7546.13BF3130 Content-Type: image/png; name="image006.png" Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAABkAAAAZCAYAAADE6YVjAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAK T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3 AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+ 5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk 5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd 0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA 4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5 h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+ Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY /R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1 mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/ 0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5 hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9 rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7 vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO 32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21 e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i /suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8 IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq YAAAOpgAABdvkl/FRgAABPtJREFUeNqklktsVdcVhr+1z7n3XNsXjKu4KK4boZYAsYqSGlAUBhHt JGEAaSgZVGr6SFLFHaCo7YxRKwZ9zPrIQ3kI1UhWCx1UkVAgSUFVW5UUW0auHeoOrDoP+jBGvg/f c8/Ze6/dwbn3FgKDFJb062hvaa3/rMe/9xY6pqrfB77uvd/CHZgxBhH5LfADY8wlAAHw3p93zu3L sowoihCR2yZxzhFFEUmSrAFfiOP4Etbab7Tb7bC2thbyPA/W2mCtDYcPHw6Tk5PhzJkzYf/+/b39 j4NWqxXq9Xqw1s4CxKr6pXaWUalUAAghADA+Ps709AybN29mZGSkt/9xLI5jsjzHOffA6rVrw8Z7 P+S97/alh/vGxrhw4c+8884F9u3bx5EjRzhw4ADHjh1jbm6OgwcPMjU1xdGjR2/w6yKOIqx1JOXy 54xqIGhAP4K9e/fSarVYWlpiYKDK/Pw8hw4d4ty5c1jraDabZFlGq9W6yVc1AIJXj/eK0aCEW6A6 MMDY2BibNm1iePgu6vU6Y2Nj1Ot1nLM0Go0eya38NShBAyEosXpFNeBVb6ptmqYMDQ1hbRH0+m+t ViNN2zSb67f0LeIqYIhza8nynCRJbhrdNE0B6Ovrp1arMTU1Ra1W65GcP38OESHojUMRCDjvsLlF jBB777F5TpbnAIhID1u33gsCO3bsYOfOnRw/fpyJiQn6+vsZHBwkLpUYHR3FOUcIAQ2hN4XOOZyz RFGMfHjln79vtVoPV6vVQrGXZjGnTiLNJgjI0hK0WmAMEsdQKiOVBOnrg2oV2b4DtmwhrK7iowj7 +JcJ1WqHxBHH0Rdj7z1dmH//i+Q7z9FLXgREkCiCOEbimFAuIUmCqVaRoU9gBIz3mF27MaOfovab U6RPfq0XU0SIr5/t5OxZIjFUF97t1ddfvEj61DfBOtBA+elvEe3ZQ/t730XSDJrrhLUaunIV7rmH /pX/sP4RzRjv/7cAiKKI/Omn0MVFdHER+5MfF2Us1IpRRYISj34a06gjq1cx5QRxjjA3h1y5cgOB 91pk4jsAiI2BmRmk0SjWg4NU/jqPf+klZPduwvQ0ZnwXyeQkevo0/o9/oPTDHxVZnziBLiz04nlV RHxBEryiXpFOJr1+dI5uANNZiwhhZgb+vohs2078xBOE2VkQMA/cj7z2WqGRLkSIvXp80OIICAHf GcG4037tlEo790IADAGtN4oSBpDxzxf6mJ3FZ228elR9US6VQvG+w5o5R9NaADZ0BJY6xwYgV08c Ak49JQ1Y9ZS6Sp++SPb66yCGPE3pxvSq4AVTNKhgzZylmWc086zILihph9Ts2o0PSu49MjIC27bh g5J98D5y9wiVZyfQz36GZju9rvFFRrH3incFczupYF0RtH9hAYDa8j+ovHkW36ij9QbZ8jKyME+0 cZBrp06RXX6XuwYGALh68tdkNsd7JbcWEUF9QP5yceaEde6r5XKJaHUV99y3Cc31275+o8ceJ3pm gmazSX9/P5cvXx6W02+ceXR4+JNvtNbXqfT1Ie8tk039krD+/xPFO++n/JUnabdTjBhMFP3poQf3 PCxA/Nbb51/csHHDM+12G1W9o4dECIGkXEY1/O3kyV898vOf/fS9brTkF8+/8Ni927Y/G0VmI+EO 3kQirKysvPm7t9965dVXXl4GwvW/bIAEKHWfSrdpHsgA29347wAa+pFmyNu48AAAAABJRU5ErkJg gg== ------=_NextPart_000_0234_01CD7546.13BF3130 Content-Type: image/png; name="image007.png" Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAABkAAAAZCAYAAADE6YVjAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAK T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3 AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+ 5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk 5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd 0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA 4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5 h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+ Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY /R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1 mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/ 0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5 hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9 rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7 vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO 32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21 e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i /suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8 IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq YAAAOpgAABdvkl/FRgAABYNJREFUeNqcln2MnFUVxn/nvu/MO++8M9ttt7PbLl2bFmy70BYsDWKl hS6iqxS6WBMoFAkBEhKJmKxR1Aj4WQwx1rRaIF1TjApS04i6pFi+6bYQ6+IHtRZYFWvZXXe7ndmd mff7Xv/otqgEm/Ekz73/Peee+zz3nCsAy7yZ/GD5ZSs6ijNurxp9UYpxAUPjIRZSL4p66XfHR394 1eCeA5Ex2AAXzWpb3zaj+Sf/MEneYLAaohVMnGCiCETQOYeymAs6S3NuvbFjya19fz/8sLTnvNKe VetfjbNWq6eFgqjGEgQhVluJ/OoL0dU6/v5BKvU6NUtoNlL76MDjy+zVs+Z+qJDLtdaSmKIo0gaK MGFEZmEHpW9+FrttNgB683aKTzwPeQeVyXiXl+ats1ud/NwYgycK3agCxtB823XYrS2c+P6P0OVJ nOVLUJkM8eN7iZtsCplsh9IYAyANEJswwtQDVN4lu2gBydFhKn27sOfNobCui6ZPXoPdVsIkCakx RjV08lRjkgTnvEXkVi5F+wHJ0bew2ltxli+h/uzL+Pt+i9Xawsw7bwKtwXDSXWJZCALaMF3YO0Mb sBQtvbfgda8BoP7MAWpPH8A5v5PZX76D8oOPoJo89PEyydFhlOMABjsZGdNVjlBsmYUqFsDJIkqB TOc7uWCCkKYb1uN1r8HfP4jV3ES+6wPoWp3qr56hsK6L0rc+B8D4XfdzYveTVNOYeGQM20Qx/tER MsfGME4WybuI56LyLuI6SDaL2DYmSXFXrcAEIeN3bwElzNmxGa/7Ut7aeCe1X+8ju3gh9af3U+t/ lgQIdIohwkYEsS0QhYkT0hOTMFE5qXEcIFYWcXOYMCA5NorTeQ46CJkaeApnayet998Fohjfug1F HrCwcjkQEAWkgtICqRhSMSQKUltIbUUimsK1V5O9+HyiWpU4DinvegKUMPsbvVjzF2IvmAdAVC6j pYDOe+h8jkRBMs2pATvFEKOJp02sjUH7NfIXLKXj0e9S3XeQ17quA3H45493U7jmCmZ8bC2dr78E GYvKnucpD/wGcs7pdidAgiHCoDEojSEWiJQhTGPCOMR67wKmhv7G1MBBCpesxLvqcoKoju/XOLLx U4zueJRweITRHY/w2qZPE6UJsYJYzDuQAnY6ncD3fXJennO2fJ3Sxh7Gf9bPm/dtY+kvd3LWl+5g eHc/pZ5u2q7v4c839yLZDOlUFbEtJJuBf+sXb1eiScWgEiBIItT8uZz78z7abr6WpF6nddPHmTh0 mGMPP0ZhxTI6dz3IuY89wKyejyDz51KbrBDlMkQZi1A0oZjTCKb3SAwpBpWYlFAM5+3cwsy1q3i1 9x4O9d4LwJLvbWbshQPEE2XaPnElwfAoA10bmHhjiNhzCJUhEP0uOJkoEYO1OONevCDW3e7MZto/ vBZxssy7YQPVN/5KyyXvJ9s+h5GnngMRXly/ieN/OASee9qR74ZEDD6aI2kwYCdiiPMOf3poJwuv 30Dpsg9yeHsfg1/4Gj1/HKC4+Gyeu/E24vIUYaWCPSNPYs7crw0QokkElMao0BImgyovf/U+AFre t5w1P+3D6ziLV769ldGhIabqU8RuFp+UQM4MX1J80aQYsSfR1UQ0oZfj9T1PsugX/Zx99ZUAvPjF exj8zjasoosW9R8O+l+hgJrRGIFQ9KTlGx2udPO3VEhtrTWVob8w/9LV7O39PAcfeAhV8NCWkGLO qMMpVEUzoVMcS0x/ffJeAVidL3zlCq9wd0WniDZ4xSK18XFs1234u5JgMECzsnihXtu2tzb1mVMD 0VmWy91+oevelFPyniRJlVhWA+Py7UeokDTQ+s3fB8GuV3x/OzD53zTtrlKl6Wv9f0P7Wo8BI6dE /NcAQhbE7cZc9jcAAAAASUVORK5CYII= ------=_NextPart_000_0234_01CD7546.13BF3130 Content-Type: image/png; name="image008.png" Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAABkAAAAZCAYAAADE6YVjAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAK T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3 AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+ 5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk 5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd 0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA 4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5 h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+ Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY /R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1 mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/ 0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5 hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9 rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7 vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO 32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21 e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i /suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8 IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq YAAAOpgAABdvkl/FRgAABUxJREFUeNqklk9sVNcVxn/3zbw3HjODwVGBpKocBBlinOIumiiQJsiu J1GahD9JqrTAoqWC0kVLAi1Gatw4sruAgLuoIhZNm0VVlHhs6tDQAPkDVQAvqFRCqkCwOnIlaGrj EjP2m/fmzb33dDGD04g/dttP+hZv8c53v3O+8+6DKnpzuSdF5INSqWSDIJD/h1rrT8fGxl5pbW2t v1afDRs2rImiSCYmJsT3fQnDUIKZMggkiiIRESmXy1IMApmYmJByuSyDg4PH0+l0TSyVStXs37+/ t66u7gtKKVzXRSkHZ0ZUeJ6HiLBr1y4WLlzIbfW34TiKIAhYtGjRncPDwxfiDQ0Ni+bPX7Akisp4 novWBqW4NQRQEI+7jI+Ps3HjRgYGBrh8+TI9PT1Ya/E8D2stDzzwtTbHcZxarcsOCoyxWGsxZhpa i+t6oKBYDDhy5AgA+/bt4+zZs7iuh7WC1oZkMlnriIgYY8VWBWbCRCLB0bePkm1ro1Qqkc1mmT17 NqVSiY6OjopZEay1aKPFufbw3wicPHmCNatXc+zYMdavX8fddzdSW1tLNvswBw8e5NAfD1GTrMFa i1jBATDG3LSosRZjDU4sxqxUCteNc1cmw7x583Ach3PnzvHqq7/hypUrtLa2kE6n2dnezuTkJAKV d0WEIAwJw5CoXEYbUy38+dP/49Il2tt3sGnTJkZHRtm1ezfWWh5auZI5c+YSRRHDw39n+/btPP74 E2ht8H2fqBRJXETQWlPWGqn2UimFAlCKRCLB0NAQT65dSz6fryxuby/9Bw7Q0trKn44fp6fnF3R0 PM8777zN+ydO4HkJgiAAwFpLXKrtMsaglEJEPpfWRCJBz94e8vk8L+3Zgz/p09n5Atuee46fvdDJ N59+itdef41fvfJrtNaIUGlV9bBWLHFEpqKplEXE4jgOyWQSx4mhlOL8+fN4nseqVau5444vcubM GQYGfg/At9et468ffsjSpiZqk0l8368sEVREjOAIYK3B2Iobqm76cn307N3DRx+dI5PJEEURBw70 k5qV5OttbQAMDw/T2fkiv/3dfhRQKExMBeUarZiqE2sxxhBzYlhj2blzB/19fQDkcjm6un9OLtdL d1cXWhsOvfkmAIsX30Vt7SwcJ0YYlq4ZmIJSCmuFOIA1Fmss7iyPI4ffor+vj1WrVvPggw+x4Pbb aWlpYceOdrq7u+h4/qcAbN36LMual1EoFG769amIWOIinw0eYGhoCIBHHn2UZ575FqMjI2zZspl7 7vkyA2/8gcHBUzQ2NrJ8+QqKfvG6oNxQBGRKJIoiGhruBKA/l+Oxx57gnyMjvDEwQOFqgc2bt7C0 qQmtNX6xCLcQuIGTSrqKfpHlK1awdGkT7733Lj/58TbS6TQAmSVLKAYB/uQkM8VnIshUuqJyRE1N kj17e/jBlu+T630dgK/eey/r12/A9yen2jq9AigUIqLiqrrkuqxxHIdC4SoXhi7wy5dfZvDUKVzX oy2bJZlMEpWi6xJ0qztHKYXWRpyxsbFP/KL/aVlrXNfl6OHDPPujH/Ln06f5zne/x5q1a4nH4oRh WI369LRWCMIAJxYjn8//LRaG4UTdnDlfuv/+5feNj18lUZPg0sWLrGxpJZVKERQDjDGIFcTaaWmt pVQKicfjFAqFwt6Xdm+LAZz94Mzp+vr6xZlMpnHu3LlkH36E+fMXUI4ipr+LrxsFXsJjbOxfn3R3 vbj144/Pv/ufFeqam7/yjWXNzfe5rps0xgr/AxzHkdHRkYsnT7z/1vj4+F/gxmOMMfPx3syMrv5u APDvAQA0od/2coVKtQAAAABJRU5ErkJggg== ------=_NextPart_000_0234_01CD7546.13BF3130-- From lufang@cisco.com Wed Aug 8 01:16: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 4113621F8673 for ; Wed, 8 Aug 2012 01:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.83 X-Spam-Level: X-Spam-Status: No, score=-8.83 tagged_above=-999 required=5 tests=[AWL=-0.652, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkNFtJnJLq1u for ; Wed, 8 Aug 2012 01:16:11 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 288FF21F8668 for ; Wed, 8 Aug 2012 01:16:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=113670; q=dns/txt; s=iport; t=1344413768; x=1345623368; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=dK2ZclDMZMGqag6gnLdc3ngeMM5R1rSdpb/I0BjJnJY=; b=U5ndM3R+XL0DKnasRKtsNzFOutTR6FS/RkkpSdkQNX3MMeQbcR/EwRTm KPqZZpSpP1uEhbXKHHi4pueeKVeyEreL4tF3cVvGHopAHLTK8r6ntsMBA HvIDQcdJ+tC+4/SJ4Y6W68XjiiLdzPmzBHktFwAtia5tszRlyxFGDw2I+ Y=; X-Files: image001.jpg, image009.gif, image010.png, image011.png, image012.png, image013.png, image014.png, image015.png : 35434, 1408, 3853, 3749, 3902, 4048, 4184, 4129 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFACEfIlCtJV2Y/2dsb2JhbABCA4JKrkgBiFaBB4IgAQEBBAUNARIIATYlAgEIEQQBAQYBAQECCA4BBgcCBRAGBwIMFAkIAQEEAREBCAYUh2sLmnKgOYsPgz+CQWADjFmDHwEBToYUgiWKbYFmgl8 X-IronPort-AV: E=Sophos;i="4.77,730,1336348800"; d="gif'147?png'147,150?jpg'147,150,145?scan'147,150,145,208,217,147,150,145"; a="109276950" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 08 Aug 2012 08:16:07 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q788G7lB021933 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Aug 2012 08:16:07 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.155]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0298.004; Wed, 8 Aug 2012 03:16:07 -0500 From: "Luyuan Fang (lufang)" To: "adrian@olddog.co.uk" , "'Shahram Davari'" , "mpls@ietf.org" Thread-Topic: [mpls] draft-ietf-mpls-tp-use-cases-and-design-02 Thread-Index: Ac109rZq2Pfvls9SQTu4EKif2qQJBQACDt+QABoqCIAACnBuMA== Date: Wed, 8 Aug 2012 08:16:06 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD930F4C9F44@xmb-rcd-x03.cisco.com> References: <4A6CE49E6084B141B15C0713B8993F2806E252@SJEXCHMB12.corp.ad.broadcom.com> <0DB8F45437AB844CBB5102F807A0AD930F4C9E61@xmb-rcd-x03.cisco.com> <023301cd753d$b1f3eb60$15dbc220$@olddog.co.uk> In-Reply-To: <023301cd753d$b1f3eb60$15dbc220$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-cr-puzzleid: {E0103577-AC7E-472E-846F-3B1F5716CABC} x-cr-hashedpuzzle: AYZ0 C0GQ H32x JbNM Js/r LJzN LKCH LQg1 Lwg0 MbEQ Mi0W N00w OlLD QrrF RcdC VY/c; 3; YQBkAHIAaQBhAG4AQABvAGwAZABkAG8AZwAuAGMAbwAuAHUAawA7AGQAYQB2AGEAcgBpAEAAYgByAG8AYQBkAGMAbwBtAC4AYwBvAG0AOwBtAHAAbABzAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {E0103577-AC7E-472E-846F-3B1F5716CABC}; bAB1AGYAYQBuAGcAQABjAGkAcwBjAG8ALgBjAG8AbQA=; Wed, 08 Aug 2012 08:15:42 GMT; UgBFADoAIABbAG0AcABsAHMAXQAgAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBtAHAAbABzAC0AdABwAC0AdQBzAGUALQBjAGEAcwBlAHMALQBhAG4AZAAtAGQAZQBzAGkAZwBuAC0AMAAyAA== x-originating-ip: [10.21.126.236] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19092.004 x-tm-as-result: No--54.963300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/related; boundary="_011_0DB8F45437AB844CBB5102F807A0AD930F4C9F44xmbrcdx03ciscoc_"; type="multipart/alternative" MIME-Version: 1.0 Subject: Re: [mpls] draft-ietf-mpls-tp-use-cases-and-design-02 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, 08 Aug 2012 08:16:15 -0000 --_011_0DB8F45437AB844CBB5102F807A0AD930F4C9F44xmbrcdx03ciscoc_ Content-Type: multipart/alternative; boundary="_000_0DB8F45437AB844CBB5102F807A0AD930F4C9F44xmbrcdx03ciscoc_" --_000_0DB8F45437AB844CBB5102F807A0AD930F4C9F44xmbrcdx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sure. Thanks, Adrian. Luyuan From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Wednesday, August 08, 2012 1:13 AM To: Luyuan Fang (lufang); 'Shahram Davari'; mpls@ietf.org Subject: RE: [mpls] draft-ietf-mpls-tp-use-cases-and-design-02 I will include this point in my AD review and you can fix it in the respin = that will be needed. A From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Luy= uan Fang (lufang) Sent: 08 August 2012 02:57 To: Shahram Davari; mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-tp-use-cases-and-design-02 Shahram, It is a valid point, thanks. We can replace "PHP as optional" with "PHP must be disabled by default". I assume we can make the change through RFC editing process, Loa can help t= o confirm if OK. Thanks, Luyuan From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Sha= hram Davari Sent: Tuesday, August 07, 2012 4:45 PM To: mpls@ietf.org Subject: [mpls] draft-ietf-mpls-tp-use-cases-and-design-02 Hi, I am not sure it is late or not, but I found a discrepancy between This dra= ft and RFC5960. This draft says PHP is optional for MPLS-TP, while RFC5960= says PHP MUST not be used. Is there any way to correct this before IESG publication? Thank you, [Description: Description: Description: Description: Description: Descripti= on: Description: Description: Description: Description: Description: cid:im= age009.jpg@01CD505E.7B800DB0] Shahram Davari | Technical Director, Network Switching Group Broadcom Corporation | (O) 408-922-7436 | (M) 408-660-5695 [Description: Description: Description: Description: Description: Descripti= on: Description: Description: Description: Description: Description: Descri= ption: Description: image005][Des= cription: Description: Description: Description: Description: Description: = Description: Description: Description: Description: Description: Descriptio= n: Description: image002][Description: Desc= ription: Description: Description: Description: Description: Description: D= escription: Description: Description: Description: Description: Description= : image003][Description: Description: De= scription: Description: Description: Description: Description: Description:= Description: Description: Description: Description: Description: image004]= [Description: Description: Description: Description: Description: Des= cription: Description: Description: Description: Description: Description: = Description: Description: image006][Description: Description: Description: Description: Description:= Description: Description: Description: Description: Description: Descripti= on: Description: Description: image008][Descript= ion: Description: Description: Description: Description: Description: Descr= iption: Description: Description: Description: Description: Description: De= scription: image007] --_000_0DB8F45437AB844CBB5102F807A0AD930F4C9F44xmbrcdx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sure. Thanks, Adrian.<= o:p>

Luyuan

 

From: Adrian F= arrel [mailto:adrian@olddog.co.uk]
Sent: Wednesday, August 08, 2012 1:13 AM
To: Luyuan Fang (lufang); 'Shahram Davari'; mpls@ietf.org
Subject: RE: [mpls] draft-ietf-mpls-tp-use-cases-and-design-02<= /o:p>

 

I will = include this point in my AD review and you can fix it in the respin that wi= ll be needed.

&n= bsp;

A<= /o:p>

&n= bsp;

From: mpls-bou= nces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Luyuan Fang (lufang)
Sent: 08 August 2012 02:57
To: Shahram Davari; mpls@ietf.org
Subject: Re: [mpls] draft-ietf-mpls-tp-use-cases-and-design-02<= /o:p>

 

Shahram,

 

It is a valid point, t= hanks.

We can replace “= PHP as optional” with “PHP must be disabled by default”.<= o:p>

 

I assume we can make t= he change through RFC editing process, Loa can help to confirm if OK.<= /o:p>

 

Thanks,

Luyuan

 

From: mpls-bou= nces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari
Sent: Tuesday, August 07, 2012 4:45 PM
To: mpls@ietf.org
Subject: [mpls] draft-ietf-mpls-tp-use-cases-and-design-02

 

Hi,

 

I am not sure it is late or not, but I found a discr= epancy between This draft and  RFC5960. This draft says PHP is optiona= l for MPLS-TP, while RFC5960 says PHP MUST not be used.

 

Is there any way to correct this before IESG publica= tion?

 

Thank you,<= /span>

 

 

 

Shahram Davari | Technical Director, Network Switching Group
Broadcom Corporation | (O) 408-922-7436 | (M) 408-660-5695<= /p>

 

3D"Description:3D==3D"Description:3D"Description:<= img border=3D"0" width=3D"25" height=3D"25" src=3D"cid:image013.png@01CD750= 3.53899690" alt=3D"Description: Description: Description: Description: Desc= ription: Description: Description: Description: Description: Description: D= escription: Description: Description: image006" v:shapes=3D"Picture_x0020_4= ">3D"Des=3D"Descripti=   &nb= sp;     

 

 

 

 

--_000_0DB8F45437AB844CBB5102F807A0AD930F4C9F44xmbrcdx03ciscoc_-- --_011_0DB8F45437AB844CBB5102F807A0AD930F4C9F44xmbrcdx03ciscoc_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=35434; creation-date="Wed, 08 Aug 2012 08:15:59 GMT"; modification-date="Wed, 08 Aug 2012 08:15:59 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4RSrRXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUAAAABAAAAYgEbAAUAAAABAAAA agEoAAMAAAABAAIAAAExAAIAAAAeAAAAcgEyAAIAAAAUAAAAkIdpAAQAAAABAAAApAAAANAADqYA AAAnEAAOpgAAACcQQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2gAMjAxMjowNjoxNSAxNjox Njo0OAAAA6ABAAMAAAABAAEAAKACAAQAAAABAAABCKADAAQAAAABAAAAOgAAAAAAAAAGAQMAAwAA AAEABgAAARoABQAAAAEAAAEeARsABQAAAAEAAAEmASgAAwAAAAEAAgAAAgEABAAAAAEAAAEuAgIA BAAAAAEAABN1AAAAAAAAAEgAAAABAAAASAAAAAH/2P/iDFhJQ0NfUFJPRklMRQABAQAADEhMaW5v AhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAAAAAAAAAA AAAAAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQAAAIEAAAA FHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRtZGQAAALE AAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAAJHRlY2gA AAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAAQ29weXJp Z2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJzUkdCIElF QzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAA AAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeFAAAY2lhZ WiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAA AAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29s b3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29s b3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxSZWZlcmVu Y2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVmZXJlbmNl IFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlWAFAAAABX H+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBjdXJ2AAAA AAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABtAHIAdwB8 AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsBAQEHAQ0B EwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHBAckB0QHZ AeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsECywLVAuAC 6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQTBCAELQQ7 BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYFtQXFBdUF 5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZB6wHvwfS B+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J5Qn7ChEK Jwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1DI4MpwzA DNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14Peg+WD7MP zw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLDEuMTAxMj E0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwWjxayFtYW +hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqeGsUa7BsU GzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMfPh9pH5Qf vx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQfJE0kfCSr JNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWspnSnQKgIq NSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9aL5Evxy/+ MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1wjX9Njc2 cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8JzxlPKQ84z0i PWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31DwEQDREdE ikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtTS5pL4kwq THJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19TqlP2VEJU j1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1XIZc1l0n XXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1lkmXnZj1m kmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8eb3hv0XAr cIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5iXnnekZ6 pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQdhICE44VH hauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaPnpAGkG6Q 1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtCm6+cHJyJ nPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSp N6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYB tnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD 1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+ 0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4Dbg veFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M 8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+S/7c/23/ ///tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8V GBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4O DhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgA IwCgAwEiAAIRAQMRAf/dAAQACv/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUB AQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJx gTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePz RieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYF NQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNU oxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//a AAwDAQACEQMRAD8A9Re1vJA+JMIZcAfa8DzDz+Rwc1GeYEyGjxd/qEPc48Oe74AAf9Mf9+SUptzg AXDc09xH97mf9JAxesdMy82/BxshtmVi/wA/UJluu06kbX7HeyzZ/N/4RG2O3A7XT3JDf++FrlxH 1aeWdZxM5oh3VW55J8dt3q6/9tpspUYjv/6L/wB02eX5eOTHmmSQccbhX7/DPL6v+p4cj3ySCzIB 0f7T49kXlOay6SSSSlKL3hvOpPDRyVE2SdtY3u8ew/rOQ5kF4dp+fb/3ypJS7nPMyYj6UGGt/rP+ k5yh+kkbXODjwOSR47H/AEG/11KD7QG6811+H/CWJaQZ9zSYce73fuN/kJKY+vkMiQ2xp4Ils/8A Vf5/82pNy5Gtbh5iCPyhOGFziHGT/hT2/k1D+SnfSRqzj93/AMikpk29juxb8Qp8qqDEjuO3+u3/ AF/0X84ptsLT8e3+v53+r0lNhJMCHAEag8J0lKSTFwBidfBJJT//0O4+ufVsro31bzupYbR9qpa1 tDiA4h9j2UBwYZ3bPU9RcC768fXk1OcxxczGl/2j7I0V3V2X1YeFY7e5jn03Odb+kwW+r/wP6Oy5 eldT6f1PLsZ9k6k/Bp2lttbKmPc6T9Jltvupdt/cVP8A5o4VbfVxcnKp6gIP283Pssc4cfaK7HfZ 7mf6Sr0kCT0H4s0MeIxBnm4Sf0YwlPh/2p/V/wDjXvPFV/Xr6w+tY/0hkZF4uxn9LZh2RhZTXGrC rfktbbbm2X1MtzMmn/RU2ekxVMf6ydatf0ijplNDM/GxiacL7I8l+W/KuxMyqfY3Apdi1fbMm176 fT/8893f0z619Q2Yefl41OCHg3XYnqsyLWN/wbtx9On1v8J6b1r9VwD1Hp92G25+M60ey6okOa4H cx3tLdzdw97N3vQu79O21pMBAxj7wqZ9ft8Uowh8nFL5eP0Tyej/AL986b9devuoys71W1Fj/SzM CzCtLelt9b7OzIvzGN/XbWUfp7aLP+t0/o7GKtZ9evrnhbB6TsrHbXea8sY3pHJZYMgdKz7aCG/Z m78Sy/0v0fq4q7lmB9bspjcXPzcfGxwALMjCD/tNgHt+ncPSxnP/ANJUz/i0rPqnj0H1+l5OTg5U 7nXMtdZvd/3ZpyXPqyP/AANLiPSP26JOHFHSWePEdvbjLJj/AOqT9HD/AIEMqT6r9Uv6h0PFuy7z bmtrYMwlgqi5zGZLq9lldbfZVkVfzX6NaZcD9Jwd/WdP/QrG1yrYFOdRSa83MOdcXEi01tpIbA/R +lU6v8737lak8Q773j/vqcPsYJAAkCQkB+lHi4Zf4/BJcgkajc0dj7GD+z9JKSfdO4j886Mb/VH5 3+v6RNGsxr2Ja5x/znpO0ILuexsI/wCjWxJCtIJkhjvpPP0nn91qeHbhAAfHtb2Y3x/rJ2te4yJn /SP7f1GIjGBogd9STyT5pKU1oY0NHZSSSSUxfWx/0hPgeD96AcV4+hZ8ngH8m1WUklNQOyaT72yw 8ubLo/lfvIjX7xO6QeDOn/R2f9UjobqW7tzPa48xwfiElLNj4eQgf9TKmDHw+5R9w5/Cf70+vYH7 o/6pJT//0fVUl8qpJKfqpJfKqSSn6qSXyqkkp+p7PoH6P9rhCZtnXb/1uf8Avq+XUklP1G/Z2/6e 6E9HJ/m/7H/fl8tpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp//Z/+0dyFBo b3Rvc2hvcCAzLjAAOEJJTQQEAAAAAAAvHAFaAAMbJUccAVoAAxslRxwBWgADGyVHHAFaAAMbJUcc AVoAAxslRxwCAAACAAAAOEJJTQQlAAAAAAAQbrNy3vn/dsPQ3CJIvyt90zhCSU0EOgAAAAAAjQAA ABAAAAABAAAAAAALcHJpbnRPdXRwdXQAAAAEAAAAAFBzdFNib29sAQAAAABJbnRlZW51bQAAAABJ bnRlAAAAAENscm0AAAAPcHJpbnRTaXh0ZWVuQml0Ym9vbAAAAAALcHJpbnRlck5hbWVURVhUAAAA DABwAHIAdAAtAGkAcgB2AC0AMAA3ADIAAAA4QklNBDsAAAAAAbIAAAAQAAAAAQAAAAAAEnByaW50 T3V0cHV0T3B0aW9ucwAAABIAAAAAQ3B0bmJvb2wAAAAAAENsYnJib29sAAAAAABSZ3NNYm9vbAAA AAAAQ3JuQ2Jvb2wAAAAAAENudENib29sAAAAAABMYmxzYm9vbAAAAAAATmd0dmJvb2wAAAAAAEVt bERib29sAAAAAABJbnRyYm9vbAAAAAAAQmNrZ09iamMAAAABAAAAAAAAUkdCQwAAAAMAAAAAUmQg IGRvdWJAb+AAAAAAAAAAAABHcm4gZG91YkBv4AAAAAAAAAAAAEJsICBkb3ViQG/gAAAAAAAAAAAA QnJkVFVudEYjUmx0AAAAAAAAAAAAAAAAQmxkIFVudEYjUmx0AAAAAAAAAAAAAAAAUnNsdFVudEYj UHhsQFgAAAAAAAAAAAAKdmVjdG9yRGF0YWJvb2wBAAAAAFBnUHNlbnVtAAAAAFBnUHMAAAAAUGdQ QwAAAABMZWZ0VW50RiNSbHQAAAAAAAAAAAAAAABUb3AgVW50RiNSbHQAAAAAAAAAAAAAAABTY2wg VW50RiNQcmNAWQAAAAAAADhCSU0D7QAAAAAAEABgAAAAAQABAGAAAAABAAE4QklNBCYAAAAAAA4A AAAAAAAAAAAAP4AAADhCSU0D8gAAAAAACgAA////////AAA4QklNBA0AAAAAAAQAAABaOEJJTQQZ AAAAAAAEAAAAHjhCSU0D8wAAAAAACQAAAAAAAAAAAQA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAA CgABAAAAAAAAAAE4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAA AAEAMgAAAAEAWgAAAAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAAAHAAAP////// //////////////////////8D6AAAAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAOEJJTQQAAAAA AAACABA4QklNBAIAAAAAACIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOEJJTQQw AAAAAAARAQEBAQEBAQEBAQEBAQEBAQEAOEJJTQQtAAAAAAAGAAEAAAAiOEJJTQQIAAAAAAAQAAAA AQAAAkAAAAJAAAAAADhCSU0EHgAAAAAABAAAAAA4QklNBBoAAAAAA2EAAAAGAAAAAAAAAAAAAAA6 AAABCAAAABYAMwA5ADEAMwAwAF8AZAAwADQALQAyAC4ANwA1AGkAbgBfADkANgBkAHAAaQAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAABCAAAADoAAAAAAAAAAAAAAAAAAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAQAAAAAQAAAAAAAG51bGwAAAACAAAABmJvdW5kc09iamMAAAABAAAAAAAA UmN0MQAAAAQAAAAAVG9wIGxvbmcAAAAAAAAAAExlZnRsb25nAAAAAAAAAABCdG9tbG9uZwAAADoA AAAAUmdodGxvbmcAAAEIAAAABnNsaWNlc1ZsTHMAAAABT2JqYwAAAAEAAAAAAAVzbGljZQAAABIA AAAHc2xpY2VJRGxvbmcAAAAAAAAAB2dyb3VwSURsb25nAAAAAAAAAAZvcmlnaW5lbnVtAAAADEVT bGljZU9yaWdpbgAAAA1hdXRvR2VuZXJhdGVkAAAAAFR5cGVlbnVtAAAACkVTbGljZVR5cGUAAAAA SW1nIAAAAAZib3VuZHNPYmpjAAAAAQAAAAAAAFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABM ZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAA6AAAAAFJnaHRsb25nAAABCAAAAAN1cmxURVhUAAAA AQAAAAAAAG51bGxURVhUAAAAAQAAAAAAAE1zZ2VURVhUAAAAAQAAAAAABmFsdFRhZ1RFWFQAAAAB AAAAAAAOY2VsbFRleHRJc0hUTUxib29sAQAAAAhjZWxsVGV4dFRFWFQAAAABAAAAAAAJaG9yekFs aWduZW51bQAAAA9FU2xpY2VIb3J6QWxpZ24AAAAHZGVmYXVsdAAAAAl2ZXJ0QWxpZ25lbnVtAAAA D0VTbGljZVZlcnRBbGlnbgAAAAdkZWZhdWx0AAAAC2JnQ29sb3JUeXBlZW51bQAAABFFU2xpY2VC R0NvbG9yVHlwZQAAAABOb25lAAAACXRvcE91dHNldGxvbmcAAAAAAAAACmxlZnRPdXRzZXRsb25n AAAAAAAAAAxib3R0b21PdXRzZXRsb25nAAAAAAAAAAtyaWdodE91dHNldGxvbmcAAAAAADhCSU0E KAAAAAAADAAAAAI/8AAAAAAAADhCSU0EFAAAAAAABAAAACY4QklNBAwAAAAAE5EAAAABAAAAoAAA ACMAAAHgAABBoAAAE3UAGAAB/9j/4gxYSUNDX1BST0ZJTEUAAQEAAAxITGlubwIQAABtbnRyUkdC IFhZWiAHzgACAAkABgAxAABhY3NwTVNGVAAAAABJRUMgc1JHQgAAAAAAAAAAAAAAAAAA9tYAAQAA AADTLUhQICAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABFj cHJ0AAABUAAAADNkZXNjAAABhAAAAGx3dHB0AAAB8AAAABRia3B0AAACBAAAABRyWFlaAAACGAAA ABRnWFlaAAACLAAAABRiWFlaAAACQAAAABRkbW5kAAACVAAAAHBkbWRkAAACxAAAAIh2dWVkAAAD TAAAAIZ2aWV3AAAD1AAAACRsdW1pAAAD+AAAABRtZWFzAAAEDAAAACR0ZWNoAAAEMAAAAAxyVFJD AAAEPAAACAxnVFJDAAAEPAAACAxiVFJDAAAEPAAACAx0ZXh0AAAAAENvcHlyaWdodCAoYykgMTk5 OCBIZXdsZXR0LVBhY2thcmQgQ29tcGFueQAAZGVzYwAAAAAAAAASc1JHQiBJRUM2MTk2Ni0yLjEA AAAAAAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAPNRAAEAAAABFsxYWVogAAAAAAAAAAAAAAAA AAAAAFhZWiAAAAAAAABvogAAOPUAAAOQWFlaIAAAAAAAAGKZAAC3hQAAGNpYWVogAAAAAAAAJKAA AA+EAAC2z2Rlc2MAAAAAAAAAFklFQyBodHRwOi8vd3d3LmllYy5jaAAAAAAAAAAAAAAAFklFQyBo dHRwOi8vd3d3LmllYy5jaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABkZXNjAAAAAAAAAC5JRUMgNjE5NjYtMi4xIERlZmF1bHQgUkdCIGNvbG91ciBzcGFjZSAt IHNSR0IAAAAAAAAAAAAAAC5JRUMgNjE5NjYtMi4xIERlZmF1bHQgUkdCIGNvbG91ciBzcGFjZSAt IHNSR0IAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZGVzYwAAAAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcg Q29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAALFJlZmVyZW5jZSBWaWV3aW5nIENv bmRpdGlvbiBpbiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHZpZXcAAAAA ABOk/gAUXy4AEM8UAAPtzAAEEwsAA1yeAAAAAVhZWiAAAAAAAEwJVgBQAAAAVx/nbWVhcwAAAAAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAo8AAAACc2lnIAAAAABDUlQgY3VydgAAAAAAAAQAAAAABQAK AA8AFAAZAB4AIwAoAC0AMgA3ADsAQABFAEoATwBUAFkAXgBjAGgAbQByAHcAfACBAIYAiwCQAJUA mgCfAKQAqQCuALIAtwC8AMEAxgDLANAA1QDbAOAA5QDrAPAA9gD7AQEBBwENARMBGQEfASUBKwEy ATgBPgFFAUwBUgFZAWABZwFuAXUBfAGDAYsBkgGaAaEBqQGxAbkBwQHJAdEB2QHhAekB8gH6AgMC DAIUAh0CJgIvAjgCQQJLAlQCXQJnAnECegKEAo4CmAKiAqwCtgLBAssC1QLgAusC9QMAAwsDFgMh Ay0DOANDA08DWgNmA3IDfgOKA5YDogOuA7oDxwPTA+AD7AP5BAYEEwQgBC0EOwRIBFUEYwRxBH4E jASaBKgEtgTEBNME4QTwBP4FDQUcBSsFOgVJBVgFZwV3BYYFlgWmBbUFxQXVBeUF9gYGBhYGJwY3 BkgGWQZqBnsGjAadBq8GwAbRBuMG9QcHBxkHKwc9B08HYQd0B4YHmQesB78H0gflB/gICwgfCDII RghaCG4IggiWCKoIvgjSCOcI+wkQCSUJOglPCWQJeQmPCaQJugnPCeUJ+woRCicKPQpUCmoKgQqY Cq4KxQrcCvMLCwsiCzkLUQtpC4ALmAuwC8gL4Qv5DBIMKgxDDFwMdQyODKcMwAzZDPMNDQ0mDUAN Wg10DY4NqQ3DDd4N+A4TDi4OSQ5kDn8Omw62DtIO7g8JDyUPQQ9eD3oPlg+zD88P7BAJECYQQxBh EH4QmxC5ENcQ9RETETERTxFtEYwRqhHJEegSBxImEkUSZBKEEqMSwxLjEwMTIxNDE2MTgxOkE8UT 5RQGFCcUSRRqFIsUrRTOFPAVEhU0FVYVeBWbFb0V4BYDFiYWSRZsFo8WshbWFvoXHRdBF2UXiReu F9IX9xgbGEAYZRiKGK8Y1Rj6GSAZRRlrGZEZtxndGgQaKhpRGncanhrFGuwbFBs7G2MbihuyG9oc AhwqHFIcexyjHMwc9R0eHUcdcB2ZHcMd7B4WHkAeah6UHr4e6R8THz4faR+UH78f6iAVIEEgbCCY IMQg8CEcIUghdSGhIc4h+yInIlUigiKvIt0jCiM4I2YjlCPCI/AkHyRNJHwkqyTaJQklOCVoJZcl xyX3JicmVyaHJrcm6CcYJ0kneierJ9woDSg/KHEooijUKQYpOClrKZ0p0CoCKjUqaCqbKs8rAis2 K2krnSvRLAUsOSxuLKIs1y0MLUEtdi2rLeEuFi5MLoIuty7uLyQvWi+RL8cv/jA1MGwwpDDbMRIx SjGCMbox8jIqMmMymzLUMw0zRjN/M7gz8TQrNGU0njTYNRM1TTWHNcI1/TY3NnI2rjbpNyQ3YDec N9c4FDhQOIw4yDkFOUI5fzm8Ofk6Njp0OrI67zstO2s7qjvoPCc8ZTykPOM9Ij1hPaE94D4gPmA+ oD7gPyE/YT+iP+JAI0BkQKZA50EpQWpBrEHuQjBCckK1QvdDOkN9Q8BEA0RHRIpEzkUSRVVFmkXe RiJGZ0arRvBHNUd7R8BIBUhLSJFI10kdSWNJqUnwSjdKfUrESwxLU0uaS+JMKkxyTLpNAk1KTZNN 3E4lTm5Ot08AT0lPk0/dUCdQcVC7UQZRUFGbUeZSMVJ8UsdTE1NfU6pT9lRCVI9U21UoVXVVwlYP VlxWqVb3V0RXklfgWC9YfVjLWRpZaVm4WgdaVlqmWvVbRVuVW+VcNVyGXNZdJ114XcleGl5sXr1f D19hX7NgBWBXYKpg/GFPYaJh9WJJYpxi8GNDY5dj62RAZJRk6WU9ZZJl52Y9ZpJm6Gc9Z5Nn6Wg/ aJZo7GlDaZpp8WpIap9q92tPa6dr/2xXbK9tCG1gbbluEm5rbsRvHm94b9FwK3CGcOBxOnGVcfBy S3KmcwFzXXO4dBR0cHTMdSh1hXXhdj52m3b4d1Z3s3gReG54zHkqeYl553pGeqV7BHtje8J8IXyB fOF9QX2hfgF+Yn7CfyN/hH/lgEeAqIEKgWuBzYIwgpKC9INXg7qEHYSAhOOFR4Wrhg6GcobXhzuH n4gEiGmIzokziZmJ/opkisqLMIuWi/yMY4zKjTGNmI3/jmaOzo82j56QBpBukNaRP5GokhGSepLj k02TtpQglIqU9JVflcmWNJaflwqXdZfgmEyYuJkkmZCZ/JpomtWbQpuvnByciZz3nWSd0p5Anq6f HZ+Ln/qgaaDYoUehtqImopajBqN2o+akVqTHpTilqaYapoum/adup+CoUqjEqTepqaocqo+rAqt1 q+msXKzQrUStuK4trqGvFq+LsACwdbDqsWCx1rJLssKzOLOutCW0nLUTtYq2AbZ5tvC3aLfguFm4 0blKucK6O7q1uy67p7whvJu9Fb2Pvgq+hL7/v3q/9cBwwOzBZ8Hjwl/C28NYw9TEUcTOxUvFyMZG xsPHQce/yD3IvMk6ybnKOMq3yzbLtsw1zLXNNc21zjbOts83z7jQOdC60TzRvtI/0sHTRNPG1EnU y9VO1dHWVdbY11zX4Nhk2OjZbNnx2nba+9uA3AXcit0Q3ZbeHN6i3ynfr+A24L3hROHM4lPi2+Nj 4+vkc+T85YTmDeaW5x/nqegy6LzpRunQ6lvq5etw6/vshu0R7ZzuKO6070DvzPBY8OXxcvH/8ozz GfOn9DT0wvVQ9d72bfb794r4Gfio+Tj5x/pX+uf7d/wH/Jj9Kf26/kv+3P9t////7QAMQWRvYmVf Q00AAf/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACMAoAMBIgACEQED EQH/3QAEAAr/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APUXtbyQPiTCGXAH2vA8w8/kcHNRnmBMho8Xf6hD3OPDnu+AAH/TH/fklKbc4AFw3NPcR/e5n/SQ MXrHTMvNvwcbIbZlYv8AP1CZbrtOpG1+x3ss2fzf+ERtjtwO109yQ3/vha5cR9WnlnWcTOaId1Vu eSfHbd6uv/babKVGI7/+i/8AdNnl+Xjkx5pkkHHG4V+/wzy+r/qeHI98kgsyAdH+0+PZF5Tmsukk kkpSi94bzqTw0clRNknbWN7vHsP6zkOZBeHafn2/98qSUu5zzMmI+lBhrf6z/pOcofpJG1zg48Dk keOx/wBBv9dSg+0BuvNdfh/wliWkGfc0mHHu937jf5CSmPr5DIkNsaeCJbP/AFX+f/NqTcuRrW4e Ygj8oThhc4hxk/4U9v5NQ/kp30kas4/d/wDIpKZNvY7sW/EKfKqgxI7jt/rt/wBf9F/OKbbC0/Ht /r+d/q9JTYSTAhwBGoPCdJSkkxcAYnXwSSU//9DuPrn1bK6N9W87qWG0faqWtbQ4gOIfY9lAcGGd 2z1PUXAu+vH15NTnMcXMxpf9o+yNFd1dl9WHhWO3uY59NznW/pMFvq/8D+jsuXpXU+n9Ty7GfZOp PwadpbbWypj3Ok/SZbb7qXbf3FT/AOaOFW31cXJyqeoCD9vNz7LHOHH2iux32e5n+kq9JAk9B+LN DHiMQZ5uEn9GMJT4f9qf1f8A417zxVf16+sPrWP9IZGReLsZ/S2YdkYWU1xqwq35LW225tl9TLcz Jp/0VNnpMVTH+snWrX9Io6ZTQzPxsYmnC+yPJflvyrsTMqn2NwKXYtX2zJte+n0//PPd39M+tfUN mHn5eNTgh4N12J6rMi1jf8G7cfTp9b/Cem9a/VcA9R6fdhtufjOtHsuqJDmuB3Md7S3c3cPezd70 Lu/TttaTAQMY+8KmfX7fFKMIfJxS+Xj9E8no/wC/fOm/XXr7qMrO9VtRY/0szAswrS3pbfW+zsyL 8xjf121lH6e2iz/rdP6OxirWfXr654Wwek7Kx213mvLGN6RyWWDIHSs+2ghv2Zu/Esv9L9H6uKu5 ZgfW7KY3Fz83HxscACzIwg/7TYB7fp3D0sZz/wDSVM/4tKz6p49B9fpeTk4OVO51zLXWb3f92acl z6sj/wADS4j0j9uiThxR0lnjxHb24yyY/wDqk/Rw/wCBDKk+q/VL+odDxbsu825ra2DMJYKoucxm S6vZZXW32VZFX81+jWmXA/ScHf1nT/0Kxtcq2BTnUUmvNzDnXFxItNbaSGwP0fpVOr/O9+5WpPEO +94/76nD7GCQAJAkJAfpR4uGX+PwSXIJGo3NHY+xg/s/SSkn3TuI/POjG/1R+d/r+kTRrMa9iWuc f856TtCC7nsbCP8Ao1sSQrSCZIY76Tz9J5/danh24QAHx7W9mN8f6ydrXuMiZ/0j+39RiIxgaIHf Uk8k+aSlNaGNDR2UkkklMX1sf9IT4Hg/egHFePoWfJ4B/JtVlJJTUDsmk+9ssPLmy6P5X7yI1+8T ukHgzp/0dn/VI6G6lu7cz2uPMcH4hJSzY+HkIH/Uypgx8PuUfcOfwn+9Pr2B+6P+qSU//9H1VJfK qSSn6qSXyqkkp+qkl8qpJKfqez6B+j/a4QmbZ12/9bn/AL6vl1JJT9Rv2dv+nuhPRyf5v+x/35fL aSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKf/2QA4QklNBCEAAAAAAFUAAAAB AQAAAA8AQQBkAG8AYgBlACAAUABoAG8AdABvAHMAaABvAHAAAAATAEEAZABvAGIAZQAgAFAAaABv AHQAbwBzAGgAbwBwACAAQwBTADUAAAABADhCSU0PoAAAAAABHG1hbmlJUkZSAAABEDhCSU1BbkRz AAAA8AAAABAAAAABAAAAAAAAbnVsbAAAAAMAAAAAQUZTdGxvbmcAAAAAAAAAAEZySW5WbExzAAAA AU9iamMAAAABAAAAAAAAbnVsbAAAAAMAAAAARnJJRGxvbmd4CbGJAAAAAEZyRGxsb25nAAAD6AAA AABGckdBZG91YkBWgAAAAAAAAAAAAEZTdHNWbExzAAAAAU9iamMAAAABAAAAAAAAbnVsbAAAAAQA AAAARnNJRGxvbmcAAAAAAAAAAEFGcm1sb25nAAAAAAAAAABGc0ZyVmxMcwAAAAFsb25neAmxiQAA AABMQ250bG9uZwAAAAEAADhCSU1Sb2xsAAAACAAAAAAAAAAAOEJJTQ+hAAAAAAAcbWZyaQAAAAIA AAAQAAAAAQAAAAAAAAABAAAAADhCSU0EBgAAAAAABwAIAAAAAQEA/+EmSGh0dHA6Ly9ucy5hZG9i ZS5jb20veGFwLzEuMC8APD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6 TlRjemtjOWQiPz4gPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0i QWRvYmUgWE1QIENvcmUgNS4wLWMwNjAgNjEuMTM0Nzc3LCAyMDEwLzAyLzEyLTE3OjMyOjAwICAg ICAgICAiPiA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjIt cmRmLXN5bnRheC1ucyMiPiA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4bXA9 Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcv ZGMvZWxlbWVudHMvMS4xLyIgeG1sbnM6eG1wTU09Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEu MC9tbS8iIHhtbG5zOnN0RXZ0PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvc1R5cGUvUmVz b3VyY2VFdmVudCMiIHhtbG5zOnN0UmVmPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvc1R5 cGUvUmVzb3VyY2VSZWYjIiB4bWxuczpwaG90b3Nob3A9Imh0dHA6Ly9ucy5hZG9iZS5jb20vcGhv dG9zaG9wLzEuMC8iIHhtbG5zOnhtcFJpZ2h0cz0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4w L3JpZ2h0cy8iIHhtbG5zOkV4dGVuc2lzRm9udFNlbnNlPSJodHRwOi8vd3d3LmV4dGVuc2lzLmNv bS9tZXRhL0ZvbnRTZW5zZS8iIHhtcDpDcmVhdG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIENTNSBN YWNpbnRvc2giIHhtcDpDcmVhdGVEYXRlPSIyMDEyLTA2LTEyVDE3OjAyOjQ4LTA3OjAwIiB4bXA6 TWV0YWRhdGFEYXRlPSIyMDEyLTA2LTE1VDE2OjE2OjQ4LTA3OjAwIiB4bXA6TW9kaWZ5RGF0ZT0i MjAxMi0wNi0xNVQxNjoxNjo0OC0wNzowMCIgZGM6Zm9ybWF0PSJpbWFnZS9qcGVnIiB4bXBNTTpJ bnN0YW5jZUlEPSJ4bXAuaWlkOkE2NzIxMzBCMzAyMDY4MTE5N0E1QzA4QzdBOUMwODY3IiB4bXBN TTpEb2N1bWVudElEPSJ4bXAuZGlkOkUxNkY4NzM3MzUyMDY4MTE5NDU3RDEzMkQxRDVFMkU3IiB4 bXBNTTpPcmlnaW5hbERvY3VtZW50SUQ9InhtcC5kaWQ6RTM2Rjg3MzczNTIwNjgxMTk0NTdEMTMy RDFENUUyRTciIHBob3Rvc2hvcDpDb2xvck1vZGU9IjMiIHBob3Rvc2hvcDpJQ0NQcm9maWxlPSJz UkdCIElFQzYxOTY2LTIuMSIgeG1wUmlnaHRzOk1hcmtlZD0iRmFsc2UiPiA8eG1wTU06SGlzdG9y eT4gPHJkZjpTZXE+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJjcmVhdGVkIiBzdEV2dDppbnN0YW5j ZUlEPSJ4bXAuaWlkOkUzNkY4NzM3MzUyMDY4MTE5NDU3RDEzMkQxRDVFMkU3IiBzdEV2dDp3aGVu PSIyMDEyLTA2LTEyVDE3OjAyOjQ4LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBQ aG90b3Nob3AgQ1M1IE1hY2ludG9zaCIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0 RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6RTQ2Rjg3MzczNTIwNjgxMTk0NTdEMTMyRDFENUUyRTci IHN0RXZ0OndoZW49IjIwMTItMDYtMTJUMTc6MDM6MjMtMDc6MDAiIHN0RXZ0OnNvZnR3YXJlQWdl bnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgTWFjaW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDxy ZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDpFNTZG ODczNzM1MjA2ODExOTQ1N0QxMzJEMUQ1RTJFNyIgc3RFdnQ6d2hlbj0iMjAxMi0wNi0xMlQxNzow NjoxMy0wNzowMCIgc3RFdnQ6c29mdHdhcmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNp bnRvc2giIHN0RXZ0OmNoYW5nZWQ9Ii8iLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249InNhdmVkIiBz dEV2dDppbnN0YW5jZUlEPSJ4bXAuaWlkOkU2NkY4NzM3MzUyMDY4MTE5NDU3RDEzMkQxRDVFMkU3 IiBzdEV2dDp3aGVuPSIyMDEyLTA2LTEyVDE3OjA3OjE5LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFn ZW50PSJBZG9iZSBQaG90b3Nob3AgQ1M1IE1hY2ludG9zaCIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8 cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6RTc2 Rjg3MzczNTIwNjgxMTk0NTdEMTMyRDFENUUyRTciIHN0RXZ0OndoZW49IjIwMTItMDYtMTJUMTc6 MDk6NTAtMDc6MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgTWFj aW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIg c3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDowMTgwMTE3NDA3MjA2ODExQjFBNENFMDczQzY3M0Q2 MCIgc3RFdnQ6d2hlbj0iMjAxMi0wNi0xM1QwOTozMjoyNS0wNzowMCIgc3RFdnQ6c29mdHdhcmVB Z2VudD0iQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2giIHN0RXZ0OmNoYW5nZWQ9Ii8iLz4g PHJkZjpsaSBzdEV2dDphY3Rpb249InNhdmVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAuaWlkOjAy ODAxMTc0MDcyMDY4MTFCMUE0Q0UwNzNDNjczRDYwIiBzdEV2dDp3aGVuPSIyMDEyLTA2LTEzVDA5 OjQ3OjQ5LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBQaG90b3Nob3AgQ1M1IE1h Y2ludG9zaCIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQi IHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6MDM4MDExNzQwNzIwNjgxMUIxQTRDRTA3M0M2NzNE NjAiIHN0RXZ0OndoZW49IjIwMTItMDYtMTNUMDk6NTE6MTctMDc6MDAiIHN0RXZ0OnNvZnR3YXJl QWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgTWFjaW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIvIi8+ IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDpE ODJERkUyQTE1MjA2ODExQjFBNENFMDczQzY3M0Q2MCIgc3RFdnQ6d2hlbj0iMjAxMi0wNi0xM1Qx MToxMDozNS0wNzowMCIgc3RFdnQ6c29mdHdhcmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9wIENTNSBN YWNpbnRvc2giIHN0RXZ0OmNoYW5nZWQ9Ii8iLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249InNhdmVk IiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAuaWlkOjA2RkU2QzkyMUQyMDY4MTE4RjYyRUFGRTIwMjBF M0M2IiBzdEV2dDp3aGVuPSIyMDEyLTA2LTE0VDExOjU3OjIwLTA3OjAwIiBzdEV2dDpzb2Z0d2Fy ZUFnZW50PSJBZG9iZSBQaG90b3Nob3AgQ1M1IE1hY2ludG9zaCIgc3RFdnQ6Y2hhbmdlZD0iLyIv PiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6 MDdGRTZDOTIxRDIwNjgxMThGNjJFQUZFMjAyMEUzQzYiIHN0RXZ0OndoZW49IjIwMTItMDYtMTRU MTE6NTc6MjAtMDc6MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUg TWFjaW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZl ZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDowOEZFNkM5MjFEMjA2ODExOEY2MkVBRkUyMDIw RTNDNiIgc3RFdnQ6d2hlbj0iMjAxMi0wNi0xNFQxMTo1ODoyNi0wNzowMCIgc3RFdnQ6c29mdHdh cmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2giIHN0RXZ0OmNoYW5nZWQ9Ii8i Lz4gPHJkZjpsaSBzdEV2dDphY3Rpb249InNhdmVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAuaWlk OjA5RkU2QzkyMUQyMDY4MTE4RjYyRUFGRTIwMjBFM0M2IiBzdEV2dDp3aGVuPSIyMDEyLTA2LTE0 VDExOjU5OjA5LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBQaG90b3Nob3AgQ1M1 IE1hY2ludG9zaCIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2 ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6MEFGRTZDOTIxRDIwNjgxMThGNjJFQUZFMjAy MEUzQzYiIHN0RXZ0OndoZW49IjIwMTItMDYtMTRUMTE6NTk6MjctMDc6MDAiIHN0RXZ0OnNvZnR3 YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgTWFjaW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIv Ii8+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlp ZDozMUM2OTQxQTJBMjA2ODExOEY2MkVBRkUyMDIwRTNDNiIgc3RFdnQ6d2hlbj0iMjAxMi0wNi0x NFQxNToyNjoxOC0wNzowMCIgc3RFdnQ6c29mdHdhcmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9wIENT NSBNYWNpbnRvc2giIHN0RXZ0OmNoYW5nZWQ9Ii8iLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249InNh dmVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAuaWlkOkYzMTUzRDIzMTkyMDY4MTE5N0E1QzA4QzdB OUMwODY3IiBzdEV2dDp3aGVuPSIyMDEyLTA2LTE1VDEyOjE4OjI0LTA3OjAwIiBzdEV2dDpzb2Z0 d2FyZUFnZW50PSJBZG9iZSBQaG90b3Nob3AgQ1M1IE1hY2ludG9zaCIgc3RFdnQ6Y2hhbmdlZD0i LyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5p aWQ6RjQxNTNEMjMxOTIwNjgxMTk3QTVDMDhDN0E5QzA4NjciIHN0RXZ0OndoZW49IjIwMTItMDYt MTVUMTI6MTg6MjQtMDc6MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBD UzUgTWFjaW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJz YXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDowRTQ2QzEwRDFGMjA2ODExOTdBNUMwOEM3 QTlDMDg2NyIgc3RFdnQ6d2hlbj0iMjAxMi0wNi0xNVQxNDozMDoxOC0wNzowMCIgc3RFdnQ6c29m dHdhcmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2giIHN0RXZ0OmNoYW5nZWQ9 Ii8iLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249InNhdmVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAu aWlkOjBGNDZDMTBEMUYyMDY4MTE5N0E1QzA4QzdBOUMwODY3IiBzdEV2dDp3aGVuPSIyMDEyLTA2 LTE1VDE0OjMwOjE4LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBQaG90b3Nob3Ag Q1M1IE1hY2ludG9zaCIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0i c2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6QTQ3MjEzMEIzMDIwNjgxMTk3QTVDMDhD N0E5QzA4NjciIHN0RXZ0OndoZW49IjIwMTItMDYtMTVUMTY6MTE6NDUtMDc6MDAiIHN0RXZ0OnNv ZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgTWFjaW50b3NoIiBzdEV2dDpjaGFuZ2Vk PSIvIi8+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1w LmlpZDpBNTcyMTMwQjMwMjA2ODExOTdBNUMwOEM3QTlDMDg2NyIgc3RFdnQ6d2hlbj0iMjAxMi0w Ni0xNVQxNjoxNjo0OC0wNzowMCIgc3RFdnQ6c29mdHdhcmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9w IENTNSBNYWNpbnRvc2giIHN0RXZ0OmNoYW5nZWQ9Ii8iLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249 ImNvbnZlcnRlZCIgc3RFdnQ6cGFyYW1ldGVycz0iZnJvbSBhcHBsaWNhdGlvbi92bmQuYWRvYmUu cGhvdG9zaG9wIHRvIGltYWdlL2pwZWciLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249ImRlcml2ZWQi IHN0RXZ0OnBhcmFtZXRlcnM9ImNvbnZlcnRlZCBmcm9tIGFwcGxpY2F0aW9uL3ZuZC5hZG9iZS5w aG90b3Nob3AgdG8gaW1hZ2UvanBlZyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0 RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6QTY3MjEzMEIzMDIwNjgxMTk3QTVDMDhDN0E5QzA4Njci IHN0RXZ0OndoZW49IjIwMTItMDYtMTVUMTY6MTY6NDgtMDc6MDAiIHN0RXZ0OnNvZnR3YXJlQWdl bnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgTWFjaW50b3NoIiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDwv cmRmOlNlcT4gPC94bXBNTTpIaXN0b3J5PiA8eG1wTU06RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFu Y2VJRD0ieG1wLmlpZDpBNTcyMTMwQjMwMjA2ODExOTdBNUMwOEM3QTlDMDg2NyIgc3RSZWY6ZG9j dW1lbnRJRD0ieG1wLmRpZDpFMTZGODczNzM1MjA2ODExOTQ1N0QxMzJEMUQ1RTJFNyIgc3RSZWY6 b3JpZ2luYWxEb2N1bWVudElEPSJ4bXAuZGlkOkUzNkY4NzM3MzUyMDY4MTE5NDU3RDEzMkQxRDVF MkU3Ii8+IDxwaG90b3Nob3A6VGV4dExheWVycz4gPHJkZjpCYWc+IDxyZGY6bGkgcGhvdG9zaG9w OkxheWVyTmFtZT0iRm9sbG93IEJyb2FkY29tIG9uIFR3aXR0ZXIsIEZhY2Vib29rLCBHb29nbGUr LCBMaW5rZWRJbiBhbmQgWW91IiBwaG90b3Nob3A6TGF5ZXJUZXh0PSJGb2xsb3cgQnJvYWRjb20g b24gVHdpdHRlciwgRmFjZWJvb2ssIEdvb2dsZSssIExpbmtlZEluIGFuZCBZb3VUdWJlIFN0YXkg Q29ubmVjdGVkOiBSZWFkIHRoZSBCcm9hZGNvbSBDb25uZWN0ZWQgQmxvZyIvPiA8cmRmOmxpIHBo b3Rvc2hvcDpMYXllck5hbWU9IlRBTEVOVCBBQ1FVSVNJVElPTiIgcGhvdG9zaG9wOkxheWVyVGV4 dD0iVEFMRU5UIEFDUVVJU0lUSU9OIi8+IDwvcmRmOkJhZz4gPC9waG90b3Nob3A6VGV4dExheWVy cz4gPEV4dGVuc2lzRm9udFNlbnNlOnNsdWc+IDxyZGY6QmFnPiA8cmRmOmxpIEV4dGVuc2lzRm9u dFNlbnNlOkZvbnRTZW5zZV8xLjJfQ2hlY2tzdW09IjIxNjk2MTE2MDMiIEV4dGVuc2lzRm9udFNl bnNlOlZlcnNpb249IjUuMDEuMiIgRXh0ZW5zaXNGb250U2Vuc2U6RmFtaWx5PSJBcmlhbCIgRXh0 ZW5zaXNGb250U2Vuc2U6T3V0bGluZUZpbGVTaXplPSIwIiBFeHRlbnNpc0ZvbnRTZW5zZTpLZXJu aW5nQ2hlY2tzdW09IjAiIEV4dGVuc2lzRm9udFNlbnNlOkZvdW5kcnk9Ik1vbm90eXBlIFR5cG9n cmFwaHkiIEV4dGVuc2lzRm9udFNlbnNlOkZvbnRLaW5kPSJPcGVuVHlwZSAtIFRUIiBFeHRlbnNp c0ZvbnRTZW5zZTpDaGVja3N1bT0iMjE2OTYxMTYwMyIgRXh0ZW5zaXNGb250U2Vuc2U6UG9zdFNj cmlwdE5hbWU9IkFyaWFsTVQiLz4gPHJkZjpsaSBFeHRlbnNpc0ZvbnRTZW5zZTpGb250U2Vuc2Vf MS4yX0NoZWNrc3VtPSIyMzY3MTYxNzI2IiBFeHRlbnNpc0ZvbnRTZW5zZTpWZXJzaW9uPSIwMDEu MDA2IiBFeHRlbnNpc0ZvbnRTZW5zZTpGYW1pbHk9IkhlbHZldGljYSIgRXh0ZW5zaXNGb250U2Vu c2U6T3V0bGluZUZpbGVTaXplPSIyOTc1MyIgRXh0ZW5zaXNGb250U2Vuc2U6S2VybmluZ0NoZWNr c3VtPSIxMzg5MzQiIEV4dGVuc2lzRm9udFNlbnNlOkZvdW5kcnk9IkFkb2JlIFN5c3RlbXMiIEV4 dGVuc2lzRm9udFNlbnNlOkZvbnRLaW5kPSJQb3N0U2NyaXB0IiBFeHRlbnNpc0ZvbnRTZW5zZTpD aGVja3N1bT0iMjM2NzE2MTcyNiIgRXh0ZW5zaXNGb250U2Vuc2U6UG9zdFNjcmlwdE5hbWU9Ikhl bHZldGljYSIvPiA8cmRmOmxpIEV4dGVuc2lzRm9udFNlbnNlOkZvbnRTZW5zZV8xLjJfQ2hlY2tz dW09IjE1NTIyNjEyNzEiIEV4dGVuc2lzRm9udFNlbnNlOlZlcnNpb249IjUuMDEuMiIgRXh0ZW5z aXNGb250U2Vuc2U6RmFtaWx5PSJBcmlhbCIgRXh0ZW5zaXNGb250U2Vuc2U6T3V0bGluZUZpbGVT aXplPSIwIiBFeHRlbnNpc0ZvbnRTZW5zZTpLZXJuaW5nQ2hlY2tzdW09IjAiIEV4dGVuc2lzRm9u dFNlbnNlOkZvdW5kcnk9Ik1vbm90eXBlIFR5cG9ncmFwaHkiIEV4dGVuc2lzRm9udFNlbnNlOkZv bnRLaW5kPSJPcGVuVHlwZSAtIFRUIiBFeHRlbnNpc0ZvbnRTZW5zZTpDaGVja3N1bT0iMTU1MjI2 MTI3MSIgRXh0ZW5zaXNGb250U2Vuc2U6UG9zdFNjcmlwdE5hbWU9IkFyaWFsLUJvbGRNVCIvPiA8 L3JkZjpCYWc+IDwvRXh0ZW5zaXNGb250U2Vuc2U6c2x1Zz4gPC9yZGY6RGVzY3JpcHRpb24+IDwv cmRmOlJERj4gPC94OnhtcG1ldGE+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPD94cGFja2V0IGVuZD0idyI/Pv/iDFhJQ0NfUFJPRklMRQABAQAA DEhMaW5vAhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAA AAAAAAAAAAABAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQA AAIEAAAAFHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRt ZGQAAALEAAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAA JHRlY2gAAAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAA Q29weXJpZ2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJz UkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEW zFhZWiAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeF AAAY2lhZWiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNo AAAAAAAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBS R0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBS R0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxS ZWZlcmVuY2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVm ZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlW AFAAAABXH+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBj dXJ2AAAAAAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABt AHIAdwB8AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsB AQEHAQ0BEwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHB AckB0QHZAeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsEC ywLVAuAC6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQT BCAELQQ7BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYF tQXFBdUF5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZ B6wHvwfSB+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J 5Qn7ChEKJwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1 DI4MpwzADNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14P eg+WD7MPzw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLD EuMTAxMjE0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwW jxayFtYW+hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqe GsUa7BsUGzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMf Ph9pH5Qfvx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQf JE0kfCSrJNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWsp nSnQKgIqNSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9a L5Evxy/+MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1 wjX9Njc2cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8Jzxl PKQ84z0iPWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31D wEQDREdEikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtT S5pL4kwqTHJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19T qlP2VEJUj1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1 XIZc1l0nXXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1l kmXnZj1mkmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8e b3hv0XArcIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5 iXnnekZ6pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQd hICE44VHhauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaP npAGkG6Q1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtC m6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n 4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSc tRO1irYBtnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePC X8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA5 0LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLf Kd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o 7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+ S/7c/23////uAA5BZG9iZQBkQAAAAAH/2wCEAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQECAgICAgICAgICAgMDAwMDAwMDAwMBAQEBAQEBAQEBAQICAQICAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA//AABEIADoBCAMBEQAC EQEDEQH/3QAEACH/xAGiAAAABgIDAQAAAAAAAAAAAAAHCAYFBAkDCgIBAAsBAAAGAwEBAQAAAAAA AAAAAAYFBAMHAggBCQAKCxAAAgEDBAEDAwIDAwMCBgl1AQIDBBEFEgYhBxMiAAgxFEEyIxUJUUIW YSQzF1JxgRhikSVDobHwJjRyChnB0TUn4VM2gvGSokRUc0VGN0djKFVWVxqywtLi8mSDdJOEZaOz w9PjKThm83UqOTpISUpYWVpnaGlqdnd4eXqFhoeIiYqUlZaXmJmapKWmp6ipqrS1tre4ubrExcbH yMnK1NXW19jZ2uTl5ufo6er09fb3+Pn6EQACAQMCBAQDBQQEBAYGBW0BAgMRBCESBTEGACITQVEH MmEUcQhCgSORFVKhYhYzCbEkwdFDcvAX4YI0JZJTGGNE8aKyJjUZVDZFZCcKc4OTRnTC0uLyVWV1 VjeEhaOzw9Pj8ykalKS0xNTk9JWltcXV5fUoR1dmOHaGlqa2xtbm9md3h5ent8fX5/dIWGh4iJio uMjY6Pg5SVlpeYmZqbnJ2en5KjpKWmp6ipqqusra6vr/2gAMAwEAAhEDEQA/AN92txOPlvLU1mVp wOSYdwZqiQcAcJT5CKPm30t9f8T7917pNSxbeR3EWf3RG4AuabMbkrlQG3KiZq6FtVvqQfrx73+X WvzPUH+NU9I1qbsanRg2kQ7vx+PSEsCF8SSwRbYqbliAC0kjBj+f0+/fl178+nyDceTgiWbJYday iI/4u+1ak52jItq1y0CxQZaO4/swx1QH5b8+/U69XpR47KY7L0/3WMraetg1FGaCQMYpB+qKePiS CdDwyOFdTwQD711vqf7917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v 3XumrLZqgw0UT1kjtNUuYaKiponqa+vnA1eCio4g01RIByxA0ovqYqoJ9+690mchlM4lOa7J1uP2 djmdY4YniXN5+oke/jhjWORsfFWyW9NPDFkGc/pb8e99az0nq6o3XFRyZBdwZXB46IkjIbrk2nRy zFwBCq4eg2hU1BSSThY5J6epP0K6jYbx6dez69R03bvnF0hravF0GcxUektlq4RbFDKSwGiPNV88 0zPYaNVLTh7/AOt79QevXqnrJRd07Zey5nHbg29IqxNO+Qxc0tJEKjV9u/no/PKYZ9J0MYlDWNuB f37T17UOlrjt9bOywH2G5cNMxAIieuhp57EXv9vUtDPx+fTx+feqH069UdKlHSRVeN1dGF1dGDKw P0KspII96631y9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//Q39JG 0DUI3kYDhUC6j/gC7Igv/iQPfuvdM09TuJiRRYnGov4kyOYmif8A2EFFi65W4HN5Vtf8/T3vHXs9 RCN4sSGTa7RE2aMtlCWQ/VC5jK3K8X0W/wAPx79jrWek5Pg6tJmqpNmUENSeWyGy9xNjMrIeCTIJ 6TbkUxB40y1MiMPrwSvv1fn178uk1Uhkr45xPVnM+mGmfJQw7R3kwtZYKXLeBdrbwVQCFp5UMZIu XJ97691q9d//AM5/5e9b/NnfGOwWdwyfG/pfuqHqjdmxp9gbaCbiotv5nLYTcdRmtySY3Kbyxu6M 2Nt5WemOOr4qOFqVNNPKius0W7jzbudvvVwsTD93QzaCukGtCQatTVU0YihpjgfPtr7T/cM9lua/ u68q3W92Nw3u7zBy6dyt7v6qdGhaeKKaBY7ZZVtGhh+oto5hNEzsZG/UjLJ4e3jFLFPFHNBJHNDK iyRSxOskUsbgMkkciEo6OpuCCQR7lDriX1k9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173 7r3Sey+caknjxWLgXJZ6qj8kFDrKQUlPrWNsjlZ1VzR0ERbjgyTMNEasb231qvTGVh25Mksvk3Lv bMxiKMeiKaWJGBkjp1PkjwW26F21OeRexYyzsNXuP2de/wAPXGSNMHNS5LL33HvLJa6bGUdMBHHD qCtUUuGgmLR4zF0y2apq5PWygGRiTHGPf4Ovf4esdRH/AAqWkyeaVdw7xrmaLB4qnJWjopjGPNFi IZtS0VHTI16rISjylP1EAxw+/de/w9YqiB6Cto5K1YNz76rleXHUzBo8TgYNQWarpoW8v8LxVGTp apYNWVb2QMSQie/wde/w9M+Z25DlaxcV5DnN5eOCrrNyVRZKTalOzjx/aUEMnhgWoDP4KDk1SgtU u6gs3v8AB1qn7egprtmU82QbGiGlrBBWPjTm55Xhx+UrKWqp6gY3bry00mNwWZEc8sD0kzyYwyR+ ONC2sRWr1qnWel2ZiqBJJoZq2mWjlaCqrJarIYpMfUTHUtPuShopWqtsV9iBHXItZjJEs3jVSp9+ r1ug6VVHQ5ajm8cOa3RFPTx/cyUL5WurapKZrWr2xcde9LuTHMbXqcbNGUBCml1XUe/Ide6EHF5/ JoKYTVEGShqgBSSySU/jyJF7pjcxTw0lK9WoBH2tVT082oEa2sW91630uKKvp65HaFmDxN46inlU xVFNLa5iqIW9Ub2Nx+GHKkgg+9db6me/de697917r3v3Xuve/de697917r3v3Xuve/de6//R38Zm nAtTxxu/4aaQxxj/AF9CSOf9YD/Y+/de6ZZcXmaxj9zuGejiP+6MNRUdMSP9S9VkI8pUH/g0fiJ/ w+nvf5de6TFVHsinleCu3Fkq+tU/uUq7t3BXVge9uMVjMkwidibAJApP0H9Pfs+nWsevXCT+60h8 kFBvsk3Xy0VN2JQFdNiGjYGj1I4P6kurjgkj37Py691DrKigFPJA+fzVPSSJolx++trZCtwcikD0 TVeRxeNqZLagGb751H1IPvf5de60Icnt6Tsj4kfMDvxaN3GV+ZfT2ZFfFQ414qenyOC+Qk9XSLVz LDm8ZDV1PY9G7RIggqWhiLqGgGmC2T6nad4v6ZN5Ga/aJa/POsV/L06+m2y3Icn++vsD7YiTTHb+ 326waO+haObYghNCyEom3yhSSdIdxq7xXdU+NXYGVy/RvSW9qGV2h3t0/wBb71mxtVRSwRVUO4tm 4XNTZD+G0lLGyQMtaXavxMGhS16ugjfUVmjb5fqLCxn/AI4Ub9qg/L1+XXzn+62yf1Z90fcnlzTT 937/ALhbU9PAu5oqfE/8PHU3+mPHo2+D3di814IS32GQqIjNDRVMsLisiXhqjFVtPJLQ5elUjl6e R9H0cI11CunQCr0qveut9e9+691737r3Xvfuvde9+6910zKqlmIVVBZmYgKqgXJJPAAHv3Xuke+d rc4zUu0xG9OGaOp3PURmTFU9rqwxMd0/jlWtuGQikQ/qkYgxndKcetceHUYS0+BeXB7egbNbnrSl VkKismLsjygIuW3LkI0JghEY/ZgRQzqvjgRUF09x48OvfZx69+1tgFI/LuHeWcCli5EdTXvD6fLL pEkeG27jWlPAHjiDWUSTP6/cfs69w+3rohdtWrKstuHeecH2sEcVonqjGTL9lQRsXTE7fxxfXLIb hV9cjSSsur3H7OvcPt69b+7aHI5AjObyzzLSU0MF4/uJB+5HisWjhzj8FjtXkmlYcKDNKS5A9+/w de4fb1xZanbtOEjaLL723NLp8r+Radp4lZmkKFnkpNubfhlJVAQSLC5mmJb3H7Ovf4esc1HJjoqf aWGqpmzGY8uSz2cfT95DRyMIsjmpWAKJkK6QCnoktojt6R44Cvv3zPXvl0rkw2LTFLhPsaZ8UtMt J9jJGstO0CgemRJA3kJI1Fmuxb1E3596630gsttnJYx46vHyV2Rp6WMxUtTTtHLufEUty7UeurPg 3bgxzejqyahRzG8kmm1q9a6SUE0Jip4o4qc05qiKWlpKh6DHjJj9b7VyNS0dZszcim5bE1pSGViU RrF3b3WunSOrDGdnkpZXq5hR1j1sBoMdl6z06cZurH6NW2t02t4axUWGdtNrgpGPdb6dYK4pJHIt VPSzQSpj6bIZIEVWNrG8bJtvdyKf8opakkfa1l2D6gVcsVeXXXuhAxWUTJwyaonpa2kk+2yNBKbz UVWEVzGWsBLDIjh4pV9MsbBh/Qa6306e/de697917r3v3Xuve/de6wLUwyO0cciysps4jOsIf6Oy 3VD/AIEg+/de6z+/de6//9LfqqVyEoKUklNSA/WomjaqkA/OinWSCPV/Qs5A/wBSfz7r3VePye/m Nfy7fh72HQ9V/Lz5a9c9adj5TauN3vR7K7CzmRhnn2rlslmcRjcz/AMJjJMOKOtyO36yKMTxtMRA SfSQzbr1qnQb77/nY/ypepKDYkuV+ZHQ9Fiuyto/372DX4rdGPfb+49oruTcezJM/jq/HRzQTY+n 3ds/K4uUxJI8WQxtTTsokglVPfn178ulxu3+a98D9ndBbe+Ue5fmf8WdvdC7vy2V2/tPf9H2EN+R bm3HgoYajO7XwGC26KHcma3ZgKaqilyGKpKSauoklQzRoro59jreep2Q+efxp7Y+E/bfyu6p+Xvx 0zXRW3trbsw2X7qlfJUmwtnbnkoYsRQYvesv8Yy+c2nkkzG4MarUtTi6ivKVkLR0c/nhSRmdXeCZ IqeIUIFeFSMVwcV+R+zo75YvNu27mTl7cN5SRtogvoJJxGA0hhSVGlEal4gXKBgoMkYLUBdPiGu9 R9R9D9NfyVt77i378vvh+2xvk78jNv1nR3yRx3ZG+h09nMvtStx1BWbL/itb1HQbin3FHH1DvaKS nFE8cFRRAFktUFAPb8qXsfL19tbzRfVyTK6kFtAA0cTo1A0DcFPl8+umHNX36PbrefvX+2fvZt+w b8nIWz8v3FhcwvDarfPLOL86oolv2tniDy2hrJPGw0zHQxWLVbN/Lr+W3xNzvwu2zQ7Z+Xfxl7Po PjH1pRw93bm697LhqNs9cYTa8OSSj3bvXFbnptm7r2jgxgsSzruOGloQxp5mZahYXlYX7TazWW22 dpcMpljQKStSMcKEgHhTiB1gV76c6cu+43u/7hc+cqWt1BsO77lJdRJcoiTqZqPIJEilnQHxS5Gi VwQQcfCBU+OP8zr+X78udzb02V8e/lZ1J2duvZWPym593bZoczFR5dcDg/E2Z3nT4XdNHtaj7C2r hFljepz2H+1rKRXQzSMWVmMOonp1P6O/nCfy9e6u1qjo3pn5tdHdidiU0OQmpNswbqqsric9T4nH VeYycmzt31lFj6rNpjMPj56uqNMc5FSUsMkry+NGdfYPW89CDsv+cH/Lv3x0r2l8icL8nusMj0l0 jldp4TtntDDZ18ttDY2V33kqfD7OocxKtHS5+KbcmVqkp6Qfw4eaUkLcq+nXXvy6OD0v8mOivkR1 ptHuPpXsbD9hdX78o6zIbP3rhabLphc/RUGUr8LWVVBNkMdRSNDT5bF1FOxZF/chYfj3rr1R0Jn9 8cEw/wAnkyNcx4EePwWcr31cWDfa46VYr3+rlVH1JA59+p16o64nL7grfTituSUqm9q3cVXBQQj6 WeOhoGyWRlIB/RKtNci2ofX3vr2fTplyVPioHibe2eGYqHbXS7fp6eSKgmYXIWm2xRPXZHMsCeBU NV2IBAU+/fZ177enO+4s2qw0sT7Tw+kIZ5Vp5Nw1EIAASkpF81DhY2T6PKZp1HHijYXHsfn17PUK kraWlSTCbGo4a6oWeX+IZaaSabFUdW1vuKrK5Qs9RmssWtqhjkeZjYSPEtm9++3r3yHWXVS7YbwR fcbj3hmVV31si11eEkZRPUMimDDbfoHlYKABFELqgklaz+4/Z17h9vXarHtmN8tlnbM7qzLJSRRU ifu1UvqlgweDglb/ACXF0vLu7kCwaedvqR7jgde/w9dLp2+ku4M/av3LlSlFTUlAGmca/XS7dwMc zKfChQvNKRGJGDTS6EUBPcfs69/h67QvgIJ9wZ2+Q3HlfFR09DQgyaGbVJRbcwysLmJZAXlmbT5G DTSFI1Cx++Xl17/D08bfxU+PhqKvIvHPm8tKKzLVEVzEsgXRT0FKzAOKDGQWiiBtqs0hGuRr+P8A Lrw/n0oPeut9e9+690l83tPGZozT6TRZCaD7eWtp44XFVCOVpspRVEctDlqQNz46iN9P1Qo1mG69 ap0E+bwW7cAHmXHyZykjgNManFxnI1DUFjegq8VWyyVeTxWktahqHqhGCTDVwEhfe8HrWR0lafem PMrU0sqw1KQCj+3yEdVPeiIYSYXJwVMa1mYwTa7Ikkf8RoXYtCamO7e90PWq9K7GbjEFRSVlA7TT QLFTQJLVxyyVmPmlcw7bylaZXgqpBJqOGyesxTsDBIySM4fVOt16GCDcuBnoYcicrQ09LMpYNWVM NG8TI3jlhqI6l43gqIJQUkRgGRwVIB916tXrAN14abjHy1OXY/oOHoazIwP9OfvqaF8eim/DNKqn +vvdOtV67kyOYkQyLQUmGpx9anN1kTyKObH7LHyyQtcc+qqjI/pf6a631Ejanqv87W1+4X/440MY gxfNxp1QmGikQn8T1Ep976108RtPFGvmWixdKnpSJHV3A5spfTDTwk/6lQ/+v711vpyRldQVJKn6 Egi4/qLgXB9+691//9Pfiq6XJ1hMa5H+GwHgmhgilrWB/pU1iTU8Nx/SBmH4YHn37r3XzQ/513W3 yW7e/nPfODdW3vjn8193bVxfx7pPj58cdwdZfBmD5XYrfu+JuqtlY+rwM03aNBFiNo7Hy+7ty7pv vHa38W3NhJVhOKpS0rvT+690T74/fywP5lGW7E39T/7LXX9A7p+BP8sDtrelJRdt/FnL977E7ezz YvcPY8vUOw8D2dtvd2y8/wDIHsGo78rJIoYoa0YLcdFWrR0oNJBH7917p4+FfxR7A+FPcP8ALx+T vzZ/lmfMr5GfFmp6M7oy0nTm1Omdw9pyYr5DZDtDurrnE/3t603XT7d27trM5VcJt3Kpi8maOpfH zY6ugFfNRrG3uvdR+uvgd/NL3zHkPh1tv+XN36nXHyk+R2J+dnePxwxObpfjXtTH9NbOq8qOv+hI O7e2MVSdedSblq8XuXIVNTjq/wDiVfAkG2ZjQNXUL0sfuvdRJtgfK9/5cH8ur4j9vfBT5h5va3QH 8xvv7f3eO19l/GPs7K7urelMPTdFZ7H/AMImfEYzB56s3NUdt9gUeKMtdBSyzUBAqYYmMre690vf l3/K5/mE949c/wAwP+YF8dPgV3p8Uuiu7+9Ordr7X+FWL6+qtu9qZ/44Y2jzm69zb8zvQ+DoY9wU +PwfZeydlZeqSlx8zGuyuQqIJJqGiq6p/de6NZ8qOhs587Ojvkl2R/L0/kfdw/Eqk6o+OXWvV3V3 eG7Id9dGd890bIh3RtTH9m9R7Q+MmxKeHqvvXOZDYuWzqZHOoMruKvwVCkFTVy1UlJj039nWuirb 86E7V+S+yfiLvz4Vfy4PkT8RsF/LQ+H26sj3f3Fu3oqt683V3t8q9uYCjjO0tqV20dvVO5u5Mzub tzApGkdU0udig3BlDWw0FJApPuvfn1XpX/y/P5lPX/x57p6Wofj78g8d01n9nfFX5a7owrdM9itm N47+nw1Hsba/XuLmo9qwPkc3gKv5D5XKZLBsKh6Kk28Zp1jqqQn3rrfX0n/5P249zdffGbr74Z5L or5XdOVHwz6A+LOyNzdi9i9Y4aj6o7d7D3703iN+9jHpmuEOR3PuKk2ZuiumgzAMSJQVVbHBqdwx XfWura/43KBeo3pkKVT6SKjZNTj5wxU8KtfjhpkT8hkax4I9+61+fXmqcTVC1XuLfedDAHwY/F5m jgcEXsJdrYHFsISRb9yYrzZmPv35Drf7enLHLUUaum2NkJjDObzV+aqKLF+clgTLP9k2XzNZIoJN p0jLEAah9R77T177B1iylPSxhG3xudJUmJMOBx5kxVBUgg/s/Y001Rm85wpBjeV4nsf2R9PfvsHX vtPU+GfN5CGOkwONTa+JjVYo6/JUkcdaIV404rbyhUpRp4V6wxlD9adx79jr3UWCoxuEmq8Xtylm 3DuSeRWyc8lR5ZVn0kpPuTNsjxUUcSNdIADIFNoYNP09x48Ovf4espSl2438Yzc75vdGSBpKVKWn BqJT/nRhtuUDOxpaJLBpWZ/Vby1ElgCvuPDh17h9vXJF/hIn3ZuudP4iYzS0VDTGSpgxUFTIgixO KiVRJkMrXyqgllCeSeSyIFjUA++Q698z1Mw+Mq6qs/vHnYgmTkiaLG44lZItv0EhJNOjK7xyZSrW xq51PNhGh8a+rx9B1759Kr3rrfXvfuvde9+691737r3XvfuvdNuRw+Jy6eLK4zH5KPSVC11HT1QU Hn0+aN9HPPFrHn36tOvdBjmOk9nZDVLjVrMDUlSB9lMKiickhrT0FeKiKSLUAdCNGCQPdtR60VHQ cjYe+tgVP3mNig3Bih4zUth6akpsl44I1hjkaklpZ6lZ1TUWanMryFiXP597qD1qhHStwm5UzETH z19W6MRNFLubedF9sF/UlVLiduvDG6MAbO6mxN7j3rrwPS0o5MUGSULs+Cb6LNWZWoylWjDTrCyZ Kloqo2uCeV5Fj/Uaz1vpRpU+YevLmUWt48RQNbjjTq05GYcfkMv9eB711vqTFEFYPTY6R5QOKvJT Hyf64eRqqrX/AFtKD/W/HutdShUCJtNRVJJMfpT00ZLD/DxqZZmH+JsP9b37rfX/1N135aZr5L7a 6V3HnPibsjbPZ3dlNkNvR7b2PvHIUmG21ksdU5yhg3HPXZCo3v12Ulx+BknmhAzFNqlQALKbRlBu cm4RWcj7XAkl5UUVsAiorxZeAr5j8+pT9mdp9p979wNq273s5nvtn9vHinM91aIzzo6xOYAqpaXr EPMEVqW70UnKfEKb8v0t/O5+ZTx7H7i3D1V8FuqnCx7sbqTMUlXuTdNJK+iYUsmzuw+xtz5OYxOy yUdRuXCY+oiZhL5CFUhOS15x3ciG8ljs7bz0HJ+zSzk/ZrUHrO/bOd/7vX2BR9/5A2fePcPnLjb/ ALxiZYIGGQX+qsrGBBWhWVbG7mRgNGkVPTk/8hWm6wo497/GD5j97dbd94+IV8W8szWY9NvZ3OJL NUSxV0OzqTb+48XisqZPHN5qzM6FeRpIqlWMR3/UoWw8bbt2mjvRnUaUJ+emhAP2t9h4dNL/AHkM vN878v8Au97Fcubt7bStoNrErmaGEgKChummgkkjpqXTFa1IUK8JAcYsV/Nl+R/wnqh1T/Mz+Nm+ qzL4t3o8D310vjsBWbd7LpYo3FNXw4/JV+1tkVuQqPGss0lBk6GWJJQk2LpZY2R9LzPuG0H6bmHb 3LjhJGBR/nQkLX7CPmoPV7z7lntX7/wnnP7pXuvt0djMA02z7o8yz2DEjUheNLi7RFqVQTQTKxUt HeTIwZQJqO9vkX/OI+W3VFJ8eIO+egvhr1RKJ+xt6x5/LbEq8/TzV9Lktz02ZyeyM+2Hqt1Z+ixl PiMNi6evycmO8k1c5WF6gRoje3/Ne6WosBPBtMXxtUrXNTUqaajQKoBNMtwr1IsXt17W/cX9lOdJ /c+TlvmX333oUsbQwx3awsEaO3aKO7h8VbeF5Hubq4eGBZ6R26guseraTVVRVVVCqoCqqgBVUCwV QLAAAcD3JHXHsksSSak9azHf+/fk3/Kz+fW5PkLnh3X3b8Ge4UzMmQw8e6NwbtxPX0m6J6fLZDA4 yjz+Ul27tDcW0N20vlwq1BpKauwE7UUNQj/cNTx5fT7jy3vcl8/jTbNLWoqWC1yQKmilW+GtAVwD xp1q9tOW/aT74n3bNq9sdt/q/wAv/eI2IxBJTbw20l6LcNGk0jQxie5gubZtN0U8SSK8QXDxMvhC URdy/wA5ve/yuj/0Qfy8viX2b2J2PuVRj6ndPcOE29R7P2DHUEJ/Hcxj9s7o3HgFgplYtFVZfNYu ip5whdKkHwOpbm6fcSLbYNtle5b8TgBV+ZoSPzZgPt4dBGx+4Jyv7Rxvzh96j3k2bb+T7bvFrt0k z3F6Vz4Mb3FvBNqJwY7a1uJWXVpaIjxFY5/5HPYPdFEvYvzQ+WPa/bPb2VpVqK+g2LkMZBhdm1bR gxY/btRvXG5Klz2MxsjELTUlJtmAJdYVXjV4cnS348fet2lkuzntppX5CoOPsCj5dVk/vCNi9spB yz93P2K2PauQ4DoDXayG6ulXAlm+nljIkZQKtPPeSE9zyMcBNbe+OX83T4PSVuL+Jfa+3PmD05E7 wU/WnaMiUme2qsrqwpa/Z29904GvwHjWRhoxGf8At6mzSmmRmUDy7bzXsrFNtuUu7TyWQ0I/3plp T+i9Dx0jp6+93fuL/eOgS/8AeXky/wCQuexmW92pGkinpxqba0uBIz0FTcba0sY0oty6gnqwb4Q7 /wDnn2LmOwR8vvjv1D09SY2g2/Lsf/QrvigxGey+SqZ8r/eOPOYTF919kQ/5HTw0jIKyHGgtKxDT ciI+2e43+ZpxvVjFCoA0aCDU5rWkj8Men59YtfeE5W+6zy7Z8rv93T3J3rf72WWcXy30UkYhRVi8 Ax69q26pdjKGo0tAq4Ti1h4q6+lIWbJ9jY0AgGCr23itwxpYm6/dYPCZiVvwC7VDrbm97n2e/s6x i/b12c4LETb5r6cPzGDtP7OoADfXTW4uUMpAIv4xf8e/fl1qvz68ajFTkrVbg7AzgIBEVHi81RRM rLqA8+1tvYdPGy/QvLY/S5N7+/Idb/b1Px0clG7NtzYn2MswtLk81U0GMee/9qompnzOdqWH9Jol J+lx9R77T178uu8lEYo0m3nuuGippLquIxMrYSlqWPAgNR55c9k5T9NEMsKyXsYjwB77B177T1lo 6mvlpkoNoYCHCYxPTHk8vRtjqVFJ9ctDt9Pt8nVyMOQaj7RGJ1amtY++09e+wdYlkxG362UI9bur eNVEqyKpgqcsYnbUkb6fBj9uYfXyA328Btf1yfX3H7Ovf4enbH4WrnrI81uKSGpycWv+HUFMzvi8 EkgZHFJ5FjasyEkbaZKuRFcqSsaxoWDe+zr329Kj3rrfXvfuvde9+691737r3Xvfuvde9+691737 r3Xvfuvde9+690jNxbHw+ekFciLjczEdUOVpYovKWH6RVxMPHWICB+r1i3pYc32CR1qnTFTHcWBI hy0tWadTZcjRVxlpXS/p1/xqLKR0rEfUSPSxKSAhP49g9e6VUFXUSIrvUZoK4upTH4+cEH8rNRQV lObH8gke/db6k3ST9UGarD/qZb0qE/0ZHehgP+xFveuvdSEWqjjIhp6HGQgXLSESuP6s0UPhhB/x Mrc/X37r3X//1d/j37r3Xvfuvde9+691gqaamrKealrKeCqpaiNoqimqYo56eeJxZ4poZVaOWNwb FWBBHvRAIIIqOnIpZYJEmglZJlNQykggjgQRkEeo65xRRU8UUEEUcMEMaRQwxIscUUUahI4oo0Cp HHGigKoAAAsPewAAABjqru8rvJI5aRiSSTUknJJJySTkk9ZPfuq9e9+691FoqChxlLFRY2jpcfRQ a/DSUVPDSUsPkkeaTxU8CRxR+SWRmawF2Yk8n3oKqgBQAOnri5uLuZ7i6neWdqVZ2LMaAAVYkk0A AFTwAHUr3vpnpmyeAxeWeOeqpytZApWmyVJNNQ5OlB5Igr6R4apIy3JTUY2t6lI9+r16nSbr9sZS ZVSaXCbqp4gPBT7qxsMdfDpNx4c5jKcrCR+GNE8lwCWJvfdetU6bBR1dBcfwre+HC8+XB5+LcmNU 6vUKehylVV1KL/tK0CrbkC9/fuvdd/xd4QQ28dyUpAF/49sk07AA6SA6bdxEEjM5sGXUrW9N7E+/ fl178+sn8YU6lfsWIHxebRT4bHJVqgIOsRTQ1LWP0IMZNzYc+/fl17/bdYzU4ipA+43JvzOg8iPH Y/L0qMLm6mbamAxQRbrpJeQW4BNzz78uvfmepuPiFJKZdvbCenqZOGy2cqKDGySggqfNViTM7hks v18kHIPH59+/Pr32Dp2OHzuSv/Gs61LTE/8AFt23HJjQy8eipzE0k2Ul/PqpzRnnkG3PuvdPuOxe OxNP9rjaOCigLGR1gjCmWVra5p5OZKieS3qkcs7Hkk+9db6n+/de697917r3v3Xuve/de697917r 3v3Xuve/de697917r3v3Xuve/de697917r3v3XumtsNji7SRQNSSMSzPQTz0DMx/tSCjlhWU8f2w wP59+6913/C1/NdkytrafvpR/resWlv/AI6r+/de67GIx+oPJT/cupur1ss9cyn+qmsknKkfi1rf j37r3X//1t/j37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+ 691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3 Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//2Q== --_011_0DB8F45437AB844CBB5102F807A0AD930F4C9F44xmbrcdx03ciscoc_ Content-Type: image/gif; name="image009.gif" Content-Description: image009.gif Content-Disposition: inline; filename="image009.gif"; size=1408; creation-date="Wed, 08 Aug 2012 08:16:01 GMT"; modification-date="Wed, 08 Aug 2012 08:16:01 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhGQAZAHcAMSH/C01TT0ZGSUNFOS4wFQAAAAlwSFlzAAAOxAAADsQBlSsOGwAh/wtJQ0NS R0JHMTAxMgAh/wtNU09GRklDRTkuMCwAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADqYAAA OpgAABdvkl/FRgAh/wtNU09GRklDRTkuMBgAAAAMbXNPUE1TT0ZGSUNFOS4wzfpCa7cALAAAAAAZ ABkAhwBpngBqnxR/rgF0pgBvogBwowp5qRZ+rQNxpABvowBuogR2pwBzpQBxpAN1pgBtoQVxpAJy pRB8qwV2pwBuoRR+rBV+rABypQJ0pgBypA97qgZ2pwBsoQd3qABxowN1pwN2pwR1pxF+rhmBrxyI tR2Jth6ItRWCsh2ItR2HtR6JtjF1lD12kCd5nSOPvSeKtTOSuiCLuDeDpSaRvjuGpjOPtjeRuCaR vzqGpzmSuTyUuieIszWQuDyGpiKLuTiFpiKMuyCItCGDriGKuCKJtimTwCyWwiyZxy6WwUmBmkaZ vUOYvUCawVKlyFWnyUmhxVCgw2KeuH6yx3C41We00mi00mez0mm103W82Gq102m002231WWz0m23 1Gu102u202641G221G693Gu21G+51XC51m631Wy31GKx0WOy0WOx0W641XG51nO92mGuznS51XzA 2nvA2n3B24GTnI2Zno6ZnoyYnZafo5qxu5mstI6lr4+msI6lsI2kr42kroGxxIKzxoa2x4/C1ozG 3JHI3ZDI3JDI3onA1oLE3YLD3ITC24HB2o7B14/B15TE2YPK5o7N5InJ4YvO6I7L443S7Y7S64vN 5YzP6oLG4YrO6YHG4I/S64TH4Z/P457P45TK4KK1vam2u6SzuKSzuau1uaStsqitsKrM2rHY6LLZ 6a/Y6MfX3dvd38PGx8zNzcDc6cXf6sLd6cTe6sXe6sfj79vu9cLg7dTn8NDk7t/t9N7t9Nrq8svi 7Ozt7uzs7PT6/Ofx9unz9/n8/fb5/Pr9/eDt9Pr8/efx9+fy9+vr6/r6+ujo6P///wECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwj/AJkJHEiwoMGDqwQNIlSoocOHDQ0dOtWL IKhHkBDBicOxo0eOciJJkuJLICs5k6ZQqcKypcuWVq4kooRHYKhKWKxk2cmzp88rWiz9ESjq0pYr PLlw8cm0CiZAAkdl6oI0ixdFir4w7VlFE1RmojaBQVolzK9fXaps3VmFUyCBecSMIVPGjJlOns5U QcMFTRo1VNZMYeOlTRSBelwIeMGkiRtUqa4sovVJVS1bb5w8gTEihgyBe2YMIECggAFgwQ5AYSbs Fi5mrxAkIKCABA3QMxYwYNDAQS5dD2owgwUhwq5hEgrwLnGbWWjdvCfkylXABjNGACjEIlZBeQPm oG9AzW8gnbp1RgEIyBLWfXnz57vJFytWnVmj9LOMtf+OQyCf3PFNcAwyBeTAjCPp8cKMBd6V0B8z fQDIwAUY6KBDBhoosUMDGfCwxAYZLNeDQBFCt9sDDzCQAQcJ7KbAAxfEV8KIzOgh3m445qgjjt/R 6EcRHYS445C7eeDDDwKRAkQQBQhJZI4eGGBEEgIls8IRJnTwAQhcdukllyGIgMQJpQzUCgtCDIHC mmy2SQIKKahARAtzKEPQMqbQoScdddSxJ5+A2nGHKwcVaihBAQEAOw== --_011_0DB8F45437AB844CBB5102F807A0AD930F4C9F44xmbrcdx03ciscoc_ Content-Type: image/png; name="image010.png" Content-Description: image010.png Content-Disposition: inline; filename="image010.png"; size=3853; creation-date="Wed, 08 Aug 2012 08:16:01 GMT"; modification-date="Wed, 08 Aug 2012 08:16:01 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAZCAIAAABLixI0AAAACXBIWXMAAA7EAAAOxAGVKw4bAAAK T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3 AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+ 5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk 5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd 0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA 4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5 h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+ Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY /R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1 mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/ 0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5 hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9 rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7 vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO 32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21 e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i /suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8 IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq YAAAOpgAABdvkl/FRgAABDhJREFUeNqsVTtvHGUUPed+Mzu762eMTUKUOA8lSBilSIIl8hCvAokG mjTQQEEFEiUVBb+BKkJIFCkgUgqQiIgoKAJIUUBWQIGERxIlspM4Nthe7+7sY757KHZjb3iIhk9T jL7RHJ1z7r3nUhL+p5NsvH07v3x5qV7JSiAhEAD/5SeBxmartWWo8vT20fGhSu+akmKMJ89f6uw6 UEXR6EYHCAgiSP4DkABA5RBCSO6trJwYrs88uq/P6+yFufbeQ2yu/7DeiYILXakSzIGOKwsPAPYs EQTh4XKYnpw4c2v97elWuVxO2u32pTyZVPfSWrvnXDWxl3cOPz6WReni7+1ztxsiDOwRIiGBgIj5 ZpFavfzIzrkfrxw9fDDpFkUsirVO0XFPjFF4fd/YgfFSQzDipR3JWMlO3aiVbJNXj5kEo5baxd4R W16rATCSkjouhzqu6aH0wHjpboF7heY7+iPiqanKSGrrhTcLNQtvu7vkgiAHCleUywUgISBAkgsR mswMQM0VARfWXBOBx6cqS60iMbqw2I7X1jsBIOCSgxtNlUjqxFgGyI0aoeXIBQEpAeDEzuHBSn6z lL9/bc0AkiQ6cof6dVzMW6o1Fhp5OUnangGIQFcwYDXip7ZSIgARaAsTgcemKldrnU/nay53j57Y fr+PRbLlfi9vR7QfG00A1CPqQk/IagR7igAXrkvPjnB2ovTelaZRQ8GEvpqk538wpsFMNBJA7qpH GCAgarBPIYBgFCywREsDgxk3/CJpNDOTYGYA2hF5IRIV49TmmMGF3RmHibN36oFmBjOz+72cADDQ jIEE+7xarmaUA9vKeG4kDBq/2okfXF///E5jKA1RCuQGWAKARiODGdDHake0Ihwo/K/jeKtZfLWc w5iQcDej0TZ5ETDSSJHB+rxaUSKWuvgl98FU2j+WnTy87c25xWv1Tk8gBzX2+qT3YaUrABWiVqhs uJ7r16ZvGO/AeOBbO9JXd4+9c3kpIc34oF+kkUakwW40urWuHxkN39Vix5H8LXNudnWzpV3VpBSC QUaQ/aSzfuSRJIOxEXV6ob63zFe2pqMBeVRz4KlH7c64p8yr9a56w0waSRBAIsDNKsF6BammduZ2 MzV7bXp4diRbKVQMuEVgMuVK1z9aaJSDuVQKJBklAEkpTYtmfXs1G0oaXTEBy4GnbzfnasUzk+U9 1ZAZB/pLF1biZ3fz5Y6SwFah6WraKHy8kgFIsiw7mrYutoqDk8O/reW5YORwsIVWPLXQTMwCjexn SXQV7gGqBBpsTzUd37Ll56+/nH3hiX7ed7vddz/8+M6h56e3TkkiLRjNEAxmMMIIAe5wwR3R4S4C zSLevHD+jV3V40ee7GMByPP8k3NffL+4WoDWzx5avyj9FSJJgqD7a5APBb14bHZmZmZzD23YURRF jLEfwP91SGZZNnjz5wCK81KNPiIliQAAAABJRU5ErkJggg== --_011_0DB8F45437AB844CBB5102F807A0AD930F4C9F44xmbrcdx03ciscoc_ Content-Type: image/png; name="image011.png" Content-Description: image011.png Content-Disposition: inline; filename="image011.png"; size=3749; creation-date="Wed, 08 Aug 2012 08:16:02 GMT"; modification-date="Wed, 08 Aug 2012 08:16:02 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAZCAIAAABLixI0AAAACXBIWXMAAA7EAAAOxAGVKw4bAAAK T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3 AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+ 5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk 5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd 0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA 4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5 h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+ Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY /R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1 mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/ 0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5 hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9 rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7 vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO 32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21 e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i /suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8 IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq YAAAOpgAABdvkl/FRgAAA9BJREFUeNqslc1rXFUYxt/nfc+5985kzIclpk0tCQl1CLRpFy5iQYR2 URFEEcS13fgHCN26FtyJblwJggilCxEUFypWRYTa0KQaaPNh0wxkzOSrmU7v3HPO6+Le+Wgx1IVn NffOOb/3ed7n3HOgqvQ/DdP9tbPX/HWhvnfQSpLkvxXQrO2qk0NnqsfyZ+TLrt9YuHa7dGS4EtS3 M/9kDJEASWwOUtjm0ttvvgQAqpqm6Yef/35iYnpjc3drNw2Ha3JenQ9d0UMVO3280nTx9MDaxfNz hohuLi4NjIzX6jt3N5tW8O8YUDsLYyNJdWJkdDiJLKvqj/P1hTvbs9Wx+TsHF8+TIaL9+03Voc3G A9VwmL92O1QnBt957WQSS/flrZXd5Xv37zdTBYreM3P6MGu3nc8C8LgcIoSg1vBbFyb6QUQUfHDO pakjDb0cffDee+c8QFTwQEQAiDTNwuyJwaNHSvnkVuq/+mm9sZeubOyDgg8+BC1YqqGdtoNqUEUe UlcVNHPabLlS0ts9P9+sf/b1chJLpWRE2PvQbrcLlnN+dXV9s9GUKCmVEmutGCPCAEKgqfFKOTGT xwa6rErJvHh2LI7k1u366tqW8S1qNXoenQ+7uwetdM8YyyLGWGONMSZzdOmVuXNnj/a3ae7U6Nyp USJ69/3a3Xtbx0fLCbhggYjBYqzxAhYiOKfOOSXfSr3zh25dMcYYy2IooKsLABMEDLAAIAgAIo5h rv/RaLb8s2OV0yefzhHL63tLazvW8Ob2Q2stwKCOLiUlFoAJBAiYCQwwgWODL75d3T/I3rgw2WV9 91vtg0/nK2WJLcdxTBB0Pea6AAEAZrAULGIASWIDSZxEXWuRNZWBUqXEqiFzDmAl9J8TIHDHIxel CiIAyit35nbqEQAlMKGPBTDA4PwPAfIQGOjUoB4LYLBhZlUPKMDoZxEYzESaU0Dcpw7MAPd9PQAg uRYgPNL7jsd8MIiJJQfla3LYI6giaCoMdnWpkrVGRKgwn+cgfZkqQR7rF5goKJitMSElImIiKieW NIyPVjKnRdUi2aJ3BLGmx4qMEDER+0BxZAafKnuXFrrOzM58cvXK1My5zFFtKw2aa0YeIEGiCH/+ lX50taYhgHRpbT+ORCkMVaKZqeG/tx+8MBP3zvvvf7j28ZWVyeeeZzHOEbEAhpgZBhAIO480Cxq8 Bm9FrSjIR5Y2avVxc+O9y5eiKEL3yllcXPzym18ae5kIq5IP+QGW753iZiBSyudrAMMKna4+8/qr L5fL5Z6u7kjTNF/2xGsNgDFGpNfHfwYAQFicrB4gTtcAAAAASUVORK5CYII= --_011_0DB8F45437AB844CBB5102F807A0AD930F4C9F44xmbrcdx03ciscoc_ Content-Type: image/png; name="image012.png" Content-Description: image012.png Content-Disposition: inline; filename="image012.png"; size=3902; creation-date="Wed, 08 Aug 2012 08:16:03 GMT"; modification-date="Wed, 08 Aug 2012 08:16:03 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAZCAIAAABLixI0AAAACXBIWXMAAA7EAAAOxAGVKw4bAAAK T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3 AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+ 5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk 5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd 0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA 4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5 h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+ Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY /R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1 mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/ 0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5 hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9 rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7 vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO 32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21 e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i /suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8 IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq YAAAOpgAABdvkl/FRgAABGlJREFUeNqslV9sFEUcx38zu/dv7+pde+1dbZGYtrRgY8WKsWmLxIgx 8oQPxsQXX8REjApEQozRJ1+QxDTUqFUeJEajJiZGjIYCpQjYitJSKE1aiqHtdWnT+7+319vdmd/P h20PQqqBxMnnYWdmf9/5/mZ+O8uICP6nppafzIvDhfOnS/Nzd6+tBgLB1s0V23eolVEAYK6v9E/f Z8+dXpaoMOCM3aWWQGIMQsFg7NW9vvoHOACUErOZswMFITWFexlDIf4NFcDLWBlN4QpArlDI9B8j IpWI8mN/lYRUgTIO+Ftaqzc/5tGCd1i4OfRbYeRCzX0VRJQxi/5HtpRSS5WZJQ9jlsDC1bGoEFxK aVm2IDJDkcbd+6x0aubLz6aOfJyenAhvaAlvaDHmbmQmJ4yRC9GKEBIhERHUdm6NNG9yu5yBJLIs i0spbcdGorY9B/SBfu9iIhLUqjyKMdg/d+o4EcU7uhfPnKwKBd1IJCJYOZ7yCCI5jqMSESIhker3 Zy8OuzEAEPB5F/t/ru3oVAPa+udfTP34neWI6PbnAKAKwB+tiTRDFgAA5PQUX0wQkQoA0rbcxRTG EW+VhEeK5KWR2o7uSFPLvO0AQKR502o1aK4cANiZjD0zvVJfdiqZvjRCjm3o8/5YjRqqcAN8qlpK LgGiv7KKAAJez0xfDwAsW87GN/enJ65kjv0gCkbRyHsde52rRURCOCClt25d7uoo50wJaExReEBj uSxJsTD8u72gKz4vAMjlomkUHCNfvKnbc38DAEqUjAEAd7UkESFufPmVdMGUSLZpWvl8LpEgIchx xj/tweRiUU8U9YSVSdv5XHpi3NQTEmkForIWkCTHyEcamx/a805WQrFkF0s2xuvrurcNvfu2sjBP BIjk4vd65z4/bAyecLuEhJJW9guBJNHxl3a2vvZWXde2+7uezE1PAUC4qfnsvt18YV5VFXn7FcCY oioA4A5KIg5wK0ckDDGc6j108oUdv+x8xjby1W2PZq9NSn2WK2zV0NpIQkkIq3sPbr15FMWjKEBU 17kVCLVY3FG8qhTsP792QkJ2my+J6GILgUQTR48QohaLdx7sgXi9LUT5hTXBsi8EQiJb9dQ83hlu bNLitbnr046R94RC4YbGroM9V/p6F8+cUlVlTV+SiGP5LiRAhKe/+FofOjf5zVE7uQQA17/9Slv/ YMf7H2jx2va9B4YNIzvyJ+dsrRwB2WpNIBEiXu7rvXz4kMykFIW7lOZnB9/YNdP/KyC17XrdFs7a OdJKjhwA1OqYAnBj4ATjXBKVQSK0SqM9H5oLuhaL+apjt8+6CKSSRBbQGGMcACId3Z6AfxnJFFJI vKMBY0tjoySlFovfMWVJmXOEByj41LOcc2ZZVjKZHD/Vn/rkIyubdvAefkucgY8xb/sTzfvfa2ho YFLKfD6v6/rstancH+dFaunutRhjvofb69q31NfXx2IxRkSWZWWz2XQ6bZqm4zj3pOX3+8PhcDQa DQaD/wwA2uRn79BoYwAAAAAASUVORK5CYII= --_011_0DB8F45437AB844CBB5102F807A0AD930F4C9F44xmbrcdx03ciscoc_ Content-Type: image/png; name="image013.png" Content-Description: image013.png Content-Disposition: inline; filename="image013.png"; size=4048; creation-date="Wed, 08 Aug 2012 08:16:04 GMT"; modification-date="Wed, 08 Aug 2012 08:16:04 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAZCAYAAADE6YVjAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAK T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3 AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+ 5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk 5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd 0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA 4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5 h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+ Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY /R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1 mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/ 0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5 hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9 rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7 vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO 32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21 e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i /suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8 IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq YAAAOpgAABdvkl/FRgAABPtJREFUeNqklktsVdcVhr+1z7n3XNsXjKu4KK4boZYAsYqSGlAUBhHt JGEAaSgZVGr6SFLFHaCo7YxRKwZ9zPrIQ3kI1UhWCx1UkVAgSUFVW5UUW0auHeoOrDoP+jBGvg/f c8/Ze6/dwbn3FgKDFJb062hvaa3/rMe/9xY6pqrfB77uvd/CHZgxBhH5LfADY8wlAAHw3p93zu3L sowoihCR2yZxzhFFEUmSrAFfiOP4Etbab7Tb7bC2thbyPA/W2mCtDYcPHw6Tk5PhzJkzYf/+/b39 j4NWqxXq9Xqw1s4CxKr6pXaWUalUAAghADA+Ps709AybN29mZGSkt/9xLI5jsjzHOffA6rVrw8Z7 P+S97/alh/vGxrhw4c+8884F9u3bx5EjRzhw4ADHjh1jbm6OgwcPMjU1xdGjR2/w6yKOIqx1JOXy 54xqIGhAP4K9e/fSarVYWlpiYKDK/Pw8hw4d4ty5c1jraDabZFlGq9W6yVc1AIJXj/eK0aCEW6A6 MMDY2BibNm1iePgu6vU6Y2Nj1Ot1nLM0Go0eya38NShBAyEosXpFNeBVb6ptmqYMDQ1hbRH0+m+t ViNN2zSb67f0LeIqYIhza8nynCRJbhrdNE0B6Ovrp1arMTU1Ra1W65GcP38OESHojUMRCDjvsLlF jBB777F5TpbnAIhID1u33gsCO3bsYOfOnRw/fpyJiQn6+vsZHBwkLpUYHR3FOUcIAQ2hN4XOOZyz RFGMfHjln79vtVoPV6vVQrGXZjGnTiLNJgjI0hK0WmAMEsdQKiOVBOnrg2oV2b4DtmwhrK7iowj7 +JcJ1WqHxBHH0Rdj7z1dmH//i+Q7z9FLXgREkCiCOEbimFAuIUmCqVaRoU9gBIz3mF27MaOfovab U6RPfq0XU0SIr5/t5OxZIjFUF97t1ddfvEj61DfBOtBA+elvEe3ZQ/t730XSDJrrhLUaunIV7rmH /pX/sP4RzRjv/7cAiKKI/Omn0MVFdHER+5MfF2Us1IpRRYISj34a06gjq1cx5QRxjjA3h1y5cgOB 91pk4jsAiI2BmRmk0SjWg4NU/jqPf+klZPduwvQ0ZnwXyeQkevo0/o9/oPTDHxVZnziBLiz04nlV RHxBEryiXpFOJr1+dI5uANNZiwhhZgb+vohs2078xBOE2VkQMA/cj7z2WqGRLkSIvXp80OIICAHf GcG4037tlEo790IADAGtN4oSBpDxzxf6mJ3FZ228elR9US6VQvG+w5o5R9NaADZ0BJY6xwYgV08c Ak49JQ1Y9ZS6Sp++SPb66yCGPE3pxvSq4AVTNKhgzZylmWc086zILihph9Ts2o0PSu49MjIC27bh g5J98D5y9wiVZyfQz36GZju9rvFFRrH3incFczupYF0RtH9hAYDa8j+ovHkW36ij9QbZ8jKyME+0 cZBrp06RXX6XuwYGALh68tdkNsd7JbcWEUF9QP5yceaEde6r5XKJaHUV99y3Cc31275+o8ceJ3pm gmazSX9/P5cvXx6W02+ceXR4+JNvtNbXqfT1Ie8tk039krD+/xPFO++n/JUnabdTjBhMFP3poQf3 PCxA/Nbb51/csHHDM+12G1W9o4dECIGkXEY1/O3kyV898vOf/fS9brTkF8+/8Ni927Y/G0VmI+EO 3kQirKysvPm7t9965dVXXl4GwvW/bIAEKHWfSrdpHsgA29347wAa+pFmyNu48AAAAABJRU5ErkJg gg== --_011_0DB8F45437AB844CBB5102F807A0AD930F4C9F44xmbrcdx03ciscoc_ Content-Type: image/png; name="image014.png" Content-Description: image014.png Content-Disposition: inline; filename="image014.png"; size=4184; creation-date="Wed, 08 Aug 2012 08:16:04 GMT"; modification-date="Wed, 08 Aug 2012 08:16:04 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAZCAYAAADE6YVjAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAK T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3 AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+ 5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk 5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd 0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA 4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5 h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+ Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY /R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1 mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/ 0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5 hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9 rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7 vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO 32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21 e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i /suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8 IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq YAAAOpgAABdvkl/FRgAABYNJREFUeNqcln2MnFUVxn/nvu/MO++8M9ttt7PbLl2bFmy70BYsDWKl hS6iqxS6WBMoFAkBEhKJmKxR1Aj4WQwx1rRaIF1TjApS04i6pFi+6bYQ6+IHtRZYFWvZXXe7ndmd mff7Xv/otqgEm/Ekz73/Peee+zz3nCsAy7yZ/GD5ZSs6ijNurxp9UYpxAUPjIRZSL4p66XfHR394 1eCeA5Ex2AAXzWpb3zaj+Sf/MEneYLAaohVMnGCiCETQOYeymAs6S3NuvbFjya19fz/8sLTnvNKe VetfjbNWq6eFgqjGEgQhVluJ/OoL0dU6/v5BKvU6NUtoNlL76MDjy+zVs+Z+qJDLtdaSmKIo0gaK MGFEZmEHpW9+FrttNgB683aKTzwPeQeVyXiXl+ats1ud/NwYgycK3agCxtB823XYrS2c+P6P0OVJ nOVLUJkM8eN7iZtsCplsh9IYAyANEJswwtQDVN4lu2gBydFhKn27sOfNobCui6ZPXoPdVsIkCakx RjV08lRjkgTnvEXkVi5F+wHJ0bew2ltxli+h/uzL+Pt+i9Xawsw7bwKtwXDSXWJZCALaMF3YO0Mb sBQtvbfgda8BoP7MAWpPH8A5v5PZX76D8oOPoJo89PEyydFhlOMABjsZGdNVjlBsmYUqFsDJIkqB TOc7uWCCkKYb1uN1r8HfP4jV3ES+6wPoWp3qr56hsK6L0rc+B8D4XfdzYveTVNOYeGQM20Qx/tER MsfGME4WybuI56LyLuI6SDaL2DYmSXFXrcAEIeN3bwElzNmxGa/7Ut7aeCe1X+8ju3gh9af3U+t/ lgQIdIohwkYEsS0QhYkT0hOTMFE5qXEcIFYWcXOYMCA5NorTeQ46CJkaeApnayet998Fohjfug1F HrCwcjkQEAWkgtICqRhSMSQKUltIbUUimsK1V5O9+HyiWpU4DinvegKUMPsbvVjzF2IvmAdAVC6j pYDOe+h8jkRBMs2pATvFEKOJp02sjUH7NfIXLKXj0e9S3XeQ17quA3H45493U7jmCmZ8bC2dr78E GYvKnucpD/wGcs7pdidAgiHCoDEojSEWiJQhTGPCOMR67wKmhv7G1MBBCpesxLvqcoKoju/XOLLx U4zueJRweITRHY/w2qZPE6UJsYJYzDuQAnY6ncD3fXJennO2fJ3Sxh7Gf9bPm/dtY+kvd3LWl+5g eHc/pZ5u2q7v4c839yLZDOlUFbEtJJuBf+sXb1eiScWgEiBIItT8uZz78z7abr6WpF6nddPHmTh0 mGMPP0ZhxTI6dz3IuY89wKyejyDz51KbrBDlMkQZi1A0oZjTCKb3SAwpBpWYlFAM5+3cwsy1q3i1 9x4O9d4LwJLvbWbshQPEE2XaPnElwfAoA10bmHhjiNhzCJUhEP0uOJkoEYO1OONevCDW3e7MZto/ vBZxssy7YQPVN/5KyyXvJ9s+h5GnngMRXly/ieN/OASee9qR74ZEDD6aI2kwYCdiiPMOf3poJwuv 30Dpsg9yeHsfg1/4Gj1/HKC4+Gyeu/E24vIUYaWCPSNPYs7crw0QokkElMao0BImgyovf/U+AFre t5w1P+3D6ziLV769ldGhIabqU8RuFp+UQM4MX1J80aQYsSfR1UQ0oZfj9T1PsugX/Zx99ZUAvPjF exj8zjasoosW9R8O+l+hgJrRGIFQ9KTlGx2udPO3VEhtrTWVob8w/9LV7O39PAcfeAhV8NCWkGLO qMMpVEUzoVMcS0x/ffJeAVidL3zlCq9wd0WniDZ4xSK18XFs1234u5JgMECzsnihXtu2tzb1mVMD 0VmWy91+oevelFPyniRJlVhWA+Py7UeokDTQ+s3fB8GuV3x/OzD53zTtrlKl6Wv9f0P7Wo8BI6dE /NcAQhbE7cZc9jcAAAAASUVORK5CYII= --_011_0DB8F45437AB844CBB5102F807A0AD930F4C9F44xmbrcdx03ciscoc_ Content-Type: image/png; name="image015.png" Content-Description: image015.png Content-Disposition: inline; filename="image015.png"; size=4129; creation-date="Wed, 08 Aug 2012 08:16:05 GMT"; modification-date="Wed, 08 Aug 2012 08:16:05 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAZCAYAAADE6YVjAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAK T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3 AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+ 5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk 5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd 0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA 4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5 h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+ Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY /R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1 mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/ 0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5 hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9 rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7 vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO 32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21 e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i /suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8 IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq YAAAOpgAABdvkl/FRgAABUxJREFUeNqklk9sVNcVxn/3zbw3HjODwVGBpKocBBlinOIumiiQJsiu J1GahD9JqrTAoqWC0kVLAi1Gatw4sruAgLuoIhZNm0VVlHhs6tDQAPkDVQAvqFRCqkCwOnIlaGrj EjP2m/fmzb33dDGD04g/dttP+hZv8c53v3O+8+6DKnpzuSdF5INSqWSDIJD/h1rrT8fGxl5pbW2t v1afDRs2rImiSCYmJsT3fQnDUIKZMggkiiIRESmXy1IMApmYmJByuSyDg4PH0+l0TSyVStXs37+/ t66u7gtKKVzXRSkHZ0ZUeJ6HiLBr1y4WLlzIbfW34TiKIAhYtGjRncPDwxfiDQ0Ni+bPX7Akisp4 novWBqW4NQRQEI+7jI+Ps3HjRgYGBrh8+TI9PT1Ya/E8D2stDzzwtTbHcZxarcsOCoyxWGsxZhpa i+t6oKBYDDhy5AgA+/bt4+zZs7iuh7WC1oZkMlnriIgYY8VWBWbCRCLB0bePkm1ro1Qqkc1mmT17 NqVSiY6OjopZEay1aKPFufbw3wicPHmCNatXc+zYMdavX8fddzdSW1tLNvswBw8e5NAfD1GTrMFa i1jBATDG3LSosRZjDU4sxqxUCteNc1cmw7x583Ach3PnzvHqq7/hypUrtLa2kE6n2dnezuTkJAKV d0WEIAwJw5CoXEYbUy38+dP/49Il2tt3sGnTJkZHRtm1ezfWWh5auZI5c+YSRRHDw39n+/btPP74 E2ht8H2fqBRJXETQWlPWGqn2UimFAlCKRCLB0NAQT65dSz6fryxuby/9Bw7Q0trKn44fp6fnF3R0 PM8777zN+ydO4HkJgiAAwFpLXKrtMsaglEJEPpfWRCJBz94e8vk8L+3Zgz/p09n5Atuee46fvdDJ N59+itdef41fvfJrtNaIUGlV9bBWLHFEpqKplEXE4jgOyWQSx4mhlOL8+fN4nseqVau5444vcubM GQYGfg/At9et468ffsjSpiZqk0l8368sEVREjOAIYK3B2Iobqm76cn307N3DRx+dI5PJEEURBw70 k5qV5OttbQAMDw/T2fkiv/3dfhRQKExMBeUarZiqE2sxxhBzYlhj2blzB/19fQDkcjm6un9OLtdL d1cXWhsOvfkmAIsX30Vt7SwcJ0YYlq4ZmIJSCmuFOIA1Fmss7iyPI4ffor+vj1WrVvPggw+x4Pbb aWlpYceOdrq7u+h4/qcAbN36LMual1EoFG769amIWOIinw0eYGhoCIBHHn2UZ575FqMjI2zZspl7 7vkyA2/8gcHBUzQ2NrJ8+QqKfvG6oNxQBGRKJIoiGhruBKA/l+Oxx57gnyMjvDEwQOFqgc2bt7C0 qQmtNX6xCLcQuIGTSrqKfpHlK1awdGkT7733Lj/58TbS6TQAmSVLKAYB/uQkM8VnIshUuqJyRE1N kj17e/jBlu+T630dgK/eey/r12/A9yen2jq9AigUIqLiqrrkuqxxHIdC4SoXhi7wy5dfZvDUKVzX oy2bJZlMEpWi6xJ0qztHKYXWRpyxsbFP/KL/aVlrXNfl6OHDPPujH/Ln06f5zne/x5q1a4nH4oRh WI369LRWCMIAJxYjn8//LRaG4UTdnDlfuv/+5feNj18lUZPg0sWLrGxpJZVKERQDjDGIFcTaaWmt pVQKicfjFAqFwt6Xdm+LAZz94Mzp+vr6xZlMpnHu3LlkH36E+fMXUI4ipr+LrxsFXsJjbOxfn3R3 vbj144/Pv/ufFeqam7/yjWXNzfe5rps0xgr/AxzHkdHRkYsnT7z/1vj4+F/gxmOMMfPx3syMrv5u APDvAQA0od/2coVKtQAAAABJRU5ErkJggg== --_011_0DB8F45437AB844CBB5102F807A0AD930F4C9F44xmbrcdx03ciscoc_-- From RCosta@ptinovacao.pt Wed Aug 8 02:12: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 B939D21F8704 for ; Wed, 8 Aug 2012 02:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnAmQYF8Fyfu for ; Wed, 8 Aug 2012 02:12:55 -0700 (PDT) Received: from owa.ptinovacao.pt (owa.ptinovacao.pt [194.65.138.99]) by ietfa.amsl.com (Postfix) with ESMTP id A897F21F850D for ; Wed, 8 Aug 2012 02:12:54 -0700 (PDT) Received: from INOAVREX11.ptin.corpPT.com ([10.112.15.122]) by inoavrcas01.ptin.corpPT.com ([10.112.15.99]) with mapi; Wed, 8 Aug 2012 10:12:52 +0100 From: Rui Costa To: Loa Andersson , "mpls@ietf.org" Date: Wed, 8 Aug 2012 10:12:52 +0100 Thread-Topic: [mpls] wg last call draft-ietf-mpls-tp-itu-t-identifiers-03 Thread-Index: Ac1pvrS3rlSxEZLCRHiFjL4WmBmNkQLhzpyA Message-ID: <52981DB05D3C5247A12D0AEE309F3CC20264890BB480@INOAVREX11.ptin.corpPT.com> References: <4FFC3316.3080302@pi.nu> <500ED60E.5000106@pi.nu> In-Reply-To: <500ED60E.5000106@pi.nu> Accept-Language: pt-PT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: pt-PT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" , MPLS-TP ad hoc team , "draft-ietf-mpls-tp-itu-t-identifiers@tools.ietf.org" Subject: Re: [mpls] wg last call draft-ietf-mpls-tp-itu-t-identifiers-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, 08 Aug 2012 09:12:55 -0000 support regards,=09 rui -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: ter=E7a-feira, 24 de Julho de 2012 18:06 To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; MPLS-TP ad hoc team; draft-ietf-mpls-tp-itu= -t-identifiers@tools.ietf.org Subject: Re: [mpls] wg last call draft-ietf-mpls-tp-itu-t-identifiers-03 Working Group, this working group last call were supposed to end on July 22nd. However, we have not had one single comment on the draft during the last call period. We are therefore extending the wg last call until August 10, 2012. We have also selected some members of the of the MPLS Review Team whom we asked to review the draft and respond during the extended working group last call period. /Loa for the MPLS wG co-charis On 2012-07-10 15:50, Loa Andersson wrote: > Working Group, > > this is to start a working group last call on > draft-ietf-mpls-tp-itu-t-identifiers-03. > > Please send your comments to the MPLS wg mailing list (mpls@ietf.org). > > We have done an IPR poll among the authors and on the mpls wg mailing > list. All the authors has responded that they are not aware any IPR > claims on this document. > > No IPR disclosures has been filed against this document. > > This working group last call would normally end July 22, 2012, but > since we at that time are in the publication cut-off period prior to > the Vancouver meeting this wg last call ends when the cut-off is > lifted. > > /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 loa@pi.nu Wed Aug 8 02:52: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 686DE21F8621 for ; Wed, 8 Aug 2012 02:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFIgJqOMkoVJ for ; Wed, 8 Aug 2012 02:52:50 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id B76EF21F861D for ; Wed, 8 Aug 2012 02:52:49 -0700 (PDT) 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) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id F14ED2A8003; Wed, 8 Aug 2012 11:52:47 +0200 (CEST) Message-ID: <502236F0.3070707@pi.nu> Date: Wed, 08 Aug 2012 11:52:48 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <500841D6.40402@pi.nu> In-Reply-To: <500841D6.40402@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-raza-mpls-ldp-applicability-label-adv@tools.ietf.org, "mpls-ads@tools.ietf.org" Subject: Re: [mpls] Poll for WG adoption for draft-raza-mpls-ldp-applicability-label-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: Wed, 08 Aug 2012 09:52:50 -0000 Working Group, this poll has ended. We have a new working group document. Could the authors please republish the draft as draft-ietf-mpls-ldp-applicability-label-adv-00.txt without any other changes than version, file name and dates! /Loa wg co-chair On 2012-07-19 19:20, Loa Andersson wrote: > Working group, > > this is to start a "two week" poll on adopting > draft-raza-mpls-ldp-applicability-label-adv-03 > as an MPLS working group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). > > Due to the IETF meeting week this poll is extended and will end > Aug 7th, 2012. > > /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 eosborne@cisco.com Wed Aug 8 04:33: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 6078A21F8565 for ; Wed, 8 Aug 2012 04:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jz6+zVfbhej4 for ; Wed, 8 Aug 2012 04:33:26 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id D0CB021F8554 for ; Wed, 8 Aug 2012 04:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=1175; q=dns/txt; s=iport; t=1344425606; x=1345635206; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/KiYzB5iHA5EDtvtPppFraSqUUqjrjc9nq5y8YiWfv8=; b=Vg9z+sXjBE0NlFpqqACPGX+k9SqhmqCkHROqh4sa8JJxNkcRi/UzRSWf Gt7a7ATy0k/mdk+meVovHqjJeRhz11r7s9deM00Roh0Q/Srot5VrTOl4M kZX4u4xxlFFVpbYU5g1uP+klFL8SCaly8egopIHiuRJZ7fED35lkzJDsx g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmUFAENOIlCtJV2c/2dsb2JhbABFtjKDKYEHgiEBAQQSASc/EAIBCCIUEDIlAgQBDQ0ah2uaWaBDkRJgA6NygWaCXw X-IronPort-AV: E=Sophos;i="4.77,732,1336348800"; d="scan'208";a="109543248" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 08 Aug 2012 11:33:04 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q78BX4rt024177 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Aug 2012 11:33:04 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Wed, 8 Aug 2012 06:33:03 -0500 From: "Eric Osborne (eosborne)" To: Xuxiaohu , "Eric Rosen (erosen)" Thread-Topic: Comments on MPLS-in-UDP Thread-Index: AQHNdIEAkfCDwjMvAUa1dYjrrKc2pZdOc4cAgAD99ICAAFevoA== Date: Wed, 8 Aug 2012 11:33:02 +0000 Message-ID: <20ECF67871905846A80F77F8F4A275720F53BAB7@xmb-rcd-x09.cisco.com> References: Your message of Mon, 30 Jul 2012 18:03:44 -0000. <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753B3A1@szxeml525-mbx.china.huawei.com> <9398.1344282664@erosen-linux> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753EB93@szxeml525-mbx.china.huawei.com> <20ECF67871905846A80F77F8F4A275720F5396EC@xmb-rcd-x09.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753EE7F@szxeml525-mbx.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753EE7F@szxeml525-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.23.87] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19094.000 x-tm-as-result: No--36.567800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on 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: Wed, 08 Aug 2012 11:33:27 -0000 > > > > What happens if the UDP source port you generate is an ephemeral > number > > already in use? I realize that the draft doesn't specify a particular = hashing > > algorithm but collisions are unavoidable. Does the hardware that's > imposing > > the hashed source port now need to track allocated source ports by all > > applications on the PE? I could see some on-router firewalls choking o= n a > > packet that shared a source port with some other application. >=20 > Hi Eric, >=20 > It's an interesting question. As said in section 3: " To ensure that the = source > port number is always in the range 49152 to 65535 which is required in so= me > cases, instead of calculating a 16-bit hash, the ingress PE router would > calculate a 14-bit hash and use those 14 bits as the least significant bi= ts of the > source port field while the most significant two bits would be set to bin= ary > 11." Can this trick deal with the above concern you mentioned? >=20 No. See, for example, rfc6335 section 6. 49152-65535 is the ephemeral port ran= ge. So effectively the entire 16-bit UDP port space is 100% allocated.=20 eric From koike.yoshinori@lab.ntt.co.jp Wed Aug 8 08:18: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 CB85D21F86B3 for ; Wed, 8 Aug 2012 08:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.21 X-Spam-Level: X-Spam-Status: No, score=0.21 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rnr+ZVIKtpza for ; Wed, 8 Aug 2012 08:18:05 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id ED2AB21F86B2 for ; Wed, 8 Aug 2012 08:18:04 -0700 (PDT) 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.14.5/8.14.5) with ESMTP id q78FI44Y009264 for ; Thu, 9 Aug 2012 00:18:04 +0900 (JST) 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 3DDEDE00F2 for ; Thu, 9 Aug 2012 00:18:04 +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 15011E00F1 for ; Thu, 9 Aug 2012 00:18:04 +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 q78FI3fV022230 for ; Thu, 9 Aug 2012 00:18:04 +0900 Message-ID: <5022836E.20500@lab.ntt.co.jp> Date: Thu, 09 Aug 2012 00:19:10 +0900 From: Yoshinori Koike User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: mpls@ietf.org References: <4FFC3316.3080302@pi.nu> <500ED60E.5000106@pi.nu> In-Reply-To: <500ED60E.5000106@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] wg last call draft-ietf-mpls-tp-itu-t-identifiers-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, 08 Aug 2012 15:18:06 -0000 Yes, support. However, I also think that the modification on PW_Path_ID which was already pointed out will be necessary. Best regards, Yoshinori (2012/07/25 2:06), Loa Andersson wrote: > Working Group, > > this working group last call were supposed to end on July 22nd. > > However, we have not had one single comment on the draft during > the last call period. > > We are therefore extending the wg last call until August 10, 2012. > > We have also selected some members of the of the MPLS Review Team > whom we asked to review the draft and respond during the extended > working group last > call period. > > /Loa > for the MPLS wG co-charis > > On 2012-07-10 15:50, Loa Andersson wrote: >> Working Group, >> >> this is to start a working group last call on >> draft-ietf-mpls-tp-itu-t-identifiers-03. >> >> Please send your comments to the MPLS wg mailing list (mpls@ietf.org). >> >> We have done an IPR poll among the authors and on the mpls wg mailing >> list. All the authors has responded that they are not aware any IPR >> claims on this document. >> >> No IPR disclosures has been filed against this document. >> >> This working group last call would normally end July 22, 2012, but >> since we at that time are in the publication cut-off period prior to >> the Vancouver meeting this wg last call ends when the cut-off is >> lifted. >> >> /Loa >> (for the wg co-chairs) >> >> > -- Yoshinori Koike koike.yoshinori@lab.ntt.co.jp From internet-drafts@ietf.org Wed Aug 8 09:59: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 B8A3A11E810F; Wed, 8 Aug 2012 09:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iINrjGy1aaS; Wed, 8 Aug 2012 09:59:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E3C11E810B; Wed, 8 Aug 2012 09:59:11 -0700 (PDT) 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.33 Message-ID: <20120808165911.26276.62115.idtracker@ietfa.amsl.com> Date: Wed, 08 Aug 2012 09:59:11 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-applicability-label-adv-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: Wed, 08 Aug 2012 16:59:12 -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 : Applicability of LDP Label Advertisement Mode Author(s) : Kamran Raza Sami Boutros Luca Martini Nicolai Leymann Filename : draft-ietf-mpls-ldp-applicability-label-adv-00.txt Pages : 9 Date : 2012-08-08 Abstract: An LDP speaker negotiates the label advertisement mode with its LDP peer at the time of session establishment. Although different applications sharing the same LDP session may need different modes of label distribution and advertisement, there is only one type of label advertisement mode that is negotiated and used per LDP session. This document clarifies the use and the applicability of session's negotiated label advertisement mode, and categorizes LDP applications into two broad categories of negotiated mode-bound and mode-independent applications. The document also suggests an update to RFC 5036 and RFC 4447 to remove any ambiquity and conflict in the area of using correct label advertisement mode for a given application. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-applicability-label-adv There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-applicability-label-adv-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From sboutros@cisco.com Wed Aug 8 13:39: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 1C92921F866A for ; Wed, 8 Aug 2012 13:39:45 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bE2ohBJKJBVF for ; Wed, 8 Aug 2012 13:39:44 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 829A721F8670 for ; Wed, 8 Aug 2012 13:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sboutros@cisco.com; l=1522; q=dns/txt; s=iport; t=1344458384; x=1345667984; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=e4g+J1MEOUKzrWFAaLQqJr+YqrCRsMNR5LztbImK7tw=; b=ABd3bOIBwwcU4xums5WfE3YZdqp/18JYv1bhjfpTmV3PGPr1eFgx9Hcz lMGJgEio2KzP4OS8Ag0JKEhO6/6fO3+XieBfoB8w9vfqgNBNMyQxYn3fh TlXbqXFINd6rh8bCoMwxVRgNXs0rznClmmpe/hL/AkZdna8zTlf/BOjQi k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJrNIlCtJV2d/2dsb2JhbABFuWOBB4IgAQEBAwEBAQEPASc0BgUFCQICAQg2EBsMCyUCBA4FIodlBgubFKA/BASLDoYAYAOVSY4pgWaCX4Ff X-IronPort-AV: E=Sophos;i="4.77,734,1336348800"; d="scan'208";a="109499670" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 08 Aug 2012 20:39:44 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q78KdhKB013536 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Aug 2012 20:39:43 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.212]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0298.004; Wed, 8 Aug 2012 15:39:43 -0500 From: "Sami Boutros (sboutros)" To: Loa Andersson Thread-Topic: [mpls] IPR poll on draft-ietf-mpls-ldp-ip-pw-capability Thread-Index: AQHNb9iAz0xmmdOGSESVkVvZ2ZeE05dQwAAA Date: Wed, 8 Aug 2012 20:39:42 +0000 Message-ID: <33622388-7880-4E03-A442-04589EA285EA@cisco.com> References: <5019125A.4050400@pi.nu> In-Reply-To: <5019125A.4050400@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.220.114] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19092.004 x-tm-as-result: No--40.325900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <23D0D4681A5BDA46A7AF8F78BA63B8D7@cisco.com> 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-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, 08 Aug 2012 20:39:45 -0000 I am not aware of any IPR on this draft. Thanks, Sami On Aug 1, 2012, at 4:26 AM, Loa Andersson wrote: > Working Group and authors; >=20 > draft-ietf-mpls-ldp-ip-pw-capability - the wg chair are nearly ready > to request publication for this draft, but before we do so we need > to make an IPR poll >=20 > Are you aware of any IPR that applies to > draft-ietf-mpls-ldp-ip-pw-capability? >=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 documents 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 > 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 From pranjal.dutta@alcatel-lucent.com Wed Aug 8 16:51: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 9451821F857D for ; Wed, 8 Aug 2012 16:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.521 X-Spam-Level: X-Spam-Status: No, score=-7.521 tagged_above=-999 required=5 tests=[AWL=-0.923, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhlYo3zsBLMG for ; Wed, 8 Aug 2012 16:51:16 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECE121F8589 for ; Wed, 8 Aug 2012 16:51:16 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q78Np70d018173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Aug 2012 18:51:11 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q78Np6p3011454 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 9 Aug 2012 05:21:06 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Thu, 9 Aug 2012 05:21:05 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Lizhong Jin , "erosen@cisco.com" Date: Thu, 9 Aug 2012 05:21:03 +0530 Thread-Topic: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-04 Thread-Index: Ac11BlXLAa+0NTaWQaOFlK18A6eW9AAt2iBg Message-ID: References: <20570.1344354133@erosen-linux> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C584046466ED224CA92C1BC3313B963E09F2218C4AINBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-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, 08 Aug 2012 23:51:20 -0000 --_000_C584046466ED224CA92C1BC3313B963E09F2218C4AINBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lizhong, I am a bit confused on the text below. [Lizhong] PE1 have the tunnel >. Then wh= en PE1 initiates new MVPN service, and has leaf member PE2, PE3, PE4, then = PE1 is not necessary to initiate new mLDP tunnel, but directly aggreate to = tunnel > for MVPN service. If PE1 does n= ot have the leaf information of tunnel >= , then PE1 could not aggregate MVPN service to that tunnel. And Leaf A-D ro= ute in MVPN could not help PE1 to find the leaf information of tunnel >. That means two different kind of applicati= ons could share one tunnel which is this draft trying to solve. Could you please clarify how would we aggregate multiple applications like = MVPN over "in-band" S, G Tunnel? I believe you meant multiplexing multiple= applications over generic opaque tunnel, is that correct? Irrespective of that, if the motivation of the solution is efficient mLdp r= esource management/aggregation then had you considered the option of using = existing OAM mechanisms (e.g on-demand p2mp lsp ping or same with periodi= c refreshes after some larger intervals) to gather leaf info? Having learnt about leaves thru T-LDP does not mean that leaves are reachab= le in data path. It is possible that a leaf join is stuck midway and couldn= 't really join the tree. For example, thru T-LDP you have learnt about leaves L1, L2, L3, L4 but L4 = couldn't join and is stuck in some transit node (e.g no session/hello adjac= ency to upstream etc). Then choosing the tree for an application that wants= to talk to L1,L2,L3 and L4 may impact the application delivery. Cheers, Pranjal ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Liz= hong Jin Sent: Tuesday, August 07, 2012 6:36 PM To: erosen@cisco.com Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org Subject: Re: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-04 Hi Eric, See inline below. Hope the clarification helps. Thanks Lizhong Eric Rosen wrote 2012/08/07 23:42:13: > > The leaf discovery mechanism is not to complement MVPN > > > The leaf discovery mechanism is useful for root initiated application t= o > > aggregate tunnels from leaf initiated application. For example, how to = let > > MVPN to aggregate the mLDP tunnel generated by in-band signaling? > > I'm confused by these two sentences, as the second mentions the use of ml= dp > leaf discovery by MVPN, but the first says that you dont' intend the two > mechanisms to be used together. However, let's assume for now that there= is > no MVPN here, just some mLDP in-band signaling. > > So suppose PE2, PE3, and PE4 join an mLDP tunnel rooted at PE1. Say the > tunnel is identified by the mLDP FEC element value=3D> (this is a case of in-band signaling).. > > Now PE2, PE3, and PE4 join another mLDP tunnel rooted at PE1, say > > (another case of in-band signaling). > > PE1 sees that the two tunnels have exactly the same set of leaf nodes. S= o > what is PE1 supposed to do? [Lizhong] PE1 have the tunnel >. Then wh= en PE1 initiates new MVPN service, and has leaf member PE2, PE3, PE4, then = PE1 is not necessary to initiate new mLDP tunnel, but directly aggreate to = tunnel > for MVPN service. If PE1 does n= ot have the leaf information of tunnel >= , then PE1 could not aggregate MVPN service to that tunnel. And Leaf A-D ro= ute in MVPN could not help PE1 to find the leaf information of tunnel >. That means two different kind of applicati= ons could share one tunnel which is this draft trying to solve. > > > the root node has the capability to aggregate existing tunnel instead o= f > > creating an additional one. > > A few questions: > > - How does it do this? There doesn't seem to be any mechanism to do this= . > > * What will cause PE2,PE3,PE4 to expect (S2,G2) traffic on the opaque value=3D> tunnel? > > * What will cause the teardown of the partially set up tunnel > at the P routers and PE routers? > > - How does the root node's aggregation strategy respond to dynamically > changing sets of leaf nodes? (Remember the leaf nodes join and leave t= he > LSP one at a time.) > > - How does the root node even know that the leaf nodes can correctly hand= le > traffic from an aggregated tunnel? > > I don't think any of this can be done without some application-layer > signaling between the root and leaf nodes. But if there is > application-layer signaling between the root and leaf nodes, why doesn't > that provide all the necessary auto-discovery? [Lizhong] as stated above, this draft did not try to help aggregate tunnel = > and >, but help to aggregate tunnels from different kinds of applications, or = to let leaf initiated application and root initiated application to share o= ne tunnel. E.g, enable MVPN to use tunnel >. > > > leaf discovery did not introduce much additional new T-LDP session, but > > mostly rely on the existing T-LDP session provided by the application. > > If you want to focus on a use case where there is already T-LDP signaling > for some application, you have to show that some requirement is not met b= y > the existing T-LDP signaling for that application. > > > > > > > > > - > --_000_C584046466ED224CA92C1BC3313B963E09F2218C4AINBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Lizhong,

       &= nbsp;           &nbs= p;       I am a bit confused on the text below.

 

[Lizhong] PE1 have the tunnel <root=3DPE1, opaque value=3D<S1,G1>>. Then when PE1 initiates new MVPN service, and ha= s leaf member PE2, PE3, PE4, then PE1 is not necessary to initiate new mLDP tunnel= , but directly aggreate to tunnel <root=3DPE1, opaque value=3D<S1,G1>= ;> for MVPN service. If PE1 does not have the leaf information of tunnel <root=3DPE1, opaque value=3D<S1,G1>>, then PE1 could not aggreg= ate MVPN service to that tunnel. And Leaf A-D route in MVPN could not help PE1 to fi= nd the leaf information of tunnel <root=3DPE1, opaque value=3D<S1,G1>= >. That means two different kind of applications could share one tunnel which = is this draft trying to solve.

Could you please clarify how would we = aggregate multiple applications like MVPN over “in-band” S, G Tunnel?&nbs= p; I believe you meant multiplexing multiple applications over generic opaque tu= nnel, is that correct?

      

Irrespective of that, if the motivatio= n of the solution is efficient mLdp resource management/aggregation then had you= considered the option of using existing OAM mechanisms  (e.g on-demand p2mp lsp p= ing  or same with periodic refreshes after some larger intervals) to gather leaf in= fo?<= /font>  

 

Having learnt about leaves thru T-LDP = does not mean that leaves are reachable in data path. It is possible that a leaf join is stuck midway and couldn’t really join the tree.

For example, thru T-LDP you have learn= t about leaves L1, L2, L3, L4 but L4 couldn’t join and is stuck in some trans= it node (e.g no session/hello adjacency to upstream etc). Then choosing the tr= ee for an application that wants to talk to L1,L2,L3 and L4 may impact the application delivery.

 

Cheers,

Pranjal

 

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Lizhong Jin
Sent: Tuesday, August 07, 20= 12 6:36 PM
To: erosen@cisco.com
Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org
Subject: Re: [mpls] wg doc p= oll on draft-jin-mpls-mldp-leaf-discovery-04

 


Hi Eric,
See inline below. Hope the clarification helps.

Thanks
Lizhong
 

Er= ic Rosen <erosen@cisco.com> wrote 2012/08/07 23:42:13:

> > The leaf discovery mechanism is no= t to complement MVPN
>
> > The leaf discovery mechanism is us= eful for root initiated application to
> > aggregate tunnels from leaf initia= ted application. For example, how to let
> > MVPN to aggregate the mLDP tunnel generated by in-band signaling?
>
> I'm confused by these two sentences, as= the second mentions the use of mldp
> leaf discovery by MVPN, but the first s= ays that you dont' intend the two
> mechanisms to be used together.  However, let's assume for now that there is
> no MVPN here, just some mLDP in-band signaling.
>
> So suppose PE2, PE3, and PE4 join an mL= DP tunnel rooted at PE1.  Say the
> tunnel is identified by the mLDP FEC el= ement <root=3DPE1, opaque
> value=3D<S1,G1>> (this is a ca= se of in-band signaling)..
>
> Now PE2, PE3, and PE4 join another mLDP tunnel rooted at PE1, say
> <root=3DPE1,opaque value=3D<S2,G2= >> (another case of in-band signaling).
>
> PE1 sees that the two tunnels have exac= tly the same set of leaf nodes.  So
> what is PE1 supposed to do?=
[L= izhong] PE1 have the tunnel <root=3DPE1, opaque value=3D<S1,G1>>. Then = when PE1 initiates new MVPN service, and has leaf member PE2, PE3, PE4, then PE1 is = not necessary to initiate new mLDP tunnel, but directly aggreate to tunnel <root=3DPE1, opaque value=3D<S1,G1>> for MVPN service. If PE1 d= oes not have the leaf information of tunnel <root=3DPE1, opaque value=3D<S1,G1>>, then PE1 could not aggregate MVPN service to tha= t tunnel. And Leaf A-D route in MVPN could not help PE1 to find the leaf information of tunnel <root=3DPE1, opaque value=3D<S1,G1>>. Tha= t means two different kind of applications could share one tunnel which is this dra= ft trying to solve.

>
> > the root node has the capability t= o aggregate existing tunnel instead of
> > creating an additional one.=
>
> A few questions:
>
> - How does it do this?  There does= n't seem to be any mechanism to do this.
>
>   * What will cause PE2,PE3,PE4 to expect (S2,G2) traffic on the <root=3DPE1,
>     opaque value=3D<S1,G1&= gt;> tunnel?
>
>   * What will cause the teardown o= f the partially set up tunnel <PE1,S2,G2>
>     at the P routers and PE routers?
>
> - How does the root node's aggregation strategy respond to dynamically
>   changing sets of leaf nodes?  (Remember the leaf nodes join and leave the
>   LSP one at a time.)<= br> >
> - How does the root node even know that= the leaf nodes can correctly handle
>   traffic from an aggregated tunne= l?
>
> I don't think any of this can be done w= ithout some application-layer
> signaling between the root and leaf nod= es.  But if there is
> application-layer signaling between the= root and leaf nodes, why doesn't
> that provide all the necessary auto-discovery?
[L= izhong] as stated above, this draft did not try to help aggregate tunnel <root=3DPE= 1, opaque value=3D<S1,G1>> and <root=3DPE1, opaque value=3D<S2,G2>>, but help to aggregate tunnels from different kin= ds of applications, or to let leaf initiated application and root initiated application to share one tunnel. E.g, enable MVPN to use tunnel <root=3D= PE1, opaque value=3D<S1,G1>>.

>
> > leaf discovery did not introduce m= uch additional new T-LDP session, but
> > mostly rely on the existing T-LDP session provided by the application.
>
> If you want to focus on a use case wher= e there is already T-LDP signaling
> for some application, you have to show = that some requirement is not met by
> the existing T-LDP signaling for that application.
>
>
>
>
>  
>
>  
>
> -  
>

--_000_C584046466ED224CA92C1BC3313B963E09F2218C4AINBANSXCHMBSA_-- From xuxiaohu@huawei.com Wed Aug 8 18:52: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 3C3ED11E814F for ; Wed, 8 Aug 2012 18:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=-0.528, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFRma3R47y3B for ; Wed, 8 Aug 2012 18:52:17 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8954D11E80A5 for ; Wed, 8 Aug 2012 18:52:17 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJB17999; Wed, 08 Aug 2012 17:52:17 -0800 (PST) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 8 Aug 2012 18:49:45 -0700 Received: from SZXEML426-HUB.china.huawei.com (10.72.61.34) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 8 Aug 2012 18:49:50 -0700 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.5]) by szxeml426-hub.china.huawei.com ([10.72.61.34]) with mapi id 14.01.0323.003; Thu, 9 Aug 2012 09:49:42 +0800 From: Xuxiaohu To: "Eric Osborne (eosborne)" , "Eric Rosen (erosen)" Thread-Topic: Comments on MPLS-in-UDP Thread-Index: AQHNdAzUtdwdCzXyaEe3xLHRR7iIc5dOB+Tg///myACAAS1rQIAAKNYAgAFym+A= Date: Thu, 9 Aug 2012 01:49:42 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753F1F5@szxeml525-mbx.china.huawei.com> References: Your message of Mon, 30 Jul 2012 18:03:44 -0000. <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753B3A1@szxeml525-mbx.china.huawei.com> <9398.1344282664@erosen-linux> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753EB93@szxeml525-mbx.china.huawei.com> <20ECF67871905846A80F77F8F4A275720F5396EC@xmb-rcd-x09.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753EE7F@szxeml525-mbx.china.huawei.com> <20ECF67871905846A80F77F8F4A275720F53BAB7@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A275720F53BAB7@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.99.24] 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] Comments on 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: Thu, 09 Aug 2012 01:52:18 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogRXJpYyBPc2Jvcm5lIChlb3Nib3Ju ZSkgW21haWx0bzplb3Nib3JuZUBjaXNjby5jb21dDQo+ILeiy83KsbzkOiAyMDEyxOo41MI4yNUg MTk6MzMNCj4gytW8/sjLOiBYdXhpYW9odTsgRXJpYyBSb3NlbiAoZXJvc2VuKQ0KPiCzrcvNOiBt cGxzQGlldGYub3JnDQo+INb3zOI6IFJFOiBDb21tZW50cyBvbiBNUExTLWluLVVEUA0KPiANCj4g PiA+DQo+ID4gPiBXaGF0IGhhcHBlbnMgaWYgdGhlIFVEUCBzb3VyY2UgcG9ydCB5b3UgZ2VuZXJh dGUgaXMgYW4gZXBoZW1lcmFsDQo+ID4gbnVtYmVyDQo+ID4gPiBhbHJlYWR5IGluIHVzZT8gIEkg cmVhbGl6ZSB0aGF0IHRoZSBkcmFmdCBkb2Vzbid0IHNwZWNpZnkgYSBwYXJ0aWN1bGFyIGhhc2hp bmcNCj4gPiA+IGFsZ29yaXRobSBidXQgY29sbGlzaW9ucyBhcmUgdW5hdm9pZGFibGUuICBEb2Vz IHRoZSBoYXJkd2FyZSB0aGF0J3MNCj4gPiBpbXBvc2luZw0KPiA+ID4gdGhlIGhhc2hlZCBzb3Vy Y2UgcG9ydCBub3cgbmVlZCB0byB0cmFjayBhbGxvY2F0ZWQgc291cmNlIHBvcnRzIGJ5IGFsbA0K PiA+ID4gYXBwbGljYXRpb25zIG9uIHRoZSBQRT8gIEkgY291bGQgc2VlIHNvbWUgb24tcm91dGVy IGZpcmV3YWxscyBjaG9raW5nIG9uIGENCj4gPiA+IHBhY2tldCB0aGF0IHNoYXJlZCBhIHNvdXJj ZSBwb3J0IHdpdGggc29tZSBvdGhlciBhcHBsaWNhdGlvbi4NCj4gPg0KPiA+IEhpIEVyaWMsDQo+ ID4NCj4gPiBJdCdzIGFuIGludGVyZXN0aW5nIHF1ZXN0aW9uLiBBcyBzYWlkIGluIHNlY3Rpb24g MzogIiBUbyBlbnN1cmUgdGhhdCB0aGUgc291cmNlDQo+ID4gcG9ydCBudW1iZXIgaXMgYWx3YXlz IGluIHRoZSByYW5nZSA0OTE1MiB0byA2NTUzNSB3aGljaCBpcyByZXF1aXJlZCBpbiBzb21lDQo+ ID4gY2FzZXMsIGluc3RlYWQgb2YgY2FsY3VsYXRpbmcgYSAxNi1iaXQgaGFzaCwgdGhlIGluZ3Jl c3MgUEUgcm91dGVyIHdvdWxkDQo+ID4gY2FsY3VsYXRlIGEgMTQtYml0IGhhc2ggYW5kIHVzZSB0 aG9zZSAxNCBiaXRzIGFzIHRoZSBsZWFzdCBzaWduaWZpY2FudCBiaXRzIG9mDQo+IHRoZQ0KPiA+ IHNvdXJjZSBwb3J0IGZpZWxkIHdoaWxlIHRoZSBtb3N0IHNpZ25pZmljYW50IHR3byBiaXRzIHdv dWxkIGJlIHNldCB0byBiaW5hcnkNCj4gPiAxMS4iICBDYW4gdGhpcyB0cmljayBkZWFsIHdpdGgg dGhlIGFib3ZlIGNvbmNlcm4geW91IG1lbnRpb25lZD8NCj4gPg0KPiANCj4gTm8uDQo+IA0KPiBT ZWUsIGZvciBleGFtcGxlLCByZmM2MzM1IHNlY3Rpb24gNi4gIDQ5MTUyLTY1NTM1IGlzIHRoZSBl cGhlbWVyYWwgcG9ydA0KPiByYW5nZS4gIFNvIGVmZmVjdGl2ZWx5IHRoZSBlbnRpcmUgMTYtYml0 IFVEUCBwb3J0IHNwYWNlIGlzIDEwMCUgYWxsb2NhdGVkLg0KDQpIaSBFcmljLA0KDQpBcyBzdGF0 ZWQgaW4gc2VjdGlvbiA2IG9mIFJGQzYzMzUsICIuLi50aGUgRHluYW1pYyBQb3J0cywgYWxzbyBr bm93biBhcyB0aGUgUHJpdmF0ZSBvciBFcGhlbWVyYWwgUG9ydHMsIGZyb20gNDkxNTItNjU1MzUg KG5ldmVyIGFzc2lnbmVkKS4uLiIgIEluIGFkZGl0aW9uLCB0aGUgc3BlY2lmaWMgZGVzdGluYXRp b24gcG9ydCBudW1iZXIgdG8gYmUgYXNzaWduZWQgYnkgSUFOQSBjYW4gaW5kaWNhdGUgdGhlIHBh eWxvYWQgb2YgdGhlIFVEUCBpcyBhIE1QTFMgcGFja2V0LiBIZW5jZSBJIGRvbid0IHVuZGVyc3Rh bmQgd2h5IGl0IHdvdWxkIGNhdXNlIGFueSBwcm9ibGVtLiBDb3VsZCB5b3UgcGxlYXNlIGV4cGxh aW4geW91ciBjb25jZXJucyB3aXRoIGEgY29uY3JldGUgZXhhbXBsZT8NCg0KQmVzdCByZWdhcmRz LA0KWGlhb2h1DQoNCiANCj4gDQo+IA0KPiANCj4gZXJpYw0KPiANCg0K From lizhong.jin@zte.com.cn Wed Aug 8 21:41: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 75FCE21E8039 for ; Wed, 8 Aug 2012 21:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.537 X-Spam-Level: X-Spam-Status: No, score=-100.537 tagged_above=-999 required=5 tests=[AWL=-0.452, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMo9DXL9+uir for ; Wed, 8 Aug 2012 21:40:59 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 8A70D11E8127 for ; Wed, 8 Aug 2012 21:40:56 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 10723806486374; Thu, 9 Aug 2012 12:28:27 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 1041.5347743313; Thu, 9 Aug 2012 12:40:40 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q794elbe068937; Thu, 9 Aug 2012 12:40:47 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: "Dutta, Pranjal K (Pranjal)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: lizhong.jin@zte.com.cn Date: Thu, 9 Aug 2012 12:39:58 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-09 12:40:42, Serialize complete at 2012-08-09 12:40:42 Content-Type: multipart/alternative; boundary="=_alternative 0019B44D48257A55_=" X-MAIL: mse01.zte.com.cn q794elbe068937 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-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, 09 Aug 2012 04:41:01 -0000 This is a multipart message in MIME format. --=_alternative 0019B44D48257A55_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgUHJhbmphbCwNClRoYW5rIHlvdSBmb3IgdGhlIGNvbW1lbnRzLiBTZWUgaW5saW5lIGJlbG93 Lg0KDQpMaXpob25nDQogDQoNCiJEdXR0YSwgUHJhbmphbCBLIChQcmFuamFsKSIgPHByYW5qYWwu ZHV0dGFAYWxjYXRlbC1sdWNlbnQuY29tPiB3cm90ZSANCjIwMTIvMDgvMDkgMDc6NTE6MDM6DQoN Cj4gSGkgTGl6aG9uZywNCj4gSSBhbSBhIGJpdCBjb25mdXNlZCBvbiB0aGUgdGV4dCBiZWxvdy4N Cj4gDQo+IFtMaXpob25nXSBQRTEgaGF2ZSB0aGUgdHVubmVsIDxyb290PVBFMSwgb3BhcXVlIHZh bHVlPTxTMSxHMT4+LiBUaGVuDQo+IHdoZW4gUEUxIGluaXRpYXRlcyBuZXcgTVZQTiBzZXJ2aWNl LCBhbmQgaGFzIGxlYWYgbWVtYmVyIFBFMiwgUEUzLCANCj4gUEU0LCB0aGVuIFBFMSBpcyBub3Qg bmVjZXNzYXJ5IHRvIGluaXRpYXRlIG5ldyBtTERQIHR1bm5lbCwgYnV0IA0KPiBkaXJlY3RseSBh Z2dyZWF0ZSB0byB0dW5uZWwgPHJvb3Q9UEUxLCBvcGFxdWUgdmFsdWU9PFMxLEcxPj4gZm9yIA0K PiBNVlBOIHNlcnZpY2UuIElmIFBFMSBkb2VzIG5vdCBoYXZlIHRoZSBsZWFmIGluZm9ybWF0aW9u IG9mIHR1bm5lbCANCj4gPHJvb3Q9UEUxLCBvcGFxdWUgdmFsdWU9PFMxLEcxPj4sIHRoZW4gUEUx IGNvdWxkIG5vdCBhZ2dyZWdhdGUgTVZQTiANCj4gc2VydmljZSB0byB0aGF0IHR1bm5lbC4gQW5k IExlYWYgQS1EIHJvdXRlIGluIE1WUE4gY291bGQgbm90IGhlbHAgDQo+IFBFMSB0byBmaW5kIHRo ZSBsZWFmIGluZm9ybWF0aW9uIG9mIHR1bm5lbCA8cm9vdD1QRTEsIG9wYXF1ZSANCj4gdmFsdWU9 PFMxLEcxPj4uIFRoYXQgbWVhbnMgdHdvIGRpZmZlcmVudCBraW5kIG9mIGFwcGxpY2F0aW9ucyBj b3VsZCANCj4gc2hhcmUgb25lIHR1bm5lbCB3aGljaCBpcyB0aGlzIGRyYWZ0IHRyeWluZyB0byBz b2x2ZS4gDQoNCj4gQ291bGQgeW91IHBsZWFzZSBjbGFyaWZ5IGhvdyB3b3VsZCB3ZSBhZ2dyZWdh dGUgbXVsdGlwbGUgDQo+IGFwcGxpY2F0aW9ucyBsaWtlIE1WUE4gb3ZlciChsGluLWJhbmShsSBT LCBHIFR1bm5lbD8gIEkgYmVsaWV2ZSB5b3UgDQo+IG1lYW50IG11bHRpcGxleGluZyBtdWx0aXBs ZSBhcHBsaWNhdGlvbnMgb3ZlciBnZW5lcmljIG9wYXF1ZSB0dW5uZWwsDQo+IGlzIHRoYXQgY29y cmVjdD8NCltMaXpob25nXSByaWdodCwgYW5kIEkgdGhpbmsgd2UgYXJlIG5lYXJseSBhbGlnbmVk LiBBbmQgYWN0dWFsbHksIHdoZXRoZXIgDQp0aGUgbUxEUCB0dW5uZWwgb3BhcXVlIHZhbHVlIGlz IGdlbmVyaWMgb3IgPFMsRz4sIHR1bm5lbCBhZ2dyZWdhdGlvbiB3aWxsIA0KY2FyZSBtb3JlIGFi b3V0IHRoZSB0dW5uZWwgcm9vdCBhbmQgbGVhZiBtZW1iZXJzLg0KDQo+IA0KPiBJcnJlc3BlY3Rp dmUgb2YgdGhhdCwgaWYgdGhlIG1vdGl2YXRpb24gb2YgdGhlIHNvbHV0aW9uIGlzIGVmZmljaWVu dA0KPiBtTGRwIHJlc291cmNlIG1hbmFnZW1lbnQvYWdncmVnYXRpb24gdGhlbiBoYWQgeW91IGNv bnNpZGVyZWQgdGhlIA0KPiBvcHRpb24gb2YgdXNpbmcgZXhpc3RpbmcgT0FNIG1lY2hhbmlzbXMg IChlLmcgb24tZGVtYW5kIHAybXAgbHNwIA0KPiBwaW5nICBvciBzYW1lIHdpdGggcGVyaW9kaWMg cmVmcmVzaGVzIGFmdGVyIHNvbWUgbGFyZ2VyIGludGVydmFscykgDQo+IHRvIGdhdGhlciBsZWFm IGluZm8/DQpbTGl6aG9uZ10gV2UgaGF2ZSBjb25zaWRlcmVkIHRoaXMgb3B0aW9uIGJlZm9yZSwg cGxlYXNlIHJlZmVyIHRvIA0KaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy83Ny9zbGlk ZXMvbXBscy00L21wbHMtNF9maWxlcy9mcmFtZS5odG0uIA0KQnkgdXNpbmcgT0FNIHRvb2xzLCBh ZGRpdGlvbmFsIG92ZXJsb2FkIHdpbGwgYmUgYWRkZWQgdG8gdGhlIG5ldHdvcmssIGFuZCANCmxl YWYgZGlzY292ZXJ5IGlzIG1vcmUgb2YgYSBzaWduYWxpbmcgcmVxdWlyZW1lbnQuIFRoYXQncyB3 aHkgd2UgY2hvb3NlIA0Kc2lnbmFsaW5nIHRvIGRvIGxlYWYgZGlzY292ZXJ5Lg0KDQo+IA0KPiBI YXZpbmcgbGVhcm50IGFib3V0IGxlYXZlcyB0aHJ1IFQtTERQIGRvZXMgbm90IG1lYW4gdGhhdCBs ZWF2ZXMgYXJlIA0KPiByZWFjaGFibGUgaW4gZGF0YSBwYXRoLiBJdCBpcyBwb3NzaWJsZSB0aGF0 IGEgbGVhZiBqb2luIGlzIHN0dWNrIA0KPiBtaWR3YXkgYW5kIGNvdWxkbqGvdCByZWFsbHkgam9p biB0aGUgdHJlZS4NCj4gRm9yIGV4YW1wbGUsIHRocnUgVC1MRFAgeW91IGhhdmUgbGVhcm50IGFi b3V0IGxlYXZlcyBMMSwgTDIsIEwzLCBMNCANCj4gYnV0IEw0IGNvdWxkbqGvdCBqb2luIGFuZCBp cyBzdHVjayBpbiBzb21lIHRyYW5zaXQgbm9kZSAoZS5nIG5vIA0KPiBzZXNzaW9uL2hlbGxvIGFk amFjZW5jeSB0byB1cHN0cmVhbSBldGMpLiBUaGVuIGNob29zaW5nIHRoZSB0cmVlIGZvcg0KPiBh biBhcHBsaWNhdGlvbiB0aGF0IHdhbnRzIHRvIHRhbGsgdG8gTDEsTDIsTDMgYW5kIEw0IG1heSBp bXBhY3QgdGhlIA0KPiBhcHBsaWNhdGlvbiBkZWxpdmVyeS4NCltMaXpob25nXSBJIHVuZGVyc3Rh bmQgeW91IGNvbmNlcm4sIGJ1dCBJIHRoaW5rIHJlYWNoYWJpbGl0eSBpcyB0aGUgDQpyZXBvbnNh YmlsaXR5IG9mIE9BTSB0b29scy4NCg0KPiANCj4gQ2hlZXJzLA0KPiBQcmFuamFsDQo+IA0KPiAN Cj4gDQo+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIA0KPiBMaXpob25nIEppbg0KPiBTZW50OiBUdWVzZGF5LCBB dWd1c3QgMDcsIDIwMTIgNjozNiBQTQ0KPiBUbzogZXJvc2VuQGNpc2NvLmNvbQ0KPiBDYzogbXBs c0BpZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtt cGxzXSB3ZyBkb2MgcG9sbCBvbiBkcmFmdC1qaW4tbXBscy1tbGRwLWxlYWYtZGlzY292ZXJ5LTA0 DQo+IA0KPiANCj4gSGkgRXJpYywgDQo+IFNlZSBpbmxpbmUgYmVsb3cuIEhvcGUgdGhlIGNsYXJp ZmljYXRpb24gaGVscHMuIA0KPiANCj4gVGhhbmtzIA0KPiBMaXpob25nIA0KPiANCj4gDQo+IEVy aWMgUm9zZW4gPGVyb3NlbkBjaXNjby5jb20+IHdyb3RlIDIwMTIvMDgvMDcgMjM6NDI6MTM6DQo+ IA0KPiA+ID4gVGhlIGxlYWYgZGlzY292ZXJ5IG1lY2hhbmlzbSBpcyBub3QgdG8gY29tcGxlbWVu dCBNVlBODQo+ID4gDQo+ID4gPiBUaGUgbGVhZiBkaXNjb3ZlcnkgbWVjaGFuaXNtIGlzIHVzZWZ1 bCBmb3Igcm9vdCBpbml0aWF0ZWQgDQphcHBsaWNhdGlvbiB0bw0KPiA+ID4gYWdncmVnYXRlIHR1 bm5lbHMgZnJvbSBsZWFmIGluaXRpYXRlZCBhcHBsaWNhdGlvbi4gRm9yIGV4YW1wbGUsIGhvdyAN CnRvIGxldA0KPiA+ID4gTVZQTiB0byBhZ2dyZWdhdGUgdGhlIG1MRFAgdHVubmVsIGdlbmVyYXRl ZCBieSBpbi1iYW5kIHNpZ25hbGluZz8NCj4gPiANCj4gPiBJJ20gY29uZnVzZWQgYnkgdGhlc2Ug dHdvIHNlbnRlbmNlcywgYXMgdGhlIHNlY29uZCBtZW50aW9ucyB0aGUgdXNlIG9mIA0KbWxkcA0K PiA+IGxlYWYgZGlzY292ZXJ5IGJ5IE1WUE4sIGJ1dCB0aGUgZmlyc3Qgc2F5cyB0aGF0IHlvdSBk b250JyBpbnRlbmQgdGhlIA0KdHdvDQo+ID4gbWVjaGFuaXNtcyB0byBiZSB1c2VkIHRvZ2V0aGVy LiAgSG93ZXZlciwgbGV0J3MgYXNzdW1lIGZvciBub3cgdGhhdCANCnRoZXJlIGlzDQo+ID4gbm8g TVZQTiBoZXJlLCBqdXN0IHNvbWUgbUxEUCBpbi1iYW5kIHNpZ25hbGluZy4NCj4gPiANCj4gPiBT byBzdXBwb3NlIFBFMiwgUEUzLCBhbmQgUEU0IGpvaW4gYW4gbUxEUCB0dW5uZWwgcm9vdGVkIGF0 IFBFMS4gIFNheSANCnRoZQ0KPiA+IHR1bm5lbCBpcyBpZGVudGlmaWVkIGJ5IHRoZSBtTERQIEZF QyBlbGVtZW50IDxyb290PVBFMSwgb3BhcXVlDQo+ID4gdmFsdWU9PFMxLEcxPj4gKHRoaXMgaXMg YSBjYXNlIG9mIGluLWJhbmQgc2lnbmFsaW5nKS4uDQo+ID4gDQo+ID4gTm93IFBFMiwgUEUzLCBh bmQgUEU0IGpvaW4gYW5vdGhlciBtTERQIHR1bm5lbCByb290ZWQgYXQgUEUxLCBzYXkNCj4gPiA8 cm9vdD1QRTEsb3BhcXVlIHZhbHVlPTxTMixHMj4+IChhbm90aGVyIGNhc2Ugb2YgaW4tYmFuZCBz aWduYWxpbmcpLg0KPiA+IA0KPiA+IFBFMSBzZWVzIHRoYXQgdGhlIHR3byB0dW5uZWxzIGhhdmUg ZXhhY3RseSB0aGUgc2FtZSBzZXQgb2YgbGVhZiBub2Rlcy4gDQogU28NCj4gPiB3aGF0IGlzIFBF MSBzdXBwb3NlZCB0byBkbz8gDQo+IFtMaXpob25nXSBQRTEgaGF2ZSB0aGUgdHVubmVsIDxyb290 PVBFMSwgb3BhcXVlIHZhbHVlPTxTMSxHMT4+LiBUaGVuDQo+IHdoZW4gUEUxIGluaXRpYXRlcyBu ZXcgTVZQTiBzZXJ2aWNlLCBhbmQgaGFzIGxlYWYgbWVtYmVyIFBFMiwgUEUzLCANCj4gUEU0LCB0 aGVuIFBFMSBpcyBub3QgbmVjZXNzYXJ5IHRvIGluaXRpYXRlIG5ldyBtTERQIHR1bm5lbCwgYnV0 IA0KPiBkaXJlY3RseSBhZ2dyZWF0ZSB0byB0dW5uZWwgPHJvb3Q9UEUxLCBvcGFxdWUgdmFsdWU9 PFMxLEcxPj4gZm9yIA0KPiBNVlBOIHNlcnZpY2UuIElmIFBFMSBkb2VzIG5vdCBoYXZlIHRoZSBs ZWFmIGluZm9ybWF0aW9uIG9mIHR1bm5lbCANCj4gPHJvb3Q9UEUxLCBvcGFxdWUgdmFsdWU9PFMx LEcxPj4sIHRoZW4gUEUxIGNvdWxkIG5vdCBhZ2dyZWdhdGUgTVZQTiANCj4gc2VydmljZSB0byB0 aGF0IHR1bm5lbC4gQW5kIExlYWYgQS1EIHJvdXRlIGluIE1WUE4gY291bGQgbm90IGhlbHAgDQo+ IFBFMSB0byBmaW5kIHRoZSBsZWFmIGluZm9ybWF0aW9uIG9mIHR1bm5lbCA8cm9vdD1QRTEsIG9w YXF1ZSANCj4gdmFsdWU9PFMxLEcxPj4uIFRoYXQgbWVhbnMgdHdvIGRpZmZlcmVudCBraW5kIG9m IGFwcGxpY2F0aW9ucyBjb3VsZCANCj4gc2hhcmUgb25lIHR1bm5lbCB3aGljaCBpcyB0aGlzIGRy YWZ0IHRyeWluZyB0byBzb2x2ZS4gDQo+IA0KPiA+IA0KPiA+ID4gdGhlIHJvb3Qgbm9kZSBoYXMg dGhlIGNhcGFiaWxpdHkgdG8gYWdncmVnYXRlIGV4aXN0aW5nIHR1bm5lbCANCmluc3RlYWQgb2YN Cj4gPiA+IGNyZWF0aW5nIGFuIGFkZGl0aW9uYWwgb25lLg0KPiA+IA0KPiA+IEEgZmV3IHF1ZXN0 aW9uczoNCj4gPiANCj4gPiAtIEhvdyBkb2VzIGl0IGRvIHRoaXM/ICBUaGVyZSBkb2Vzbid0IHNl ZW0gdG8gYmUgYW55IG1lY2hhbmlzbSB0byBkbyANCnRoaXMuDQo+ID4gDQo+ID4gICAqIFdoYXQg d2lsbCBjYXVzZSBQRTIsUEUzLFBFNCB0byBleHBlY3QgKFMyLEcyKSB0cmFmZmljIG9uIHRoZSAN Cjxyb290PVBFMSwNCj4gPiAgICAgb3BhcXVlIHZhbHVlPTxTMSxHMT4+IHR1bm5lbD8NCj4gPiAN Cj4gPiAgICogV2hhdCB3aWxsIGNhdXNlIHRoZSB0ZWFyZG93biBvZiB0aGUgcGFydGlhbGx5IHNl dCB1cCB0dW5uZWwgDQo8UEUxLFMyLEcyPg0KPiA+ICAgICBhdCB0aGUgUCByb3V0ZXJzIGFuZCBQ RSByb3V0ZXJzPw0KPiA+IA0KPiA+IC0gSG93IGRvZXMgdGhlIHJvb3Qgbm9kZSdzIGFnZ3JlZ2F0 aW9uIHN0cmF0ZWd5IHJlc3BvbmQgdG8gZHluYW1pY2FsbHkNCj4gPiAgIGNoYW5naW5nIHNldHMg b2YgbGVhZiBub2Rlcz8gIChSZW1lbWJlciB0aGUgbGVhZiBub2RlcyBqb2luIGFuZCANCmxlYXZl IHRoZQ0KPiA+ICAgTFNQIG9uZSBhdCBhIHRpbWUuKQ0KPiA+IA0KPiA+IC0gSG93IGRvZXMgdGhl IHJvb3Qgbm9kZSBldmVuIGtub3cgdGhhdCB0aGUgbGVhZiBub2RlcyBjYW4gY29ycmVjdGx5IA0K aGFuZGxlDQo+ID4gICB0cmFmZmljIGZyb20gYW4gYWdncmVnYXRlZCB0dW5uZWw/DQo+ID4gDQo+ ID4gSSBkb24ndCB0aGluayBhbnkgb2YgdGhpcyBjYW4gYmUgZG9uZSB3aXRob3V0IHNvbWUgYXBw bGljYXRpb24tbGF5ZXINCj4gPiBzaWduYWxpbmcgYmV0d2VlbiB0aGUgcm9vdCBhbmQgbGVhZiBu b2Rlcy4gIEJ1dCBpZiB0aGVyZSBpcw0KPiA+IGFwcGxpY2F0aW9uLWxheWVyIHNpZ25hbGluZyBi ZXR3ZWVuIHRoZSByb290IGFuZCBsZWFmIG5vZGVzLCB3aHkgDQpkb2Vzbid0DQo+ID4gdGhhdCBw cm92aWRlIGFsbCB0aGUgbmVjZXNzYXJ5IGF1dG8tZGlzY292ZXJ5PyANCj4gW0xpemhvbmddIGFz IHN0YXRlZCBhYm92ZSwgdGhpcyBkcmFmdCBkaWQgbm90IHRyeSB0byBoZWxwIGFnZ3JlZ2F0ZSAN Cj4gdHVubmVsIDxyb290PVBFMSwgb3BhcXVlIHZhbHVlPTxTMSxHMT4+IGFuZCA8cm9vdD1QRTEs IG9wYXF1ZSANCj4gdmFsdWU9PFMyLEcyPj4sIGJ1dCBoZWxwIHRvIGFnZ3JlZ2F0ZSB0dW5uZWxz IGZyb20gZGlmZmVyZW50IGtpbmRzIA0KPiBvZiBhcHBsaWNhdGlvbnMsIG9yIHRvIGxldCBsZWFm IGluaXRpYXRlZCBhcHBsaWNhdGlvbiBhbmQgcm9vdCANCj4gaW5pdGlhdGVkIGFwcGxpY2F0aW9u IHRvIHNoYXJlIG9uZSB0dW5uZWwuIEUuZywgZW5hYmxlIE1WUE4gdG8gdXNlIA0KPiB0dW5uZWwg PHJvb3Q9UEUxLCBvcGFxdWUgdmFsdWU9PFMxLEcxPj4uIA0KPiANCj4gPiANCj4gPiA+IGxlYWYg ZGlzY292ZXJ5IGRpZCBub3QgaW50cm9kdWNlIG11Y2ggYWRkaXRpb25hbCBuZXcgVC1MRFAgc2Vz c2lvbiwgDQpidXQNCj4gPiA+IG1vc3RseSByZWx5IG9uIHRoZSBleGlzdGluZyBULUxEUCBzZXNz aW9uIHByb3ZpZGVkIGJ5IHRoZSANCmFwcGxpY2F0aW9uLg0KPiA+IA0KPiA+IElmIHlvdSB3YW50 IHRvIGZvY3VzIG9uIGEgdXNlIGNhc2Ugd2hlcmUgdGhlcmUgaXMgYWxyZWFkeSBULUxEUCANCnNp Z25hbGluZw0KPiA+IGZvciBzb21lIGFwcGxpY2F0aW9uLCB5b3UgaGF2ZSB0byBzaG93IHRoYXQg c29tZSByZXF1aXJlbWVudCBpcyBub3QgDQptZXQgYnkNCj4gPiB0aGUgZXhpc3RpbmcgVC1MRFAg c2lnbmFsaW5nIGZvciB0aGF0IGFwcGxpY2F0aW9uLg0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IA0K PiA+IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IC0gDQo+ID4gDQo= --=_alternative 0019B44D48257A55_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFByYW5qYWwsPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFuayB5b3UgZm9yIHRoZSBjb21t ZW50cy4gU2VlIGlubGluZQ0KYmVsb3cuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5MaXpob25nPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPiZxdW90O0R1dHRhLCBQcmFuamFsIEsgKFByYW5qYWwpJnF1b3Q7DQombHQ7cHJh bmphbC5kdXR0YUBhbGNhdGVsLWx1Y2VudC5jb20mZ3Q7IHdyb3RlIDIwMTIvMDgvMDkgMDc6NTE6 MDM6PGJyPg0KPGJyPg0KJmd0OyBIaSBMaXpob25nLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyBJIGFtIGEgYml0IGNvbmZ1c2VkIG9uIHRoZSB0ZXh0DQpi ZWxvdy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgJm5i c3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IFtMaXpo b25nXSBQRTEgaGF2ZSB0aGUgdHVubmVsICZsdDtyb290PVBFMSwNCm9wYXF1ZSB2YWx1ZT0mbHQ7 UzEsRzEmZ3Q7Jmd0Oy4gVGhlbjxicj4NCiZndDsgd2hlbiBQRTEgaW5pdGlhdGVzIG5ldyBNVlBO IHNlcnZpY2UsIGFuZCBoYXMgbGVhZiBtZW1iZXIgUEUyLCBQRTMsDQo8YnI+DQomZ3Q7IFBFNCwg dGhlbiBQRTEgaXMgbm90IG5lY2Vzc2FyeSB0byBpbml0aWF0ZSBuZXcgbUxEUCB0dW5uZWwsIGJ1 dCA8YnI+DQomZ3Q7IGRpcmVjdGx5IGFnZ3JlYXRlIHRvIHR1bm5lbCAmbHQ7cm9vdD1QRTEsIG9w YXF1ZSB2YWx1ZT0mbHQ7UzEsRzEmZ3Q7Jmd0Ow0KZm9yIDxicj4NCiZndDsgTVZQTiBzZXJ2aWNl LiBJZiBQRTEgZG9lcyBub3QgaGF2ZSB0aGUgbGVhZiBpbmZvcm1hdGlvbiBvZiB0dW5uZWwNCjxi cj4NCiZndDsgJmx0O3Jvb3Q9UEUxLCBvcGFxdWUgdmFsdWU9Jmx0O1MxLEcxJmd0OyZndDssIHRo ZW4gUEUxIGNvdWxkIG5vdCBhZ2dyZWdhdGUNCk1WUE4gPGJyPg0KJmd0OyBzZXJ2aWNlIHRvIHRo YXQgdHVubmVsLiBBbmQgTGVhZiBBLUQgcm91dGUgaW4gTVZQTiBjb3VsZCBub3QgaGVscA0KPGJy Pg0KJmd0OyBQRTEgdG8gZmluZCB0aGUgbGVhZiBpbmZvcm1hdGlvbiBvZiB0dW5uZWwgJmx0O3Jv b3Q9UEUxLCBvcGFxdWUgPGJyPg0KJmd0OyB2YWx1ZT0mbHQ7UzEsRzEmZ3Q7Jmd0Oy4gVGhhdCBt ZWFucyB0d28gZGlmZmVyZW50IGtpbmQgb2YgYXBwbGljYXRpb25zDQpjb3VsZCA8YnI+DQomZ3Q7 IHNoYXJlIG9uZSB0dW5uZWwgd2hpY2ggaXMgdGhpcyBkcmFmdCB0cnlpbmcgdG8gc29sdmUuIDxi cj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyBDb3Vs ZCB5b3UgcGxlYXNlIGNsYXJpZnkgaG93IHdvdWxkDQp3ZSBhZ2dyZWdhdGUgbXVsdGlwbGUgPGJy Pg0KJmd0OyBhcHBsaWNhdGlvbnMgbGlrZSBNVlBOIG92ZXIgobBpbi1iYW5kobEgUywgRyBUdW5u ZWw/ICZuYnNwO0kgYmVsaWV2ZQ0KeW91IDxicj4NCiZndDsgbWVhbnQgbXVsdGlwbGV4aW5nIG11 bHRpcGxlIGFwcGxpY2F0aW9ucyBvdmVyIGdlbmVyaWMgb3BhcXVlIHR1bm5lbCw8YnI+DQomZ3Q7 IGlzIHRoYXQgY29ycmVjdD88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPltMaXpob25nXSByaWdodCwgYW5kIEkgdGhpbmsgd2UgYXJlDQpuZWFybHkgYWxpZ25lZC4g QW5kIGFjdHVhbGx5LCB3aGV0aGVyIHRoZSBtTERQIHR1bm5lbCBvcGFxdWUgdmFsdWUgaXMgZ2Vu ZXJpYw0Kb3IgJmx0O1MsRyZndDssIHR1bm5lbCBhZ2dyZWdhdGlvbiB3aWxsIGNhcmUgbW9yZSBh Ym91dCB0aGUgdHVubmVsIHJvb3QNCmFuZCBsZWFmIG1lbWJlcnMuPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyBJ cnJlc3BlY3RpdmUgb2YgdGhhdCwgaWYgdGhlIG1vdGl2YXRpb24NCm9mIHRoZSBzb2x1dGlvbiBp cyBlZmZpY2llbnQ8YnI+DQomZ3Q7IG1MZHAgcmVzb3VyY2UgbWFuYWdlbWVudC9hZ2dyZWdhdGlv biB0aGVuIGhhZCB5b3UgY29uc2lkZXJlZCB0aGUgPGJyPg0KJmd0OyBvcHRpb24gb2YgdXNpbmcg ZXhpc3RpbmcgT0FNIG1lY2hhbmlzbXMgJm5ic3A7KGUuZyBvbi1kZW1hbmQgcDJtcA0KbHNwIDxi cj4NCiZndDsgcGluZyAmbmJzcDtvciBzYW1lIHdpdGggcGVyaW9kaWMgcmVmcmVzaGVzIGFmdGVy IHNvbWUgbGFyZ2VyIGludGVydmFscykNCjxicj4NCiZndDsgdG8gZ2F0aGVyIGxlYWYgaW5mbz88 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPltMaXpob25nXSBXZSBo YXZlIGNvbnNpZGVyZWQgdGhpcyBvcHRpb24NCmJlZm9yZSwgcGxlYXNlIHJlZmVyIHRvIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvNzcvc2xpZGVzL21wbHMtNC9tcGxzLTRfZmlsZXMv ZnJhbWUuaHRtLg0KQnkgdXNpbmcgT0FNIHRvb2xzLCBhZGRpdGlvbmFsIG92ZXJsb2FkIHdpbGwg YmUgYWRkZWQgdG8gdGhlIG5ldHdvcmssIGFuZA0KbGVhZiBkaXNjb3ZlcnkgaXMgbW9yZSBvZiBh IHNpZ25hbGluZyByZXF1aXJlbWVudC4gVGhhdCdzIHdoeSB3ZSBjaG9vc2UNCnNpZ25hbGluZyB0 byBkbyBsZWFmIGRpc2NvdmVyeS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPiZndDsgJm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj4mZ3Q7IEhhdmluZyBsZWFybnQgYWJvdXQgbGVhdmVzIHRocnUNClQtTERQIGRv ZXMgbm90IG1lYW4gdGhhdCBsZWF2ZXMgYXJlIDxicj4NCiZndDsgcmVhY2hhYmxlIGluIGRhdGEg cGF0aC4gSXQgaXMgcG9zc2libGUgdGhhdCBhIGxlYWYgam9pbiBpcyBzdHVjayA8YnI+DQomZ3Q7 IG1pZHdheSBhbmQgY291bGRuoa90IHJlYWxseSBqb2luIHRoZSB0cmVlLjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyBGb3IgZXhhbXBsZSwgdGhydSBULUxE UCB5b3UgaGF2ZQ0KbGVhcm50IGFib3V0IGxlYXZlcyBMMSwgTDIsIEwzLCBMNCA8YnI+DQomZ3Q7 IGJ1dCBMNCBjb3VsZG6hr3Qgam9pbiBhbmQgaXMgc3R1Y2sgaW4gc29tZSB0cmFuc2l0IG5vZGUg KGUuZyBubyA8YnI+DQomZ3Q7IHNlc3Npb24vaGVsbG8gYWRqYWNlbmN5IHRvIHVwc3RyZWFtIGV0 YykuIFRoZW4gY2hvb3NpbmcgdGhlIHRyZWUgZm9yPGJyPg0KJmd0OyBhbiBhcHBsaWNhdGlvbiB0 aGF0IHdhbnRzIHRvIHRhbGsgdG8gTDEsTDIsTDMgYW5kIEw0IG1heSBpbXBhY3QgdGhlDQo8YnI+ DQomZ3Q7IGFwcGxpY2F0aW9uIGRlbGl2ZXJ5LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+W0xpemhvbmddIEkgdW5kZXJzdGFuZCB5b3UgY29uY2VybiwNCmJ1dCBJ IHRoaW5rIHJlYWNoYWJpbGl0eSBpcyB0aGUgcmVwb25zYWJpbGl0eSBvZiBPQU0gdG9vbHMuPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7ICZuYnNw OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyBDaGVlcnMs PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IFByYW5qYWw8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgJm5ic3A7PC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7ICZuYnNwOzwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyA8YnI+DQomZ3Q7IEZy b206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmDQpPZiA8YnI+DQomZ3Q7IExpemhvbmcgSmluPGJyPg0KJmd0OyBTZW50OiBUdWVz ZGF5LCBBdWd1c3QgMDcsIDIwMTIgNjozNiBQTTxicj4NCiZndDsgVG86IGVyb3NlbkBjaXNjby5j b208YnI+DQomZ3Q7IENjOiBtcGxzQGlldGYub3JnOyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9y Zzxicj4NCiZndDsgU3ViamVjdDogUmU6IFttcGxzXSB3ZyBkb2MgcG9sbCBvbiBkcmFmdC1qaW4t bXBscy1tbGRwLWxlYWYtZGlzY292ZXJ5LTA0PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj4mZ3Q7ICZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+Jmd0OyA8YnI+DQomZ3Q7IEhpIEVyaWMsIDxicj4NCiZndDsgU2VlIGlubGlu ZSBiZWxvdy4gSG9wZSB0aGUgY2xhcmlmaWNhdGlvbiBoZWxwcy4gPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IFRoYW5rcyA8YnI+DQomZ3Q7IExpemhvbmcgPGJyPg0KJmd0OyAmbmJzcDsgPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IEVyaWMgUm9zZW4gJmx0O2Vyb3NlbkBjaXNjby5jb20mZ3Q7IHdyb3RlIDIw MTIvMDgvMDcgMjM6NDI6MTM6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBUaGUgbGVh ZiBkaXNjb3ZlcnkgbWVjaGFuaXNtIGlzIG5vdCB0byBjb21wbGVtZW50IE1WUE48YnI+DQomZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhlIGxlYWYgZGlzY292ZXJ5IG1lY2hhbmlzbSBp cyB1c2VmdWwgZm9yIHJvb3QgaW5pdGlhdGVkDQphcHBsaWNhdGlvbiB0bzxicj4NCiZndDsgJmd0 OyAmZ3Q7IGFnZ3JlZ2F0ZSB0dW5uZWxzIGZyb20gbGVhZiBpbml0aWF0ZWQgYXBwbGljYXRpb24u IEZvciBleGFtcGxlLA0KaG93IHRvIGxldDxicj4NCiZndDsgJmd0OyAmZ3Q7IE1WUE4gdG8gYWdn cmVnYXRlIHRoZSBtTERQIHR1bm5lbCBnZW5lcmF0ZWQgYnkgaW4tYmFuZCBzaWduYWxpbmc/PGJy Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJJ20gY29uZnVzZWQgYnkgdGhlc2UgdHdvIHNl bnRlbmNlcywgYXMgdGhlIHNlY29uZCBtZW50aW9ucyB0aGUNCnVzZSBvZiBtbGRwPGJyPg0KJmd0 OyAmZ3Q7IGxlYWYgZGlzY292ZXJ5IGJ5IE1WUE4sIGJ1dCB0aGUgZmlyc3Qgc2F5cyB0aGF0IHlv dSBkb250JyBpbnRlbmQNCnRoZSB0d288YnI+DQomZ3Q7ICZndDsgbWVjaGFuaXNtcyB0byBiZSB1 c2VkIHRvZ2V0aGVyLiAmbmJzcDtIb3dldmVyLCBsZXQncyBhc3N1bWUgZm9yDQpub3cgdGhhdCB0 aGVyZSBpczxicj4NCiZndDsgJmd0OyBubyBNVlBOIGhlcmUsIGp1c3Qgc29tZSBtTERQIGluLWJh bmQgc2lnbmFsaW5nLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgU28gc3VwcG9zZSBQ RTIsIFBFMywgYW5kIFBFNCBqb2luIGFuIG1MRFAgdHVubmVsIHJvb3RlZCBhdCBQRTEuDQombmJz cDtTYXkgdGhlPGJyPg0KJmd0OyAmZ3Q7IHR1bm5lbCBpcyBpZGVudGlmaWVkIGJ5IHRoZSBtTERQ IEZFQyBlbGVtZW50ICZsdDtyb290PVBFMSwgb3BhcXVlPGJyPg0KJmd0OyAmZ3Q7IHZhbHVlPSZs dDtTMSxHMSZndDsmZ3Q7ICh0aGlzIGlzIGEgY2FzZSBvZiBpbi1iYW5kIHNpZ25hbGluZykuLjxi cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgTm93IFBFMiwgUEUzLCBhbmQgUEU0IGpvaW4g YW5vdGhlciBtTERQIHR1bm5lbCByb290ZWQgYXQgUEUxLA0Kc2F5PGJyPg0KJmd0OyAmZ3Q7ICZs dDtyb290PVBFMSxvcGFxdWUgdmFsdWU9Jmx0O1MyLEcyJmd0OyZndDsgKGFub3RoZXIgY2FzZSBv Zg0KaW4tYmFuZCBzaWduYWxpbmcpLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgUEUx IHNlZXMgdGhhdCB0aGUgdHdvIHR1bm5lbHMgaGF2ZSBleGFjdGx5IHRoZSBzYW1lIHNldCBvZiBs ZWFmDQpub2Rlcy4gJm5ic3A7U288YnI+DQomZ3Q7ICZndDsgd2hhdCBpcyBQRTEgc3VwcG9zZWQg dG8gZG8/IDxicj4NCiZndDsgW0xpemhvbmddIFBFMSBoYXZlIHRoZSB0dW5uZWwgJmx0O3Jvb3Q9 UEUxLCBvcGFxdWUgdmFsdWU9Jmx0O1MxLEcxJmd0OyZndDsuDQpUaGVuPGJyPg0KJmd0OyB3aGVu IFBFMSBpbml0aWF0ZXMgbmV3IE1WUE4gc2VydmljZSwgYW5kIGhhcyBsZWFmIG1lbWJlciBQRTIs IFBFMywNCjxicj4NCiZndDsgUEU0LCB0aGVuIFBFMSBpcyBub3QgbmVjZXNzYXJ5IHRvIGluaXRp YXRlIG5ldyBtTERQIHR1bm5lbCwgYnV0IDxicj4NCiZndDsgZGlyZWN0bHkgYWdncmVhdGUgdG8g dHVubmVsICZsdDtyb290PVBFMSwgb3BhcXVlIHZhbHVlPSZsdDtTMSxHMSZndDsmZ3Q7DQpmb3Ig PGJyPg0KJmd0OyBNVlBOIHNlcnZpY2UuIElmIFBFMSBkb2VzIG5vdCBoYXZlIHRoZSBsZWFmIGlu Zm9ybWF0aW9uIG9mIHR1bm5lbA0KPGJyPg0KJmd0OyAmbHQ7cm9vdD1QRTEsIG9wYXF1ZSB2YWx1 ZT0mbHQ7UzEsRzEmZ3Q7Jmd0OywgdGhlbiBQRTEgY291bGQgbm90IGFnZ3JlZ2F0ZQ0KTVZQTiA8 YnI+DQomZ3Q7IHNlcnZpY2UgdG8gdGhhdCB0dW5uZWwuIEFuZCBMZWFmIEEtRCByb3V0ZSBpbiBN VlBOIGNvdWxkIG5vdCBoZWxwDQo8YnI+DQomZ3Q7IFBFMSB0byBmaW5kIHRoZSBsZWFmIGluZm9y bWF0aW9uIG9mIHR1bm5lbCAmbHQ7cm9vdD1QRTEsIG9wYXF1ZSA8YnI+DQomZ3Q7IHZhbHVlPSZs dDtTMSxHMSZndDsmZ3Q7LiBUaGF0IG1lYW5zIHR3byBkaWZmZXJlbnQga2luZCBvZiBhcHBsaWNh dGlvbnMNCmNvdWxkIDxicj4NCiZndDsgc2hhcmUgb25lIHR1bm5lbCB3aGljaCBpcyB0aGlzIGRy YWZ0IHRyeWluZyB0byBzb2x2ZS4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgdGhlIHJvb3Qgbm9kZSBoYXMgdGhlIGNhcGFiaWxpdHkgdG8gYWdncmVnYXRl IGV4aXN0aW5nIHR1bm5lbA0KaW5zdGVhZCBvZjxicj4NCiZndDsgJmd0OyAmZ3Q7IGNyZWF0aW5n IGFuIGFkZGl0aW9uYWwgb25lLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgQSBmZXcg cXVlc3Rpb25zOjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgLSBIb3cgZG9lcyBpdCBk byB0aGlzPyAmbmJzcDtUaGVyZSBkb2Vzbid0IHNlZW0gdG8gYmUgYW55IG1lY2hhbmlzbQ0KdG8g ZG8gdGhpcy48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAqIFdoYXQgd2ls bCBjYXVzZSBQRTIsUEUzLFBFNCB0byBleHBlY3QgKFMyLEcyKSB0cmFmZmljDQpvbiB0aGUgJmx0 O3Jvb3Q9UEUxLDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IG9wYXF1ZSB2YWx1ZT0mbHQ7 UzEsRzEmZ3Q7Jmd0OyB0dW5uZWw/PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmbmJz cDsgKiBXaGF0IHdpbGwgY2F1c2UgdGhlIHRlYXJkb3duIG9mIHRoZSBwYXJ0aWFsbHkgc2V0IHVw DQp0dW5uZWwgJmx0O1BFMSxTMixHMiZndDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBh dCB0aGUgUCByb3V0ZXJzIGFuZCBQRSByb3V0ZXJzPzxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7 ICZndDsgLSBIb3cgZG9lcyB0aGUgcm9vdCBub2RlJ3MgYWdncmVnYXRpb24gc3RyYXRlZ3kgcmVz cG9uZCB0byBkeW5hbWljYWxseTxicj4NCiZndDsgJmd0OyAmbmJzcDsgY2hhbmdpbmcgc2V0cyBv ZiBsZWFmIG5vZGVzPyAmbmJzcDsoUmVtZW1iZXIgdGhlIGxlYWYNCm5vZGVzIGpvaW4gYW5kIGxl YXZlIHRoZTxicj4NCiZndDsgJmd0OyAmbmJzcDsgTFNQIG9uZSBhdCBhIHRpbWUuKTxicj4NCiZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgLSBIb3cgZG9lcyB0aGUgcm9vdCBub2RlIGV2ZW4ga25v dyB0aGF0IHRoZSBsZWFmIG5vZGVzIGNhbiBjb3JyZWN0bHkNCmhhbmRsZTxicj4NCiZndDsgJmd0 OyAmbmJzcDsgdHJhZmZpYyBmcm9tIGFuIGFnZ3JlZ2F0ZWQgdHVubmVsPzxicj4NCiZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgSSBkb24ndCB0aGluayBhbnkgb2YgdGhpcyBjYW4gYmUgZG9uZSB3 aXRob3V0IHNvbWUgYXBwbGljYXRpb24tbGF5ZXI8YnI+DQomZ3Q7ICZndDsgc2lnbmFsaW5nIGJl dHdlZW4gdGhlIHJvb3QgYW5kIGxlYWYgbm9kZXMuICZuYnNwO0J1dCBpZiB0aGVyZQ0KaXM8YnI+ DQomZ3Q7ICZndDsgYXBwbGljYXRpb24tbGF5ZXIgc2lnbmFsaW5nIGJldHdlZW4gdGhlIHJvb3Qg YW5kIGxlYWYgbm9kZXMsDQp3aHkgZG9lc24ndDxicj4NCiZndDsgJmd0OyB0aGF0IHByb3ZpZGUg YWxsIHRoZSBuZWNlc3NhcnkgYXV0by1kaXNjb3Zlcnk/IDxicj4NCiZndDsgW0xpemhvbmddIGFz IHN0YXRlZCBhYm92ZSwgdGhpcyBkcmFmdCBkaWQgbm90IHRyeSB0byBoZWxwIGFnZ3JlZ2F0ZQ0K PGJyPg0KJmd0OyB0dW5uZWwgJmx0O3Jvb3Q9UEUxLCBvcGFxdWUgdmFsdWU9Jmx0O1MxLEcxJmd0 OyZndDsgYW5kICZsdDtyb290PVBFMSwNCm9wYXF1ZSA8YnI+DQomZ3Q7IHZhbHVlPSZsdDtTMixH MiZndDsmZ3Q7LCBidXQgaGVscCB0byBhZ2dyZWdhdGUgdHVubmVscyBmcm9tIGRpZmZlcmVudA0K a2luZHMgPGJyPg0KJmd0OyBvZiBhcHBsaWNhdGlvbnMsIG9yIHRvIGxldCBsZWFmIGluaXRpYXRl ZCBhcHBsaWNhdGlvbiBhbmQgcm9vdCA8YnI+DQomZ3Q7IGluaXRpYXRlZCBhcHBsaWNhdGlvbiB0 byBzaGFyZSBvbmUgdHVubmVsLiBFLmcsIGVuYWJsZSBNVlBOIHRvIHVzZQ0KPGJyPg0KJmd0OyB0 dW5uZWwgJmx0O3Jvb3Q9UEUxLCBvcGFxdWUgdmFsdWU9Jmx0O1MxLEcxJmd0OyZndDsuIDxicj4N CiZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IGxlYWYgZGlzY292ZXJ5 IGRpZCBub3QgaW50cm9kdWNlIG11Y2ggYWRkaXRpb25hbCBuZXcgVC1MRFANCnNlc3Npb24sIGJ1 dDxicj4NCiZndDsgJmd0OyAmZ3Q7IG1vc3RseSByZWx5IG9uIHRoZSBleGlzdGluZyBULUxEUCBz ZXNzaW9uIHByb3ZpZGVkIGJ5IHRoZQ0KYXBwbGljYXRpb24uPGJyPg0KJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyBJZiB5b3Ugd2FudCB0byBmb2N1cyBvbiBhIHVzZSBjYXNlIHdoZXJlIHRoZXJl IGlzIGFscmVhZHkgVC1MRFANCnNpZ25hbGluZzxicj4NCiZndDsgJmd0OyBmb3Igc29tZSBhcHBs aWNhdGlvbiwgeW91IGhhdmUgdG8gc2hvdyB0aGF0IHNvbWUgcmVxdWlyZW1lbnQNCmlzIG5vdCBt ZXQgYnk8YnI+DQomZ3Q7ICZndDsgdGhlIGV4aXN0aW5nIFQtTERQIHNpZ25hbGluZyBmb3IgdGhh dCBhcHBsaWNhdGlvbi48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 IC0gJm5ic3A7IDxicj4NCiZndDsgJmd0OyA8L2ZvbnQ+DQo= --=_alternative 0019B44D48257A55_=-- From eosborne@cisco.com Thu Aug 9 05:22: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 2AD5F21F868A for ; Thu, 9 Aug 2012 05:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Q8LRChWDyke for ; Thu, 9 Aug 2012 05:22:26 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7276121F86C5 for ; Thu, 9 Aug 2012 05:22:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=1216; q=dns/txt; s=iport; t=1344514945; x=1345724545; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Xm+FE5p3Mz5lm/sv9tGMkCZAMR1sPnFdj3qcXat8f/0=; b=cqOLMW17fAJpbCuWP7vNrvPN0AyfHdARXhnYHaQX5NrzWCQ7SZrBJTuG uJ2MHLEoiu6xkDu7TxXCDtcHPhm1zeSIhm72GoIFvpH2xpV9kypCfsnca 4qOfIaeZ599+f2+RwdwYM3hhc9TUlK18sIx0GuY9n4q0JnUKWpwM0raTH g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAN+qI1CtJXG+/2dsb2JhbABFuV+BB4IgAQEBAwESASc/BQsCAQgiFBAyJQIEAQ0NGodlBgucBaBfkRdgA6NygWaCXw X-IronPort-AV: E=Sophos;i="4.77,739,1336348800"; d="scan'208";a="109929490" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 09 Aug 2012 12:22:23 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q79CMNR8026272 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Aug 2012 12:22:23 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0298.004; Thu, 9 Aug 2012 07:22:23 -0500 From: "Eric Osborne (eosborne)" To: Xuxiaohu , "Eric Rosen (erosen)" Thread-Topic: Comments on MPLS-in-UDP Thread-Index: AQHNdIEAkfCDwjMvAUa1dYjrrKc2pZdOc4cAgAD99ICAAFevoIABRCIAgABZtxA= Date: Thu, 9 Aug 2012 12:22:22 +0000 Message-ID: <20ECF67871905846A80F77F8F4A275720F53D5DD@xmb-rcd-x09.cisco.com> References: Your message of Mon, 30 Jul 2012 18:03:44 -0000. <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753B3A1@szxeml525-mbx.china.huawei.com> <9398.1344282664@erosen-linux> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753EB93@szxeml525-mbx.china.huawei.com> <20ECF67871905846A80F77F8F4A275720F5396EC@xmb-rcd-x09.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753EE7F@szxeml525-mbx.china.huawei.com> <20ECF67871905846A80F77F8F4A275720F53BAB7@xmb-rcd-x09.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753F1F5@szxeml525-mbx.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753F1F5@szxeml525-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.23.87] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19096.006 x-tm-as-result: No--40.532600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on 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: Thu, 09 Aug 2012 12:22:27 -0000 ... > Hi Eric, >=20 > As stated in section 6 of RFC6335, "...the Dynamic Ports, also known as t= he > Private or Ephemeral Ports, from 49152-65535 (never assigned)..." In > addition, the specific destination port number to be assigned by IANA can > indicate the payload of the UDP is a MPLS packet. Hence I don't understan= d > why it would cause any problem. Could you please explain your concerns > with a concrete example? The ephemeral range is used for source port numbers. =20 http://en.wikipedia.org/wiki/Ephemeral_port If a host stack on a router allocates source port 50000 to be used to talk = to a particular server and your scheme also uses source port 50000 at the s= ame time due to hashing, you have two distinct applications using the same = source port. This is Bad, as I can see it breaking things like on-router f= irewalls and anything in the middle. In order to avoid this collision you need to ensure that your hashing doesn= 't collide with your ephemeral port allocation, which could mean a ton of r= eal-time coordination between forwarding hardware and the host stack. eric >=20 > Best regards, > Xiaohu >=20 >=20 > > > > > > > > eric > > From erosen@cisco.com Thu Aug 9 07: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 7EA0021F86BB for ; Thu, 9 Aug 2012 07:24:31 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEtuYKlhCbgP for ; Thu, 9 Aug 2012 07:24:30 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id DD52521F85B8 for ; Thu, 9 Aug 2012 07:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=erosen@cisco.com; l=972; q=dns/txt; s=iport; t=1344522270; x=1345731870; h=to:cc:subject:in-reply-to:reply-to:date:message-id:from; bh=D2tzXGOItiFw8v7uPD1al28SL4tzvvrAbPoFu0nVylk=; b=bW4MgHjzZ0IlLrRNRtYntj4Ju5JZZSs7j83aJvKtpFnLVkTM/Wnr9ZCS gKoR18MjOVuzy2qbGm8jgqOqifWn+El36OEY6vJyG0Rnn1rVflRNTH1tM ok6j5HR0d3r1zQc6y85sFax5NkGVn56c7QHk0OKwHYkB66JwGNW5k3IWb 4=; X-IronPort-AV: E=Sophos;i="4.77,740,1336348800"; d="scan'208";a="54544344" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 09 Aug 2012 14:24:30 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q79EOTZ5023355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Aug 2012 14:24:30 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id q79EOTxU024043; Thu, 9 Aug 2012 10:24:29 -0400 To: Xuxiaohu In-reply-to: Your message of Thu, 09 Aug 2012 01:49:42 -0000. <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753F1F5@szxeml525-mbx.china.huawei.com> Date: Thu, 09 Aug 2012 10:24:29 -0400 Message-ID: <24042.1344522269@erosen-linux> From: Eric Rosen Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on MPLS-in-UDP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 14:24:31 -0000 A few more miscellaneous comments. How many possible hash values are actually needed? Probably not 2**14. If ECMP in the transit nodes uses only four equal cost paths, say, can't one achieve the necessary entropy with just four hash values? If one uses a small number of hash values, I wonder if it would be better to use the "destination port" field rather than the "source port" field to convey the entropy. The possible destination port values could even be dynamically allocated by the receiving endpoint of the UDP "tunnel" and signaled to the transmitting endpoint. (We know there's already some signaling between the tunnel endpoints, since the MPLS labels have to be signaled.) It's convenient to use the port number to indicate whether the top label of the payload packet is downstream-assigned or upstream-assigned, but it's not strictly necessary to do so, as one could devise a way to indicate this in the first word of the payload. From akatlas@gmail.com Thu Aug 9 07:36: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 81CEF21F85CD for ; Thu, 9 Aug 2012 07:36:42 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhMyj7eS4uX7 for ; Thu, 9 Aug 2012 07:36:42 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id ABE4A21F85CC for ; Thu, 9 Aug 2012 07:36:41 -0700 (PDT) Received: by weyu54 with SMTP id u54so399728wey.31 for ; Thu, 09 Aug 2012 07:36:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Z2mmLRO5x77K6g3Ponw1IXQNdxdLmVi9QcPfJxjwBQ8=; b=0JSfhRrfdZhZqFl06aawnRvHWH+p46EMS5zY4tckGlZnxJd9GoRBkCzPQCSk/7JR4T VnlZZtLnJxoPjgQJ6hee6Mu2Z10yYR1/9SStg9Nq1R03D0GsmxJC/cWH7t2+LrTzTO4E ynkxig2Bo54Xbh5ZjflrVEn2hA4WS0ALQSf9OT2ZXKhFimct2XmuYJ4TIOGO6Wv8etui FhlD/dsJ3u9X8tbHcCHYIJCJJ460as/TecBwMAWR9nSMqMd/NdxMhKS8IQ6yQEqYzHhM jelazTvNIdP2JtL7+ctA/WAW+8DMEOhZTxMZYt78uua+RCXw4xsfS1NJjCTy0CarUvlc MQBA== MIME-Version: 1.0 Received: by 10.50.158.199 with SMTP id ww7mr1200066igb.58.1344523000213; Thu, 09 Aug 2012 07:36:40 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Thu, 9 Aug 2012 07:36:40 -0700 (PDT) In-Reply-To: <24042.1344522269@erosen-linux> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753F1F5@szxeml525-mbx.china.huawei.com> <24042.1344522269@erosen-linux> Date: Thu, 9 Aug 2012 10:36:40 -0400 Message-ID: From: Alia Atlas To: erosen@cisco.com Content-Type: text/plain; charset=ISO-8859-1 Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on 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: Thu, 09 Aug 2012 14:36:42 -0000 The number of hash values needed depends on how many transit nodes there are, the number of paths at each of those, and how well hash diversity is maintained on each path. Say there are 3 transit nodes with 4 paths each- with perfect splitting, then one needs to specify 64 different hash values. Perfect splitting isn't likely either. This isn't to say that a new encapsulation method is needed - but the problem of hashing is real. Alia On Thu, Aug 9, 2012 at 10:24 AM, Eric Rosen wrote: > A few more miscellaneous comments. > > How many possible hash values are actually needed? Probably not 2**14. If > ECMP in the transit nodes uses only four equal cost paths, say, can't one > achieve the necessary entropy with just four hash values? > > If one uses a small number of hash values, I wonder if it would be better to > use the "destination port" field rather than the "source port" field to > convey the entropy. The possible destination port values could even be > dynamically allocated by the receiving endpoint of the UDP "tunnel" and > signaled to the transmitting endpoint. (We know there's already some > signaling between the tunnel endpoints, since the MPLS labels have to be > signaled.) > > It's convenient to use the port number to indicate whether the top label of > the payload packet is downstream-assigned or upstream-assigned, but it's not > strictly necessary to do so, as one could devise a way to indicate this in > the first word of the payload. > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From eosborne@cisco.com Thu Aug 9 07:43: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 5BEB421F86D7 for ; Thu, 9 Aug 2012 07:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.532 X-Spam-Level: X-Spam-Status: No, score=-10.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctLJcvLHYAAk for ; Thu, 9 Aug 2012 07:43:29 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 322CF21F86D1 for ; Thu, 9 Aug 2012 07:43:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=1488; q=dns/txt; s=iport; t=1344523403; x=1345733003; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=UUyPXUc6e28JiQLPJmI2LUahxpjlOwhDNqQ4h9lWgtA=; b=LBwN5bCD9qivj3IyW/W6vAuTxCIaXGm3Zz7bfS5dQ/SNR8tipDouZ543 eH5NNcRvM2gXNgxf25h7qLMIy/N7aeTJ31oGn+lPmKMnmP7DQfSyLB5QR RKvgJdPRHWome3zryu4OqQsf4DtGc93HSZqV6NCy5xdWO96V9fWtMx4Bl c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACjLI1CtJXG9/2dsb2JhbABFuWKBB4IgAQEBBBIBJz8MBAIBCBEEAQELFBAyHQgCBAENBQgah2ubc6Bsiw+GBGADo3KBZoJf X-IronPort-AV: E=Sophos;i="4.77,740,1336348800"; d="scan'208";a="109974495" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 09 Aug 2012 14:43:22 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q79EhMA4012201 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Aug 2012 14:43:22 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0298.004; Thu, 9 Aug 2012 09:43:22 -0500 From: "Eric Osborne (eosborne)" To: "Eric Rosen (erosen)" , Xuxiaohu Thread-Topic: Comments on MPLS-in-UDP Thread-Index: AQHNdjqvkfCDwjMvAUa1dYjrrKc2pZdRjf9A Date: Thu, 9 Aug 2012 14:43:22 +0000 Message-ID: <20ECF67871905846A80F77F8F4A275720F53D868@xmb-rcd-x09.cisco.com> References: Your message of Thu, 09 Aug 2012 01:49:42 -0000. <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753F1F5@szxeml525-mbx.china.huawei.com> <24042.1344522269@erosen-linux> In-Reply-To: <24042.1344522269@erosen-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.23.87] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19096.004 x-tm-as-result: No--31.803500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on 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: Thu, 09 Aug 2012 14:43:30 -0000 If you have four paths and each hop has an arbitrary (proprietary, in most = cases) hash algorithm, don't you need far more than four hash values to ens= ure decent distribution across the buckets? eric > -----Original Message----- > From: Eric Rosen (erosen) > Sent: Thursday, August 09, 2012 10:24 AM > To: Xuxiaohu > Cc: Eric Osborne (eosborne); Eric Rosen (erosen); mpls@ietf.org > Subject: Re: Comments on MPLS-in-UDP >=20 > A few more miscellaneous comments. >=20 > How many possible hash values are actually needed? Probably not 2**14. = If > ECMP in the transit nodes uses only four equal cost paths, say, can't one > achieve the necessary entropy with just four hash values? >=20 > If one uses a small number of hash values, I wonder if it would be better= to > use the "destination port" field rather than the "source port" field to > convey the entropy. The possible destination port values could even be > dynamically allocated by the receiving endpoint of the UDP "tunnel" and > signaled to the transmitting endpoint. (We know there's already some > signaling between the tunnel endpoints, since the MPLS labels have to be > signaled.) >=20 > It's convenient to use the port number to indicate whether the top label = of > the payload packet is downstream-assigned or upstream-assigned, but it's > not > strictly necessary to do so, as one could devise a way to indicate this i= n > the first word of the payload. >=20 >=20 From erosen@cisco.com Thu Aug 9 07:43: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 E060521F86E5 for ; Thu, 9 Aug 2012 07:43:47 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dX4Ta-4cS-FG for ; Thu, 9 Aug 2012 07:43:47 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id E65DC21F86E4 for ; Thu, 9 Aug 2012 07:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=erosen@cisco.com; l=1097; q=dns/txt; s=iport; t=1344523426; x=1345733026; h=to:cc:subject:in-reply-to:reply-to:date:message-id:from; bh=rklCg+uoNdSOJAqAdSPjDautDhodohDWUJSqgq69lJ4=; b=QKnSC9e3UaAF+WBTs6RHputQNa7qje4JNFX52VxpAGAJMwhlKA7RSi/O bggWm9IcXDFk1d8F9ZcZn3iIS7JVEAjdfuhL9UUM5gqWkwZM/sAFOfwiy K+iws6RvJ0JNnXrnP6Zd75yLMkU/fn7+VFwNIA/nF5//8fAsHkXOKtw+c o=; X-IronPort-AV: E=Sophos;i="4.77,740,1336348800"; d="scan'208";a="51433682" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 09 Aug 2012 14:43:46 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q79EhjUO015716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Aug 2012 14:43:46 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id q79Ehik2024247; Thu, 9 Aug 2012 10:43:44 -0400 To: Lizhong Jin In-reply-to: Your message of Wed, 08 Aug 2012 09:36:04 +0800. Date: Thu, 09 Aug 2012 10:43:44 -0400 Message-ID: <24246.1344523424@erosen-linux> From: Eric Rosen Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 14:43:48 -0000 Lizhong> PE1 has the tunnel >. Then when PE1 Lizhong> initiates new MVPN service, and has leaf members PE2, PE3, PE4, PE1 Lizhong> does not need to initiate a new mLDP tunnel, In the MVPN procedures, PE1 generally advertises a tunnel before it knows which other PEs need to join the tunnel. Lizhong> but directly aggrgeate to tunnel > Lizhong> for MVPN service ... That means two different kinds of application Lizhong> could share one tunnel, which is what this draft is trying to Lizhong> solve. If PE1 sends the MVPN traffic into a tunnel that is being used by another application, how will the leaf nodes know which traffic belongs to which application? I think this would require a demultiplexor field which is understood by both applications. Also, if the (S1,G1) flow stops while the MVPN application continues, it will be necessary to leave the > tunnel in place. This may cause a problem if the (S1,G1) flow later resumes, but with a different set of receivers. From erosen@cisco.com Thu Aug 9 08:16: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 A341821F866E for ; Thu, 9 Aug 2012 08:16:40 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRxFHFZcHRVp for ; Thu, 9 Aug 2012 08:16:39 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id D5E0521F8621 for ; Thu, 9 Aug 2012 08:16:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=erosen@cisco.com; l=708; q=dns/txt; s=iport; t=1344525400; x=1345735000; h=to:cc:subject:in-reply-to:reply-to:date:message-id:from; bh=7jXNt5zwCMD0NSUr53ftqEMz2XUC9N9VpA+xKfuSanI=; b=bWhVkKh/op38jbMbmtjWAUjNreCv7WMTLCYVCWtbzXA+pu2HqMxVxdho JA+x73J4p//8BLFbCE8CSgzEeKTAinNHrZfYqfF5b9Qx2UuuxZuuuFJt2 yc9zFs44ewdIcvxgR/Hj9uCypzHzbMYwD2DLwPc+fXDCQ24YHoLgsdPIW M=; X-IronPort-AV: E=Sophos;i="4.77,740,1336348800"; d="scan'208";a="110016544" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 09 Aug 2012 15:16:39 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q79FGbfO020012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Aug 2012 15:16:38 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id q79FGaYa024630; Thu, 9 Aug 2012 11:16:36 -0400 To: Alia Atlas In-reply-to: Your message of Thu, 09 Aug 2012 10:36:40 -0400. Date: Thu, 09 Aug 2012 11:16:36 -0400 Message-ID: <24629.1344525396@erosen-linux> From: Eric Rosen Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on MPLS-in-UDP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 15:16:40 -0000 Alia> Say there are 3 transit nodes with 4 paths each- with perfect Alia> splitting, then one needs to specify 64 different hash values. Eric O> If you have four paths and each hop has an arbitrary (proprietary, in Eric O> most cases) hash algorithm, don't you need far more than four hash Eric O> values to ensure decent distribution across the buckets? Yes, sorry, don't know what I was thinking. If the DC environment requires anything like a 2**n-way (or more) split, and/or if the hashing algorithms are proprietary, you want as many hash buckets as possible. But the more hash values you need, the less attractive it becomes to store the hash value in either of the UDP port fields. From csekar@juniper.net Thu Aug 9 10:22: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 D605821F86F7 for ; Thu, 9 Aug 2012 10:22:54 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydDymEzFln2c for ; Thu, 9 Aug 2012 10:22:54 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3A921F86FC for ; Thu, 9 Aug 2012 10:22:45 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUCPx5XiGQ2KzZU/fE6GRYdHofJTIvToh@postini.com; Thu, 09 Aug 2012 10:22:54 PDT Received: from p-emfe02-bng.jnpr.net (10.211.204.20) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 9 Aug 2012 10:21:43 -0700 Received: from EMBX02-BNG.jnpr.net ([fe80::8ce3:7a6:9990:3c6e]) by p-emfe02-bng.jnpr.net ([::1]) with mapi; Thu, 9 Aug 2012 22:51:42 +0530 From: Chandrasekar R To: Lizhong Jin , "erosen@cisco.com" Date: Thu, 9 Aug 2012 22:51:41 +0530 Thread-Topic: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-04 Thread-Index: Ac11BlVzPWK94DC3TIeFFK+Lb55gEQBSbS1g Message-ID: <105EB9F002CB164DA9ADD111BFC4DCFF1C957F24@EMBX02-BNG.jnpr.net> References: <20570.1344354133@erosen-linux> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_105EB9F002CB164DA9ADD111BFC4DCFF1C957F24EMBX02BNGjnprne_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-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, 09 Aug 2012 17:22:55 -0000 --_000_105EB9F002CB164DA9ADD111BFC4DCFF1C957F24EMBX02BNGjnprne_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI Lizhong, [Lizhong] PE1 have the tunnel >. Then wh= en PE1 initiates new MVPN service, and has leaf member PE2, PE3, PE4, then = PE1 is not necessary to initiate new mLDP tunnel, but directly aggreate to = tunnel > for MVPN service. If PE1 does n= ot have the leaf information of tunnel >= , then PE1 could not aggregate MVPN service to that tunnel. And Leaf A-D ro= ute in MVPN could not help PE1 to find the leaf information of tunnel >. That means two different kind of applicati= ons could share one tunnel which is this draft trying to solve. [Chandra] How does the leaf PE differentiate between the mLDP traffic (S1, = G1) and the MVPN traffic whose source/group addresses could be on a differe= nt address space? If aggregating mLDP tunnels across different applications is the primary go= al of the draft, then we should first establish whether the traffic of thos= e applications can be actually aggregated. Regards, Chandra. --_000_105EB9F002CB164DA9ADD111BFC4DCFF1C957F24EMBX02BNGjnprne_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

HI Lizhon= g,

 

[Lizh= ong] PE1 have the tunnel <root=3DPE1, opaque value=3D<S1,G1>>. = Then when PE1 initiates new MVPN service, and has leaf member PE2, PE3, PE4= , then PE1 is not necessary to initiate new mLDP tunnel, but directly aggre= ate to tunnel <root=3DPE1, opaque value=3D<S1,G1>> for MVPN ser= vice. If PE1 does not have the leaf information of tunnel <root=3DPE1, o= paque value=3D<S1,G1>>, then PE1 could not aggregate MVPN service = to that tunnel. And Leaf A-D route in MVPN could not help PE1 to find the l= eaf information of tunnel <root=3DPE1, opaque value=3D<S1,G1>>.= That means two different kind of applications could share one tunnel which= is this draft trying to solve.

[Chandra] How does the leaf PE differentiate= between the mLDP traffic (S1, G1) and the MVPN traffic whose source/group = addresses could be on a different address space?<= /p>

 

If aggregating mLDP tunnels across differen= t applications is the primary goal of the draft, then we should first estab= lish whether the traffic of those applications can be actually aggregated.<= o:p>

 <= /o:p>

Regards,

Chandra.<= /span>

= --_000_105EB9F002CB164DA9ADD111BFC4DCFF1C957F24EMBX02BNGjnprne_-- From xuxiaohu@huawei.com Thu Aug 9 18:03: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 2A4E521F853E for ; Thu, 9 Aug 2012 18:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=-0.517, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJTb4qWgotY9 for ; Thu, 9 Aug 2012 18:03:49 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3273621F853C for ; Thu, 9 Aug 2012 18:03:49 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIS08735; Thu, 09 Aug 2012 17:03:48 -0800 (PST) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 9 Aug 2012 18:01:27 -0700 Received: from SZXEML437-HUB.china.huawei.com (10.72.61.72) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 9 Aug 2012 18:01:25 -0700 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.5]) by szxeml437-hub.china.huawei.com ([10.72.61.72]) with mapi id 14.01.0323.003; Fri, 10 Aug 2012 09:01:05 +0800 From: Xuxiaohu To: "Eric Osborne (eosborne)" , "Eric Rosen (erosen)" Thread-Topic: Comments on MPLS-in-UDP Thread-Index: AQHNdAzUtdwdCzXyaEe3xLHRR7iIc5dOB+Tg///myACAAS1rQIAAKNYAgAFym+CAAC2CAIABWAAw Date: Fri, 10 Aug 2012 01:01:05 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753F54F@szxeml525-mbx.china.huawei.com> References: Your message of Mon, 30 Jul 2012 18:03:44 -0000. <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753B3A1@szxeml525-mbx.china.huawei.com> <9398.1344282664@erosen-linux> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753EB93@szxeml525-mbx.china.huawei.com> <20ECF67871905846A80F77F8F4A275720F5396EC@xmb-rcd-x09.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753EE7F@szxeml525-mbx.china.huawei.com> <20ECF67871905846A80F77F8F4A275720F53BAB7@xmb-rcd-x09.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753F1F5@szxeml525-mbx.china.huawei.com> <20ECF67871905846A80F77F8F4A275720F53D5DD@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A275720F53D5DD@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.99.24] 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] Comments on 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, 10 Aug 2012 01:03:50 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogRXJpYyBPc2Jvcm5lIChlb3Nib3Ju ZSkgW21haWx0bzplb3Nib3JuZUBjaXNjby5jb21dDQo+ILeiy83KsbzkOiAyMDEyxOo41MI5yNUg MjA6MjINCj4gytW8/sjLOiBYdXhpYW9odTsgRXJpYyBSb3NlbiAoZXJvc2VuKQ0KPiCzrcvNOiBt cGxzQGlldGYub3JnDQo+INb3zOI6IFJFOiBDb21tZW50cyBvbiBNUExTLWluLVVEUA0KPiANCj4g Li4uDQo+IA0KPiA+IEhpIEVyaWMsDQo+ID4NCj4gPiBBcyBzdGF0ZWQgaW4gc2VjdGlvbiA2IG9m IFJGQzYzMzUsICIuLi50aGUgRHluYW1pYyBQb3J0cywgYWxzbyBrbm93biBhcyB0aGUNCj4gPiBQ cml2YXRlIG9yIEVwaGVtZXJhbCBQb3J0cywgZnJvbSA0OTE1Mi02NTUzNSAobmV2ZXIgYXNzaWdu ZWQpLi4uIiAgSW4NCj4gPiBhZGRpdGlvbiwgdGhlIHNwZWNpZmljIGRlc3RpbmF0aW9uIHBvcnQg bnVtYmVyIHRvIGJlIGFzc2lnbmVkIGJ5IElBTkEgY2FuDQo+ID4gaW5kaWNhdGUgdGhlIHBheWxv YWQgb2YgdGhlIFVEUCBpcyBhIE1QTFMgcGFja2V0LiBIZW5jZSBJIGRvbid0IHVuZGVyc3RhbmQN Cj4gPiB3aHkgaXQgd291bGQgY2F1c2UgYW55IHByb2JsZW0uIENvdWxkIHlvdSBwbGVhc2UgZXhw bGFpbiB5b3VyIGNvbmNlcm5zDQo+ID4gd2l0aCBhIGNvbmNyZXRlIGV4YW1wbGU/DQo+IA0KPiBU aGUgZXBoZW1lcmFsIHJhbmdlIGlzIHVzZWQgZm9yIHNvdXJjZSBwb3J0IG51bWJlcnMuDQo+IGh0 dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvRXBoZW1lcmFsX3BvcnQNCj4gDQo+IElmIGEgaG9z dCBzdGFjayBvbiBhIHJvdXRlciBhbGxvY2F0ZXMgc291cmNlIHBvcnQgNTAwMDAgdG8gYmUgdXNl ZCB0byB0YWxrIHRvIGENCj4gcGFydGljdWxhciBzZXJ2ZXIgYW5kIHlvdXIgc2NoZW1lIGFsc28g dXNlcyBzb3VyY2UgcG9ydCA1MDAwMCBhdCB0aGUgc2FtZQ0KPiB0aW1lIGR1ZSB0byBoYXNoaW5n LCB5b3UgaGF2ZSB0d28gZGlzdGluY3QgYXBwbGljYXRpb25zIHVzaW5nIHRoZSBzYW1lIHNvdXJj ZQ0KPiBwb3J0LiAgVGhpcyBpcyBCYWQsIGFzIEkgY2FuIHNlZSBpdCBicmVha2luZyB0aGluZ3Mg bGlrZSBvbi1yb3V0ZXIgZmlyZXdhbGxzIGFuZA0KPiBhbnl0aGluZyBpbiB0aGUgbWlkZGxlLg0K DQpEbyB5b3UgYmVsaWV2ZSB0aGF0IG9uLXJvdXRlciBmaXJld2FsbHMgb3IgTkFUIGJveGVzIHdv dWxkIGJlIGRlcGxveWVkIG9uIHRoZSBwYXRoIGJldHdlZW4gUEUgcm91dGVycyBpbiBwcmFjdGlj ZT8NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4gSW4gb3JkZXIgdG8gYXZvaWQgdGhpcyBj b2xsaXNpb24geW91IG5lZWQgdG8gZW5zdXJlIHRoYXQgeW91ciBoYXNoaW5nIGRvZXNuJ3QNCj4g Y29sbGlkZSB3aXRoIHlvdXIgZXBoZW1lcmFsIHBvcnQgYWxsb2NhdGlvbiwgd2hpY2ggY291bGQg bWVhbiBhIHRvbiBvZg0KPiByZWFsLXRpbWUgY29vcmRpbmF0aW9uIGJldHdlZW4gZm9yd2FyZGlu ZyBoYXJkd2FyZSBhbmQgdGhlIGhvc3Qgc3RhY2suDQo+IA0KPiANCj4gZXJpYw0KPiANCj4gDQo+ ID4NCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gWGlhb2h1DQo+ID4NCj4gPg0KPiA+ID4NCj4gPiA+ DQo+ID4gPg0KPiA+ID4gZXJpYw0KPiA+ID4NCg0K From xuxiaohu@huawei.com Thu Aug 9 18:20: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 3FC5E21F861D for ; Thu, 9 Aug 2012 18:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=-0.506, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j67rMOJTuIau for ; Thu, 9 Aug 2012 18:20:03 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 55AD321F853F for ; Thu, 9 Aug 2012 18:20:03 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIS09534; Thu, 09 Aug 2012 17:20:03 -0800 (PST) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 9 Aug 2012 18:18:49 -0700 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 9 Aug 2012 18:18:47 -0700 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.5]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.003; Fri, 10 Aug 2012 09:18:40 +0800 From: Xuxiaohu To: "erosen@cisco.com" Thread-Topic: Comments on MPLS-in-UDP Thread-Index: AQHNdjqvtdwdCzXyaEe3xLHRR7iIc5dSPIwA Date: Fri, 10 Aug 2012 01:18:39 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753F562@szxeml525-mbx.china.huawei.com> References: Your message of Thu, 09 Aug 2012 01:49:42 -0000. <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753F1F5@szxeml525-mbx.china.huawei.com> <24042.1344522269@erosen-linux> In-Reply-To: <24042.1344522269@erosen-linux> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.24] 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] Comments on 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, 10 Aug 2012 01:20:04 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogRXJpYyBSb3NlbiBbbWFpbHRvOmVy b3NlbkBjaXNjby5jb21dDQo+ILeiy83KsbzkOiAyMDEyxOo41MI5yNUgMjI6MjQNCj4gytW8/sjL OiBYdXhpYW9odQ0KPiCzrcvNOiBFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKTsgRXJpYyBSb3NlbiAo ZXJvc2VuKTsgbXBsc0BpZXRmLm9yZw0KPiDW98ziOiBSZTogQ29tbWVudHMgb24gTVBMUy1pbi1V RFANCj4gDQo+IEEgZmV3IG1vcmUgbWlzY2VsbGFuZW91cyBjb21tZW50cy4NCj4gDQo+IEhvdyBt YW55IHBvc3NpYmxlIGhhc2ggdmFsdWVzIGFyZSBhY3R1YWxseSBuZWVkZWQ/ICBQcm9iYWJseSBu b3QgMioqMTQuICBJZg0KPiBFQ01QIGluIHRoZSB0cmFuc2l0IG5vZGVzIHVzZXMgb25seSBmb3Vy IGVxdWFsIGNvc3QgcGF0aHMsIHNheSwgY2FuJ3Qgb25lDQo+IGFjaGlldmUgdGhlIG5lY2Vzc2Fy eSBlbnRyb3B5IHdpdGgganVzdCBmb3VyIGhhc2ggdmFsdWVzPw0KPiANCj4gSWYgb25lIHVzZXMg YSBzbWFsbCBudW1iZXIgb2YgaGFzaCB2YWx1ZXMsIEkgd29uZGVyIGlmIGl0IHdvdWxkIGJlIGJl dHRlciB0bw0KPiB1c2UgdGhlICJkZXN0aW5hdGlvbiBwb3J0IiBmaWVsZCByYXRoZXIgdGhhbiB0 aGUgInNvdXJjZSBwb3J0IiBmaWVsZCB0bw0KPiBjb252ZXkgdGhlIGVudHJvcHkuICBUaGUgcG9z c2libGUgZGVzdGluYXRpb24gcG9ydCB2YWx1ZXMgY291bGQgZXZlbiBiZQ0KPiBkeW5hbWljYWxs eSBhbGxvY2F0ZWQgYnkgdGhlIHJlY2VpdmluZyBlbmRwb2ludCBvZiB0aGUgVURQICJ0dW5uZWwi IGFuZA0KPiBzaWduYWxlZCB0byB0aGUgdHJhbnNtaXR0aW5nIGVuZHBvaW50LiAgKFdlIGtub3cg dGhlcmUncyBhbHJlYWR5IHNvbWUNCj4gc2lnbmFsaW5nIGJldHdlZW4gdGhlIHR1bm5lbCBlbmRw b2ludHMsIHNpbmNlIHRoZSBNUExTIGxhYmVscyBoYXZlIHRvIGJlDQo+IHNpZ25hbGVkLikNCj4g DQo+IEl0J3MgY29udmVuaWVudCB0byB1c2UgdGhlIHBvcnQgbnVtYmVyIHRvIGluZGljYXRlIHdo ZXRoZXIgdGhlIHRvcCBsYWJlbCBvZg0KPiB0aGUgcGF5bG9hZCBwYWNrZXQgaXMgZG93bnN0cmVh bS1hc3NpZ25lZCBvciB1cHN0cmVhbS1hc3NpZ25lZCwgYnV0IGl0J3Mgbm90DQoNCkhpIEVyaWMs DQoNCkl0J3MgdGhlIHJvdXRpbmUgbWV0aG9kLCBJTUhPLg0KDQo+IHN0cmljdGx5IG5lY2Vzc2Fy eSB0byBkbyBzbywgYXMgb25lIGNvdWxkIGRldmlzZSBhIHdheSB0byBpbmRpY2F0ZSB0aGlzIGlu DQo+IHRoZSBmaXJzdCB3b3JkIG9mIHRoZSBwYXlsb2FkLg0KDQpEaWQgeW91IG1lYW4gdGhlIE1Q TFMgaGVhZGVyIGJ5IHNheWluZyB0aGUgZmlyc3Qgd29yZCBvZiB0aGUgVURQIHBheWxvYWQ/IElm IHNvLCB3aGljaCBmaWVsZCBjYW4gYmUgdXNlZCB0byBmaWxsIHRoaXMgcm9sZT8NCg0KQmVzdCBy ZWdhcmRzLA0KWGlhb2h1DQo+IA0KDQo= From lizhong.jin@zte.com.cn Thu Aug 9 18:25: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 BFB4121F85D4 for ; Thu, 9 Aug 2012 18:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.397 X-Spam-Level: X-Spam-Status: No, score=-101.397 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLXr-QlUs6ag for ; Thu, 9 Aug 2012 18:25:36 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5C121F8587 for ; Thu, 9 Aug 2012 18:25:35 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 10723806486374; Fri, 10 Aug 2012 09:12:56 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 12802.5335797074; Fri, 10 Aug 2012 09:25:31 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q7A1POb4005487; Fri, 10 Aug 2012 09:25:24 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: <24246.1344523424@erosen-linux> To: erosen@cisco.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: lizhong.jin@zte.com.cn Date: Fri, 10 Aug 2012 09:24:30 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-10 09:25:17, Serialize complete at 2012-08-10 09:25:17 Content-Type: multipart/alternative; boundary="=_alternative 0007D06B48257A56_=" X-MAIL: mse02.zte.com.cn q7A1POb4005487 Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: [mpls] DISCUSS///Re: wg doc poll on draft-jin-mpls-mldp-leaf-discovery-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, 10 Aug 2012 01:25:36 -0000 This is a multipart message in MIME format. --=_alternative 0007D06B48257A56_= Content-Type: text/plain; charset="US-ASCII" Hi Eric, I think we are on the road to get aligned. See inline below. Thanks Lizhong Eric Rosen wrote 2012/08/09 22:43:44: > > Lizhong> PE1 has the tunnel >. Then when PE1 > Lizhong> initiates new MVPN service, and has leaf members PE2, PE3, PE4, PE1 > Lizhong> does not need to initiate a new mLDP tunnel, > > In the MVPN procedures, PE1 generally advertises a tunnel before it knows > which other PEs need to join the tunnel. [Lizhong] Right, but in MVPN, if want to aggregate I/S-PMSI onto same P-Multicast tree, PE would re-advertise I/S-PMSI A-D route. It is the same here, re-advertise I/S-PMSI A-D route. > > Lizhong> but directly aggrgeate to tunnel > > Lizhong> for MVPN service ... That means two different kinds of application > Lizhong> could share one tunnel, which is what this draft is trying to > Lizhong> solve. > > If PE1 sends the MVPN traffic into a tunnel that is being used by another > application, how will the leaf nodes know which traffic belongs to which > application? > > I think this would require a demultiplexor field which is understood by both > applications. [Lizhong] right, tunnel aggregation require upstream label. But tunnel > is not necessary to have demultiplexor field for mLDP in-band service, and PHP should be disabled for this tunnel. > > Also, if the (S1,G1) flow stops while the MVPN application continues, it > will be necessary to leave the > tunnel in > place. This may cause a problem if the (S1,G1) flow later resumes, but with > a different set of receivers. [Lizhong] right, but this is not special for this draft, and I don't think this is a problem, this is general pain of multicast tunnel aggregation. The problem you referred is also existed for S-MPSI aggregation in MVPN. The deployment should balance between the pain and gain of multicast tunnel aggregation. > > > > > > --=_alternative 0007D06B48257A56_= Content-Type: text/html; charset="US-ASCII"
Hi Eric,
I think we are on the road to get aligned. See inline below.

Thanks
Lizhong
 

Eric Rosen <erosen@cisco.com> wrote 2012/08/09 22:43:44:

>
> Lizhong> PE1 has the tunnel <root=PE1, opaque value=<S1,G1>>. Then when PE1
> Lizhong> initiates new MVPN service, and has leaf members PE2, PE3, PE4, PE1
> Lizhong> does not need to initiate a new mLDP tunnel,
>
> In the MVPN procedures, PE1 generally advertises a tunnel before it knows
> which other PEs need to join the tunnel.  
[Lizhong] Right, but in MVPN, if want to aggregate I/S-PMSI onto same P-Multicast tree, PE would re-advertise I/S-PMSI A-D route. It is the same here, re-advertise I/S-PMSI A-D route.

>
> Lizhong> but directly aggrgeate to tunnel <root=PE1, opaque value=<S1,G1>>
> Lizhong> for MVPN service ... That means two different kinds of application
> Lizhong> could share one tunnel, which is what this draft is trying to
> Lizhong> solve.
>
> If PE1 sends the MVPN traffic into a tunnel that is being used by another
> application, how will the leaf nodes know which traffic belongs to which
> application?
>
> I think this would require a demultiplexor field which is understood by both
> applications.
[Lizhong] right, tunnel aggregation require upstream label. But tunnel <root=PE1, opaque value=<S1,G1>> is not necessary to have demultiplexor field for mLDP in-band service, and PHP should be disabled for this tunnel.

>
> Also, if the (S1,G1) flow stops while the MVPN application continues, it
> will be necessary to leave the <root=PE1, opaque value=<S1,G1>> tunnel in
> place.  This may cause a problem if the (S1,G1) flow later resumes, but with
> a different set of receivers.
[Lizhong] right, but this is not special for this draft, and I don't think this is a problem, this is general pain of multicast tunnel aggregation. The problem you referred is also existed for S-MPSI aggregation in MVPN. The deployment should balance between the pain and gain of multicast tunnel aggregation.

>
>
>
>
>
>
--=_alternative 0007D06B48257A56_=-- From lizhong.jin@zte.com.cn Thu Aug 9 18: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 595BB21F8587 for ; Thu, 9 Aug 2012 18:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.412 X-Spam-Level: X-Spam-Status: No, score=-101.412 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id As6NJwnn1R9A for ; Thu, 9 Aug 2012 18:25:45 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 4D14821F85E6 for ; Thu, 9 Aug 2012 18:25:45 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 10723806486374; Fri, 10 Aug 2012 09:12:44 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 1533.3994372557; Fri, 10 Aug 2012 09:25:28 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q7A1PW8f070575; Fri, 10 Aug 2012 09:25:32 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: <105EB9F002CB164DA9ADD111BFC4DCFF1C957F24@EMBX02-BNG.jnpr.net> To: Chandrasekar R MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: lizhong.jin@zte.com.cn Date: Fri, 10 Aug 2012 09:24:38 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-10 09:25:25, Serialize complete at 2012-08-10 09:25:25 Content-Type: multipart/alternative; boundary="=_alternative 0007D37448257A56_=" X-MAIL: mse01.zte.com.cn q7A1PW8f070575 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: [mpls] DISCUSS///RE: wg doc poll on draft-jin-mpls-mldp-leaf-discovery-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, 10 Aug 2012 01:25:46 -0000 This is a multipart message in MIME format. --=_alternative 0007D37448257A56_= Content-Type: text/plain; charset="US-ASCII" Chandra, Thanks for the comments. See reply below. Lizhong Chandrasekar R wrote 2012/08/10 01:21:41: > HI Lizhong, > > [Lizhong] PE1 have the tunnel >. Then > when PE1 initiates new MVPN service, and has leaf member PE2, PE3, > PE4, then PE1 is not necessary to initiate new mLDP tunnel, but > directly aggreate to tunnel > for > MVPN service. If PE1 does not have the leaf information of tunnel > >, then PE1 could not aggregate MVPN > service to that tunnel. And Leaf A-D route in MVPN could not help > PE1 to find the leaf information of tunnel value=>. That means two different kind of applications could > share one tunnel which is this draft trying to solve. > [Chandra] How does the leaf PE differentiate between the mLDP > traffic (S1, G1) and the MVPN traffic whose source/group addresses > could be on a different address space? [Lizhong] If MVPN would aggregate I/S-PMSI onto one tunnel, it should certainly advertise upstream label which is specified in RFC6514. The upstream label would be used to demultiplex the MVPN traffic. Only the mLDP traffic (S1, G1) will not have upstream label, and could be differentiated by leaf PE. Note that PHP would be disabled for this mLDP tunnel. > > If aggregating mLDP tunnels across different applications is the > primary goal of the draft, then we should first establish whether > the traffic of those applications can be actually aggregated. [Lizhong] right, and as I know, the applications listed in the draft already has upstream label advertisement in their respective RFC/Draft. > > Regards, > Chandra. --=_alternative 0007D37448257A56_= Content-Type: text/html; charset="US-ASCII"
Chandra,
Thanks for the comments. See reply below.

Lizhong


Chandrasekar R <csekar@juniper.net> wrote 2012/08/10 01:21:41:

> HI Lizhong,
>  
> [Lizhong] PE1 have the tunnel <root=PE1, opaque value=<S1,G1>>. Then
> when PE1 initiates new MVPN service, and has leaf member PE2, PE3,
> PE4, then PE1 is not necessary to initiate new mLDP tunnel, but
> directly aggreate to tunnel <root=PE1, opaque value=<S1,G1>> for
> MVPN service. If PE1 does not have the leaf information of tunnel
> <root=PE1, opaque value=<S1,G1>>, then PE1 could not aggregate MVPN
> service to that tunnel. And Leaf A-D route in MVPN could not help
> PE1 to find the leaf information of tunnel <root=PE1, opaque
> value=<S1,G1>>. That means two different kind of applications could
> share one tunnel which is this draft trying to solve.

> [Chandra] How does the leaf PE differentiate between the mLDP
> traffic (S1, G1) and the MVPN traffic whose source/group addresses
> could be on a different address space?
[Lizhong] If MVPN would aggregate I/S-PMSI onto one tunnel, it should certainly advertise upstream label which is specified in RFC6514. The upstream label would be used to demultiplex the MVPN traffic. Only the mLDP traffic (S1, G1) will not have upstream label, and could be differentiated by leaf PE. Note that PHP would be disabled for this mLDP tunnel.

>  
> If aggregating mLDP tunnels across different applications is the
> primary goal of the draft, then we should first establish whether
> the traffic of those applications can be actually aggregated.
[Lizhong] right, and as I know, the applications listed in the draft already has upstream label advertisement in their respective RFC/Draft.
>  
> Regards,
> Chandra. --=_alternative 0007D37448257A56_=-- From xuxiaohu@huawei.com Thu Aug 9 19:04: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 3B25A21F8624 for ; Thu, 9 Aug 2012 19:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=-0.496, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfvBxepvjqqm for ; Thu, 9 Aug 2012 19:04:48 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id AA8EE21F8621 for ; Thu, 9 Aug 2012 19:04:48 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJB97126; Thu, 09 Aug 2012 18:04:48 -0800 (PST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 9 Aug 2012 19:01:13 -0700 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 9 Aug 2012 19:01:19 -0700 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.5]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Fri, 10 Aug 2012 10:01:16 +0800 From: Xuxiaohu To: "erosen@cisco.com" , Alia Atlas Thread-Topic: [mpls] Comments on MPLS-in-UDP Thread-Index: AQHNdkH3tdwdCzXyaEe3xLHRR7iIc5dSP8qA Date: Fri, 10 Aug 2012 02:01:15 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753F5A8@szxeml525-mbx.china.huawei.com> References: Your message of Thu, 09 Aug 2012 10:36:40 -0400. <24629.1344525396@erosen-linux> In-Reply-To: <24629.1344525396@erosen-linux> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.24] 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] Comments on 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, 10 Aug 2012 02:04:49 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogRXJpYyBSb3NlbiBbbWFpbHRvOmVy b3NlbkBjaXNjby5jb21dDQo+ILeiy83KsbzkOiAyMDEyxOo41MI5yNUgMjM6MTcNCj4gytW8/sjL OiBBbGlhIEF0bGFzDQo+ILOty806IGVyb3NlbkBjaXNjby5jb207IFh1eGlhb2h1OyBtcGxzQGll dGYub3JnDQo+INb3zOI6IFJlOiBbbXBsc10gQ29tbWVudHMgb24gTVBMUy1pbi1VRFANCj4gDQo+ IEFsaWE+IFNheSB0aGVyZSBhcmUgMyB0cmFuc2l0IG5vZGVzIHdpdGggNCBwYXRocyBlYWNoLSB3 aXRoIHBlcmZlY3QNCj4gQWxpYT4gc3BsaXR0aW5nLCB0aGVuIG9uZSBuZWVkcyB0byBzcGVjaWZ5 IDY0IGRpZmZlcmVudCBoYXNoIHZhbHVlcy4NCj4gDQo+IEVyaWMgTz4gSWYgeW91IGhhdmUgZm91 ciBwYXRocyBhbmQgZWFjaCBob3AgaGFzIGFuIGFyYml0cmFyeSAocHJvcHJpZXRhcnksIGluDQo+ IEVyaWMgTz4gbW9zdCBjYXNlcykgaGFzaCBhbGdvcml0aG0sIGRvbid0IHlvdSBuZWVkIGZhciBt b3JlIHRoYW4gZm91ciBoYXNoDQo+IEVyaWMgTz4gdmFsdWVzIHRvIGVuc3VyZSBkZWNlbnQgZGlz dHJpYnV0aW9uIGFjcm9zcyB0aGUgYnVja2V0cz8NCj4gDQo+IFllcywgc29ycnksIGRvbid0IGtu b3cgd2hhdCBJIHdhcyB0aGlua2luZy4gIElmIHRoZSBEQyBlbnZpcm9ubWVudCByZXF1aXJlcw0K PiBhbnl0aGluZyBsaWtlIGEgMioqbi13YXkgKG9yIG1vcmUpIHNwbGl0LCBhbmQvb3IgaWYgdGhl IGhhc2hpbmcgYWxnb3JpdGhtcw0KPiBhcmUgcHJvcHJpZXRhcnksIHlvdSB3YW50IGFzIG1hbnkg aGFzaCBidWNrZXRzIGFzIHBvc3NpYmxlLg0KPiANCj4gQnV0IHRoZSBtb3JlIGhhc2ggdmFsdWVz IHlvdSBuZWVkLCB0aGUgbGVzcyBhdHRyYWN0aXZlIGl0IGJlY29tZXMgdG8gc3RvcmUNCj4gdGhl IGhhc2ggdmFsdWUgaW4gZWl0aGVyIG9mIHRoZSBVRFAgcG9ydCBmaWVsZHMuDQoNClllcywgdGhl IG1vcmUsIHRoZSBiZXR0ZXIuIEhvd2V2ZXIsIGlzbid0IHRoaXMgMTQtYml0IGVudHJ5IGxhYmVs IGVub3VnaCBpbiB0aGUgREMgZW52aXJvbm1lbnQ/DQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0K DQo+IA0KPiANCj4gDQoNCg== From dave.mcdysan@verizon.com Fri Aug 10 03:12: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 1802521F8667 for ; Fri, 10 Aug 2012 03:12:42 -0700 (PDT) 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=[AWL=0.350, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oHShUWtvLm8 for ; Fri, 10 Aug 2012 03:12:41 -0700 (PDT) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1D321F865F for ; Fri, 10 Aug 2012 03:12:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe01.verizon.com with ESMTP; 10 Aug 2012 10:12:40 +0000 From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.77,744,1336348800"; d="scan'208";a="316483086" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi01.verizon.com with ESMTP; 10 Aug 2012 10:12:40 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([166.68.59.148]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Fri, 10 Aug 2012 06:12:39 -0400 To: Mpls Date: Fri, 10 Aug 2012 06:12:38 -0400 Thread-Topic: Consolidated Responses to MPLS-RT for draft-fuxh-mpls-delay-loss-te-framework Thread-Index: Ac124KvFknIR5oI1Sb6duZvsqSVEnw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] Consolidated Responses to MPLS-RT for draft-fuxh-mpls-delay-loss-te-framework 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, 10 Aug 2012 10:12:42 -0000 Hi, As mentioned in the meeting, below are the consolidated responses from the subject draft presented on Friday, Aug 3 at Vancouver, augmented with a few comments from the meeting for your review, comment and discussion. Opinions were also invited in the meeting as to where the best place in the IETF would be for the two proposed drafts (requirements, framework) would be. Thanks again to the MPLS Review Team (MPLS-RT) Stewart Bryant, Daniel King and Jia He for their review and comments. Dave =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D Overall Response to MPLS-RT Review * Split Text into two Drafts - Problem Statement/Requirements: - Perform substantial re-write and add new text focusing on problem statement, context , use case and requirements. * Framework draft:=20 - Summarize framework to meet requirements using current/proposed approaches=20 - Document scalability assessment and recommendations -Identify any needed protocol development - Remove solution specific material * Change Intended Status from Standards Track to Informational for these drafts Specific Responses to MPLS-RT Review * Node latency: queuing latency - Don=B9t prohibit solution from considering node latency, range of problems are: - Large geographic separation of nodes, few nodes (e.g., trans-oceanic) - link latency a good approximation - Small geographic separation of nodes, many nodes node/device latency very important link may be negligible - Medium geographic separation, few-many nodes - Recommend usage of both link and node latency - To simply things, could resurrect the following from a previous version - If certain customers (e.g., financial) care deeply about node latency, solution may provide configuration knob to the user to let them add some fixed value of a portion (e.g., one half) node latency to link latency. * Proof of Jitter/Delay Variation Accumulation - Summarize ITU-T Y.1541 delay variation models and propose simple upper bounds - Additive is very loose upper bound, tighter approximations are known =AD but more complex - Summarize operational experience with delay variation in real networks * Measurement of Nodal Latency - Describe current and potential methods for measuring nodal latency =80Scalability - Need to state domains of applicability and requirements for scaling - Wide, Metro, Medium network geography/nodes - Number of domains, number/rate of change of inter-domain TE LSPs - Major topic of framework draft would be to agree on categorization, evaluation of current approaches and assessment of applicability and requirements - Requesting refferences on good scalability analyses from previous RFCs and/or drafts (or other sources) * Current/Proposed Potentially Applicable IETF Approaches - IGP flooding/ state change frequency within one area/level - RSVP-TE signaling across multiple domains (area/level, AS) probing, recording status of previous attempts, retries - Global state not known at the origin as in a single IGP area/level. - (Stateful) PCE listening to each domain, communicating amongst PCEs in other domains approximating global state to reduce probing and retries to improve scalability * Add requirements on performance measurement/monitoring (e.g., delay/loss). In framework, described how existing performance measurement and monitoring methods could be use to meet requirements From eosborne@cisco.com Fri Aug 10 06:15: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 5306A21F849B for ; Fri, 10 Aug 2012 06:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pI7jSKMqBKl for ; Fri, 10 Aug 2012 06:15:11 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 62B0D21F84AF for ; Fri, 10 Aug 2012 06:15:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=1923; q=dns/txt; s=iport; t=1344604511; x=1345814111; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=rMJ1b1uGmF7iWV23Tvq2W78w69ztJQetCuwQ/XfiIew=; b=L6fUHE+2syoCyfVEA+OtBgfDUaV6vxO8m7kld+lpoGIp+atmNOk1Ewbi LA6q5ookJqD3kpurAqFhfaC+7AvKfe6hCvcjw5t49a01AQlEsKieeQGDI ziEeQ2li0TpSC2w9bhPn6HYisw578mlHVUvMv/h+/Lu45h5VgVjGf1X9X 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAIzgI1CtJV2Z/2dsb2JhbABFuWKBB4IgAQEBAwESASc/EAIBCCIUEDIlAgQBDQ0TB4dlBpsGoG2RE2ADo3KBZoJf X-IronPort-AV: E=Sophos;i="4.77,745,1336348800"; d="scan'208";a="110312908" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 10 Aug 2012 13:15:02 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7ADF26I026016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Aug 2012 13:15:02 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0298.004; Fri, 10 Aug 2012 08:15:01 -0500 From: "Eric Osborne (eosborne)" To: Xuxiaohu , "Eric Rosen (erosen)" Thread-Topic: Comments on MPLS-in-UDP Thread-Index: AQHNdIEAkfCDwjMvAUa1dYjrrKc2pZdOc4cAgAD99ICAAFevoIABRCIAgABZtxCAASsJgP//yHNA Date: Fri, 10 Aug 2012 13:15:00 +0000 Message-ID: <20ECF67871905846A80F77F8F4A275720F53F663@xmb-rcd-x09.cisco.com> References: Your message of Mon, 30 Jul 2012 18:03:44 -0000. <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753B3A1@szxeml525-mbx.china.huawei.com> <9398.1344282664@erosen-linux> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753EB93@szxeml525-mbx.china.huawei.com> <20ECF67871905846A80F77F8F4A275720F5396EC@xmb-rcd-x09.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753EE7F@szxeml525-mbx.china.huawei.com> <20ECF67871905846A80F77F8F4A275720F53BAB7@xmb-rcd-x09.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753F1F5@szxeml525-mbx.china.huawei.com> <20ECF67871905846A80F77F8F4A275720F53D5DD@xmb-rcd-x09.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753F54F@szxeml525-mbx.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753F54F@szxeml525-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.23.87] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19098.003 x-tm-as-result: No--39.806600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on 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, 10 Aug 2012 13:15:12 -0000 ... > > If a host stack on a router allocates source port 50000 to be used to t= alk to a > > particular server and your scheme also uses source port 50000 at the sa= me > > time due to hashing, you have two distinct applications using the same > source > > port. This is Bad, as I can see it breaking things like on-router fire= walls and > > anything in the middle. >=20 > Do you believe that on-router firewalls or NAT boxes would be deployed on > the path between PE routers in practice? 1) I'm aware of at least one implementation where the PE itself creates a = dynamic stateful firewall to help protect against DDOS. Carving a 14-bit h= ole for ephemeral ports seems like a bad idea, and real-time coordination b= etween hashing hardware and socket software is hard. 2) I have, over the years, discovered that I'm extremely bad at predicting = what people will never, ever do with their networks. This applies doubly t= o things that we think are 'sensible' - one operator's best practice is ano= ther operator's anathema. =20 3) It is bad practice to assume that nobody will mind if you overload a fie= ld and then overload the field based on that assumption. =20 While it may be possible to overload a long used and well understood field = in the right circumstances, you'd have to have pretty strong justification.= I don't believe that "some hardware may not be able to handle other solut= ions to this problem" is strong enough. =20 eric >=20 > Best regards, > Xiaohu >=20 > > In order to avoid this collision you need to ensure that your hashing d= oesn't > > collide with your ephemeral port allocation, which could mean a ton of > > real-time coordination between forwarding hardware and the host stack. > > > > > > eric > > > > > > > > > > Best regards, > > > Xiaohu > > > > > > > > > > > > > > > > > > > > > > eric > > > > From pabloisnot@gmail.com Fri Aug 10 07: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 7388321F850D for ; Fri, 10 Aug 2012 07:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.321 X-Spam-Level: X-Spam-Status: No, score=-3.321 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNhssDkP2+Kd for ; Fri, 10 Aug 2012 07:23:28 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 9274321F865D for ; Fri, 10 Aug 2012 07:23:27 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so1089228wib.13 for ; Fri, 10 Aug 2012 07:23:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FO9EE4oa02kZMxQqeuI+LTcv21VvgCtlcyssdGDTTAM=; b=GHHgAT+6JS7ZvUznsdaexwCjkB2fyGPemMPpUqdMVOY9ZV2e4cOYyaeZIHleeR+Ke4 x77qt3R8XpLkDHTBH7wWpPgcVqLCRMcyBrk/fHMn3wTo7eIa14WGpqGeZE6jUABJBzNg cib/aqxECL5QMqWzl4Zp++dPs/d1UO9OERVpriUB+5NGzfZW7WlaY2Kp+H3m9/IZKZvB GD24NCXJi9X0RAflkttz2X76OQEqs2tk3CCYu8ziGXzGR9/WDjpDbre5VAYn+jQ5pZ+R 3EwZkQK5bwoNyWh3HBEmzv6eh/pVt0iKAnxaIpUjyBB/a89CNVcwyzIFyrqwEXG8bhQy jCZw== MIME-Version: 1.0 Received: by 10.216.162.141 with SMTP id y13mr1720213wek.14.1344608606557; Fri, 10 Aug 2012 07:23:26 -0700 (PDT) Received: by 10.227.197.206 with HTTP; Fri, 10 Aug 2012 07:23:25 -0700 (PDT) In-Reply-To: References: Date: Fri, 10 Aug 2012 10:23:26 -0400 Message-ID: From: Pablo Frank To: Yaacov Weingarten Content-Type: multipart/alternative; boundary=0016e65b5db25b16e904c6ea16d2 Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-weingarten-mpls-smp-requirements-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: Fri, 10 Aug 2012 14:23:29 -0000 --0016e65b5db25b16e904c6ea16d2 Content-Type: text/plain; charset=ISO-8859-1 Hi Yaacov, Some more comments inline... PF>> On Mon, Aug 6, 2012 at 8:56 AM, Yaacov Weingarten wrote: > Hi, > > Thank you for your comments. Please see my comments inline below. > > BR, > yaacov > > On Tue, Jul 17, 2012 at 11:51 PM, Pablo Frank wrote: > >> Good draft and certainly something that needs to be done before we can >> start discussing specific solutions. >> >> Only a few comments / questions: >> >> - In 4.1.1, if one is operating in an MPLS-TP network that requires >> exclusive use of the protection resources, doesn't this SHOULD requirement >> become a MUST requirement? >> > > yw>> Sorry - but could you explain more fully this comment. > PF>> If you're trying to meet RFC 5654 req 58b in particular, I would think you MUST validate that enough protection resources are available (or are preemptible) to carry 100% of the service traffic that is being restored. In existing transport networks (i.e. OTN / sonet), this is typically done before you switch traffic to the protection path. From a solution perspective, I think you'll probably want to leverage something like the locking mode that is being proposed for the 1:n draft. - Nit: you might want to avoid using the "query" verb in the title of 4.1.1 >> because it subtly suggests some kind of protocol messaging is required. I >> would use the more generic verb "checking" or "verifying". >> > yw>> Sounds OK to me. > >> - In 4.3, there is no suggestion for what should happen if one or more >> failing paths in an MPLS-TP network are of equal priority. I presume it >> will be some kind of first-come, first-serve requirement but this will >> bring up the question of how to break ties. >> > yw>> This could be resolved along the lines that it was addressed in the > 1:n protection > PF>> Except that you guys removed separate path priority from the latest version of the 1:n draft. In the latest version, each path has a strict priority defined by its path ID so ties were not possible. I don't think that solution will work for SMP because I have a hard time seeing how all the various endpoints involved in a shared mesh could coordinate non-overlapping path IDs, while at the same time not exceeding the limit of 255 path IDs. > - Also in 4.3, there is an allowance for a high priority path and a lower >> priority path to temporarily share the protection resources while >> preemption is taking place. Two questions: >> >> - Is the ingress node to the shared segment expected to discard excess >> traffic now that the protection-path is temporarily oversubscribed? >> >> yw>> this would most probably follow standard MPLS behavior as described > elsewhere > PF>> I guess I'll ask what is the standard behaviour? And is it applicable to MPLS-TP networks? > - If not, how do we ensure that other transport paths are unaffected? >> >> - The first paragraph of 4.4 appears to contradict 4.1.1. 4.4 seems to >> suggest that one MUST switch the traffic onto the protection path first and >> then get notified if there's not enough resources. That's probably okay in >> the general case. But in an MPLS-TP network, I don't think it's a good >> idea to blindly switch low priority traffic onto the protection path and >> possibly disrupt a high priority path that is already using that resource. >> > yw>> This is dependent upon the actual mechanism that is developed by the > WG. For example, one suggestion for the mechanism has notifications sent > to lower priority working paths making the protection path unavailable if > it is in use by a high-priority working path. > > >> - In section 4.5, there's an attempt to define "protection switching >> time" as not including preemption time. I don't think end-users really >> care about "protection switching time". They care about recovery time and >> IMO, that should also include fault detection time (although it doesn't per >> RFC 5654) and any preemption time. >> > yw>> we do try to work within the accepted definitions of the IETF! > PF>> I guess there's two separate comments here that I kinda conflated together. One was more of a gripe: why did we exclude fault detection time from the 50ms restoration time requirement in RFC 5654? I know that my customers measure only one thing: how many ms of traffic do they lose after a breakage. I don't get a free pass on the ~10ms it takes for BFD to detect the failure. According to RFC 5654, I could use 60sec CCMs and still meet the 50ms requirement! The 2nd comment was really about this draft now trying to exclude preemption time from restoration time as well. IMO, if it takes a few seconds for a high priority service to finish preempting a lower priority service, then we haven't met the 50ms restoration time requirement. Especially since it's typically my higher priority services that want 50ms restoration times in the first place, so they'll be more often in a position to preempt. In other words, I think we want preemption to be fast and is a critical component of protection switching. > >> regards, >> Pablo >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> > --0016e65b5db25b16e904c6ea16d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Yaacov,

Some more comments inline... PF>>
On Mon, Aug 6, 2012 at 8:56 AM, Yaacov Weingar= ten <wyaacov@gmail.com> wrote:
Hi,

Than= k you for your comments. =A0Please see my comments inline below.
=
BR,
yaacov

On Tue, Jul 17, 2012 at 11:51 PM, Pablo Frank &l= t;pabloisnot@gmai= l.com> wrote:
Good draft and certainly something that need= s to be done before we can start discussing specific solutions.

Only a few comments / questions:

- In 4.1.1, = if one is operating in an MPLS-TP network that requires exclusive use of th= e protection resources, doesn't this SHOULD requirement become a MUST r= equirement?

yw>> Sorry - but could you exp= lain more fully this comment.

=
PF>> =A0If you're trying to meet RFC 5654 req 58b in p= articular, I would think you MUST validate that enough protection resources= are available (or are preemptible) to carry 100% of the service traffic th= at is being restored. =A0In existing transport networks (i.e. OTN / sonet),= this is typically done before you switch traffic to the protection path. = =A0From a solution perspective, I think you'll probably want to leverag= e something like the locking mode that is being proposed for the 1:n draft.=

- Nit: you might want to avoid using the "query" verb in the= title of 4.1.1 because it subtly suggests some kind of protocol messaging = is required. =A0I would use the more generic verb "checking" or &= quot;verifying".
yw>> Sounds OK to me.=A0
- In 4.3, there is no suggestion for what should happen if one or more= failing paths in an MPLS-TP network are of equal priority. =A0I presume it= will be some kind of first-come, first-serve requirement but this will bri= ng up the question of how to break ties.
yw>> This could be resolved along the lines t= hat it was addressed in the 1:n protection

PF>> Except that you guys removed separate path pri= ority from the latest version of the 1:n draft. =A0In the latest version, e= ach path has a strict priority defined by its path ID so ties were not poss= ible. =A0I don't think that solution will work for SMP because I have a= hard time seeing how all the various endpoints involved in a shared mesh c= ould coordinate non-overlapping path IDs, while at the same time not exceed= ing the limit of 255 path IDs.


- Also in 4.3, there is an allowance for a high priority path and a lo= wer priority path to temporarily share the protection resources while preem= ption is taking place. =A0Two questions:
- Is the ingress node to the shared segment expected to discard excess= traffic now that the protection-path is temporarily oversubscribed?
<= /blockquote>
yw>> this would most probably fol= low standard MPLS behavior as described elsewhere=A0

PF>> I guess I'll as= k what is the standard behaviour? =A0And is it applicable to MPLS-TP networ= ks?
=A0
- If not, how do we ensure that other transport pa= ths are unaffected?
- The first paragraph of 4.4 appears to contradict 4.1.1.= =A04.4 seems to suggest that one MUST switch the traffic onto the protecti= on path first and then get notified if there's not enough resources. = =A0That's probably okay in the general case. =A0But in an MPLS-TP netwo= rk, I don't think it's a good idea to blindly switch low priority t= raffic onto the protection path and possibly disrupt a high priority path t= hat is already using that resource.
yw>> This is dependent upon the actual mechan= ism that is developed by the WG. =A0For example, one suggestion for the mec= hanism has notifications sent to lower priority working paths making the pr= otection path unavailable if it is in use by a high-priority working path.<= /div>
=A0
- In section 4.5, there's an attempt to define "protection sw= itching time" as not including preemption time. =A0I don't think e= nd-users really care about "protection switching time". =A0They c= are about recovery time and IMO, that should also include fault detection t= ime (although it doesn't per RFC 5654) and any preemption time.
yw>> we do try to work within the accepted de= finitions of the IETF!=A0

PF>> I guess there's two separate comments here that I kinda con= flated together. =A0One was more of a gripe: why did we exclude fault detec= tion time from the 50ms restoration time requirement in RFC 5654? =A0I know= that my customers measure only one thing: how many ms of traffic do they l= ose after a breakage. =A0I don't get a free pass on the ~10ms it takes = for BFD to detect the failure. =A0According to RFC 5654, I could use 60sec = CCMs and still meet the 50ms requirement!

The 2nd comment was really about this draft now trying = to exclude preemption time from restoration time as well. =A0IMO, if it tak= es a few seconds for a high priority service to finish preempting a lower p= riority service, then we haven't met the 50ms restoration time requirem= ent. =A0Especially since it's typically my higher priority services tha= t want 50ms restoration times in the first place, so they'll be more of= ten in a position to preempt. =A0In other words, I think we want preemption= to be fast and is a critical component of protection switching. =A0
=A0

regards,
Pablo


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



--0016e65b5db25b16e904c6ea16d2-- From csekar@juniper.net Fri Aug 10 08: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 6872C21F866D for ; Fri, 10 Aug 2012 08:18:33 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsRFe65Z7AjV for ; Fri, 10 Aug 2012 08:18:32 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 0215B21F849D for ; Fri, 10 Aug 2012 08:18:23 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUCUmOz5X3BvuBjOE/pdpnsLRgj7nqGbe@postini.com; Fri, 10 Aug 2012 08:18:28 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 10 Aug 2012 08:17:17 -0700 Received: from p-emfe02-bng.jnpr.net (10.211.204.41) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 10 Aug 2012 08:17:14 -0700 Received: from EMBX02-BNG.jnpr.net ([fe80::8ce3:7a6:9990:3c6e]) by p-emfe02-bng.jnpr.net ([::1]) with mapi; Fri, 10 Aug 2012 20:47:07 +0530 From: Chandrasekar R To: "lizhong.jin@zte.com.cn" Date: Fri, 10 Aug 2012 20:47:07 +0530 Thread-Topic: DISCUSS///RE: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-04 Thread-Index: Ac12lxOhQxkR62qhQPWO/55MVIpDyQAaUtcw Message-ID: <105EB9F002CB164DA9ADD111BFC4DCFF1C95811D@EMBX02-BNG.jnpr.net> References: <105EB9F002CB164DA9ADD111BFC4DCFF1C957F24@EMBX02-BNG.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_105EB9F002CB164DA9ADD111BFC4DCFF1C95811DEMBX02BNGjnprne_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] DISCUSS///RE: wg doc poll on draft-jin-mpls-mldp-leaf-discovery-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, 10 Aug 2012 15:18:33 -0000 --_000_105EB9F002CB164DA9ADD111BFC4DCFF1C95811DEMBX02BNGjnprne_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lizhong, Yes, it was clear that UHP should be used on the mLDP LSP. If the same mLD= P LSP is to be shared for MVPN also, then leaf PE cannot know from control = plane signaling alone whether mLDP LSP label should be used for forwarding = in-band multicast traffic or not. In any case if my understanding is correc= t it is not possible to aggregate two different mLDP in-band multicast flow= s. So aggregating an in-band multicast flow with flows of different applica= tion also increasing complexity is not a convincing motivation. Regards, Chandra. From: lizhong.jin@zte.com.cn [mailto:lizhong.jin@zte.com.cn] Sent: Friday, August 10, 2012 6:55 AM To: Chandrasekar R Cc: erosen@cisco.com; mpls@ietf.org; mpls-chairs@tools.ietf.org Subject: DISCUSS///RE: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-disco= very-04 Chandra, Thanks for the comments. See reply below. Lizhong Chandrasekar R > wrote 2012/0= 8/10 01:21:41: > HI Lizhong, > > [Lizhong] PE1 have the tunnel >. Then > when PE1 initiates new MVPN service, and has leaf member PE2, PE3, > PE4, then PE1 is not necessary to initiate new mLDP tunnel, but > directly aggreate to tunnel > for > MVPN service. If PE1 does not have the leaf information of tunnel > >, then PE1 could not aggregate MVPN > service to that tunnel. And Leaf A-D route in MVPN could not help > PE1 to find the leaf information of tunnel value=3D>. That means two different kind of applications could > share one tunnel which is this draft trying to solve. > [Chandra] How does the leaf PE differentiate between the mLDP > traffic (S1, G1) and the MVPN traffic whose source/group addresses > could be on a different address space? [Lizhong] If MVPN would aggregate I/S-PMSI onto one tunnel, it should certa= inly advertise upstream label which is specified in RFC6514. The upstream l= abel would be used to demultiplex the MVPN traffic. Only the mLDP traffic (= S1, G1) will not have upstream label, and could be differentiated by leaf P= E. Note that PHP would be disabled for this mLDP tunnel. > > If aggregating mLDP tunnels across different applications is the > primary goal of the draft, then we should first establish whether > the traffic of those applications can be actually aggregated. [Lizhong] right, and as I know, the applications listed in the draft alread= y has upstream label advertisement in their respective RFC/Draft. > > Regards, > Chandra. --_000_105EB9F002CB164DA9ADD111BFC4DCFF1C95811DEMBX02BNGjnprne_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Lizhon= g,

Yes, it was clear that = UHP should be used on the mLDP LSP.  If the same mLDP LSP is to be sha= red for MVPN also, then leaf PE cannot know from control plane signaling al= one whether mLDP LSP label should be used for forwarding in-band multicast = traffic or not. In any case if my understanding is correct it is not possib= le to aggregate two different mLDP in-band multicast flows. So aggregating = an in-band multicast flow with flows of different application also increasi= ng complexity is not a convincing motivation.

 

Regards,

Chandra.  <= o:p>

 

 

From: lizhong.jin@zte.com.cn [mailto:lizhong.jin@zte= .com.cn]
Sent: Friday, August 10, 2012 6:55 AM
To: Cha= ndrasekar R
Cc: erosen@cisco.com; mpls@ietf.org; mpls-chairs@tool= s.ietf.org
Subject: DISCUSS///RE: [mpls] wg doc poll on draft-jin= -mpls-mldp-leaf-discovery-04

 


Chandra,
Thanks for the comm= ents. See reply below.

Lizhong


Chandrasekar R <csekar@juniper.net> wrote 2012/08/10 = 01:21:41:

> HI Lizhong,
>  
> [Lizhong] PE1 have t= he tunnel <root=3DPE1, opaque value=3D<S1,G1>>. Then
> wh= en PE1 initiates new MVPN service, and has leaf member PE2, PE3,
> P= E4, then PE1 is not necessary to initiate new mLDP tunnel, but
> dir= ectly aggreate to tunnel <root=3DPE1, opaque value=3D<S1,G1>> f= or
> MVPN service. If PE1 does not have the leaf information of tunn= el
> <root=3DPE1, opaque value=3D<S1,G1>>, then PE1 coul= d not aggregate MVPN
> service to that tunnel. And Leaf A-D route in= MVPN could not help
> PE1 to find the leaf information of tunnel &l= t;root=3DPE1, opaque
> value=3D<S1,G1>>. That means two dif= ferent kind of applications could
> share one tunnel which is this d= raft trying to solve.

> [Chandra] How does the leaf PE differentia= te between the mLDP
> traffic (S1, G1) and the MVPN traffic whose so= urce/group addresses
> could be on a different address space?=
[Liz= hong] If MVPN would aggregate I/S-PMSI onto one tunnel, it should certainly= advertise upstream label which is specified in RFC6514. The upstream label= would be used to demultiplex the MVPN traffic. Only the mLDP traffic (S1, = G1) will not have upstream label, and could be differentiated by leaf PE. N= ote that PHP would be disabled for this mLDP tunnel.

>  
&g= t; If aggregating mLDP tunnels across different applications is the
>= ; primary goal of the draft, then we should first establish whether
>= ; the traffic of those applications can be actually aggregated.
= [Lizhong]= right, and as I know, the applications listed in the draft already has ups= tream label advertisement in their respective RFC/Draft.
>  
&g= t; Regards,
> Chandra.

= --_000_105EB9F002CB164DA9ADD111BFC4DCFF1C95811DEMBX02BNGjnprne_-- From lizhong.jin@zte.com.cn Sat Aug 11 07:48: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 B17DB21F854A for ; Sat, 11 Aug 2012 07:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.427 X-Spam-Level: X-Spam-Status: No, score=-101.427 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqSDhjSjx+Cr for ; Sat, 11 Aug 2012 07:48:44 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 3B72E21F84C4 for ; Sat, 11 Aug 2012 07:48:44 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 10723806486374; Sat, 11 Aug 2012 22:35:45 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 77422.3994372557; Sat, 11 Aug 2012 22:48:18 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q7BEmTp0075456; Sat, 11 Aug 2012 22:48:29 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: <105EB9F002CB164DA9ADD111BFC4DCFF1C95811D@EMBX02-BNG.jnpr.net> To: Chandrasekar R MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Sat, 11 Aug 2012 22:47:31 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-11 22:48:22, Serialize complete at 2012-08-11 22:48:22 Content-Type: multipart/alternative; boundary="=_alternative 005157DE48257A57_=" X-MAIL: mse02.zte.com.cn q7BEmTp0075456 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] DISCUSS///RE: wg doc poll on draft-jin-mpls-mldp-leaf-discovery-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: Sat, 11 Aug 2012 14:48:45 -0000 This is a multipart message in MIME format. --=_alternative 005157DE48257A57_= Content-Type: text/plain; charset="US-ASCII" Chandrasekar R wrote 2012/08/10 23:17:07: > Hi Lizhong, > Yes, it was clear that UHP should be used on the mLDP LSP. If the > same mLDP LSP is to be shared for MVPN also, then leaf PE cannot > know from control plane signaling alone whether mLDP LSP label > should be used for forwarding in-band multicast traffic or not. [Lizhong] if the traffic contains mLDP LSP label at the bottom of label stack, the leaf PE consider it as in-band multicast traffic, otherwise not. Note that there is only one in-band multicast flow carried by this mLDP LSP label, other traffic flow (not in-band multicast) will have upstream label for forwarding. Let me give an example, if leaf PE advertise label_A for >, when MVPN aggregate flow to this mLDP LSP, root PE1 will advertise upstream label_B for this MVPN flow to leaf PE (RFC6514). The leaf PE will know that if bottom label stack is label_A, it is in-band multicast traffic, if label stack is labe_A and label_B, it is MVPN traffic. > In > any case if my understanding is correct it is not possible to > aggregate two different mLDP in-band multicast flows. [Lizhong] yes, and aggregating two different mLDP in-band multicast flows is not the purpose of this draft. The purpose of this draft is to allow root initiated application (e.g, MVPN) to aggregate flow onto LSP setup by leaf initiated application (e.g, in-band mLDP). We will rephrase purpose content in the draft to make it more clear. > So aggregating > an in-band multicast flow with flows of different application also > increasing complexity is not a convincing motivation. [Lizhong] Could you explicitly point out what kind of the complexity you have concern about? Regards Lizhong > > Regards, > Chandra. > > > From: lizhong.jin@zte.com.cn [mailto:lizhong.jin@zte.com.cn] > Sent: Friday, August 10, 2012 6:55 AM > To: Chandrasekar R > Cc: erosen@cisco.com; mpls@ietf.org; mpls-chairs@tools.ietf.org > Subject: DISCUSS///RE: [mpls] wg doc poll on draft-jin-mpls-mldp- > leaf-discovery-04 > > > Chandra, > Thanks for the comments. See reply below. > > Lizhong > > > Chandrasekar R wrote 2012/08/10 01:21:41: > > > HI Lizhong, > > > > [Lizhong] PE1 have the tunnel >. Then > > when PE1 initiates new MVPN service, and has leaf member PE2, PE3, > > PE4, then PE1 is not necessary to initiate new mLDP tunnel, but > > directly aggreate to tunnel > for > > MVPN service. If PE1 does not have the leaf information of tunnel > > >, then PE1 could not aggregate MVPN > > service to that tunnel. And Leaf A-D route in MVPN could not help > > PE1 to find the leaf information of tunnel > value=>. That means two different kind of applications could > > share one tunnel which is this draft trying to solve. > > > [Chandra] How does the leaf PE differentiate between the mLDP > > traffic (S1, G1) and the MVPN traffic whose source/group addresses > > could be on a different address space? > [Lizhong] If MVPN would aggregate I/S-PMSI onto one tunnel, it > should certainly advertise upstream label which is specified in > RFC6514. The upstream label would be used to demultiplex the MVPN > traffic. Only the mLDP traffic (S1, G1) will not have upstream > label, and could be differentiated by leaf PE. Note that PHP would > be disabled for this mLDP tunnel. > > > > > If aggregating mLDP tunnels across different applications is the > > primary goal of the draft, then we should first establish whether > > the traffic of those applications can be actually aggregated. > [Lizhong] right, and as I know, the applications listed in the draft > already has upstream label advertisement in their respective RFC/Draft. > > > > Regards, > > Chandra. --=_alternative 005157DE48257A57_= Content-Type: text/html; charset="US-ASCII"
Chandrasekar R <csekar@juniper.net> wrote 2012/08/10 23:17:07:

> Hi Lizhong,
> Yes, it was clear that UHP should be used on the mLDP LSP.  If the
> same mLDP LSP is to be shared for MVPN also, then leaf PE cannot
> know from control plane signaling alone whether mLDP LSP label
> should be used for forwarding in-band multicast traffic or not.
[Lizhong] if the traffic contains mLDP LSP label at the bottom of label stack, the leaf PE consider it as in-band multicast traffic, otherwise not. Note that there is only one in-band multicast flow carried by this mLDP LSP label, other traffic flow (not in-band multicast) will have upstream label for forwarding. Let me give an example, if leaf PE advertise label_A for <root=PE1, opaque value=<S1,G1>>, when MVPN aggregate flow to this mLDP LSP, root PE1 will advertise upstream label_B for this MVPN flow to leaf PE (RFC6514). The leaf PE will know that if bottom label stack is label_A, it is in-band multicast traffic, if label stack is labe_A and label_B, it is MVPN traffic.

> In
> any case if my understanding is correct it is not possible to
> aggregate two different mLDP in-band multicast flows.
[Lizhong] yes, and aggregating two different mLDP in-band multicast flows is not the purpose of this draft. The purpose of this draft is to allow root initiated application (e.g, MVPN) to aggregate flow onto LSP setup by leaf initiated application (e.g, in-band mLDP). We will rephrase purpose content in the draft to make it more clear.

> So aggregating
> an in-band multicast flow with flows of different application also
> increasing complexity is not a convincing motivation.
[Lizhong] Could you explicitly point out what kind of the complexity you have concern about?

Regards
Lizhong

>  
> Regards,
> Chandra.  
>  
>  
> From: lizhong.jin@zte.com.cn [mailto:lizhong.jin@zte.com.cn]
> Sent: Friday, August 10, 2012 6:55 AM
> To: Chandrasekar R
> Cc: erosen@cisco.com; mpls@ietf.org; mpls-chairs@tools.ietf.org
> Subject: DISCUSS///RE: [mpls] wg doc poll on draft-jin-mpls-mldp-
> leaf-discovery-04
>  
>
> Chandra,
> Thanks for the comments. See reply below.
>
> Lizhong
>
>
> Chandrasekar R <csekar@juniper.net> wrote 2012/08/10 01:21:41:
>
> > HI Lizhong,
> >  
> > [Lizhong] PE1 have the tunnel <root=PE1, opaque value=<S1,G1>>. Then
> > when PE1 initiates new MVPN service, and has leaf member PE2, PE3,
> > PE4, then PE1 is not necessary to initiate new mLDP tunnel, but
> > directly aggreate to tunnel <root=PE1, opaque value=<S1,G1>> for
> > MVPN service. If PE1 does not have the leaf information of tunnel
> > <root=PE1, opaque value=<S1,G1>>, then PE1 could not aggregate MVPN
> > service to that tunnel. And Leaf A-D route in MVPN could not help
> > PE1 to find the leaf information of tunnel <root=PE1, opaque
> > value=<S1,G1>>. That means two different kind of applications could
> > share one tunnel which is this draft trying to solve.
>
> > [Chandra] How does the leaf PE differentiate between the mLDP
> > traffic (S1, G1) and the MVPN traffic whose source/group addresses
> > could be on a different address space?
> [Lizhong] If MVPN would aggregate I/S-PMSI onto one tunnel, it
> should certainly advertise upstream label which is specified in
> RFC6514. The upstream label would be used to demultiplex the MVPN
> traffic. Only the mLDP traffic (S1, G1) will not have upstream
> label, and could be differentiated by leaf PE. Note that PHP would
> be disabled for this mLDP tunnel.
>
> >  
> > If aggregating mLDP tunnels across different applications is the
> > primary goal of the draft, then we should first establish whether
> > the traffic of those applications can be actually aggregated.
> [Lizhong] right, and as I know, the applications listed in the draft
> already has upstream label advertisement in their respective RFC/Draft.
> >  
> > Regards,
> > Chandra. --=_alternative 005157DE48257A57_=-- From xuxiaohu@huawei.com Tue Aug 14 02:25: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 61AAD21F8691 for ; Tue, 14 Aug 2012 02:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=-0.477, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cekDEBIs+11p for ; Tue, 14 Aug 2012 02:25:06 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A2D5B21F866A for ; Tue, 14 Aug 2012 02:25:06 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfwdlp01-ep.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIV94350; Tue, 14 Aug 2012 01:25:06 -0800 (PST) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Aug 2012 02:20:36 -0700 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Aug 2012 02:20:39 -0700 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.5]) by szxeml415-hub.china.huawei.com ([10.82.67.154]) with mapi id 14.01.0323.003; Tue, 14 Aug 2012 17:20:32 +0800 From: Xuxiaohu To: "Eric Osborne (eosborne)" , "Eric Rosen (erosen)" Thread-Topic: Comments on MPLS-in-UDP Thread-Index: AQHNdAzUtdwdCzXyaEe3xLHRR7iIc5dOB+Tg///myACAAS1rQIAAKNYAgAFym+CAAC2CAIABWAAwgABJCgCABoi0cA== Date: Tue, 14 Aug 2012 09:20:31 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0754064B@szxeml525-mbx.china.huawei.com> References: Your message of Mon, 30 Jul 2012 18:03:44 -0000. <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753B3A1@szxeml525-mbx.china.huawei.com> <9398.1344282664@erosen-linux> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753EB93@szxeml525-mbx.china.huawei.com> <20ECF67871905846A80F77F8F4A275720F5396EC@xmb-rcd-x09.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753EE7F@szxeml525-mbx.china.huawei.com> <20ECF67871905846A80F77F8F4A275720F53BAB7@xmb-rcd-x09.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753F1F5@szxeml525-mbx.china.huawei.com> <20ECF67871905846A80F77F8F4A275720F53D5DD@xmb-rcd-x09.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753F54F@szxeml525-mbx.china.huawei.com> <20ECF67871905846A80F77F8F4A275720F53F663@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A275720F53F663@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.99.24] 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] Comments on 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: Tue, 14 Aug 2012 09:25:07 -0000 SGkgRXJpYywNCg0KVGhhbmtzIGEgbG90IGZvciB5b3VyIGNvbW1lbnRzLg0KDQpJbiBmYWN0LCB1 c2luZyBVRFAgZW5jYXBzdWxhdGlvbiBhbmQgZmlsbGluZyB0aGUgc291cmNlIHBvcnQgZmllbGQg d2l0aCBhIGhhc2ggdmFsdWUgaXNuJ3QgYSB0b3RhbGx5IG5vdmVsIGlkZWEgc2luY2UgaXQgaGFk IGJlZW4gcHJvcG9zZWQgaW4gbWFueSBvdGhlciBlbmNhcHN1bGF0aW9uIHJlbGF0ZWQgcHJvdG9j b2xzLiBPbmUgZXhhbXBsZSBpcyBMSVNQLCBwbGVhc2Ugc2VlIHNlY3Rpb24gNi41IChodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWxpc3AtMjMjc2VjdGlvbi02LjUpIGZvciBt b3JlIGRldGFpbHMuDQoNCkFueSBmdXJ0aGVyIGNvbW1lbnRzIGFyZSBtb3JlIHRoYW4gd2VsY29t ZS4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILei vP7IyzogRXJpYyBPc2Jvcm5lIChlb3Nib3JuZSkgW21haWx0bzplb3Nib3JuZUBjaXNjby5jb21d DQo+ILeiy83KsbzkOiAyMDEyxOo41MIxMMjVIDIxOjE1DQo+IMrVvP7IyzogWHV4aWFvaHU7IEVy aWMgUm9zZW4gKGVyb3NlbikNCj4gs63LzTogbXBsc0BpZXRmLm9yZw0KPiDW98ziOiBSRTogQ29t bWVudHMgb24gTVBMUy1pbi1VRFANCj4gDQo+IC4uLg0KPiANCj4gPiA+IElmIGEgaG9zdCBzdGFj ayBvbiBhIHJvdXRlciBhbGxvY2F0ZXMgc291cmNlIHBvcnQgNTAwMDAgdG8gYmUgdXNlZCB0byB0 YWxrIHRvDQo+IGENCj4gPiA+IHBhcnRpY3VsYXIgc2VydmVyIGFuZCB5b3VyIHNjaGVtZSBhbHNv IHVzZXMgc291cmNlIHBvcnQgNTAwMDAgYXQgdGhlIHNhbWUNCj4gPiA+IHRpbWUgZHVlIHRvIGhh c2hpbmcsIHlvdSBoYXZlIHR3byBkaXN0aW5jdCBhcHBsaWNhdGlvbnMgdXNpbmcgdGhlIHNhbWUN Cj4gPiBzb3VyY2UNCj4gPiA+IHBvcnQuICBUaGlzIGlzIEJhZCwgYXMgSSBjYW4gc2VlIGl0IGJy ZWFraW5nIHRoaW5ncyBsaWtlIG9uLXJvdXRlciBmaXJld2FsbHMNCj4gYW5kDQo+ID4gPiBhbnl0 aGluZyBpbiB0aGUgbWlkZGxlLg0KPiA+DQo+ID4gRG8geW91IGJlbGlldmUgdGhhdCBvbi1yb3V0 ZXIgZmlyZXdhbGxzIG9yIE5BVCBib3hlcyB3b3VsZCBiZSBkZXBsb3llZCBvbg0KPiA+IHRoZSBw YXRoIGJldHdlZW4gUEUgcm91dGVycyBpbiBwcmFjdGljZT8NCj4gDQo+IDEpICBJJ20gYXdhcmUg b2YgYXQgbGVhc3Qgb25lIGltcGxlbWVudGF0aW9uIHdoZXJlIHRoZSBQRSBpdHNlbGYgY3JlYXRl cyBhDQo+IGR5bmFtaWMgc3RhdGVmdWwgZmlyZXdhbGwgdG8gaGVscCBwcm90ZWN0IGFnYWluc3Qg RERPUy4gIENhcnZpbmcgYSAxNC1iaXQgaG9sZQ0KPiBmb3IgZXBoZW1lcmFsIHBvcnRzIHNlZW1z IGxpa2UgYSBiYWQgaWRlYSwgYW5kIHJlYWwtdGltZSBjb29yZGluYXRpb24gYmV0d2Vlbg0KPiBo YXNoaW5nIGhhcmR3YXJlIGFuZCBzb2NrZXQgc29mdHdhcmUgaXMgaGFyZC4NCj4gDQo+IDIpIEkg aGF2ZSwgb3ZlciB0aGUgeWVhcnMsIGRpc2NvdmVyZWQgdGhhdCBJJ20gZXh0cmVtZWx5IGJhZCBh dCBwcmVkaWN0aW5nIHdoYXQNCj4gcGVvcGxlIHdpbGwgbmV2ZXIsIGV2ZXIgZG8gd2l0aCB0aGVp ciBuZXR3b3Jrcy4gIFRoaXMgYXBwbGllcyBkb3VibHkgdG8gdGhpbmdzDQo+IHRoYXQgd2UgdGhp bmsgYXJlICdzZW5zaWJsZScgLSBvbmUgb3BlcmF0b3IncyBiZXN0IHByYWN0aWNlIGlzIGFub3Ro ZXIgb3BlcmF0b3Incw0KPiBhbmF0aGVtYS4NCj4gDQo+IDMpIEl0IGlzIGJhZCBwcmFjdGljZSB0 byBhc3N1bWUgdGhhdCBub2JvZHkgd2lsbCBtaW5kIGlmIHlvdSBvdmVybG9hZCBhIGZpZWxkIGFu ZA0KPiB0aGVuIG92ZXJsb2FkIHRoZSBmaWVsZCBiYXNlZCBvbiB0aGF0IGFzc3VtcHRpb24uDQo+ IA0KPiANCj4gV2hpbGUgaXQgbWF5IGJlIHBvc3NpYmxlIHRvIG92ZXJsb2FkIGEgbG9uZyB1c2Vk IGFuZCB3ZWxsIHVuZGVyc3Rvb2QgZmllbGQgaW4NCj4gdGhlIHJpZ2h0IGNpcmN1bXN0YW5jZXMs IHlvdSdkIGhhdmUgdG8gaGF2ZSBwcmV0dHkgc3Ryb25nIGp1c3RpZmljYXRpb24uICBJIGRvbid0 DQo+IGJlbGlldmUgdGhhdCAic29tZSBoYXJkd2FyZSBtYXkgbm90IGJlIGFibGUgdG8gaGFuZGxl IG90aGVyIHNvbHV0aW9ucyB0byB0aGlzDQo+IHByb2JsZW0iIGlzIHN0cm9uZyBlbm91Z2guDQoN Cg0KIA0KPiBlcmljDQo+IA0KPiANCj4gDQo+ID4NCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gWGlh b2h1DQo+ID4NCj4gPiA+IEluIG9yZGVyIHRvIGF2b2lkIHRoaXMgY29sbGlzaW9uIHlvdSBuZWVk IHRvIGVuc3VyZSB0aGF0IHlvdXIgaGFzaGluZyBkb2Vzbid0DQo+ID4gPiBjb2xsaWRlIHdpdGgg eW91ciBlcGhlbWVyYWwgcG9ydCBhbGxvY2F0aW9uLCB3aGljaCBjb3VsZCBtZWFuIGEgdG9uIG9m DQo+ID4gPiByZWFsLXRpbWUgY29vcmRpbmF0aW9uIGJldHdlZW4gZm9yd2FyZGluZyBoYXJkd2Fy ZSBhbmQgdGhlIGhvc3Qgc3RhY2suDQo+ID4gPg0KPiA+ID4NCj4gPiA+IGVyaWMNCj4gPiA+DQo+ ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gPiA+IFhpYW9odQ0KPiA+ ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ IGVyaWMNCj4gPiA+ID4gPg0KDQo= From loa@pi.nu Wed Aug 15 04:54: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 7D6D721F86F3 for ; Wed, 15 Aug 2012 04:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZHfyTY2c5U8 for ; Wed, 15 Aug 2012 04:54:03 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id D728121F8438 for ; Wed, 15 Aug 2012 04:54:02 -0700 (PDT) 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) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 1F8D92A8003; Wed, 15 Aug 2012 13:54:01 +0200 (CEST) Message-ID: <502B8DD8.5050906@pi.nu> Date: Wed, 15 Aug 2012 13:54:00 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <4FFC3316.3080302@pi.nu> In-Reply-To: <4FFC3316.3080302@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , MPLS-TP ad hoc team , "draft-ietf-mpls-tp-itu-t-identifiers@tools.ietf.org" Subject: [mpls] Closed - Re: wg last call draft-ietf-mpls-tp-itu-t-identifiers-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, 15 Aug 2012 11:54:03 -0000 Working Group, this wg last call is closed. There were comments that the authors has been asked to resolve. /Loa On 2012-07-10 15:50, Loa Andersson wrote: > Working Group, > > this is to start a working group last call on > draft-ietf-mpls-tp-itu-t-identifiers-03. > > Please send your comments to the MPLS wg mailing list (mpls@ietf.org). > > We have done an IPR poll among the authors and on the mpls wg mailing > list. All the authors has responded that they are not aware any IPR > claims on this document. > > No IPR disclosures has been filed against this document. > > This working group last call would normally end July 22, 2012, but > since we at that time are in the publication cut-off period prior to > the Vancouver meeting this wg last call ends when the cut-off is > lifted. > > /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 adrian@olddog.co.uk Wed Aug 15 06:39: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 3F66E21F8836 for ; Wed, 15 Aug 2012 06:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrLkKPycBKpq for ; Wed, 15 Aug 2012 06:39:28 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 80AAF21F87ED for ; Wed, 15 Aug 2012 06:39:28 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7FDdQc8029655 for ; Wed, 15 Aug 2012 14:39:26 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7FDdPdh029636 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 15 Aug 2012 14:39:26 +0100 From: "Adrian Farrel" To: Date: Wed, 15 Aug 2012 14:39:21 +0100 Message-ID: <0bf101cd7aeb$60af5920$220e0b60$@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: Ac1661URs5yUMVx+QaG9E2tpOBHE2Q== Content-Language: en-gb Subject: [mpls] AD review of draft-ietf-mpls-tp-security-framework 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, 15 Aug 2012 13:39:29 -0000 Hi, I have done my review of this document and raised a number of structural issues with the authors and WG chairs. We will keep you posted as our discussions progress. For the moment I have marked the I-D as needing a new revision. Adrian From gregory.mirsky@ericsson.com Wed Aug 15 11:09: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 984BC11E80D7 for ; Wed, 15 Aug 2012 11:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.534 X-Spam-Level: X-Spam-Status: No, score=-6.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joG3kYXEhBlO for ; Wed, 15 Aug 2012 11:09:15 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id C5B0811E80D2 for ; Wed, 15 Aug 2012 11:09:14 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q7FI6j3K003592; Wed, 15 Aug 2012 13:09:26 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 15 Aug 2012 14:08:30 -0400 From: Gregory Mirsky To: "akatlas@juniper.net" , "rtorvi@juniper.net" , "mjork@juniper.net" , "mpls@ietf.org" Date: Wed, 15 Aug 2012 14:08:27 -0400 Thread-Topic: Comments to draft-torvi-mpls-rsvp-ingress-protection-00 Thread-Index: Ac17EPftgQo7tIrqT0i+MikMhoGKeQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF1392684B399EUSAACMS0715e_" MIME-Version: 1.0 Subject: [mpls] Comments to draft-torvi-mpls-rsvp-ingress-protection-00 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, 15 Aug 2012 18:09:15 -0000 --_000_FE60A4E52763E84B935532D7D9294FF1392684B399EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, et al., Please kindly consider my comments and questions: * The title of the document refers to RSVP-TE LSPs. But these could b= e unidirectional (MPLS-TE) or bidirectional (MPLS-TP). Does the discussion = of the RSVP-TE extension in the MPLS WG imply that the scope is on unidirec= tional MPLS-TE? If that is the case, then IP BFD might be used to monitor c= ontinuity in scenarios under consideration. But if MPLS-TP is in the scope = of the document, RFC 5884 or RFC 6428 should be used. * I do agree that ingress LER, as well as egress LER, protection is d= esirable but I think that this is service protection, not tunnel protection= problem. And to tackle it we might look at PW Redundancy http://tools.ietf= .org/html/draft-ietf-pwe3-redundancy-09, e.g. sections 3.2.1 and 3.2.2. * I think that Scenario B is an example of 1+1 Segment Protection. I = think that RFC 4873, though it is GMPLS, is relevant to this scenario. And = I am concerned that Source-MP OAM domain might be overlapping, which is pro= hibited in some OAM models, with OAM domains that monitor other segments of= the LSP (OAM domains can be enclosed, not overlapping). And if Source and = MP are in separate administrative domains, security might present additiona= l challenge. To avoid these issues, Service OAM can be used between Ces to = monitor working and protecting paths thus providing ingress and/or ergess L= ER protection. * In Scenario C, in my view, failure of the Ingress LER can not be re= liable differentiated from a failure of a link between Ingress and Backup I= ngress nodes. Thus the Backup might start forwarding traffic while the Ingr= ess is still forwading traffic. Regards, Greg --_000_FE60A4E52763E84B935532D7D9294FF1392684B399EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Authors, et al.,
Please kindly consider my comments and questions:
  • The title of the document refers to RSVP-TE LSPs. But these could be un= idirectional (MPLS-TE) or bidirectional (MPLS-TP). Does the discussion of t= he RSVP-TE extension in the MPLS WG imply that the scope is on unidirection= al MPLS-TE? If that is the case, then IP BFD might be used to monitor continuity in scenarios under consider= ation. But if MPLS-TP is in the scope of the document, RFC 5884 or RFC 6428= should be used.
  • I do agree that ingress LER, as well as egress LER= , protection is desirable but I think that this is service protection, not = tunnel protection problem. And to tackle it we might look at PW Redundancy = http://tools.ietf.org/html/draft-ietf-pwe3-redundancy-= 09, e.g. sections 3.2.1 and 3.2.2.
  • I think that Scenario B is an exampl= e of 1+1 Segment Protection. I think that RFC 4873, though it is GMPLS,= is relevant to this scenario. And I am concerned that Source-MP OAM domain= might be overlapping, which is prohibited in some OAM models, with OAM domains that monitor other segments of the LSP (OAM domains can be enclosed= , not overlapping). And if Source and MP are in separate administrative dom= ains, security might present additional challenge. To avoid these issues, S= ervice OAM can be used between Ces to monitor working and protecting paths thus providing ingress and/or erges= s LER protection.
  • In Scenario C, in my view, failure of the Ingress= LER can not be reliable differentiated from a failure of a link between In= gress and Backup Ingress nodes. Thus the Backup might start forwarding traf= fic while the Ingress is still forwading traffic.
 
        Regards,
           &nbs= p;    Greg
 
 --_000_FE60A4E52763E84B935532D7D9294FF1392684B399EUSAACMS0715e_-- From gregory.mirsky@ericsson.com Wed Aug 15 15:45: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 E0C9F21F84A7 for ; Wed, 15 Aug 2012 15:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=0.060, 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 zZxC3snDxs58 for ; Wed, 15 Aug 2012 15:45:31 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id ECB0421F84D6 for ; Wed, 15 Aug 2012 15:45:30 -0700 (PDT) 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 q7FMjohR028965; Wed, 15 Aug 2012 17:45:53 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 15 Aug 2012 18:45:24 -0400 From: Gregory Mirsky To: Pablo Frank , Yaacov Weingarten Date: Wed, 15 Aug 2012 18:45:23 -0400 Thread-Topic: [mpls] Comments on draft-weingarten-mpls-smp-requirements-00.txt Thread-Index: Ac13A7xvz2miJ80xQ6mi2hc3p3Nr4gADXyww Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF1392684B5D3EUSAACMS0715e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-weingarten-mpls-smp-requirements-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: Wed, 15 Aug 2012 22:45:33 -0000 --_000_FE60A4E52763E84B935532D7D9294FF1392684B5D3EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Pablo, Yaacov, et al., I've been following discussion with great deal of interest. I have some que= stions in addition to ones being brought up by Pablo: * Section 1.2 refers to operator's desire to have service restoration more ex= pedient than one achievable with control plane. I haven't seen any quantati= ve information to compare with. What is "expedient enough" for SMP? * Section 3.1 desrcibes, what can be called, "instant determinism" in regard = to SMP resource avaialability. I think that there's not enough reasoning to= conclude that almost instanteneous update of SMP resources avaialability i= s required. * In the last sentence of Section 3.1 non-control plane coordination of share= d resources presented as another requirement. And again I can not find how = we come to such conclusion, where the source of this requirement. Would exi= sting control plane signaling solution be sufficient for a MPLS network? * I've noticed that many requirements being referred to MPLS-TP, not MPLS, ne= tworks. Would that be a good reason to narrow scope of the document to MPLS= -TP networks only, starting with the name of the document? Regards, Greg ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Pab= lo Frank Sent: Friday, August 10, 2012 7:23 AM To: Yaacov Weingarten Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-weingarten-mpls-smp-requirements-00.t= xt Hi Yaacov, Some more comments inline... PF>> On Mon, Aug 6, 2012 at 8:56 AM, Yaacov Weingarten > wrote: Hi, Thank you for your comments. Please see my comments inline below. BR, yaacov On Tue, Jul 17, 2012 at 11:51 PM, Pablo Frank > wrote: Good draft and certainly something that needs to be done before we can star= t discussing specific solutions. Only a few comments / questions: - In 4.1.1, if one is operating in an MPLS-TP network that requires exclusi= ve use of the protection resources, doesn't this SHOULD requirement become = a MUST requirement? yw>> Sorry - but could you explain more fully this comment. PF>> If you're trying to meet RFC 5654 req 58b in particular, I would thin= k you MUST validate that enough protection resources are available (or are = preemptible) to carry 100% of the service traffic that is being restored. = In existing transport networks (i.e. OTN / sonet), this is typically done b= efore you switch traffic to the protection path. From a solution perspecti= ve, I think you'll probably want to leverage something like the locking mod= e that is being proposed for the 1:n draft. - Nit: you might want to avoid using the "query" verb in the title of 4.1.1= because it subtly suggests some kind of protocol messaging is required. I= would use the more generic verb "checking" or "verifying". yw>> Sounds OK to me. - In 4.3, there is no suggestion for what should happen if one or more fail= ing paths in an MPLS-TP network are of equal priority. I presume it will b= e some kind of first-come, first-serve requirement but this will bring up t= he question of how to break ties. yw>> This could be resolved along the lines that it was addressed in the 1:= n protection PF>> Except that you guys removed separate path priority from the latest ve= rsion of the 1:n draft. In the latest version, each path has a strict prio= rity defined by its path ID so ties were not possible. I don't think that = solution will work for SMP because I have a hard time seeing how all the va= rious endpoints involved in a shared mesh could coordinate non-overlapping = path IDs, while at the same time not exceeding the limit of 255 path IDs. - Also in 4.3, there is an allowance for a high priority path and a lower p= riority path to temporarily share the protection resources while preemption= is taking place. Two questions: - Is the ingress node to the shared segment expected to discard excess traf= fic now that the protection-path is temporarily oversubscribed? yw>> this would most probably follow standard MPLS behavior as described el= sewhere PF>> I guess I'll ask what is the standard behaviour? And is it applicable= to MPLS-TP networks? - If not, how do we ensure that other transport paths are unaffected? - The first paragraph of 4.4 appears to contradict 4.1.1. 4.4 seems to sug= gest that one MUST switch the traffic onto the protection path first and th= en get notified if there's not enough resources. That's probably okay in t= he general case. But in an MPLS-TP network, I don't think it's a good idea= to blindly switch low priority traffic onto the protection path and possib= ly disrupt a high priority path that is already using that resource. yw>> This is dependent upon the actual mechanism that is developed by the W= G. For example, one suggestion for the mechanism has notifications sent to= lower priority working paths making the protection path unavailable if it = is in use by a high-priority working path. - In section 4.5, there's an attempt to define "protection switching time" = as not including preemption time. I don't think end-users really care abou= t "protection switching time". They care about recovery time and IMO, that= should also include fault detection time (although it doesn't per RFC 5654= ) and any preemption time. yw>> we do try to work within the accepted definitions of the IETF! PF>> I guess there's two separate comments here that I kinda conflated toge= ther. One was more of a gripe: why did we exclude fault detection time fro= m the 50ms restoration time requirement in RFC 5654? I know that my custom= ers measure only one thing: how many ms of traffic do they lose after a bre= akage. I don't get a free pass on the ~10ms it takes for BFD to detect the= failure. According to RFC 5654, I could use 60sec CCMs and still meet the= 50ms requirement! The 2nd comment was really about this draft now trying to exclude preemptio= n time from restoration time as well. IMO, if it takes a few seconds for a= high priority service to finish preempting a lower priority service, then = we haven't met the 50ms restoration time requirement. Especially since it'= s typically my higher priority services that want 50ms restoration times in= the first place, so they'll be more often in a position to preempt. In ot= her words, I think we want preemption to be fast and is a critical componen= t of protection switching. regards, Pablo _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_FE60A4E52763E84B935532D7D9294FF1392684B5D3EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Pablo, Yaacov, et al.,
I've been following discussion with great deal of = interest.=20 I have some questions in addition to ones being brought up by=20 Pablo:
  • Section 1.2 refers to operator's desire to have service=20 restoration more expedient than one achievable with control pla= ne. I=20 haven't seen any quantative information to compare with. What is "expedie= nt=20 enough" for SMP?
  • Section 3.1 desrcibes, what can be called, "instant determinism"= in=20 regard to SMP resource avaialability. I think that there's not enough=20 reasoning to conclude that almost instanteneous update of SMP resources=20 avaialability is required.
  • In the last sentence of Section 3.1 non-control plane coordinati= on of=20 shared resources presented as another requirement. And again I can not fi= nd=20 how we come to such conclusion, where the source of this requirement. Wou= ld=20 existing control plane signaling solution be sufficient for a MPLS=20 network?
  • I've noticed that many requirements being referred to MPLS-TP, n= ot=20 MPLS, networks. Would that be a good reason to narrow scope of the docume= nt to=20 MPLS-TP networks only, starting with the name of the=20 document?
    Regards,
        Greg

From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of Pablo Frank
Sent:<= /B>=20 Friday, August 10, 2012 7:23 AM
To: Yaacov Weingarten
Cc:=20 mpls@ietf.org
Subject: Re: [mpls] Comments on=20 draft-weingarten-mpls-smp-requirements-00.txt

Hi Yaacov,

Some more comments inline... PF>>

On Mon, Aug 6, 2012 at 8:56 AM, Yaacov Weingarten = <wyaacov@gmail.com> wrote:
Hi,

Thank you for your comments.  Please see my comments inline=20 below.

BR,
yaacov

On Tue, Jul 17, 2012 at 11:51 PM, Pablo Frank <pabloisnot@gmail.com> wrote:
Good=20 draft and certainly something that needs to be done before we can start= =20 discussing specific solutions.

Only a few comments / questions:

- In 4.1.1, if one is operating in an MPLS-TP network that require= s=20 exclusive use of the protection resources, doesn't this SHOULD requirem= ent=20 become a MUST requirement?

yw>> Sorry - but could you explain more fully this=20 comment.

PF>>  If you're trying to meet RFC 5654 req 58b in particul= ar, I=20 would think you MUST validate that enough protection resources are availabl= e (or=20 are preemptible) to carry 100% of the service traffic that is being restore= d.=20  In existing transport networks (i.e. OTN / sonet), this is typically = done=20 before you switch traffic to the protection path.  From a solution=20 perspective, I think you'll probably want to leverage something like the lo= cking=20 mode that is being proposed for the 1:n draft.

- Nit: you might want to avoid using the "query" verb in the title= of=20 4.1.1 because it subtly suggests some kind of protocol messaging is=20 required.  I would use the more generic verb "checking" or=20 "verifying".
yw>> Sounds OK to me. 
- In 4.3, there is no suggestion for what should happen if one or = more=20 failing paths in an MPLS-TP network are of equal priority.  I pres= ume=20 it will be some kind of first-come, first-serve requirement but this wi= ll=20 bring up the question of how to break ties.
yw>> This could be resolved along the lines that it was addres= sed=20 in the 1:n protection

PF>> Except that you guys removed separate path priority from th= e=20 latest version of the 1:n draft.  In the latest version, each path has= a=20 strict priority defined by its path ID so ties were not possible.  I d= on't=20 think that solution will work for SMP because I have a hard time seeing how= all=20 the various endpoints involved in a shared mesh could coordinate non-overla= pping=20 path IDs, while at the same time not exceeding the limit of 255 path IDs.


- Also in 4.3, there is an allowance for a high priority path and = a=20 lower priority path to temporarily share the protection resources while= =20 preemption is taking place.  Two questions:
- Is the ingress node to the shared segment expected to discard= =20 excess traffic now that the protection-path is temporarily=20 oversubscribed?
yw>> this would most probably follow standard MPLS behavior as= =20 described elsewhere 

PF>> I guess I'll ask what is the standard behaviour?  And = is it=20 applicable to MPLS-TP networks?
 
- If not, how do we ensure that other transport paths are=20 unaffected?
- The first paragraph of 4.4 appears to contradict 4.1.1.  4.= 4=20 seems to suggest that one MUST switch the traffic onto the protection p= ath=20 first and then get notified if there's not enough resources.  That= 's=20 probably okay in the general case.  But in an MPLS-TP network, I d= on't=20 think it's a good idea to blindly switch low priority traffic onto the= =20 protection path and possibly disrupt a high priority path that is alrea= dy=20 using that resource.
yw>> This is dependent upon the actual mechanism that is devel= oped=20 by the WG.  For example, one suggestion for the mechanism has=20 notifications sent to lower priority working paths making the protection = path=20 unavailable if it is in use by a high-priority working path.
 
- In section 4.5, there's an attempt to define "protection switchi= ng=20 time" as not including preemption time.  I don't think end-users r= eally=20 care about "protection switching time".  They care about recovery = time=20 and IMO, that should also include fault detection time (although it doe= sn't=20 per RFC 5654) and any preemption time.
yw>> we do try to work within the accepted definitions of the= =20 IETF! 

PF>> I guess there's two separate comments here that I kinda=20 conflated together.  One was more of a gripe: why did we exclude fault= =20 detection time from the 50ms restoration time requirement in RFC 5654? &nbs= p;I=20 know that my customers measure only one thing: how many ms of traffic do th= ey=20 lose after a breakage.  I don't get a free pass on the ~10ms it takes = for=20 BFD to detect the failure.  According to RFC 5654, I could use 60sec C= CMs=20 and still meet the 50ms requirement!

The 2nd comment was really about this draft now trying to exclude=20 preemption time from restoration time as well.  IMO, if it takes a few= =20 seconds for a high priority service to finish preempting a lower priority=20 service, then we haven't met the 50ms restoration time requirement.=20  Especially since it's typically my higher priority services that want= 50ms=20 restoration times in the first place, so they'll be more often in a positio= n to=20 preempt.  In other words, I think we want preemption to be fast and is= a=20 critical component of protection switching.  
 

regards,
Pablo


_______________________________________________
m= pls=20 mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

<= /BLOCKQUOTE>


--_000_FE60A4E52763E84B935532D7D9294FF1392684B5D3EUSAACMS0715e_-- From liuzh_gz@qq.com Wed Aug 15 16:14: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 6DE2A21F85DB for ; Wed, 15 Aug 2012 16:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.845 X-Spam-Level: X-Spam-Status: No, score=-0.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] 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 Ln5MznQdBfQc for ; Wed, 15 Aug 2012 16:14:17 -0700 (PDT) Received: from smtpbg53.tencent.com (smtpbg53.tencent.com [64.71.138.62]) by ietfa.amsl.com (Postfix) with SMTP id AB2EE21F85D0 for ; Wed, 15 Aug 2012 16:14:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907; t=1345072447; bh=XITDIXILmuSuiUwKlznpVBOO6oooNwKNcm5kR+HQh+Y=; h=X-QQ-mid:Received:X-QQ-SSF:Date:From:To:Subject:References: X-Priority:X-Has-Attach:X-Mailer:Mime-Version:Message-ID: Content-Type; b=f7HbZDeeoqjs2MBiRNrEmZZtWxenYOz0ryv2Kv5GiMmvwcG0Wg3Nax564XF/M7GJZ FMO7Q3BDZ8R3uuks9G0L/d8BaMAJzyyjAZEYixZEJHw4tLKhWQDb0vlwUBZ3Kd/ X-QQ-mid: esmtp11t1345020476t023t15668 Received: from GSTA-DATA (unknown [120.88.10.149]) by esmtp4.qq.com (ESMTP) with id ; Wed, 15 Aug 2012 16:47:55 +0800 (CST) X-QQ-SSF: 0000000000000020F2100F000000000 Date: Wed, 15 Aug 2012 16:47:33 +0800 From: liuzh_gz To: mpls , mpls-chairs References: <201208151645598126595@gsta.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201208151647327349766@qq.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart576675842538_=----" Subject: Re: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-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, 15 Aug 2012 23:14:18 -0000 This is a multi-part message in MIME format. ------=_001_NextPart576675842538_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U3VwcG9ydA0KDQoNCg0KDQpsaXV6aF9neg0KDQoNCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+ID4+IA0KPiA+PiBNZXNzYWdlOiAzDQo+ID4+IERhdGU6IFR1ZSwgMzEgSnVs IDIwMTIgMTQ6MTE6MTYgKzAyMDANCj4gPj4gRnJvbTogTG9hIEFuZGVyc3NvbiA8bG9hQHBpLm51 Pg0KPiA+PiBUbzogIm1wbHNAaWV0Zi5vcmciIDxtcGxzQGlldGYub3JnPiwgICAgTWFydGluIFZp Z291cmV1eA0KPiA+PiAgICA8bWFydGluLnZpZ291cmV1eEBhbGNhdGVsLWx1Y2VudC5jb20+DQo+ ID4+IENjOiAibXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciIDxtcGxzLWNoYWlyc0B0b29scy5p ZXRmLm9yZz4NCj4gPj4gU3ViamVjdDogW21wbHNdIHdnIGRvYyBwb2xsIG9uIGRyYWZ0LWppbi1t cGxzLW1sZHAtbGVhZi1kaXNjb3ZlcnktMDQNCj4gPj4gTWVzc2FnZS1JRDogPDUwMTdDQjY0Ljkw NzA1MDdAcGkubnU+DQo+ID4+IENvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD1JU08t ODg1OS0xOyBmb3JtYXQ9Zmxvd2VkDQo+ID4+IA0KPiA+PiBXb3JraW5nIGdyb3VwLA0KPiA+PiAN Cj4gPj4gdGhpcyBpcyB0byBzdGFydCBhIHR3byB3ZWVrIHBvbGwgb24gYWRvcHRpbmcNCj4gPj4g ZHJhZnQtamluLW1wbHMtbWxkcC1sZWFmLWRpc2NvdmVyeS0wNA0KPiA+PiBhcyBhbiBNUExTIHdv cmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQo+ID4+IA0KPiA+PiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1l bnRzIChzdXBwb3J0L25vdCBzdXBwb3J0KSB0byB0aGUgbXBscyB3b3JraW5nDQo+ID4+IGdyb3Vw IG1haWxpbmcgbGlzdCAobXBsc0BpZXRmLm9yZykuDQo+ID4+IA0KPiA+PiBUaGlzIHBvbGwgZW5k cyBBdWd1c3QgMTcsIDIwMTIuDQo+ID4+IA0KPiA+PiAvTG9hDQo+ID4+IChtcGxzIHdnIGNvLWNo YWlyKQ0KPiA+PiAtLSANCj4gPj4gDQo+ID4+IA0KPiA+PiBMb2EgQW5kZXJzc29uICAgICAgICAg ICAgICAgICAgICAgICAgIGVtYWlsOiANCmxvYS5hbmRlcnNzb25AZXJpY3Nzb24uY29tDQo+ID4+ IFNyIFN0cmF0ZWd5IGFuZCBTdGFuZGFyZHMgTWFuYWdlciAgICAgICAgICAgIGxvYUBwaS5udQ0K PiA+PiBFcmljc3NvbiBJbmMgICAgICAgICAgICAgICAgICAgICAgICAgIHBob25lOiArNDYgMTAg NzE3IDUyIDEzDQo+ID4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICArNDYgNzY3IDcyIDkyIDEz ------=_001_NextPart576675842538_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Support
 
liuzh_gz
 
 
> >> ------------------------------
> >> 
> >> Message: 3
> >> Date: Tue, 31 Jul 2012&nb= sp;14:11:16 +0200
> >> From: Loa Andersson <loa@pi= .nu>
> >> To: "mpls@ietf.org" <mpls@ietf.o= rg>,    Martin Vigoureux
> >>    <martin.vigoureux@alcate= l-lucent.com>
> >> Cc: "mpls-chairs@tools.ietf.org" &l= t;mpls-chairs@tools.ietf.org>
> >> Subject: [mpls] wg doc po= ll on draft-jin-mpls-mldp-leaf-discovery-04
> >> Message-ID: <5017CB64.9070507@pi.nu&g= t;
> >> Content-Type: text/plain; charset= =3DISO-8859-1; format=3Dflowed
> >> 
> >> Working group,
> >> 
> >> this is to start a t= wo week poll on adopting
> >> draft-jin-mpls-mldp-leaf-discovery-04
> >> as an MPLS working group&= nbsp;document.
> >> 
> >> Please send your comments = ;(support/not support) to the mpls working
> >> group mailing list (mpls@ietf.= org).
> >> 
> >> This poll ends August 17,=  2012.
> >> 
> >> /Loa
> >> (mpls wg co-chair)
> >> -- 
> >> 
> >> 
> >> Loa Andersson    &nb= sp;            = ;        email: 
loa.andersson@ericsson.com
> >> Sr Strategy and Standards = ;Manager           =  loa@pi.nu
> >> Ericsson Inc    &nbs= p;            =          phone: +46 = ;10 717 52 13
> >>        &nb= sp;            = ;            &= nbsp;           &nb= sp; +46 767 72 92 13
------=_001_NextPart576675842538_=------ From adrian@olddog.co.uk Thu Aug 16 04:21: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 04CF721F85E6 for ; Thu, 16 Aug 2012 04:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 No2FlmiydPPl for ; Thu, 16 Aug 2012 04:21:28 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id AA44221F8606 for ; Thu, 16 Aug 2012 04:21:25 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7GBLOAF014242; Thu, 16 Aug 2012 12:21:24 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7GBLLss014204 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 Aug 2012 12:21:22 +0100 From: "Adrian Farrel" To: Date: Thu, 16 Aug 2012 12:21:17 +0100 Message-ID: <0da001cd7ba1$41c9aea0$c55d0be0$@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: Ac17oRkEPObiKMg1T6m8FOX+hMPW4Q== Content-Language: en-gb Cc: mpls@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 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, 16 Aug 2012 11:21:29 -0000 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. 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. Please work with the chairs and the working group to resolve these issues. Thanks, Adrian === 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." --- Please fix the format nits shown by idnits (page and line lengths). --- Per the exchanges on the MPLS mailing list, you need to replace "PHP as optional" with "PHP must be disabled by default" --- It would significantly help the reviewers if you could manage to format the page headers and footers, align the section headings. --- The Table of Contents is a bit messed up. --- There are a number of random page throws that mess up the formatting. --- 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. 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). 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). - - - - Abstract OLD The design considerations discussed in this documents ranging from NEW The design considerations discussed in this document range from - - - - Section 1.1 OLD The end of live for many NEW The end of life for many - - - - 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 - - - - Section 1.1 OLD MPLS-TP extended current MPLS OAM functions NEW MPLS-TP extended previous MPLS OAM functions --- 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. --- There are too many acronyms used in Section 1 without expansion. --- Section 1.2 I think Henry Yu asked for you to change his affiliation. --- s/2. Terminologies/2. Terminology/ --- 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. Please also decide whether G-ACH or 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. - - - - 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. - - - - 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. --- 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. --- 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? --- 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. Where does Section 1.2 sit with respect to the Authors and Contributors? Do you really need Section 1.2? --- s/10. Author's Addresses/10. Authors' Addresses/ From csekar@juniper.net Thu Aug 16 05:29: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 C7A7321F8587 for ; Thu, 16 Aug 2012 05:29:11 -0700 (PDT) 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 3ZvuHrXhHSY1 for ; Thu, 16 Aug 2012 05:29:11 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 194B521F84B6 for ; Thu, 16 Aug 2012 05:29:11 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKUCznjA4KVU3cR7VIvDln4buSCxiAK895@postini.com; Thu, 16 Aug 2012 05:29:11 PDT Received: from p-emfe01-bng.jnpr.net (10.211.204.19) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 16 Aug 2012 05:27:56 -0700 Received: from EMBX02-BNG.jnpr.net ([fe80::8ce3:7a6:9990:3c6e]) by p-emfe01-bng.jnpr.net ([::1]) with mapi; Thu, 16 Aug 2012 17:55:16 +0530 From: Chandrasekar R To: Loa Andersson , "mpls@ietf.org" , Martin Vigoureux Date: Thu, 16 Aug 2012 17:55:16 +0530 Thread-Topic: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-04 Thread-Index: Ac1vFaDMkKwEbwWLRWWtwU7ZdGmhOwMk/shw Message-ID: <105EB9F002CB164DA9ADD111BFC4DCFF1DC17E6C@EMBX02-BNG.jnpr.net> References: <5017CB64.9070507@pi.nu> In-Reply-To: <5017CB64.9070507@pi.nu> 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 Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-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, 16 Aug 2012 12:29:11 -0000 Do not support. > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Tuesday, July 31, 2012 5:41 PM > To: mpls@ietf.org; Martin Vigoureux > Cc: mpls-chairs@tools.ietf.org > Subject: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-04 >=20 > Working group, >=20 > this is to start a two week poll on adopting > draft-jin-mpls-mldp-leaf-discovery-04 > as an MPLS working group document. >=20 > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). >=20 > This poll ends August 17, 2012. >=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 adrian@olddog.co.uk Thu Aug 16 06:20: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 D15FB21F84BF for ; Thu, 16 Aug 2012 06:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 4oGpSHmeRG0h for ; Thu, 16 Aug 2012 06:20:00 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 72CB221F842B for ; Thu, 16 Aug 2012 06:20:00 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7GDJwcF005056; Thu, 16 Aug 2012 14:19:58 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7GDJvoC005034 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 Aug 2012 14:19:58 +0100 From: "Adrian Farrel" To: Date: Thu, 16 Aug 2012 14:19:53 +0100 Message-ID: <0dc501cd7bb1$d318ad10$794a0730$@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: Ac17sZfDkT27l/w9TrKEZ8PU5F3Mkg== Content-Language: en-gb Cc: mpls@ietf.org Subject: [mpls] AD review of draft-ietf-mpls-entropy-label 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, 16 Aug 2012 13:20:02 -0000 Hi, I have conducted my usual review of this draft before it moves on for IETF last call and IESG evaluation. The purpose of the review is to check that the document is ready to be published as an RFC and to try to dig out any nits that should be resolved before wider review. I am very impressed with the readability of this document and thank the authors for their work so far. There are a number of minor nits and small technical questions. I considered leaving these to be handled during IETF last call, but I think there are enough of them that we should get them fixed in a new revision before progressing further. Please feel free to debate any of the points with me. Can you please make a new revision, and as soon as I see it I will start the last call. Thanks, Adrian === Please fix the following idnits -- The draft header indicates that this document updates RFC5036, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3031, but the abstract doesn't seem to mention this, which it should. == Unused Reference: 'RFC4364' is defined on line 946, but no explicit reference was found in the text == Unused Reference: 'RFC4761' is defined on line 957, but no explicit reference was found in the text == Unused Reference: 'RFC4762' is defined on line 961, but no explicit reference was found in the text --- Need to expand a number of acronyms on first use because they show up before Section 1.1 LSR You need to add the following acronyms to Section 1.1 LSP PW --- Section 1.2 s/MPLS is very/MPLS is a very/ s/most notably: IP, PWE3/most notably: IP, PWs/ (in fact, in most cases s/PWE3/PW/) --- Section 3 The CoS field of an entropy label can be set to any value deemed appropriate. and The CoS field can be set to any value deemed appropriate; typically, this will be the value in the label above the ELI in the label stack. The field (formerly the EXP bits) is now known as the TC field per RFC 5462. --- Section 3 This is accomplished by REQUIRING that the label That is not a 2119 word. Try... To accomplish this, it is REQUIRED that the label --- Somewhere in the document you need to say what would happen if a legacy node accidentally received an ELI. I think the answer is easy: there is no label mapping for the received label, so the packet is dropped per section 3.18 of RFC 3031. It would be helpful to say this in Section 4.1. --- Section 4.2 1. On an incoming packet, identify the application to which the packet belongs, and thereby pick the fields to input to the load balancing function; call the output LB. I think "LB" is load balancing function. Suggest... 1. On an incoming packet, identify the application to which the packet belongs, and thereby pick the fields to input to the load balancing function (LB); call the output LB. --- Section 4.2 4. If, for the chosen tunnel, Y has not indicated that it can process ELs, push onto the packet. If Y has indicated that it can process ELs for the tunnel, push onto the packet. X SHOULD put the same TTL and TC fields for the ELI as it does for TL. The TTL for the EL MUST be zero. The TC for the EL may be any value. Why is this "SHOULD". Under what conditions MAY this be varied? --- 4.4. Penultimate Hop LSR No change is needed at penultimate hop LSRs. I'm not clear about this. Consider a simple tunnel carrying IP. Before using the entropy label, PHP was a pop-and-go function such that the whole MPLS header (including BoS) was stripped and only a native IP packet was forwarded onto the final hop of the LSP. The implication in what you write is that for when the entropy label is used, the forwarded packet will contain ELI and EL. Surely you want to strip them as well? Otherwise a router that did not previously handle MPLS headers will suddenly need to. I know that signaling (as described) will enable the egress to say whether it can handle EL, but I am not sure that helps. So the rule would be that whenever you pop a label that is immediately followed by ELI, you must also pop ELI and EL. From eosborne@cisco.com Thu Aug 16 08:11: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 51E7221F85AC for ; Thu, 16 Aug 2012 08:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 7lH06P5jupIz for ; Thu, 16 Aug 2012 08:11:39 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 21F7F21F85AD for ; Thu, 16 Aug 2012 08:11:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=1421; q=dns/txt; s=iport; t=1345129899; x=1346339499; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YiShtV22aE8adkZbODAAqEkAPo+CVWZhOw9Msyy8FOM=; b=OGSHAkmPEMc92h5PKmvVGXWQQpoluu1Lc5qUR1fhdOpf+mHIh3mIofpI zKF/YwVEov8wIoLgOPtS6o+TWa3df8eI39qb7hQe3nifNOwGQsv+lFimT 3NLngd1dQpBSePv/2ReKVhoDd8S/scasobOR2lHwdJlGYFvKPjLobixjL w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAC8NLVCtJV2Y/2dsb2JhbABFuiSBB4IgAQEBBAEBAQ8BJzQLDAICAgEIEQQBAQsUCQcbDAsUCQgCBAENBQgah2sLmjegJQQEiwWFd2ADo3uBZoJfgV8 X-IronPort-AV: E=Sophos;i="4.77,778,1336348800"; d="scan'208";a="112244931" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 16 Aug 2012 15:11:34 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7GFBYvH030935 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Aug 2012 15:11:34 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0298.004; Thu, 16 Aug 2012 10:11:34 -0500 From: "Eric Osborne (eosborne)" To: Loa Andersson , "mpls@ietf.org" , "Martin Vigoureux" Thread-Topic: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-04 Thread-Index: AQHNbxWaReNKZm1K5UinyUyV4kO5YpdcpC5A Date: Thu, 16 Aug 2012 15:11:33 +0000 Message-ID: <20ECF67871905846A80F77F8F4A275720F5453A9@xmb-rcd-x09.cisco.com> References: <5017CB64.9070507@pi.nu> In-Reply-To: <5017CB64.9070507@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.23.87] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19116.000 x-tm-as-result: No--32.624100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-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, 16 Aug 2012 15:11:40 -0000 Sorry if this is late. I saw that Kamran had some comments as part of the RT review. The reply wa= s that they would be addressed in the 'next version'. I don't believe they= have been, as -04 dates back to May 2012. I don't believe WG status is wa= rranted until the authors can make the changes they'd committed to. eric > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Tuesday, July 31, 2012 8:11 AM > To: mpls@ietf.org; Martin Vigoureux > Cc: mpls-chairs@tools.ietf.org > Subject: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-04 >=20 > Working group, >=20 > this is to start a two week poll on adopting > draft-jin-mpls-mldp-leaf-discovery-04 > as an MPLS working group document. >=20 > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). >=20 > This poll ends August 17, 2012. >=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 lufang@cisco.com Thu Aug 16 08: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 7AB9621F85AC for ; Thu, 16 Aug 2012 08:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.114 X-Spam-Level: X-Spam-Status: No, score=-10.114 tagged_above=-999 required=5 tests=[AWL=0.485, 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 Z-QdyoeiFCb4 for ; Thu, 16 Aug 2012 08:18:45 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 4258B21F85A7 for ; Thu, 16 Aug 2012 08:18:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=7198; q=dns/txt; s=iport; t=1345130325; x=1346339925; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hphwsPkzPqN+CRIaRtOP37XoQrVMR52Gg443eJ+NMG8=; b=gcr+pE8y637BUDO4HBH8iglSXd1CIiBA2IaB5YXCve9gUFdwI1GNd6Oj tz157P5DHtMUZLib/mneRSUFh4ogwNVnDUZDXpvQm3Bf9ACWMooSyveGg DtcIpHjsoq3B9Ls+V5nOI+ZMRyNkGSPzP549vXAT3V/4CjxMqiaBrXCU0 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABoPLVCtJV2Y/2dsb2JhbAA7CrolgQeCIAEBAQQBAQEPASc0CwwEAgEIEQQBAQsUCQcnCxQJCAEBBAENBQgRCYdrC5o3oCUEiwkQhWdgA6N7gWaCXw X-IronPort-AV: E=Sophos;i="4.77,778,1336348800"; d="scan'208";a="112258745" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 16 Aug 2012 15:18:24 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7GFIOVU008054 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Aug 2012 15:18:24 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.155]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0298.004; Thu, 16 Aug 2012 10:18:23 -0500 From: "Luyuan Fang (lufang)" To: "adrian@olddog.co.uk" , "draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org" Thread-Topic: [mpls] AD review of draft-ietf-mpls-tp-use-cases-and-design Thread-Index: Ac17oRkEPObiKMg1T6m8FOX+hMPW4QAHkqjg Date: Thu, 16 Aug 2012 15:18:23 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD930F4E4C38@xmb-rcd-x03.cisco.com> References: <0da001cd7ba1$41c9aea0$c55d0be0$@olddog.co.uk> In-Reply-To: <0da001cd7ba1$41c9aea0$c55d0be0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.83.56] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19116.000 x-tm-as-result: No--65.870600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [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: Thu, 16 Aug 2012 15:18:46 -0000 Adrian, Thank you very much for your AD review and comments, appreciate your effort= to help identify the issues in details. We'll revise the document to address all comments and work with chairs and = working group to resolve all issues. Thanks, Luyuan > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Adrian Farrel > Sent: Thursday, August 16, 2012 7:21 AM > To: draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org > Cc: mpls@ietf.org > Subject: [mpls] AD review of draft-ietf-mpls-tp-use-cases-and-design >=20 > Hi, >=20 > 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. >=20 > 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. >=20 > Please work with the chairs and the working group to resolve these > issues. >=20 > Thanks, > Adrian >=20 > =3D=3D=3D >=20 > 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. >=20 > 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." >=20 > --- >=20 > Please fix the format nits shown by idnits (page and line lengths). >=20 > --- >=20 > Per the exchanges on the MPLS mailing list, you need to replace "PHP as > optional" with "PHP must be disabled by default" >=20 > --- >=20 > It would significantly help the reviewers if you could manage to > format the page headers and footers, align the section headings. >=20 > --- >=20 > The Table of Contents is a bit messed up. >=20 > --- >=20 > There are a number of random page throws that mess up the formatting. >=20 > --- >=20 > 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. >=20 > 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). >=20 > Here are a few examples from early in the document... >=20 > - - - - >=20 > Abstract >=20 > OLD > for Multiprotocol Label Switching Transport > profile (MPLS-TP). > NEW > for the Multiprotocol Label Switching Transport > Profile (MPLS-TP). >=20 > - - - - >=20 > Abstract >=20 > OLD > The > design considerations discussed in this documents ranging from > NEW > The > design considerations discussed in this document range from >=20 > - - - - >=20 > Section 1.1 >=20 > OLD > The end of live for many > NEW > The end of life for many >=20 > - - - - >=20 > Section 1.1 >=20 > OLD > MPLS-TP re-use a subset of > MPLS base functions > NEW > MPLS-TP re-uses a subset of > MPLS base functions >=20 > - - - - >=20 > Section 1.1 >=20 > OLD > MPLS-TP extended current MPLS OAM > functions > NEW > MPLS-TP extended previous MPLS OAM > functions >=20 > --- >=20 > 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. >=20 > --- >=20 > There are too many acronyms used in Section 1 without expansion. >=20 > --- >=20 > Section 1.2 >=20 > I think Henry Yu asked for you to change his affiliation. >=20 > --- >=20 > s/2. Terminologies/2. Terminology/ >=20 > --- >=20 > 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. >=20 > Please also decide whether G-ACH or G-ACh. >=20 > --- >=20 > 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. >=20 > - - - - >=20 > Section 3.2 >=20 > MPLS-TP extended the LSP support from unidirectional to both bi- > directional unidirectional support. >=20 > 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. >=20 > - - - - >=20 > Section 3.3 >=20 > 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. >=20 > --- >=20 > 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. >=20 > Furthermore the section ends with... >=20 > More discussion will be added on how to manage the Relative delay > time. >=20 > ...and this does not convince me that the document is complete. >=20 > --- >=20 > Section 6 >=20 > 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? >=20 > --- >=20 > 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. >=20 > Where does Section 1.2 sit with respect to the Authors and > Contributors? Do you really need Section 1.2? >=20 > --- >=20 > s/10. Author's Addresses/10. Authors' Addresses/ >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From lufang@cisco.com Thu Aug 16 08:36: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 59DDC21F859B for ; Thu, 16 Aug 2012 08:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.137 X-Spam-Level: X-Spam-Status: No, score=-10.137 tagged_above=-999 required=5 tests=[AWL=0.462, 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 0B7cYZDhYAQe for ; Thu, 16 Aug 2012 08:36:07 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 828A921F8596 for ; Thu, 16 Aug 2012 08:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=927; q=dns/txt; s=iport; t=1345131367; x=1346340967; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=MYf2EjUiUpvNQAi+WFl/BFU7CVbspgvI+eQGL0LFiA8=; b=hqUtWB6LoSZVJMzkZbwHJSt0gjPxV/37mqGFiqV1I7eo+qzFRv67cbko sXlApOndj5YDoVLkQLgLxUL7f8iqbZ2VguF/6zyTs/6sHMnS10I9KJ/Pi 22wsAMzt+SsYJ65Z6xuivKHFV08KDg7c4pu0xhNk1uO4FC9h+L8kDA8JL I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAEYSLVCtJXHB/2dsb2JhbABFhTq0a4EHgiABAQEEAQEBDwEnNBcEAgEIEQQBAQsUCQcnCxQJCAEBBAESCBqHawuaMqAkBIsJhXdgA6N7gWaCXw X-IronPort-AV: E=Sophos;i="4.77,778,1336348800"; d="scan'208";a="112284720" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 16 Aug 2012 15:36:07 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q7GFa6tD024073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Aug 2012 15:36:06 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.155]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0298.004; Thu, 16 Aug 2012 10:36:06 -0500 From: "Luyuan Fang (lufang)" To: "adrian@olddog.co.uk" , "mpls@ietf.org" Thread-Topic: [mpls] AD review of draft-ietf-mpls-tp-security-framework Thread-Index: Ac1661URs5yUMVx+QaG9E2tpOBHE2QA2Fs8Q Date: Thu, 16 Aug 2012 15:36:06 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD930F4E4C87@xmb-rcd-x03.cisco.com> References: <0bf101cd7aeb$60af5920$220e0b60$@olddog.co.uk> In-Reply-To: <0bf101cd7aeb$60af5920$220e0b60$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.83.56] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19116.000 x-tm-as-result: No--31.392200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] AD review of draft-ietf-mpls-tp-security-framework 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, 16 Aug 2012 15:36:08 -0000 Adrian, Thanks a lot for your AD review and comments, they are very helpful. We'll revise the document to address the structural issues and other commen= ts, and work with chairs and working group to resolve all issues. Thanks, Luyuan > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Adrian Farrel > Sent: Wednesday, August 15, 2012 9:39 AM > To: mpls@ietf.org > Subject: [mpls] AD review of draft-ietf-mpls-tp-security-framework >=20 > Hi, >=20 > I have done my review of this document and raised a number of > structural issues > with the authors and WG chairs. We will keep you posted as our > discussions > progress. For the moment I have marked the I-D as needing a new > revision. >=20 > Adrian >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From kireeti@juniper.net Thu Aug 16 15:37: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 15CF221F85CC for ; Thu, 16 Aug 2012 15:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.266 X-Spam-Level: X-Spam-Status: No, score=-6.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_32=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 systHKMg057L for ; Thu, 16 Aug 2012 15:37:04 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id BC71121F858A for ; Thu, 16 Aug 2012 15:36:55 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKUC12AcO186xiL4pFoHIj/NYl2qha/Zg1@postini.com; Thu, 16 Aug 2012 15:36:55 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 16 Aug 2012 15:35:44 -0700 From: Kireeti Kompella To: "adrian@olddog.co.uk" Date: Thu, 16 Aug 2012 15:35:43 -0700 Thread-Topic: AD review of draft-ietf-mpls-entropy-label Thread-Index: Ac17/3i9i7y3tkJESfyacmyNuUPRvg== Message-ID: References: <0dc501cd7bb1$d318ad10$794a0730$@olddog.co.uk> In-Reply-To: <0dc501cd7bb1$d318ad10$794a0730$@olddog.co.uk> 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 Cc: "mpls@ietf.org" , "draft-ietf-mpls-entropy-label@tools.ietf.org" Subject: Re: [mpls] AD review of draft-ietf-mpls-entropy-label 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, 16 Aug 2012 22:37:05 -0000 Hi Adrian, On Aug 16, 2012, at 6:19 , Adrian Farrel wrote: > Hi, >=20 > I have conducted my usual review of this draft before it moves on for > IETF last call and IESG evaluation. The purpose of the review is to=20 > check that the document is ready to be published as an RFC and to try > to dig out any nits that should be resolved before wider review. I appreciate that, and appreciate as well your thorough review. > I am very impressed with the readability of this document and thank the > authors for their work so far. There are a number of minor nits and=20 > small technical questions. I considered leaving these to be handled=20 > during IETF last call, but I think there are enough of them that we > should get them fixed in a new revision before progressing further. >=20 > Please feel free to debate any of the points with me. See inline. > Can you please make a new revision, and as soon as I see it I will start > the last call. I agree with most of what you say, and will produce a new version incorpora= ting them, with the tweaks mentioned below. I'll post this Monday Aug 20. = If before then I get wording or a reference for behavior for ununderstood = reserved labels, I'll include that as well. If anyone has an alternative t= o the way I propose dealing with your comments re sect 4.4, please speak up= ! > Thanks, > Adrian >=20 > =3D=3D=3D >=20 > Please fix the following idnits Will do. > Section 1.2 > Section 3 > Section 3 Okay to all of the above. > --- >=20 > Somewhere in the document you need to say what would happen if a=20 > legacy node accidentally received an ELI. I think the answer is easy: > there is no label mapping for the received label, so the packet is > dropped per section 3.18 of RFC 3031. It would be helpful to say this > in Section 4.1. Good point. Since the ELI is (will be) a reserved label, the handling of that should be= well-defined. However, I don't see it; section 2.1 of 3032 sets some labe= ls apart as reserved, gives meaning to a few of them, and remains mum about= the rest. Is there an RFC that describes the desired/expected behavior on= receiving an ununderstood reserved label? That would be perfect for this = purpose. If not, I will make up some words. > --- >=20 > Section 4.2 Will rewrite for clarity. > --- >=20 > Section 4.2 >=20 > 4. If, for the chosen tunnel, Y has not indicated that it can > process ELs, push onto the packet. If Y has indicated that > it can process ELs for the tunnel, push onto the > packet. X SHOULD put the same TTL and TC fields for the ELI as > it does for TL. The TTL for the EL MUST be zero. The TC for the > EL may be any value. >=20 > Why is this "SHOULD". Under what conditions MAY this be varied? This relates to your point below about PHP. If the tunnel is PHP-ed, the E= LI serves as a proxy for the tunnel label, at least insofar as the TTL and = CoS^h^h^h TC bits go. Hence the SHOULD. Different choices of TTL and TC m= ay lead to unexpected behavior on the egress. However, if PHP is not used = (or if as you suggest the PHP LSR strips ELI+EL), it might not matter, but = the lack of warmth and fuzziness distresses me. I'm open to alternate opin= ions, though. > --- >=20 > 4.4. Penultimate Hop LSR >=20 > No change is needed at penultimate hop LSRs. >=20 > I'm not clear about this. >=20 > Consider a simple tunnel carrying IP. > Before using the entropy label, PHP was a pop-and-go function such that > the whole MPLS header (including BoS) was stripped and only a native IP > packet was forwarded onto the final hop of the LSP. Good point. > The implication in what you write is that for when the entropy label is > used, the forwarded packet will contain ELI and EL. Surely you want to > strip them as well? Otherwise a router that did not previously handle > MPLS headers will suddenly need to. So far, ELs affect ingress and egress LSRs, which is nice. I'll be happy t= o add this as a MAY in this section. Also mumble something about load bala= ncing on the last hop. > I know that signaling (as described) will enable the egress to say > whether it can handle EL, but I am not sure that helps. I'll also remind folks (in section 5) that an LSR signaling EL capability h= ad better be prepared to pop ELI+EL. Thanks again for the detailed review! Kireeti. From kireeti@juniper.net Thu Aug 16 15:52: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 07B8E11E80A3 for ; Thu, 16 Aug 2012 15:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 ySgGX5uizG9z for ; Thu, 16 Aug 2012 15:52:44 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 898D211E808A for ; Thu, 16 Aug 2012 15:52:44 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUC15to3qsbDKMkI6Y0r8F+LgFlpqIdRN@postini.com; Thu, 16 Aug 2012 15:52:44 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 16 Aug 2012 15:49:55 -0700 From: Kireeti Kompella To: "adrian@olddog.co.uk" Date: Thu, 16 Aug 2012 15:49:53 -0700 Thread-Topic: AD review of draft-ietf-mpls-entropy-label Thread-Index: Ac18AXPrrexfdsfuQ9GwZDTCBf+40w== Message-ID: References: <0dc501cd7bb1$d318ad10$794a0730$@olddog.co.uk> In-Reply-To: <0dc501cd7bb1$d318ad10$794a0730$@olddog.co.uk> 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 Cc: "mpls@ietf.org" , "draft-ietf-mpls-entropy-label@tools.ietf.org" Subject: Re: [mpls] AD review of draft-ietf-mpls-entropy-label 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, 16 Aug 2012 22:52:45 -0000 On Aug 16, 2012, at 6:19 , Adrian Farrel wrote: > -- The draft header indicates that this document updates RFC5036, but th= e > abstract doesn't seem to mention this, which it should. >=20 > -- The draft header indicates that this document updates RFC3031, but th= e > abstract doesn't seem to mention this, which it should. While on the subject, should this document state that it updates 5420 (LSP = attrs) and labeled BGP (3107)? (If not, should this document NOT state tha= t it updates 5036?) If I add mumble about dealing with ELI, can that be construed as updating 3= 032? I don't know the accepted practices regarding the "updates <>" attributes, = so just say the word. Kireeti. From kam.lam@alcatel-lucent.com Thu Aug 16 17:34: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 9836B21F8589 for ; Thu, 16 Aug 2012 17:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.249 X-Spam-Level: X-Spam-Status: No, score=-8.249 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 kHCxinl1UWjV for ; Thu, 16 Aug 2012 17:34:58 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id A280521F8584 for ; Thu, 16 Aug 2012 17:34:57 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q7H0Yt23014423 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 17 Aug 2012 02:34:55 +0200 Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 17 Aug 2012 02:34:55 +0200 Received: from US70TWXCHMBA12.zam.alcatel-lucent.com ([169.254.6.16]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Thu, 16 Aug 2012 20:34:52 -0400 From: "Lam, Hing-Kam (Kam)" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] wg last call draft-ietf-mpls-tp-itu-t-identifiers-03 Thread-Index: AQHNab66APDQT38/2Ei5ZTBmg9h/dJddTEZQ Date: Fri, 17 Aug 2012 00:34:51 +0000 Message-ID: <8DBC3FDAC14BE441AED9C5939C77758509BA2DD8@US70TWXCHMBA12.zam.alcatel-lucent.com> References: <4FFC3316.3080302@pi.nu> <500ED60E.5000106@pi.nu> In-Reply-To: <500ED60E.5000106@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.11] 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.83 Cc: "mpls-chairs@tools.ietf.org" , MPLS-TP ad hoc team , "draft-ietf-mpls-tp-itu-t-identifiers@tools.ietf.org" Subject: Re: [mpls] wg last call draft-ietf-mpls-tp-itu-t-identifiers-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, 17 Aug 2012 00:34:58 -0000 Yes, support. Sorry for this belated support. Regards, Kam > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Tuesday, July 24, 2012 1:06 PM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; MPLS-TP ad hoc team; draft-ietf-mpls- > tp-itu-t-identifiers@tools.ietf.org > Subject: Re: [mpls] wg last call draft-ietf-mpls-tp-itu-t-identifiers- > 03 >=20 > Working Group, >=20 > this working group last call were supposed to end on July 22nd. >=20 > However, we have not had one single comment on the draft during > the last call period. >=20 > We are therefore extending the wg last call until August 10, 2012. >=20 > We have also selected some members of the of the MPLS Review Team > whom we asked to review the draft and respond during the extended > working group last > call period. >=20 > /Loa > for the MPLS wG co-charis >=20 > On 2012-07-10 15:50, Loa Andersson wrote: > > Working Group, > > > > this is to start a working group last call on > > draft-ietf-mpls-tp-itu-t-identifiers-03. > > > > Please send your comments to the MPLS wg mailing list (mpls@ietf.org). > > > > We have done an IPR poll among the authors and on the mpls wg mailing > > list. All the authors has responded that they are not aware any IPR > > claims on this document. > > > > No IPR disclosures has been filed against this document. > > > > This working group last call would normally end July 22, 2012, but > > since we at that time are in the publication cut-off period prior to > > the Vancouver meeting this wg last call ends when the cut-off is > > lifted. > > > > /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 adrian@olddog.co.uk Thu Aug 16 23:28: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 ECFC221F8554 for ; Thu, 16 Aug 2012 23:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 0DAPixu6KBFO for ; Thu, 16 Aug 2012 23:28:47 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5E421F8550 for ; Thu, 16 Aug 2012 23:28:46 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7H6SjBb028653; Fri, 17 Aug 2012 07:28:45 +0100 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 q7H6SiOK028644 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 17 Aug 2012 07:28:44 +0100 From: "Adrian Farrel" To: "'Kireeti Kompella'" References: <0dc501cd7bb1$d318ad10$794a0730$@olddog.co.uk> In-Reply-To: Date: Fri, 17 Aug 2012 07:28:38 +0100 Message-ID: <0ed401cd7c41$8a1828d0$9e487a70$@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: AQHPHuSqRl1cgpHy+Pw5z8k+/Sb7UAF5YjHTl052P7A= Content-Language: en-gb Cc: mpls@ietf.org, draft-ietf-mpls-entropy-label@tools.ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-entropy-label 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, 17 Aug 2012 06:28:48 -0000 Well, you would ask, wouldn't you? The IESG is currently going through a debate about the correct meaning of "updates". The currently in force meaning is found in RFC 2223 although there is an rfc2223bis draft. RFC 2223 states Updates To be used as a reference from a new item that cannot be used alone (i.e., one that supplements a previous document), to refer to the previous document. The newer publication is a part that will supplement or be added on to the existing document; e.g., an addendum, or separate, extra information that is to be added to the original document. rfc2223bis states Updates Specifies an earlier document whose contents are modified or augmented by the new document. The new document cannot be used alone, it can only be used in conjunction with the earlier document. The IESG thinks: - these definitions suck - "updates" has not been used consistently in the past - it doesn't (yet) have consensus on a better meaning. Several ADs have been trying to pursue a more limited view of "updates" as follows... RFC Y updates RFC X if and only if new implementations of RFC X will be expected to also implement RFC Y. This allows for the following to be classed as updates: - clarifications and interpretations - bug fixes - resolved omissions - mandatory extensions - optional extensions But the last of these sits a little on the fence because it is unclear to say what it means to support an optional extension by opting to not implement it :-) However, I think a view of this is to ask, suppose you made a "full function" implementation of RFC X: would you also implement RFC Y? Now, to your specific case... As I understand it, the intention is that entropy label becomes a core feature of MPLS networks. We hope that going forward, all implementations will support EL. That means that the signaling protocols will also need to support EL. So I am comfortable with updates for 3031 and 5036. I thought about 3032, but had a look and didn't think it is updated. Yes, you could include 3209 and 3017. I don't believe this updates 5420 - it defines a new flag, but makes no change to LSP Attributes processing. Clear? I hope no clearer for you than for me! Adrian > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: 16 August 2012 23:50 > To: adrian@olddog.co.uk > Cc: Kireeti Kompella; draft-ietf-mpls-entropy-label@tools.ietf.org; mpls@ietf.org > Subject: Re: AD review of draft-ietf-mpls-entropy-label > > On Aug 16, 2012, at 6:19 , Adrian Farrel wrote: > > > -- The draft header indicates that this document updates RFC5036, but the > > abstract doesn't seem to mention this, which it should. > > > > -- The draft header indicates that this document updates RFC3031, but the > > abstract doesn't seem to mention this, which it should. > > While on the subject, should this document state that it updates 5420 (LSP attrs) > and labeled BGP (3107)? (If not, should this document NOT state that it updates > 5036?) > > If I add mumble about dealing with ELI, can that be construed as updating 3032? > > I don't know the accepted practices regarding the "updates <>" attributes, so just > say the word. > > Kireeti. From adrian@olddog.co.uk Thu Aug 16 23:43: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 BDD4221F8577 for ; Thu, 16 Aug 2012 23:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 PMtS3ERhqSqH for ; Thu, 16 Aug 2012 23:43:24 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id E337221F8570 for ; Thu, 16 Aug 2012 23:43:23 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7H6hMaX031896; Fri, 17 Aug 2012 07:43:22 +0100 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 q7H6hKej031885 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 17 Aug 2012 07:43:21 +0100 From: "Adrian Farrel" To: "'Kireeti Kompella'" References: <0dc501cd7bb1$d318ad10$794a0730$@olddog.co.uk> In-Reply-To: Date: Fri, 17 Aug 2012 07:43:14 +0100 Message-ID: <0edf01cd7c43$94feec00$befcc400$@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: AQHPHuSqRl1cgpHy+Pw5z8k+/Sb7UAKzUXN9l0SrSbA= Content-Language: en-gb Cc: mpls@ietf.org, draft-ietf-mpls-entropy-label@tools.ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-entropy-label 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, 17 Aug 2012 06:43:24 -0000 Hi Kireeti, All looks good. See in snipped-line. A > > Somewhere in the document you need to say what would happen if a > > legacy node accidentally received an ELI. I think the answer is easy: > > there is no label mapping for the received label, so the packet is > > dropped per section 3.18 of RFC 3031. It would be helpful to say this > > in Section 4.1. > > Good point. > > Since the ELI is (will be) a reserved label, the handling of that should be well- > defined. However, I don't see it; section 2.1 of 3032 sets some labels apart as > reserved, gives meaning to a few of them, and remains mum about the rest. Is > there an RFC that describes the desired/expected behavior on receiving an > ununderstood reserved label? That would be perfect for this purpose. > > If not, I will make up some words. I think I already gave the reference for processing unknown reserved labels. The processing is the same as for any unknown label. That is in section 3.18 of RFC 3031. > > Section 4.2 > > > > 4. If, for the chosen tunnel, Y has not indicated that it can > > process ELs, push onto the packet. If Y has indicated that > > it can process ELs for the tunnel, push onto the > > packet. X SHOULD put the same TTL and TC fields for the ELI as > > it does for TL. The TTL for the EL MUST be zero. The TC for the > > EL may be any value. > > > > Why is this "SHOULD". Under what conditions MAY this be varied? > > This relates to your point below about PHP. If the tunnel is PHP-ed, the ELI > serves as a proxy for the tunnel label, at least insofar as the TTL and CoS^h^h^h > TC bits go. Hence the SHOULD. Different choices of TTL and TC may lead to > unexpected behavior on the egress. However, if PHP is not used (or if as you > suggest the PHP LSR strips ELI+EL), it might not matter, but the lack of warmth > and fuzziness distresses me. I'm open to alternate opinions, though. So... OLD X SHOULD put the same TTL and TC fields for the ELI as it does for TL. NEW X SHOULD put the same TTL and TC fields for the ELI as it does for TL to protect LSP behavior in cases where PHP is used and the ELI and EL are not stripped at the previous hop (see Section 4.4). If it is known that PHP is not used or that PHP will strip the ELI and EL, the TTL and TC of the ELI MAY be set differently. END ***or*** s/SHOULD/MUST/ Cheers, Adrian From kireeti@juniper.net Fri Aug 17 10:51: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 D5C3A21F8475 for ; Fri, 17 Aug 2012 10:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 FYtc7Z6EaD2X for ; Fri, 17 Aug 2012 10:51:20 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 409AD21F8448 for ; Fri, 17 Aug 2012 10:51:20 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUC6EksfVVbtiuz4dRrVdB7Lahx8cIWYa@postini.com; Fri, 17 Aug 2012 10:51:20 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 17 Aug 2012 10:48:49 -0700 From: Kireeti Kompella To: "adrian@olddog.co.uk" Date: Fri, 17 Aug 2012 10:48:48 -0700 Thread-Topic: AD review of draft-ietf-mpls-entropy-label Thread-Index: Ac18oI5AmMlDJEf4T0GSX4EPF9l4UA== Message-ID: <01B0F64B-A1E8-43D5-B0AA-001EA79AADF3@juniper.net> References: <0dc501cd7bb1$d318ad10$794a0730$@olddog.co.uk> <0ed401cd7c41$8a1828d0$9e487a70$@olddog.co.uk> In-Reply-To: <0ed401cd7c41$8a1828d0$9e487a70$@olddog.co.uk> 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 Cc: "mpls@ietf.org" , "draft-ietf-mpls-entropy-label@tools.ietf.org" Subject: Re: [mpls] AD review of draft-ietf-mpls-entropy-label 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, 17 Aug 2012 17:51:20 -0000 Hi Adrian, Yes, I had to ask. I'm sorry I did :-) RFC Y updates RFC X if and only if new implementations of RFC X will be expected to also implement RFC Y. Don't really want to get into the debate, but has anyone considered: RFC Y updates RFC X iff the content of Y will be incorporated into X i= f X is ever republished, e.g., promoted (PS to Draft Standard to Full S)= . ? (Don't answer that. I will NOT be sucked into this debate.) On Aug 16, 2012, at 23:28 , Adrian Farrel wrote: > Now, to your specific case... > As I understand it, the intention is that entropy label becomes a core fe= ature > of MPLS networks. We hope that going forward, all implementations will su= pport > EL. That means that the signaling protocols will also need to support EL. > So I am comfortable with updates for 3031 and 5036.=20 > I thought about 3032, but had a look and didn't think it is updated. > Yes, you could include 3209 and 3017. > I don't believe this updates 5420 - it defines a new flag, but makes no c= hange > to LSP Attributes processing. >=20 > Clear? Clear enough. I will add 3107 and 3209, leave out 5420 and 3032. Thanks for your help! Kireeti. From kireeti@juniper.net Fri Aug 17 11:04: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 A314221E8044 for ; Fri, 17 Aug 2012 11:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 k2dcaJDlmIL1 for ; Fri, 17 Aug 2012 11:04:07 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id E265F11E80E0 for ; Fri, 17 Aug 2012 11:04:06 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUC6HkLKSJZ2XyyIbg4uw+/2No+5WoveE@postini.com; Fri, 17 Aug 2012 11:04:07 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 17 Aug 2012 11:01:43 -0700 From: Kireeti Kompella To: "adrian@olddog.co.uk" Date: Fri, 17 Aug 2012 11:01:42 -0700 Thread-Topic: AD review of draft-ietf-mpls-entropy-label Thread-Index: Ac18oluGXfiTD6BdSraQwNkO52csXA== Message-ID: <3E2B22DB-9FF6-41D0-92C3-85E25FF57ECF@juniper.net> References: <0dc501cd7bb1$d318ad10$794a0730$@olddog.co.uk> <0edf01cd7c43$94feec00$befcc400$@olddog.co.uk> In-Reply-To: <0edf01cd7c43$94feec00$befcc400$@olddog.co.uk> 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 Cc: "mpls@ietf.org" , "draft-ietf-mpls-entropy-label@tools.ietf.org" Subject: Re: [mpls] AD review of draft-ietf-mpls-entropy-label 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, 17 Aug 2012 18:04:08 -0000 On Aug 16, 2012, at 23:43 , Adrian Farrel wrote: > So... > OLD > X SHOULD put the same TTL and TC fields for the ELI as > it does for TL. > NEW > X SHOULD put the same TTL and TC fields for the ELI as > it does for TL to protect LSP behavior in cases where PHP is used > and the ELI and EL are not stripped at the previous hop (see Section > 4.4). If it is known that PHP is not used or that PHP will strip the EL= I > and EL, the TTL and TC of the ELI MAY be set differently. > END X will likely be blissfully unaware of whether PHP will be used (and whethe= r the PHP LSR will pop ELI+EL), unless this is a very short LSP. > ***or*** >=20 > s/SHOULD/MUST/ I have a pathological fear of MUST. How about: NEW X SHOULD put the same TTL and TC fields for the ELI as it does for TL. This protects LSP behavior in cases where PHP is used and the ELI and EL are not stripped at the penultimate hop (see Section 4.4). END I'd better get out a new version before the list of things to do gets any l= onger. Kireeti.= From internet-drafts@ietf.org Fri Aug 17 12:19: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 BDB6A21F84F0; Fri, 17 Aug 2012 12:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 o3FrbQTYXUxa; Fri, 17 Aug 2012 12:19:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E6B21F8468; Fri, 17 Aug 2012 12:19:09 -0700 (PDT) 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.33 Message-ID: <20120817191909.22120.13634.idtracker@ietfa.amsl.com> Date: Fri, 17 Aug 2012 12:19:09 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-entropy-label-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: Fri, 17 Aug 2012 19:19: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 : The Use of Entropy Labels in MPLS Forwarding Author(s) : Kireeti Kompella John Drake Shane Amante Wim Henderickx Lucy Yong Filename : draft-ietf-mpls-entropy-label-05.txt Pages : 23 Date : 2012-08-17 Abstract: Load balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing across MPLS networks using the concept of "entropy labels". It defines the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications. This document updates RFCs 3031, 3107, 3209 and 5036. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-entropy-label There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-entropy-label-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-entropy-label-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From venkat.mahalingams@gmail.com Fri Aug 17 13:51: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 C4F8C11E80DC; Fri, 17 Aug 2012 13:51:22 -0700 (PDT) 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 vBNdTYBV-1ib; Fri, 17 Aug 2012 13:51:21 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7095F11E80E1; Fri, 17 Aug 2012 13:51:20 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4299956vbb.31 for ; Fri, 17 Aug 2012 13:51:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Fim84srpMfh5Kx7lguCGngBGwNLy92i/Ly2ngS2eR2I=; b=PMNdBEspG8K+muvHJLIN2HmxmOv6U0G3as2IfKsF+x5uDud7G4Lfk1MpKnQkOWOOTW kxGDolWHHTdyaKxoUr88zVke+Frry/XDIPGAZ4CSL+QONiKwhgvliKfgX6Y2oRCkCO0q qm5WNAu8puSx+Kmqzw8tgWDNkvQAxUwIwqC7/AO/cfHoCOYtJDf3+4S12qMRz9KnL3lo DReLgHnwXP31PIWUmyEc6ZMTp/zo+ZIngiIjkIhXUJJvWVEq1/TUOiGfUb+p1vw2o1s/ x2nu8jzjRh2t3bo4YOk3I+F49TEwfm9P6suL+66h/yLFhacMROnTZ0cZAJnbWOYGXCc8 ag1w== MIME-Version: 1.0 Received: by 10.52.98.101 with SMTP id eh5mr3032154vdb.8.1345236679820; Fri, 17 Aug 2012 13:51:19 -0700 (PDT) Received: by 10.220.166.210 with HTTP; Fri, 17 Aug 2012 13:51:19 -0700 (PDT) In-Reply-To: <02c601cd7cb8$06037910$6801a8c0@JoanPC> References: <056101cd6354$c9deb1b0$6801a8c0@JoanPC> <5257BD19-4A53-4767-9BAB-6C2AB2032846@lucidvision.com> <026f01cd7c9c$b7224030$6801a8c0@JoanPC> <02c601cd7cb8$06037910$6801a8c0@JoanPC> Date: Fri, 17 Aug 2012 13:51:19 -0700 Message-ID: From: Venkatesan Mahalingam To: Joan Cucchiara , mpls@ietf.org, "MIB Doctors (E-mail)" , mpls-chairs@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Sam Aldrin Subject: Re: [mpls] draft-ietf-mpls-tp-te-mib-04.txt review request 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, 17 Aug 2012 20:51:23 -0000 ++ MPLS WG & MIB Drs. Thanks, Venkat. On Fri, Aug 17, 2012 at 1:36 PM, Joan Cucchiara wrote: > Venkat, > > The SMIv2 specifies that once a TC is defined, then the definition cannot > change in the way being > proposed by the draft-ietf-mpls-tp-te-mib-04. > > From RFC2579: > 3.3. Mapping of the DESCRIPTION clause > The DESCRIPTION clause, which must be present, contains a textual > definition of the textual convention, which provides all semantic > definitions necessary for implementation, and should embody any > information which would otherwise be communicated in any ASN.1 > commentary annotations associated with the object. > > > My concern is that MPLS-TC-STD-MIB defines MplsExtendedTunnelId and this > draft is changing that original definition. > If RFC3811 does not contain "all semantic definitions necessary for > implementation" then the problem is to update RFC3811 > and maybe other associated RFCs as needed, not to propose additional > semantics in draft-ietf-mpls-tp-te-mib. > > The draft is proposing to bifurcate the values and also not use zero for the > MplsExtendedTunnelId, that is not the original > definition of MplsExtendedTunnelId, so why is this draft using > MplsExtendedTunnelId? > > Please include the MIB Dr's on your email because this is a MIB concern and > one which I've had since > before this draft was adopted as a WG document. > > The options are (as I see them): > 1) create a specific MPLS TP table for TP Tunnels (which was originally > proposed by Adrian Farrel) > 2) update RFC3811 to accurately reflect MplsExtendedTunnelId and other RFCs > which utilize this TC. > 3) ?? > > Thanks, > -Joan > > > ----- Original Message ----- From: "Venkatesan Mahalingam" > > To: "Joan Cucchiara" > Cc: "Thomas Nadeau" ; "Sam Aldrin" > ; "Kannan KV Sampath" > Sent: Friday, August 17, 2012 2:39 PM > > Subject: Re: draft-ietf-mpls-tp-te-mib-04.txt review request > > >> Joan, >> >> Thanks for your response. Appreciate your time for reviewing this >> draft. Please find below my response tagged [VM]. >> >> However, I looked over the doc and wanted to let you know that I still >> have >>> >>> the same issue wrt to both SYNTAX and semantic >>> redefinition as before. You cannot narrow the range of values in a >>> DESCRIPTION clause which I see happens in mplsTunnelExtNodeConfigLocalId >>> and maybe in MplsNodeId TC as it says zero must not be used, but then >>> you >>> have it as part of allowable values in the SYNTAX. >> >> [VM] If MplsExtendedTunnelId allows zero as the valid value, I don't >> see any issue to allow zero as the valid value for MplsNodeId. >> >>> Additionally, the SYNTAX below for MplsExtendedTunnelId allows any >>> Unsigned32 and says "may represent an IPv4 address". If (for whatever >>> reason) an >>> operator has configured something in the 1..16777216 (i.e. Local Id) >>> range, >>> for a regular TE Tunnel, that is perfectly legal, right? >> >> [VM] I don't see any implementation which allows non-IP TE tunnel >> source/destination in the range 1..16777216 in MPLS domain, >> if you are not still convinced, we can poll in MPLS WG list to get the >> operators' opinion on this. >> >>> If the answer is Yes, then how would you add TP Tunnels using your draft >>> if >>> an operator has a regular MPLS TE Tunnel configured >>> in the range 1..16777216 without having to ensure that any and all legacy >>> equipment be queried first? >> >> [VM] It is expected to configure MPLS TE tunnels in IP address range >> and MPLS-TP tunnel in NON-IP range, if the implementors have mixed >> mode of configuration, then it is expected to clarify in the document >> that how to use MPLS-TE & MPLS-TP tunnel configurations. >> What you are saying is correct only if the legacy equipments use the >> NON-IP range for MPLS TE tunnels, so, as I stated above, let's close >> this with the MPLS WG list. >> >> HTH >> >> Thanks, >> Venkat. >> >> On Fri, Aug 17, 2012 at 10:21 AM, Joan Cucchiara >> wrote: >>> >>> Tom and all, >>> >>> Unfortunately, my linux box is giving me grief this week (and I don't >>> have >>> access to my MIB tools). I'm getting some assistance >>> with it but won't be resolved until (hopefully) during the weekend. >>> >>> However, I looked over the doc and wanted to let you know that I still >>> have >>> the same issue wrt to both SYNTAX and semantic >>> redefinition as before. You cannot narrow the range of values in a >>> DESCRIPTION clause which I see happens in mplsTunnelExtNodeConfigLocalId >>> and maybe in MplsNodeId TC as it says zero must not be used, but then >>> you >>> have it as part of allowable values in the SYNTAX. >>> >>> Whatever is specified in the DESCRIPTION clause for values, should be >>> reflected by the SYNTAX, right? >>> >>> Additionally, the SYNTAX below for MplsExtendedTunnelId allows any >>> Unsigned32 and says "may represent an IPv4 address". If (for whatever >>> reason) an >>> operator has configured something in the 1..16777216 (i.e. Local Id) >>> range, >>> for a regular TE Tunnel, that is perfectly legal, right? >>> >>> >>> MplsExtendedTunnelId ::= TEXTUAL-CONVENTION >>> STATUS current >>> DESCRIPTION >>> "A unique identifier for an MPLS Tunnel. This may >>> represent an IPv4 address of the ingress or egress >>> LSR for the tunnel. This value is derived from the >>> Extended Tunnel Id in RSVP or the Ingress Router ID >>> for CR-LDP." >>> REFERENCE >>> "RSVP-TE: Extensions to RSVP for LSP Tunnels, >>> [RFC3209]. >>> >>> Constraint-Based LSP Setup using LDP, [RFC3212]." >>> SYNTAX Unsigned32(0..4294967295) >>> >>> If the answer is Yes, then how would you add TP Tunnels using your draft >>> if >>> an operator has a regular MPLS TE Tunnel configured >>> in the range 1..16777216 without having to ensure that any and all legacy >>> equipment be queried first? >>> >>> Thanks, >>> -Joan >>> >>> >>> >>> ----- Original Message ----- >>> From: Thomas Nadeau >>> To: Joan Cucchiara >>> Cc: Sam Aldrin ; Venkatesan Mahalingam ; Kannan KV Sampath >>> Sent: Thursday, August 09, 2012 8:58 AM >>> Subject: Re: draft-ietf-mpls-tp-te-mib-04.txt review request >>> >>> hi Joan >>> >>> hope you had a great vacation! ;) >>> >>> can you please follow up on the note below when you have a chance? >>> >>> Tom >>> >>> >>> >>> On Jul 16, 2012, at 9:13 AM, "Joan Cucchiara" >>> wrote: >>> >>> Sam, >>> >>> We are away this week returning on 7/23. Sorry, I can't review the doc >>> until after 7/23 and it will >>> take a few days after that as I'll just be returning from vacation. >>> >>> I glanced at it and see that there are read-write objects in a row (which >>> is >>> read-create) so that's >>> an error which I mentioned before. >>> >>> Have you compiled this with smilint? >>> >>> Thanks, >>> -Joan >>> >>> >>> >>> >>> >>> ----- Original Message ----- >>> From: Sam Aldrin >>> To: Joan Cucchiara >>> Cc: Venkatesan Mahalingam ; Thomas Nadeau ; Kannan KV Sampath >>> Sent: Friday, July 13, 2012 9:11 PM >>> Subject: Fwd: draft-ietf-mpls-tp-te-mib-04.txt review request >>> >>> Hi Joan, >>> >>> Please find the updated MIB document. Apologize for the delay. We plan to >>> publish the doc on Monday as it is the deadline before IETF. Diff file is >>> attached as well. >>> >>> This version addresses all your comments. Highlighting couple of them to >>> make sure you are OK with them >>> >>> 1. W.r.t mplsLocalID as index type, we have removed that using >>> MplsExtendedTunnelId itself. As the value range for this object could >>> have >>> value of non-IP address, we are using it. This will make the indices for >>> the >>> same as TunnelTable. >>> In the definition of IngressLSRId and and EgressLSRId, for TP entries, we >>> added description to use value of non-IP address, which is local ID. >>> >>> I do hope this satisfies the need and not necessitate for a new table >>> altogether for TP. >>> >>> 2. In regards to adding references to TC conventions. We believe, those >>> were >>> added in the reference section. IF we have missed any TC references, >>> could >>> you kindly let us know. >>> >>> Appreciate if you can get back by Monday noon time PST. I know it is a >>> very >>> short time, but appreciate if you could do that. >>> >>> thanks >>> -sam >>> >>> ________________________________ >>> >>> > From aldrin.ietf@gmail.com Fri Aug 17 14:06: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 91A5B11E80E3; Fri, 17 Aug 2012 14:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.306 X-Spam-Level: X-Spam-Status: No, score=-3.306 tagged_above=-999 required=5 tests=[AWL=0.293, 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 o5gPBX8LCZGG; Fri, 17 Aug 2012 14:06:48 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7472111E80D1; Fri, 17 Aug 2012 14:06:48 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so3994824pbb.31 for ; Fri, 17 Aug 2012 14:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=cxZ9cgM7g0ZhYBr8pYQERfhhTPSOfxiEJ9e1gjIxyIo=; b=yyjvlE+tEzc1PRT5lp7O7Orxbu2wtlW7Gq5zZEQWrvl40Ic/GMZRkfZzfVw/R4QAXi 9++30xMFoB1ajsqNiGtT8IVIidHfmHEwNz/dEldNc4o9L+fqSs4Vorpvdk8xfky38k/w vavW0BFehLPzKR/OartYqMyWvQuLFbJj0iTJ71Ssvygv2BLjnUUICGS+SA16Llj/o3mj HiXvtdDMY86RXpIl+7m/4XRdIcwPBKhikMrAfBLbxyMWK3R8byRLIAEQehWNTs2WXuqq lSrrwV+jHg0GyYH2+lfBrpfcNWG2gzlim8mb+shLsOHICqL7K+Ml0Q30I6MQmeNYyVMs dw4Q== Received: by 10.68.116.48 with SMTP id jt16mr14481600pbb.101.1345237607405; Fri, 17 Aug 2012 14:06:47 -0700 (PDT) Received: from [192.168.1.9] (c-107-3-156-34.hsd1.ca.comcast.net. [107.3.156.34]) by mx.google.com with ESMTPS id nk3sm5607351pbc.27.2012.08.17.14.06.44 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Aug 2012 14:06:46 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Sam Aldrin In-Reply-To: Date: Fri, 17 Aug 2012 14:06:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2E7490DB-3DE7-42C8-8E43-7378A76C2B4C@gmail.com> References: <056101cd6354$c9deb1b0$6801a8c0@JoanPC> <5257BD19-4A53-4767-9BAB-6C2AB2032846@lucidvision.com> <026f01cd7c9c$b7224030$6801a8c0@JoanPC> <02c601cd7cb8$06037910$6801a8c0@JoanPC> To: Venkatesan Mahalingam X-Mailer: Apple Mail (2.1485) Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, Sam Aldrin , "MIB Doctors \(E-mail\)" Subject: Re: [mpls] draft-ietf-mpls-tp-te-mib-04.txt review request 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, 17 Aug 2012 21:06:49 -0000 Hi Joan, The issue boils down to the range value specified in the DESCRIPTION. If that is removed, does that resolve the concern you raised? Do not think we are restricting not to use '0' in anyway or redefining = the semantics. As the value is local and the intention is to help implementor of the = MIB to choose right value, without conflicting with TE tunnel index, we = added that range. If implementor chooses to use different value = altogether, it is perfectly OK as long as it is in the range of = mplsExtendedTunnelId definition. W.r.t legacy implementation, it is unto the implementor to assign the = right index value to TP tunnel, if it conflicts with TE tunnel index. The example provided could give guidance on what value to use, but will = not MANDATE the usage. In regards to implementing a new table, we have deliberated extensively = among authors and also with implementors. Adding new MIB or table is not = really efficient. Infact, there are already implementations which were = able to support the legacy model as well as new TP tunnels. Unless there = is a compelling reason that MPLS TP tunnel table should have its own = table, which essentially duplicated all of the objects, I am not for = that model. If others in WG feels the need, they can speak up. -sam On Aug 17, 2012, at 1:51 PM, Venkatesan Mahalingam = wrote: > ++ MPLS WG & MIB Drs. >=20 > Thanks, > Venkat. >=20 > On Fri, Aug 17, 2012 at 1:36 PM, Joan Cucchiara > wrote: >> Venkat, >>=20 >> The SMIv2 specifies that once a TC is defined, then the definition = cannot >> change in the way being >> proposed by the draft-ietf-mpls-tp-te-mib-04. >>=20 >> =46rom RFC2579: >> 3.3. Mapping of the DESCRIPTION clause >> The DESCRIPTION clause, which must be present, contains a textual >> definition of the textual convention, which provides all semantic >> definitions necessary for implementation, and should embody any >> information which would otherwise be communicated in any ASN.1 >> commentary annotations associated with the object. >>=20 >>=20 >> My concern is that MPLS-TC-STD-MIB defines MplsExtendedTunnelId and = this >> draft is changing that original definition. >> If RFC3811 does not contain "all semantic definitions necessary for >> implementation" then the problem is to update RFC3811 >> and maybe other associated RFCs as needed, not to propose additional >> semantics in draft-ietf-mpls-tp-te-mib. >>=20 >> The draft is proposing to bifurcate the values and also not use zero = for the >> MplsExtendedTunnelId, that is not the original >> definition of MplsExtendedTunnelId, so why is this draft using >> MplsExtendedTunnelId? >>=20 >> Please include the MIB Dr's on your email because this is a MIB = concern and >> one which I've had since >> before this draft was adopted as a WG document. >>=20 >> The options are (as I see them): >> 1) create a specific MPLS TP table for TP Tunnels (which was = originally >> proposed by Adrian Farrel) >> 2) update RFC3811 to accurately reflect MplsExtendedTunnelId and = other RFCs >> which utilize this TC. >> 3) ?? >>=20 >> Thanks, >> -Joan >>=20 >>=20 >> ----- Original Message ----- From: "Venkatesan Mahalingam" >> >> To: "Joan Cucchiara" >> Cc: "Thomas Nadeau" ; "Sam Aldrin" >> ; "Kannan KV Sampath" = >> Sent: Friday, August 17, 2012 2:39 PM >>=20 >> Subject: Re: draft-ietf-mpls-tp-te-mib-04.txt review request >>=20 >>=20 >>> Joan, >>>=20 >>> Thanks for your response. Appreciate your time for reviewing this >>> draft. Please find below my response tagged [VM]. >>>=20 >>> However, I looked over the doc and wanted to let you know that I = still >>> have >>>>=20 >>>> the same issue wrt to both SYNTAX and semantic >>>> redefinition as before. You cannot narrow the range of values in = a >>>> DESCRIPTION clause which I see happens in = mplsTunnelExtNodeConfigLocalId >>>> and maybe in MplsNodeId TC as it says zero must not be used, but = then >>>> you >>>> have it as part of allowable values in the SYNTAX. >>>=20 >>> [VM] If MplsExtendedTunnelId allows zero as the valid value, I don't >>> see any issue to allow zero as the valid value for MplsNodeId. >>>=20 >>>> Additionally, the SYNTAX below for MplsExtendedTunnelId allows any >>>> Unsigned32 and says "may represent an IPv4 address". If (for = whatever >>>> reason) an >>>> operator has configured something in the 1..16777216 (i.e. Local = Id) >>>> range, >>>> for a regular TE Tunnel, that is perfectly legal, right? >>>=20 >>> [VM] I don't see any implementation which allows non-IP TE tunnel >>> source/destination in the range 1..16777216 in MPLS domain, >>> if you are not still convinced, we can poll in MPLS WG list to get = the >>> operators' opinion on this. >>>=20 >>>> If the answer is Yes, then how would you add TP Tunnels using your = draft >>>> if >>>> an operator has a regular MPLS TE Tunnel configured >>>> in the range 1..16777216 without having to ensure that any and all = legacy >>>> equipment be queried first? >>>=20 >>> [VM] It is expected to configure MPLS TE tunnels in IP address range >>> and MPLS-TP tunnel in NON-IP range, if the implementors have mixed >>> mode of configuration, then it is expected to clarify in the = document >>> that how to use MPLS-TE & MPLS-TP tunnel configurations. >>> What you are saying is correct only if the legacy equipments use the >>> NON-IP range for MPLS TE tunnels, so, as I stated above, let's close >>> this with the MPLS WG list. >>>=20 >>> HTH >>>=20 >>> Thanks, >>> Venkat. >>>=20 >>> On Fri, Aug 17, 2012 at 10:21 AM, Joan Cucchiara >>> wrote: >>>>=20 >>>> Tom and all, >>>>=20 >>>> Unfortunately, my linux box is giving me grief this week (and I = don't >>>> have >>>> access to my MIB tools). I'm getting some assistance >>>> with it but won't be resolved until (hopefully) during the weekend. >>>>=20 >>>> However, I looked over the doc and wanted to let you know that I = still >>>> have >>>> the same issue wrt to both SYNTAX and semantic >>>> redefinition as before. You cannot narrow the range of values in = a >>>> DESCRIPTION clause which I see happens in = mplsTunnelExtNodeConfigLocalId >>>> and maybe in MplsNodeId TC as it says zero must not be used, but = then >>>> you >>>> have it as part of allowable values in the SYNTAX. >>>>=20 >>>> Whatever is specified in the DESCRIPTION clause for values, should = be >>>> reflected by the SYNTAX, right? >>>>=20 >>>> Additionally, the SYNTAX below for MplsExtendedTunnelId allows any >>>> Unsigned32 and says "may represent an IPv4 address". If (for = whatever >>>> reason) an >>>> operator has configured something in the 1..16777216 (i.e. Local = Id) >>>> range, >>>> for a regular TE Tunnel, that is perfectly legal, right? >>>>=20 >>>>=20 >>>> MplsExtendedTunnelId ::=3D TEXTUAL-CONVENTION >>>> STATUS current >>>> DESCRIPTION >>>> "A unique identifier for an MPLS Tunnel. This may >>>> represent an IPv4 address of the ingress or egress >>>> LSR for the tunnel. This value is derived from the >>>> Extended Tunnel Id in RSVP or the Ingress Router ID >>>> for CR-LDP." >>>> REFERENCE >>>> "RSVP-TE: Extensions to RSVP for LSP Tunnels, >>>> [RFC3209]. >>>>=20 >>>> Constraint-Based LSP Setup using LDP, [RFC3212]." >>>> SYNTAX Unsigned32(0..4294967295) >>>>=20 >>>> If the answer is Yes, then how would you add TP Tunnels using your = draft >>>> if >>>> an operator has a regular MPLS TE Tunnel configured >>>> in the range 1..16777216 without having to ensure that any and all = legacy >>>> equipment be queried first? >>>>=20 >>>> Thanks, >>>> -Joan >>>>=20 >>>>=20 >>>>=20 >>>> ----- Original Message ----- >>>> From: Thomas Nadeau >>>> To: Joan Cucchiara >>>> Cc: Sam Aldrin ; Venkatesan Mahalingam ; Kannan KV Sampath >>>> Sent: Thursday, August 09, 2012 8:58 AM >>>> Subject: Re: draft-ietf-mpls-tp-te-mib-04.txt review request >>>>=20 >>>> hi Joan >>>>=20 >>>> hope you had a great vacation! ;) >>>>=20 >>>> can you please follow up on the note below when you have a chance? >>>>=20 >>>> Tom >>>>=20 >>>>=20 >>>>=20 >>>> On Jul 16, 2012, at 9:13 AM, "Joan Cucchiara" = >>>> wrote: >>>>=20 >>>> Sam, >>>>=20 >>>> We are away this week returning on 7/23. Sorry, I can't review = the doc >>>> until after 7/23 and it will >>>> take a few days after that as I'll just be returning from vacation. >>>>=20 >>>> I glanced at it and see that there are read-write objects in a row = (which >>>> is >>>> read-create) so that's >>>> an error which I mentioned before. >>>>=20 >>>> Have you compiled this with smilint? >>>>=20 >>>> Thanks, >>>> -Joan >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> ----- Original Message ----- >>>> From: Sam Aldrin >>>> To: Joan Cucchiara >>>> Cc: Venkatesan Mahalingam ; Thomas Nadeau ; Kannan KV Sampath >>>> Sent: Friday, July 13, 2012 9:11 PM >>>> Subject: Fwd: draft-ietf-mpls-tp-te-mib-04.txt review request >>>>=20 >>>> Hi Joan, >>>>=20 >>>> Please find the updated MIB document. Apologize for the delay. We = plan to >>>> publish the doc on Monday as it is the deadline before IETF. Diff = file is >>>> attached as well. >>>>=20 >>>> This version addresses all your comments. Highlighting couple of = them to >>>> make sure you are OK with them >>>>=20 >>>> 1. W.r.t mplsLocalID as index type, we have removed that using >>>> MplsExtendedTunnelId itself. As the value range for this object = could >>>> have >>>> value of non-IP address, we are using it. This will make the = indices for >>>> the >>>> same as TunnelTable. >>>> In the definition of IngressLSRId and and EgressLSRId, for TP = entries, we >>>> added description to use value of non-IP address, which is local = ID. >>>>=20 >>>> I do hope this satisfies the need and not necessitate for a new = table >>>> altogether for TP. >>>>=20 >>>> 2. In regards to adding references to TC conventions. We believe, = those >>>> were >>>> added in the reference section. IF we have missed any TC = references, >>>> could >>>> you kindly let us know. >>>>=20 >>>> Appreciate if you can get back by Monday noon time PST. I know it = is a >>>> very >>>> short time, but appreciate if you could do that. >>>>=20 >>>> thanks >>>> -sam >>>>=20 >>>> ________________________________ >>>>=20 >>>>=20 >>=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From gregory.mirsky@ericsson.com Fri Aug 17 16:42:19 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 0F53811E8097; Fri, 17 Aug 2012 16:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.132, 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 nFhZ9VWTbQye; Fri, 17 Aug 2012 16:42:13 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9C85B21F847A; Fri, 17 Aug 2012 16:42:12 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q7HNg9bO024938 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Aug 2012 18:42:10 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 17 Aug 2012 19:42:09 -0400 From: Gregory Mirsky To: John E Drake , Greg Mirsky , Francesco Fondelli Date: Fri, 17 Aug 2012 19:42:04 -0400 Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: Ac18rlwA4D2YlfZKRGCBpFI+2JZEwgABuVOAAAA1SUAAAN63wAAAvlnAAAAigwAAAIUx8AAAYKSAAAMO/NA= Message-ID: References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> <502D5125.6000105@labn.net> <502D61B8.5050106@labn.net> <5E893DB832F57341992548CDBB333163A631A84710@EMBX01-HQ.jnpr.net> <502D6F4D.7020707@labn.net> <5E893DB832F57341992548CDBB333163A631A84E31@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A631A84E97@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A631A84EF3@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A631A84F48@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A631A84F48@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF139268CC08EEUSAACMS0715e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "ccamp@ietf.org" Subject: Re: [mpls] [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-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: Fri, 17 Aug 2012 23:42:19 -0000 --_000_FE60A4E52763E84B935532D7D9294FF139268CC08EEUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi John, "The only difference is whether if one direction fails, the other direction= is forced to fail." Yes. And whether associated bidirectional LSP requires protection as single= bidirectional p2p construct or protection applies to each direction indepe= ndently. But what happens to association in that case? Should protecting un= idirectional LSPs be associated with working and protecting unidirectional = LSPs of reverse direction before switchover? Consider working L1 A-Z and L2= Z-A are protected by L3 A-Z and L4 Z-A accordingly. L1 and L2 form associa= ted bidirectional p2p LSP. What about L3 and L2, L1 and L4, L3 and L4 - are= these the same associated bi-directional LSP or not? Regards, Greg PS. Even though most of MPLS WG is likely subscribed to CCAMP list, I'll ad= d MPLS WG to have opinions and comments from it. ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Friday, August 17, 2012 2:49 PM To: Gregory Mirsky; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, It's not clear what 'monitored independently' means and whether it edicts c= oordinated or independent mode. It really can't, because as I indicated previously, in both modes there is = a bidirectional flow of control packets and in both modes there is a stream= of CC/CV packets in each direction. The only difference is whether if one= direction fails, the other direction is forced to fail. I always thought independent mode was suspect and that requirement for it w= as derived from the way Y.1731 worked, but I think it is equally suspect fo= r both associated and co-routed. Thanks, John Sent from my iPhone From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, August 17, 2012 2:34 PM To: John E Drake; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt John, as Dave Allan pointed, RFC 6428 does not mandate how coordinated and indepe= ndent modes should be used. But the very first sentence of Section 3.1 of t= he document we're discussing says "The associated bidirectional LSP's forward and backward directions are set= up, monitored, and protected independently as required by [RFC5654]." And in RFC 5654, section 1.2.2 I indeed f= ind "Associated bidirectional path: A path that supports traffic flow in both d= irections but that is constructed from a pair of unidirectional paths (one = for each direction) that are associated with one another at the path's ingr= ess/egress points. The forward and backward directions are setup, monitore= d, and protected independently. As a consequence, they may or may not foll= ow the same route (links and nodes) across the network." I think there's no need for RFC 6428bis. Do you think there's need to revis= e RFC 5654? Regards, Greg ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Friday, August 17, 2012 2:20 PM To: Gregory Mirsky; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, For both modes there is bidirectional flow of control packets. For Indepen= dent mode the CC/CV packets flow in only one direction. There never was a coupling between modes and associated/co-routed and if yo= u can point me to any text that says the contrary I would appreciate it as = a bis to remove that text would be required. Thanks, John Sent from my iPhone From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, August 17, 2012 2:12 PM To: John E Drake; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi John, in independent mode CC/CV control messages been sent only in one direction.= Thus there are two CC/CV sessions - one for each independently monitored d= irection. That, AFAIK, was intentional. Regards, Greg ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Friday, August 17, 2012 1:50 PM To: Gregory Mirsky; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, That certainly wasn't the intent. With a bidirectional LSP of either type = you have one forward and one return path and BFD does not care whether they= are congruent. Thanks, John Sent from my iPhone From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, August 17, 2012 1:28 PM To: John E Drake; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi John, I think that bi-directional associated p2p LSP, regardless of how many comm= on LSRs forward and reverse directions have, implies use of independent mod= e of RFC 6428, then there will be two sessions to monitor each direction in= dependently. Coordinated mode of RFC 6428, in my understanding, applies to = bidirectional co-routed p2p LSP. Regards, Greg ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of John E Drake Sent: Friday, August 17, 2012 1:19 PM To: Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, According to RFC 6428 the is one CC/CV/RDI session irregardless of whether = the bi-directional packet LSP is co-routed or associated. Thanks, John Sent from my iPhone From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Greg Mirsky Sent: Friday, August 17, 2012 12:27 PM To: Francesco Fondelli Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi Francesco, "from a data-plane view point b) and c2) are the same thing" I think that given that c) is associated bi-directional LSP that implies in= dependent OAM and protection for each direction, b) and c2) are not the sam= e in the data plane view. E.g., there will be single CC/CV/RDI session for = b) while c2) will have two sessions. And if linear protection requested, b)= will be protected by single bi-directional LSP, but c2) - by two unidirect= ional LSPs. Regards, Greg On Fri, Aug 17, 2012 at 1:48 AM, Francesco Fondelli > wrote: Hi All, I think I'm lost, please help. Rakesh is talking about "co-routed associated bidirectional LSP"... for the sake of clarity, let me try to categorize LSPs from a control plane view point: a) Point-to-point unidirectional b) Point-to-point co-routed bidirectional c) Point-to-point associated bidirectional c1) fwd and rev LSP follow different paths c2) fwd and rev LSP follow same path d) Point-to-multipoint unidirectional e) Multipoint-to-point unidirectional Is section 3.2.5 (Signaling of Co-routed LSPs) of mpls-tp-rsvpte-ext-associated-lsp about b) or it is about c2)? In my opinion: - b) should be signaled with 3473 - c) are addressed by this I-D (mpls-tp-rsvpte-ext-associated-lsp) Am I missing something? thank you ciao fra PS from a data-plane view point b) and c2) are the same thing. On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi (rgandhi) > wrote: > Hi Lou, > > Thanks for initiating discussions on the changes in the draft. > > Agree with you here, if we/WG do not agree on the "co-routed associated b= idirectional LSP" part, we are ok to remove it from this draft and can alwa= ys submit a new draft just for that. We respect your/WG decision. > > Thanks, > Rakesh > > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, August 16, 2012 6:08 PM > To: John E Drake > Cc: Rakesh Gandhi (rgandhi); ccamp@ietf.org > Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-asso= ciated-lsp-04.txt > > John, > While strictly speaking WG drafts should only reflect current WG = consensus, and it is the WG draft editor's job to ensure this, in practice = authors/editors are given a lot of latitude in timing / ordering in introdu= ction to changes. I personally think this is a practical way of keeping th= e process moving. Also if the WG disagrees with a change, it can always be= backed out. > > So, yes, the WG could do exactly as you say if it comes to it. (The chai= rs can even appoint different editor if needed, e.g., to make this > happen.) While I'm not happy with how this revision came about, as I cov= ered in earlier mail, my feeling is to let the discussion take place on the= list (and at the next IETF, if needed) and then have the draft updated to = reflect the WG discussion/consensus. > > Lou > > On 8/16/2012 5:35 PM, John E Drake wrote: >> Lou, >> >> Since the WG did not agree to this changes, let alone discuss them, >> would it be possible to simply rollback these changes and ask the >> authors to write a draft addressing the topics you list in your email, >> below? >> >> Thanks, >> >> John >> >> Sent from my iPhone >> >> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:cca= mp-bounces@ietf.org] On >>> Behalf Of Lou Berger >>> Sent: Thursday, August 16, 2012 2:10 PM >>> To: Rakesh Gandhi (rgandhi) >>> Cc: ccamp@ietf.org >>> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>> associated-lsp-04.txt >>> >>> Rakesh, >>> Such major changes (in scope and functionality) to WG drafts are >>> usually discussed with the WG prior to the authors/editors just >>> publishing the changes. But, this is a judgment call by the document >>> editors in how, quoting rfc2418, they "ensur[e] that the contents of >>> the document accurately reflect the decisions that have been made by >>> the working group." >>> >>> So let's jump into discussing the changes. >>> >>> As I see it this draft introduces several major functional changes >>> that have not been discussed by the WG. Correct me if I get them >>> wrong, but I believe they include: >>> 1) Introduction of a second method for signaling Co-routed LSPs >>> 2) Support for FRR bypass tunnels for piggybacked on the TP >>> bidirectional LSP mechanisms. >>> >>> There are also other changes, but I'll defer discussing them >>> until the discussion on the above is concluded. >>> >>> Is this correct? >>> >>> Assuming yes, I have questions about both rational and specific >>> mechanisms. For now let's look at the former, so please: >>> >>> A) Articulate the issues/limitations with using the RFC3473 defined >>> mechanisms for (co-routed) bidirectional LSPs that you'd like to see >>> addressed. >>> >>> B.1) Articulate the FRR/GMPLS-related issue you'd like to address? >>> >>> B.2) Articulate why this issue should be solved in a TP-specific and >>> not GMPLS generic fashion? >>> >>> Thanks, >>> Lou >>> >>> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote: >>>> Hi Lou, >>>> >>>> Yes. >>>> >>>> Please advise if you think detailed email is required. >>>> We believe latest draft summarizes the changes well and we could >>> start review/discussions from there. >>>> >>>> Thanks, >>>> Rakesh >>>> >>>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Thursday, August 16, 2012 4:00 PM >>>> To: Rakesh Gandhi (rgandhi) >>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn >>>> Subject: Re: [CCAMP] I-D Action: >>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>> >>>> Rakesh, >>>> Is this the start of the thread that I requested in >>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html >>>> >>>> In particular, is it the response to: >>>>> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the >>>>> proposed change and the rational for each change (in one or in >>>>> separate e-mails). The WG discussion can then really begin on the >>>>> proposed changes. (Which are quite substantial both in scope and >>>>> implication.) >>>> >>>> Lou >>>> >>>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: >>>>> Hi All, >>>>> >>>>> We have uploaded a new version of this draft with following changes: >>>> >>>> 1. Added a section on Signaling of Co-routed LSPs >>>> >>>> 2. Added clarification on Signaling of Associated Bidirectional >>>> Protection LSPs >>>> >>>> 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs >>>> >>>> 4. Added clarification on Signaling of Inter-domain Associated >>> Bidirectional LSPs >>>> >>>> 5. The Extended ASSOCIATION object format with Association Type >>> "Associated Bidirectional LSP". Clarified on how to populate >>> different fields in this object. >>>> >>>> >>>>> We believe that some of these changes were necessary to avoid the >>> interoperability issues due to potentially different interpretations. >>>>> >>>>> Your review comments are welcome. >>>>> >>>>> Thanks, >>>>> Rakesh >>>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:c= camp-bounces@ietf.org] On >>>>> Behalf Of internet-drafts@ietf.org >>>>> Sent: Wednesday, August 15, 2012 10:53 AM >>>>> To: i-d-announce@ietf.org >>>>> Cc: ccamp@ietf.org >>>>> Subject: [CCAMP] I-D Action: >>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>>>> This draft is a work item of the Common Control and Measurement >>> Plane Working Group of the IETF. >>>>> >>>>> Title : RSVP-TE Extensions for Associated Bidirectional >>> LSPs >>>>> Author(s) : Fei Zhang >>>>> Ruiquan Jing >>>>> Rakesh Gandhi >>>>> Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated- >>> lsp-04.txt >>>>> Pages : 17 >>>>> Date : 2012-08-15 >>>>> >>>>> Abstract: >>>>> The MPLS Transport Profile (MPLS-TP) requirements document >>> [RFC5654], >>>>> describes that MPLS-TP MUST support associated bidirectional >>> point- >>>>> to-point LSPs. >>>>> >>>>> This document provides a method to bind two unidirectional Label >>>>> Switched Paths (LSPs) into an associated bidirectional LSP. The >>>>> association is achieved by defining the new Association Type in >>> the >>>>> Extended ASSOCIATION object. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte- >>> ext- >>>>> a >>>>> ssociated-lsp >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>> associ >>>>> a >>>>> ted-lsp-04 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte- >>> ext- >>>>> a >>>>> ssociated-lsp-04 >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_FE60A4E52763E84B935532D7D9294FF139268CC08EEUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi John,
"The only difference is whether if one direction f= ails, the=20 other direction is forced to fail."
Yes. And whether associated bidirectional LSP requ= ires=20 protection as single bidirectional p2p construct or protection applies to e= ach=20 direction independently. But what happens to association in that case? Shou= ld=20 protecting unidirectional LSPs be associated with working and protecting=20 unidirectional LSPs of reverse direction before switchover? Consider=20 working L1 A-Z and L2 Z-A are protected by L3 A-Z and L4 Z-A according= ly.=20 L1 and L2 form associated bidirectional p2p LSP. What about L3 and L2, L1 a= nd=20 L4, L3 and L4 - are these the same associated bi-directional LSP or=20 not?
 
  &n= bsp; Regards,
        Greg
 
PS. Even though most of MPLS WG is likely subscrib= ed to=20 CCAMP list, I'll add MPLS WG to have opinions and comments from=20 it.

From: John E Drake [mailto:jdrake@junip= er.net]=20
Sent: Friday, August 17, 2012 2:49 PM
To: Gregory Mirs= ky;=20 Greg Mirsky; Francesco Fondelli
Cc: ccamp@ietf.org
Subject:= =20 RE: [CCAMP] I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Greg,

 

It’s=20 not clear what ‘monitored independently’ means and whether it e= dicts=20 coordinated  or independent mode.

 

It=20 really can’t, because as I indicated previously, in both modes there = is a=20 bidirectional flow of control packets and in both modes there is a stream o= f=20 CC/CV packets in each direction.  The only difference is whether if on= e=20 direction fails, the other direction is forced to fail.

 

I=20 always thought independent mode was suspect and that requirement for it was= =20 derived from the way Y.1731 worked, but I think it is equally suspect for b= oth=20 associated and co-routed.

 

Thanks,

 

John =20  

 

Sent=20 from my iPhone

 

From:<= /B> Gregory Mirs= ky=20 [mailto:gregory.mirsky@ericsson.com]
Sent: Friday, August 17, 20= 12=20 2:34 PM
To: John E Drake; Greg Mirsky; Francesco=20 Fondelli
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] I-D Ac= tion:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

 

J= ohn,

a= s Dave=20 Allan pointed, RFC 6428 does not mandate how coordinated and independent mo= des=20 should be used. But the very first sentence of Section 3.1 of the document = we're=20 discussing says

"= The=20 associated bidirectional LSP's forward and backward directions are set= up,=20 monitored, and protected independently as required by   [RFC5654]." And in RFC 5654, section 1.2= .2 I=20 indeed find

"= Associated=20 bidirectional path: A path that supports traffic flow in both directio= ns=20 but that is constructed from a pair of unidirectional paths (one for e= ach=20 direction) that are associated with one another at the path's=20 ingress/egress points.  The forward and backward directions are s= etup,=20 monitored, and protected independently.  As a consequence, they m= ay or=20 may not follow the same route (links and nodes) across the=20 network."

 

I= think=20 there's no need for RFC 6428bis. Do you think there's need to revise RFC=20 5654?

 

    R= egards,

        G= reg

 

 

From:<= /B> John E Drake= [mailto:jdrake@juniper.net]
Se= nt:=20 Friday, August 17, 2012 2:20 PM
To: Gregory Mirsky; Greg Mirsky;= =20 Francesco Fondelli
Cc: ccamp@ietf.org
Subject: RE: [C= CAMP]=20 I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

Greg,

 

For=20 both modes there is bidirectional flow of control packets.  For Indepe= ndent=20 mode the CC/CV packets flow in only one direction.

 

There=20 never was a coupling between modes and associated/co-routed and if you can = point=20 me to any text that says the contrary I would appreciate it as a bis to rem= ove=20 that text would be required.

 

Thanks,

 

John=20

 

Sent=20 from my iPhone

 

From:<= /B> Gregory Mirs= ky [mailto:gregory.mirsky@ericsson.= com]=20
Sent: Friday, August 17, 2012 2:12 PM
To: John E Drake= ;=20 Greg Mirsky; Francesco Fondelli
Cc: ccamp@ietf.org
Subject: RE: [C= CAMP]=20 I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

 

H= i=20 John,

i= n=20 independent mode CC/CV control messages been sent only in one direction. Th= us=20 there are two CC/CV sessions - one for each independently monitored directi= on.=20 That, AFAIK, was intentional.

 

    R= egards,

        G= reg

 

From:<= /B> John E Drake= [mailto:jdrake@juniper.net]
Se= nt:=20 Friday, August 17, 2012 1:50 PM
To: Gregory Mirsky; Greg Mirsky;= =20 Francesco Fondelli
Cc: ccamp@ietf.org
Subject: RE: [C= CAMP]=20 I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

Greg,

 

That=20 certainly wasn’t the intent.  With a bidirectional LSP of either= type you=20 have one forward and one return path and BFD does not care whether they are= =20 congruent.

 

Thanks,

 

John

 

Sent=20 from my iPhone

 

From:<= /B> Gregory Mirs= ky [mailto:gregory.mirsky@ericsson.= com]=20
Sent: Friday, August 17, 2012 1:28 PM
To: John E Drake= ;=20 Greg Mirsky; Francesco Fondelli
Cc: ccamp@ietf.org
Subject: RE: [C= CAMP]=20 I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

 

H= i=20 John,

I= think=20 that bi-directional associated p2p LSP, regardless of how many common = LSRs=20 forward and reverse directions have, implies use of independent mode o= f RFC=20 6428, then there will be two sessions to monitor each direction independent= ly.=20 Coordinated mode of RFC 6428, in my understanding, applies to bidirectional= =20 co-routed p2p LSP.

 

    R= egards,

        G= reg

 

From:<= /B> ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] <= B>On=20 Behalf Of John E Drake
Sent: Friday, August 17, 2012 1:19=20 PM
To: Greg Mirsky; Francesco Fondelli
Cc: ccamp@ietf.org
Subject: Re: [C= CAMP]=20 I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

Greg,

 

According=20 to RFC 6428 the is one CC/CV/RDI session irregardless of whether the=20 bi-directional packet LSP is co-routed or associated.

 

Thanks,

 

John

 

Sent=20 from my iPhone

 

From:<= /B> ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] <= B>On=20 Behalf Of Greg Mirsky
Sent: Friday, August 17, 2012 12:27=20 PM
To: Francesco Fondelli
Cc: ccamp@ietf.org
Subject: Re: [C= CAMP]=20 I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

 

Hi Francesco,
"from a= =20 data-plane view point b) and c2) are the same thing"
I think that given = that=20 c) is associated bi-directional LSP that implies independent OAM and protec= tion=20 for each direction, b) and c2) are not the same in the data plane view. E.g= .,=20 there will be single CC/CV/RDI session for b) while c2) will have two sessi= ons.=20 And if linear protection requested, b) will be protected by single=20 bi-directional LSP, but c2) - by two unidirectional=20 LSPs.

Regards,
Greg

On Fri, Aug 17, 2012 at 1:48 AM, Francesco Fondelli &l= t;francesco.fondelli@gmail.com> wrote:

Hi All,

I think I'm lost, please help.

R= akesh=20 is talking about "co-routed associated bidirectional
LSP"... for the sak= e of=20 clarity, let me try to categorize
LSPs from a control plane view=20 point:

  a) Point-to-point unidirectional
  b)=20 Point-to-point co-routed bidirectional
  c) Point-to-point associat= ed=20 bidirectional
   c1) fwd and rev LSP follow different=20 paths
   c2) fwd and rev LSP follow same path
  d)=20 Point-to-multipoint unidirectional
  e) Multipoint-to-point=20 unidirectional

Is section 3.2.5 (Signaling of Co-routed LSPs)=20 of
mpls-tp-rsvpte-ext-associated-lsp about b) or it is about c2)?
In=20 my opinion:

- b) should be signaled with 3473
- c) are addressed = by=20 this I-D (mpls-tp-rsvpte-ext-associated-lsp)

Am I missing=20 something?

thank you
ciao
fra

PS
from a data-plane v= iew=20 point b) and c2) are the same thing.


On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi=20 (rgandhi)
<rgandhi@cisco.com= >=20 wrote:
> Hi Lou,
>
> Thanks for initiating discussions on= the=20 changes in the draft.
>
> Agree with you here, if we/WG do not = agree=20 on the "co-routed associated bidirectional LSP" part, we are ok to remove i= t=20 from this draft and can always submit a new draft just for that. We respect= =20 your/WG decision.
>
> Thanks,
>=20 Rakesh
>
>
>
> -----Original Message-----
> F= rom:=20 Lou Berger [mailto:lberger@labn.net]
> Sent: Thursd= ay,=20 August 16, 2012 6:08 PM
> To: John E Drake
> Cc: Rakesh Gandhi= =20 (rgandhi); ccamp@ietf.org
> Sub= ject:=20 Re: [CCAMP] I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>
>=20 John,
>         While strictly speaking WG drafts= =20 should only reflect current WG consensus, and it is the WG draft editor's j= ob to=20 ensure this, in practice authors/editors are given a lot of latitude in tim= ing /=20 ordering in introduction to changes.  I personally think this is a=20 practical way of keeping the process moving.  Also if the WG disagrees= with=20 a change, it can always be backed out.
>
> So, yes, the WG coul= d do=20 exactly as you say if it comes to it.  (The chairs can even appoint=20 different editor if needed, e.g., to make this
> happen.)  While= I'm=20 not happy with how this revision came about, as I covered in earlier mail, = my=20 feeling is to let the discussion take place on the list (and at the next IE= TF,=20 if needed) and then have the draft updated to reflect the WG=20 discussion/consensus.
>
> Lou
>
> On 8/16/2012 5:35= PM,=20 John E Drake wrote:
>> Lou,
>>
>> Since the WG d= id=20 not agree to this changes, let alone discuss them,
>> would it be= =20 possible to simply rollback these changes and ask the
>> authors t= o=20 write a draft addressing the topics you list in your email,
>>=20 below?
>>
>> Thanks,
>>
>>=20 John
>>
>> Sent from my=20 iPhone
>>
>>
>>> -----Original=20 Message-----
>>> From: ccamp-bounces@ietf.org [mailto:<= A=20 href=3D"mailto:ccamp-bounces@ietf.org">ccamp-bounces@ietf.org]=20 On
>>> Behalf Of Lou Berger
>>> Sent: Thursday, Aug= ust=20 16, 2012 2:10 PM
>>> To: Rakesh Gandhi (rgandhi)
>>>= ; Cc:=20 ccamp@ietf.org
>>> Subjec= t: Re:=20 [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-
>>>=20 associated-lsp-04.txt
>>>
>>> Rakesh,
>>&g= t;=20      Such major changes (in scope and functionality) to WG d= rafts=20 are
>>> usually discussed with the WG prior to the authors/edit= ors=20 just
>>> publishing the changes.  But, this is a judgment = call=20 by the document
>>> editors in how, quoting rfc2418, they "ensu= r[e]=20 that the contents of
>>> the document accurately reflect the=20 decisions that have been made by
>>> the working=20 group."
>>>
>>> So let's jump into discussing the=20 changes.
>>>
>>> As I see it this draft introduces= =20 several major functional changes
>>> that have not been discuss= ed by=20 the WG.  Correct me if I get them
>>> wrong, but I believe= they=20 include:
>>> 1) Introduction of a second method for signaling=20 Co-routed LSPs
>>> 2) Support for FRR bypass tunnels for piggyb= acked=20 on the TP
>>> bidirectional LSP=20 mechanisms.
>>>
>>>    There are also oth= er=20 changes, but I'll defer discussing them
>>>    until = the=20 discussion on the above is concluded.
>>>
>>> Is th= is=20 correct?
>>>
>>> Assuming yes, I have questions abo= ut=20 both rational and specific
>>> mechanisms.  For now let's = look=20 at the former, so please:
>>>
>>> A) Articulate the= =20 issues/limitations with using the RFC3473 defined
>>> mechanism= s for=20 (co-routed) bidirectional LSPs that you'd like to see
>>>=20 addressed.
>>>
>>> B.1) Articulate the FRR/GMPLS-re= lated=20 issue you'd like to address?
>>>
>>> B.2) Articulat= e why=20 this issue should be solved in a TP-specific and
>>> not GMPLS= =20 generic fashion?
>>>
>>> Thanks,
>>>=20 Lou
>>>
>>> On 8/16/2012 4:26 PM, Rakesh Gandhi=20 (rgandhi) wrote:
>>>> Hi=20 Lou,
>>>>
>>>>=20 Yes.
>>>>
>>>> Please advise if you think det= ailed=20 email is required.
>>>> We believe latest draft summarizes t= he=20 changes well and we could
>>> start review/discussions from=20 there.
>>>>
>>>> Thanks,
>>>>= =20 Rakesh
>>>>
>>>>
>>>> -----Ori= ginal=20 Message-----
>>>> From: Lou Berger [mailto:lberger@labn.net]
>>>> = Sent:=20 Thursday, August 16, 2012 4:00 PM
>>>> To: Rakesh Gandhi=20 (rgandhi)
>>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn
>>= >>=20 Subject: Re: [CCAMP] I-D Action:
>>>>=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>&g= t;
>>>>=20 Rakesh,
>>>>     Is this the start of the thread t= hat I=20 requested in
>>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729= .html
>>>>
>>>>=20 In particular, is it the response to:
>>>>> I'd like to a= sk=20 that someone (Rakesh, Fei, etc.) review each of the
>>>>>= =20 proposed change and the rational for each change (in one or=20 in
>>>>> separate e-mails). The WG discussion can then re= ally=20 begin on the
>>>>> proposed changes. (Which are quite=20 substantial both in scope and
>>>>>=20 implication.)
>>>>
>>>>=20 Lou
>>>>
>>>> On 8/16/2012 3:19 PM, Rakesh Ga= ndhi=20 (rgandhi) wrote:
>>>>> Hi=20 All,
>>>>>
>>>>> We have uploaded a new= =20 version of this draft with following=20 changes:
>>>>
>>>> 1.  Added a section o= n=20 Signaling of Co-routed LSPs
>>>>
>>>> 2.=20  Added clarification on Signaling of Associated=20 Bidirectional
>>>> Protection=20 LSPs
>>>>
>>>> 3.  Added a section on=20 Signaling of Auto-tunnel Mesh-group LSPs
>>>>
>>>= ;>=20 4.   Added clarification on Signaling of Inter-domain=20 Associated
>>> Bidirectional=20 LSPs
>>>>
>>>> 5.  The Extended ASSOCIAT= ION=20 object format with Association Type
>>> "Associated Bidirection= al=20 LSP". Clarified on how to populate
>>> different fields in this= =20 object.
>>>>
>>>>
>>>>> We= =20 believe that some of these changes were necessary to avoid the
>>&= gt;=20 interoperability issues due to potentially different=20 interpretations.
>>>>>
>>>>> Your revie= w=20 comments are welcome.
>>>>>
>>>>>=20 Thanks,
>>>>>=20 Rakesh
>>>>>
>>>>> -----Original=20 Message-----
>>>>> From: ccamp-bounces@ietf.org [mailto:<= A=20 href=3D"mailto:ccamp-bounces@ietf.org">ccamp-bounces@ietf.org]=20 On
>>>>> Behalf Of internet-drafts@ietf.org
&g= t;>>>>=20 Sent: Wednesday, August 15, 2012 10:53 AM
>>>>> To: i-d-announce@ietf.org
>>= >>>=20 Cc: ccamp@ietf.org
>>>>= ;>=20 Subject: [CCAMP] I-D Action:
>>>>>=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>&g= t;>
>>>>>
>>>>>=20 A New Internet-Draft is available from the on-line=20 Internet-Drafts
>>> directories.
>>>>>  = This=20 draft is a work item of the Common Control and Measurement
>>> = Plane=20 Working Group of the IETF.
>>>>>
>>>>>= =20    Title           : RSVP-TE Extensions = for=20 Associated Bidirectional
>>> LSPs
>>>>>  = ;=20  Author(s)       : Fei Zhang
>>>>> &n= bsp;=20                      = ;=20   Ruiquan Jing
>>>>>         &nb= sp;=20                 Rakesh=20 Gandhi
>>>>>    Filename      =20  : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-
>>>=20 lsp-04.txt
>>>>>    Pages      = =20     : 17
>>>>>    Date    = =20        :=20 2012-08-15
>>>>>
>>>>>=20 Abstract:
>>>>>    The MPLS Transport Profile=20 (MPLS-TP) requirements document
>>>=20 [RFC5654],
>>>>>    describes that MPLS-TP MUST= =20 support associated bidirectional
>>> point-
>>>>= >=20    to-point LSPs.
>>>>>
>>>>>= =20    This document provides a method to bind two unidirectional=20 Label
>>>>>    Switched Paths (LSPs) into an=20 associated bidirectional LSP.  The
>>>>>  =20  association is achieved by defining the new Association Type=20 in
>>> the
>>>>>    Extended ASSOCI= ATION=20 object.
>>>>>
>>>>>
>>>>= >=20 The IETF datatracker status page for this draft is:
>>>>>= https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-r= svpte-
>>>=20 ext-
>>>>> a
>>>>>=20 ssociated-lsp
>>>>>
>>>>> There's also = a=20 htmlized version available at:
>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-= ext-
>>>=20 associ
>>>>> a
>>>>>=20 ted-lsp-04
>>>>>
>>>>> A diff from the= =20 previous version is available at:
>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp= -rsvpte-
>>>=20 ext-
>>>>> a
>>>>>=20 ssociated-lsp-04
>>>>>
>>>>>
>>= ;>>>=20 Internet-Drafts are also available by anonymous FTP at:
>>>>= >=20 ftp://ftp.ietf.org/internet-drafts/
>>>>= >
>>>>>=20 _______________________________________________
>>>>> CCA= MP=20 mailing list
>>>>> CCAMP@ietf.org
>>>>> <= A=20 href=3D"https://www.ietf.org/mailman/listinfo/ccamp"=20 target=3D_blank>https://www.ietf.org/mailman/listinfo/ccamp
>>= >>>
>>>>>
>>>>>
>>>= ;>>
>>>>
>>>>
>>>>
&g= t;>>>
>>>=20 _______________________________________________
>>> CCAMP maili= ng=20 list
>>> CCAMP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>=
>>
>>
>>
>=20 _______________________________________________
> CCAMP mailing=20 list
> CCAMP@ietf.org
> <= A=20 href=3D"https://www.ietf.org/mailman/listinfo/ccamp"=20 target=3D_blank>https://www.ietf.org/mailman/listinfo/ccamp
________= _______________________________________
CCAMP=20 mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp<= /P>

 

--_000_FE60A4E52763E84B935532D7D9294FF139268CC08EEUSAACMS0715e_-- From kvivek@broadcom.com Sat Aug 18 04:45:17 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 9012921F8575 for ; Sat, 18 Aug 2012 04:45:17 -0700 (PDT) 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 J42poiBMz3kb for ; Sat, 18 Aug 2012 04:45:14 -0700 (PDT) Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 946EE21F8570 for ; Sat, 18 Aug 2012 04:45:14 -0700 (PDT) Received: from [10.16.192.224] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Sat, 18 Aug 2012 04:43:09 -0700 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; Sat, 18 Aug 2012 04:45:01 -0700 Received: from SJEXCHMB09.corp.ad.broadcom.com ( [fe80::3da7:665e:cc78:181f]) by SJEXCHCAS07.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Sat, 18 Aug 2012 04:45:01 -0700 From: "Vivek Kumar" To: "mpls@ietf.org" Thread-Topic: Question regarding MPLS reserved label with ECMP Thread-Index: AQHNfTbmBR1rCwOtLk2zVDYhhU884w== Date: Sat, 18 Aug 2012 11:45:00 +0000 Message-ID: <3C086BA39C55B9418AE8FEA3F3EFDEC408291E@SJEXCHMB09.corp.ad.broadcom.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.240.253.6] MIME-Version: 1.0 X-WSS-ID: 7C31A04749820811403-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [mpls] Question regarding MPLS reserved label with ECMP 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, 18 Aug 2012 11:45:17 -0000 Hi , I have one question regarding whether MPLS reserved label should be used = or skipped when Transit LSR is doing hashing on full label stack which has = some reserved label. RFC 6391 , section 7 , says " Note that, depending on the number of labe= ls hashed by the LSR, the inclusion of the Router Alert label may cause the OAM packet to be load-balanced to a different path from that taken by the data packets with identical flow and PW labels". The above comment implies that reserved label is used by LSR when doing h= ashing for ECMP.=20 Is there any other RFC which states what should be the correct behavior.= =20 =20 The draft " draft-ietf-mpls-entropy-label-05" section 4.3 , says reserved= label should not be used by LSR when doing hashing on label stack. =20 Regards, Vivek=20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of mpl= s-request@ietf.org Sent: Saturday, August 18, 2012 5:12 AM To: mpls@ietf.org Subject: mpls Digest, Vol 100, Issue 32 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to=20 https://www.ietf.org/mailman/listinfo/mpls Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send mpls mailing list submissions to mpls@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/mpls or, via email, send a message with subject or body 'help' to mpls-request@ietf.org You can reach the person managing the list at mpls-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of mpls digest..." Today's Topics: 1. I-D Action: draft-ietf-mpls-entropy-label-05.txt (internet-drafts@ietf.org) 2. Re: draft-ietf-mpls-tp-te-mib-04.txt review request (Venkatesan Mahalingam) 3. Re: draft-ietf-mpls-tp-te-mib-04.txt review request (Sam Aldrin) 4. Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt (Gregory Mirsky) ---------------------------------------------------------------------- Message: 1 Date: Fri, 17 Aug 2012 12:19:09 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-entropy-label-05.txt Message-ID: <20120817191909.22120.13634.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=3D"utf-8" 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 : The Use of Entropy Labels in MPLS Forwarding Author(s) : Kireeti Kompella John Drake Shane Amante Wim Henderickx Lucy Yong Filename : draft-ietf-mpls-entropy-label-05.txt Pages : 23 Date : 2012-08-17 Abstract: Load balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing across MPLS networks using the concept of "entropy labels". It defines the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications. This document updates RFCs 3031, 3107, 3209 and 5036. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-entropy-label There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-entropy-label-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-entropy-label-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ------------------------------ Message: 2 Date: Fri, 17 Aug 2012 13:51:19 -0700 From: Venkatesan Mahalingam To: Joan Cucchiara , mpls@ietf.org, "MIB Doctors (E-mail)" , mpls-chairs@tools.ietf.org Cc: Sam Aldrin Subject: Re: [mpls] draft-ietf-mpls-tp-te-mib-04.txt review request Message-ID: Content-Type: text/plain; charset=3DISO-8859-1 ++ MPLS WG & MIB Drs. Thanks, Venkat. On Fri, Aug 17, 2012 at 1:36 PM, Joan Cucchiara wrote: > Venkat, > > The SMIv2 specifies that once a TC is defined, then the definition cannot > change in the way being > proposed by the draft-ietf-mpls-tp-te-mib-04. > > From RFC2579: > 3.3. Mapping of the DESCRIPTION clause > The DESCRIPTION clause, which must be present, contains a textual > definition of the textual convention, which provides all semantic > definitions necessary for implementation, and should embody any > information which would otherwise be communicated in any ASN.1 > commentary annotations associated with the object. > > > My concern is that MPLS-TC-STD-MIB defines MplsExtendedTunnelId and this > draft is changing that original definition. > If RFC3811 does not contain "all semantic definitions necessary for > implementation" then the problem is to update RFC3811 > and maybe other associated RFCs as needed, not to propose additional > semantics in draft-ietf-mpls-tp-te-mib. > > The draft is proposing to bifurcate the values and also not use zero for = the > MplsExtendedTunnelId, that is not the original > definition of MplsExtendedTunnelId, so why is this draft using > MplsExtendedTunnelId? > > Please include the MIB Dr's on your email because this is a MIB concern a= nd > one which I've had since > before this draft was adopted as a WG document. > > The options are (as I see them): > 1) create a specific MPLS TP table for TP Tunnels (which was originally > proposed by Adrian Farrel) > 2) update RFC3811 to accurately reflect MplsExtendedTunnelId and other RF= Cs > which utilize this TC. > 3) ?? > > Thanks, > -Joan > > > ----- Original Message ----- From: "Venkatesan Mahalingam" > > To: "Joan Cucchiara" > Cc: "Thomas Nadeau" ; "Sam Aldrin" > ; "Kannan KV Sampath" > Sent: Friday, August 17, 2012 2:39 PM > > Subject: Re: draft-ietf-mpls-tp-te-mib-04.txt review request > > >> Joan, >> >> Thanks for your response. Appreciate your time for reviewing this >> draft. Please find below my response tagged [VM]. >> >> However, I looked over the doc and wanted to let you know that I still >> have >>> >>> the same issue wrt to both SYNTAX and semantic >>> redefinition as before. You cannot narrow the range of values in a >>> DESCRIPTION clause which I see happens in mplsTunnelExtNodeConfigLocalI= d >>> and maybe in MplsNodeId TC as it says zero must not be used, but then >>> you >>> have it as part of allowable values in the SYNTAX. >> >> [VM] If MplsExtendedTunnelId allows zero as the valid value, I don't >> see any issue to allow zero as the valid value for MplsNodeId. >> >>> Additionally, the SYNTAX below for MplsExtendedTunnelId allows any >>> Unsigned32 and says "may represent an IPv4 address". If (for whateve= r >>> reason) an >>> operator has configured something in the 1..16777216 (i.e. Local Id) >>> range, >>> for a regular TE Tunnel, that is perfectly legal, right? >> >> [VM] I don't see any implementation which allows non-IP TE tunnel >> source/destination in the range 1..16777216 in MPLS domain, >> if you are not still convinced, we can poll in MPLS WG list to get the >> operators' opinion on this. >> >>> If the answer is Yes, then how would you add TP Tunnels using your draf= t >>> if >>> an operator has a regular MPLS TE Tunnel configured >>> in the range 1..16777216 without having to ensure that any and all lega= cy >>> equipment be queried first? >> >> [VM] It is expected to configure MPLS TE tunnels in IP address range >> and MPLS-TP tunnel in NON-IP range, if the implementors have mixed >> mode of configuration, then it is expected to clarify in the document >> that how to use MPLS-TE & MPLS-TP tunnel configurations. >> What you are saying is correct only if the legacy equipments use the >> NON-IP range for MPLS TE tunnels, so, as I stated above, let's close >> this with the MPLS WG list. >> >> HTH >> >> Thanks, >> Venkat. >> >> On Fri, Aug 17, 2012 at 10:21 AM, Joan Cucchiara >> wrote: >>> >>> Tom and all, >>> >>> Unfortunately, my linux box is giving me grief this week (and I don't >>> have >>> access to my MIB tools). I'm getting some assistance >>> with it but won't be resolved until (hopefully) during the weekend. >>> >>> However, I looked over the doc and wanted to let you know that I still >>> have >>> the same issue wrt to both SYNTAX and semantic >>> redefinition as before. You cannot narrow the range of values in a >>> DESCRIPTION clause which I see happens in mplsTunnelExtNodeConfigLocalI= d >>> and maybe in MplsNodeId TC as it says zero must not be used, but then >>> you >>> have it as part of allowable values in the SYNTAX. >>> >>> Whatever is specified in the DESCRIPTION clause for values, should be >>> reflected by the SYNTAX, right? >>> >>> Additionally, the SYNTAX below for MplsExtendedTunnelId allows any >>> Unsigned32 and says "may represent an IPv4 address". If (for whateve= r >>> reason) an >>> operator has configured something in the 1..16777216 (i.e. Local Id) >>> range, >>> for a regular TE Tunnel, that is perfectly legal, right? >>> >>> >>> MplsExtendedTunnelId ::=3D TEXTUAL-CONVENTION >>> STATUS current >>> DESCRIPTION >>> "A unique identifier for an MPLS Tunnel. This may >>> represent an IPv4 address of the ingress or egress >>> LSR for the tunnel. This value is derived from the >>> Extended Tunnel Id in RSVP or the Ingress Router ID >>> for CR-LDP." >>> REFERENCE >>> "RSVP-TE: Extensions to RSVP for LSP Tunnels, >>> [RFC3209]. >>> >>> Constraint-Based LSP Setup using LDP, [RFC3212]." >>> SYNTAX Unsigned32(0..4294967295) >>> >>> If the answer is Yes, then how would you add TP Tunnels using your draf= t >>> if >>> an operator has a regular MPLS TE Tunnel configured >>> in the range 1..16777216 without having to ensure that any and all lega= cy >>> equipment be queried first? >>> >>> Thanks, >>> -Joan >>> >>> >>> >>> ----- Original Message ----- >>> From: Thomas Nadeau >>> To: Joan Cucchiara >>> Cc: Sam Aldrin ; Venkatesan Mahalingam ; Kannan KV Sampath >>> Sent: Thursday, August 09, 2012 8:58 AM >>> Subject: Re: draft-ietf-mpls-tp-te-mib-04.txt review request >>> >>> hi Joan >>> >>> hope you had a great vacation! ;) >>> >>> can you please follow up on the note below when you have a chance? >>> >>> Tom >>> >>> >>> >>> On Jul 16, 2012, at 9:13 AM, "Joan Cucchiara" >>> wrote: >>> >>> Sam, >>> >>> We are away this week returning on 7/23. Sorry, I can't review the do= c >>> until after 7/23 and it will >>> take a few days after that as I'll just be returning from vacation. >>> >>> I glanced at it and see that there are read-write objects in a row (whi= ch >>> is >>> read-create) so that's >>> an error which I mentioned before. >>> >>> Have you compiled this with smilint? >>> >>> Thanks, >>> -Joan >>> >>> >>> >>> >>> >>> ----- Original Message ----- >>> From: Sam Aldrin >>> To: Joan Cucchiara >>> Cc: Venkatesan Mahalingam ; Thomas Nadeau ; Kannan KV Sampath >>> Sent: Friday, July 13, 2012 9:11 PM >>> Subject: Fwd: draft-ietf-mpls-tp-te-mib-04.txt review request >>> >>> Hi Joan, >>> >>> Please find the updated MIB document. Apologize for the delay. We plan = to >>> publish the doc on Monday as it is the deadline before IETF. Diff file = is >>> attached as well. >>> >>> This version addresses all your comments. Highlighting couple of them t= o >>> make sure you are OK with them >>> >>> 1. W.r.t mplsLocalID as index type, we have removed that using >>> MplsExtendedTunnelId itself. As the value range for this object could >>> have >>> value of non-IP address, we are using it. This will make the indices fo= r >>> the >>> same as TunnelTable. >>> In the definition of IngressLSRId and and EgressLSRId, for TP entries, = we >>> added description to use value of non-IP address, which is local ID. >>> >>> I do hope this satisfies the need and not necessitate for a new table >>> altogether for TP. >>> >>> 2. In regards to adding references to TC conventions. We believe, those >>> were >>> added in the reference section. IF we have missed any TC references, >>> could >>> you kindly let us know. >>> >>> Appreciate if you can get back by Monday noon time PST. I know it is a >>> very >>> short time, but appreciate if you could do that. >>> >>> thanks >>> -sam >>> >>> ________________________________ >>> >>> > ------------------------------ Message: 3 Date: Fri, 17 Aug 2012 14:06:45 -0700 From: Sam Aldrin To: Venkatesan Mahalingam Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, Sam Aldrin , "MIB Doctors \(E-mail\)" Subject: Re: [mpls] draft-ietf-mpls-tp-te-mib-04.txt review request Message-ID: <2E7490DB-3DE7-42C8-8E43-7378A76C2B4C@gmail.com> Content-Type: text/plain; charset=3Dus-ascii Hi Joan, The issue boils down to the range value specified in the DESCRIPTION. If that is removed, does that resolve the concern you raised? Do not think we are restricting not to use '0' in anyway or redefining the = semantics. As the value is local and the intention is to help implementor of the MIB t= o choose right value, without conflicting with TE tunnel index, we added th= at range. If implementor chooses to use different value altogether, it is p= erfectly OK as long as it is in the range of mplsExtendedTunnelId definitio= n. W.r.t legacy implementation, it is unto the implementor to assign the right= index value to TP tunnel, if it conflicts with TE tunnel index. The example provided could give guidance on what value to use, but will not= MANDATE the usage. In regards to implementing a new table, we have deliberated extensively amo= ng authors and also with implementors. Adding new MIB or table is not reall= y efficient. Infact, there are already implementations which were able to s= upport the legacy model as well as new TP tunnels. Unless there is a compel= ling reason that MPLS TP tunnel table should have its own table, which esse= ntially duplicated all of the objects, I am not for that model. If others i= n WG feels the need, they can speak up. -sam On Aug 17, 2012, at 1:51 PM, Venkatesan Mahalingam wrote: > ++ MPLS WG & MIB Drs. >=20 > Thanks, > Venkat. >=20 > On Fri, Aug 17, 2012 at 1:36 PM, Joan Cucchiara > wrote: >> Venkat, >>=20 >> The SMIv2 specifies that once a TC is defined, then the definition canno= t >> change in the way being >> proposed by the draft-ietf-mpls-tp-te-mib-04. >>=20 >> From RFC2579: >> 3.3. Mapping of the DESCRIPTION clause >> The DESCRIPTION clause, which must be present, contains a textual >> definition of the textual convention, which provides all semantic >> definitions necessary for implementation, and should embody any >> information which would otherwise be communicated in any ASN.1 >> commentary annotations associated with the object. >>=20 >>=20 >> My concern is that MPLS-TC-STD-MIB defines MplsExtendedTunnelId and this >> draft is changing that original definition. >> If RFC3811 does not contain "all semantic definitions necessary for >> implementation" then the problem is to update RFC3811 >> and maybe other associated RFCs as needed, not to propose additional >> semantics in draft-ietf-mpls-tp-te-mib. >>=20 >> The draft is proposing to bifurcate the values and also not use zero for= the >> MplsExtendedTunnelId, that is not the original >> definition of MplsExtendedTunnelId, so why is this draft using >> MplsExtendedTunnelId? >>=20 >> Please include the MIB Dr's on your email because this is a MIB concern = and >> one which I've had since >> before this draft was adopted as a WG document. >>=20 >> The options are (as I see them): >> 1) create a specific MPLS TP table for TP Tunnels (which was originally >> proposed by Adrian Farrel) >> 2) update RFC3811 to accurately reflect MplsExtendedTunnelId and other R= FCs >> which utilize this TC. >> 3) ?? >>=20 >> Thanks, >> -Joan >>=20 >>=20 >> ----- Original Message ----- From: "Venkatesan Mahalingam" >> >> To: "Joan Cucchiara" >> Cc: "Thomas Nadeau" ; "Sam Aldrin" >> ; "Kannan KV Sampath" >> Sent: Friday, August 17, 2012 2:39 PM >>=20 >> Subject: Re: draft-ietf-mpls-tp-te-mib-04.txt review request >>=20 >>=20 >>> Joan, >>>=20 >>> Thanks for your response. Appreciate your time for reviewing this >>> draft. Please find below my response tagged [VM]. >>>=20 >>> However, I looked over the doc and wanted to let you know that I still >>> have >>>>=20 >>>> the same issue wrt to both SYNTAX and semantic >>>> redefinition as before. You cannot narrow the range of values in a >>>> DESCRIPTION clause which I see happens in mplsTunnelExtNodeConfigLocal= Id >>>> and maybe in MplsNodeId TC as it says zero must not be used, but then >>>> you >>>> have it as part of allowable values in the SYNTAX. >>>=20 >>> [VM] If MplsExtendedTunnelId allows zero as the valid value, I don't >>> see any issue to allow zero as the valid value for MplsNodeId. >>>=20 >>>> Additionally, the SYNTAX below for MplsExtendedTunnelId allows any >>>> Unsigned32 and says "may represent an IPv4 address". If (for whatev= er >>>> reason) an >>>> operator has configured something in the 1..16777216 (i.e. Local Id) >>>> range, >>>> for a regular TE Tunnel, that is perfectly legal, right? >>>=20 >>> [VM] I don't see any implementation which allows non-IP TE tunnel >>> source/destination in the range 1..16777216 in MPLS domain, >>> if you are not still convinced, we can poll in MPLS WG list to get the >>> operators' opinion on this. >>>=20 >>>> If the answer is Yes, then how would you add TP Tunnels using your dra= ft >>>> if >>>> an operator has a regular MPLS TE Tunnel configured >>>> in the range 1..16777216 without having to ensure that any and all leg= acy >>>> equipment be queried first? >>>=20 >>> [VM] It is expected to configure MPLS TE tunnels in IP address range >>> and MPLS-TP tunnel in NON-IP range, if the implementors have mixed >>> mode of configuration, then it is expected to clarify in the document >>> that how to use MPLS-TE & MPLS-TP tunnel configurations. >>> What you are saying is correct only if the legacy equipments use the >>> NON-IP range for MPLS TE tunnels, so, as I stated above, let's close >>> this with the MPLS WG list. >>>=20 >>> HTH >>>=20 >>> Thanks, >>> Venkat. >>>=20 >>> On Fri, Aug 17, 2012 at 10:21 AM, Joan Cucchiara >>> wrote: >>>>=20 >>>> Tom and all, >>>>=20 >>>> Unfortunately, my linux box is giving me grief this week (and I don't >>>> have >>>> access to my MIB tools). I'm getting some assistance >>>> with it but won't be resolved until (hopefully) during the weekend. >>>>=20 >>>> However, I looked over the doc and wanted to let you know that I still >>>> have >>>> the same issue wrt to both SYNTAX and semantic >>>> redefinition as before. You cannot narrow the range of values in a >>>> DESCRIPTION clause which I see happens in mplsTunnelExtNodeConfigLocal= Id >>>> and maybe in MplsNodeId TC as it says zero must not be used, but then >>>> you >>>> have it as part of allowable values in the SYNTAX. >>>>=20 >>>> Whatever is specified in the DESCRIPTION clause for values, should be >>>> reflected by the SYNTAX, right? >>>>=20 >>>> Additionally, the SYNTAX below for MplsExtendedTunnelId allows any >>>> Unsigned32 and says "may represent an IPv4 address". If (for whatev= er >>>> reason) an >>>> operator has configured something in the 1..16777216 (i.e. Local Id) >>>> range, >>>> for a regular TE Tunnel, that is perfectly legal, right? >>>>=20 >>>>=20 >>>> MplsExtendedTunnelId ::=3D TEXTUAL-CONVENTION >>>> STATUS current >>>> DESCRIPTION >>>> "A unique identifier for an MPLS Tunnel. This may >>>> represent an IPv4 address of the ingress or egress >>>> LSR for the tunnel. This value is derived from the >>>> Extended Tunnel Id in RSVP or the Ingress Router ID >>>> for CR-LDP." >>>> REFERENCE >>>> "RSVP-TE: Extensions to RSVP for LSP Tunnels, >>>> [RFC3209]. >>>>=20 >>>> Constraint-Based LSP Setup using LDP, [RFC3212]." >>>> SYNTAX Unsigned32(0..4294967295) >>>>=20 >>>> If the answer is Yes, then how would you add TP Tunnels using your dra= ft >>>> if >>>> an operator has a regular MPLS TE Tunnel configured >>>> in the range 1..16777216 without having to ensure that any and all leg= acy >>>> equipment be queried first? >>>>=20 >>>> Thanks, >>>> -Joan >>>>=20 >>>>=20 >>>>=20 >>>> ----- Original Message ----- >>>> From: Thomas Nadeau >>>> To: Joan Cucchiara >>>> Cc: Sam Aldrin ; Venkatesan Mahalingam ; Kannan KV Sampath >>>> Sent: Thursday, August 09, 2012 8:58 AM >>>> Subject: Re: draft-ietf-mpls-tp-te-mib-04.txt review request >>>>=20 >>>> hi Joan >>>>=20 >>>> hope you had a great vacation! ;) >>>>=20 >>>> can you please follow up on the note below when you have a chance? >>>>=20 >>>> Tom >>>>=20 >>>>=20 >>>>=20 >>>> On Jul 16, 2012, at 9:13 AM, "Joan Cucchiara" >>>> wrote: >>>>=20 >>>> Sam, >>>>=20 >>>> We are away this week returning on 7/23. Sorry, I can't review the d= oc >>>> until after 7/23 and it will >>>> take a few days after that as I'll just be returning from vacation. >>>>=20 >>>> I glanced at it and see that there are read-write objects in a row (wh= ich >>>> is >>>> read-create) so that's >>>> an error which I mentioned before. >>>>=20 >>>> Have you compiled this with smilint? >>>>=20 >>>> Thanks, >>>> -Joan >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> ----- Original Message ----- >>>> From: Sam Aldrin >>>> To: Joan Cucchiara >>>> Cc: Venkatesan Mahalingam ; Thomas Nadeau ; Kannan KV Sampath >>>> Sent: Friday, July 13, 2012 9:11 PM >>>> Subject: Fwd: draft-ietf-mpls-tp-te-mib-04.txt review request >>>>=20 >>>> Hi Joan, >>>>=20 >>>> Please find the updated MIB document. Apologize for the delay. We plan= to >>>> publish the doc on Monday as it is the deadline before IETF. Diff file= is >>>> attached as well. >>>>=20 >>>> This version addresses all your comments. Highlighting couple of them = to >>>> make sure you are OK with them >>>>=20 >>>> 1. W.r.t mplsLocalID as index type, we have removed that using >>>> MplsExtendedTunnelId itself. As the value range for this object could >>>> have >>>> value of non-IP address, we are using it. This will make the indices f= or >>>> the >>>> same as TunnelTable. >>>> In the definition of IngressLSRId and and EgressLSRId, for TP entries,= we >>>> added description to use value of non-IP address, which is local ID. >>>>=20 >>>> I do hope this satisfies the need and not necessitate for a new table >>>> altogether for TP. >>>>=20 >>>> 2. In regards to adding references to TC conventions. We believe, thos= e >>>> were >>>> added in the reference section. IF we have missed any TC references, >>>> could >>>> you kindly let us know. >>>>=20 >>>> Appreciate if you can get back by Monday noon time PST. I know it is a >>>> very >>>> short time, but appreciate if you could do that. >>>>=20 >>>> thanks >>>> -sam >>>>=20 >>>> ________________________________ >>>>=20 >>>>=20 >>=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls ------------------------------ Message: 4 Date: Fri, 17 Aug 2012 19:42:04 -0400 From: Gregory Mirsky To: John E Drake , Greg Mirsky , Francesco Fondelli Cc: "mpls@ietf.org" , "ccamp@ietf.org" Subject: Re: [mpls] [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Message-ID: =09 Content-Type: text/plain; charset=3D"us-ascii" Hi John, "The only difference is whether if one direction fails, the other direction= is forced to fail." Yes. And whether associated bidirectional LSP requires protection as single= bidirectional p2p construct or protection applies to each direction indepe= ndently. But what happens to association in that case? Should protecting un= idirectional LSPs be associated with working and protecting unidirectional = LSPs of reverse direction before switchover? Consider working L1 A-Z and L2= Z-A are protected by L3 A-Z and L4 Z-A accordingly. L1 and L2 form associa= ted bidirectional p2p LSP. What about L3 and L2, L1 and L4, L3 and L4 - are= these the same associated bi-directional LSP or not? Regards, Greg PS. Even though most of MPLS WG is likely subscribed to CCAMP list, I'll ad= d MPLS WG to have opinions and comments from it. ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Friday, August 17, 2012 2:49 PM To: Gregory Mirsky; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, It's not clear what 'monitored independently' means and whether it edicts c= oordinated or independent mode. It really can't, because as I indicated previously, in both modes there is = a bidirectional flow of control packets and in both modes there is a stream= of CC/CV packets in each direction. The only difference is whether if one= direction fails, the other direction is forced to fail. I always thought independent mode was suspect and that requirement for it w= as derived from the way Y.1731 worked, but I think it is equally suspect fo= r both associated and co-routed. Thanks, John Sent from my iPhone From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, August 17, 2012 2:34 PM To: John E Drake; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt John, as Dave Allan pointed, RFC 6428 does not mandate how coordinated and indepe= ndent modes should be used. But the very first sentence of Section 3.1 of t= he document we're discussing says "The associated bidirectional LSP's forward and backward directions are set= up, monitored, and protected independently as required by [RFC5654]." And in RFC 5654, section 1.2.2 I indeed f= ind "Associated bidirectional path: A path that supports traffic flow in both d= irections but that is constructed from a pair of unidirectional paths (one = for each direction) that are associated with one another at the path's ingr= ess/egress points. The forward and backward directions are setup, monitore= d, and protected independently. As a consequence, they may or may not foll= ow the same route (links and nodes) across the network." I think there's no need for RFC 6428bis. Do you think there's need to revis= e RFC 5654? Regards, Greg ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Friday, August 17, 2012 2:20 PM To: Gregory Mirsky; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, For both modes there is bidirectional flow of control packets. For Indepen= dent mode the CC/CV packets flow in only one direction. There never was a coupling between modes and associated/co-routed and if yo= u can point me to any text that says the contrary I would appreciate it as = a bis to remove that text would be required. Thanks, John Sent from my iPhone From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, August 17, 2012 2:12 PM To: John E Drake; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi John, in independent mode CC/CV control messages been sent only in one direction.= Thus there are two CC/CV sessions - one for each independently monitored d= irection. That, AFAIK, was intentional. Regards, Greg ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Friday, August 17, 2012 1:50 PM To: Gregory Mirsky; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, That certainly wasn't the intent. With a bidirectional LSP of either type = you have one forward and one return path and BFD does not care whether they= are congruent. Thanks, John Sent from my iPhone From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, August 17, 2012 1:28 PM To: John E Drake; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi John, I think that bi-directional associated p2p LSP, regardless of how many comm= on LSRs forward and reverse directions have, implies use of independent mod= e of RFC 6428, then there will be two sessions to monitor each direction in= dependently. Coordinated mode of RFC 6428, in my understanding, applies to = bidirectional co-routed p2p LSP. Regards, Greg ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of John E Drake Sent: Friday, August 17, 2012 1:19 PM To: Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, According to RFC 6428 the is one CC/CV/RDI session irregardless of whether = the bi-directional packet LSP is co-routed or associated. Thanks, John Sent from my iPhone From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Greg Mirsky Sent: Friday, August 17, 2012 12:27 PM To: Francesco Fondelli Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi Francesco, "from a data-plane view point b) and c2) are the same thing" I think that given that c) is associated bi-directional LSP that implies in= dependent OAM and protection for each direction, b) and c2) are not the sam= e in the data plane view. E.g., there will be single CC/CV/RDI session for = b) while c2) will have two sessions. And if linear protection requested, b)= will be protected by single bi-directional LSP, but c2) - by two unidirect= ional LSPs. Regards, Greg On Fri, Aug 17, 2012 at 1:48 AM, Francesco Fondelli > wrote: Hi All, I think I'm lost, please help. Rakesh is talking about "co-routed associated bidirectional LSP"... for the sake of clarity, let me try to categorize LSPs from a control plane view point: a) Point-to-point unidirectional b) Point-to-point co-routed bidirectional c) Point-to-point associated bidirectional c1) fwd and rev LSP follow different paths c2) fwd and rev LSP follow same path d) Point-to-multipoint unidirectional e) Multipoint-to-point unidirectional Is section 3.2.5 (Signaling of Co-routed LSPs) of mpls-tp-rsvpte-ext-associated-lsp about b) or it is about c2)? In my opinion: - b) should be signaled with 3473 - c) are addressed by this I-D (mpls-tp-rsvpte-ext-associated-lsp) Am I missing something? thank you ciao fra PS from a data-plane view point b) and c2) are the same thing. On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi (rgandhi) > wrote: > Hi Lou, > > Thanks for initiating discussions on the changes in the draft. > > Agree with you here, if we/WG do not agree on the "co-routed associated b= idirectional LSP" part, we are ok to remove it from this draft and can alwa= ys submit a new draft just for that. We respect your/WG decision. > > Thanks, > Rakesh > > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, August 16, 2012 6:08 PM > To: John E Drake > Cc: Rakesh Gandhi (rgandhi); ccamp@ietf.org > Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-asso= ciated-lsp-04.txt > > John, > While strictly speaking WG drafts should only reflect current WG = consensus, and it is the WG draft editor's job to ensure this, in practice = authors/editors are given a lot of latitude in timing / ordering in introdu= ction to changes. I personally think this is a practical way of keeping th= e process moving. Also if the WG disagrees with a change, it can always be= backed out. > > So, yes, the WG could do exactly as you say if it comes to it. (The chai= rs can even appoint different editor if needed, e.g., to make this > happen.) While I'm not happy with how this revision came about, as I cov= ered in earlier mail, my feeling is to let the discussion take place on the= list (and at the next IETF, if needed) and then have the draft updated to = reflect the WG discussion/consensus. > > Lou > > On 8/16/2012 5:35 PM, John E Drake wrote: >> Lou, >> >> Since the WG did not agree to this changes, let alone discuss them, >> would it be possible to simply rollback these changes and ask the >> authors to write a draft addressing the topics you list in your email, >> below? >> >> Thanks, >> >> John >> >> Sent from my iPhone >> >> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:cca= mp-bounces@ietf.org] On >>> Behalf Of Lou Berger >>> Sent: Thursday, August 16, 2012 2:10 PM >>> To: Rakesh Gandhi (rgandhi) >>> Cc: ccamp@ietf.org >>> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>> associated-lsp-04.txt >>> >>> Rakesh, >>> Such major changes (in scope and functionality) to WG drafts are >>> usually discussed with the WG prior to the authors/editors just >>> publishing the changes. But, this is a judgment call by the document >>> editors in how, quoting rfc2418, they "ensur[e] that the contents of >>> the document accurately reflect the decisions that have been made by >>> the working group." >>> >>> So let's jump into discussing the changes. >>> >>> As I see it this draft introduces several major functional changes >>> that have not been discussed by the WG. Correct me if I get them >>> wrong, but I believe they include: >>> 1) Introduction of a second method for signaling Co-routed LSPs >>> 2) Support for FRR bypass tunnels for piggybacked on the TP >>> bidirectional LSP mechanisms. >>> >>> There are also other changes, but I'll defer discussing them >>> until the discussion on the above is concluded. >>> >>> Is this correct? >>> >>> Assuming yes, I have questions about both rational and specific >>> mechanisms. For now let's look at the former, so please: >>> >>> A) Articulate the issues/limitations with using the RFC3473 defined >>> mechanisms for (co-routed) bidirectional LSPs that you'd like to see >>> addressed. >>> >>> B.1) Articulate the FRR/GMPLS-related issue you'd like to address? >>> >>> B.2) Articulate why this issue should be solved in a TP-specific and >>> not GMPLS generic fashion? >>> >>> Thanks, >>> Lou >>> >>> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote: >>>> Hi Lou, >>>> >>>> Yes. >>>> >>>> Please advise if you think detailed email is required. >>>> We believe latest draft summarizes the changes well and we could >>> start review/discussions from there. >>>> >>>> Thanks, >>>> Rakesh >>>> >>>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Thursday, August 16, 2012 4:00 PM >>>> To: Rakesh Gandhi (rgandhi) >>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn >>>> Subject: Re: [CCAMP] I-D Action: >>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>> >>>> Rakesh, >>>> Is this the start of the thread that I requested in >>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html >>>> >>>> In particular, is it the response to: >>>>> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the >>>>> proposed change and the rational for each change (in one or in >>>>> separate e-mails). The WG discussion can then really begin on the >>>>> proposed changes. (Which are quite substantial both in scope and >>>>> implication.) >>>> >>>> Lou >>>> >>>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: >>>>> Hi All, >>>>> >>>>> We have uploaded a new version of this draft with following changes: >>>> >>>> 1. Added a section on Signaling of Co-routed LSPs >>>> >>>> 2. Added clarification on Signaling of Associated Bidirectional >>>> Protection LSPs >>>> >>>> 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs >>>> >>>> 4. Added clarification on Signaling of Inter-domain Associated >>> Bidirectional LSPs >>>> >>>> 5. The Extended ASSOCIATION object format with Association Type >>> "Associated Bidirectional LSP". Clarified on how to populate >>> different fields in this object. >>>> >>>> >>>>> We believe that some of these changes were necessary to avoid the >>> interoperability issues due to potentially different interpretations. >>>>> >>>>> Your review comments are welcome. >>>>> >>>>> Thanks, >>>>> Rakesh >>>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:c= camp-bounces@ietf.org] On >>>>> Behalf Of internet-drafts@ietf.org >>>>> Sent: Wednesday, August 15, 2012 10:53 AM >>>>> To: i-d-announce@ietf.org >>>>> Cc: ccamp@ietf.org >>>>> Subject: [CCAMP] I-D Action: >>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>>>> This draft is a work item of the Common Control and Measurement >>> Plane Working Group of the IETF. >>>>> >>>>> Title : RSVP-TE Extensions for Associated Bidirectional >>> LSPs >>>>> Author(s) : Fei Zhang >>>>> Ruiquan Jing >>>>> Rakesh Gandhi >>>>> Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated- >>> lsp-04.txt >>>>> Pages : 17 >>>>> Date : 2012-08-15 >>>>> >>>>> Abstract: >>>>> The MPLS Transport Profile (MPLS-TP) requirements document >>> [RFC5654], >>>>> describes that MPLS-TP MUST support associated bidirectional >>> point- >>>>> to-point LSPs. >>>>> >>>>> This document provides a method to bind two unidirectional Label >>>>> Switched Paths (LSPs) into an associated bidirectional LSP. The >>>>> association is achieved by defining the new Association Type in >>> the >>>>> Extended ASSOCIATION object. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte- >>> ext- >>>>> a >>>>> ssociated-lsp >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>> associ >>>>> a >>>>> ted-lsp-04 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte- >>> ext- >>>>> a >>>>> ssociated-lsp-04 >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls End of mpls Digest, Vol 100, Issue 32 ************************************* From adrian@olddog.co.uk Sat Aug 18 10:18: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 6D29321F849D for ; Sat, 18 Aug 2012 10:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 ZlJvxEHB7yV7 for ; Sat, 18 Aug 2012 10:18:34 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAE221F8495 for ; Sat, 18 Aug 2012 10:18:34 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7IHIWrt016770; Sat, 18 Aug 2012 18:18:33 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7IHIUtD016734 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 18 Aug 2012 18:18:32 +0100 From: "Adrian Farrel" To: "'Kireeti Kompella'" References: <0dc501cd7bb1$d318ad10$794a0730$@olddog.co.uk> <0edf01cd7c43$94feec00$befcc400$@olddog.co.uk> <3E2B22DB-9FF6-41D0-92C3-85E25FF57ECF@juniper.net> In-Reply-To: <3E2B22DB-9FF6-41D0-92C3-85E25FF57ECF@juniper.net> Date: Sat, 18 Aug 2012 18:18:26 +0100 Message-ID: <10c101cd7d65$7bd332e0$737998a0$@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: AQHPHuSqRl1cgpHy+Pw5z8k+/Sb7UAKzUXN9AjoNQFkBrUf7l5cntwCg Content-Language: en-gb Cc: mpls@ietf.org, draft-ietf-mpls-entropy-label@tools.ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-entropy-label 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: Sat, 18 Aug 2012 17:18:35 -0000 Yeah, and it is great that you give a reason for doing it, but by using SHOULD you have to explain why you might vary. That was what my MAY sentence was trying to do. If I got the reason wrong then sorry, please add your own reason. But if your reason is, because there might turn out to be a reason one day in the future, then use MUST and write a new I-D sometime in the future. A > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: 17 August 2012 19:02 > To: adrian@olddog.co.uk > Cc: Kireeti Kompella; draft-ietf-mpls-entropy-label@tools.ietf.org; mpls@ietf.org > Subject: Re: AD review of draft-ietf-mpls-entropy-label > > On Aug 16, 2012, at 23:43 , Adrian Farrel wrote: > > > So... > > OLD > > X SHOULD put the same TTL and TC fields for the ELI as > > it does for TL. > > NEW > > X SHOULD put the same TTL and TC fields for the ELI as > > it does for TL to protect LSP behavior in cases where PHP is used > > and the ELI and EL are not stripped at the previous hop (see Section > > 4.4). If it is known that PHP is not used or that PHP will strip the ELI > > and EL, the TTL and TC of the ELI MAY be set differently. > > END > > X will likely be blissfully unaware of whether PHP will be used (and whether the > PHP LSR will pop ELI+EL), unless this is a very short LSP. > > > ***or*** > > > > s/SHOULD/MUST/ > > I have a pathological fear of MUST. > > How about: > > NEW > X SHOULD put the same TTL and TC fields for the ELI as > it does for TL. This protects LSP behavior in cases where PHP is used > and the ELI and EL are not stripped at the penultimate hop (see Section > 4.4). > END > > I'd better get out a new version before the list of things to do gets any longer. > > Kireeti.= From internet-drafts@ietf.org Sat Aug 18 20:56: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 2794321F84C9; Sat, 18 Aug 2012 20:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 NYWAT7encYFt; Sat, 18 Aug 2012 20:56:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD06021F8494; Sat, 18 Aug 2012 20:56:53 -0700 (PDT) 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.33 Message-ID: <20120819035653.12878.87067.idtracker@ietfa.amsl.com> Date: Sat, 18 Aug 2012 20:56:53 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-ip-pw-capability-02.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, 19 Aug 2012 03:56:54 -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 : Disabling IPoMPLS and P2P PW LDP Applications Author(s) : Kamran Raza Sami Boutros Filename : draft-ietf-mpls-ldp-ip-pw-capability-02.txt Pages : 12 Date : 2012-08-18 Abstract: Currently, no LDP capability is exchanged for LDP applications like IP label switching and L2VPN P2P PW signaling. When an LDP session comes up, an LDP speaker may unnecessarily advertise its local state for such LDP applications even when the peer session may be established for some other applications like ICCP. This document proposes a solution by which an LDP speaker announces its disinterest in such non-negotiated application. This, in turn, disables the advertisement of corresponding application state, which would have otherwise be advertised by default, over the established LDP session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ip-pw-capability There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-ip-pw-capability-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-ldp-ip-pw-capability-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From skraza@cisco.com Sat Aug 18 21:30: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 5681E21F848F for ; Sat, 18 Aug 2012 21:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.215 X-Spam-Level: X-Spam-Status: No, score=-10.215 tagged_above=-999 required=5 tests=[AWL=0.384, 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 zUs5XsuFpXyX for ; Sat, 18 Aug 2012 21:30:43 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2E66C21F8467 for ; Sat, 18 Aug 2012 21:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=skraza@cisco.com; l=2052; q=dns/txt; s=iport; t=1345350643; x=1346560243; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=dInv1G2Nif1d34b7jLw6UkQ/DbOZX05ofhnoXFWxvZc=; b=P0crq4o3lO3nubkQUocTHHhMcpVYPCxIz87ENaTdeoM+afwIrfFduEZ3 2gG2kiVaqhCfc+Cji5zYddExtT0EO2EZWhjjQ1R8gf+fs3KhUsROiA/XA Xg1XklJcb76GZQmviw8rleKh94WUhMaT+ZagxqQ0FN0iiHqcG10Jx85m9 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAIdqMFCtJV2b/2dsb2JhbABFukCBB4IiAQQBAQEPASc0CxIBCDY3CyUCBA4FCRIHh2sLmR2fDpIdA5VQgRSNGIFmgmE X-IronPort-AV: E=Sophos;i="4.77,792,1336348800"; d="scan'208";a="113079182" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 19 Aug 2012 04:30:42 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7J4UgXu007779 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 19 Aug 2012 04:30:42 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.113]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0298.004; Sat, 18 Aug 2012 23:30:42 -0500 From: "Kamran Raza (skraza)" To: "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-ldp-ip-pw-capability-02.txt Thread-Index: AQHNfb7Hrss5DpENfUau+XNlhf5BPZdgnHUA Date: Sun, 19 Aug 2012 04:30:42 +0000 Message-ID: In-Reply-To: <20120819035653.12878.87067.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.86.249.176] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19124.001 x-tm-as-result: No--30.846400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <22F835677A051F4DB72789FD55AE0AD4@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Sami Boutros \(sboutros\)" Subject: Re: [mpls] I-D Action: draft-ietf-mpls-ldp-ip-pw-capability-02.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, 19 Aug 2012 04:30:44 -0000 Hello WG, The latest rev of our draft makes substantial changes from its previous rev.=20 As this draft is approaching WG LC, we request you to review and provide any feedback on this latest rev. Regards, -- Kamran and Sami On 12-08-18 11:56 PM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Multiprotocol Label Switching Working >Group of the IETF. > > Title : Disabling IPoMPLS and P2P PW LDP Applications > Author(s) : Kamran Raza > Sami Boutros > Filename : draft-ietf-mpls-ldp-ip-pw-capability-02.txt > Pages : 12 > Date : 2012-08-18 > >Abstract: > Currently, no LDP capability is exchanged for LDP applications like > IP label switching and L2VPN P2P PW signaling. When an LDP session > comes up, an LDP speaker may unnecessarily advertise its local state > for such LDP applications even when the peer session may be > established for some other applications like ICCP. This document > proposes a solution by which an LDP speaker announces its disinterest > in such non-negotiated application. This, in turn, disables the > advertisement of corresponding application state, which would have > otherwise be advertised by default, over the established LDP session. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ip-pw-capability > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-mpls-ldp-ip-pw-capability-02 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-ldp-ip-pw-capability-02 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From jcucchiara@mindspring.com Sun Aug 19 06:42: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 3910721F8459; Sun, 19 Aug 2012 06:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, STOX_REPLY_TYPE=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 IXcQRCEFeNxv; Sun, 19 Aug 2012 06:42:51 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id CA42B21F8458; Sun, 19 Aug 2012 06:42:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=cDXM7cc3YYfbflwXcipJWlGxWrVoPoANhv0A8CywCuIcLDraq0l1VNjhr8oAEOdP; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.69.138] (helo=JoanPC) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1T35mD-0002ma-JC; Sun, 19 Aug 2012 09:42:49 -0400 Message-ID: <04c801cd7e10$3c45b430$6801a8c0@JoanPC> From: "Joan Cucchiara" To: "Sam Aldrin" , "Venkatesan Mahalingam" References: <056101cd6354$c9deb1b0$6801a8c0@JoanPC> <5257BD19-4A53-4767-9BAB-6C2AB2032846@lucidvision.com> <026f01cd7c9c$b7224030$6801a8c0@JoanPC> <02c601cd7cb8$06037910$6801a8c0@JoanPC> <2E7490DB-3DE7-42C8-8E43-7378A76C2B4C@gmail.com> Date: Sun, 19 Aug 2012 09:40:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e26545b6e7e11005fc7b4ace4b1fb2318649910ec827ca34601a1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.69.138 Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, Sam Aldrin , "MIB Doctors \(E-mail\)" Subject: Re: [mpls] draft-ietf-mpls-tp-te-mib-04.txt review request 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, 19 Aug 2012 13:42:52 -0000 > Hi Joan, > > The issue boils down to the range value specified in the DESCRIPTION. > If that is removed, does that resolve the concern you raised? Sam, I think that depends on how the new DESCRIPTION clause is worded. This DESCRIPTION was brought up as a MAJOR concern and the authors agreed to reword it for 04, but that was not done. Please see inline below. > Do not think we are restricting not to use '0' in anyway or redefining the > semantics. > > As the value is local and the intention is to help implementor of the MIB > to > choose right value, without conflicting with TE tunnel index, we added > that > range. If implementor chooses to use different value altogether, it is > perfectly OK as long as it is in the range of mplsExtendedTunnelId > definition. So why was the above (extremely helpful) information not included as part of the DESCRIPTION clause? The object is: mplsTunnelExtNodeConfigLocalId OBJECT-TYPE SYNTAX MplsExtendedTunnelId MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object is used in accommodating the bigger size Global_Node_ID and/or ICC with lower size LSR identifier in order to index the mplsTunnelTable. The Local Identifier is configured between 1 and 16777215, as valid IP address range starts from 16777216(01.00.00.00). This range is chosen to identify the mplsTunnelTable's Ingress/Egress LSR-id is IP address or Local identifier, if the configured range is not IP address, administrator is expected to retrieve the complete information (Global_Node_ID or ICC) from mplsTunnelExtNodeConfigTable. This way, existing mplsTunnelTable is reused for bidirectional tunnel extensions for MPLS based transport networks. This Local Identifier allows the administrator to assign a unique identifier to map Global_Node_ID and/or ICC." ::= { mplsTunnelExtNodeConfigEntry 1 } No where in the DESCRIPTION does it say this is a "hint" to the operator (you say implementor, but think you mean the operator, i.e. the person that configures this MIB table.) > W.r.t legacy implementation, it is unto the implementor to assign the > right > index value to TP tunnel, if it conflicts with TE tunnel index. Yes, but the draft says in Section 9. "Do note that a MPLS-TP tunnel could be setup statically as well as signaled via control plane." so if the tunnel is signaled, then what happens? Are there entries created in these tables by the local management subsystem (e.g. agent) when the MPLS TP tunnel is signaled successfully OR are entries entirely dependent on an operator for configuration? As far as I can tell, the MIB does not support signaled TP tunnels, is this correct? If so, that needs to be clearly stated, particularly in the Abstract. If I am wrong and it does support signaled TP Tunnels then, how does that work with mapping tables? While there is an example for statically configured tunnels, I don't see one for Signaled TP Tunnels. > The example provided could give guidance on what value to use, but will > not > MANDATE the usage. > > In regards to implementing a new table, we have deliberated extensively > among authors and also with implementors. Adding new MIB or table is not > really efficient. Infact, there are already implementations which were > able > to support the legacy model as well as new TP tunnels. Unless there is a > compelling reason that MPLS TP tunnel table should have its own table, > which > essentially duplicated all of the objects, I am not for that model. If > others in WG feels the need, they can speak up. I'd like to see the new DESCRIPTION clause and understand about MPLS TP signaled tunnels wrt to this draft, prior to delving into the above (and other issues). Thanks, -Joan On Aug 17, 2012, at 1:51 PM, Venkatesan Mahalingam wrote: > ++ MPLS WG & MIB Drs. > > Thanks, > Venkat. > > On Fri, Aug 17, 2012 at 1:36 PM, Joan Cucchiara > wrote: >> Venkat, >> >> The SMIv2 specifies that once a TC is defined, then the definition cannot >> change in the way being >> proposed by the draft-ietf-mpls-tp-te-mib-04. >> >> From RFC2579: >> 3.3. Mapping of the DESCRIPTION clause >> The DESCRIPTION clause, which must be present, contains a textual >> definition of the textual convention, which provides all semantic >> definitions necessary for implementation, and should embody any >> information which would otherwise be communicated in any ASN.1 >> commentary annotations associated with the object. >> >> >> My concern is that MPLS-TC-STD-MIB defines MplsExtendedTunnelId and this >> draft is changing that original definition. >> If RFC3811 does not contain "all semantic definitions necessary for >> implementation" then the problem is to update RFC3811 >> and maybe other associated RFCs as needed, not to propose additional >> semantics in draft-ietf-mpls-tp-te-mib. >> >> The draft is proposing to bifurcate the values and also not use zero for >> the >> MplsExtendedTunnelId, that is not the original >> definition of MplsExtendedTunnelId, so why is this draft using >> MplsExtendedTunnelId? >> >> Please include the MIB Dr's on your email because this is a MIB concern >> and >> one which I've had since >> before this draft was adopted as a WG document. >> >> The options are (as I see them): >> 1) create a specific MPLS TP table for TP Tunnels (which was originally >> proposed by Adrian Farrel) >> 2) update RFC3811 to accurately reflect MplsExtendedTunnelId and other >> RFCs >> which utilize this TC. >> 3) ?? >> >> Thanks, >> -Joan >> >> >> ----- Original Message ----- From: "Venkatesan Mahalingam" >> >> To: "Joan Cucchiara" >> Cc: "Thomas Nadeau" ; "Sam Aldrin" >> ; "Kannan KV Sampath" >> Sent: Friday, August 17, 2012 2:39 PM >> >> Subject: Re: draft-ietf-mpls-tp-te-mib-04.txt review request >> >> >>> Joan, >>> >>> Thanks for your response. Appreciate your time for reviewing this >>> draft. Please find below my response tagged [VM]. >>> >>> However, I looked over the doc and wanted to let you know that I still >>> have >>>> >>>> the same issue wrt to both SYNTAX and semantic >>>> redefinition as before. You cannot narrow the range of values in a >>>> DESCRIPTION clause which I see happens in >>>> mplsTunnelExtNodeConfigLocalId >>>> and maybe in MplsNodeId TC as it says zero must not be used, but then >>>> you >>>> have it as part of allowable values in the SYNTAX. >>> >>> [VM] If MplsExtendedTunnelId allows zero as the valid value, I don't >>> see any issue to allow zero as the valid value for MplsNodeId. >>> >>>> Additionally, the SYNTAX below for MplsExtendedTunnelId allows any >>>> Unsigned32 and says "may represent an IPv4 address". If (for >>>> whatever >>>> reason) an >>>> operator has configured something in the 1..16777216 (i.e. Local Id) >>>> range, >>>> for a regular TE Tunnel, that is perfectly legal, right? >>> >>> [VM] I don't see any implementation which allows non-IP TE tunnel >>> source/destination in the range 1..16777216 in MPLS domain, >>> if you are not still convinced, we can poll in MPLS WG list to get the >>> operators' opinion on this. >>> >>>> If the answer is Yes, then how would you add TP Tunnels using your >>>> draft >>>> if >>>> an operator has a regular MPLS TE Tunnel configured >>>> in the range 1..16777216 without having to ensure that any and all >>>> legacy >>>> equipment be queried first? >>> >>> [VM] It is expected to configure MPLS TE tunnels in IP address range >>> and MPLS-TP tunnel in NON-IP range, if the implementors have mixed >>> mode of configuration, then it is expected to clarify in the document >>> that how to use MPLS-TE & MPLS-TP tunnel configurations. >>> What you are saying is correct only if the legacy equipments use the >>> NON-IP range for MPLS TE tunnels, so, as I stated above, let's close >>> this with the MPLS WG list. >>> >>> HTH >>> >>> Thanks, >>> Venkat. >>> >>> On Fri, Aug 17, 2012 at 10:21 AM, Joan Cucchiara >>> wrote: >>>> >>>> Tom and all, >>>> >>>> Unfortunately, my linux box is giving me grief this week (and I don't >>>> have >>>> access to my MIB tools). I'm getting some assistance >>>> with it but won't be resolved until (hopefully) during the weekend. >>>> >>>> However, I looked over the doc and wanted to let you know that I still >>>> have >>>> the same issue wrt to both SYNTAX and semantic >>>> redefinition as before. You cannot narrow the range of values in a >>>> DESCRIPTION clause which I see happens in >>>> mplsTunnelExtNodeConfigLocalId >>>> and maybe in MplsNodeId TC as it says zero must not be used, but then >>>> you >>>> have it as part of allowable values in the SYNTAX. >>>> >>>> Whatever is specified in the DESCRIPTION clause for values, should be >>>> reflected by the SYNTAX, right? >>>> >>>> Additionally, the SYNTAX below for MplsExtendedTunnelId allows any >>>> Unsigned32 and says "may represent an IPv4 address". If (for >>>> whatever >>>> reason) an >>>> operator has configured something in the 1..16777216 (i.e. Local Id) >>>> range, >>>> for a regular TE Tunnel, that is perfectly legal, right? >>>> >>>> >>>> MplsExtendedTunnelId ::= TEXTUAL-CONVENTION >>>> STATUS current >>>> DESCRIPTION >>>> "A unique identifier for an MPLS Tunnel. This may >>>> represent an IPv4 address of the ingress or egress >>>> LSR for the tunnel. This value is derived from the >>>> Extended Tunnel Id in RSVP or the Ingress Router ID >>>> for CR-LDP." >>>> REFERENCE >>>> "RSVP-TE: Extensions to RSVP for LSP Tunnels, >>>> [RFC3209]. >>>> >>>> Constraint-Based LSP Setup using LDP, [RFC3212]." >>>> SYNTAX Unsigned32(0..4294967295) >>>> >>>> If the answer is Yes, then how would you add TP Tunnels using your >>>> draft >>>> if >>>> an operator has a regular MPLS TE Tunnel configured >>>> in the range 1..16777216 without having to ensure that any and all >>>> legacy >>>> equipment be queried first? >>>> >>>> Thanks, >>>> -Joan >>>> >>>> >>>> >>>> ----- Original Message ----- >>>> From: Thomas Nadeau >>>> To: Joan Cucchiara >>>> Cc: Sam Aldrin ; Venkatesan Mahalingam ; Kannan KV Sampath >>>> Sent: Thursday, August 09, 2012 8:58 AM >>>> Subject: Re: draft-ietf-mpls-tp-te-mib-04.txt review request >>>> >>>> hi Joan >>>> >>>> hope you had a great vacation! ;) >>>> >>>> can you please follow up on the note below when you have a chance? >>>> >>>> Tom >>>> >>>> >>>> >>>> On Jul 16, 2012, at 9:13 AM, "Joan Cucchiara" >>>> >>>> wrote: >>>> >>>> Sam, >>>> >>>> We are away this week returning on 7/23. Sorry, I can't review the >>>> doc >>>> until after 7/23 and it will >>>> take a few days after that as I'll just be returning from vacation. >>>> >>>> I glanced at it and see that there are read-write objects in a row >>>> (which >>>> is >>>> read-create) so that's >>>> an error which I mentioned before. >>>> >>>> Have you compiled this with smilint? >>>> >>>> Thanks, >>>> -Joan >>>> >>>> >>>> >>>> >>>> >>>> ----- Original Message ----- >>>> From: Sam Aldrin >>>> To: Joan Cucchiara >>>> Cc: Venkatesan Mahalingam ; Thomas Nadeau ; Kannan KV Sampath >>>> Sent: Friday, July 13, 2012 9:11 PM >>>> Subject: Fwd: draft-ietf-mpls-tp-te-mib-04.txt review request >>>> >>>> Hi Joan, >>>> >>>> Please find the updated MIB document. Apologize for the delay. We plan >>>> to >>>> publish the doc on Monday as it is the deadline before IETF. Diff file >>>> is >>>> attached as well. >>>> >>>> This version addresses all your comments. Highlighting couple of them >>>> to >>>> make sure you are OK with them >>>> >>>> 1. W.r.t mplsLocalID as index type, we have removed that using >>>> MplsExtendedTunnelId itself. As the value range for this object could >>>> have >>>> value of non-IP address, we are using it. This will make the indices >>>> for >>>> the >>>> same as TunnelTable. >>>> In the definition of IngressLSRId and and EgressLSRId, for TP entries, >>>> we >>>> added description to use value of non-IP address, which is local ID. >>>> >>>> I do hope this satisfies the need and not necessitate for a new table >>>> altogether for TP. >>>> >>>> 2. In regards to adding references to TC conventions. We believe, those >>>> were >>>> added in the reference section. IF we have missed any TC references, >>>> could >>>> you kindly let us know. >>>> >>>> Appreciate if you can get back by Monday noon time PST. I know it is a >>>> very >>>> short time, but appreciate if you could do that. >>>> >>>> thanks >>>> -sam >>>> >>>> ________________________________ >>>> >>>> >> > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From skraza@cisco.com Sun Aug 19 09:03: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 63EE521F853F for ; Sun, 19 Aug 2012 09:03:38 -0700 (PDT) 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=[AWL=0.000, 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 9-l+ZAq5yd1O for ; Sun, 19 Aug 2012 09:03:37 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id BADA521F8453 for ; Sun, 19 Aug 2012 09:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=skraza@cisco.com; l=2880; q=dns/txt; s=iport; t=1345392217; x=1346601817; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Un9ImFsUk2i8LXjERqMS1b4AeG582RaZpYz++jnGgkU=; b=l1hVKM6wIdhlerTqQdSuQt5afjhNIxZ0ZnSOyJn+xjzeObda22mDrFkD r2dljB0MdKb57gYPwjfTmcI7QZb0TbBqXl2fOmTSiqkcLM5nkjk2f+lR/ UVIne8CmrvLETOSshSsdUF8EUjNI+0sbif2fU2hEFYca8u9aEl2qUUByv k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALMNMVCtJV2Z/2dsb2JhbABFuj+BB4IgAQEBBAEBAQ8BJzQLEgEIGB43CyUCBAENBQkSB4drC5g/nxqSHQOVUIEUjRiBZoJh X-IronPort-AV: E=Sophos;i="4.77,794,1336348800"; d="scan'208";a="113117257" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 19 Aug 2012 16:03:37 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7JG3b7N025214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 19 Aug 2012 16:03:37 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.113]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0298.004; Sun, 19 Aug 2012 11:03:36 -0500 From: "Kamran Raza (skraza)" To: "Kamran Raza (skraza)" , "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-ldp-ip-pw-capability-02.txt Thread-Index: AQHNfb7Hrss5DpENfUau+XNlhf5BPZdgnHUAgADBewA= Date: Sun, 19 Aug 2012 16:03:36 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.86.248.163] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19124.006 x-tm-as-result: No--40.858100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <914A574653739949A13FDD58407451D8@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Sami Boutros \(sboutros\)" Subject: Re: [mpls] I-D Action: draft-ietf-mpls-ldp-ip-pw-capability-02.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, 19 Aug 2012 16:03:38 -0000 The changes in this draft are: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-ldp-ip-pw-capability-0= 2. txt - Section 4: Consolidated two separate IP and PW (disable) LDP capabilities into a "single" LDP capability. - Section 5: Rearranged/moved some of text/description from subsection to main section on Capability procedures. - Section 6.4: Added a new use case (in dual-stack environment) to section 6 (Operational Examples). - Changed the title of the doc - Terminology update and some general cleanup of doc Thanks. On 12-08-19 12:30 AM, "Kamran Raza (skraza)" wrote: >Hello WG, > >The latest rev of our draft makes substantial changes from its previous >rev.=20 >As this draft is approaching WG LC, we request you to review and provide >any feedback >on this latest rev. > >Regards, >-- Kamran and Sami > >On 12-08-18 11:56 PM, "internet-drafts@ietf.org" > wrote: > >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> This draft is a work item of the Multiprotocol Label Switching Working >>Group of the IETF. >> >> Title : Disabling IPoMPLS and P2P PW LDP Applications >> Author(s) : Kamran Raza >> Sami Boutros >> Filename : draft-ietf-mpls-ldp-ip-pw-capability-02.txt >> Pages : 12 >> Date : 2012-08-18 >> >>Abstract: >> Currently, no LDP capability is exchanged for LDP applications like >> IP label switching and L2VPN P2P PW signaling. When an LDP session >> comes up, an LDP speaker may unnecessarily advertise its local state >> for such LDP applications even when the peer session may be >> established for some other applications like ICCP. This document >> proposes a solution by which an LDP speaker announces its disinterest >> in such non-negotiated application. This, in turn, disables the >> advertisement of corresponding application state, which would have >> otherwise be advertised by default, over the established LDP session. >> >> >>The IETF datatracker status page for this draft is: >>https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ip-pw-capability >> >>There's also a htmlized version available at: >>http://tools.ietf.org/html/draft-ietf-mpls-ldp-ip-pw-capability-02 >> >>A diff from the previous version is available at: >>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-ldp-ip-pw-capability-0= 2 >> >> >>Internet-Drafts are also available by anonymous FTP at: >>ftp://ftp.ietf.org/internet-drafts/ >> >>_______________________________________________ >>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 lizhong.jin@zte.com.cn Sun Aug 19 17:55: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 EBD1121F863C for ; Sun, 19 Aug 2012 17:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.588 X-Spam-Level: X-Spam-Status: No, score=-101.588 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, 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 DVYrqQzrUoPx for ; Sun, 19 Aug 2012 17:55:39 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 80C0421F863B for ; Sun, 19 Aug 2012 17:55:38 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 23255806486374; Mon, 20 Aug 2012 08:49:50 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 4936.1922239162; Mon, 20 Aug 2012 08:55:37 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q7K0tMRm092637; Mon, 20 Aug 2012 08:55:22 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: kvivek@broadcom.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Mon, 20 Aug 2012 08:55:21 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-20 08:55:22, Serialize complete at 2012-08-20 08:55:22 Content-Type: multipart/alternative; boundary="=_alternative 0005113748257A60_=" X-MAIL: mse02.zte.com.cn q7K0tMRm092637 Cc: mpls@ietf.org Subject: Re: [mpls] Question regarding MPLS reserved label with ECMP 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, 20 Aug 2012 00:55:40 -0000 This is a multipart message in MIME format. --=_alternative 0005113748257A60_= Content-Type: text/plain; charset="US-ASCII" > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 18 Aug 2012 11:45:00 +0000 > From: "Vivek Kumar" > To: "mpls@ietf.org" > Subject: [mpls] Question regarding MPLS reserved label with ECMP > Message-ID: > <3C086BA39C55B9418AE8FEA3F3EFDEC408291E@SJEXCHMB09.corp.ad.broadcom.com> > > Content-Type: text/plain; charset=us-ascii > > Hi , > I have one question regarding whether MPLS reserved label should > be used or skipped when Transit LSR is doing hashing on full label > stack which has some reserved label. > > RFC 6391 , section 7 , says " Note that, depending on the number > of labels hashed by the LSR, the > inclusion of the Router Alert label may cause the OAM packet to be > load-balanced to a different path from that taken by the data packets > with identical flow and PW labels". > > The above comment implies that reserved label is used by LSR when > doing hashing for ECMP. [Lizhong] Since inclusion will cause problem, I will interpret the above as an implication of hashing without reserved label. Lizhong > > Is there any other RFC which states what should be the correct behavior. > > The draft " draft-ietf-mpls-entropy-label-05" section 4.3 , says > reserved label should not be used by LSR when doing hashing on label stack. > > > Regards, > Vivek > --=_alternative 0005113748257A60_= Content-Type: text/html; charset="US-ASCII"
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 18 Aug 2012 11:45:00 +0000
> From: "Vivek Kumar" <kvivek@broadcom.com>
> To: "mpls@ietf.org" <mpls@ietf.org>
> Subject: [mpls] Question regarding MPLS reserved label with ECMP
> Message-ID:
>    <3C086BA39C55B9418AE8FEA3F3EFDEC408291E@SJEXCHMB09.corp.ad.broadcom.com>
>    
> Content-Type: text/plain; charset=us-ascii
>
> Hi ,
>   I have one question regarding whether MPLS reserved label should
> be used or skipped when Transit LSR is doing hashing on full label
> stack which has some reserved label.
>
>    RFC 6391 , section 7 , says " Note that, depending on the number
> of labels hashed by the LSR, the
>    inclusion of the Router Alert label may cause the OAM packet to be
>    load-balanced to a different path from that taken by the data packets
>    with identical flow and PW labels".
>
>   The above comment implies that reserved label is used by LSR when
> doing hashing for ECMP.
[Lizhong] Since inclusion will cause problem, I will interpret the above as an implication of hashing without reserved label.

Lizhong

>
>   Is there any other RFC which states what should be the correct behavior.
>    
>   The draft " draft-ietf-mpls-entropy-label-05" section 4.3 , says
> reserved label should not be used by LSR when doing hashing on label stack.
>  
>
> Regards,
> Vivek
> --=_alternative 0005113748257A60_=-- From kvivek@broadcom.com Sun Aug 19 20:49: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 DE89021F856D for ; Sun, 19 Aug 2012 20:49:23 -0700 (PDT) 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, 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 JIZcnuFpuYof for ; Sun, 19 Aug 2012 20:49:23 -0700 (PDT) Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 38DFF21F8564 for ; Sun, 19 Aug 2012 20:49:23 -0700 (PDT) Received: from [10.16.192.232] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Sun, 19 Aug 2012 20:47:12 -0700 X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF Received: from SJEXCHCAS02.corp.ad.broadcom.com (10.16.192.37) by SJEXCHHUB02.corp.ad.broadcom.com (10.16.192.232) with Microsoft SMTP Server (TLS) id 8.2.247.2; Sun, 19 Aug 2012 20:49:05 -0700 Received: from SJEXCHMB09.corp.ad.broadcom.com ( [fe80::3da7:665e:cc78:181f]) by sjexchcas02.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Sun, 19 Aug 2012 20:48:45 -0700 From: "Vivek Kumar" To: "Lizhong Jin" Thread-Topic: [mpls] Question regarding MPLS reserved label with ECMP Thread-Index: AQHNfm6H9s1eeGl34kenU72R5DoY7ZdiECkw Date: Mon, 20 Aug 2012 03:48:44 +0000 Message-ID: <3C086BA39C55B9418AE8FEA3F3EFDEC40849E0@SJEXCHMB09.corp.ad.broadcom.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.75.111] MIME-Version: 1.0 X-WSS-ID: 7C2F6CCA49821290597-01-01 Content-Type: multipart/alternative; boundary=_000_3C086BA39C55B9418AE8FEA3F3EFDEC40849E0SJEXCHMB09corpadb_ Cc: "mpls@ietf.org" Subject: Re: [mpls] Question regarding MPLS reserved label with ECMP 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, 20 Aug 2012 03:49:24 -0000 --_000_3C086BA39C55B9418AE8FEA3F3EFDEC40849E0SJEXCHMB09corpadb_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Lizhong, Thanks. I think that states what should be correct behavior . Regards, Vivek From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] Sent: Monday, August 20, 2012 6:25 AM To: Vivek Kumar Cc: mpls@ietf.org Subject: Re: [mpls] Question regarding MPLS reserved label with ECMP > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 18 Aug 2012 11:45:00 +0000 > From: "Vivek Kumar" > To: "mpls@ietf.org" > Subject: [mpls] Question regarding MPLS reserved label with ECMP > Message-ID: > <3C086BA39C55B9418AE8FEA3F3EFDEC408291E@SJEXCHMB09.corp.ad.broadcom.co= m> > > Content-Type: text/plain; charset=3Dus-ascii > > Hi , > I have one question regarding whether MPLS reserved label should > be used or skipped when Transit LSR is doing hashing on full label > stack which has some reserved label. > > RFC 6391 , section 7 , says " Note that, depending on the number > of labels hashed by the LSR, the > inclusion of the Router Alert label may cause the OAM packet to be > load-balanced to a different path from that taken by the data packets > with identical flow and PW labels". > > The above comment implies that reserved label is used by LSR when > doing hashing for ECMP. [Lizhong] Since inclusion will cause problem, I will interpret the above as= an implication of hashing without reserved label. Lizhong > > Is there any other RFC which states what should be the correct behavior= . > > The draft " draft-ietf-mpls-entropy-label-05" section 4.3 , says > reserved label should not be used by LSR when doing hashing on label stac= k. > > > Regards, > Vivek > --_000_3C086BA39C55B9418AE8FEA3F3EFDEC40849E0SJEXCHMB09corpadb_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Hi Lizhong,

  Thanks. I think th= at states what should be correct behavior .

 <= /p>

Regards,

Vivek

 <= /p>

From: Lizhong = Jin [mailto:lizhong.jin@zte.com.cn]
Sent: Monday, August 20, 2012 6:25 AM
To: Vivek Kumar
Cc: mpls@ietf.org
Subject: Re: [mpls] Question regarding MPLS reserved label with ECMP=

 


> -----------------------------------------------------------= -----------
>
> Message: 1
> Date: Sat, 18 Aug 2012 11:45:00 +0000
> From: "Vivek Kumar" <kvivek@broadcom.com>
> To: "mpls@ietf.org" <mpls@ietf.org>
> Subject: [mpls] Question regarding MPLS reserved label with ECMP
> Message-ID:
>    <3C086BA39C55B9418AE8FEA3F3EFDEC408291E@SJEXCHMB09.cor= p.ad.broadcom.com>
>    
> Content-Type: text/plain; charset=3Dus-ascii
>
> Hi ,
>   I have one question regarding whether MPLS reserved label shoul= d
> be used or skipped when Transit LSR is doing hashing on full label > stack which has some reserved label.
>
>    RFC 6391 , section 7 , says " Note that, depending o= n the number
> of labels hashed by the LSR, the
>    inclusion of the Router Alert label may cause the OAM pac= ket to be
>    load-balanced to a different path from that taken by the = data packets
>    with identical flow and PW labels".
>
>   The above comment implies that reserved label is used by LSR wh= en
> doing hashing for ECMP.
[Lizhong] Since inclusion will cause problem, I will interpret t= he above as an implication of hashing without reserved label.

Lizhong

>
>   Is there any other RFC which states what should be the correct = behavior.
>    
>   The draft " draft-ietf-mpls-entropy-label-05" section= 4.3 , says
> reserved label should not be used by LSR when doing hashing on label s= tack.
>  
>
> Regards,
> Vivek
>

--_000_3C086BA39C55B9418AE8FEA3F3EFDEC40849E0SJEXCHMB09corpadb_-- From daniele.ceccarelli@ericsson.com Mon Aug 20 01:11: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 83B1721F86A2 for ; Mon, 20 Aug 2012 01:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=2.775, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 VeWI3rqgzHf5 for ; Mon, 20 Aug 2012 01:11:00 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B562E21F86A1 for ; Mon, 20 Aug 2012 01:10:59 -0700 (PDT) X-AuditID: c1b4fb2d-b7fd66d0000004ad-ae-5031f1112fec Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C1.FA.01197.111F1305; Mon, 20 Aug 2012 10:10:58 +0200 (CEST) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.2.59]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Mon, 20 Aug 2012 10:10:57 +0200 From: Daniele Ceccarelli To: "mpls-chairs@tools.ietf.org" Date: Mon, 20 Aug 2012 10:10:57 +0200 Thread-Topic: draft-ietf-mpls-tp-ring-protection Thread-Index: Ac1+q1OjqynWmaW5R2Sn7VBlh8mTCg== Message-ID: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: it-IT, en-US Content-Type: multipart/alternative; boundary="_000_B5630A95D803744A81C51AD4040A6DAA23CFBA99CEESESSCMS0360e_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvra7QR8MAgwv/GS2+X1rCYnFr6UpW ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugSvj/7PNrAWruCtaDgc2MN7n7GLk5JAQMJFY f76HEcIWk7hwbz1bFyMXh5DAKUaJu98Os0M4cxgl+uafYOpi5OBgE7CSeHLIB8QUEbCVaL5s C2IyCyhLnLorAzKGRUBVYu6h32wgtrCAtsT91/dZQWwRAQOJTx8OsEPYehLfG5aDxXkFwiXe vJ7IDGIzCshKTNi9COwcZgFxiVtP5jNBnCYgsWTPeWYIW1Ti5eN/rBD1MhK/Nn1jhajPl3i2 ajMbxExBiZMzn7BMYBSehWTULCRls5CUQcR1JBbs/sQGYWtLLFv4mhnGPnPgMROy+AJG9lWM wrmJmTnp5YZ6qUWZycXF+Xl6xambGIFRc3DLb90djKfOiRxilOZgURLn5Ura7y8kkJ5Ykpqd mlqQWhRfVJqTWnyIkYmDU6qB0br/pnD83bLosOqn/KrJLAoPrAKMQkO8N8l+N1TewpZXaXOq ZvXluffFLhwWv2tm9vx0vfkHz2DOgtMPGerzG4QCMlKsXI86PNewOx5R8+ljufTJHOF9m562 bOVYJWpwKXjZvwqmLIG/RT/Mwyas3XDsQV3LlQ+feQOdpOMXshxjvP+OudxXiaU4I9FQi7mo OBEAquElGGgCAAA= Cc: "mpls@ietf.org" Subject: [mpls] draft-ietf-mpls-tp-ring-protection 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, 20 Aug 2012 08:11:01 -0000 --_000_B5630A95D803744A81C51AD4040A6DAA23CFBA99CEESESSCMS0360e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear MPLS chairs, The ring protection draft has been presented at the last IETF meeting and o= nce again comments have been requested. Since there are none the authors co= nsider the draft ready for last call. BR The authors --_000_B5630A95D803744A81C51AD4040A6DAA23CFBA99CEESESSCMS0360e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear MPLS chairs,
 
The ring protection draft has been presented at the last IETF meeting = and once again comments have been requested. Since there are none the autho= rs consider the draft ready for last call.
 
BR
The authors
 
 
  --_000_B5630A95D803744A81C51AD4040A6DAA23CFBA99CEESESSCMS0360e_-- From zhang.fei3@zte.com.cn Mon Aug 20 04:02: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 051D021F84F7; Mon, 20 Aug 2012 04:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.226 X-Spam-Level: X-Spam-Status: No, score=-97.226 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, 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 VHhZMaLDL8jB; Mon, 20 Aug 2012 04:02:52 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id DA85B21F8585; Mon, 20 Aug 2012 04:02:51 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 107231784411434; Mon, 20 Aug 2012 18:47:59 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 3262.6577259554; Mon, 20 Aug 2012 19:02:44 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q7KB2fRf046175; Mon, 20 Aug 2012 19:02:41 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: To: Gregory Mirsky MIME-Version: 1.0 X-KeepSent: 996FE7AF:A73C1846-48257A60:003C3159; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Mon, 20 Aug 2012 19:02:41 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-20 19:02:43, Serialize complete at 2012-08-20 19:02:43 Content-Type: multipart/alternative; boundary="=_alternative 003C996748257A60_=" X-MAIL: mse02.zte.com.cn q7KB2fRf046175 Cc: "mpls@ietf.org" , mpls-bounces@ietf.org Subject: Re: [mpls] Comments on draft-weingarten-mpls-smp-requirements-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, 20 Aug 2012 11:02:54 -0000 This is a multipart message in MIME format. --=_alternative 003C996748257A60_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 R3JlZywgc25pcHBlZA0KDQpJbiB0aGUgbGFzdCBzZW50ZW5jZSBvZiBTZWN0aW9uIDMuMSBub24t Y29udHJvbCBwbGFuZSBjb29yZGluYXRpb24gb2YgDQpzaGFyZWQgcmVzb3VyY2VzIHByZXNlbnRl ZCBhcyBhbm90aGVyIHJlcXVpcmVtZW50LiBBbmQgYWdhaW4gSSBjYW4gbm90IA0KZmluZCBob3cg d2UgY29tZSB0byBzdWNoIGNvbmNsdXNpb24sIHdoZXJlIHRoZSBzb3VyY2Ugb2YgdGhpcyByZXF1 aXJlbWVudC4gDQpXb3VsZCBleGlzdGluZyBjb250cm9sIHBsYW5lIHNpZ25hbGluZyBzb2x1dGlv biBiZSBzdWZmaWNpZW50IGZvciBhIE1QTFMgDQpuZXR3b3JrPyANCg0KPEZlaT4gSSBkbyBub3Qg dGhpbmsgdGhlIGV4aXN0aW5nIGNvbnRyb2wgcGxhbmUgKGRlZmluZWQgaW4gUkZDNDg3MikgaXMg DQpzdWZmaWNpZW50IGZvciBhIE1QTFMgbmV0d29yaywgYW5kIHRoZXJlIGlzIGFuIGFuYWx5c2lz IGluIHRoZSBkcmFmdCANCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhlLWNjYW1w LW5vdGlmaWNhdGlvbi1zaGFyZWQtbWVzaC1wcm90ZWN0aW9uLTAwLiANCg0KDQoNCkJlc3QgcmVn YXJkcw0KDQpGZWkNCg0KDQoNCg0KR3JlZ29yeSBNaXJza3kgPGdyZWdvcnkubWlyc2t5QGVyaWNz c29uLmNvbT4gDQq3orz+yMs6ICBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTItMDgtMTYgMDY6 NDUNCg0KytW8/sjLDQpQYWJsbyBGcmFuayA8cGFibG9pc25vdEBnbWFpbC5jb20+LCBZYWFjb3Yg V2VpbmdhcnRlbiA8d3lhYWNvdkBnbWFpbC5jb20+DQqzrcvNDQoibXBsc0BpZXRmLm9yZyIgPG1w bHNAaWV0Zi5vcmc+DQrW98ziDQpSZTogW21wbHNdIENvbW1lbnRzIG9uIGRyYWZ0LXdlaW5nYXJ0 ZW4tbXBscy1zbXAtcmVxdWlyZW1lbnRzLTAwLnR4dA0KDQoNCg0KDQoNCg0KRGVhciBQYWJsbywg WWFhY292LCBldCBhbC4sDQpJJ3ZlIGJlZW4gZm9sbG93aW5nIGRpc2N1c3Npb24gd2l0aCBncmVh dCBkZWFsIG9mIGludGVyZXN0LiBJIGhhdmUgc29tZSANCnF1ZXN0aW9ucyBpbiBhZGRpdGlvbiB0 byBvbmVzIGJlaW5nIGJyb3VnaHQgdXAgYnkgUGFibG86DQpTZWN0aW9uIDEuMiByZWZlcnMgdG8g b3BlcmF0b3IncyBkZXNpcmUgdG8gaGF2ZSBzZXJ2aWNlIHJlc3RvcmF0aW9uIG1vcmUgDQpleHBl ZGllbnQgdGhhbiBvbmUgYWNoaWV2YWJsZSB3aXRoIGNvbnRyb2wgcGxhbmUuIEkgaGF2ZW4ndCBz ZWVuIGFueSANCnF1YW50YXRpdmUgaW5mb3JtYXRpb24gdG8gY29tcGFyZSB3aXRoLiBXaGF0IGlz ICJleHBlZGllbnQgZW5vdWdoIiBmb3IgDQpTTVA/DQpTZWN0aW9uIDMuMSBkZXNyY2liZXMsIHdo YXQgY2FuIGJlIGNhbGxlZCwgImluc3RhbnQgZGV0ZXJtaW5pc20iIGluIHJlZ2FyZCANCnRvIFNN UCByZXNvdXJjZSBhdmFpYWxhYmlsaXR5LiBJIHRoaW5rIHRoYXQgdGhlcmUncyBub3QgZW5vdWdo IHJlYXNvbmluZyANCnRvIGNvbmNsdWRlIHRoYXQgYWxtb3N0IGluc3RhbnRlbmVvdXMgdXBkYXRl IG9mIFNNUCByZXNvdXJjZXMgDQphdmFpYWxhYmlsaXR5IGlzIHJlcXVpcmVkLg0KSW4gdGhlIGxh c3Qgc2VudGVuY2Ugb2YgU2VjdGlvbiAzLjEgbm9uLWNvbnRyb2wgcGxhbmUgY29vcmRpbmF0aW9u IG9mIA0Kc2hhcmVkIHJlc291cmNlcyBwcmVzZW50ZWQgYXMgYW5vdGhlciByZXF1aXJlbWVudC4g QW5kIGFnYWluIEkgY2FuIG5vdCANCmZpbmQgaG93IHdlIGNvbWUgdG8gc3VjaCBjb25jbHVzaW9u LCB3aGVyZSB0aGUgc291cmNlIG9mIHRoaXMgcmVxdWlyZW1lbnQuIA0KV291bGQgZXhpc3Rpbmcg Y29udHJvbCBwbGFuZSBzaWduYWxpbmcgc29sdXRpb24gYmUgc3VmZmljaWVudCBmb3IgYSBNUExT IA0KbmV0d29yaz8NCkkndmUgbm90aWNlZCB0aGF0IG1hbnkgcmVxdWlyZW1lbnRzIGJlaW5nIHJl ZmVycmVkIHRvIE1QTFMtVFAsIG5vdCBNUExTLCANCm5ldHdvcmtzLiBXb3VsZCB0aGF0IGJlIGEg Z29vZCByZWFzb24gdG8gbmFycm93IHNjb3BlIG9mIHRoZSBkb2N1bWVudCB0byANCk1QTFMtVFAg bmV0d29ya3Mgb25seSwgc3RhcnRpbmcgd2l0aCB0aGUgbmFtZSBvZiB0aGUgZG9jdW1lbnQ/DQog ICAgUmVnYXJkcywNCiAgICAgICAgR3JlZw0KDQpGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiANClBhYmxvIEZyYW5r DQpTZW50OiBGcmlkYXksIEF1Z3VzdCAxMCwgMjAxMiA3OjIzIEFNDQpUbzogWWFhY292IFdlaW5n YXJ0ZW4NCkNjOiBtcGxzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21wbHNdIENvbW1lbnRzIG9u IA0KZHJhZnQtd2VpbmdhcnRlbi1tcGxzLXNtcC1yZXF1aXJlbWVudHMtMDAudHh0DQoNCkhpIFlh YWNvdiwgDQoNClNvbWUgbW9yZSBjb21tZW50cyBpbmxpbmUuLi4gUEY+Pg0KDQpPbiBNb24sIEF1 ZyA2LCAyMDEyIGF0IDg6NTYgQU0sIFlhYWNvdiBXZWluZ2FydGVuIDx3eWFhY292QGdtYWlsLmNv bT4gDQp3cm90ZToNCkhpLCANCg0KVGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnRzLiAgUGxlYXNl IHNlZSBteSBjb21tZW50cyBpbmxpbmUgYmVsb3cuDQoNCkJSLA0KeWFhY292DQoNCk9uIFR1ZSwg SnVsIDE3LCAyMDEyIGF0IDExOjUxIFBNLCBQYWJsbyBGcmFuayA8cGFibG9pc25vdEBnbWFpbC5j b20+IA0Kd3JvdGU6DQpHb29kIGRyYWZ0IGFuZCBjZXJ0YWlubHkgc29tZXRoaW5nIHRoYXQgbmVl ZHMgdG8gYmUgZG9uZSBiZWZvcmUgd2UgY2FuIA0Kc3RhcnQgZGlzY3Vzc2luZyBzcGVjaWZpYyBz b2x1dGlvbnMuIA0KDQpPbmx5IGEgZmV3IGNvbW1lbnRzIC8gcXVlc3Rpb25zOg0KDQotIEluIDQu MS4xLCBpZiBvbmUgaXMgb3BlcmF0aW5nIGluIGFuIE1QTFMtVFAgbmV0d29yayB0aGF0IHJlcXVp cmVzIA0KZXhjbHVzaXZlIHVzZSBvZiB0aGUgcHJvdGVjdGlvbiByZXNvdXJjZXMsIGRvZXNuJ3Qg dGhpcyBTSE9VTEQgcmVxdWlyZW1lbnQgDQpiZWNvbWUgYSBNVVNUIHJlcXVpcmVtZW50Pw0KDQp5 dz4+IFNvcnJ5IC0gYnV0IGNvdWxkIHlvdSBleHBsYWluIG1vcmUgZnVsbHkgdGhpcyBjb21tZW50 Lg0KDQpQRj4+ICBJZiB5b3UncmUgdHJ5aW5nIHRvIG1lZXQgUkZDIDU2NTQgcmVxIDU4YiBpbiBw YXJ0aWN1bGFyLCBJIHdvdWxkIA0KdGhpbmsgeW91IE1VU1QgdmFsaWRhdGUgdGhhdCBlbm91Z2gg cHJvdGVjdGlvbiByZXNvdXJjZXMgYXJlIGF2YWlsYWJsZSAob3IgDQphcmUgcHJlZW1wdGlibGUp IHRvIGNhcnJ5IDEwMCUgb2YgdGhlIHNlcnZpY2UgdHJhZmZpYyB0aGF0IGlzIGJlaW5nIA0KcmVz dG9yZWQuICBJbiBleGlzdGluZyB0cmFuc3BvcnQgbmV0d29ya3MgKGkuZS4gT1ROIC8gc29uZXQp LCB0aGlzIGlzIA0KdHlwaWNhbGx5IGRvbmUgYmVmb3JlIHlvdSBzd2l0Y2ggdHJhZmZpYyB0byB0 aGUgcHJvdGVjdGlvbiBwYXRoLiAgRnJvbSBhIA0Kc29sdXRpb24gcGVyc3BlY3RpdmUsIEkgdGhp bmsgeW91J2xsIHByb2JhYmx5IHdhbnQgdG8gbGV2ZXJhZ2Ugc29tZXRoaW5nIA0KbGlrZSB0aGUg bG9ja2luZyBtb2RlIHRoYXQgaXMgYmVpbmcgcHJvcG9zZWQgZm9yIHRoZSAxOm4gZHJhZnQuDQoN Ci0gTml0OiB5b3UgbWlnaHQgd2FudCB0byBhdm9pZCB1c2luZyB0aGUgInF1ZXJ5IiB2ZXJiIGlu IHRoZSB0aXRsZSBvZiANCjQuMS4xIGJlY2F1c2UgaXQgc3VidGx5IHN1Z2dlc3RzIHNvbWUga2lu ZCBvZiBwcm90b2NvbCBtZXNzYWdpbmcgaXMgDQpyZXF1aXJlZC4gIEkgd291bGQgdXNlIHRoZSBt b3JlIGdlbmVyaWMgdmVyYiAiY2hlY2tpbmciIG9yICJ2ZXJpZnlpbmciLg0KeXc+PiBTb3VuZHMg T0sgdG8gbWUuIA0KLSBJbiA0LjMsIHRoZXJlIGlzIG5vIHN1Z2dlc3Rpb24gZm9yIHdoYXQgc2hv dWxkIGhhcHBlbiBpZiBvbmUgb3IgbW9yZSANCmZhaWxpbmcgcGF0aHMgaW4gYW4gTVBMUy1UUCBu ZXR3b3JrIGFyZSBvZiBlcXVhbCBwcmlvcml0eS4gIEkgcHJlc3VtZSBpdCANCndpbGwgYmUgc29t ZSBraW5kIG9mIGZpcnN0LWNvbWUsIGZpcnN0LXNlcnZlIHJlcXVpcmVtZW50IGJ1dCB0aGlzIHdp bGwgDQpicmluZyB1cCB0aGUgcXVlc3Rpb24gb2YgaG93IHRvIGJyZWFrIHRpZXMuDQp5dz4+IFRo aXMgY291bGQgYmUgcmVzb2x2ZWQgYWxvbmcgdGhlIGxpbmVzIHRoYXQgaXQgd2FzIGFkZHJlc3Nl ZCBpbiB0aGUgDQoxOm4gcHJvdGVjdGlvbg0KDQpQRj4+IEV4Y2VwdCB0aGF0IHlvdSBndXlzIHJl bW92ZWQgc2VwYXJhdGUgcGF0aCBwcmlvcml0eSBmcm9tIHRoZSBsYXRlc3QgDQp2ZXJzaW9uIG9m IHRoZSAxOm4gZHJhZnQuICBJbiB0aGUgbGF0ZXN0IHZlcnNpb24sIGVhY2ggcGF0aCBoYXMgYSBz dHJpY3QgDQpwcmlvcml0eSBkZWZpbmVkIGJ5IGl0cyBwYXRoIElEIHNvIHRpZXMgd2VyZSBub3Qg cG9zc2libGUuICBJIGRvbid0IHRoaW5rIA0KdGhhdCBzb2x1dGlvbiB3aWxsIHdvcmsgZm9yIFNN UCBiZWNhdXNlIEkgaGF2ZSBhIGhhcmQgdGltZSBzZWVpbmcgaG93IGFsbCANCnRoZSB2YXJpb3Vz IGVuZHBvaW50cyBpbnZvbHZlZCBpbiBhIHNoYXJlZCBtZXNoIGNvdWxkIGNvb3JkaW5hdGUgDQpu b24tb3ZlcmxhcHBpbmcgcGF0aCBJRHMsIHdoaWxlIGF0IHRoZSBzYW1lIHRpbWUgbm90IGV4Y2Vl ZGluZyB0aGUgbGltaXQgDQpvZiAyNTUgcGF0aCBJRHMuDQoNCg0KLSBBbHNvIGluIDQuMywgdGhl cmUgaXMgYW4gYWxsb3dhbmNlIGZvciBhIGhpZ2ggcHJpb3JpdHkgcGF0aCBhbmQgYSBsb3dlciAN CnByaW9yaXR5IHBhdGggdG8gdGVtcG9yYXJpbHkgc2hhcmUgdGhlIHByb3RlY3Rpb24gcmVzb3Vy Y2VzIHdoaWxlIA0KcHJlZW1wdGlvbiBpcyB0YWtpbmcgcGxhY2UuICBUd28gcXVlc3Rpb25zOg0K LSBJcyB0aGUgaW5ncmVzcyBub2RlIHRvIHRoZSBzaGFyZWQgc2VnbWVudCBleHBlY3RlZCB0byBk aXNjYXJkIGV4Y2VzcyANCnRyYWZmaWMgbm93IHRoYXQgdGhlIHByb3RlY3Rpb24tcGF0aCBpcyB0 ZW1wb3JhcmlseSBvdmVyc3Vic2NyaWJlZD8NCnl3Pj4gdGhpcyB3b3VsZCBtb3N0IHByb2JhYmx5 IGZvbGxvdyBzdGFuZGFyZCBNUExTIGJlaGF2aW9yIGFzIGRlc2NyaWJlZCANCmVsc2V3aGVyZSAN Cg0KUEY+PiBJIGd1ZXNzIEknbGwgYXNrIHdoYXQgaXMgdGhlIHN0YW5kYXJkIGJlaGF2aW91cj8g IEFuZCBpcyBpdCANCmFwcGxpY2FibGUgdG8gTVBMUy1UUCBuZXR3b3Jrcz8NCiANCi0gSWYgbm90 LCBob3cgZG8gd2UgZW5zdXJlIHRoYXQgb3RoZXIgdHJhbnNwb3J0IHBhdGhzIGFyZSB1bmFmZmVj dGVkPw0KLSBUaGUgZmlyc3QgcGFyYWdyYXBoIG9mIDQuNCBhcHBlYXJzIHRvIGNvbnRyYWRpY3Qg NC4xLjEuICA0LjQgc2VlbXMgdG8gDQpzdWdnZXN0IHRoYXQgb25lIE1VU1Qgc3dpdGNoIHRoZSB0 cmFmZmljIG9udG8gdGhlIHByb3RlY3Rpb24gcGF0aCBmaXJzdCANCmFuZCB0aGVuIGdldCBub3Rp ZmllZCBpZiB0aGVyZSdzIG5vdCBlbm91Z2ggcmVzb3VyY2VzLiAgVGhhdCdzIHByb2JhYmx5IA0K b2theSBpbiB0aGUgZ2VuZXJhbCBjYXNlLiAgQnV0IGluIGFuIE1QTFMtVFAgbmV0d29yaywgSSBk b24ndCB0aGluayBpdCdzIGEgDQpnb29kIGlkZWEgdG8gYmxpbmRseSBzd2l0Y2ggbG93IHByaW9y aXR5IHRyYWZmaWMgb250byB0aGUgcHJvdGVjdGlvbiBwYXRoIA0KYW5kIHBvc3NpYmx5IGRpc3J1 cHQgYSBoaWdoIHByaW9yaXR5IHBhdGggdGhhdCBpcyBhbHJlYWR5IHVzaW5nIHRoYXQgDQpyZXNv dXJjZS4NCnl3Pj4gVGhpcyBpcyBkZXBlbmRlbnQgdXBvbiB0aGUgYWN0dWFsIG1lY2hhbmlzbSB0 aGF0IGlzIGRldmVsb3BlZCBieSB0aGUgDQpXRy4gIEZvciBleGFtcGxlLCBvbmUgc3VnZ2VzdGlv biBmb3IgdGhlIG1lY2hhbmlzbSBoYXMgbm90aWZpY2F0aW9ucyBzZW50IA0KdG8gbG93ZXIgcHJp b3JpdHkgd29ya2luZyBwYXRocyBtYWtpbmcgdGhlIHByb3RlY3Rpb24gcGF0aCB1bmF2YWlsYWJs ZSBpZiANCml0IGlzIGluIHVzZSBieSBhIGhpZ2gtcHJpb3JpdHkgd29ya2luZyBwYXRoLg0KIA0K LSBJbiBzZWN0aW9uIDQuNSwgdGhlcmUncyBhbiBhdHRlbXB0IHRvIGRlZmluZSAicHJvdGVjdGlv biBzd2l0Y2hpbmcgdGltZSIgDQphcyBub3QgaW5jbHVkaW5nIHByZWVtcHRpb24gdGltZS4gIEkg ZG9uJ3QgdGhpbmsgZW5kLXVzZXJzIHJlYWxseSBjYXJlIA0KYWJvdXQgInByb3RlY3Rpb24gc3dp dGNoaW5nIHRpbWUiLiAgVGhleSBjYXJlIGFib3V0IHJlY292ZXJ5IHRpbWUgYW5kIElNTywgDQp0 aGF0IHNob3VsZCBhbHNvIGluY2x1ZGUgZmF1bHQgZGV0ZWN0aW9uIHRpbWUgKGFsdGhvdWdoIGl0 IGRvZXNuJ3QgcGVyIFJGQyANCjU2NTQpIGFuZCBhbnkgcHJlZW1wdGlvbiB0aW1lLg0KeXc+PiB3 ZSBkbyB0cnkgdG8gd29yayB3aXRoaW4gdGhlIGFjY2VwdGVkIGRlZmluaXRpb25zIG9mIHRoZSBJ RVRGISANCg0KUEY+PiBJIGd1ZXNzIHRoZXJlJ3MgdHdvIHNlcGFyYXRlIGNvbW1lbnRzIGhlcmUg dGhhdCBJIGtpbmRhIGNvbmZsYXRlZCANCnRvZ2V0aGVyLiAgT25lIHdhcyBtb3JlIG9mIGEgZ3Jp cGU6IHdoeSBkaWQgd2UgZXhjbHVkZSBmYXVsdCBkZXRlY3Rpb24gDQp0aW1lIGZyb20gdGhlIDUw bXMgcmVzdG9yYXRpb24gdGltZSByZXF1aXJlbWVudCBpbiBSRkMgNTY1ND8gIEkga25vdyB0aGF0 IA0KbXkgY3VzdG9tZXJzIG1lYXN1cmUgb25seSBvbmUgdGhpbmc6IGhvdyBtYW55IG1zIG9mIHRy YWZmaWMgZG8gdGhleSBsb3NlIA0KYWZ0ZXIgYSBicmVha2FnZS4gIEkgZG9uJ3QgZ2V0IGEgZnJl ZSBwYXNzIG9uIHRoZSB+MTBtcyBpdCB0YWtlcyBmb3IgQkZEIA0KdG8gZGV0ZWN0IHRoZSBmYWls dXJlLiAgQWNjb3JkaW5nIHRvIFJGQyA1NjU0LCBJIGNvdWxkIHVzZSA2MHNlYyBDQ01zIGFuZCAN CnN0aWxsIG1lZXQgdGhlIDUwbXMgcmVxdWlyZW1lbnQhDQoNClRoZSAybmQgY29tbWVudCB3YXMg cmVhbGx5IGFib3V0IHRoaXMgZHJhZnQgbm93IHRyeWluZyB0byBleGNsdWRlIA0KcHJlZW1wdGlv biB0aW1lIGZyb20gcmVzdG9yYXRpb24gdGltZSBhcyB3ZWxsLiAgSU1PLCBpZiBpdCB0YWtlcyBh IGZldyANCnNlY29uZHMgZm9yIGEgaGlnaCBwcmlvcml0eSBzZXJ2aWNlIHRvIGZpbmlzaCBwcmVl bXB0aW5nIGEgbG93ZXIgcHJpb3JpdHkgDQpzZXJ2aWNlLCB0aGVuIHdlIGhhdmVuJ3QgbWV0IHRo ZSA1MG1zIHJlc3RvcmF0aW9uIHRpbWUgcmVxdWlyZW1lbnQuIA0KRXNwZWNpYWxseSBzaW5jZSBp dCdzIHR5cGljYWxseSBteSBoaWdoZXIgcHJpb3JpdHkgc2VydmljZXMgdGhhdCB3YW50IDUwbXMg DQpyZXN0b3JhdGlvbiB0aW1lcyBpbiB0aGUgZmlyc3QgcGxhY2UsIHNvIHRoZXknbGwgYmUgbW9y ZSBvZnRlbiBpbiBhIA0KcG9zaXRpb24gdG8gcHJlZW1wdC4gIEluIG90aGVyIHdvcmRzLCBJIHRo aW5rIHdlIHdhbnQgcHJlZW1wdGlvbiB0byBiZSANCmZhc3QgYW5kIGlzIGEgY3JpdGljYWwgY29t cG9uZW50IG9mIHByb3RlY3Rpb24gc3dpdGNoaW5nLiANCiANCg0KcmVnYXJkcywNClBhYmxvDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMg bWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21wbHMNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KDQoNCg== --=_alternative 003C996748257A60_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkdyZWcsIHNuaXBwZWQ8L2ZvbnQ+ DQo8YnI+DQo8dWw+DQo8bGk+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPklu IHRoZSBsYXN0IHNlbnRlbmNlIG9mIFNlY3Rpb24NCjMuMSBub24tY29udHJvbCBwbGFuZSBjb29y ZGluYXRpb24gb2Ygc2hhcmVkIHJlc291cmNlcyBwcmVzZW50ZWQgYXMgYW5vdGhlcg0KcmVxdWly ZW1lbnQuIEFuZCBhZ2FpbiBJIGNhbiBub3QgZmluZCBob3cgd2UgY29tZSB0byBzdWNoIGNvbmNs dXNpb24sIHdoZXJlDQp0aGUgc291cmNlIG9mIHRoaXMgcmVxdWlyZW1lbnQuIFdvdWxkIGV4aXN0 aW5nIGNvbnRyb2wgcGxhbmUgc2lnbmFsaW5nDQpzb2x1dGlvbiBiZSBzdWZmaWNpZW50IGZvciBh IE1QTFMgbmV0d29yaz8gPC9mb250PjwvdWw+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiZsdDtGZWkmZ3Q7IEkgZG8gbm90IHRoaW5rIHRoZSBleGlzdGluZw0KY29udHJvbCBw bGFuZSAoZGVmaW5lZCBpbiBSRkM0ODcyKSBpcyBzdWZmaWNpZW50IGZvciBhIE1QTFMgbmV0d29y aywgYW5kDQp0aGVyZSBpcyBhbiBhbmFseXNpcyBpbiB0aGUgZHJhZnQgaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaGUtY2NhbXAtbm90aWZpY2F0aW9uLXNoYXJlZC1tZXNoLXByb3Rl Y3Rpb24tMDAuDQo8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPkJlc3QgcmVnYXJkczwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+RmVpPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxl IHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNiU+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPjxiPkdyZWdvcnkgTWlyc2t5ICZsdDtncmVnb3J5Lm1pcnNreUBl cmljc3Nvbi5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj63orz+yMs6ICZuYnNwO21wbHMtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEyLTA4LTE2IDA2OjQ1PC9mb250Pg0KPHRk IHdpZHRoPTYzJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8 ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2Zv bnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlBhYmxvIEZyYW5r ICZsdDtwYWJsb2lzbm90QGdtYWlsLmNvbSZndDssDQpZYWFjb3YgV2VpbmdhcnRlbiAmbHQ7d3lh YWNvdkBnbWFpbC5jb20mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2 Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDttcGxzQGlldGYub3Jn JnF1b3Q7ICZsdDttcGxzQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFttcGxz XSBDb21tZW50cyBvbiBkcmFmdC13ZWluZ2FydGVuLW1wbHMtc21wLXJlcXVpcmVtZW50cy0wMC50 eHQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg Y29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+RGVhciBQYWJsbywgWWFhY292LCBldCBhbC4sPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj5JJ3ZlIGJlZW4gZm9s bG93aW5nIGRpc2N1c3Npb24NCndpdGggZ3JlYXQgZGVhbCBvZiBpbnRlcmVzdC4gSSBoYXZlIHNv bWUgcXVlc3Rpb25zIGluIGFkZGl0aW9uIHRvIG9uZXMNCmJlaW5nIGJyb3VnaHQgdXAgYnkgUGFi bG86PC9mb250Pg0KPHVsPg0KPGxpPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFs Ij5TZWN0aW9uIDEuMiByZWZlcnMgdG8gb3BlcmF0b3Incw0KZGVzaXJlIHRvIGhhdmUgc2Vydmlj ZSByZXN0b3JhdGlvbiBtb3JlIGV4cGVkaWVudCB0aGFuIG9uZSBhY2hpZXZhYmxlIHdpdGgNCmNv bnRyb2wgcGxhbmUuIEkgaGF2ZW4ndCBzZWVuIGFueSBxdWFudGF0aXZlIGluZm9ybWF0aW9uIHRv IGNvbXBhcmUgd2l0aC4NCldoYXQgaXMgJnF1b3Q7ZXhwZWRpZW50IGVub3VnaCZxdW90OyBmb3Ig U01QPzwvZm9udD4NCjxsaT48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+U2Vj dGlvbiAzLjEgZGVzcmNpYmVzLCB3aGF0IGNhbg0KYmUgY2FsbGVkLCAmcXVvdDtpbnN0YW50IGRl dGVybWluaXNtJnF1b3Q7IGluIHJlZ2FyZCB0byBTTVAgcmVzb3VyY2UgYXZhaWFsYWJpbGl0eS4N CkkgdGhpbmsgdGhhdCB0aGVyZSdzIG5vdCBlbm91Z2ggcmVhc29uaW5nIHRvIGNvbmNsdWRlIHRo YXQgYWxtb3N0IGluc3RhbnRlbmVvdXMNCnVwZGF0ZSBvZiBTTVAgcmVzb3VyY2VzIGF2YWlhbGFi aWxpdHkgaXMgcmVxdWlyZWQuPC9mb250Pg0KPGxpPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZh Y2U9IkFyaWFsIj5JbiB0aGUgbGFzdCBzZW50ZW5jZSBvZiBTZWN0aW9uDQozLjEgbm9uLWNvbnRy b2wgcGxhbmUgY29vcmRpbmF0aW9uIG9mIHNoYXJlZCByZXNvdXJjZXMgcHJlc2VudGVkIGFzIGFu b3RoZXINCnJlcXVpcmVtZW50LiBBbmQgYWdhaW4gSSBjYW4gbm90IGZpbmQgaG93IHdlIGNvbWUg dG8gc3VjaCBjb25jbHVzaW9uLCB3aGVyZQ0KdGhlIHNvdXJjZSBvZiB0aGlzIHJlcXVpcmVtZW50 LiBXb3VsZCBleGlzdGluZyBjb250cm9sIHBsYW5lIHNpZ25hbGluZw0Kc29sdXRpb24gYmUgc3Vm ZmljaWVudCBmb3IgYSBNUExTIG5ldHdvcms/PC9mb250Pg0KPGxpPjxmb250IHNpemU9MiBjb2xv cj1ibHVlIGZhY2U9IkFyaWFsIj5JJ3ZlIG5vdGljZWQgdGhhdCBtYW55IHJlcXVpcmVtZW50cw0K YmVpbmcgcmVmZXJyZWQgdG8gTVBMUy1UUCwgbm90IE1QTFMsIG5ldHdvcmtzLiBXb3VsZCB0aGF0 IGJlIGEgZ29vZCByZWFzb24NCnRvIG5hcnJvdyBzY29wZSBvZiB0aGUgZG9jdW1lbnQgdG8gTVBM Uy1UUCBuZXR3b3JrcyBvbmx5LCBzdGFydGluZyB3aXRoDQp0aGUgbmFtZSBvZiB0aGUgZG9jdW1l bnQ/PC9mb250PjwvdWw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPiZuYnNw Ow0KJm5ic3A7IFJlZ2FyZHMsPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFs Ij5HcmVnPC9mb250Pg0KPGJyPg0KPGJyPg0KPGhyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEi PjxiPkZyb206PC9iPiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNA aWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlBhYmxvIEZyYW5rPGI+PGJyPg0KU2VudDo8 L2I+IEZyaWRheSwgQXVndXN0IDEwLCAyMDEyIDc6MjMgQU08Yj48YnI+DQpUbzo8L2I+IFlhYWNv diBXZWluZ2FydGVuPGI+PGJyPg0KQ2M6PC9iPiBtcGxzQGlldGYub3JnPGI+PGJyPg0KU3ViamVj dDo8L2I+IFJlOiBbbXBsc10gQ29tbWVudHMgb24gZHJhZnQtd2VpbmdhcnRlbi1tcGxzLXNtcC1y ZXF1aXJlbWVudHMtMDAudHh0PC9mb250Pjxmb250IHNpemU9Mz48YnI+DQo8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0zPkhpIFlhYWNvdiwgPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz5T b21lIG1vcmUgY29tbWVudHMgaW5saW5lLi4uIFBGJmd0OyZndDs8YnI+DQo8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0zPk9uIE1vbiwgQXVnIDYsIDIwMTIgYXQgODo1NiBBTSwgWWFhY292IFdlaW5n YXJ0ZW4gJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzp3eWFhY292QGdtYWlsLmNvbSB0YXJnZXQ9 X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pnd5YWFjb3ZAZ21haWwuY29tPC91Pjwv Zm9udD48L2E+PGZvbnQgc2l6ZT0zPiZndDsNCndyb3RlOjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTM+SGksIDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+VGhhbmsgeW91IGZvciB5b3Vy IGNvbW1lbnRzLiAmbmJzcDtQbGVhc2Ugc2VlIG15IGNvbW1lbnRzDQppbmxpbmUgYmVsb3cuPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz5CUiw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0z PnlhYWNvdjxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+T24gVHVlLCBKdWwgMTcsIDIw MTIgYXQgMTE6NTEgUE0sIFBhYmxvIEZyYW5rICZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86cGFi bG9pc25vdEBnbWFpbC5jb20gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48 dT5wYWJsb2lzbm90QGdtYWlsLmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz4mZ3Q7DQp3 cm90ZTo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPkdvb2QgZHJhZnQgYW5kIGNlcnRhaW5seSBz b21ldGhpbmcgdGhhdCBuZWVkcyB0byBiZSBkb25lDQpiZWZvcmUgd2UgY2FuIHN0YXJ0IGRpc2N1 c3Npbmcgc3BlY2lmaWMgc29sdXRpb25zLiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0z Pk9ubHkgYSBmZXcgY29tbWVudHMgLyBxdWVzdGlvbnM6PC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9Mz4tIEluIDQuMS4xLCBpZiBvbmUgaXMgb3BlcmF0aW5nIGluIGFuIE1QTFMtVFAgbmV0 d29yaw0KdGhhdCByZXF1aXJlcyBleGNsdXNpdmUgdXNlIG9mIHRoZSBwcm90ZWN0aW9uIHJlc291 cmNlcywgZG9lc24ndCB0aGlzIFNIT1VMRA0KcmVxdWlyZW1lbnQgYmVjb21lIGEgTVVTVCByZXF1 aXJlbWVudD88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPnl3Jmd0OyZndDsgU29ycnkg LSBidXQgY291bGQgeW91IGV4cGxhaW4gbW9yZSBmdWxseSB0aGlzDQpjb21tZW50LjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTM+UEYmZ3Q7Jmd0OyAmbmJzcDtJZiB5b3UncmUgdHJ5aW5n IHRvIG1lZXQgUkZDIDU2NTQgcmVxDQo1OGIgaW4gcGFydGljdWxhciwgSSB3b3VsZCB0aGluayB5 b3UgTVVTVCB2YWxpZGF0ZSB0aGF0IGVub3VnaCBwcm90ZWN0aW9uDQpyZXNvdXJjZXMgYXJlIGF2 YWlsYWJsZSAob3IgYXJlIHByZWVtcHRpYmxlKSB0byBjYXJyeSAxMDAlIG9mIHRoZSBzZXJ2aWNl DQp0cmFmZmljIHRoYXQgaXMgYmVpbmcgcmVzdG9yZWQuICZuYnNwO0luIGV4aXN0aW5nIHRyYW5z cG9ydCBuZXR3b3JrcyAoaS5lLg0KT1ROIC8gc29uZXQpLCB0aGlzIGlzIHR5cGljYWxseSBkb25l IGJlZm9yZSB5b3Ugc3dpdGNoIHRyYWZmaWMgdG8gdGhlIHByb3RlY3Rpb24NCnBhdGguICZuYnNw O0Zyb20gYSBzb2x1dGlvbiBwZXJzcGVjdGl2ZSwgSSB0aGluayB5b3UnbGwgcHJvYmFibHkgd2Fu dCB0bw0KbGV2ZXJhZ2Ugc29tZXRoaW5nIGxpa2UgdGhlIGxvY2tpbmcgbW9kZSB0aGF0IGlzIGJl aW5nIHByb3Bvc2VkIGZvciB0aGUNCjE6biBkcmFmdC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0zPi0gTml0OiB5b3UgbWlnaHQgd2FudCB0byBhdm9pZCB1c2luZyB0aGUgJnF1b3Q7cXVl cnkmcXVvdDsNCnZlcmIgaW4gdGhlIHRpdGxlIG9mIDQuMS4xIGJlY2F1c2UgaXQgc3VidGx5IHN1 Z2dlc3RzIHNvbWUga2luZCBvZiBwcm90b2NvbA0KbWVzc2FnaW5nIGlzIHJlcXVpcmVkLiAmbmJz cDtJIHdvdWxkIHVzZSB0aGUgbW9yZSBnZW5lcmljIHZlcmIgJnF1b3Q7Y2hlY2tpbmcmcXVvdDsN Cm9yICZxdW90O3ZlcmlmeWluZyZxdW90Oy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPnl3Jmd0 OyZndDsgU291bmRzIE9LIHRvIG1lLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPi0gSW4gNC4z LCB0aGVyZSBpcyBubyBzdWdnZXN0aW9uIGZvciB3aGF0IHNob3VsZCBoYXBwZW4NCmlmIG9uZSBv ciBtb3JlIGZhaWxpbmcgcGF0aHMgaW4gYW4gTVBMUy1UUCBuZXR3b3JrIGFyZSBvZiBlcXVhbCBw cmlvcml0eS4NCiZuYnNwO0kgcHJlc3VtZSBpdCB3aWxsIGJlIHNvbWUga2luZCBvZiBmaXJzdC1j b21lLCBmaXJzdC1zZXJ2ZSByZXF1aXJlbWVudA0KYnV0IHRoaXMgd2lsbCBicmluZyB1cCB0aGUg cXVlc3Rpb24gb2YgaG93IHRvIGJyZWFrIHRpZXMuPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz55 dyZndDsmZ3Q7IFRoaXMgY291bGQgYmUgcmVzb2x2ZWQgYWxvbmcgdGhlIGxpbmVzIHRoYXQNCml0 IHdhcyBhZGRyZXNzZWQgaW4gdGhlIDE6biBwcm90ZWN0aW9uPC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9Mz5QRiZndDsmZ3Q7IEV4Y2VwdCB0aGF0IHlvdSBndXlzIHJlbW92ZWQgc2VwYXJh dGUgcGF0aA0KcHJpb3JpdHkgZnJvbSB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIDE6biBkcmFm dC4gJm5ic3A7SW4gdGhlIGxhdGVzdA0KdmVyc2lvbiwgZWFjaCBwYXRoIGhhcyBhIHN0cmljdCBw cmlvcml0eSBkZWZpbmVkIGJ5IGl0cyBwYXRoIElEIHNvIHRpZXMNCndlcmUgbm90IHBvc3NpYmxl LiAmbmJzcDtJIGRvbid0IHRoaW5rIHRoYXQgc29sdXRpb24gd2lsbCB3b3JrIGZvciBTTVANCmJl Y2F1c2UgSSBoYXZlIGEgaGFyZCB0aW1lIHNlZWluZyBob3cgYWxsIHRoZSB2YXJpb3VzIGVuZHBv aW50cyBpbnZvbHZlZA0KaW4gYSBzaGFyZWQgbWVzaCBjb3VsZCBjb29yZGluYXRlIG5vbi1vdmVy bGFwcGluZyBwYXRoIElEcywgd2hpbGUgYXQgdGhlDQpzYW1lIHRpbWUgbm90IGV4Y2VlZGluZyB0 aGUgbGltaXQgb2YgMjU1IHBhdGggSURzLjwvZm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBz aXplPTM+LSBBbHNvIGluIDQuMywgdGhlcmUgaXMgYW4gYWxsb3dhbmNlIGZvciBhIGhpZ2ggcHJp b3JpdHkNCnBhdGggYW5kIGEgbG93ZXIgcHJpb3JpdHkgcGF0aCB0byB0ZW1wb3JhcmlseSBzaGFy ZSB0aGUgcHJvdGVjdGlvbiByZXNvdXJjZXMNCndoaWxlIHByZWVtcHRpb24gaXMgdGFraW5nIHBs YWNlLiAmbmJzcDtUd28gcXVlc3Rpb25zOjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+LSBJcyB0 aGUgaW5ncmVzcyBub2RlIHRvIHRoZSBzaGFyZWQgc2VnbWVudCBleHBlY3RlZCB0bw0KZGlzY2Fy ZCBleGNlc3MgdHJhZmZpYyBub3cgdGhhdCB0aGUgcHJvdGVjdGlvbi1wYXRoIGlzIHRlbXBvcmFy aWx5IG92ZXJzdWJzY3JpYmVkPzwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+eXcmZ3Q7Jmd0OyB0 aGlzIHdvdWxkIG1vc3QgcHJvYmFibHkgZm9sbG93IHN0YW5kYXJkIE1QTFMNCmJlaGF2aW9yIGFz IGRlc2NyaWJlZCBlbHNld2hlcmUgPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz5QRiZn dDsmZ3Q7IEkgZ3Vlc3MgSSdsbCBhc2sgd2hhdCBpcyB0aGUgc3RhbmRhcmQgYmVoYXZpb3VyPw0K Jm5ic3A7QW5kIGlzIGl0IGFwcGxpY2FibGUgdG8gTVBMUy1UUCBuZXR3b3Jrcz88L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+LSBJZiBub3Qs IGhvdyBkbyB3ZSBlbnN1cmUgdGhhdCBvdGhlciB0cmFuc3BvcnQgcGF0aHMNCmFyZSB1bmFmZmVj dGVkPzwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+LSBUaGUgZmlyc3QgcGFyYWdyYXBoIG9mIDQu NCBhcHBlYXJzIHRvIGNvbnRyYWRpY3QgNC4xLjEuDQombmJzcDs0LjQgc2VlbXMgdG8gc3VnZ2Vz dCB0aGF0IG9uZSBNVVNUIHN3aXRjaCB0aGUgdHJhZmZpYyBvbnRvIHRoZSBwcm90ZWN0aW9uDQpw YXRoIGZpcnN0IGFuZCB0aGVuIGdldCBub3RpZmllZCBpZiB0aGVyZSdzIG5vdCBlbm91Z2ggcmVz b3VyY2VzLiAmbmJzcDtUaGF0J3MNCnByb2JhYmx5IG9rYXkgaW4gdGhlIGdlbmVyYWwgY2FzZS4g Jm5ic3A7QnV0IGluIGFuIE1QTFMtVFAgbmV0d29yaywgSSBkb24ndA0KdGhpbmsgaXQncyBhIGdv b2QgaWRlYSB0byBibGluZGx5IHN3aXRjaCBsb3cgcHJpb3JpdHkgdHJhZmZpYyBvbnRvIHRoZQ0K cHJvdGVjdGlvbiBwYXRoIGFuZCBwb3NzaWJseSBkaXNydXB0IGEgaGlnaCBwcmlvcml0eSBwYXRo IHRoYXQgaXMgYWxyZWFkeQ0KdXNpbmcgdGhhdCByZXNvdXJjZS48L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0zPnl3Jmd0OyZndDsgVGhpcyBpcyBkZXBlbmRlbnQgdXBvbiB0aGUgYWN0dWFsIG1lY2hh bmlzbQ0KdGhhdCBpcyBkZXZlbG9wZWQgYnkgdGhlIFdHLiAmbmJzcDtGb3IgZXhhbXBsZSwgb25l IHN1Z2dlc3Rpb24gZm9yIHRoZQ0KbWVjaGFuaXNtIGhhcyBub3RpZmljYXRpb25zIHNlbnQgdG8g bG93ZXIgcHJpb3JpdHkgd29ya2luZyBwYXRocyBtYWtpbmcNCnRoZSBwcm90ZWN0aW9uIHBhdGgg dW5hdmFpbGFibGUgaWYgaXQgaXMgaW4gdXNlIGJ5IGEgaGlnaC1wcmlvcml0eSB3b3JraW5nDQpw YXRoLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp emU9Mz4tIEluIHNlY3Rpb24gNC41LCB0aGVyZSdzIGFuIGF0dGVtcHQgdG8gZGVmaW5lICZxdW90 O3Byb3RlY3Rpb24NCnN3aXRjaGluZyB0aW1lJnF1b3Q7IGFzIG5vdCBpbmNsdWRpbmcgcHJlZW1w dGlvbiB0aW1lLiAmbmJzcDtJIGRvbid0IHRoaW5rDQplbmQtdXNlcnMgcmVhbGx5IGNhcmUgYWJv dXQgJnF1b3Q7cHJvdGVjdGlvbiBzd2l0Y2hpbmcgdGltZSZxdW90Oy4gJm5ic3A7VGhleQ0KY2Fy ZSBhYm91dCByZWNvdmVyeSB0aW1lIGFuZCBJTU8sIHRoYXQgc2hvdWxkIGFsc28gaW5jbHVkZSBm YXVsdCBkZXRlY3Rpb24NCnRpbWUgKGFsdGhvdWdoIGl0IGRvZXNuJ3QgcGVyIFJGQyA1NjU0KSBh bmQgYW55IHByZWVtcHRpb24gdGltZS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPnl3Jmd0OyZn dDsgd2UgZG8gdHJ5IHRvIHdvcmsgd2l0aGluIHRoZSBhY2NlcHRlZCBkZWZpbml0aW9ucw0Kb2Yg dGhlIElFVEYhIDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+UEYmZ3Q7Jmd0OyBJIGd1 ZXNzIHRoZXJlJ3MgdHdvIHNlcGFyYXRlIGNvbW1lbnRzIGhlcmUNCnRoYXQgSSBraW5kYSBjb25m bGF0ZWQgdG9nZXRoZXIuICZuYnNwO09uZSB3YXMgbW9yZSBvZiBhIGdyaXBlOiB3aHkgZGlkDQp3 ZSBleGNsdWRlIGZhdWx0IGRldGVjdGlvbiB0aW1lIGZyb20gdGhlIDUwbXMgcmVzdG9yYXRpb24g dGltZSByZXF1aXJlbWVudA0KaW4gUkZDIDU2NTQ/ICZuYnNwO0kga25vdyB0aGF0IG15IGN1c3Rv bWVycyBtZWFzdXJlIG9ubHkgb25lIHRoaW5nOiBob3cNCm1hbnkgbXMgb2YgdHJhZmZpYyBkbyB0 aGV5IGxvc2UgYWZ0ZXIgYSBicmVha2FnZS4gJm5ic3A7SSBkb24ndCBnZXQgYSBmcmVlDQpwYXNz IG9uIHRoZSB+MTBtcyBpdCB0YWtlcyBmb3IgQkZEIHRvIGRldGVjdCB0aGUgZmFpbHVyZS4gJm5i c3A7QWNjb3JkaW5nDQp0byBSRkMgNTY1NCwgSSBjb3VsZCB1c2UgNjBzZWMgQ0NNcyBhbmQgc3Rp bGwgbWVldCB0aGUgNTBtcyByZXF1aXJlbWVudCE8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0zPlRoZSAybmQgY29tbWVudCB3YXMgcmVhbGx5IGFib3V0IHRoaXMgZHJhZnQgbm93IHRyeWlu Zw0KdG8gZXhjbHVkZSBwcmVlbXB0aW9uIHRpbWUgZnJvbSByZXN0b3JhdGlvbiB0aW1lIGFzIHdl bGwuICZuYnNwO0lNTywgaWYNCml0IHRha2VzIGEgZmV3IHNlY29uZHMgZm9yIGEgaGlnaCBwcmlv cml0eSBzZXJ2aWNlIHRvIGZpbmlzaCBwcmVlbXB0aW5nDQphIGxvd2VyIHByaW9yaXR5IHNlcnZp Y2UsIHRoZW4gd2UgaGF2ZW4ndCBtZXQgdGhlIDUwbXMgcmVzdG9yYXRpb24gdGltZQ0KcmVxdWly ZW1lbnQuICZuYnNwO0VzcGVjaWFsbHkgc2luY2UgaXQncyB0eXBpY2FsbHkgbXkgaGlnaGVyIHBy aW9yaXR5IHNlcnZpY2VzDQp0aGF0IHdhbnQgNTBtcyByZXN0b3JhdGlvbiB0aW1lcyBpbiB0aGUg Zmlyc3QgcGxhY2UsIHNvIHRoZXknbGwgYmUgbW9yZQ0Kb2Z0ZW4gaW4gYSBwb3NpdGlvbiB0byBw cmVlbXB0LiAmbmJzcDtJbiBvdGhlciB3b3JkcywgSSB0aGluayB3ZSB3YW50IHByZWVtcHRpb24N CnRvIGJlIGZhc3QgYW5kIGlzIGEgY3JpdGljYWwgY29tcG9uZW50IG9mIHByb3RlY3Rpb24gc3dp dGNoaW5nLiAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTM+cmVnYXJkcyw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPlBh YmxvPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz48YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1wbHMgbWFpbGluZyBsaXN0PC9m b250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1t YWlsdG86bXBsc0BpZXRmLm9yZyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVl Pjx1Pm1wbHNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48 dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tcGxzIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPC91PjwvZm9udD48L2E+PGZv bnQgc2l6ZT0zPjxicj4NCjwvZm9udD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbXBscyBtYWls aW5nIGxpc3Q8YnI+DQptcGxzQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tcGxzPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo= --=_alternative 003C996748257A60_=-- From iesg-secretary@ietf.org Mon Aug 20 08:50: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 8866E21F86C8; Mon, 20 Aug 2012 08:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 HRPhFBwCowE0; Mon, 20 Aug 2012 08:50:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6A921F8650; Mon, 20 Aug 2012 08:50:36 -0700 (PDT) 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.33 Message-ID: <20120820155036.4940.80906.idtracker@ietfa.amsl.com> Date: Mon, 20 Aug 2012 08:50:36 -0700 Cc: mpls@ietf.org Subject: [mpls] Last Call: (The Use of Entropy Labels in MPLS Forwarding) 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: Mon, 20 Aug 2012 15:50:37 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'The Use of Entropy Labels in MPLS Forwarding' 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 2012-09-03. 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 Load balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing across MPLS networks using the concept of "entropy labels". It defines the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications. This document updates RFCs 3031, 3107, 3209 and 5036. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-entropy-label/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-entropy-label/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1797/ http://datatracker.ietf.org/ipr/1605/ http://datatracker.ietf.org/ipr/1789/ From kireeti@juniper.net Mon Aug 20 11:12: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 9D2D521F8688 for ; Mon, 20 Aug 2012 11:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 EXYshVn-1TT4 for ; Mon, 20 Aug 2012 11:12:05 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 8915421F8673 for ; Mon, 20 Aug 2012 11:12:05 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKUDJ98lpnelyo5kGCpAmh5IjvQMjQIRzv@postini.com; Mon, 20 Aug 2012 11:12:05 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Mon, 20 Aug 2012 11:10:49 -0700 From: Kireeti Kompella To: Vivek Kumar Date: Mon, 20 Aug 2012 11:10:47 -0700 Thread-Topic: [mpls] Question regarding MPLS reserved label with ECMP Thread-Index: Ac1+/yBVgAEZDLTjTie+nD5ql/O0jQ== Message-ID: References: <3C086BA39C55B9418AE8FEA3F3EFDEC408291E@SJEXCHMB09.corp.ad.broadcom.com> In-Reply-To: <3C086BA39C55B9418AE8FEA3F3EFDEC408291E@SJEXCHMB09.corp.ad.broadcom.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 Cc: "mpls@ietf.org" Subject: Re: [mpls] Question regarding MPLS reserved label with ECMP 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, 20 Aug 2012 18:12:08 -0000 On Aug 18, 2012, at 4:45 , Vivek Kumar wrote: > Hi , > I have one question regarding whether MPLS reserved label should be used= or skipped when Transit LSR is doing hashing on full label stack which has= some reserved label. draft-ietf-mpls-entropy-label, section 4.3: If a transit LSR recognizes the ELI, it MAY choose to load balance solely on the following label (the EL); otherwise, it SHOULD use as much of the whole label stack as feasible as keys for the load balancing function, with the exception that reserved labels MUST NOT be used. > RFC 6391 , section 7 , says " Note that, depending on the number of lab= els hashed by the LSR, the > inclusion of the Router Alert label may cause the OAM packet to be > load-balanced to a different path from that taken by the data packets > with identical flow and PW labels". > > The above comment implies that reserved label is used by LSR when doing = hashing for ECMP. > > Is there any other RFC which states what should be the correct behavior. > > The draft " draft-ietf-mpls-entropy-label-05" section 4.3 , says reserve= d label should not be used by LSR when doing hashing on label stack. > > > Regards, > Vivek > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of m= pls-request@ietf.org > Sent: Saturday, August 18, 2012 5:12 AM > To: mpls@ietf.org > Subject: mpls Digest, Vol 100, Issue 32 > > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/mpls > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send mpls mailing list submissions to > mpls@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/mpls > or, via email, send a message with subject or body 'help' to > mpls-request@ietf.org > > You can reach the person managing the list at > mpls-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of mpls digest..." > > > Today's Topics: > > 1. I-D Action: draft-ietf-mpls-entropy-label-05.txt > (internet-drafts@ietf.org) > 2. Re: draft-ietf-mpls-tp-te-mib-04.txt review request > (Venkatesan Mahalingam) > 3. Re: draft-ietf-mpls-tp-te-mib-04.txt review request (Sam Aldrin) > 4. Re: [CCAMP] I-D Action: > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt > (Gregory Mirsky) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 17 Aug 2012 12:19:09 -0700 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Cc: mpls@ietf.org > Subject: [mpls] I-D Action: draft-ietf-mpls-entropy-label-05.txt > Message-ID: <20120817191909.22120.13634.idtracker@ietfa.amsl.com> > Content-Type: text/plain; charset=3D"utf-8" > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Multiprotocol Label Switching Working Gr= oup of the IETF. > > Title : The Use of Entropy Labels in MPLS Forwarding > Author(s) : Kireeti Kompella > John Drake > Shane Amante > Wim Henderickx > Lucy Yong > Filename : draft-ietf-mpls-entropy-label-05.txt > Pages : 23 > Date : 2012-08-17 > > Abstract: > Load balancing is a powerful tool for engineering traffic across a > network. This memo suggests ways of improving load balancing across > MPLS networks using the concept of "entropy labels". It defines the > concept, describes why entropy labels are useful, enumerates > properties of entropy labels that allow maximal benefit, and shows > how they can be signaled and used for various applications. This > document updates RFCs 3031, 3107, 3209 and 5036. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mpls-entropy-label > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mpls-entropy-label-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-entropy-label-05 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > > ------------------------------ > > Message: 2 > Date: Fri, 17 Aug 2012 13:51:19 -0700 > From: Venkatesan Mahalingam > To: Joan Cucchiara , mpls@ietf.org, "MIB > Doctors (E-mail)" , mpls-chairs@tools.ietf.o= rg > Cc: Sam Aldrin > Subject: Re: [mpls] draft-ietf-mpls-tp-te-mib-04.txt review request > Message-ID: > > Content-Type: text/plain; charset=3DISO-8859-1 > > ++ MPLS WG & MIB Drs. > > Thanks, > Venkat. > > On Fri, Aug 17, 2012 at 1:36 PM, Joan Cucchiara > wrote: >> Venkat, >> >> The SMIv2 specifies that once a TC is defined, then the definition canno= t >> change in the way being >> proposed by the draft-ietf-mpls-tp-te-mib-04. >> >> From RFC2579: >> 3.3. Mapping of the DESCRIPTION clause >> The DESCRIPTION clause, which must be present, contains a textual >> definition of the textual convention, which provides all semantic >> definitions necessary for implementation, and should embody any >> information which would otherwise be communicated in any ASN.1 >> commentary annotations associated with the object. >> >> >> My concern is that MPLS-TC-STD-MIB defines MplsExtendedTunnelId and this >> draft is changing that original definition. >> If RFC3811 does not contain "all semantic definitions necessary for >> implementation" then the problem is to update RFC3811 >> and maybe other associated RFCs as needed, not to propose additional >> semantics in draft-ietf-mpls-tp-te-mib. >> >> The draft is proposing to bifurcate the values and also not use zero for= the >> MplsExtendedTunnelId, that is not the original >> definition of MplsExtendedTunnelId, so why is this draft using >> MplsExtendedTunnelId? >> >> Please include the MIB Dr's on your email because this is a MIB concern = and >> one which I've had since >> before this draft was adopted as a WG document. >> >> The options are (as I see them): >> 1) create a specific MPLS TP table for TP Tunnels (which was originally >> proposed by Adrian Farrel) >> 2) update RFC3811 to accurately reflect MplsExtendedTunnelId and other R= FCs >> which utilize this TC. >> 3) ?? >> >> Thanks, >> -Joan >> >> >> ----- Original Message ----- From: "Venkatesan Mahalingam" >> >> To: "Joan Cucchiara" >> Cc: "Thomas Nadeau" ; "Sam Aldrin" >> ; "Kannan KV Sampath" >> Sent: Friday, August 17, 2012 2:39 PM >> >> Subject: Re: draft-ietf-mpls-tp-te-mib-04.txt review request >> >> >>> Joan, >>> >>> Thanks for your response. Appreciate your time for reviewing this >>> draft. Please find below my response tagged [VM]. >>> >>> However, I looked over the doc and wanted to let you know that I still >>> have >>>> >>>> the same issue wrt to both SYNTAX and semantic >>>> redefinition as before. You cannot narrow the range of values in a >>>> DESCRIPTION clause which I see happens in mplsTunnelExtNodeConfigLocal= Id >>>> and maybe in MplsNodeId TC as it says zero must not be used, but then >>>> you >>>> have it as part of allowable values in the SYNTAX. >>> >>> [VM] If MplsExtendedTunnelId allows zero as the valid value, I don't >>> see any issue to allow zero as the valid value for MplsNodeId. >>> >>>> Additionally, the SYNTAX below for MplsExtendedTunnelId allows any >>>> Unsigned32 and says "may represent an IPv4 address". If (for whatev= er >>>> reason) an >>>> operator has configured something in the 1..16777216 (i.e. Local Id) >>>> range, >>>> for a regular TE Tunnel, that is perfectly legal, right? >>> >>> [VM] I don't see any implementation which allows non-IP TE tunnel >>> source/destination in the range 1..16777216 in MPLS domain, >>> if you are not still convinced, we can poll in MPLS WG list to get the >>> operators' opinion on this. >>> >>>> If the answer is Yes, then how would you add TP Tunnels using your dra= ft >>>> if >>>> an operator has a regular MPLS TE Tunnel configured >>>> in the range 1..16777216 without having to ensure that any and all leg= acy >>>> equipment be queried first? >>> >>> [VM] It is expected to configure MPLS TE tunnels in IP address range >>> and MPLS-TP tunnel in NON-IP range, if the implementors have mixed >>> mode of configuration, then it is expected to clarify in the document >>> that how to use MPLS-TE & MPLS-TP tunnel configurations. >>> What you are saying is correct only if the legacy equipments use the >>> NON-IP range for MPLS TE tunnels, so, as I stated above, let's close >>> this with the MPLS WG list. >>> >>> HTH >>> >>> Thanks, >>> Venkat. >>> >>> On Fri, Aug 17, 2012 at 10:21 AM, Joan Cucchiara >>> wrote: >>>> >>>> Tom and all, >>>> >>>> Unfortunately, my linux box is giving me grief this week (and I don't >>>> have >>>> access to my MIB tools). I'm getting some assistance >>>> with it but won't be resolved until (hopefully) during the weekend. >>>> >>>> However, I looked over the doc and wanted to let you know that I still >>>> have >>>> the same issue wrt to both SYNTAX and semantic >>>> redefinition as before. You cannot narrow the range of values in a >>>> DESCRIPTION clause which I see happens in mplsTunnelExtNodeConfigLocal= Id >>>> and maybe in MplsNodeId TC as it says zero must not be used, but then >>>> you >>>> have it as part of allowable values in the SYNTAX. >>>> >>>> Whatever is specified in the DESCRIPTION clause for values, should be >>>> reflected by the SYNTAX, right? >>>> >>>> Additionally, the SYNTAX below for MplsExtendedTunnelId allows any >>>> Unsigned32 and says "may represent an IPv4 address". If (for whatev= er >>>> reason) an >>>> operator has configured something in the 1..16777216 (i.e. Local Id) >>>> range, >>>> for a regular TE Tunnel, that is perfectly legal, right? >>>> >>>> >>>> MplsExtendedTunnelId ::=3D TEXTUAL-CONVENTION >>>> STATUS current >>>> DESCRIPTION >>>> "A unique identifier for an MPLS Tunnel. This may >>>> represent an IPv4 address of the ingress or egress >>>> LSR for the tunnel. This value is derived from the >>>> Extended Tunnel Id in RSVP or the Ingress Router ID >>>> for CR-LDP." >>>> REFERENCE >>>> "RSVP-TE: Extensions to RSVP for LSP Tunnels, >>>> [RFC3209]. >>>> >>>> Constraint-Based LSP Setup using LDP, [RFC3212]." >>>> SYNTAX Unsigned32(0..4294967295) >>>> >>>> If the answer is Yes, then how would you add TP Tunnels using your dra= ft >>>> if >>>> an operator has a regular MPLS TE Tunnel configured >>>> in the range 1..16777216 without having to ensure that any and all leg= acy >>>> equipment be queried first? >>>> >>>> Thanks, >>>> -Joan >>>> >>>> >>>> >>>> ----- Original Message ----- >>>> From: Thomas Nadeau >>>> To: Joan Cucchiara >>>> Cc: Sam Aldrin ; Venkatesan Mahalingam ; Kannan KV Sampath >>>> Sent: Thursday, August 09, 2012 8:58 AM >>>> Subject: Re: draft-ietf-mpls-tp-te-mib-04.txt review request >>>> >>>> hi Joan >>>> >>>> hope you had a great vacation! ;) >>>> >>>> can you please follow up on the note below when you have a chance? >>>> >>>> Tom >>>> >>>> >>>> >>>> On Jul 16, 2012, at 9:13 AM, "Joan Cucchiara" >>>> wrote: >>>> >>>> Sam, >>>> >>>> We are away this week returning on 7/23. Sorry, I can't review the d= oc >>>> until after 7/23 and it will >>>> take a few days after that as I'll just be returning from vacation. >>>> >>>> I glanced at it and see that there are read-write objects in a row (wh= ich >>>> is >>>> read-create) so that's >>>> an error which I mentioned before. >>>> >>>> Have you compiled this with smilint? >>>> >>>> Thanks, >>>> -Joan >>>> >>>> >>>> >>>> >>>> >>>> ----- Original Message ----- >>>> From: Sam Aldrin >>>> To: Joan Cucchiara >>>> Cc: Venkatesan Mahalingam ; Thomas Nadeau ; Kannan KV Sampath >>>> Sent: Friday, July 13, 2012 9:11 PM >>>> Subject: Fwd: draft-ietf-mpls-tp-te-mib-04.txt review request >>>> >>>> Hi Joan, >>>> >>>> Please find the updated MIB document. Apologize for the delay. We plan= to >>>> publish the doc on Monday as it is the deadline before IETF. Diff file= is >>>> attached as well. >>>> >>>> This version addresses all your comments. Highlighting couple of them = to >>>> make sure you are OK with them >>>> >>>> 1. W.r.t mplsLocalID as index type, we have removed that using >>>> MplsExtendedTunnelId itself. As the value range for this object could >>>> have >>>> value of non-IP address, we are using it. This will make the indices f= or >>>> the >>>> same as TunnelTable. >>>> In the definition of IngressLSRId and and EgressLSRId, for TP entries,= we >>>> added description to use value of non-IP address, which is local ID. >>>> >>>> I do hope this satisfies the need and not necessitate for a new table >>>> altogether for TP. >>>> >>>> 2. In regards to adding references to TC conventions. We believe, thos= e >>>> were >>>> added in the reference section. IF we have missed any TC references, >>>> could >>>> you kindly let us know. >>>> >>>> Appreciate if you can get back by Monday noon time PST. I know it is a >>>> very >>>> short time, but appreciate if you could do that. >>>> >>>> thanks >>>> -sam >>>> >>>> ________________________________ >>>> >>>> >> > > > ------------------------------ > > Message: 3 > Date: Fri, 17 Aug 2012 14:06:45 -0700 > From: Sam Aldrin > To: Venkatesan Mahalingam > Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, Sam Aldrin > , "MIB Doctors \(E-mail\)" > > Subject: Re: [mpls] draft-ietf-mpls-tp-te-mib-04.txt review request > Message-ID: <2E7490DB-3DE7-42C8-8E43-7378A76C2B4C@gmail.com> > Content-Type: text/plain; charset=3Dus-ascii > > Hi Joan, > > The issue boils down to the range value specified in the DESCRIPTION. > If that is removed, does that resolve the concern you raised? > Do not think we are restricting not to use '0' in anyway or redefining th= e semantics. > > As the value is local and the intention is to help implementor of the MIB= to choose right value, without conflicting with TE tunnel index, we added = that range. If implementor chooses to use different value altogether, it is= perfectly OK as long as it is in the range of mplsExtendedTunnelId definit= ion. > W.r.t legacy implementation, it is unto the implementor to assign the rig= ht index value to TP tunnel, if it conflicts with TE tunnel index. > The example provided could give guidance on what value to use, but will n= ot MANDATE the usage. > > In regards to implementing a new table, we have deliberated extensively a= mong authors and also with implementors. Adding new MIB or table is not rea= lly efficient. Infact, there are already implementations which were able to= support the legacy model as well as new TP tunnels. Unless there is a comp= elling reason that MPLS TP tunnel table should have its own table, which es= sentially duplicated all of the objects, I am not for that model. If others= in WG feels the need, they can speak up. > > -sam > On Aug 17, 2012, at 1:51 PM, Venkatesan Mahalingam wrote: > >> ++ MPLS WG & MIB Drs. >> >> Thanks, >> Venkat. >> >> On Fri, Aug 17, 2012 at 1:36 PM, Joan Cucchiara >> wrote: >>> Venkat, >>> >>> The SMIv2 specifies that once a TC is defined, then the definition cann= ot >>> change in the way being >>> proposed by the draft-ietf-mpls-tp-te-mib-04. >>> >>> From RFC2579: >>> 3.3. Mapping of the DESCRIPTION clause >>> The DESCRIPTION clause, which must be present, contains a textual >>> definition of the textual convention, which provides all semantic >>> definitions necessary for implementation, and should embody any >>> information which would otherwise be communicated in any ASN.1 >>> commentary annotations associated with the object. >>> >>> >>> My concern is that MPLS-TC-STD-MIB defines MplsExtendedTunnelId and thi= s >>> draft is changing that original definition. >>> If RFC3811 does not contain "all semantic definitions necessary for >>> implementation" then the problem is to update RFC3811 >>> and maybe other associated RFCs as needed, not to propose additional >>> semantics in draft-ietf-mpls-tp-te-mib. >>> >>> The draft is proposing to bifurcate the values and also not use zero fo= r the >>> MplsExtendedTunnelId, that is not the original >>> definition of MplsExtendedTunnelId, so why is this draft using >>> MplsExtendedTunnelId? >>> >>> Please include the MIB Dr's on your email because this is a MIB concern= and >>> one which I've had since >>> before this draft was adopted as a WG document. >>> >>> The options are (as I see them): >>> 1) create a specific MPLS TP table for TP Tunnels (which was originally >>> proposed by Adrian Farrel) >>> 2) update RFC3811 to accurately reflect MplsExtendedTunnelId and other = RFCs >>> which utilize this TC. >>> 3) ?? >>> >>> Thanks, >>> -Joan >>> >>> >>> ----- Original Message ----- From: "Venkatesan Mahalingam" >>> >>> To: "Joan Cucchiara" >>> Cc: "Thomas Nadeau" ; "Sam Aldrin" >>> ; "Kannan KV Sampath" >>> Sent: Friday, August 17, 2012 2:39 PM >>> >>> Subject: Re: draft-ietf-mpls-tp-te-mib-04.txt review request >>> >>> >>>> Joan, >>>> >>>> Thanks for your response. Appreciate your time for reviewing this >>>> draft. Please find below my response tagged [VM]. >>>> >>>> However, I looked over the doc and wanted to let you know that I still >>>> have >>>>> >>>>> the same issue wrt to both SYNTAX and semantic >>>>> redefinition as before. You cannot narrow the range of values in a >>>>> DESCRIPTION clause which I see happens in mplsTunnelExtNodeConfigLoca= lId >>>>> and maybe in MplsNodeId TC as it says zero must not be used, but the= n >>>>> you >>>>> have it as part of allowable values in the SYNTAX. >>>> >>>> [VM] If MplsExtendedTunnelId allows zero as the valid value, I don't >>>> see any issue to allow zero as the valid value for MplsNodeId. >>>> >>>>> Additionally, the SYNTAX below for MplsExtendedTunnelId allows any >>>>> Unsigned32 and says "may represent an IPv4 address". If (for whate= ver >>>>> reason) an >>>>> operator has configured something in the 1..16777216 (i.e. Local Id) >>>>> range, >>>>> for a regular TE Tunnel, that is perfectly legal, right? >>>> >>>> [VM] I don't see any implementation which allows non-IP TE tunnel >>>> source/destination in the range 1..16777216 in MPLS domain, >>>> if you are not still convinced, we can poll in MPLS WG list to get the >>>> operators' opinion on this. >>>> >>>>> If the answer is Yes, then how would you add TP Tunnels using your dr= aft >>>>> if >>>>> an operator has a regular MPLS TE Tunnel configured >>>>> in the range 1..16777216 without having to ensure that any and all le= gacy >>>>> equipment be queried first? >>>> >>>> [VM] It is expected to configure MPLS TE tunnels in IP address range >>>> and MPLS-TP tunnel in NON-IP range, if the implementors have mixed >>>> mode of configuration, then it is expected to clarify in the document >>>> that how to use MPLS-TE & MPLS-TP tunnel configurations. >>>> What you are saying is correct only if the legacy equipments use the >>>> NON-IP range for MPLS TE tunnels, so, as I stated above, let's close >>>> this with the MPLS WG list. >>>> >>>> HTH >>>> >>>> Thanks, >>>> Venkat. >>>> >>>> On Fri, Aug 17, 2012 at 10:21 AM, Joan Cucchiara >>>> wrote: >>>>> >>>>> Tom and all, >>>>> >>>>> Unfortunately, my linux box is giving me grief this week (and I don't >>>>> have >>>>> access to my MIB tools). I'm getting some assistance >>>>> with it but won't be resolved until (hopefully) during the weekend. >>>>> >>>>> However, I looked over the doc and wanted to let you know that I stil= l >>>>> have >>>>> the same issue wrt to both SYNTAX and semantic >>>>> redefinition as before. You cannot narrow the range of values in a >>>>> DESCRIPTION clause which I see happens in mplsTunnelExtNodeConfigLoca= lId >>>>> and maybe in MplsNodeId TC as it says zero must not be used, but the= n >>>>> you >>>>> have it as part of allowable values in the SYNTAX. >>>>> >>>>> Whatever is specified in the DESCRIPTION clause for values, should be >>>>> reflected by the SYNTAX, right? >>>>> >>>>> Additionally, the SYNTAX below for MplsExtendedTunnelId allows any >>>>> Unsigned32 and says "may represent an IPv4 address". If (for whate= ver >>>>> reason) an >>>>> operator has configured something in the 1..16777216 (i.e. Local Id) >>>>> range, >>>>> for a regular TE Tunnel, that is perfectly legal, right? >>>>> >>>>> >>>>> MplsExtendedTunnelId ::=3D TEXTUAL-CONVENTION >>>>> STATUS current >>>>> DESCRIPTION >>>>> "A unique identifier for an MPLS Tunnel. This may >>>>> represent an IPv4 address of the ingress or egress >>>>> LSR for the tunnel. This value is derived from the >>>>> Extended Tunnel Id in RSVP or the Ingress Router ID >>>>> for CR-LDP." >>>>> REFERENCE >>>>> "RSVP-TE: Extensions to RSVP for LSP Tunnels, >>>>> [RFC3209]. >>>>> >>>>> Constraint-Based LSP Setup using LDP, [RFC3212]." >>>>> SYNTAX Unsigned32(0..4294967295) >>>>> >>>>> If the answer is Yes, then how would you add TP Tunnels using your dr= aft >>>>> if >>>>> an operator has a regular MPLS TE Tunnel configured >>>>> in the range 1..16777216 without having to ensure that any and all le= gacy >>>>> equipment be queried first? >>>>> >>>>> Thanks, >>>>> -Joan >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> From: Thomas Nadeau >>>>> To: Joan Cucchiara >>>>> Cc: Sam Aldrin ; Venkatesan Mahalingam ; Kannan KV Sampath >>>>> Sent: Thursday, August 09, 2012 8:58 AM >>>>> Subject: Re: draft-ietf-mpls-tp-te-mib-04.txt review request >>>>> >>>>> hi Joan >>>>> >>>>> hope you had a great vacation! ;) >>>>> >>>>> can you please follow up on the note below when you have a chance? >>>>> >>>>> Tom >>>>> >>>>> >>>>> >>>>> On Jul 16, 2012, at 9:13 AM, "Joan Cucchiara" >>>>> wrote: >>>>> >>>>> Sam, >>>>> >>>>> We are away this week returning on 7/23. Sorry, I can't review the = doc >>>>> until after 7/23 and it will >>>>> take a few days after that as I'll just be returning from vacation. >>>>> >>>>> I glanced at it and see that there are read-write objects in a row (w= hich >>>>> is >>>>> read-create) so that's >>>>> an error which I mentioned before. >>>>> >>>>> Have you compiled this with smilint? >>>>> >>>>> Thanks, >>>>> -Joan >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> From: Sam Aldrin >>>>> To: Joan Cucchiara >>>>> Cc: Venkatesan Mahalingam ; Thomas Nadeau ; Kannan KV Sampath >>>>> Sent: Friday, July 13, 2012 9:11 PM >>>>> Subject: Fwd: draft-ietf-mpls-tp-te-mib-04.txt review request >>>>> >>>>> Hi Joan, >>>>> >>>>> Please find the updated MIB document. Apologize for the delay. We pla= n to >>>>> publish the doc on Monday as it is the deadline before IETF. Diff fil= e is >>>>> attached as well. >>>>> >>>>> This version addresses all your comments. Highlighting couple of them= to >>>>> make sure you are OK with them >>>>> >>>>> 1. W.r.t mplsLocalID as index type, we have removed that using >>>>> MplsExtendedTunnelId itself. As the value range for this object could >>>>> have >>>>> value of non-IP address, we are using it. This will make the indices = for >>>>> the >>>>> same as TunnelTable. >>>>> In the definition of IngressLSRId and and EgressLSRId, for TP entries= , we >>>>> added description to use value of non-IP address, which is local ID. >>>>> >>>>> I do hope this satisfies the need and not necessitate for a new table >>>>> altogether for TP. >>>>> >>>>> 2. In regards to adding references to TC conventions. We believe, tho= se >>>>> were >>>>> added in the reference section. IF we have missed any TC references, >>>>> could >>>>> you kindly let us know. >>>>> >>>>> Appreciate if you can get back by Monday noon time PST. I know it is = a >>>>> very >>>>> short time, but appreciate if you could do that. >>>>> >>>>> thanks >>>>> -sam >>>>> >>>>> ________________________________ >>>>> >>>>> >>> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > > > ------------------------------ > > Message: 4 > Date: Fri, 17 Aug 2012 19:42:04 -0400 > From: Gregory Mirsky > To: John E Drake , Greg Mirsky > , Francesco Fondelli > > Cc: "mpls@ietf.org" , "ccamp@ietf.org" > Subject: Re: [mpls] [CCAMP] I-D Action: > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt > Message-ID: > > > Content-Type: text/plain; charset=3D"us-ascii" > > Hi John, > "The only difference is whether if one direction fails, the other directi= on is forced to fail." > Yes. And whether associated bidirectional LSP requires protection as sing= le bidirectional p2p construct or protection applies to each direction inde= pendently. But what happens to association in that case? Should protecting = unidirectional LSPs be associated with working and protecting unidirectiona= l LSPs of reverse direction before switchover? Consider working L1 A-Z and = L2 Z-A are protected by L3 A-Z and L4 Z-A accordingly. L1 and L2 form assoc= iated bidirectional p2p LSP. What about L3 and L2, L1 and L4, L3 and L4 - a= re these the same associated bi-directional LSP or not? > > Regards, > Greg > > PS. Even though most of MPLS WG is likely subscribed to CCAMP list, I'll = add MPLS WG to have opinions and comments from it. > > ________________________________ > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Friday, August 17, 2012 2:49 PM > To: Gregory Mirsky; Greg Mirsky; Francesco Fondelli > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-asso= ciated-lsp-04.txt > > Greg, > > It's not clear what 'monitored independently' means and whether it edicts= coordinated or independent mode. > > It really can't, because as I indicated previously, in both modes there i= s a bidirectional flow of control packets and in both modes there is a stre= am of CC/CV packets in each direction. The only difference is whether if o= ne direction fails, the other direction is forced to fail. > > I always thought independent mode was suspect and that requirement for it= was derived from the way Y.1731 worked, but I think it is equally suspect = for both associated and co-routed. > > Thanks, > > John > > Sent from my iPhone > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Friday, August 17, 2012 2:34 PM > To: John E Drake; Greg Mirsky; Francesco Fondelli > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-asso= ciated-lsp-04.txt > > John, > as Dave Allan pointed, RFC 6428 does not mandate how coordinated and inde= pendent modes should be used. But the very first sentence of Section 3.1 of= the document we're discussing says > "The associated bidirectional LSP's forward and backward directions are s= et up, monitored, and protected independently as required by [RFC5654]." And in RFC 5654, section 1.2.2 I indeed= find > "Associated bidirectional path: A path that supports traffic flow in both= directions but that is constructed from a pair of unidirectional paths (on= e for each direction) that are associated with one another at the path's in= gress/egress points. The forward and backward directions are setup, monito= red, and protected independently. As a consequence, they may or may not fo= llow the same route (links and nodes) across the network." > > I think there's no need for RFC 6428bis. Do you think there's need to rev= ise RFC 5654? > > Regards, > Greg > > > ________________________________ > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Friday, August 17, 2012 2:20 PM > To: Gregory Mirsky; Greg Mirsky; Francesco Fondelli > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-asso= ciated-lsp-04.txt > Greg, > > For both modes there is bidirectional flow of control packets. For Indep= endent mode the CC/CV packets flow in only one direction. > > There never was a coupling between modes and associated/co-routed and if = you can point me to any text that says the contrary I would appreciate it a= s a bis to remove that text would be required. > > Thanks, > > John > > Sent from my iPhone > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Friday, August 17, 2012 2:12 PM > To: John E Drake; Greg Mirsky; Francesco Fondelli > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-asso= ciated-lsp-04.txt > > Hi John, > in independent mode CC/CV control messages been sent only in one directio= n. Thus there are two CC/CV sessions - one for each independently monitored= direction. That, AFAIK, was intentional. > > Regards, > Greg > > ________________________________ > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Friday, August 17, 2012 1:50 PM > To: Gregory Mirsky; Greg Mirsky; Francesco Fondelli > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-asso= ciated-lsp-04.txt > Greg, > > That certainly wasn't the intent. With a bidirectional LSP of either typ= e you have one forward and one return path and BFD does not care whether th= ey are congruent. > > Thanks, > > John > > Sent from my iPhone > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Friday, August 17, 2012 1:28 PM > To: John E Drake; Greg Mirsky; Francesco Fondelli > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-asso= ciated-lsp-04.txt > > Hi John, > I think that bi-directional associated p2p LSP, regardless of how many co= mmon LSRs forward and reverse directions have, implies use of independent m= ode of RFC 6428, then there will be two sessions to monitor each direction = independently. Coordinated mode of RFC 6428, in my understanding, applies t= o bidirectional co-routed p2p LSP. > > Regards, > Greg > > ________________________________ > From: ccamp-bounces@ietf.org [mailto:ccamp= -bounces@ietf.org] On Behalf Of John E Drake > Sent: Friday, August 17, 2012 1:19 PM > To: Greg Mirsky; Francesco Fondelli > Cc: ccamp@ietf.org > Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-asso= ciated-lsp-04.txt > Greg, > > According to RFC 6428 the is one CC/CV/RDI session irregardless of whethe= r the bi-directional packet LSP is co-routed or associated. > > Thanks, > > John > > Sent from my iPhone > > From: ccamp-bounces@ietf.org [mailto:ccamp= -bounces@ietf.org] On Behalf Of Greg Mirsky > Sent: Friday, August 17, 2012 12:27 PM > To: Francesco Fondelli > Cc: ccamp@ietf.org > Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-asso= ciated-lsp-04.txt > > Hi Francesco, > "from a data-plane view point b) and c2) are the same thing" > I think that given that c) is associated bi-directional LSP that implies = independent OAM and protection for each direction, b) and c2) are not the s= ame in the data plane view. E.g., there will be single CC/CV/RDI session fo= r b) while c2) will have two sessions. And if linear protection requested, = b) will be protected by single bi-directional LSP, but c2) - by two unidire= ctional LSPs. > > Regards, > Greg > On Fri, Aug 17, 2012 at 1:48 AM, Francesco Fondelli > wrote: > Hi All, > > I think I'm lost, please help. > > Rakesh is talking about "co-routed associated bidirectional > LSP"... for the sake of clarity, let me try to categorize > LSPs from a control plane view point: > > a) Point-to-point unidirectional > b) Point-to-point co-routed bidirectional > c) Point-to-point associated bidirectional > c1) fwd and rev LSP follow different paths > c2) fwd and rev LSP follow same path > d) Point-to-multipoint unidirectional > e) Multipoint-to-point unidirectional > > Is section 3.2.5 (Signaling of Co-routed LSPs) of > mpls-tp-rsvpte-ext-associated-lsp about b) or it is about c2)? > > In my opinion: > > - b) should be signaled with 3473 > - c) are addressed by this I-D (mpls-tp-rsvpte-ext-associated-lsp) > > Am I missing something? > > thank you > ciao > fra > > PS > from a data-plane view point b) and c2) are the same thing. > > On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi (rgandhi) > > wrote: >> Hi Lou, >> >> Thanks for initiating discussions on the changes in the draft. >> >> Agree with you here, if we/WG do not agree on the "co-routed associated = bidirectional LSP" part, we are ok to remove it from this draft and can alw= ays submit a new draft just for that. We respect your/WG decision. >> >> Thanks, >> Rakesh >> >> >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Thursday, August 16, 2012 6:08 PM >> To: John E Drake >> Cc: Rakesh Gandhi (rgandhi); ccamp@ietf.org >> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-ass= ociated-lsp-04.txt >> >> John, >> While strictly speaking WG drafts should only reflect current WG = consensus, and it is the WG draft editor's job to ensure this, in practice = authors/editors are given a lot of latitude in timing / ordering in introdu= ction to changes. I personally think this is a practical way of keeping th= e process moving. Also if the WG disagrees with a change, it can always be= backed out. >> >> So, yes, the WG could do exactly as you say if it comes to it. (The cha= irs can even appoint different editor if needed, e.g., to make this >> happen.) While I'm not happy with how this revision came about, as I co= vered in earlier mail, my feeling is to let the discussion take place on th= e list (and at the next IETF, if needed) and then have the draft updated to= reflect the WG discussion/consensus. >> >> Lou >> >> On 8/16/2012 5:35 PM, John E Drake wrote: >>> Lou, >>> >>> Since the WG did not agree to this changes, let alone discuss them, >>> would it be possible to simply rollback these changes and ask the >>> authors to write a draft addressing the topics you list in your email, >>> below? >>> >>> Thanks, >>> >>> John >>> >>> Sent from my iPhone >>> >>> >>>> -----Original Message----- >>>> From: ccamp-bounces@ietf.org [mailto:cc= amp-bounces@ietf.org] On >>>> Behalf Of Lou Berger >>>> Sent: Thursday, August 16, 2012 2:10 PM >>>> To: Rakesh Gandhi (rgandhi) >>>> Cc: ccamp@ietf.org >>>> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>>> associated-lsp-04.txt >>>> >>>> Rakesh, >>>> Such major changes (in scope and functionality) to WG drafts are >>>> usually discussed with the WG prior to the authors/editors just >>>> publishing the changes. But, this is a judgment call by the document >>>> editors in how, quoting rfc2418, they "ensur[e] that the contents of >>>> the document accurately reflect the decisions that have been made by >>>> the working group." >>>> >>>> So let's jump into discussing the changes. >>>> >>>> As I see it this draft introduces several major functional changes >>>> that have not been discussed by the WG. Correct me if I get them >>>> wrong, but I believe they include: >>>> 1) Introduction of a second method for signaling Co-routed LSPs >>>> 2) Support for FRR bypass tunnels for piggybacked on the TP >>>> bidirectional LSP mechanisms. >>>> >>>> There are also other changes, but I'll defer discussing them >>>> until the discussion on the above is concluded. >>>> >>>> Is this correct? >>>> >>>> Assuming yes, I have questions about both rational and specific >>>> mechanisms. For now let's look at the former, so please: >>>> >>>> A) Articulate the issues/limitations with using the RFC3473 defined >>>> mechanisms for (co-routed) bidirectional LSPs that you'd like to see >>>> addressed. >>>> >>>> B.1) Articulate the FRR/GMPLS-related issue you'd like to address? >>>> >>>> B.2) Articulate why this issue should be solved in a TP-specific and >>>> not GMPLS generic fashion? >>>> >>>> Thanks, >>>> Lou >>>> >>>> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote: >>>>> Hi Lou, >>>>> >>>>> Yes. >>>>> >>>>> Please advise if you think detailed email is required. >>>>> We believe latest draft summarizes the changes well and we could >>>> start review/discussions from there. >>>>> >>>>> Thanks, >>>>> Rakesh >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>> Sent: Thursday, August 16, 2012 4:00 PM >>>>> To: Rakesh Gandhi (rgandhi) >>>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn >>>>> Subject: Re: [CCAMP] I-D Action: >>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>>> >>>>> Rakesh, >>>>> Is this the start of the thread that I requested in >>>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html >>>>> >>>>> In particular, is it the response to: >>>>>> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the >>>>>> proposed change and the rational for each change (in one or in >>>>>> separate e-mails). The WG discussion can then really begin on the >>>>>> proposed changes. (Which are quite substantial both in scope and >>>>>> implication.) >>>>> >>>>> Lou >>>>> >>>>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: >>>>>> Hi All, >>>>>> >>>>>> We have uploaded a new version of this draft with following changes: >>>>> >>>>> 1. Added a section on Signaling of Co-routed LSPs >>>>> >>>>> 2. Added clarification on Signaling of Associated Bidirectional >>>>> Protection LSPs >>>>> >>>>> 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs >>>>> >>>>> 4. Added clarification on Signaling of Inter-domain Associated >>>> Bidirectional LSPs >>>>> >>>>> 5. The Extended ASSOCIATION object format with Association Type >>>> "Associated Bidirectional LSP". Clarified on how to populate >>>> different fields in this object. >>>>> >>>>> >>>>>> We believe that some of these changes were necessary to avoid the >>>> interoperability issues due to potentially different interpretations. >>>>>> >>>>>> Your review comments are welcome. >>>>>> >>>>>> Thanks, >>>>>> Rakesh >>>>>> >>>>>> -----Original Message----- >>>>>> From: ccamp-bounces@ietf.org [mailto:= ccamp-bounces@ietf.org] On >>>>>> Behalf Of internet-drafts@ietf.org >>>>>> Sent: Wednesday, August 15, 2012 10:53 AM >>>>>> To: i-d-announce@ietf.org >>>>>> Cc: ccamp@ietf.org >>>>>> Subject: [CCAMP] I-D Action: >>>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>>>> >>>>>> >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>>>> This draft is a work item of the Common Control and Measurement >>>> Plane Working Group of the IETF. >>>>>> >>>>>> Title : RSVP-TE Extensions for Associated Bidirectional >>>> LSPs >>>>>> Author(s) : Fei Zhang >>>>>> Ruiquan Jing >>>>>> Rakesh Gandhi >>>>>> Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated- >>>> lsp-04.txt >>>>>> Pages : 17 >>>>>> Date : 2012-08-15 >>>>>> >>>>>> Abstract: >>>>>> The MPLS Transport Profile (MPLS-TP) requirements document >>>> [RFC5654], >>>>>> describes that MPLS-TP MUST support associated bidirectional >>>> point- >>>>>> to-point LSPs. >>>>>> >>>>>> This document provides a method to bind two unidirectional Label >>>>>> Switched Paths (LSPs) into an associated bidirectional LSP. The >>>>>> association is achieved by defining the new Association Type in >>>> the >>>>>> Extended ASSOCIATION object. >>>>>> >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte- >>>> ext- >>>>>> a >>>>>> ssociated-lsp >>>>>> >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>>> associ >>>>>> a >>>>>> ted-lsp-04 >>>>>> >>>>>> A diff from the previous version is available at: >>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte- >>>> ext- >>>>>> a >>>>>> ssociated-lsp-04 >>>>>> >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>> _______________________________________________ >>>>>> CCAMP mailing list >>>>>> CCAMP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> CCAMP mailing list >>>> CCAMP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ccamp >>> >>> >>> >>> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > End of mpls Digest, Vol 100, Issue 32 > ************************************* > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From kireeti@juniper.net Mon Aug 20 11:30: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 0874821F8600 for ; Mon, 20 Aug 2012 11:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 Cx4MQnFZGfHw for ; Mon, 20 Aug 2012 11:30:40 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFC921F85FF for ; Mon, 20 Aug 2012 11:30:40 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUDKCS1UZ+chLOOT31XSl/y6Em8VqVZBK@postini.com; Mon, 20 Aug 2012 11:30:40 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 20 Aug 2012 11:29:35 -0700 From: Kireeti Kompella To: "adrian@olddog.co.uk" Date: Mon, 20 Aug 2012 11:29:34 -0700 Thread-Topic: AD review of draft-ietf-mpls-entropy-label Thread-Index: Ac1/Ab/AYj8jB9j7RhKhVh8LlAgcPg== Message-ID: References: <0dc501cd7bb1$d318ad10$794a0730$@olddog.co.uk> <0edf01cd7c43$94feec00$befcc400$@olddog.co.uk> <3E2B22DB-9FF6-41D0-92C3-85E25FF57ECF@juniper.net> <10c101cd7d65$7bd332e0$737998a0$@olddog.co.uk> In-Reply-To: <10c101cd7d65$7bd332e0$737998a0$@olddog.co.uk> 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 Cc: "mpls@ietf.org" , "draft-ietf-mpls-entropy-label@tools.ietf.org" Subject: Re: [mpls] AD review of draft-ietf-mpls-entropy-label 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, 20 Aug 2012 18:30:41 -0000 On Aug 18, 2012, at 10:18 , Adrian Farrel wrote: > Yeah, and it is great that you give a reason for doing it, but by using S= HOULD > you have to explain why you might vary. That was what my MAY sentence was= trying > to do. If I got the reason wrong then sorry, please add your own reason. Okay. Proposed text: X MAY choose different values for the TTL and TC fields if it is known that the ELI will not be exposed as the top label at any point along the LSP. If this is acceptable, can this wait, or should we spin an -06? Kireeti. > But if > your reason is, because there might turn out to be a reason one day in th= e > future, then use MUST and write a new I-D sometime in the future. >=20 > A >=20 >> -----Original Message----- >> From: Kireeti Kompella [mailto:kireeti@juniper.net] >> Sent: 17 August 2012 19:02 >> To: adrian@olddog.co.uk >> Cc: Kireeti Kompella; draft-ietf-mpls-entropy-label@tools.ietf.org; > mpls@ietf.org >> Subject: Re: AD review of draft-ietf-mpls-entropy-label >>=20 >> On Aug 16, 2012, at 23:43 , Adrian Farrel wrote: >>=20 >>> So... >>> OLD >>> X SHOULD put the same TTL and TC fields for the ELI as >>> it does for TL. >>> NEW >>> X SHOULD put the same TTL and TC fields for the ELI as >>> it does for TL to protect LSP behavior in cases where PHP is used >>> and the ELI and EL are not stripped at the previous hop (see Section >>> 4.4). If it is known that PHP is not used or that PHP will strip the E= LI >>> and EL, the TTL and TC of the ELI MAY be set differently. >>> END >>=20 >> X will likely be blissfully unaware of whether PHP will be used (and whe= ther > the >> PHP LSR will pop ELI+EL), unless this is a very short LSP. >>=20 >>> ***or*** >>>=20 >>> s/SHOULD/MUST/ >>=20 >> I have a pathological fear of MUST. >>=20 >> How about: >>=20 >> NEW >> X SHOULD put the same TTL and TC fields for the ELI as >> it does for TL. This protects LSP behavior in cases where PHP is used >> and the ELI and EL are not stripped at the penultimate hop (see Section >> 4.4). >> END >>=20 >> I'd better get out a new version before the list of things to do gets an= y > longer. >>=20 >> Kireeti.=3D >=20 From kireeti@juniper.net Mon Aug 20 11:38: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 613F321F84D5 for ; Mon, 20 Aug 2012 11:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 4tijv6n3BsSs for ; Mon, 20 Aug 2012 11:38:02 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id D50CC21F84D2 for ; Mon, 20 Aug 2012 11:38:01 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUDKEANcfadjgZQRqGMwSs1DMA8d9IXxG@postini.com; Mon, 20 Aug 2012 11:38:01 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 20 Aug 2012 11:37:40 -0700 From: Kireeti Kompella To: "adrian@olddog.co.uk" Date: Mon, 20 Aug 2012 11:37:38 -0700 Thread-Topic: AD review of draft-ietf-mpls-entropy-label Thread-Index: Ac1/AuBrt4NG4vEBTYKWZ3r4WaNOuw== Message-ID: References: <0dc501cd7bb1$d318ad10$794a0730$@olddog.co.uk> <0edf01cd7c43$94feec00$befcc400$@olddog.co.uk> <3E2B22DB-9FF6-41D0-92C3-85E25FF57ECF@juniper.net> <10c101cd7d65$7bd332e0$737998a0$@olddog.co.uk> In-Reply-To: <10c101cd7d65$7bd332e0$737998a0$@olddog.co.uk> 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 Cc: "mpls@ietf.org" , "draft-ietf-mpls-entropy-label@tools.ietf.org" Subject: Re: [mpls] AD review of draft-ietf-mpls-entropy-label 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, 20 Aug 2012 18:38:02 -0000 While we're on the subject, I'd like to make another change -- a clarificat= ion. section 4.3: OLD: If a transit LSR recognizes the ELI, it MAY choose to load balance solely on the following label (the EL); otherwise, it SHOULD use as much of the whole label stack as feasible as keys for the load balancing function, with the exception that reserved labels MUST NOT be used. NEW: If a transit LSR recognizes the ELI, it MAY choose to load balance solely on the following label (the EL); otherwise, it SHOULD use as much of the whole label stack as feasible as keys for the load balancing function. In any case, reserved labels MUST NOT be used as keys for the load balancing function. Kireeti. PS: there, you see, I do (sometimes) use MUST/MUST NOT. From adrian@olddog.co.uk Mon Aug 20 11: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 486BF21F854B for ; Mon, 20 Aug 2012 11:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 hx5guK1wONuf for ; Mon, 20 Aug 2012 11:40:25 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 4954121F84F5 for ; Mon, 20 Aug 2012 11:40:25 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7KIeNTp020456; Mon, 20 Aug 2012 19:40:23 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7KIeMWW020438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 20 Aug 2012 19:40:22 +0100 From: "Adrian Farrel" To: "'Kireeti Kompella'" References: <0dc501cd7bb1$d318ad10$794a0730$@olddog.co.uk> <0edf01cd7c43$94feec00$befcc400$@olddog.co.uk> <3E2B22DB-9FF6-41D0-92C3-85E25FF57ECF@juniper.net> <10c101cd7d65$7bd332e0$737998a0$@olddog.co.uk> In-Reply-To: Date: Mon, 20 Aug 2012 19:40:21 +0100 Message-ID: <129201cd7f03$4168d070$c43a7150$@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: AQHPHuSqRl1cgpHy+Pw5z8k+/Sb7UAKzUXN9AjoNQFkBrUf7lwK6ATZgAofJsNqXAOTZAA== Content-Language: en-gb Cc: mpls@ietf.org, draft-ietf-mpls-entropy-label@tools.ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-entropy-label 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: Mon, 20 Aug 2012 18:40:26 -0000 Hi, Take it as an IETF last call comment (since I already started IETF last call). Thanks, Adrian > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: 20 August 2012 19:30 > To: adrian@olddog.co.uk > Cc: Kireeti Kompella; draft-ietf-mpls-entropy-label@tools.ietf.org; mpls@ietf.org > Subject: Re: AD review of draft-ietf-mpls-entropy-label > > On Aug 18, 2012, at 10:18 , Adrian Farrel wrote: > > > Yeah, and it is great that you give a reason for doing it, but by using SHOULD > > you have to explain why you might vary. That was what my MAY sentence was > trying > > to do. If I got the reason wrong then sorry, please add your own reason. > > Okay. Proposed text: > > X MAY choose different values for the TTL and TC fields if it is > known that the ELI will not be exposed as the top label at any point > along the LSP. > > If this is acceptable, can this wait, or should we spin an -06? > > Kireeti. > > > But if > > your reason is, because there might turn out to be a reason one day in the > > future, then use MUST and write a new I-D sometime in the future. > > > > A > > > >> -----Original Message----- > >> From: Kireeti Kompella [mailto:kireeti@juniper.net] > >> Sent: 17 August 2012 19:02 > >> To: adrian@olddog.co.uk > >> Cc: Kireeti Kompella; draft-ietf-mpls-entropy-label@tools.ietf.org; > > mpls@ietf.org > >> Subject: Re: AD review of draft-ietf-mpls-entropy-label > >> > >> On Aug 16, 2012, at 23:43 , Adrian Farrel wrote: > >> > >>> So... > >>> OLD > >>> X SHOULD put the same TTL and TC fields for the ELI as > >>> it does for TL. > >>> NEW > >>> X SHOULD put the same TTL and TC fields for the ELI as > >>> it does for TL to protect LSP behavior in cases where PHP is used > >>> and the ELI and EL are not stripped at the previous hop (see Section > >>> 4.4). If it is known that PHP is not used or that PHP will strip the ELI > >>> and EL, the TTL and TC of the ELI MAY be set differently. > >>> END > >> > >> X will likely be blissfully unaware of whether PHP will be used (and whether > > the > >> PHP LSR will pop ELI+EL), unless this is a very short LSP. > >> > >>> ***or*** > >>> > >>> s/SHOULD/MUST/ > >> > >> I have a pathological fear of MUST. > >> > >> How about: > >> > >> NEW > >> X SHOULD put the same TTL and TC fields for the ELI as > >> it does for TL. This protects LSP behavior in cases where PHP is used > >> and the ELI and EL are not stripped at the penultimate hop (see Section > >> 4.4). > >> END > >> > >> I'd better get out a new version before the list of things to do gets any > > longer. > >> > >> Kireeti.= > > From adrian@olddog.co.uk Mon Aug 20 11:42: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 C30A821F8606 for ; Mon, 20 Aug 2012 11:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 qywrn+zLA6Nl for ; Mon, 20 Aug 2012 11:42:01 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 05A7621F84F5 for ; Mon, 20 Aug 2012 11:42:00 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7KIfxV0001564; Mon, 20 Aug 2012 19:41:59 +0100 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 q7KIfwnl001544 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 20 Aug 2012 19:41:58 +0100 From: "Adrian Farrel" To: "'Kireeti Kompella'" References: <0dc501cd7bb1$d318ad10$794a0730$@olddog.co.uk> <0edf01cd7c43$94feec00$befcc400$@olddog.co.uk> <3E2B22DB-9FF6-41D0-92C3-85E25FF57ECF@juniper.net> <10c101cd7d65$7bd332e0$737998a0$@olddog.co.uk> In-Reply-To: Date: Mon, 20 Aug 2012 19:41:57 +0100 Message-ID: <129401cd7f03$7aa67090$6ff351b0$@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: AQHPHuSqRl1cgpHy+Pw5z8k+/Sb7UAKzUXN9AjoNQFkBrUf7lwK6ATZgATWL1IeXC3dO4A== Content-Language: en-gb Cc: mpls@ietf.org, draft-ietf-mpls-entropy-label@tools.ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-entropy-label 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: Mon, 20 Aug 2012 18:42:01 -0000 Yes, I like that. Store it up as another last call comment. A (PS, thanks for keeping these comments public to the MPLS WG. That really helps) > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: 20 August 2012 19:38 > To: adrian@olddog.co.uk > Cc: Kireeti Kompella; draft-ietf-mpls-entropy-label@tools.ietf.org; mpls@ietf.org > Subject: Re: AD review of draft-ietf-mpls-entropy-label > > While we're on the subject, I'd like to make another change -- a clarification. > > section 4.3: > > OLD: > > If a transit LSR recognizes the ELI, it MAY choose to load balance > solely on the following label (the EL); otherwise, it SHOULD use as > much of the whole label stack as feasible as keys for the load > balancing function, with the exception that reserved labels MUST NOT > be used. > > NEW: > > If a transit LSR recognizes the ELI, it MAY choose to load balance > solely on the following label (the EL); otherwise, it SHOULD use as > much of the whole label stack as feasible as keys for the load > balancing function. In any case, reserved labels MUST NOT be used > as keys for the load balancing function. > > Kireeti. > > PS: there, you see, I do (sometimes) use MUST/MUST NOT. From jdrake@juniper.net Mon Aug 20 11:56: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 1BF4421F84F5 for ; Mon, 20 Aug 2012 11:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.757 X-Spam-Level: X-Spam-Status: No, score=-5.757 tagged_above=-999 required=5 tests=[AWL=0.842, 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 BEoEudltCU9D for ; Mon, 20 Aug 2012 11:56:43 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 85D2F21F855B for ; Mon, 20 Aug 2012 11:56:43 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUDKIZN+s4e+KD4u7Gtsq0nQnc6+T/E4Q@postini.com; Mon, 20 Aug 2012 11:56:43 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 20 Aug 2012 11:55:48 -0700 From: John E Drake To: Kireeti Kompella , "adrian@olddog.co.uk" Date: Mon, 20 Aug 2012 11:55:46 -0700 Thread-Topic: AD review of draft-ietf-mpls-entropy-label Thread-Index: Ac1/AuBrt4NG4vEBTYKWZ3r4WaNOuwAAdTPA Message-ID: <5E893DB832F57341992548CDBB333163A632037585@EMBX01-HQ.jnpr.net> References: <0dc501cd7bb1$d318ad10$794a0730$@olddog.co.uk> <0edf01cd7c43$94feec00$befcc400$@olddog.co.uk> <3E2B22DB-9FF6-41D0-92C3-85E25FF57ECF@juniper.net> <10c101cd7d65$7bd332e0$737998a0$@olddog.co.uk> In-Reply-To: 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 Cc: "mpls@ietf.org" , "draft-ietf-mpls-entropy-label@tools.ietf.org" Subject: Re: [mpls] AD review of draft-ietf-mpls-entropy-label 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, 20 Aug 2012 18:56:44 -0000 Kireeti, In the last sentence of your proposed text, I think it would be clearer if = we changed "In any case" to "Irregardless", which, according to Webster's T= hird New International, is a blend of 'irrespective' and 'regardless'. Thanks, John Sent from my iPhone > -----Original Message----- > From: Kireeti Kompella > Sent: Monday, August 20, 2012 11:38 AM > To: adrian@olddog.co.uk > Cc: Kireeti Kompella; draft-ietf-mpls-entropy-label@tools.ietf.org; > mpls@ietf.org > Subject: Re: AD review of draft-ietf-mpls-entropy-label >=20 > While we're on the subject, I'd like to make another change -- a > clarification. >=20 > section 4.3: >=20 > OLD: >=20 > If a transit LSR recognizes the ELI, it MAY choose to load balance > solely on the following label (the EL); otherwise, it SHOULD use as > much of the whole label stack as feasible as keys for the load > balancing function, with the exception that reserved labels MUST NOT > be used. >=20 > NEW: >=20 > If a transit LSR recognizes the ELI, it MAY choose to load balance > solely on the following label (the EL); otherwise, it SHOULD use as > much of the whole label stack as feasible as keys for the load > balancing function. In any case, reserved labels MUST NOT be used > as keys for the load balancing function. >=20 > Kireeti. >=20 > PS: there, you see, I do (sometimes) use MUST/MUST NOT. From tnadeau@lucidvision.com Mon Aug 20 12:31: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 6F0EE21F853A for ; Mon, 20 Aug 2012 12:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 pR1NCPxbt82Q for ; Mon, 20 Aug 2012 12:31:54 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 91C0721F8532 for ; Mon, 20 Aug 2012 12:31:54 -0700 (PDT) Received: from [172.28.131.12] (westford-nat.juniper.net [66.129.232.2]) by lucidvision.com (Postfix) with ESMTP id 13C272259408; Mon, 20 Aug 2012 15:31:52 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Thomas Nadeau In-Reply-To: <24256.1343077448@erosen-linux> Date: Mon, 20 Aug 2012 15:31:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <40F8AA95-FD9E-4D3A-BFC5-D4BE04DC7605@lucidvision.com> References: <24256.1343077448@erosen-linux> To: erosen@cisco.com X-Mailer: Apple Mail (2.1485) Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , Giles Heron Subject: Re: [mpls] MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-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, 20 Aug 2012 19:31:55 -0000 On Jul 23, 2012:5:04 PM, at 5:04 PM, Eric Rosen = wrote: > Pranjal> This draft does not change or violate procedures defined in = RFC > Pranjal> 5036. It proposes an OPTIONAL method of reduction of = "targeted' > Pranjal> hellos (only - as the name of the draft suggests) and the = proposed > Pranjal> method is backward compatible with procedures defined in RFC > Pranjal> 5036. The method uses the hello timeout negotiation = procedures as > Pranjal> per RFC 5036 without any changes in negotiation procedures. >=20 > If the draft does not change any of the procedures specified in RFC = 5036, > and does not define any new procedures or messages either, then why is = the > draft marked as "standards track"? At best it would be = "Informational". > But are you saying that all the draft really does is to suggest that a > particular parameter be set to a particular value? That doesn't seem = like > very much content. >=20 > Pranjal> The reduction of hellos provides probabilistically better > Pranjal> resiliency on maintenance of hello adjacency during sporadic = DoS > Pranjal> attacks. Sporadic DoS attacks on UDP port 646 can result in = loss of > Pranjal> "good" hello packets for certain period of time and thus = leading to > Pranjal> loss of existing adjacencies. >=20 > If an attacker can send you UDP packets on port 646, why doesn't he = make > them look like Hello packets specifying a short hold time? That's a = much > more effective attack than a "sporadic DoS attack". In fact, if real = Hellos > are not being sent at all, it just becomes easier to mount an attack = with a > spoofed Hello. An attacker could send a spoofed Hello with a hold = time of 3 > days, and the session would stay up for a few days and then fail > mysteriously, for no apparent reason. An attack whose effects are not = felt > until days later can be quite hard to deal with. When the Hellos are = sent > periodically, on the other hand, there is a self-correction mechanism = that > prevents this. >=20 > If you want to reduce the targeted Hello load, it might be better to = invent > a way (i.e., a protocol change) of turning them off entirely after the > session comes up, so that arriving Hellos are just discarded. ( >=20 > BTW, the draft asserts that the periodic Hellos have no value that is = not > better served by either BFD or the LDP session keepalives. I don't = know > whether that's true, but it would be nice to see an argument with a = little > more substance. Just following up on some old emails and I noticed this one. I = am not sure if you recall, but this was discussed when we originally = presented the draft (something like 2+ years ago). In effect that is = what we are saying with the draft. Since BFD Hellos are used to maintain = liveliness now in most implementations, the hellos that are sent after = the sessions are established are superfluous. Perhaps too much emphasis = was placed on the security aspects versus the optimization nature of the = solution, but that is the general idea. A side-effect are the potential = security benefits. =20 Keep in mind too that when this was discussed originally, we did = ask the WG whether or not to take Luca's suggestion of re-writing the = LDP spec to fix this and a few other issues or just do this simple = optimization; the guidance we received was to take the optimization = route on this one as it seemed simple, quick and effective. --Tom >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From internet-drafts@ietf.org Tue Aug 21 00:55: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 CB8EE21F8623; Tue, 21 Aug 2012 00:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[AWL=0.222, 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 s36u6kCUpYOh; Tue, 21 Aug 2012 00:55:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CBD21F862A; Tue, 21 Aug 2012 00:55:31 -0700 (PDT) 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.33 Message-ID: <20120821075531.29235.51172.idtracker@ietfa.amsl.com> Date: Tue, 21 Aug 2012 00:55:31 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-return-path-specified-lsp-ping-07.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, 21 Aug 2012 07:55:32 -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 : Return Path Specified LSP Ping Author(s) : Mach(Guoyi) Chen Wei Cao So Ning Frederic Jounay Simon Delord Filename : draft-ietf-mpls-return-path-specified-lsp-ping-07.txt Pages : 21 Date : 2012-08-21 Abstract: This document defines extensions to the failure-detection protocol for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) known as "LSP Ping" that allow selection of the LSP to use for the echo reply return path. Enforcing a specific return path can be used to verify bidirectional connectivity and also increase LSP ping robustness. It may also be used by Bidirectional Forwarding Detection (BFD) for MPLS bootstrap signaling thereby making BFD for MPLS more robust. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-return-path-specified-lsp-= ping There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-return-path-specified-lsp-ping-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-return-path-specified-ls= p-ping-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From thomas.morin@orange.com Tue Aug 21 05:07: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 D1CED21F8671 for ; Tue, 21 Aug 2012 05:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.188 X-Spam-Level: X-Spam-Status: No, score=-6.188 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 ilNjvOPvy04n for ; Tue, 21 Aug 2012 05:07:05 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8F10521F8682 for ; Tue, 21 Aug 2012 05:07:04 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6A0277D4001 for ; Tue, 21 Aug 2012 14:07:03 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 5C6714110B7 for ; Tue, 21 Aug 2012 14:07:03 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Aug 2012 14:07:02 +0200 Received: from [10.193.71.23] ([10.193.71.23]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Aug 2012 14:07:02 +0200 Message-ID: <50337A1C.5070405@orange.com> Date: Tue, 21 Aug 2012 14:07:56 +0200 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: mpls@ietf.org References: <105EB9F002CB164DA9ADD111BFC4DCFF1C957F24@EMBX02-BNG.jnpr.net> <105EB9F002CB164DA9ADD111BFC4DCFF1C95811D@EMBX02-BNG.jnpr.net> In-Reply-To: <105EB9F002CB164DA9ADD111BFC4DCFF1C95811D@EMBX02-BNG.jnpr.net> Content-Type: multipart/alternative; boundary="------------090604050607090304090004" X-OriginalArrivalTime: 21 Aug 2012 12:07:02.0711 (UTC) FILETIME=[7964B470:01CD7F95] Subject: Re: [mpls] DISCUSS///RE: wg doc poll on draft-jin-mpls-mldp-leaf-discovery-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: Tue, 21 Aug 2012 12:07:05 -0000 This is a multi-part message in MIME format. --------------090604050607090304090004 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi WG, Chandra, Chandrasekar R: > [...]Aggregating an in-band multicast flow with flows of different > application also increasing complexity is not a convincing motivation. > Yes, you are putting the finger on precisely on a point I had discussed with the authors. Due to the fact that you cannot aggregate together two in-band signalled P2MP LSPs, the only aggregation you can do involving in-band signalled LSPs will provide very limited gains, because it will not provide a significant gain (not an order of magnitude gain, at best a factor 2), and be much more constrained that the aggregation that can be done. Worse, trying to marginally optimize by aggregating single in-band signalled LSPs into service LSPs, will actually make the aggregation of these service LSPs more constrained and less efficient. A patent looking for a problem ? -Thomas > > *From:*lizhong.jin@zte.com.cn [mailto:lizhong.jin@zte.com.cn] > *Sent:* Friday, August 10, 2012 6:55 AM > *To:* Chandrasekar R > *Cc:* erosen@cisco.com; mpls@ietf.org; mpls-chairs@tools.ietf.org > *Subject:* DISCUSS///RE: [mpls] wg doc poll on > draft-jin-mpls-mldp-leaf-discovery-04 > > > Chandra, > Thanks for the comments. See reply below. > > Lizhong > > > Chandrasekar R > wrote > 2012/08/10 01:21:41: > > > HI Lizhong, > > > > [Lizhong] PE1 have the tunnel >. Then > > when PE1 initiates new MVPN service, and has leaf member PE2, PE3, > > PE4, then PE1 is not necessary to initiate new mLDP tunnel, but > > directly aggreate to tunnel > for > > MVPN service. If PE1 does not have the leaf information of tunnel > > >, then PE1 could not aggregate MVPN > > service to that tunnel. And Leaf A-D route in MVPN could not help > > PE1 to find the leaf information of tunnel > value=>. That means two different kind of applications could > > share one tunnel which is this draft trying to solve. > > > [Chandra] How does the leaf PE differentiate between the mLDP > > traffic (S1, G1) and the MVPN traffic whose source/group addresses > > could be on a different address space? > [Lizhong] If MVPN would aggregate I/S-PMSI onto one tunnel, it should > certainly advertise upstream label which is specified in RFC6514. The > upstream label would be used to demultiplex the MVPN traffic. Only the > mLDP traffic (S1, G1) will not have upstream label, and could be > differentiated by leaf PE. Note that PHP would be disabled for this > mLDP tunnel. > > > > > If aggregating mLDP tunnels across different applications is the > > primary goal of the draft, then we should first establish whether > > the traffic of those applications can be actually aggregated. > [Lizhong] right, and as I know, the applications listed in the draft > already has upstream label advertisement in their respective RFC/Draft. > > > > Regards, > > Chandra. > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --------------090604050607090304090004 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi WG, Chandra,

Chandrasekar R:
[...] Aggregating an in-band multicast flow with flows of different application also increasing complexity is not a convincing motivation.

 


Yes, you are putting the finger on precisely on a point I had discussed with the authors.

Due to the fact that you cannot aggregate together two in-band signalled P2MP LSPs, the only aggregation you can do involving in-band signalled LSPs will provide very limited gains, because it will not provide a significant gain (not an order of magnitude gain, at best a factor 2), and be much more constrained that the aggregation that can be done.  Worse, trying to marginally optimize by aggregating single in-band signalled LSPs into service LSPs, will actually make the aggregation of these service LSPs more constrained and less efficient.

A patent looking for a problem ?

-Thomas

From: lizhong.jin@zte.com.cn [mailto:lizhong.jin@zte.com.cn]
Sent: Friday, August 10, 2012 6:55 AM
To: Chandrasekar R
Cc: erosen@cisco.com; mpls@ietf.org; mpls-chairs@tools.ietf.org
Subject: DISCUSS///RE: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-04

 


Chandra,
Thanks for the comments. See reply below.

Lizhong


Chandrasekar R <csekar@juniper.net> wrote 2012/08/10 01:21:41:

> HI Lizhong,
>  
> [Lizhong] PE1 have the tunnel <root=PE1, opaque value=<S1,G1>>. Then
> when PE1 initiates new MVPN service, and has leaf member PE2, PE3,
> PE4, then PE1 is not necessary to initiate new mLDP tunnel, but
> directly aggreate to tunnel <root=PE1, opaque value=<S1,G1>> for
> MVPN service. If PE1 does not have the leaf information of tunnel
> <root=PE1, opaque value=<S1,G1>>, then PE1 could not aggregate MVPN
> service to that tunnel. And Leaf A-D route in MVPN could not help
> PE1 to find the leaf information of tunnel <root=PE1, opaque
> value=<S1,G1>>. That means two different kind of applications could
> share one tunnel which is this draft trying to solve.

> [Chandra] How does the leaf PE differentiate between the mLDP
> traffic (S1, G1) and the MVPN traffic whose source/group addresses
> could be on a different address space?
[Lizhong] If MVPN would aggregate I/S-PMSI onto one tunnel, it should certainly advertise upstream label which is specified in RFC6514. The upstream label would be used to demultiplex the MVPN traffic. Only the mLDP traffic (S1, G1) will not have upstream label, and could be differentiated by leaf PE. Note that PHP would be disabled for this mLDP tunnel.

>  
> If aggregating mLDP tunnels across different applications is the
> primary goal of the draft, then we should first establish whether
> the traffic of those applications can be actually aggregated.
[Lizhong] right, and as I know, the applications listed in the draft already has upstream label advertisement in their respective RFC/Draft.
>  
> Regards,
> Chandra.



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

--------------090604050607090304090004-- From thomas.morin@orange.com Tue Aug 21 05:09: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 E7D1221F866D for ; Tue, 21 Aug 2012 05:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 Jh3YNZ2bb7SI for ; Tue, 21 Aug 2012 05:09:57 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 55F6321F866A for ; Tue, 21 Aug 2012 05:09:57 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 13CB4E301B3 for ; Tue, 21 Aug 2012 14:12:03 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 0E73EE301B2 for ; Tue, 21 Aug 2012 14:12:03 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Aug 2012 14:09:56 +0200 Received: from [10.193.71.23] ([10.193.71.23]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Aug 2012 14:09:55 +0200 Message-ID: <50337AC9.1060103@orange.com> Date: Tue, 21 Aug 2012 14:10:49 +0200 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: mpls@ietf.org References: <5017CB64.9070507@pi.nu> In-Reply-To: <5017CB64.9070507@pi.nu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Aug 2012 12:09:55.0792 (UTC) FILETIME=[E08EC500:01CD7F95] Subject: Re: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-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: Tue, 21 Aug 2012 12:09:58 -0000 Do not support. As explained in a parallel post, I think the the gain/complexity balance is heavily tilted on the complexity side. -Thomas Loa Andersson : > Working group, > > this is to start a two week poll on adopting > draft-jin-mpls-mldp-leaf-discovery-04 > as an MPLS working group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). > > This poll ends August 17, 2012. > > /Loa > (mpls wg co-chair) From curtis@occnc.com Tue Aug 21 06:52: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 9C21D21F84F3 for ; Tue, 21 Aug 2012 06:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.409 X-Spam-Level: X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, NO_RELAYS=-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 GLVoOOmEBX-z for ; Tue, 21 Aug 2012 06:52:54 -0700 (PDT) Received: from gateway2.orleans.occnc.com (gateway2.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:145]) by ietfa.amsl.com (Postfix) with ESMTP id 232CE21F84F2 for ; Tue, 21 Aug 2012 06:52:53 -0700 (PDT) Received: from harbor2.ipv6.occnc.com (harbor2.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:404]) (authenticated bits=0) by gateway2.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q7LDqnA9039010; Tue, 21 Aug 2012 09:52:49 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208211352.q7LDqnA9039010@gateway2.orleans.occnc.com> To: Kireeti Kompella From: Curtis Villamizar In-reply-to: Your message of "Mon, 20 Aug 2012 11:10:47 PDT." Date: Tue, 21 Aug 2012 09:52:49 -0400 Cc: "mpls@ietf.org" , Vivek Kumar Subject: Re: [mpls] Question regarding MPLS reserved label with ECMP 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: Tue, 21 Aug 2012 13:52:54 -0000 In message Kireeti Kompella writes: > On Aug 18, 2012, at 4:45 , Vivek Kumar wrote: > > > Hi , > > I have one question regarding whether MPLS reserved label should be used or skipped when Transit LSR is doing hashing on full label stack which has some reserved label. > > draft-ietf-mpls-entropy-label, section 4.3: > > If a transit LSR recognizes the ELI, it MAY choose to load balance > solely on the following label (the EL); otherwise, it SHOULD use as > much of the whole label stack as feasible as keys for the load > balancing function, with the exception that reserved labels MUST NOT > be used. > > > RFC 6391 , section 7 , says " Note that, depending on the number of labels hashed by the LSR, the > > inclusion of the Router Alert label may cause the OAM packet to be > > load-balanced to a different path from that taken by the data packets > > with identical flow and PW labels". > > > > The above comment implies that reserved label is used by LSR when doing hashing for ECMP. > > > > Is there any other RFC which states what should be the correct behavior. > > > > The draft " draft-ietf-mpls-entropy-label-05" section 4.3 , says reserved label should not be used by LSR when doing hashing on label stack. > > > > > > Regards, > > Vivek Kireeti, entropy-label may be the first place where this advice has been given and it is good that it is finally somewhere. If there is a GAL that is also a reason not to hash on a reserved label. The path with or without GAL should be the same. The word "may" in "may cause" in the quoted statement from RFC 6391 is significant. Some routers hash on everything they find. This is a bad practice, but exists. Curtis From rcallon@juniper.net Tue Aug 21 08: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 137E321F8763 for ; Tue, 21 Aug 2012 08:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.53 X-Spam-Level: X-Spam-Status: No, score=-106.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, 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 gYewLHOPaHTb for ; Tue, 21 Aug 2012 08:11:54 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 4B67021F86FC for ; Tue, 21 Aug 2012 08:11:51 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUDOlM2vyfWRFjmwSGqGvuNSLde0mlP5a@postini.com; Tue, 21 Aug 2012 08:11:52 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 21 Aug 2012 08:11:03 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 21 Aug 2012 11:10:16 -0400 From: Ross Callon To: "mpls@ietf.org" Date: Tue, 21 Aug 2012 11:10:15 -0400 Thread-Topic: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-04 Thread-Index: Ac1vFZx0mKyyBs3FQrC55+0Yzf5N+gQmSWlA Message-ID: References: <5017CB64.9070507@pi.nu> In-Reply-To: <5017CB64.9070507@pi.nu> 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 Cc: Ross Callon Subject: Re: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-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: Tue, 21 Aug 2012 15:11:55 -0000 This poll has now ended. We do not have consensus to accept this document a= s a WG document.=20 Ross (for the WG chairs) -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Tuesday, July 31, 2012 8:11 AM To: mpls@ietf.org; Martin Vigoureux Cc: mpls-chairs@tools.ietf.org Subject: [mpls] wg doc poll on draft-jin-mpls-mldp-leaf-discovery-04 Working group, this is to start a two week poll on adopting draft-jin-mpls-mldp-leaf-discovery-04 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll ends August 17, 2012. /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 david.i.allan@ericsson.com Tue Aug 21 10:29: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 E8C2921F86E4 for ; Tue, 21 Aug 2012 10:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.064 X-Spam-Level: X-Spam-Status: No, score=-4.064 tagged_above=-999 required=5 tests=[AWL=-1.669, 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 dRCSlDUORPuw for ; Tue, 21 Aug 2012 10:29:05 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2460921F86CE for ; Tue, 21 Aug 2012 10:29:04 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q7LHT35s006330 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Aug 2012 12:29:03 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.2.164]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 21 Aug 2012 13:29:02 -0400 From: David Allan I To: "zhang.fei3@zte.com.cn" , Gregory Mirsky Date: Tue, 21 Aug 2012 13:29:01 -0400 Thread-Topic: [mpls] Comments on draft-weingarten-mpls-smp-requirements-00.txt Thread-Index: Ac1+w2NeT2DdR2FqSZGY4CIRJvhb3QA/d31Q Message-ID: <60C093A41B5E45409A19D42CF7786DFD5CFC7DA5BF@EUSAACMS0703.eamcs.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_60C093A41B5E45409A19D42CF7786DFD5CFC7DA5BFEUSAACMS0703e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-weingarten-mpls-smp-requirements-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: Tue, 21 Aug 2012 17:29:07 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD5CFC7DA5BFEUSAACMS0703e_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgRmVpOg0KDQpJIHNlZSAiYSIgcHJvcG9zZWQgc29sdXRpb24gaW4gdGhlIGRyYWZ0IHlvdSBy ZWZlcmVuY2UsIGJ1dCBub3QgYSBwcm9ibGVtIHN0YXRlbWVudCBvciBhbmFsc3lzLg0KDQpUaGUg cHJlZW1wdGlvbiBjb3VsZCBzaW1wbHkgYmUgcGVyZm9ybWVkIGF0IG5vZGUgRS4gQ3VycmVudGx5 IHRoZSBtb2RlbCBpcyB0aGF0IHRoZSBMRVJzIG5lZWQgdG8gbm90aWZ5IG5vZGUgRSB3aGVuIHRo ZSBQIHBhdGggaXMgYmVpbmcgdXNlZCwgYW5kIEUgbmVlZHMgdG8gbm90aWZ5IHRoZSBMRVJzIG9m IHRoZSBjdXJyZW50IHN0YXRlIG9mIHRoZSBzaGFyZWQgcmVzb3VyY2UuICBUaGlzIGFwcGVhcnMg dG8gZGVwZW5kIG9uIHRoZSBwcmVlbXB0ZWQgTFNSIHRvICJkbyB0aGUgcmlnaHQgdGhpbmciIGFu ZCBsZWFkcyB0byBhbiBJTU8gdW5yZWFzb25hYmxlIHdpbmRvdyBvZiBjb250ZW50aW9uIGZvciB0 aGUgc2hhcmVkIHJlc291cmNlcy4NCg0KSU1PIEUgc2hvdWxkIGJlIGRvaW5nIHRoZSBwcmVlbXB0 aW9uLCBhbmQgSSd2ZSBzdGlsbCBub3QgcmVhbGx5IHNlZW4gYSBuZWVkIGZvciBoZWFkIGVuZCBu b3RpZmljYXRpb24gb2YgcHJlZW1wdGlvbiB1bmxlc3Mgb25lIHN0YXJ0cyBwbGFubmluZyBiYWNr dXBzIGZvciBiYWNrdXBzLg0KDQpJZiB5b3UgaGF2ZSBtb3JlIGluZm9ybWF0aW9uLCBjb3VsZCB5 b3UgZWxhYm9yYWJsZT8NCkRhdmUNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiB6aGFuZy5mZWkzQHp0ZS5jb20uY24NClNlbnQ6IE1vbmRheSwg QXVndXN0IDIwLCAyMDEyIDQ6MDMgQU0NClRvOiBHcmVnb3J5IE1pcnNreQ0KQ2M6IG1wbHNAaWV0 Zi5vcmc7IG1wbHMtYm91bmNlc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFttcGxzXSBDb21tZW50 cyBvbiBkcmFmdC13ZWluZ2FydGVuLW1wbHMtc21wLXJlcXVpcmVtZW50cy0wMC50eHQNCg0KDQpH cmVnLCBzbmlwcGVkDQoNCiAqICAgSW4gdGhlIGxhc3Qgc2VudGVuY2Ugb2YgU2VjdGlvbiAzLjEg bm9uLWNvbnRyb2wgcGxhbmUgY29vcmRpbmF0aW9uIG9mIHNoYXJlZCByZXNvdXJjZXMgcHJlc2Vu dGVkIGFzIGFub3RoZXIgcmVxdWlyZW1lbnQuIEFuZCBhZ2FpbiBJIGNhbiBub3QgZmluZCBob3cg d2UgY29tZSB0byBzdWNoIGNvbmNsdXNpb24sIHdoZXJlIHRoZSBzb3VyY2Ugb2YgdGhpcyByZXF1 aXJlbWVudC4gV291bGQgZXhpc3RpbmcgY29udHJvbCBwbGFuZSBzaWduYWxpbmcgc29sdXRpb24g YmUgc3VmZmljaWVudCBmb3IgYSBNUExTIG5ldHdvcms/DQoNCjxGZWk+IEkgZG8gbm90IHRoaW5r IHRoZSBleGlzdGluZyBjb250cm9sIHBsYW5lIChkZWZpbmVkIGluIFJGQzQ4NzIpIGlzIHN1ZmZp Y2llbnQgZm9yIGEgTVBMUyBuZXR3b3JrLCBhbmQgdGhlcmUgaXMgYW4gYW5hbHlzaXMgaW4gdGhl IGRyYWZ0IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhlLWNjYW1wLW5vdGlmaWNh dGlvbi1zaGFyZWQtbWVzaC1wcm90ZWN0aW9uLTAwLg0KDQoNCkJlc3QgcmVnYXJkcw0KDQpGZWkN Cg0KDQoNCkdyZWdvcnkgTWlyc2t5IDxncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20+DQq3orz+ yMs6ICBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcNCg0KMjAxMi0wOC0xNiAwNjo0NQ0KDQrK1bz+yMsN ClBhYmxvIEZyYW5rIDxwYWJsb2lzbm90QGdtYWlsLmNvbT4sIFlhYWNvdiBXZWluZ2FydGVuIDx3 eWFhY292QGdtYWlsLmNvbT4NCrOty80NCiJtcGxzQGlldGYub3JnIiA8bXBsc0BpZXRmLm9yZz4N Ctb3zOINClJlOiBbbXBsc10gQ29tbWVudHMgb24gZHJhZnQtd2VpbmdhcnRlbi1tcGxzLXNtcC1y ZXF1aXJlbWVudHMtMDAudHh0DQoNCg0KDQoNCg0KRGVhciBQYWJsbywgWWFhY292LCBldCBhbC4s DQpJJ3ZlIGJlZW4gZm9sbG93aW5nIGRpc2N1c3Npb24gd2l0aCBncmVhdCBkZWFsIG9mIGludGVy ZXN0LiBJIGhhdmUgc29tZSBxdWVzdGlvbnMgaW4gYWRkaXRpb24gdG8gb25lcyBiZWluZyBicm91 Z2h0IHVwIGJ5IFBhYmxvOg0KDQogKiAgIFNlY3Rpb24gMS4yIHJlZmVycyB0byBvcGVyYXRvcidz IGRlc2lyZSB0byBoYXZlIHNlcnZpY2UgcmVzdG9yYXRpb24gbW9yZSBleHBlZGllbnQgdGhhbiBv bmUgYWNoaWV2YWJsZSB3aXRoIGNvbnRyb2wgcGxhbmUuIEkgaGF2ZW4ndCBzZWVuIGFueSBxdWFu dGF0aXZlIGluZm9ybWF0aW9uIHRvIGNvbXBhcmUgd2l0aC4gV2hhdCBpcyAiZXhwZWRpZW50IGVu b3VnaCIgZm9yIFNNUD8NCiAqICAgU2VjdGlvbiAzLjEgZGVzcmNpYmVzLCB3aGF0IGNhbiBiZSBj YWxsZWQsICJpbnN0YW50IGRldGVybWluaXNtIiBpbiByZWdhcmQgdG8gU01QIHJlc291cmNlIGF2 YWlhbGFiaWxpdHkuIEkgdGhpbmsgdGhhdCB0aGVyZSdzIG5vdCBlbm91Z2ggcmVhc29uaW5nIHRv IGNvbmNsdWRlIHRoYXQgYWxtb3N0IGluc3RhbnRlbmVvdXMgdXBkYXRlIG9mIFNNUCByZXNvdXJj ZXMgYXZhaWFsYWJpbGl0eSBpcyByZXF1aXJlZC4NCiAqICAgSW4gdGhlIGxhc3Qgc2VudGVuY2Ug b2YgU2VjdGlvbiAzLjEgbm9uLWNvbnRyb2wgcGxhbmUgY29vcmRpbmF0aW9uIG9mIHNoYXJlZCBy ZXNvdXJjZXMgcHJlc2VudGVkIGFzIGFub3RoZXIgcmVxdWlyZW1lbnQuIEFuZCBhZ2FpbiBJIGNh biBub3QgZmluZCBob3cgd2UgY29tZSB0byBzdWNoIGNvbmNsdXNpb24sIHdoZXJlIHRoZSBzb3Vy Y2Ugb2YgdGhpcyByZXF1aXJlbWVudC4gV291bGQgZXhpc3RpbmcgY29udHJvbCBwbGFuZSBzaWdu YWxpbmcgc29sdXRpb24gYmUgc3VmZmljaWVudCBmb3IgYSBNUExTIG5ldHdvcms/DQogKiAgIEkn dmUgbm90aWNlZCB0aGF0IG1hbnkgcmVxdWlyZW1lbnRzIGJlaW5nIHJlZmVycmVkIHRvIE1QTFMt VFAsIG5vdCBNUExTLCBuZXR3b3Jrcy4gV291bGQgdGhhdCBiZSBhIGdvb2QgcmVhc29uIHRvIG5h cnJvdyBzY29wZSBvZiB0aGUgZG9jdW1lbnQgdG8gTVBMUy1UUCBuZXR3b3JrcyBvbmx5LCBzdGFy dGluZyB3aXRoIHRoZSBuYW1lIG9mIHRoZSBkb2N1bWVudD8NCg0KICAgIFJlZ2FyZHMsDQogICAg ICAgIEdyZWcNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IG1wbHMt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIFBhYmxvIEZyYW5rDQpTZW50OiBGcmlkYXksIEF1Z3VzdCAxMCwgMjAxMiA3OjIzIEFNDQpU bzogWWFhY292IFdlaW5nYXJ0ZW4NCkNjOiBtcGxzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21w bHNdIENvbW1lbnRzIG9uIGRyYWZ0LXdlaW5nYXJ0ZW4tbXBscy1zbXAtcmVxdWlyZW1lbnRzLTAw LnR4dA0KDQpIaSBZYWFjb3YsDQoNClNvbWUgbW9yZSBjb21tZW50cyBpbmxpbmUuLi4gUEY+Pg0K DQpPbiBNb24sIEF1ZyA2LCAyMDEyIGF0IDg6NTYgQU0sIFlhYWNvdiBXZWluZ2FydGVuIDx3eWFh Y292QGdtYWlsLmNvbTxtYWlsdG86d3lhYWNvdkBnbWFpbC5jb20+PiB3cm90ZToNCkhpLA0KDQpU aGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMuICBQbGVhc2Ugc2VlIG15IGNvbW1lbnRzIGlubGlu ZSBiZWxvdy4NCg0KQlIsDQp5YWFjb3YNCg0KT24gVHVlLCBKdWwgMTcsIDIwMTIgYXQgMTE6NTEg UE0sIFBhYmxvIEZyYW5rIDxwYWJsb2lzbm90QGdtYWlsLmNvbTxtYWlsdG86cGFibG9pc25vdEBn bWFpbC5jb20+PiB3cm90ZToNCkdvb2QgZHJhZnQgYW5kIGNlcnRhaW5seSBzb21ldGhpbmcgdGhh dCBuZWVkcyB0byBiZSBkb25lIGJlZm9yZSB3ZSBjYW4gc3RhcnQgZGlzY3Vzc2luZyBzcGVjaWZp YyBzb2x1dGlvbnMuDQoNCk9ubHkgYSBmZXcgY29tbWVudHMgLyBxdWVzdGlvbnM6DQoNCi0gSW4g NC4xLjEsIGlmIG9uZSBpcyBvcGVyYXRpbmcgaW4gYW4gTVBMUy1UUCBuZXR3b3JrIHRoYXQgcmVx dWlyZXMgZXhjbHVzaXZlIHVzZSBvZiB0aGUgcHJvdGVjdGlvbiByZXNvdXJjZXMsIGRvZXNuJ3Qg dGhpcyBTSE9VTEQgcmVxdWlyZW1lbnQgYmVjb21lIGEgTVVTVCByZXF1aXJlbWVudD8NCg0KeXc+ PiBTb3JyeSAtIGJ1dCBjb3VsZCB5b3UgZXhwbGFpbiBtb3JlIGZ1bGx5IHRoaXMgY29tbWVudC4N Cg0KUEY+PiAgSWYgeW91J3JlIHRyeWluZyB0byBtZWV0IFJGQyA1NjU0IHJlcSA1OGIgaW4gcGFy dGljdWxhciwgSSB3b3VsZCB0aGluayB5b3UgTVVTVCB2YWxpZGF0ZSB0aGF0IGVub3VnaCBwcm90 ZWN0aW9uIHJlc291cmNlcyBhcmUgYXZhaWxhYmxlIChvciBhcmUgcHJlZW1wdGlibGUpIHRvIGNh cnJ5IDEwMCUgb2YgdGhlIHNlcnZpY2UgdHJhZmZpYyB0aGF0IGlzIGJlaW5nIHJlc3RvcmVkLiAg SW4gZXhpc3RpbmcgdHJhbnNwb3J0IG5ldHdvcmtzIChpLmUuIE9UTiAvIHNvbmV0KSwgdGhpcyBp cyB0eXBpY2FsbHkgZG9uZSBiZWZvcmUgeW91IHN3aXRjaCB0cmFmZmljIHRvIHRoZSBwcm90ZWN0 aW9uIHBhdGguICBGcm9tIGEgc29sdXRpb24gcGVyc3BlY3RpdmUsIEkgdGhpbmsgeW91J2xsIHBy b2JhYmx5IHdhbnQgdG8gbGV2ZXJhZ2Ugc29tZXRoaW5nIGxpa2UgdGhlIGxvY2tpbmcgbW9kZSB0 aGF0IGlzIGJlaW5nIHByb3Bvc2VkIGZvciB0aGUgMTpuIGRyYWZ0Lg0KDQotIE5pdDogeW91IG1p Z2h0IHdhbnQgdG8gYXZvaWQgdXNpbmcgdGhlICJxdWVyeSIgdmVyYiBpbiB0aGUgdGl0bGUgb2Yg NC4xLjEgYmVjYXVzZSBpdCBzdWJ0bHkgc3VnZ2VzdHMgc29tZSBraW5kIG9mIHByb3RvY29sIG1l c3NhZ2luZyBpcyByZXF1aXJlZC4gIEkgd291bGQgdXNlIHRoZSBtb3JlIGdlbmVyaWMgdmVyYiAi Y2hlY2tpbmciIG9yICJ2ZXJpZnlpbmciLg0KeXc+PiBTb3VuZHMgT0sgdG8gbWUuDQotIEluIDQu MywgdGhlcmUgaXMgbm8gc3VnZ2VzdGlvbiBmb3Igd2hhdCBzaG91bGQgaGFwcGVuIGlmIG9uZSBv ciBtb3JlIGZhaWxpbmcgcGF0aHMgaW4gYW4gTVBMUy1UUCBuZXR3b3JrIGFyZSBvZiBlcXVhbCBw cmlvcml0eS4gIEkgcHJlc3VtZSBpdCB3aWxsIGJlIHNvbWUga2luZCBvZiBmaXJzdC1jb21lLCBm aXJzdC1zZXJ2ZSByZXF1aXJlbWVudCBidXQgdGhpcyB3aWxsIGJyaW5nIHVwIHRoZSBxdWVzdGlv biBvZiBob3cgdG8gYnJlYWsgdGllcy4NCnl3Pj4gVGhpcyBjb3VsZCBiZSByZXNvbHZlZCBhbG9u ZyB0aGUgbGluZXMgdGhhdCBpdCB3YXMgYWRkcmVzc2VkIGluIHRoZSAxOm4gcHJvdGVjdGlvbg0K DQpQRj4+IEV4Y2VwdCB0aGF0IHlvdSBndXlzIHJlbW92ZWQgc2VwYXJhdGUgcGF0aCBwcmlvcml0 eSBmcm9tIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgMTpuIGRyYWZ0LiAgSW4gdGhlIGxhdGVz dCB2ZXJzaW9uLCBlYWNoIHBhdGggaGFzIGEgc3RyaWN0IHByaW9yaXR5IGRlZmluZWQgYnkgaXRz IHBhdGggSUQgc28gdGllcyB3ZXJlIG5vdCBwb3NzaWJsZS4gIEkgZG9uJ3QgdGhpbmsgdGhhdCBz b2x1dGlvbiB3aWxsIHdvcmsgZm9yIFNNUCBiZWNhdXNlIEkgaGF2ZSBhIGhhcmQgdGltZSBzZWVp bmcgaG93IGFsbCB0aGUgdmFyaW91cyBlbmRwb2ludHMgaW52b2x2ZWQgaW4gYSBzaGFyZWQgbWVz aCBjb3VsZCBjb29yZGluYXRlIG5vbi1vdmVybGFwcGluZyBwYXRoIElEcywgd2hpbGUgYXQgdGhl IHNhbWUgdGltZSBub3QgZXhjZWVkaW5nIHRoZSBsaW1pdCBvZiAyNTUgcGF0aCBJRHMuDQoNCg0K LSBBbHNvIGluIDQuMywgdGhlcmUgaXMgYW4gYWxsb3dhbmNlIGZvciBhIGhpZ2ggcHJpb3JpdHkg cGF0aCBhbmQgYSBsb3dlciBwcmlvcml0eSBwYXRoIHRvIHRlbXBvcmFyaWx5IHNoYXJlIHRoZSBw cm90ZWN0aW9uIHJlc291cmNlcyB3aGlsZSBwcmVlbXB0aW9uIGlzIHRha2luZyBwbGFjZS4gIFR3 byBxdWVzdGlvbnM6DQotIElzIHRoZSBpbmdyZXNzIG5vZGUgdG8gdGhlIHNoYXJlZCBzZWdtZW50 IGV4cGVjdGVkIHRvIGRpc2NhcmQgZXhjZXNzIHRyYWZmaWMgbm93IHRoYXQgdGhlIHByb3RlY3Rp b24tcGF0aCBpcyB0ZW1wb3JhcmlseSBvdmVyc3Vic2NyaWJlZD8NCnl3Pj4gdGhpcyB3b3VsZCBt b3N0IHByb2JhYmx5IGZvbGxvdyBzdGFuZGFyZCBNUExTIGJlaGF2aW9yIGFzIGRlc2NyaWJlZCBl bHNld2hlcmUNCg0KUEY+PiBJIGd1ZXNzIEknbGwgYXNrIHdoYXQgaXMgdGhlIHN0YW5kYXJkIGJl aGF2aW91cj8gIEFuZCBpcyBpdCBhcHBsaWNhYmxlIHRvIE1QTFMtVFAgbmV0d29ya3M/DQoNCi0g SWYgbm90LCBob3cgZG8gd2UgZW5zdXJlIHRoYXQgb3RoZXIgdHJhbnNwb3J0IHBhdGhzIGFyZSB1 bmFmZmVjdGVkPw0KLSBUaGUgZmlyc3QgcGFyYWdyYXBoIG9mIDQuNCBhcHBlYXJzIHRvIGNvbnRy YWRpY3QgNC4xLjEuICA0LjQgc2VlbXMgdG8gc3VnZ2VzdCB0aGF0IG9uZSBNVVNUIHN3aXRjaCB0 aGUgdHJhZmZpYyBvbnRvIHRoZSBwcm90ZWN0aW9uIHBhdGggZmlyc3QgYW5kIHRoZW4gZ2V0IG5v dGlmaWVkIGlmIHRoZXJlJ3Mgbm90IGVub3VnaCByZXNvdXJjZXMuICBUaGF0J3MgcHJvYmFibHkg b2theSBpbiB0aGUgZ2VuZXJhbCBjYXNlLiAgQnV0IGluIGFuIE1QTFMtVFAgbmV0d29yaywgSSBk b24ndCB0aGluayBpdCdzIGEgZ29vZCBpZGVhIHRvIGJsaW5kbHkgc3dpdGNoIGxvdyBwcmlvcml0 eSB0cmFmZmljIG9udG8gdGhlIHByb3RlY3Rpb24gcGF0aCBhbmQgcG9zc2libHkgZGlzcnVwdCBh IGhpZ2ggcHJpb3JpdHkgcGF0aCB0aGF0IGlzIGFscmVhZHkgdXNpbmcgdGhhdCByZXNvdXJjZS4N Cnl3Pj4gVGhpcyBpcyBkZXBlbmRlbnQgdXBvbiB0aGUgYWN0dWFsIG1lY2hhbmlzbSB0aGF0IGlz IGRldmVsb3BlZCBieSB0aGUgV0cuICBGb3IgZXhhbXBsZSwgb25lIHN1Z2dlc3Rpb24gZm9yIHRo ZSBtZWNoYW5pc20gaGFzIG5vdGlmaWNhdGlvbnMgc2VudCB0byBsb3dlciBwcmlvcml0eSB3b3Jr aW5nIHBhdGhzIG1ha2luZyB0aGUgcHJvdGVjdGlvbiBwYXRoIHVuYXZhaWxhYmxlIGlmIGl0IGlz IGluIHVzZSBieSBhIGhpZ2gtcHJpb3JpdHkgd29ya2luZyBwYXRoLg0KDQotIEluIHNlY3Rpb24g NC41LCB0aGVyZSdzIGFuIGF0dGVtcHQgdG8gZGVmaW5lICJwcm90ZWN0aW9uIHN3aXRjaGluZyB0 aW1lIiBhcyBub3QgaW5jbHVkaW5nIHByZWVtcHRpb24gdGltZS4gIEkgZG9uJ3QgdGhpbmsgZW5k LXVzZXJzIHJlYWxseSBjYXJlIGFib3V0ICJwcm90ZWN0aW9uIHN3aXRjaGluZyB0aW1lIi4gIFRo ZXkgY2FyZSBhYm91dCByZWNvdmVyeSB0aW1lIGFuZCBJTU8sIHRoYXQgc2hvdWxkIGFsc28gaW5j bHVkZSBmYXVsdCBkZXRlY3Rpb24gdGltZSAoYWx0aG91Z2ggaXQgZG9lc24ndCBwZXIgUkZDIDU2 NTQpIGFuZCBhbnkgcHJlZW1wdGlvbiB0aW1lLg0KeXc+PiB3ZSBkbyB0cnkgdG8gd29yayB3aXRo aW4gdGhlIGFjY2VwdGVkIGRlZmluaXRpb25zIG9mIHRoZSBJRVRGIQ0KDQpQRj4+IEkgZ3Vlc3Mg dGhlcmUncyB0d28gc2VwYXJhdGUgY29tbWVudHMgaGVyZSB0aGF0IEkga2luZGEgY29uZmxhdGVk IHRvZ2V0aGVyLiAgT25lIHdhcyBtb3JlIG9mIGEgZ3JpcGU6IHdoeSBkaWQgd2UgZXhjbHVkZSBm YXVsdCBkZXRlY3Rpb24gdGltZSBmcm9tIHRoZSA1MG1zIHJlc3RvcmF0aW9uIHRpbWUgcmVxdWly ZW1lbnQgaW4gUkZDIDU2NTQ/ICBJIGtub3cgdGhhdCBteSBjdXN0b21lcnMgbWVhc3VyZSBvbmx5 IG9uZSB0aGluZzogaG93IG1hbnkgbXMgb2YgdHJhZmZpYyBkbyB0aGV5IGxvc2UgYWZ0ZXIgYSBi cmVha2FnZS4gIEkgZG9uJ3QgZ2V0IGEgZnJlZSBwYXNzIG9uIHRoZSB+MTBtcyBpdCB0YWtlcyBm b3IgQkZEIHRvIGRldGVjdCB0aGUgZmFpbHVyZS4gIEFjY29yZGluZyB0byBSRkMgNTY1NCwgSSBj b3VsZCB1c2UgNjBzZWMgQ0NNcyBhbmQgc3RpbGwgbWVldCB0aGUgNTBtcyByZXF1aXJlbWVudCEN Cg0KVGhlIDJuZCBjb21tZW50IHdhcyByZWFsbHkgYWJvdXQgdGhpcyBkcmFmdCBub3cgdHJ5aW5n IHRvIGV4Y2x1ZGUgcHJlZW1wdGlvbiB0aW1lIGZyb20gcmVzdG9yYXRpb24gdGltZSBhcyB3ZWxs LiAgSU1PLCBpZiBpdCB0YWtlcyBhIGZldyBzZWNvbmRzIGZvciBhIGhpZ2ggcHJpb3JpdHkgc2Vy dmljZSB0byBmaW5pc2ggcHJlZW1wdGluZyBhIGxvd2VyIHByaW9yaXR5IHNlcnZpY2UsIHRoZW4g d2UgaGF2ZW4ndCBtZXQgdGhlIDUwbXMgcmVzdG9yYXRpb24gdGltZSByZXF1aXJlbWVudC4gIEVz cGVjaWFsbHkgc2luY2UgaXQncyB0eXBpY2FsbHkgbXkgaGlnaGVyIHByaW9yaXR5IHNlcnZpY2Vz IHRoYXQgd2FudCA1MG1zIHJlc3RvcmF0aW9uIHRpbWVzIGluIHRoZSBmaXJzdCBwbGFjZSwgc28g dGhleSdsbCBiZSBtb3JlIG9mdGVuIGluIGEgcG9zaXRpb24gdG8gcHJlZW1wdC4gIEluIG90aGVy IHdvcmRzLCBJIHRoaW5rIHdlIHdhbnQgcHJlZW1wdGlvbiB0byBiZSBmYXN0IGFuZCBpcyBhIGNy aXRpY2FsIGNvbXBvbmVudCBvZiBwcm90ZWN0aW9uIHN3aXRjaGluZy4NCg0KDQpyZWdhcmRzLA0K UGFibG8NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxp c3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bXBscw0KDQo= --_000_60C093A41B5E45409A19D42CF7786DFD5CFC7DA5BFEUSAACMS0703e_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi=20 Fei:
 
I see=20 "a" proposed solution in the draft you reference, but not a problem=20 statement or analsys.
 
The=20 preemption could simply be performed at node E. Currently the model&nb= sp;is=20 that the LERs need to notify node E when the P path is being used, and E ne= eds=20 to notify the LERs of the current state of the shared resource.  = This=20 appears to depend on the preempted LSR to "do the right thing" and lea= ds to=20 an IMO unreasonable window of contention for the shared=20 resources.
 
IMO E=20 should be doing the preemption, and I've still not really seen a need for h= ead=20 end notification of preemption unless one starts planning backups for=20 backups.
 
If you=20 have more information, could you elaborable?
Dave
 
 

From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of=20 zhang.fei3@zte.com.cn
Sent: Monday, August 20, 2012 4:03=20 AM
To: Gregory Mirsky
Cc: mpls@ietf.org;=20 mpls-bounces@ietf.org
Subject: Re: [mpls] Comments on=20 draft-weingarten-mpls-smp-requirements-00.txt


Greg, snipped
  • In the last sentence of Sect= ion 3.1=20 non-control plane coordination of shared resources presented as another=20 requirement. And again I can not find how we come to such conclusion, whe= re=20 the source of this requirement. Would existing control plane signaling=20 solution be sufficient for a MPLS network?

<Fei> I do not think the existing control plane (de= fined=20 in RFC4872) is sufficient for a MPLS network, and there is an analysis in t= he=20 draft=20 http://tools.ietf.org/html/draft-he-ccamp-notification-shared-mesh-protecti= on-00.=20


Best regards=20

Fei



Gregory Mirsky=20 <gregory.mirsky@ericsson.com>
=B7=A2=BC=FE=C8=CB:  mpls-bounces@ietf.org=20

2012-08-16 06:45

=CA=D5=BC= =FE=C8=CB
Pablo Frank=20 <pabloisnot@gmail.com>, Yaacov Weingarten=20 <wyaacov@gmail.com>=20
=B3=AD=CB= =CD
"mpls@ietf.org"=20 <mpls@ietf.org>=20
=D6=F7=CC= =E2
Re: [mpls] Comments on=20 draft-weingarten-mpls-smp-requirements-00.txt





Dear Pablo, Yaacov, et al.,
I've been following discussion with great deal of interest. I = have=20 some questions in addition to ones being brought up by Pablo:=20
  • Section 1.2 refers to operat= or's desire=20 to have service restoration more expedient than one achievable with contr= ol=20 plane. I haven't seen any quantative information to compare with. What is= =20 "expedient enough" for SMP?=20
  • Section 3.1 desrcibes, what = can be=20 called, "instant determinism" in regard to SMP resource avaialability. I = think=20 that there's not enough reasoning to conclude that almost instanteneous u= pdate=20 of SMP resources avaialability is required.=20
  • In the last sentence of Sect= ion 3.1=20 non-control plane coordination of shared resources presented as another=20 requirement. And again I can not find how we come to such conclusion, whe= re=20 the source of this requirement. Would existing control plane signaling=20 solution be sufficient for a MPLS network?=20
  • I've noticed that many requi= rements=20 being referred to MPLS-TP, not MPLS, networks. Would that be a good reaso= n to=20 narrow scope of the document to MPLS-TP networks only, starting with the = name=20 of the document?
 =20   Regards,
        Greg

From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of Pablo Frank
Sent:<= /B>=20 Friday, August 10, 2012 7:23 AM
To: Yaacov Weingarten
Cc:=20 mpls@ietf.org
Subject: Re: [mpls] Comments on=20 draft-weingarten-mpls-smp-requirements-00.txt

Hi Yaacov,

Some=20 more comments inline... PF>>

On Mon, Aug= 6,=20 2012 at 8:56 AM, Yaacov Weingarten <wyaacov@gmail.com= > wrote:
Hi,

Thank=20 you for your comments.  Please see my comments inline below.=20

BR,
yaacov

<= FONT=20 size=3D3>On Tue, Jul 17, 2012 at 11:51 PM, Pablo Frank <pabloisnot@gmail.com> wrote:=20
Good draft and certainly something that needs to be done= before=20 we can start discussing specific solutions.

O= nly a=20 few comments / questions:

- In 4.1.1, if one = is=20 operating in an MPLS-TP network that requires exclusive use of the protecti= on=20 resources, doesn't this SHOULD requirement become a MUST requirement?=20

yw>> Sorry - but could you explain more fully = this=20 comment.

PF>>  If you're trying to= meet=20 RFC 5654 req 58b in particular, I would think you MUST validate that enough= =20 protection resources are available (or are preemptible) to carry 100% of th= e=20 service traffic that is being restored.  In existing transport network= s=20 (i.e. OTN / sonet), this is typically done before you switch traffic to the= =20 protection path.  From a solution perspective, I think you'll probably= want=20 to leverage something like the locking mode that is being proposed for the = 1:n=20 draft.

- Nit: you might want to avoid using t= he=20 "query" verb in the title of 4.1.1 because it subtly suggests some kind of= =20 protocol messaging is required.  I would use the more generic verb=20 "checking" or "verifying".
yw>> Sounds OK t= o me.=20
- In 4.3, there is no suggestion for what should = happen=20 if one or more failing paths in an MPLS-TP network are of equal priority.=20  I presume it will be some kind of first-come, first-serve requirement= but=20 this will bring up the question of how to break ties.
yw>> This could be resolved along the lines that it was addr= essed=20 in the 1:n protection

PF>> Except that = you=20 guys removed separate path priority from the latest version of the 1:n draf= t.=20  In the latest version, each path has a strict priority defined by its= path=20 ID so ties were not possible.  I don't think that solution will work f= or=20 SMP because I have a hard time seeing how all the various endpoints involve= d in=20 a shared mesh could coordinate non-overlapping path IDs, while at the same = time=20 not exceeding the limit of 255 path IDs.


= - Also=20 in 4.3, there is an allowance for a high priority path and a lower priority= path=20 to temporarily share the protection resources while preemption is taking pl= ace.=20  Two questions:
- Is the ingress node to the= shared=20 segment expected to discard excess traffic now that the protection-path is= =20 temporarily oversubscribed?
yw>> this would= most=20 probably follow standard MPLS behavior as described elsewhere=20

PF>> I guess I'll ask what is the stand= ard=20 behaviour?  And is it applicable to MPLS-TP networks?
 
- If not, how do we ensure that o= ther=20 transport paths are unaffected?
- The first parag= raph of=20 4.4 appears to contradict 4.1.1.  4.4 seems to suggest that one MUST s= witch=20 the traffic onto the protection path first and then get notified if there's= not=20 enough resources.  That's probably okay in the general case.  But= in=20 an MPLS-TP network, I don't think it's a good idea to blindly switch low=20 priority traffic onto the protection path and possibly disrupt a high prior= ity=20 path that is already using that resource.
yw>&= gt;=20 This is dependent upon the actual mechanism that is developed by the WG.=20  For example, one suggestion for the mechanism has notifications sent = to=20 lower priority working paths making the protection path unavailable if it i= s in=20 use by a high-priority working path.
 =20
- In section 4.5, there's an attempt to define "protecti= on=20 switching time" as not including preemption time.  I don't think end-u= sers=20 really care about "protection switching time".  They care about recove= ry=20 time and IMO, that should also include fault detection time (although it do= esn't=20 per RFC 5654) and any preemption time.
yw>>= we do=20 try to work within the accepted definitions of the IETF!

PF>> I guess there's two separate comments here that I kinda= =20 conflated together.  One was more of a gripe: why did we exclude fault= =20 detection time from the 50ms restoration time requirement in RFC 5654? &nbs= p;I=20 know that my customers measure only one thing: how many ms of traffic do th= ey=20 lose after a breakage.  I don't get a free pass on the ~10ms it takes = for=20 BFD to detect the failure.  According to RFC 5654, I could use 60sec C= CMs=20 and still meet the 50ms requirement!

The 2nd = comment=20 was really about this draft now trying to exclude preemption time from=20 restoration time as well.  IMO, if it takes a few seconds for a high=20 priority service to finish preempting a lower priority service, then we hav= en't=20 met the 50ms restoration time requirement.  Especially since it's typi= cally=20 my higher priority services that want 50ms restoration times in the first p= lace,=20 so they'll be more often in a position to preempt.  In other words, I = think=20 we want preemption to be fast and is a critical component of protection=20 switching.  
 

regards,
Pablo


_______________________________________________
mpls mailin= g=20 list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls


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

--_000_60C093A41B5E45409A19D42CF7786DFD5CFC7DA5BFEUSAACMS0703e_-- From aldrin.ietf@gmail.com Tue Aug 21 12: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 3CF0021F8760; Tue, 21 Aug 2012 12:10:32 -0700 (PDT) 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 2D53Ka2i8h+L; Tue, 21 Aug 2012 12:10:31 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id E22F621F86C8; Tue, 21 Aug 2012 12:10:30 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so331743pbb.31 for ; Tue, 21 Aug 2012 12:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=RUbxyd2BicBG8ZrfF9/TD9kxGcB5jcq9nsL9JND/+2U=; b=FCZoHPavZszsG16E8g+yGlmBGqxvXPRmq1eyZG6jOSBVyeR31VwY6resHqKEaHPxRx TzNYCTVlKT2IxA2qY/bgilD/HbAi+1Fd5k75hqoDbR36r+Y8JKuhR/76FoPCAS2mYlzl vYlMfUDKpHTTQ95sH9hiGemGunrb4+vNLsNNrb+DQTgOx88kb0pmsliSoFBjWfTV74AO RoAhSLsbwwubGGV3GW2VKCDSS77uCU9ClIvo6Bk06xtg8axFxoldXNbT3PRIo9tqpy8a IouWgcs1IzMy9CgK//KWhxR2YJQsPEJ2eCnanKvUvm/o/3iGMQnePH5IYROaqTvAnP3F DM8A== Received: by 10.68.235.68 with SMTP id uk4mr46195895pbc.52.1345576230395; Tue, 21 Aug 2012 12:10:30 -0700 (PDT) Received: from [192.168.255.58] ([12.207.18.42]) by mx.google.com with ESMTPS id vd4sm1980425pbc.41.2012.08.21.12.10.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Aug 2012 12:10:29 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) Content-Type: text/plain; charset=iso-8859-1 From: Sam Aldrin X-Priority: 3 In-Reply-To: <04c801cd7e10$3c45b430$6801a8c0@JoanPC> Date: Tue, 21 Aug 2012 12:10:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <822F81DC-E52A-4C33-BA4E-52A213E70A02@gmail.com> References: <056101cd6354$c9deb1b0$6801a8c0@JoanPC> <5257BD19-4A53-4767-9BAB-6C2AB2032846@lucidvision.com> <026f01cd7c9c$b7224030$6801a8c0@JoanPC> <02c601cd7cb8$06037910$6801a8c0@JoanPC> <2E7490DB-3DE7-42C8-8E43-7378A76C2B4C@gmail.com> <04c801cd7e10$3c45b430$6801a8c0@JoanPC> To: Joan Cucchiara X-Mailer: Apple Mail (2.1485) Cc: Venkatesan Mahalingam , mpls@ietf.org, mpls-chairs@tools.ietf.org, Sam Aldrin , "MIB Doctors \(E-mail\)" Subject: Re: [mpls] draft-ietf-mpls-tp-te-mib-04.txt review request 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, 21 Aug 2012 19:10:32 -0000 Hi Joan, Thanks for the email. Sorry for the delayed email. Was on PTO. Please find my comments inline. thanks -sam On Aug 19, 2012, at 6:40 AM, Joan Cucchiara = wrote: >> Hi Joan, >>=20 >> The issue boils down to the range value specified in the DESCRIPTION. >> If that is removed, does that resolve the concern you raised? >=20 > Sam, >=20 > I think that depends on how the new DESCRIPTION clause is worded. > This DESCRIPTION was brought up as a MAJOR concern and > the authors agreed to reword it for 04, but that was not done. >=20 > Please see inline below. >=20 >> Do not think we are restricting not to use '0' in anyway or = redefining the >> semantics. >>=20 >> As the value is local and the intention is to help implementor of the = MIB to >> choose right value, without conflicting with TE tunnel index, we = added that >> range. If implementor chooses to use different value altogether, it = is >> perfectly OK as long as it is in the range of mplsExtendedTunnelId >> definition. >=20 > So why was the above (extremely helpful) information not included as = part of the > DESCRIPTION clause? Yes, it should have been. We will send a new text for the description = for review, which will reflect what we were discussing. Hopefully, that = will remove the confusion. >=20 > The object is: > mplsTunnelExtNodeConfigLocalId OBJECT-TYPE > SYNTAX MplsExtendedTunnelId > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This object is used in accommodating the bigger > size Global_Node_ID and/or ICC with lower size LSR > identifier in order to index the mplsTunnelTable. >=20 > The Local Identifier is configured between 1 and 16777215, > as valid IP address range starts from 16777216(01.00.00.00). > This range is chosen to identify the mplsTunnelTable's > Ingress/Egress LSR-id is IP address or Local identifier, > if the configured range is not IP address, administrator is > expected to retrieve the complete information > (Global_Node_ID or ICC) from mplsTunnelExtNodeConfigTable. > This way, existing mplsTunnelTable is reused for > bidirectional > tunnel extensions for MPLS based transport networks. >=20 > This Local Identifier allows the administrator to assign > a unique identifier to map Global_Node_ID and/or ICC." > ::=3D { mplsTunnelExtNodeConfigEntry 1 } >=20 >=20 > No where in the DESCRIPTION does it say this is a "hint" to the = operator (you say > implementor, but think you mean the operator, i.e. the person that = configures this MIB table.) Agree.=20 When I say implementor, I was implying in the case of signaled, where = the localID to be derived. Operator is also right term when the tunnel = is configured statically. New description will provide right details in = the case of static and control plane signaled TP tunnels. >=20 >=20 >> W.r.t legacy implementation, it is unto the implementor to assign the = right >> index value to TP tunnel, if it conflicts with TE tunnel index. >=20 >=20 > Yes, but the draft says in Section 9. "Do note that a MPLS-TP tunnel = could be setup statically as well as > signaled via control plane." so if the tunnel is signaled, then what = happens? Are there entries > created in these tables by the local management subsystem (e.g. agent) = when the MPLS TP tunnel is signaled > successfully OR are entries entirely dependent on an operator for = configuration? When signaled, the local agent will create those entries. It needs to = derive the localID, which is unique only on the local system as it is = locally significant. In order not to conflict with legacy TE = implementation, we 'suggest' to use the value which is below valid IP = address value.=20 >=20 > As far as I can tell, the MIB does not support signaled TP tunnels, = is this correct? > If so, that needs to be clearly stated, particularly in the Abstract. That is not correct. It does support. We never restricted the MIB to = static TP tunnels only. We will add explicit statement in the abstract = to remove the confusion. >=20 > If I am wrong and it does support signaled TP Tunnels then, how does = that work with mapping tables? > While there is an example for statically configured tunnels, I don't = see one for Signaled TP Tunnels. As I mentioned above, the local ID is derived as in the given example. = If needed, we can add more text or details in the example section, w.r.t = signaled vs static. >=20 >=20 >> The example provided could give guidance on what value to use, but = will not >> MANDATE the usage. >>=20 >> In regards to implementing a new table, we have deliberated = extensively >> among authors and also with implementors. Adding new MIB or table is = not >> really efficient. Infact, there are already implementations which = were able >> to support the legacy model as well as new TP tunnels. Unless there = is a >> compelling reason that MPLS TP tunnel table should have its own = table, which >> essentially duplicated all of the objects, I am not for that model. = If >> others in WG feels the need, they can speak up. >=20 >=20 > I'd like to see the new DESCRIPTION clause and understand about MPLS = TP signaled > tunnels wrt to this draft, prior to delving into the above (and other = issues). Will send the new text for review, soon. If you have other issues, = please do let us know. -sam >=20 > Thanks, > -Joan >=20 > On Aug 17, 2012, at 1:51 PM, Venkatesan Mahalingam = wrote: >=20 >> ++ MPLS WG & MIB Drs. >>=20 >> Thanks, >> Venkat. >>=20 >> On Fri, Aug 17, 2012 at 1:36 PM, Joan Cucchiara >> wrote: >>> Venkat, >>>=20 >>> The SMIv2 specifies that once a TC is defined, then the definition = cannot >>> change in the way being >>> proposed by the draft-ietf-mpls-tp-te-mib-04. >>>=20 >>> =46rom RFC2579: >>> 3.3. Mapping of the DESCRIPTION clause >>> The DESCRIPTION clause, which must be present, contains a textual >>> definition of the textual convention, which provides all semantic >>> definitions necessary for implementation, and should embody any >>> information which would otherwise be communicated in any ASN.1 >>> commentary annotations associated with the object. >>>=20 >>>=20 >>> My concern is that MPLS-TC-STD-MIB defines MplsExtendedTunnelId and = this >>> draft is changing that original definition. >>> If RFC3811 does not contain "all semantic definitions necessary for >>> implementation" then the problem is to update RFC3811 >>> and maybe other associated RFCs as needed, not to propose additional >>> semantics in draft-ietf-mpls-tp-te-mib. >>>=20 >>> The draft is proposing to bifurcate the values and also not use zero = for the >>> MplsExtendedTunnelId, that is not the original >>> definition of MplsExtendedTunnelId, so why is this draft using >>> MplsExtendedTunnelId? >>>=20 >>> Please include the MIB Dr's on your email because this is a MIB = concern and >>> one which I've had since >>> before this draft was adopted as a WG document. >>>=20 >>> The options are (as I see them): >>> 1) create a specific MPLS TP table for TP Tunnels (which was = originally >>> proposed by Adrian Farrel) >>> 2) update RFC3811 to accurately reflect MplsExtendedTunnelId and = other RFCs >>> which utilize this TC. >>> 3) ?? >>>=20 >>> Thanks, >>> -Joan >>>=20 >>>=20 >>> ----- Original Message ----- From: "Venkatesan Mahalingam" >>> >>> To: "Joan Cucchiara" >>> Cc: "Thomas Nadeau" ; "Sam Aldrin" >>> ; "Kannan KV Sampath" = >>> Sent: Friday, August 17, 2012 2:39 PM >>>=20 >>> Subject: Re: draft-ietf-mpls-tp-te-mib-04.txt review request >>>=20 >>>=20 >>>> Joan, >>>>=20 >>>> Thanks for your response. Appreciate your time for reviewing this >>>> draft. Please find below my response tagged [VM]. >>>>=20 >>>> However, I looked over the doc and wanted to let you know that I = still >>>> have >>>>>=20 >>>>> the same issue wrt to both SYNTAX and semantic >>>>> redefinition as before. You cannot narrow the range of values in = a >>>>> DESCRIPTION clause which I see happens in = mplsTunnelExtNodeConfigLocalId >>>>> and maybe in MplsNodeId TC as it says zero must not be used, but = then >>>>> you >>>>> have it as part of allowable values in the SYNTAX. >>>>=20 >>>> [VM] If MplsExtendedTunnelId allows zero as the valid value, I = don't >>>> see any issue to allow zero as the valid value for MplsNodeId. >>>>=20 >>>>> Additionally, the SYNTAX below for MplsExtendedTunnelId allows any >>>>> Unsigned32 and says "may represent an IPv4 address". If (for = whatever >>>>> reason) an >>>>> operator has configured something in the 1..16777216 (i.e. Local = Id) >>>>> range, >>>>> for a regular TE Tunnel, that is perfectly legal, right? >>>>=20 >>>> [VM] I don't see any implementation which allows non-IP TE tunnel >>>> source/destination in the range 1..16777216 in MPLS domain, >>>> if you are not still convinced, we can poll in MPLS WG list to get = the >>>> operators' opinion on this. >>>>=20 >>>>> If the answer is Yes, then how would you add TP Tunnels using your = draft >>>>> if >>>>> an operator has a regular MPLS TE Tunnel configured >>>>> in the range 1..16777216 without having to ensure that any and all = legacy >>>>> equipment be queried first? >>>>=20 >>>> [VM] It is expected to configure MPLS TE tunnels in IP address = range >>>> and MPLS-TP tunnel in NON-IP range, if the implementors have mixed >>>> mode of configuration, then it is expected to clarify in the = document >>>> that how to use MPLS-TE & MPLS-TP tunnel configurations. >>>> What you are saying is correct only if the legacy equipments use = the >>>> NON-IP range for MPLS TE tunnels, so, as I stated above, let's = close >>>> this with the MPLS WG list. >>>>=20 >>>> HTH >>>>=20 >>>> Thanks, >>>> Venkat. >>>>=20 >>>> On Fri, Aug 17, 2012 at 10:21 AM, Joan Cucchiara >>>> wrote: >>>>>=20 >>>>> Tom and all, >>>>>=20 >>>>> Unfortunately, my linux box is giving me grief this week (and I = don't >>>>> have >>>>> access to my MIB tools). I'm getting some assistance >>>>> with it but won't be resolved until (hopefully) during the = weekend. >>>>>=20 >>>>> However, I looked over the doc and wanted to let you know that I = still >>>>> have >>>>> the same issue wrt to both SYNTAX and semantic >>>>> redefinition as before. You cannot narrow the range of values in = a >>>>> DESCRIPTION clause which I see happens in = mplsTunnelExtNodeConfigLocalId >>>>> and maybe in MplsNodeId TC as it says zero must not be used, but = then >>>>> you >>>>> have it as part of allowable values in the SYNTAX. >>>>>=20 >>>>> Whatever is specified in the DESCRIPTION clause for values, should = be >>>>> reflected by the SYNTAX, right? >>>>>=20 >>>>> Additionally, the SYNTAX below for MplsExtendedTunnelId allows any >>>>> Unsigned32 and says "may represent an IPv4 address". If (for = whatever >>>>> reason) an >>>>> operator has configured something in the 1..16777216 (i.e. Local = Id) >>>>> range, >>>>> for a regular TE Tunnel, that is perfectly legal, right? >>>>>=20 >>>>>=20 >>>>> MplsExtendedTunnelId ::=3D TEXTUAL-CONVENTION >>>>> STATUS current >>>>> DESCRIPTION >>>>> "A unique identifier for an MPLS Tunnel. This may >>>>> represent an IPv4 address of the ingress or egress >>>>> LSR for the tunnel. This value is derived from the >>>>> Extended Tunnel Id in RSVP or the Ingress Router ID >>>>> for CR-LDP." >>>>> REFERENCE >>>>> "RSVP-TE: Extensions to RSVP for LSP Tunnels, >>>>> [RFC3209]. >>>>>=20 >>>>> Constraint-Based LSP Setup using LDP, [RFC3212]." >>>>> SYNTAX Unsigned32(0..4294967295) >>>>>=20 >>>>> If the answer is Yes, then how would you add TP Tunnels using your = draft >>>>> if >>>>> an operator has a regular MPLS TE Tunnel configured >>>>> in the range 1..16777216 without having to ensure that any and all = legacy >>>>> equipment be queried first? >>>>>=20 >>>>> Thanks, >>>>> -Joan >>>>>=20 >>>>>=20 >>>>>=20 >>>>> ----- Original Message ----- >>>>> From: Thomas Nadeau >>>>> To: Joan Cucchiara >>>>> Cc: Sam Aldrin ; Venkatesan Mahalingam ; Kannan KV Sampath >>>>> Sent: Thursday, August 09, 2012 8:58 AM >>>>> Subject: Re: draft-ietf-mpls-tp-te-mib-04.txt review request >>>>>=20 >>>>> hi Joan >>>>>=20 >>>>> hope you had a great vacation! ;) >>>>>=20 >>>>> can you please follow up on the note below when you have a chance? >>>>>=20 >>>>> Tom >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Jul 16, 2012, at 9:13 AM, "Joan Cucchiara" = >>>>> wrote: >>>>>=20 >>>>> Sam, >>>>>=20 >>>>> We are away this week returning on 7/23. Sorry, I can't review = the doc >>>>> until after 7/23 and it will >>>>> take a few days after that as I'll just be returning from = vacation. >>>>>=20 >>>>> I glanced at it and see that there are read-write objects in a row = (which >>>>> is >>>>> read-create) so that's >>>>> an error which I mentioned before. >>>>>=20 >>>>> Have you compiled this with smilint? >>>>>=20 >>>>> Thanks, >>>>> -Joan >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> ----- Original Message ----- >>>>> From: Sam Aldrin >>>>> To: Joan Cucchiara >>>>> Cc: Venkatesan Mahalingam ; Thomas Nadeau ; Kannan KV Sampath >>>>> Sent: Friday, July 13, 2012 9:11 PM >>>>> Subject: Fwd: draft-ietf-mpls-tp-te-mib-04.txt review request >>>>>=20 >>>>> Hi Joan, >>>>>=20 >>>>> Please find the updated MIB document. Apologize for the delay. We = plan to >>>>> publish the doc on Monday as it is the deadline before IETF. Diff = file is >>>>> attached as well. >>>>>=20 >>>>> This version addresses all your comments. Highlighting couple of = them to >>>>> make sure you are OK with them >>>>>=20 >>>>> 1. W.r.t mplsLocalID as index type, we have removed that using >>>>> MplsExtendedTunnelId itself. As the value range for this object = could >>>>> have >>>>> value of non-IP address, we are using it. This will make the = indices for >>>>> the >>>>> same as TunnelTable. >>>>> In the definition of IngressLSRId and and EgressLSRId, for TP = entries, we >>>>> added description to use value of non-IP address, which is local = ID. >>>>>=20 >>>>> I do hope this satisfies the need and not necessitate for a new = table >>>>> altogether for TP. >>>>>=20 >>>>> 2. In regards to adding references to TC conventions. We believe, = those >>>>> were >>>>> added in the reference section. IF we have missed any TC = references, >>>>> could >>>>> you kindly let us know. >>>>>=20 >>>>> Appreciate if you can get back by Monday noon time PST. I know it = is a >>>>> very >>>>> short time, but appreciate if you could do that. >>>>>=20 >>>>> thanks >>>>> -sam >>>>>=20 >>>>> ________________________________ >>>>>=20 >>>>>=20 >>>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >=20 From kireeti@juniper.net Tue Aug 21 13:28: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 193D821F8559 for ; Tue, 21 Aug 2012 13:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 dTKkqPzyKz-c for ; Tue, 21 Aug 2012 13:28:15 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD7821F854E for ; Tue, 21 Aug 2012 13:28:15 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUDPvWOGvpVkgW9eHZtyq5IqSerbJp3FA@postini.com; Tue, 21 Aug 2012 13:28:15 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([fe80::3c95:ce07:f642:ecd2%10]) with mapi; Tue, 21 Aug 2012 13:27:31 -0700 From: Kireeti Kompella To: "curtis@occnc.com" Date: Tue, 21 Aug 2012 13:27:29 -0700 Thread-Topic: [mpls] Question regarding MPLS reserved label with ECMP Thread-Index: Ac1/22NLQXuBk09WQz+NPeA0/T8joA== Message-ID: <39C735FD-D3DC-46A6-AB67-B4C871F175C7@juniper.net> References: <201208211352.q7LDqnA9039010@gateway2.orleans.occnc.com> In-Reply-To: <201208211352.q7LDqnA9039010@gateway2.orleans.occnc.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 Cc: "mpls@ietf.org" , Vivek Kumar Subject: Re: [mpls] Question regarding MPLS reserved label with ECMP 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, 21 Aug 2012 20:28:16 -0000 On Aug 21, 2012, at 6:52 , Curtis Villamizar wrote: > In message > Kireeti Kompella writes: >=20 >> On Aug 18, 2012, at 4:45 , Vivek Kumar wrote: >>=20 >>> Hi , >>> I have one question regarding whether MPLS reserved label should be use= d or skipped when Transit LSR is doing hashing on full label stack which ha= s some reserved label. >>=20 >> draft-ietf-mpls-entropy-label, section 4.3: >>=20 >> If a transit LSR recognizes the ELI, it MAY choose to load balance >> solely on the following label (the EL); otherwise, it SHOULD use as >> much of the whole label stack as feasible as keys for the load >> balancing function, with the exception that reserved labels MUST NOT >> be used. >>=20 >>> RFC 6391 , section 7 , says " Note that, depending on the number of la= bels hashed by the LSR, the >>> inclusion of the Router Alert label may cause the OAM packet to be >>> load-balanced to a different path from that taken by the data packets >>> with identical flow and PW labels". >>>=20 >>> The above comment implies that reserved label is used by LSR when doing= hashing for ECMP. >>>=20 >>> Is there any other RFC which states what should be the correct behavior= . >>>=20 >>> The draft " draft-ietf-mpls-entropy-label-05" section 4.3 , says reserv= ed label should not be used by LSR when doing hashing on label stack. >>>=20 >>>=20 >>> Regards, >>> Vivek >=20 >=20 > Kireeti, >=20 > entropy-label may be the first place where this advice has been given > and it is good that it is finally somewhere. >=20 > If there is a GAL that is also a reason not to hash on a reserved > label. The path with or without GAL should be the same. >=20 > The word "may" in "may cause" in the quoted statement from RFC 6391 is > significant. Some routers hash on everything they find. This is a > bad practice, but exists. This is one of the main reasons for including the above caveat. In general, as far as I can tell, the IETF has been reluctant to specify wh= at fields to load balance on, as this is to some extent an implementation c= hoice. Perhaps specifying the set of allowable fields, indirectly saying T= hou SHALT NOT (*) load balance on other fields until an RFC says you MAY, m= ight be a reasonable way of dealing with this. This would be across a numb= er of technologies -- IP (in its myriad guises: GRE, IP-in-IP, L2TPv2,3,...= , LISP), MPLS, etc., and a number of what we call transport fields (TCP, UD= P, that thing SIP uses, ...). Trouble is, every new encaps (e.g., NVGRE) w= ill mandate an update. Maybe that's a good thing, though -- load balancing= may not be optimal until the update, but at least it won't be "wrong", spr= aying flows indiscriminately across paths. Kireeti (*) Adrian will point out that this is not RFC 2119 language. It SHOULD be= , though. I'll have a serious talk with SOB. > Curtis From bhargav@force10networks.com Tue Aug 21 16:56: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 EBBF921F8645 for ; Tue, 21 Aug 2012 16:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.09 X-Spam-Level: * X-Spam-Status: No, score=1.09 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_EQ_STATIC=1.172, HOST_MISMATCH_NET=0.311] 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 E2L1QYMDmMZ5 for ; Tue, 21 Aug 2012 16:56:34 -0700 (PDT) Received: from mx.force10networks.com (207.47.62.31.static.nextweb.net [207.47.62.31]) by ietfa.amsl.com (Postfix) with ESMTP id 68C5F21F861A for ; Tue, 21 Aug 2012 16:56:34 -0700 (PDT) Received: from EX07-SJC-MBX1.force10networks.com ([fe80:0000:0000:0000:30d7:5b59:107.47.36.196]) by exch7-sjc-fe.force10networks.com ([10.11.0.87]) with mapi; Tue, 21 Aug 2012 16:56:33 -0700 From: Bhargav Bhikkaji To: Kireeti Kompella , "curtis@occnc.com" Date: Tue, 21 Aug 2012 16:55:22 -0700 Thread-Topic: [mpls] Question regarding MPLS reserved label with ECMP Thread-Index: Ac1/22NLQXuBk09WQz+NPeA0/T8joAAHQn9G Message-ID: References: <201208211352.q7LDqnA9039010@gateway2.orleans.occnc.com>, <39C735FD-D3DC-46A6-AB67-B4C871F175C7@juniper.net> In-Reply-To: <39C735FD-D3DC-46A6-AB67-B4C871F175C7@juniper.net> 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 Cc: "mpls@ietf.org" , Vivek Kumar Subject: Re: [mpls] Question regarding MPLS reserved label with ECMP 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, 21 Aug 2012 23:56:35 -0000 Hi Kireeti, Liked the idea of having entropy label, something similar to having flow-la= bel for load balancing in ipv6. In case of transit LSR (transit is a differ= ent vendor to ingress LSR), where ELI is recognized and chooses to load bal= ance solely on label following EL. The ingress would create entropy label b= ased on it's load balancing function and the transit would use this label f= or it's hasing functions, as both implementations are different and single = hashing algorithm does not load balance equally for all types of traffic, i= s there a possibility of un-equal loadbalancing observed in the transit ?=20 Thanks Bhargav ________________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Kireeti Ko= mpella [kireeti@juniper.net] Sent: Wednesday, August 22, 2012 1:57 AM To: curtis@occnc.com Cc: mpls@ietf.org; Vivek Kumar Subject: Re: [mpls] Question regarding MPLS reserved label with ECMP On Aug 21, 2012, at 6:52 , Curtis Villamizar wrote: > In message > Kireeti Kompella writes: > >> On Aug 18, 2012, at 4:45 , Vivek Kumar wrote: >> >>> Hi , >>> I have one question regarding whether MPLS reserved label should be use= d or skipped when Transit LSR is doing hashing on full label stack which ha= s some reserved label. >> >> draft-ietf-mpls-entropy-label, section 4.3: >> >> If a transit LSR recognizes the ELI, it MAY choose to load balance >> solely on the following label (the EL); otherwise, it SHOULD use as >> much of the whole label stack as feasible as keys for the load >> balancing function, with the exception that reserved labels MUST NOT >> be used. >> >>> RFC 6391 , section 7 , says " Note that, depending on the number of la= bels hashed by the LSR, the >>> inclusion of the Router Alert label may cause the OAM packet to be >>> load-balanced to a different path from that taken by the data packets >>> with identical flow and PW labels". >>> >>> The above comment implies that reserved label is used by LSR when doing= hashing for ECMP. >>> >>> Is there any other RFC which states what should be the correct behavior= . >>> >>> The draft " draft-ietf-mpls-entropy-label-05" section 4.3 , says reserv= ed label should not be used by LSR when doing hashing on label stack. >>> >>> >>> Regards, >>> Vivek > > > Kireeti, > > entropy-label may be the first place where this advice has been given > and it is good that it is finally somewhere. > > If there is a GAL that is also a reason not to hash on a reserved > label. The path with or without GAL should be the same. > > The word "may" in "may cause" in the quoted statement from RFC 6391 is > significant. Some routers hash on everything they find. This is a > bad practice, but exists. This is one of the main reasons for including the above caveat. In general, as far as I can tell, the IETF has been reluctant to specify wh= at fields to load balance on, as this is to some extent an implementation c= hoice. Perhaps specifying the set of allowable fields, indirectly saying T= hou SHALT NOT (*) load balance on other fields until an RFC says you MAY, m= ight be a reasonable way of dealing with this. This would be across a numb= er of technologies -- IP (in its myriad guises: GRE, IP-in-IP, L2TPv2,3,...= , LISP), MPLS, etc., and a number of what we call transport fields (TCP, UD= P, that thing SIP uses, ...). Trouble is, every new encaps (e.g., NVGRE) w= ill mandate an update. Maybe that's a good thing, though -- load balancing= may not be optimal until the update, but at least it won't be "wrong", spr= aying flows indiscriminately across paths. Kireeti (*) Adrian will point out that this is not RFC 2119 language. It SHOULD be= , though. I'll have a serious talk with SOB. > Curtis _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls= From loa@pi.nu Wed Aug 22 05:25: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 141C021F8648 for ; Wed, 22 Aug 2012 05:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 pcj0JX9T9Kzc for ; Wed, 22 Aug 2012 05:25:54 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 740C321F851E for ; Wed, 22 Aug 2012 05:25:54 -0700 (PDT) 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) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 5176A2A8003; Wed, 22 Aug 2012 14:25:52 +0200 (CEST) Message-ID: <5034CFCF.9030902@pi.nu> Date: Wed, 22 Aug 2012 14:25:51 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "mpls@ietf.org" , draft-ietf-mpls-tp-ring-protection@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , MPLS-TP ad hoc team Subject: [mpls] IPR poll on draft-ietf-mpls-tp-ring-protection 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, 22 Aug 2012 12:25:55 -0000 Working Group and authors; the authors of draft-ietf-mpls-tp-ring-protection has asked that the draft is working group last called. Before the working group last call, we would like to check whether there is IPR on the document that needs to be disclosed. Are you aware of any IPR that applies to draft-ietf-mpls-tp-ring-protection? 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 wyaacov@gmail.com Wed Aug 22 06:01: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 D9C3521F86AD for ; Wed, 22 Aug 2012 06:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=-0.006, 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 7N5TLue-cUaA for ; Wed, 22 Aug 2012 06:00:56 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9819E21F84DD for ; Wed, 22 Aug 2012 06:00:56 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so1096435vcb.31 for ; Wed, 22 Aug 2012 06:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oNOCgLorWH8EGOoQ5V+w59dopkmlzv2AdGpOkQpzuGY=; b=YeoEbduDDw8UVuY63uJv06RaAABC6cPAru5T1gTlFw8q6HSt6xCT7RXf6BmUlJdJX8 5p1Vw1ZQ4SIoG3XQZ7joPMEygpFcjXW/ZEhJjlcVNUTG1boSInPlOrmHJh4m7U6Tf+wM KyQplAOdG9xL2RfmEsYT1bymBFJbr/V/vfj4husL0hXOpp9YwhI2jMQ4xat0Y4nJFJF2 QB0Z90grL4yAj/Qi4O+Tyxs84xUoCjLDmS7PkqW9roofyrUpWwlms0OS3vViMDiOjbHg uojYIraMtKFvt2hV/QpdUOIVVB2qPi6DUDKqVG+EO8k4EXrMn3loGuThv4B0mnQ4uJ33 SHlQ== MIME-Version: 1.0 Received: by 10.52.70.46 with SMTP id j14mr13968824vdu.42.1345640456028; Wed, 22 Aug 2012 06:00:56 -0700 (PDT) Received: by 10.58.29.8 with HTTP; Wed, 22 Aug 2012 06:00:56 -0700 (PDT) In-Reply-To: <5034CFCF.9030902@pi.nu> References: <5034CFCF.9030902@pi.nu> Date: Wed, 22 Aug 2012 16:00:56 +0300 Message-ID: From: Yaacov Weingarten To: Loa Andersson Content-Type: multipart/alternative; boundary=20cf307f39aa60837d04c7da5583 Cc: "mpls@ietf.org" , draft-ietf-mpls-tp-ring-protection@tools.ietf.org Subject: Re: [mpls] IPR poll on draft-ietf-mpls-tp-ring-protection 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, 22 Aug 2012 13:01:01 -0000 --20cf307f39aa60837d04c7da5583 Content-Type: text/plain; charset=ISO-8859-1 I am not aware of any IPR related to this document, yaacov weingarten On Wed, Aug 22, 2012 at 3:25 PM, Loa Andersson wrote: > Working Group and authors; > > the authors of draft-ietf-mpls-tp-ring-**protection has > asked that the draft is working group last called. > > Before the working group last call, we would like to check whether > there is IPR on the document that needs to be disclosed. > > Are you aware of any IPR that applies to > draft-ietf-mpls-tp-ring-**protection? > > 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 > --20cf307f39aa60837d04c7da5583 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I am not aware of any IPR related to this document,
ya= acov weingarten

On Wed, Aug 22, 2012 at 3= :25 PM, Loa Andersson <loa@pi.nu> wrote:
Working Group and authors;

the authors of =A0draft-ietf-mpls-tp-ring-protection has
asked that the draft is working group last called.

Before the working group last call, we would like to check whether
there is IPR on the document that needs to be disclosed.

Are you aware of any IPR that applies to
draft-ietf-mpls-tp-ring-protection?

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 documen= ts 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 =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

--20cf307f39aa60837d04c7da5583-- From daniele.ceccarelli@ericsson.com Wed Aug 22 06:52: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 D46E721F84AF for ; Wed, 22 Aug 2012 06:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.585 X-Spam-Level: X-Spam-Status: No, score=-3.585 tagged_above=-999 required=5 tests=[AWL=2.664, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 t-UfLuONjETA for ; Wed, 22 Aug 2012 06:52:02 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB7621F849C for ; Wed, 22 Aug 2012 06:52:02 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-da-5034e400d8ad Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 84.8B.11467.004E4305; Wed, 22 Aug 2012 15:52:01 +0200 (CEST) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.2.59]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Wed, 22 Aug 2012 15:52:00 +0200 From: Daniele Ceccarelli To: Loa Andersson , "mpls@ietf.org" , "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" Date: Wed, 22 Aug 2012 15:51:58 +0200 Thread-Topic: [mpls] IPR poll on draft-ietf-mpls-tp-ring-protection Thread-Index: Ac2AYU0wZi0xtOfjTDaTPvUe1HbW+AAC58FA Message-ID: References: <5034CFCF.9030902@pi.nu> In-Reply-To: <5034CFCF.9030902@pi.nu> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: it-IT, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM+JvrS7jE5MAg+6l7Bafjq1ltzizt9bi 39w5zBbfLy1hsbi1dCWrA6vHkiU/mTx+3ZrE6jFrehubx5fLn9kCWKK4bFJSczLLUov07RK4 Mk60XmUteMJfse7QeZYGxo08XYycHBICJhLPrx9gg7DFJC7cWw9kc3EICZxilPh+7Bk7hLOA UeLpv5tADgcHm4CVxJNDPiBxEYHVjBLPj/1kB+lmFsiTOD5lJwuIzSKgKjFpfzMjiC0s4CTx aMEDsBoRAWeJt7P3MYLMEREwknjyhRMkzCsQLvF2VRMriC0koCLxe+cMZpASTqAxj9d6gYQZ BWQlJuxexAixSVzi1pP5TBA3C0gs2XOeGcIWlXj5+B8rRL2MxK9N31gh6vUkbkydwgZha0ss W/iaGWKtoMTJmU9YJjCKzUIydhaSlllIWmYhaVnAyLKKUTg3MTMnvdxQL7UoM7m4OD9Przh1 EyMw0g5u+a27g/HUOZFDjNIcLErivFxJ+/2FBNITS1KzU1MLUovii0pzUosPMTJxcEo1MEoz a70T2mbHtWIW89o/cTs7zpyNVzm3Y4ub76q1jcWsDgkqGS++BHmws3CtvHzZtOWWucrt45Pb vsov7Ntz5vyx02uO16WFvXN+7378zM/NOycdTJjva2I+d/XHJiEN7Sn3l6tbf1I70xUSlnLK QcR0aqLX8jd9XE27nDSqzj91YT8T7aguvleJpTgj0VCLuag4EQDGcgmXggIAAA== Cc: "mpls-chairs@tools.ietf.org" , MPLS-TP ad hoc team Subject: Re: [mpls] IPR poll on draft-ietf-mpls-tp-ring-protection 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, 22 Aug 2012 13:52:07 -0000 Hi, I'm only aware of the IPR disclosed in December 2010 (https://datatracker= .ietf.org/ipr/1462/) BR Daniele >-----Original Message----- >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 >Behalf Of Loa Andersson >Sent: mercoled=EC 22 agosto 2012 14.26 >To: mpls@ietf.org; draft-ietf-mpls-tp-ring-protection@tools.ietf.org >Cc: mpls-chairs@tools.ietf.org; MPLS-TP ad hoc team >Subject: [mpls] IPR poll on draft-ietf-mpls-tp-ring-protection > >Working Group and authors; > >the authors of draft-ietf-mpls-tp-ring-protection has asked=20 >that the draft is working group last called. > >Before the working group last call, we would like to check=20 >whether there is IPR on the document that needs to be disclosed. > >Are you aware of any IPR that applies to=20 >draft-ietf-mpls-tp-ring-protection? > >If so, has this IPR been disclosed in compliance with IETF IPR=20 >rules (see RFCs 3979, 4879, 3669 and 5378 for more details). > >If you are listed as a document author or contributor please=20 >respond to this email regardless of whether or not you are=20 >aware of any relevant IPR. The response needs to be sent to=20 >the MPLS wg mailing list. The documents will not advance to=20 >the next stage until a response has been received from each=20 >author and contributor. > >If you are on the MPLS WG email list but are not listed as an=20 >author or contributor, then please explicitly respond only if=20 >you are aware of any IPR that has not yet been disclosed in=20 >conformance with IETF rules. > >Thanks, Loa >(as 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=20 >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls >= From corsi.marco@gmail.com Wed Aug 22 07:37: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 EA45421F8501 for ; Wed, 22 Aug 2012 07:37:53 -0700 (PDT) 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 Gr13NoyY2ah1 for ; Wed, 22 Aug 2012 07:37:53 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF2A21F84DD for ; Wed, 22 Aug 2012 07:37:53 -0700 (PDT) Received: by qcac10 with SMTP id c10so754328qca.31 for ; Wed, 22 Aug 2012 07:37:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KLBRQCmGBaRRg5+fha+xSxhpETp9SbP0etVWTn5g/XE=; b=u9U7n/3OsFS8DU+ti0sk8V6sJpseFq5asjFyqcsGJ0K5Cz4PEF3mMuMWW2tCwb0DNc wFdsYGbztqcMHl4QKzwaW7+qk1U2qpda39GlMRu8aY98wLc4qtoaXPV2rn4brKwyZNp5 xdo/x/uRWu6uoW4DG5Ho4FyRdRCxfzbBH5LpCCGe37D3KIRbZnPZ5oXWWlvuMxfI0TGo X9wIJKLIg2MVx4Mz2Yd6QW8zaW49zknERdjqm41WzfDYKK+hWFMryQomwDK6Z8/BiEOb KE7MIGoGWz0pSkkrYO7dPCP2lNUCuYMD0YPlC599SU3UeZuDyb5jtdv9S4ueWKYsSjR3 5EHA== MIME-Version: 1.0 Received: by 10.58.189.69 with SMTP id gg5mr18059597vec.6.1345646272610; Wed, 22 Aug 2012 07:37:52 -0700 (PDT) Received: by 10.59.10.41 with HTTP; Wed, 22 Aug 2012 07:37:52 -0700 (PDT) In-Reply-To: <5034CFCF.9030902@pi.nu> References: <5034CFCF.9030902@pi.nu> Date: Wed, 22 Aug 2012 16:37:52 +0200 Message-ID: From: Marco Corsi To: Loa Andersson , "mpls@ietf.org" , draft-ietf-mpls-tp-ring-protection@tools.ietf.org Content-Type: multipart/alternative; boundary=047d7b67295612820904c7dbb0f6 X-Mailman-Approved-At: Wed, 22 Aug 2012 08:21:42 -0700 Cc: "mpls-chairs@tools.ietf.org" , MPLS-TP ad hoc team Subject: Re: [mpls] IPR poll on draft-ietf-mpls-tp-ring-protection 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, 22 Aug 2012 14:37:54 -0000 --047d7b67295612820904c7dbb0f6 Content-Type: text/plain; charset=ISO-8859-1 Hi, I am not aware of any IPR related to this document. BR, Marco 2012/8/22 Loa Andersson > Working Group and authors; > > the authors of draft-ietf-mpls-tp-ring-**protection has > asked that the draft is working group last called. > > Before the working group last call, we would like to check whether > there is IPR on the document that needs to be disclosed. > > Are you aware of any IPR that applies to > draft-ietf-mpls-tp-ring-**protection? > > 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 > --047d7b67295612820904c7dbb0f6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I am not aware of = any IPR related to this document.

BR,
Marco
=
2012/8/22 Loa Andersson <loa@pi.nu>
Working Group and authors;

the authors of =A0draft-ietf-mpls-tp-ring-protection has
asked that the draft is working group last called.

Before the working group last call, we would like to check whether
there is IPR on the document that needs to be disclosed.

Are you aware of any IPR that applies to
draft-ietf-mpls-tp-ring-protection?

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 documen= ts 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 =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

--047d7b67295612820904c7dbb0f6-- From eosborne@cisco.com Wed Aug 22 13:04: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 A2C5621F8514 for ; Wed, 22 Aug 2012 13:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.311 X-Spam-Level: X-Spam-Status: No, score=-10.311 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, GB_ABOUTYOU=0.5, 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 o0mkoUht6Y41 for ; Wed, 22 Aug 2012 13:04:55 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id CC35921F851B for ; Wed, 22 Aug 2012 13:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=2284; q=dns/txt; s=iport; t=1345665895; x=1346875495; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=6LgURfOH6lGNCcAXrIqVga60WEwjvLF781M9AChf/xQ=; b=KyinGUalZ14rIgA33Revqx/I6tdUO5sllhoXy3V9Qjamj7vP5r31T1uG uIMXN5U38xqm+cEjci/Fkh9q+Cfdxz3FMLJ6a+H0y9OUUIWa2Ks5Jjuez BJN2f+8joCDddV90o8E9SO/97X76h7cC/wjwpQIFOJ7bQ4pRDGBLRdgx7 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEw6NVCtJXHB/2dsb2JhbABFuk2BB4IiAQQOBAEUEysmASoUQiYBBAEaGodrmGmgQpFEYAOjf4FmgmM X-IronPort-AV: E=Sophos;i="4.80,809,1344211200"; d="scan'208";a="114331894" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 22 Aug 2012 20:04:55 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q7MK4p7l020263 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Aug 2012 20:04:54 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0298.004; Wed, 22 Aug 2012 15:04:51 -0500 From: "Eric Osborne (eosborne)" To: "mpls@ietf.org" , "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" Thread-Topic: Comments on draft-ietf-mpls-tp-ring-protection Thread-Index: Ac2Am22fhY+HY5maSCeDdFLvV1Csxw== Date: Wed, 22 Aug 2012 20:04:49 +0000 Message-ID: <20ECF67871905846A80F77F8F4A275720F54C73E@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.23.92] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19132.000 x-tm-as-result: No--38.312200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] Comments on draft-ietf-mpls-tp-ring-protection 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, 22 Aug 2012 20:04:57 -0000 I apologize if these are coming in later than you'd like; I saw Loa's IP qu= ery and realized I hadn't commented on this draft in a while. Two quick typographical comments: i) section 2.1, 'LSP arounf the failed' should be 'LSP around the failed' ii) Figure 1, the wrapped data path goes A-B-C-D-E but should go A-B-C-D-E-= F, as per the text immediately following. One comment on link vs node protection. There are few places, e.g. section= 2.4, which say that providing both link and node protection are difficult.= I do not believe this to be true. I am familiar with two implementations= that are easily able to do this today. The algorithm is simple; if the th= ing you're protecting ends on the next-hop, use link protection. Otherwise= use node. I agree that with a statically configured network it becomes th= e responsibility of the NMS to make sure this is done right, but it's a sim= ple thing to do. Also, it looks like the draft makes two assumptions, which I've spelled out= below. Can you confirm or deny? i)=20 It looks like your protection mechanisms all assume that when traffic enter= s the ring, it either goes CW or CCW. In other words, take your Figure 6. = The protected LSP is A->B->[C]->[D]->E->[F]. This implies that you do not= allow mcast traffic to enter at A and branch both right and left. In othe= r words, the following p2mp is not allowed: A ->[F]->E->[D] ->E-[C] Is that correct? =20 ii) Does the draft assume that I can have a W LSP in two directions? For a fou= r-node ring A-B-C-D-A, can I have both W:A-B-C and W:A-D-C? This won't app= ly in all cases but it may be desirable to load-balance traffic in both dir= ections across the ring. This has implications on the wrapping protection = methods. I'd also like to very much see a scale analysis of the five protection mech= anisms discussed in the draft. I started work on one but realized I needed= to clear up my questions about your assumptions. I think the p2mp mechani= sms may have serious scale challenges, but I want to make sure I get the as= sumptions right before discussing the scale. Once I understand the assumpt= ions better, I'll send out my thoughts on scale. thanks! eric From gregory.mirsky@ericsson.com Wed Aug 22 14:46: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 2F47621F85AA for ; Wed, 22 Aug 2012 14:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.148 X-Spam-Level: X-Spam-Status: No, score=-6.148 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, GB_ABOUTYOU=0.5, 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 0tdcx6xsgqVj for ; Wed, 22 Aug 2012 14:46:27 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5228621F8508 for ; Wed, 22 Aug 2012 14:46:27 -0700 (PDT) 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 q7MLlatJ007288; Wed, 22 Aug 2012 16:47:40 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.138]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 22 Aug 2012 17:46:25 -0400 From: Gregory Mirsky To: "Eric Osborne (eosborne)" , "mpls@ietf.org" , "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" Date: Wed, 22 Aug 2012 17:46:24 -0400 Thread-Topic: Comments on draft-ietf-mpls-tp-ring-protection Thread-Index: Ac2Am22fhY+HY5maSCeDdFLvV1CsxwADYaew Message-ID: References: <20ECF67871905846A80F77F8F4A275720F54C73E@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A275720F54C73E@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF13927FAC107EUSAACMS0715e_" MIME-Version: 1.0 Subject: Re: [mpls] Comments on draft-ietf-mpls-tp-ring-protection 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, 22 Aug 2012 21:46:28 -0000 --_000_FE60A4E52763E84B935532D7D9294FF13927FAC107EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Eric, putting down my $.02: I think that applicability of load-balancing techniques in MPSL-TP, includi= ng Link Bundle and/or Composite Links, have yet to be clarified. As for p2mp LSP ring protection, I think that SPME(s) can be used to protec= t sub-LSP(s). (At least until we finish with application of multi-point BFD= for unidirectional p2p and p2mp LSPs in MPLS-TP). Regards, Greg -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Eri= c Osborne (eosborne) Sent: Wednesday, August 22, 2012 1:05 PM To: mpls@ietf.org; draft-ietf-mpls-tp-ring-protection@tools.ietf.org Subject: [mpls] Comments on draft-ietf-mpls-tp-ring-protection I apologize if these are coming in later than you'd like; I saw Loa's IP qu= ery and realized I hadn't commented on this draft in a while. Two quick typographical comments: i) section 2.1, 'LSP arounf the failed' should be 'LSP around the failed' ii) Figure 1, the wrapped data path goes A-B-C-D-E but should go A-B-C-D-E-= F, as per the text immediately following. One comment on link vs node protection. There are few places, e.g. section= 2.4, which say that providing both link and node protection are difficult.= I do not believe this to be true. I am familiar with two implementations= that are easily able to do this today. The algorithm is simple; if the th= ing you're protecting ends on the next-hop, use link protection. Otherwise= use node. I agree that with a statically configured network it becomes th= e responsibility of the NMS to make sure this is done right, but it's a sim= ple thing to do. Also, it looks like the draft makes two assumptions, which I've spelled out= below. Can you confirm or deny? i) It looks like your protection mechanisms all assume that when traffic enter= s the ring, it either goes CW or CCW. In other words, take your Figure 6. = The protected LSP is A->B->[C]->[D]->E->[F]. This implies that you do not= allow mcast traffic to enter at A and branch both right and left. In othe= r words, the following p2mp is not allowed: A ->[F]->E->[D] ->E-[C] Is that correct? ii) Does the draft assume that I can have a W LSP in two directions? For a fou= r-node ring A-B-C-D-A, can I have both W:A-B-C and W:A-D-C? This won't app= ly in all cases but it may be desirable to load-balance traffic in both dir= ections across the ring. This has implications on the wrapping protection = methods. I'd also like to very much see a scale analysis of the five protection mech= anisms discussed in the draft. I started work on one but realized I needed= to clear up my questions about your assumptions. I think the p2mp mechani= sms may have serious scale challenges, but I want to make sure I get the as= sumptions right before discussing the scale. Once I understand the assumpt= ions better, I'll send out my thoughts on scale. thanks! eric _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_FE60A4E52763E84B935532D7D9294FF13927FAC107EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Eric,
putting down my $.02:
I think that applicability of load-ba= lancing techniques in MPSL-TP, including Link Bundle and/or Composite Links= , have yet to be clarified.
As for p2mp LSP ring protection, I th= ink that SPME(s) can be used to protect sub-LSP(s). (At least until we fini= sh with application of multi-point BFD for unidirectional p2p and p2mp LSPs= in MPLS-TP).
 
      &= nbsp; Regards,
      &= nbsp;         Greg
 
-----Original Message-----
From: mpls-bounces@ietf.org [= mailto:mpls-bounces@ietf.org] On = Behalf Of Eric Osborne (eosborne)
Sent: Wednesday, August 22, 2012 1:05 PM
To: mpls@ietf.org; draft-ietf-mpls-tp-ring-protection@tools.ietf.org
Subject: [mpls] Comments on draft-ietf-mpls-tp-ring-protection
 
I apologize if these are coming in later than you'd like; I saw Loa's = IP query and realized I hadn't commented on this draft in a while.
 
Two quick typographical comments:
 
i) section 2.1, 'LSP arounf the failed' should be 'LSP around the fail= ed'
ii) Figure 1, the wrapped data path goes A-B-C-D-E but should go A-B-C= -D-E-F, as per the text immediately following.
 
 
One comment on link vs node protection.  There are few places, e.= g. section 2.4, which say that providing both link and node protection are = difficult.  I do not believe this to be true.  I am familiar with= two implementations that are easily able to do this today.  The algorithm is simple; if the thing you're protecting e= nds on the next-hop, use link protection.  Otherwise use node.  I= agree that with a statically configured network it becomes the responsibil= ity of the NMS to make sure this is done right, but it's a simple thing to do.
 
Also, it looks like the draft makes two assumptions, which I've spelle= d out below.  Can you confirm or deny?
 
i)
It looks like your protection mechanisms all assume that when traffic = enters the ring, it either goes CW or CCW.  In other words, take your = Figure 6.  The protected LSP is A->B->[C]->[D]->E->[F].=   This implies that you do not allow mcast traffic to enter at A and branch both right and left.  In other words, the following p2= mp is not allowed:
 
A
->[F]->E->[D]
->E-[C]
 
Is that correct? 
 
 
 
ii)
Does the draft assume that I can have a W LSP in two directions? = For a four-node ring A-B-C-D-A, can I have both W:A-B-C and W:A-D-C? = This won't apply in all cases but it may be desirable to load-balance traf= fic in both directions across the ring.  This has implications on the wrapping protection methods.
 
 
I'd also like to very much see a scale analysis of the five protection= mechanisms discussed in the draft.  I started work on one but realize= d I needed to clear up my questions about your assumptions.  I think t= he p2mp mechanisms may have serious scale challenges, but I want to make sure I get the assumptions right before disc= ussing the scale.  Once I understand the assumptions better, I'll send= out my thoughts on scale.
 
thanks!
 
 
 
 
 
eric
_______________________________________________
mpls mailing list
mpls@ietf.org
 
 --_000_FE60A4E52763E84B935532D7D9294FF13927FAC107EUSAACMS0715e_-- From wyaacov@gmail.com Wed Aug 22 23:11: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 D9FBA21F8541 for ; Wed, 22 Aug 2012 23:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.578, BAYES_00=-2.599, GB_ABOUTYOU=0.5, 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 KYogTeYLausn for ; Wed, 22 Aug 2012 23:11:33 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BE1F921F8503 for ; Wed, 22 Aug 2012 23:11:32 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so447061vbb.31 for ; Wed, 22 Aug 2012 23:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8zy1Kao3UGv3PlxHermmSFEjsHVRngcPr3B+UcneQiY=; b=Y9iKCOt1nFvADA89/Zv4583M1WB3Ora5PuXtVRm1WeVrhw4r3UVZQNmQput0Tj4hOt Mz+z6W897X1dJdKJSQE0iBhlppr9csGCrABEpO9EQxyxCPUgVvAh59AFRad2czBRIADA 3obj8K5358ZS4ojkmoR7PgFCocJckgPsdmdup25FCK6d/6Krqsg3dHp0R4iEjYUHDmn5 4KRCVp1IJ/Q9x3RwE84tJ/GvKku5rF+7oSCj0Gi8Gxc+0eEzjyADNtorRKDSW6EPPAuH ZR247NYpqa5yZ6L1ASI0fqwGCugWmx02IDmCkR3aJY9x/ZO8hNkBcphRDmhxANALf5lv /LrA== MIME-Version: 1.0 Received: by 10.52.69.242 with SMTP id h18mr283881vdu.54.1345702291906; Wed, 22 Aug 2012 23:11:31 -0700 (PDT) Received: by 10.58.29.8 with HTTP; Wed, 22 Aug 2012 23:11:31 -0700 (PDT) In-Reply-To: <20ECF67871905846A80F77F8F4A275720F54C73E@xmb-rcd-x09.cisco.com> References: <20ECF67871905846A80F77F8F4A275720F54C73E@xmb-rcd-x09.cisco.com> Date: Thu, 23 Aug 2012 09:11:31 +0300 Message-ID: From: Yaacov Weingarten To: "Eric Osborne (eosborne)" Content-Type: multipart/alternative; boundary=20cf307cfcec151f7104c7e8bb48 Cc: "mpls@ietf.org" , "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" Subject: Re: [mpls] Comments on draft-ietf-mpls-tp-ring-protection 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, 23 Aug 2012 06:11:34 -0000 --20cf307cfcec151f7104c7e8bb48 Content-Type: text/plain; charset=ISO-8859-1 Eric, hi Thank you for your comments - see my answers below inline. On Wed, Aug 22, 2012 at 11:04 PM, Eric Osborne (eosborne) < eosborne@cisco.com> wrote: > I apologize if these are coming in later than you'd like; I saw Loa's IP > query and realized I hadn't commented on this draft in a while. > > Two quick typographical comments: > > i) section 2.1, 'LSP arounf the failed' should be 'LSP around the failed' > yw>> thank you for pointing this out > ii) Figure 1, the wrapped data path goes A-B-C-D-E but should go > A-B-C-D-E-F, as per the text immediately following. > yw>> This was actually sent to us during the Vancouver meeting, and will be corrected in the next version. I just figured that we should first go to WGLC and address all comments rather than delay the LC by publishing a new version. > > > One comment on link vs node protection. There are few places, e.g. > section 2.4, which say that providing both link and node protection are > difficult. I do not believe this to be true. I am familiar with two > implementations that are easily able to do this today. The algorithm is > simple; if the thing you're protecting ends on the next-hop, use link > protection. Otherwise use node. I agree that with a statically configured > network it becomes the responsibility of the NMS to make sure this is done > right, but it's a simple thing to do. > yw>> Yes, you are correct and previous versions of the draft actually included such a solution. However, there were many comments from different members that when we use such a scheme that the traffic is no longer using the same path in both directions and the protection path is "non-deterministic" which is bothersome to many transport service providers. We found that trying to address these comments complicated issues and therefore we suggest that the SP decide a-priori for each working path whether they want to apply link or node protection. > > Also, it looks like the draft makes two assumptions, which I've spelled > out below. Can you confirm or deny? > > i) > It looks like your protection mechanisms all assume that when traffic > enters the ring, it either goes CW or CCW. In other words, take your > Figure 6. The protected LSP is A->B->[C]->[D]->E->[F]. This implies that > you do not allow mcast traffic to enter at A and branch both right and > left. In other words, the following p2mp is not allowed: > > A > ->[F]->E->[D] > ->E-[C] > > Is that correct? > yw>> not 100% correct. There is a general transport industry assumption that all working traffic will (most probably for historical, i.e. SDH, reasons) always traverse a ring in only one direction, however, you should note that the protection that is described in section 3.2 of the document actually could split the traffic to go in both directions for p2mp traffic. In addition, see my comment to your next comment. > > > > ii) > Does the draft assume that I can have a W LSP in two directions? For a > four-node ring A-B-C-D-A, can I have both W:A-B-C and W:A-D-C? This won't > apply in all cases but it may be desirable to load-balance traffic in both > directions across the ring. This has implications on the wrapping > protection methods. > yw> Yes, the draft assumes protection per LSP that traverses the ring, therefore you could setup protection for two LSPs one that goes A-B-C and additional protection for the working LSP that traverses A-D-C > > > I'd also like to very much see a scale analysis of the five protection > mechanisms discussed in the draft. I started work on one but realized I > needed to clear up my questions about your assumptions. I think the p2mp > mechanisms may have serious scale challenges, but I want to make sure I get > the assumptions right before discussing the scale. Once I understand the > assumptions better, I'll send out my thoughts on scale. > > thanks! > > > > > > eric > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --20cf307cfcec151f7104c7e8bb48 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Eric, hi

Thank you for your comments - = see my answers below inline.

On Wed, Aug = 22, 2012 at 11:04 PM, Eric Osborne (eosborne) <eosborne@cisco.com>= wrote:
I apologize if these are coming in later tha= n you'd like; I saw Loa's IP query and realized I hadn't commen= ted on this draft in a while.

Two quick typographical comments:

i) section 2.1, 'LSP arounf the failed' should be 'LSP around t= he failed'
yw>> thank you for pointing this = out=A0
ii) Figure 1, the wrapped data path goes A-B-C-D-E but should go A-B-C-D-E-= F, as per the text immediately following.
yw>> T= his was actually sent to us during the Vancouver meeting, and will be corre= cted in the next version. =A0I just figured that we should first go to WGLC= and address all comments rather than delay the LC by publishing a new vers= ion.=A0


One comment on link vs node protection. =A0There are few places, e.g. secti= on 2.4, which say that providing both link and node protection are difficul= t. =A0I do not believe this to be true. =A0I am familiar with two implement= ations that are easily able to do this today. =A0The algorithm is simple; i= f the thing you're protecting ends on the next-hop, use link protection= . =A0Otherwise use node. =A0I agree that with a statically configured netwo= rk it becomes the responsibility of the NMS to make sure this is done right= , but it's a simple thing to do.
yw>> Yes, you are correct and previous versions of = the draft actually included such a solution. =A0However, there were many co= mments from different members that when we use such a scheme that the traff= ic is no longer using the same path in both directions and the protection p= ath is "non-deterministic" which is bothersome to many transport = service providers. We found that trying to address these comments complicat= ed issues and therefore we suggest that the SP decide a-priori for each wor= king path whether they want to apply link or node protection.=A0

Also, it looks like the draft makes two assumptions, which I've spelled= out below. =A0Can you confirm or deny?

i)
It looks like your protection mechanisms all assume that when traffic enter= s the ring, it either goes CW or CCW. =A0In other words, take your Figure 6= . =A0The protected LSP is A->B->[C]->[D]->E->[F]. =A0This im= plies that you do not allow mcast traffic to enter at A and branch both rig= ht and left. =A0In other words, the following p2mp is not allowed:

A
=A0->[F]->E->[D]
=A0->E-[C]

Is that correct?
yw>> not 100% correct. =A0There= is a general transport industry assumption that all working traffic will (= most probably for historical, i.e. SDH, reasons) always traverse a ring in = only one direction, however, you should note that the protection that is de= scribed in section 3.2 of the document actually could split the traffic to = go in both directions for p2mp traffic. =A0In addition, see my comment to y= our next comment.=A0



ii)
Does the draft assume that I can have a W LSP in two directions? =A0For a f= our-node ring A-B-C-D-A, can I have both W:A-B-C and W:A-D-C? =A0This won&#= 39;t apply in all cases but it may be desirable to load-balance traffic in = both directions across the ring. =A0This has implications on the wrapping p= rotection methods.
yw> Yes, the draft assumes protection per LSP that tra= verses the ring, therefore you could setup protection for two LSPs one that= goes A-B-C and additional protection for the working LSP that traverses A-= D-C


I'd also like to very much see a scale analysis of the five protection = mechanisms discussed in the draft. =A0I started work on one but realized I = needed to clear up my questions about your assumptions. =A0I think the p2mp= mechanisms may have serious scale challenges, but I want to make sure I ge= t the assumptions right before discussing the scale. =A0Once I understand t= he assumptions better, I'll send out my thoughts on scale.

thanks!





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

--20cf307cfcec151f7104c7e8bb48-- From eosborne@cisco.com Thu Aug 23 04:22:17 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 74C1B21F863F for ; Thu, 23 Aug 2012 04:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.288 X-Spam-Level: X-Spam-Status: No, score=-10.288 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, GB_ABOUTYOU=0.5, 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 YqcprNhbLeSx for ; Thu, 23 Aug 2012 04:22:16 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 89AA721F84C5 for ; Thu, 23 Aug 2012 04:22:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=3970; q=dns/txt; s=iport; t=1345720936; x=1346930536; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=e+cEC2URyVP1tPWRAkZ8kqXD54swPwdQgttf/oFyzL8=; b=YIcPfv6yjIaLJvYrXRrsc8QhX1JJpgLd9dHL8tAcMDpqY+nkCBpKbTfr T3iVEU+5CB6vExzNrXP0Dt1EOWTrZ5yq9ER1unk5GbLT1jApMXzY5eSiZ 5SrntCgY/Pl00rkSFtUY9QFpKs45fTlH/Jvb0aPNpsk80eSQmdxwpGN1F g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFACESNlCtJXHB/2dsb2JhbABFulKBB4IgAQEBAwEBAQELBAEUEysJEAcEAgEIEQQBAQsUCQcnCxQJCAEBBAESCBqHZQYLmHagKASLCIYxYAOkAYFngmM X-IronPort-AV: E=Sophos;i="4.80,300,1344211200"; d="scan'208";a="114562770" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 23 Aug 2012 11:22:07 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q7NBM7nG031173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Aug 2012 11:22:07 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0298.004; Thu, 23 Aug 2012 06:22:07 -0500 From: "Eric Osborne (eosborne)" To: Gregory Mirsky , "mpls@ietf.org" , "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" Thread-Topic: Comments on draft-ietf-mpls-tp-ring-protection Thread-Index: Ac2Am22fhY+HY5maSCeDdFLvV1CsxwADYaewAB4c4HA= Date: Thu, 23 Aug 2012 11:22:06 +0000 Message-ID: <20ECF67871905846A80F77F8F4A275720F54D11E@xmb-rcd-x09.cisco.com> References: <20ECF67871905846A80F77F8F4A275720F54C73E@xmb-rcd-x09.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.98.23.92] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19132.005 x-tm-as-result: No--50.838300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] Comments on draft-ietf-mpls-tp-ring-protection 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, 23 Aug 2012 11:22:17 -0000 Hi Greg- Inline... > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Wednesday, August 22, 2012 5:46 PM > To: Eric Osborne (eosborne); mpls@ietf.org; draft-ietf-mpls-tp-ring- > protection@tools.ietf.org > Subject: RE: Comments on draft-ietf-mpls-tp-ring-protection >=20 > Hi Eric, > putting down my $.02: > I think that applicability of load-balancing techniques in MPSL-TP, inclu= ding > Link Bundle and/or Composite Links, have yet to be clarified. I wasn't talking about link-layer balancing or about load balancing of p2p = traffic. I was talking about a p2mp LSP which can enter the ring and send = traffic both CW and CCW. eric > As for p2mp LSP ring protection, I think that SPME(s) can be used to prot= ect > sub-LSP(s). (At least until we finish with application of multi-point BFD= for > unidirectional p2p and p2mp LSPs in MPLS-TP). >=20 > Regards, > Greg >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org bounces@ietf.org> ] On Behalf Of Eric Osborne (eosborne) > Sent: Wednesday, August 22, 2012 1:05 PM > To: mpls@ietf.org; draft-ietf-mpls-tp-ring-protection@tools.ietf.org > Subject: [mpls] Comments on draft-ietf-mpls-tp-ring-protection >=20 > I apologize if these are coming in later than you'd like; I saw Loa's IP = query > and realized I hadn't commented on this draft in a while. >=20 > Two quick typographical comments: >=20 > i) section 2.1, 'LSP arounf the failed' should be 'LSP around the failed' > ii) Figure 1, the wrapped data path goes A-B-C-D-E but should go A-B-C-D-= E- > F, as per the text immediately following. >=20 >=20 > One comment on link vs node protection. There are few places, e.g. secti= on > 2.4, which say that providing both link and node protection are difficult= . I do > not believe this to be true. I am familiar with two implementations that= are > easily able to do this today. The algorithm is simple; if the thing you'= re > protecting ends on the next-hop, use link protection. Otherwise use node= . I > agree that with a statically configured network it becomes the responsibi= lity > of the NMS to make sure this is done right, but it's a simple thing to do= . >=20 > Also, it looks like the draft makes two assumptions, which I've spelled o= ut > below. Can you confirm or deny? >=20 > i) > It looks like your protection mechanisms all assume that when traffic ent= ers > the ring, it either goes CW or CCW. In other words, take your Figure 6. = The > protected LSP is A->B->[C]->[D]->E->[F]. This implies that you do not al= low > mcast traffic to enter at A and branch both right and left. In other wor= ds, the > following p2mp is not allowed: >=20 > A > ->[F]->E->[D] > ->E-[C] >=20 > Is that correct? >=20 >=20 >=20 > ii) > Does the draft assume that I can have a W LSP in two directions? For a f= our- > node ring A-B-C-D-A, can I have both W:A-B-C and W:A-D-C? This won't > apply in all cases but it may be desirable to load-balance traffic in bot= h > directions across the ring. This has implications on the wrapping protec= tion > methods. >=20 >=20 > I'd also like to very much see a scale analysis of the five protection > mechanisms discussed in the draft. I started work on one but realized I > needed to clear up my questions about your assumptions. I think the p2mp > mechanisms may have serious scale challenges, but I want to make sure I g= et > the assumptions right before discussing the scale. Once I understand the > assumptions better, I'll send out my thoughts on scale. >=20 > thanks! >=20 >=20 >=20 >=20 >=20 > eric > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > >=20 From Alexander.Vainshtein@ecitele.com Thu Aug 23 06:46: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 BAE5B21F85A5 for ; Thu, 23 Aug 2012 06:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.207 X-Spam-Level: X-Spam-Status: No, score=-5.207 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, 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 sGo25qMgMb81 for ; Thu, 23 Aug 2012 06:46:28 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1622D21F8594 for ; Thu, 23 Aug 2012 06:46:27 -0700 (PDT) Received: from [85.158.138.51:25797] by server-11.bemta-3.messagelabs.com id 74/1F-23152-23436305; Thu, 23 Aug 2012 13:46:26 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1345729558!27727712!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.6.1.3; banners=-,-,- Received: (qmail 24181 invoked from network); 23 Aug 2012 13:45:58 -0000 Received: from unknown (HELO fridlpvsb003.ecitele.com) (168.87.1.157) by server-5.tower-174.messagelabs.com with SMTP; 23 Aug 2012 13:45:58 -0000 X-AuditID: a8571403-b7f996d000000af3-5a-50363420f48f Received: from FRGRWPVCH001.ecitele.com (Unknown_Domain [10.1.18.35]) by fridlpvsb003.ecitele.com (Symantec Messaging Gateway) with SMTP id AA.A7.02803.02436305; Thu, 23 Aug 2012 15:46:09 +0200 (CEST) Received: from FRIDWPPMB002.ecitele.com ([169.254.4.244]) by FRGRWPVCH001.ecitele.com ([10.1.18.35]) with mapi id 14.01.0339.001; Thu, 23 Aug 2012 15:45:57 +0200 From: Alexander Vainshtein To: "david.i.allan@ericsson.com" , "swallow@cisco.com" , "John E Drake (jdrake@juniper.net)" Thread-Topic: A question regarding RFC 6428 Thread-Index: Ac2BNZvbMCmkHjiATrqyQfEmO1rwEA== Date: Thu, 23 Aug 2012 13:45:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.42.92] Content-Type: multipart/alternative; boundary="_000_F9336571731ADE42A5397FC831CEAA020D8878FRIDWPPMB002ecite_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTW0wUVxjumdnLcJl2WFY5brxMp8Gk4uLSVTMmLtGSJquJYVNMGnzRceew O+3uzDgzEjFpXEkqFqS4SBulJGBEA1UhYIwSlcBSHxYveFmiEVclEFNp0wdrS7TeZphAeenL 5Pv/7zvf98+ZfwjcEbe7CEHUkCJyEcaWackEH7jcH69eG/A0/Whjx0cu4GxLuoR9cLLTyvbH h63sWFM12GD1N/3bY/W/+nvU5u9rTtv97e0vMf+96lF7wLotBtZzoihpnIZoHqlBHxNQhEou WMXQAu9jihhajnBBFEWi5mM4WUYizxRnrtebgkgjMSjxghjyMZvKSt0su2adu4gp3hoWVBq5 o5wQoaNIVbkQovWOMbjII56ukBRaCyNaQUFBFtCOejw8PjZuka+W76mrCcRA45ZakEFAajW8 HbtkN/FCeOtRt60WZBIOahjAIw0PcbM4CWDyQjVuqGyUD/aeTs+onFQ7gIPxEbtR4NQQBg8d 6gCGKpdaDk+MpCwGdlIF8IfXSdzEhbD+1P2ZPAuVD387dw0zMEltgXcab8zogT7H9PCZmT5O 5cEHk62YOR8F2y+P4CZeAJ9NvLWaeCms7kzZTb0Ek7/+AUzPHJg8NmkxNYvgYMd9y2HgbJ5n 2zzvSPO8I2Z/JWy79Nxm4gJ46vjv+Cy+PjCBze+3AfsvAFYoAh+RK9WdHo+3UL92DUVQYVCK 9gJ9izq+cuIXwYuGwgSgCMBkk6x3TcBh5SrVqmgCLCIwZgGZcK8NOD7cKfFVYU4Nb1d2R5Ca AJDAGSe5OUPnSJ6r2osUaZb6Qr/EOO7KCkrGZ9e2ez2e/y+YPLL7y+JSBxXS1/AbhGSkzPos JggGkru8ekSOgkJoT4UQ0f6jMSLDGCNbH6PC0JCqzEVVIWTyw6CAeJdMpgFx4q3+dFhESUSu PLLMkFKGNLxbnHObAnn66+eSgsFm6+s65zOlR2B6xPJRrxGh/yxzlCsGlkx/VndsaolY35tT 6/H3DR18wdfcsT3/a9XZlulY/vl/EgdLuu6mPsHe/Dn2+fWSlp7WifTGx6myXV3fPrs5PjDU mTXdsI9+V7Py0/0rnn5EC5dDC7/7yVFHbcx9uOr83sG+10cby5dlfX/gSXzyTbqU/frKDi2e 2tC6v+tR/5FsRb75M2NRw1zRClxRufePa649JAQAAA== Cc: "mpls@ietf.org" , "robrennison@gmail.com" , Mishael Wexler Subject: [mpls] A question regarding RFC 6428 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, 23 Aug 2012 13:46:30 -0000 --_000_F9336571731ADE42A5397FC831CEAA020D8878FRIDWPPMB002ecite_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Dave/George/John, I have serious doubts regarding one of the modifications to the BFD FSM that= has been introduced in RFC 6428. The BFD FSM diagram (Figure 7) for coordinated BFD operation in Section 3.7.= 5 "State Machines" indicates that the BFD session transits from UP to DOWN u= pon receiving an LDI (and, optionally, LKR) message. Could you please explain the rationale for such a change in the BFD state ma= chine vs. what has been as described in RFC 5880? (The text in 6428 explains that the state machine is modified in order to su= pport mis-connectivity defect, but I do not see how this is related to LDI). This change is introduced in addition to a requirement from Section 3.7.2 th= at receiving Link Down Indication (be it a local link failure or an MPLS-TP= LDI message) results in entering a (presumably, Loss of Continuity) MEP def= ect state. Further, section 3.7.2 states that "receiving nothing" (i.e., exp= iration of the BFD session timer) has higher priority that reception of LDI.= My reading of these results in the following: 1. If LDI is received after the session timer expiration it is ignored 2. If LDI is received before the session timer expiration, the session= first goes down and sends back RDI with the Path Down diagnostic code. It i= s not clear whether the BFD session timer expiration results in changing the= diagnostic code to "Control Detection Timer Expired" or not 3. In the situation when BFD session timer does not expire while LDI s= tate remains active (e.g., because the LSP uses FRR or segment protection to= bypass the failed link), the session would cycle thru DOWN->INIT-->UP--> DO= WN - session flapping/churn. 4. It is not clear what is supposed to happen if the BFD session went= DOWN because an LDI message has been received and then LDI state has been c= leared (e.g., using the fast clearance mechanism defined in Section 5.2 of R= FC 6427) before t= he session timer has expired. To make my position clear, I do not see any issues with adding LDI as a trig= ger for sending the MEP to its DOWN state. I simply do not understand why th= is requires modification of the BFD State machine. At best this would speed= up generation of RDI towards the remote MEP, but the price does not seem to= justify the effort. Note that RDI is not used as a trigger for protection= actions; if bidirectional LSP protection is required, this is achieved via= the PSC - e.g., as defined in RFC 6378. Your feedback would be highly appreciated. Regards, Sasha This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_F9336571731ADE42A5397FC831CEAA020D8878FRIDWPPMB002ecite_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Dave/George/John,

 

I have serious doubts regarding one of the modificati= ons to the BFD FSM that has been introduced in RFC 64= 28.

The BFD FSM diagram (Figure 7) for coordinated BFD op= eration in Section 3.7.5 “State Machines” indicates that= the BFD session transits from UP to DOWN upon receiving an LDI (and, option= ally, LKR) message.

 

Could you please explain the rationale for such a cha= nge in the BFD state machine vs. what has been as described in RFC 58= 80?

(The text in 6428 explains that the state machine is= modified in order to support mis-connectivity defect, but I do not see how= this is related to LDI).

 

This change is introduced in addition to a requiremen= t from Section 3.7.2 that receiving Link Down Indication (be it a local link= failure or an MPLS-TP LDI message) results in entering a (presumably, Loss= of Continuity) MEP defect state. Further, section 3.7.2 states that “receiving nothing” (i.e., e= xpiration of the BFD session timer) has higher priority that reception of LD= I. My reading of these results in the following:

1.     &n= bsp; If LDI is received after th= e session timer expiration it is ignored

2.     &n= bsp; If LDI is received before t= he session timer expiration, the session first goes down and sends back RDI= with the Path Down diagnostic code. It is not clear whether the BFD session= timer expiration results in changing the diagnostic code to “Control Detection Timer Expired” or not=

3.     &n= bsp; In the situation when BFD s= ession timer does not expire while LDI state remains active (e.g., because t= he LSP uses FRR or segment protection to bypass the failed link), the sessio= n would cycle thru DOWN->INIT-->UP--> DOWN – session flapping/churn.

4.     &n= bsp; It is not clear what is sup= posed to happen if the BFD session went DOWN because an LDI message has been= received and then LDI state has been cleared (e.g., using the fast clearanc= e mechanism defined in Section 5.2 of RFC 6427) before the session timer has expired.

 

To make my position clear, I do not see any issues wi= th adding LDI as a trigger for sending the MEP to its DOWN state. I simply d= o not understand why this requires modification of the BFD State machine. At= best this would speed up generation of RDI towards the remote MEP, but the price does not seem to justify the e= ffort.  Note that RDI is not used as a trigger for protection actions;= if bidirectional LSP protection is required, this is achieved via the PSC &= #8211; e.g., as defined in RFC 63= 78.

 

Your feedback  would be highly appreciated.=

 

Regards,

     Sasha

 

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

--_000_F9336571731ADE42A5397FC831CEAA020D8878FRIDWPPMB002ecite_-- From francesco.fondelli@gmail.com Thu Aug 23 08:12: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 4E45B21F8566 for ; Thu, 23 Aug 2012 08:12:29 -0700 (PDT) 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 Ny9doVHAvSeX for ; Thu, 23 Aug 2012 08:12:28 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF5C21F8517 for ; Thu, 23 Aug 2012 08:12:28 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so1027929vcb.31 for ; Thu, 23 Aug 2012 08:12:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=k7ItxK4WmJduuG5glWK6+x4ixZ31PNLRL2nljn3PCb4=; b=sBK4Xbq+KRsgm7LnhZ4NTCX1D2lvsb4UYazzMD5pIMkC72gev8scwq5FE+mzNA6F/m rvtiOa3MZQchPbilsDh8ZMNLWeRm++FBAfC7xOcILurcnDEjGT9Vuum7dmg+73UGBI2D p4CHfAae7NUU01zFVddcvKTwMQBZrVi3urHycHNUROZpYsA2K5nMcTX4ve2qKH0x4kTA rOTn6nYxFA3lBNHqkYbVcaWot2CJkPlYoVVDmvHk3/0sUD6YAHkHbs+uPgWz2JIj1Pr3 9inJuX4VfprK7a7fEx/JDws65YK1nmNAwSQ1IHNoIs1QpUQBFWhu61rOn5guB/49X2M9 pcaw== MIME-Version: 1.0 Received: by 10.52.33.193 with SMTP id t1mr1298175vdi.96.1345734747881; Thu, 23 Aug 2012 08:12:27 -0700 (PDT) Received: by 10.52.31.194 with HTTP; Thu, 23 Aug 2012 08:12:27 -0700 (PDT) In-Reply-To: References: <5034CFCF.9030902@pi.nu> Date: Thu, 23 Aug 2012 17:12:27 +0200 Message-ID: From: Francesco Fondelli To: Daniele Ceccarelli Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: MPLS-TP ad hoc team , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-tp-ring-protection 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, 23 Aug 2012 15:12:29 -0000 I am not aware of any other IPR on this draft (except the one indicated by Daniele). Ciao Fra On Wed, Aug 22, 2012 at 3:51 PM, Daniele Ceccarelli wrote: > Hi, > > I'm only aware of the IPR disclosed in December 2010 (https://datatrack= er.ietf.org/ipr/1462/) > > BR > Daniele > >>-----Original Message----- >>From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >>Behalf Of Loa Andersson >>Sent: mercoled=C3=AC 22 agosto 2012 14.26 >>To: mpls@ietf.org; draft-ietf-mpls-tp-ring-protection@tools.ietf.org >>Cc: mpls-chairs@tools.ietf.org; MPLS-TP ad hoc team >>Subject: [mpls] IPR poll on draft-ietf-mpls-tp-ring-protection >> >>Working Group and authors; >> >>the authors of draft-ietf-mpls-tp-ring-protection has asked >>that the draft is working group last called. >> >>Before the working group last call, we would like to check >>whether there is IPR on the document that needs to be disclosed. >> >>Are you aware of any IPR that applies to >>draft-ietf-mpls-tp-ring-protection? >> >>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 >> > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From pranjal.dutta@alcatel-lucent.com Thu Aug 23 11:07: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 52D8421F8437 for ; Thu, 23 Aug 2012 11:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.636 X-Spam-Level: X-Spam-Status: No, score=-8.636 tagged_above=-999 required=5 tests=[AWL=0.473, BAYES_05=-1.11, 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 SB2xypq7yGwg for ; Thu, 23 Aug 2012 11:07:52 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 69D7921F8417 for ; Thu, 23 Aug 2012 11:07:51 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q7NI7mM6003729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 23 Aug 2012 13:07:50 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7NI7lBm005934 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 23 Aug 2012 23:37:47 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Thu, 23 Aug 2012 23:37:47 +0530 From: "Dutta, Pranjal K (Pranjal)" To: "mpls@ietf.org" Date: Thu, 23 Aug 2012 23:37:45 +0530 Thread-Topic: Question on LDP Multi-topology draft Thread-Index: Ac2BWjIZ0Xx3abQuRdipLNIkkDKwXA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C584046466ED224CA92C1BC3313B963E09F2382B09INBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: [mpls] Question on LDP Multi-topology draft 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, 23 Aug 2012 18:07:54 -0000 --_000_C584046466ED224CA92C1BC3313B963E09F2382B09INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Authors, I apologize if this is already discussed; I have a few= questions on the latest version of LDP MT draft (http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-04). The draft introduces two new address families - MT IP = and MT IPV6. This fits well into existing Prefix and mLdp FEC element types since the respective FEC elements has the Addres= s Family field. Could you please clarify how OAM tool sets (LSP Ping e= tc) are going to work for LDP-MT based prefix FECs? Following are encodings of LDP IPV4/V6 Targeted FEC sub-types as per RFC 43= 79. Sub-Type Length Value Field -------- ------ ----------- 1 5 LDP IPv4 prefix 2 17 LDP IPv6 prefix Sub-type 1 =3D LDP IPV4 FEC 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-type 2 =3D LDP IPV6 FEC 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 prefix | | (16 octets) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I don't see how existing Targeted FEC stack types would work for LDP-MT bas= ed Prefix FEC elements since it's the Targeted FEC sub-types that seem to hardcode the address family. The Multicast LDP FEC Stacks TLV (RFC 6425) bear Address Family field for R= oot address, so the LDP-MT extensions would get aligned. IMO, a section in the draft referring to OAM extensions (if required or not= required) would help. I think the following refers to section 9, as opposed to section 10. 3.4. IGP MT-ID Mapping and Translation The non-reserved non-special IGP MT-ID values can be used/carried in LDP as-is and need no translation. However, there is a need for translating reserved/special IGP MT-ID values to corresponding LDP MT-IDs. The corresponding special/reserved LDP MT-ID values are defined in later section 10. Thanks, Pranjal --_000_C584046466ED224CA92C1BC3313B963E09F2382B09INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Authors,

         &n= bsp;           I apologize if this is already discussed; I have a few questions on the lat= est version of LDP MT draft

(http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-to= pology-04).

 

         &n= bsp;          The draft introduces  two new address families – MT IP and MT IP= V6. This fits well into existing Prefix

and mLdp FEC element types since the respective FEC elem= ents has the Address Family field.

 

         &n= bsp;           Could you please clarify how OAM tool sets (LSP Ping etc) are going to work= for LDP-MT based prefix

FECs?

 

Following are encodings of LDP IPV4/V6 Targeted FEC sub-= types as per RFC 4379.

 

&=
nbsp;      Sub-Type      =
  Length         &nb=
sp;  Value Field
  =
    --------         =
; ------           -=
----------
  =
           1  &=
nbsp;         5   &n=
bsp;        LDP IPv4 prefix
  =
           2  &=
nbsp;        17    &=
nbsp;       LDP IPv6 prefix=

 <=
/o:p>
Sub-type 1 =
=3D LDP IPV4 FEC
 <=
/o:p>
  &=
nbsp;    0        &n=
bsp;          1  &nb=
sp;            =
    2         &=
nbsp;         3
  &=
nbsp;    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5=
 6 7 8 9 0 1
  &=
nbsp;   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+
  &=
nbsp;   |         &n=
bsp;            =
;    IPv4 prefix        &=
nbsp;           &nbs=
p;     |
  &=
nbsp;   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+
  &=
nbsp;   | Prefix Length |      &nbs=
p;  Must Be Zero         =
            &nb=
sp;    |
  &=
nbsp;   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+

 

Sub-type 2 =3D LDP IPV6 FEC

 

           0     &nb=
sp;            =
 1            &=
nbsp;      2      &n=
bsp;            3
  &=
nbsp;    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5=
 6 7 8 9 0 1
  &=
nbsp;   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+
  &=
nbsp;   |         &n=
bsp;            =
;    IPv6 prefix       &n=
bsp;            =
;      |
  &=
nbsp;   |         &n=
bsp;            =
;    (16 octets)       &n=
bsp;            =
;      |
  &=
nbsp;   |         &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;   |
  &=
nbsp;   |         &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;   |
  &=
nbsp;   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+
  &=
nbsp;   | Prefix Length |      &nbs=
p;  Must Be Zero         =
            &nb=
sp;    |
  &=
nbsp;   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+
 

I don’t see how existing Targeted FEC stack types would work for LDP-MT based Prefix FEC elements since it’s the <= /o:p>

Targeted FEC  sub-types that seem to hardcode the a= ddress family.

 

The Multicast LDP FEC Stacks TLV (RFC 6425) bear Address Family field for Root address, so the LDP-MT extensions

would get aligned.

 

IMO, a section in the draft referring to OAM extensions = (if required or not required) would help.

I think the following refers to section 9, as opposed t= o section 10.

3.4.  IGP MT-ID Mapping and Translation

 
   =
The non-reserved non-special IGP MT-ID values can be used/carried in
   =
LDP as-is and need no translation.  However, there is a need for<=
/o:p>
   =
translating reserved/special IGP MT-ID values to corresponding LDP
   =
MT-IDs.  The corresponding special/reserved LDP MT-ID values are<=
/o:p>
   =
defined in later section 10.

 

 

Thanks,

Pranjal

--_000_C584046466ED224CA92C1BC3313B963E09F2382B09INBANSXCHMBSA_-- From skraza@cisco.com Thu Aug 23 11:32: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 95CF721F84F1 for ; Thu, 23 Aug 2012 11:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.138 X-Spam-Level: X-Spam-Status: No, score=-10.138 tagged_above=-999 required=5 tests=[AWL=0.460, 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 bIs1kYbpdLPf for ; Thu, 23 Aug 2012 11:32:55 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 183B121F84A0 for ; Thu, 23 Aug 2012 11:32:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23140; q=dns/txt; s=iport; t=1345746769; x=1346956369; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=k9dToqqHawa54HegAdoNDFqsFfx74QDq+JvDXpxi3ts=; b=X/lclhWRgrUxCsX6NhRHuNTU/WsZ4/zSdWvfYJGi7kiI/r7dE334e+kZ srDFS1DfOXDodI9KkeaPSqx2EFsJmXP63yQ0YW98JXUxw99AT2V/VHZg5 yoPa3yRt2Y9U0zbkN2UsmWGbBvYGr+0rZF7aPSsRtTKnFp2ZkoXVoRyxe 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsUFAOV2NlCtJXG//2dsb2JhbABFgkqvOAGITIEHgiABAgQSARo6JAEIEQMBAiEHORQJCAEBBAESIodrC5lBoEuLCIcRA5VUgRSNGYFngmM X-IronPort-AV: E=Sophos;i="4.80,301,1344211200"; d="scan'208,217";a="111655164" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 23 Aug 2012 18:32:39 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7NIWcEj008544 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Aug 2012 18:32:38 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.113]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0298.004; Thu, 23 Aug 2012 13:32:38 -0500 From: "Kamran Raza (skraza)" To: "Dutta, Pranjal K (Pranjal)" , "mpls@ietf.org" Thread-Topic: [mpls] Question on LDP Multi-topology draft Thread-Index: Ac2BWjIZ0Xx3abQuRdipLNIkkDKwXAADBJsA Date: Thu, 23 Aug 2012 18:32:37 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [161.44.193.212] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19134.001 x-tm-as-result: No--31.330900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_CC5BEF771485Cskrazaciscocom_" MIME-Version: 1.0 Subject: Re: [mpls] Question on LDP Multi-topology draft 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, 23 Aug 2012 18:32:56 -0000 --_000_CC5BEF771485Cskrazaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Pranjal, I agree with your comment on adding a section / behavior for MPLS OAM exten= sions to support MT for Prefix FEC types. We will discuss amongst us (author) and update accordingly. Rgds, --Kamran From: , "Pranjal K (Pranjal)" > Date: Thursday, August 23, 2012 2:07 PM To: "mpls@ietf.org" > Subject: [mpls] Question on LDP Multi-topology draft Hi Authors, I apologize if this is already discussed; I have a few= questions on the latest version of LDP MT draft (http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-04). The draft introduces two new address families =96 MT I= P and MT IPV6. This fits well into existing Prefix and mLdp FEC element types since the respective FEC elements has the Addres= s Family field. Could you please clarify how OAM tool sets (LSP Ping e= tc) are going to work for LDP-MT based prefix FECs? Following are encodings of LDP IPV4/V6 Targeted FEC sub-types as per RFC 43= 79. Sub-Type Length Value Field -------- ------ ----------- 1 5 LDP IPv4 prefix 2 17 LDP IPv6 prefix Sub-type 1 =3D LDP IPV4 FEC 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-type 2 =3D LDP IPV6 FEC 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 prefix | | (16 octets) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I don=92t see how existing Targeted FEC stack types would work for LDP-MT b= ased Prefix FEC elements since it=92s the Targeted FEC sub-types that seem to hardcode the address family. The Multicast LDP FEC Stacks TLV (RFC 6425) bear Address Family field for R= oot address, so the LDP-MT extensions would get aligned. IMO, a section in the draft referring to OAM extensions (if required or not= required) would help. I think the following refers to section 9, as opposed to section 10. 3.4. IGP MT-ID Mapping and Translation The non-reserved non-special IGP MT-ID values can be used/carried in LDP as-is and need no translation. However, there is a need for translating reserved/special IGP MT-ID values to corresponding LDP MT-IDs. The corresponding special/reserved LDP MT-ID values are defined in later section 10. Thanks, Pranjal --_000_CC5BEF771485Cskrazaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7CC5144A32978848B5AE9F2D8447E939@cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Pranjal,

I agree with your comment on adding a section / behavior for MPLS OAM = extensions to support MT for Prefix FEC types.
We will discuss amongst us (author) and update accordingly.

Rgds,
--Kamran

From: <Dutta>, "Pranjal = K (Pranjal)" <p= ranjal.dutta@alcatel-lucent.com>
Date: Thursday, August 23, 2012 2:0= 7 PM
To: "mpls@ietf.org" <mpls@i= etf.org>
Subject: [mpls] Question on LDP Mul= ti-topology draft

Hi Authors,

         &n= bsp;           I apologiz= e if this is already discussed; I have a few questions on the latest versio= n of LDP MT draft

(http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-= topology-04).

 

         &n= bsp;          The draft introd= uces  two new address families =96 MT IP and MT IPV6. This fits well i= nto existing Prefix

and mLdp FEC element types since the respective FEC elem= ents has the Address Family field.

 

         &n= bsp;           Could you = please clarify how OAM tool sets (LSP Ping etc) are going to work for LDP-M= T based prefix

FECs?

 

Following are encodings of LDP IPV4/V6 Targeted FEC sub-= types as per RFC 4379.

 

       Sub-Type     =
;   Length         &=
nbsp;  Value Field
      --------      =
;    ------        &=
nbsp;  -----------
             1=
            5 &=
nbsp;          LDP IPv4 prefix=

             2=
           17  =
          LDP IPv6 prefix=

 
Sub-type 1 =3D LDP IPV4 FEC
 
=
       0      &=
nbsp;            1&n=
bsp;            =
;      2       =
            3
=
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 =
9 0 1 2 3 4 5 6 7 8 9 0 1
=
      +-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;
=
      |       &=
nbsp;           &nbs=
p;      IPv4 prefix     &=
nbsp;            &nb=
sp;       |

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


=
      | Prefix Length |    &nb=
sp;    Must Be Zero       =
;            &n=
bsp;      |


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


 


Sub-type 2 =3D LDP IPV6 FEC=



 


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


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


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


=
      |       &=
nbsp;           &nbs=
p;      IPv6 prefix     &=
nbsp;           &nbs=
p;        |

=
      |       &=
nbsp;           &nbs=
p;      (16 octets)     &=
nbsp;           &nbs=
p;        |

=
      |       &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;     |


=
      |       &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;     |


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


=
      | Prefix Length |    &nb=
sp;    Must Be Zero       =
;            &n=
bsp;      |


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


=
 


I don=92t see how existing Targeted FEC stack types woul=
d work for LDP-MT based Prefix FEC elements since it=92s the



Targeted FEC  sub-types that seem to hardcode the a=
ddress family.



 


The Multicast LDP FEC Stacks TLV (RFC 6425) bear Address=
 Family field for Root address, so the LDP-MT extensions


would get aligned.


 


IMO, a section in the draft referring to OAM extensions =
(if required or not required) would help.


I think the following refers to section 9, as opposed t=
o section 10.


3.4. 
 IGP MT-ID Mapping and Translation


=
 


=
   The non-reserved non-special IGP MT-ID values can be used/carr=
ied in


=
   LDP as-is and need no translation.  However, there is a n=
eed for


=
   translating reserved/special IGP MT-ID values to corresponding=
 LDP


=
   MT-IDs.  The corresponding special/reserved LDP MT-ID val=
ues are


=
   defined in later section 10.


 


 


Thanks,


Pranjal
--_000_CC5BEF771485Cskrazaciscocom_-- From aldrin.ietf@gmail.com Thu Aug 23 11:35: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 5CD1321F84F5 for ; Thu, 23 Aug 2012 11:35:11 -0700 (PDT) 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=[AWL=-0.001, 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 Gr1VvmgtHe8Q for ; Thu, 23 Aug 2012 11:35:09 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAB221F8493 for ; Thu, 23 Aug 2012 11:35:09 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so1918476pbb.31 for ; Thu, 23 Aug 2012 11:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=KRrAwpDLxQPgf72qwCobCFVIJB5eDDSsu91QmAkbXnY=; b=hVkAjk93bmZHfNQzL3N2rcLRpCfm5cgOfTBOuTMR3hRLBTD0/msCVThjoGpX54E5cM R0QikUmvesXtnfi0XPS4KKXUrwMeYsYf4LrC69lh17ssph/ouCDOkxrea0LMQp5Bauv5 5AkQhqd20Af2b11j5KlJWMzOUax2zgjo/IoWdVbkyzkbK9iD+E2BUfSqD7PqeY100496 QQvavZ3RnYav+1fE1YR2TWVgIcdHSJoSVAU/w4rq+fNrmE/BnRdIRbZSeFUvNNn0wJEQ q1qEjEMJLKiA6ywL3TmaIBt/77EH4PcHUXc+XevDWp0MVXB6t9YUj8ybCmytEIDWMZ3E 6z+g== Received: by 10.68.241.99 with SMTP id wh3mr6954216pbc.16.1345746909064; Thu, 23 Aug 2012 11:35:09 -0700 (PDT) Received: from [192.168.255.58] ([12.207.18.42]) by mx.google.com with ESMTPS id vx5sm5478449pbc.43.2012.08.23.11.35.07 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Aug 2012 11:35:08 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_D1B68DFF-88D5-49B9-BB29-060BC7A765B2" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Sam Aldrin In-Reply-To: Date: Thu, 23 Aug 2012 11:34:32 -0700 Message-Id: <95E6D1FF-9E5A-46E6-B32B-90CA825A571F@gmail.com> References: To: "Dutta, Pranjal K (Pranjal)" X-Mailer: Apple Mail (2.1486) Cc: "mpls@ietf.org" Subject: Re: [mpls] Question on LDP Multi-topology draft 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, 23 Aug 2012 18:35:12 -0000 --Apple-Mail=_D1B68DFF-88D5-49B9-BB29-060BC7A765B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Pranjal, I do not think one could use the existing FEC types identified in = RFC4379. There should be new FEC types in order to perform OAM = functions. Authors should add relevant section identifying the same.=20 With many extensions (FEC types) being added via different drafts, in = order to support OAM via RFC4379, not sure it is a good idea to create = a lap ping draft whenever new type is added. Again, I do not know if = there is a better option than having a new draft for each extension. = Thoughts? -sam On Aug 23, 2012, at 11:07 AM, "Dutta, Pranjal K (Pranjal)" = wrote: > Hi Authors, > I apologize if this is already discussed; I have = a few questions on the latest version of LDP MT draft > (http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-04). > =20 > The draft introduces two new address families =96 = MT IP and MT IPV6. This fits well into existing Prefix > and mLdp FEC element types since the respective FEC elements has the = Address Family field. > =20 > Could you please clarify how OAM tool sets (LSP = Ping etc) are going to work for LDP-MT based prefix > FECs? > =20 > Following are encodings of LDP IPV4/V6 Targeted FEC sub-types as per = RFC 4379. > =20 > Sub-Type Length Value Field > -------- ------ ----------- > 1 5 LDP IPv4 prefix > 2 17 LDP IPv6 prefix > =20 > Sub-type 1 =3D LDP IPV4 FEC > =20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPv4 prefix = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Prefix Length | Must Be Zero = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =20 > Sub-type 2 =3D LDP IPV6 FEC > =20 > 0 1 2 = 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPv6 prefix = | > | (16 octets) = | > | = | > | = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Prefix Length | Must Be Zero = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =20 > I don=92t see how existing Targeted FEC stack types would work for = LDP-MT based Prefix FEC elements since it=92s the > Targeted FEC sub-types that seem to hardcode the address family. > =20 > The Multicast LDP FEC Stacks TLV (RFC 6425) bear Address Family field = for Root address, so the LDP-MT extensions > would get aligned. > =20 > IMO, a section in the draft referring to OAM extensions (if required = or not required) would help. > I think the following refers to section 9, as opposed to section 10. >=20 > 3.4. IGP MT-ID Mapping and Translation >=20 > =20 > The non-reserved non-special IGP MT-ID values can be used/carried = in > LDP as-is and need no translation. However, there is a need for > translating reserved/special IGP MT-ID values to corresponding LDP > MT-IDs. The corresponding special/reserved LDP MT-ID values are > defined in later section 10. > =20 > =20 > Thanks, > Pranjal > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail=_D1B68DFF-88D5-49B9-BB29-060BC7A765B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 pranjal.dutta@alcatel-luc= ent.com> wrote:

=

Hi Authors,

         &= nbsp;           I apologize if this is already discussed; I have a few questions on the = latest version of LDP = MT draft =

(= http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-04).

 

         &= nbsp;          The draft introduces  two new address families =96 MT IP and MT = IPV6. This fits well into existing Prefix

and mLdp FEC element types since the respective FEC = elements has the Address Family field.

 

         &= nbsp;           Could you please clarify how OAM tool sets (LSP Ping etc) are going to = work for LDP-MT based prefix

FECs?

 

Following are encodings of LDP IPV4/V6 Targeted FEC = sub-types as per RFC 4379.

 

       =
Sub-Type      =
  Length         &n=
bsp;  Value Field
      =
--------       =
   ------        &n=
bsp;  -----------
        =
;     =
1            =
5            LDP =
IPv4 prefix
        =
;     =
2           =
17            LDP =
IPv6 prefix
 
Sub-type=
 1 =3D LDP IPV4 FEC
 
       =
0            &=
nbsp;      =
1            &=
nbsp;      =
2            &=
nbsp;      =
3
       =
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 =
1
      =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      =
|            &=
nbsp;           &nb=
sp; IPv4 prefix        =
            &n=
bsp;     |
      =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Prefix Length =
|         Must Be =
Zero           &nbs=
p;            =
  |
      =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

Sub-type 2 =3D LDP IPV6 = FEC

 

     =
      0        =
;           =
1            &=
nbsp;      =
2            =
       3
= 
       0 1 2 3 4 =
5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 =
1
      =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      =
|            &=
nbsp;           &nb=
sp; IPv6 =
prefix           &n=
bsp;           &nbs=
p;  |
      =
|            &=
nbsp;            =
 (16 =
octets)           &=
nbsp;           &nb=
sp;  |
      =
|            &=
nbsp;           &nb=
sp;            =
;            &=
nbsp;           &nb=
sp; |
      =
|            &=
nbsp;           &nb=
sp;            =
;            &=
nbsp;           &nb=
sp; |
      =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Prefix Length =
|         Must Be =
Zero           &nbs=
p;            =
  |
      =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 

I don=92t see how existing Targeted FEC stack types would work for LDP-MT based Prefix FEC elements since it=92s the =

Targeted FEC  sub-types that seem to hardcode = the address family.

 

The Multicast LDP FEC Stacks TLV (RFC 6425) bear = Address Family field for Root address, so the LDP-MT extensions

would get aligned.

 

IMO, a section in the draft referring to OAM = extensions (if required or not required) would help.

I think the following refers to section 9, as = opposed to section 10.

3.4.  IGP MT-ID Mapping and Translation

 
   The non-reserved non-special IGP =
MT-ID values can be used/carried =
in
   LDP as-is and need no =
translation.  However, there is a need =
for
   translating =
reserved/special IGP MT-ID values to corresponding =
LDP
   MT-IDs.  The =
corresponding special/reserved LDP MT-ID values =
are
   defined in later section 10.

 

 

Thanks,

Pranjal

_______________________________________________
mpls mailing = list
mpls@ietf.org
https://www.ietf.org/ma= ilman/listinfo/mpls
=

= --Apple-Mail=_D1B68DFF-88D5-49B9-BB29-060BC7A765B2-- From pranjal.dutta@alcatel-lucent.com Thu Aug 23 11:37: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 F389621F84DA for ; Thu, 23 Aug 2012 11:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.401 X-Spam-Level: X-Spam-Status: No, score=-9.401 tagged_above=-999 required=5 tests=[AWL=1.197, 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 waBaoAVc+v9l for ; Thu, 23 Aug 2012 11:37:54 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE3021F84C4 for ; Thu, 23 Aug 2012 11:37:53 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q7NIbnMZ004462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 Aug 2012 13:37:51 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7NIbmTO015908 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 24 Aug 2012 00:07:48 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Fri, 24 Aug 2012 00:07:48 +0530 From: "Dutta, Pranjal K (Pranjal)" To: "Kamran Raza (skraza)" , "mpls@ietf.org" Date: Fri, 24 Aug 2012 00:07:47 +0530 Thread-Topic: [mpls] Question on LDP Multi-topology draft Thread-Index: Ac2BWjIZ0Xx3abQuRdipLNIkkDKwXAADBJsAAAH8/gA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C584046466ED224CA92C1BC3313B963E09F2382B11INBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [mpls] Question on LDP Multi-topology draft 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, 23 Aug 2012 18:37:57 -0000 --_000_C584046466ED224CA92C1BC3313B963E09F2382B11INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kamran, Thanks for the info. Thanks, Pranjal ________________________________ From: Kamran Raza (skraza) [mailto:skraza@cisco.com] Sent: Thursday, August 23, 2012 11:33 AM To: Dutta, Pranjal K (Pranjal); mpls@ietf.org Subject: Re: [mpls] Question on LDP Multi-topology draft Hi Pranjal, I agree with your comment on adding a section / behavior for MPLS OAM exten= sions to support MT for Prefix FEC types. We will discuss amongst us (author) and update accordingly. Rgds, --Kamran From: , "Pranjal K (Pranjal)" > Date: Thursday, August 23, 2012 2:07 PM To: "mpls@ietf.org" > Subject: [mpls] Question on LDP Multi-topology draft Hi Authors, I apologize if this is already discussed; I have a few= questions on the latest version of LDP MT draft (http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-04). The draft introduces two new address families - MT IP = and MT IPV6. This fits well into existing Prefix and mLdp FEC element types since the respective FEC elements has the Addres= s Family field. Could you please clarify how OAM tool sets (LSP Ping e= tc) are going to work for LDP-MT based prefix FECs? Following are encodings of LDP IPV4/V6 Targeted FEC sub-types as per RFC 43= 79. Sub-Type Length Value Field -------- ------ ----------- 1 5 LDP IPv4 prefix 2 17 LDP IPv6 prefix Sub-type 1 =3D LDP IPV4 FEC 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-type 2 =3D LDP IPV6 FEC 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 prefix | | (16 octets) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I don't see how existing Targeted FEC stack types would work for LDP-MT bas= ed Prefix FEC elements since it's the Targeted FEC sub-types that seem to hardcode the address family. The Multicast LDP FEC Stacks TLV (RFC 6425) bear Address Family field for R= oot address, so the LDP-MT extensions would get aligned. IMO, a section in the draft referring to OAM extensions (if required or not= required) would help. I think the following refers to section 9, as opposed to section 10. 3.4. IGP MT-ID Mapping and Translation The non-reserved non-special IGP MT-ID values can be used/carried in LDP as-is and need no translation. However, there is a need for translating reserved/special IGP MT-ID values to corresponding LDP MT-IDs. The corresponding special/reserved LDP MT-ID values are defined in later section 10. Thanks, Pranjal --_000_C584046466ED224CA92C1BC3313B963E09F2382B11INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kamran,

      &n= bsp;            = ; Thanks for the info.

Thanks,

Pranjal

 

From: Kamran R= aza (skraza) [mailto:skraza@cisco.com]
Sent: Thursday, August 23, 2= 012 11:33 AM
To: Dutta, Pranjal K (Pranja= l); mpls@ietf.org
Subject: Re: [mpls] Question= on LDP Multi-topology draft

 

Hi Pranjal,<= /o:p>

 =

I agree with your comment on adding a section / behavior for MPLS OAM extensions to support M= T for Prefix FEC types.

We will discuss a= mongst us (author) and update accordingly.

 =

Rgds,<= /span>

--Kamran

 =

From: <Dutta>, "Pranjal K (Pranjal)" <pranjal.dutta@alcatel-luce= nt.com>
Date: Thursday, August 23, 2= 012 2:07 PM
To: "mpls@ietf.org" <mpls@ietf.org>
Subject: [mpls] Question on = LDP Multi-topology draft

 =

Hi Authors,

      &= nbsp;           &nbs= p;  I apologize if this is already discussed; I have a few questions on the lat= est version of LDP MT draft

(h= ttp://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-04).=

 

      &= nbsp;           &nbs= p; The draft introduces  two new address families – MT IP and MT IP= V6. This fits well into existing Prefix

and mLdp FEC element types since the respective FEC elements has the Address Family field.

 

      &= nbsp;           &nbs= p;  Could you please clarify how OAM tool sets (LSP Ping etc) are going to work= for LDP-MT based prefix

FECs?

 

Following are encodings of LDP IPV4/V= 6 Targeted FEC sub-types as per RFC 4379.

 

       Sub-Type   =
;     Length       &=
nbsp;    Value Field
      --------   &nbs=
p;      ------      =
     -----------<=
/pre>
          &=
nbsp;  1          &n=
bsp; 5            LD=
P IPv4 prefix
          &=
nbsp;  2           1=
7            LDP IPv=
6 prefix
 
Sub-type 1 =3D LDP IPV4 FEC
 
       0    =
            &nb=
sp;  1          &nbs=
p;        2     =
;            &n=
bsp; 3
       0 1 2 3 4 5 6 7 8 9 0 1 2=
 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     =             &nb= sp;        IPv4 prefix   =              &n= bsp;         |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      | Prefix Length |  &n= bsp;      Must Be Zero    &nbs= p;            &= nbsp;        |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

Sub-type 2= =3D LDP IPV6 FEC

 

       &n=
bsp;   0 &=
nbsp;           &nbs=
p;     1        =
;           2  =
             &n=
bsp;   3
       0 1 2 3 4 5 6 7 8 9 0 1 2= 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      |     =             &nb= sp;        IPv6 prefix   =             &nb= sp;          |      |     =             &nb= sp;        (16 octets)   =             &nb= sp;          |      |     =             &nb= sp;            =             &nb= sp;            =         |      |     =             &nb= sp;            =             &nb= sp;            =         |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      | Prefix Length |  &n= bsp;      Must Be Zero    &nbs= p;            &= nbsp;        |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

I don’t see how existing Target= ed FEC stack types would work for LDP-MT based Prefix FEC elements since it’s the =

Targeted FEC  sub-types that see= m to hardcode the address family.

 

The Multicast LDP FEC Stacks TLV (RFC 6425) bear Address Family field for Root address, so the LDP-MT extensions<= /span>

would get aligned.

 

IMO, a section in the draft referring= to OAM extensions (if required or not required) would help.

I think the following ref= ers to section 9, as opposed to section 10.

3.4.  IGP MT-ID Mapping and Translation<= /u1:p>

 
   The non-reserved non-special IGP MT-ID values can be used/=
carried in
   LDP as-is and need no translation.  However,= there is a need for   translating reserved/special IGP MT-ID values to = corresponding LDP   MT-IDs.  The corresponding special/reserved = LDP MT-ID values are   defined in later section 10.

 

 

Thanks,

Pranjal

--_000_C584046466ED224CA92C1BC3313B963E09F2382B11INBANSXCHMBSA_-- From pranjal.dutta@alcatel-lucent.com Thu Aug 23 11:45: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 C92DC21F8489 for ; Thu, 23 Aug 2012 11:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.449 X-Spam-Level: X-Spam-Status: No, score=-9.449 tagged_above=-999 required=5 tests=[AWL=1.149, 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 3CR6jVkYt1RH for ; Thu, 23 Aug 2012 11:45:18 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id E9EDD21F8578 for ; Thu, 23 Aug 2012 11:45:17 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q7NIjBII016049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 Aug 2012 13:45:14 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7NIjAho016078 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 24 Aug 2012 00:15:10 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Fri, 24 Aug 2012 00:15:10 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Sam Aldrin Date: Fri, 24 Aug 2012 00:15:09 +0530 Thread-Topic: [mpls] Question on LDP Multi-topology draft Thread-Index: Ac2BXgkOXqTsea9XR3awp0hox9h/pAAAF2cQ Message-ID: References: <95E6D1FF-9E5A-46E6-B32B-90CA825A571F@gmail.com> In-Reply-To: <95E6D1FF-9E5A-46E6-B32B-90CA825A571F@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C584046466ED224CA92C1BC3313B963E09F2382B16INBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "mpls@ietf.org" Subject: Re: [mpls] Question on LDP Multi-topology draft 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, 23 Aug 2012 18:45:20 -0000 --_000_C584046466ED224CA92C1BC3313B963E09F2382B16INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sam, Yes, existing types can't be used for LDP-MT. It requires ne= w types. I agree with you - probably it is fragile to keep adding new types= to RFC 4379 but at the same I don't see a cleaner seamless solution that would= maintain backward compatibility with RFC 4379. Perhaps creating a generic Target FEC stack for LDP that would embed any LDP FEC element types= may be extendable solution, but need to explore pros and cons on such approaches from LspPing/Trace point if view. Thanks, Pranjal ________________________________ From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] Sent: Thursday, August 23, 2012 11:35 AM To: Dutta, Pranjal K (Pranjal) Cc: mpls@ietf.org Subject: Re: [mpls] Question on LDP Multi-topology draft Pranjal, I do not think one could use the existing FEC types identified in RFC4379. = There should be new FEC types in order to perform OAM functions. Authors sh= ould add relevant section identifying the same. With many extensions (FEC types) being added via different drafts, in order= to support OAM via RFC4379, not sure it is a good idea to create a lap pi= ng draft whenever new type is added. Again, I do not know if there is a bet= ter option than having a new draft for each extension. Thoughts? -sam On Aug 23, 2012, at 11:07 AM, "Dutta, Pranjal K (Pranjal)" > wrote: Hi Authors, I apologize if this is already discussed; I have a few= questions on the latest version of LDP MT draft (http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-04). The draft introduces two new address families - MT IP = and MT IPV6. This fits well into existing Prefix and mLdp FEC element types since the respective FEC elements has the Addres= s Family field. Could you please clarify how OAM tool sets (LSP Ping e= tc) are going to work for LDP-MT based prefix FECs? Following are encodings of LDP IPV4/V6 Targeted FEC sub-types as per RFC 43= 79. Sub-Type Length Value Field -------- ------ ----------- 1 5 LDP IPv4 prefix 2 17 LDP IPv6 prefix Sub-type 1 =3D LDP IPV4 FEC 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-type 2 =3D LDP IPV6 FEC 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 prefix | | (16 octets) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I don't see how existing Targeted FEC stack types would work for LDP-MT bas= ed Prefix FEC elements since it's the Targeted FEC sub-types that seem to hardcode the address family. The Multicast LDP FEC Stacks TLV (RFC 6425) bear Address Family field for R= oot address, so the LDP-MT extensions would get aligned. IMO, a section in the draft referring to OAM extensions (if required or not= required) would help. I think the following refers to section 9, as opposed to section 10. 3.4. IGP MT-ID Mapping and Translation The non-reserved non-special IGP MT-ID values can be used/carried in LDP as-is and need no translation. However, there is a need for translating reserved/special IGP MT-ID values to corresponding LDP MT-IDs. The corresponding special/reserved LDP MT-ID values are defined in later section 10. Thanks, Pranjal _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_C584046466ED224CA92C1BC3313B963E09F2382B16INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sam,

      &n= bsp;        Yes, existing types can’t be used for LDP-MT. It requires new types. = I agree with you – probably it is fragile to keep adding new types to <= o:p>

RFC 4379 but at the same I don’t= see a cleaner seamless solution that would maintain backward compatibility with= RFC 4379. Perhaps creating a

generic Target FEC stack for LDP that would embed any LDP FEC element types may be extendable solution, but need = to explore pros and cons

on such approaches from LspPing/Trace point if view.

 

Thanks,

Pranjal

 

From: Sam Aldr= in [mailto:aldrin.ietf@gmail.com]
Sent: Thursday, August 23, 2= 012 11:35 AM
To: Dutta, Pranjal K (Pranja= l)
Cc: mpls@ietf.org
Subject: Re: [mpls] Question= on LDP Multi-topology draft

 

Pranjal,

 

I do not think one could use the existing FEC types identified in RFC4379. There should be new FEC types in order to perform OAM functions. Authors should add relevant section identifying the same. <= /span>

 

With many extensions (FEC types) being added via different drafts, = in order to support OAM via RFC4379,  not sure it is a good idea to creat= e a lap ping draft whenever new type is added. Again, I do not know if there is= a better option than having a new draft for each extension. Thoughts?

 

-sam

On Aug 23, 2012, at 11:07 AM, "Dutta, Pranjal K (Pranjal)"= ; <pranjal.dutta@alcat= el-lucent.com> wrote:



Hi Authors,

         &n= bsp;           I apologize if this is already discussed; I have a few questions on the lat= est version of LDP MT draft

(h= ttp://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-04).=

 

         &n= bsp;          The draft introduces  two new address families – MT IP and MT IP= V6. This fits well into existing Prefix <= /p>

and mLdp FEC element types since the respective FEC elem= ents has the Address Family field.

 

         &n= bsp;           Could you please clarify how OAM tool sets (LSP Ping etc) are going to work= for LDP-MT based prefix

FECs?

 

Following are encodings of LDP IPV4/V6 Targeted FEC sub-types as per RFC 4379.

 

&=
nbsp;      Sub-Type      =
  Length         &nb=
sp;  Value Field
  =
    --------         =
; ------           -=
----------
  =
           1  &=
nbsp;         5   &n=
bsp;        LDP IPv4 prefix=

  =
           2  &=
nbsp;        17    &=
nbsp;       LDP IPv6 prefix=

 =

Sub-type 1 =
=3D LDP IPV4 FEC
 =

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

  &=
nbsp;    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5=
 6 7 8 9 0 1
  &=
nbsp;   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+
  &=
nbsp;   |         &n=
bsp;            =
;    IPv4 prefix        &=
nbsp;           &nbs=
p;     |
  &=
nbsp;   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+
  &=
nbsp;   | Prefix Length |      &nbs=
p;  Must Be Zero         =
            &nb=
sp;    |
  &=
nbsp;   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+



 



Sub-type 2 =3D LDP IPV6 FEC<=
/font>



 



           0     &nb=
sp;            =
 1            &=
nbsp;      2      &n=
bsp;            3
  &=
nbsp;    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5=
 6 7 8 9 0 1
  &=
nbsp;   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+
  &=
nbsp;   |         &n=
bsp;            =
;    IPv6 prefix       &n=
bsp;            =
;      |
  &=
nbsp;   |         &n=
bsp;            =
;    (16 octets)       &n=
bsp;            =
;      |
  &=
nbsp;   |         &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;   |
  &=
nbsp;   |         &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;   |
  &=
nbsp;   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+
  &=
nbsp;   | Prefix Length |      &nbs=
p;  Must Be Zero         =
            &nb=
sp;    |
  &=
nbsp;   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+
 <=
/u1:p>



I don’t see how existing Targeted FEC stack types
would work for LDP-MT based Prefix FEC elements since it’s the =




Targeted FEC  sub-types that seem to hardcode the
address family. 



 



The Multicast LDP FEC Stacks TLV (RFC 6425) bear Address
Family field for Root address, so the LDP-MT extensions 





would get aligned.=




 



IMO, a section in the draft referring to OAM extensions =
(if
required or not required) would help.=




I think the following refers to section 9, as opposed t=
o
section 10.



3.4. 
IGP MT-ID Mapping and Translation


 
   =
The non-reserved non-special IGP MT-ID values can be used/carried in<=
/u1:p>
   =
LDP as-is and need no translation.  However, there is a need for=

   =
translating reserved/special IGP MT-ID values to corresponding LDP
   =
MT-IDs.  The corresponding special/reserved LDP MT-ID values are=

   =
defined in later section 10.



 



 



Thanks,



Pranjal

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

 

--_000_C584046466ED224CA92C1BC3313B963E09F2382B16INBANSXCHMBSA_-- From eosborne@cisco.com Thu Aug 23 13: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 983E421F86A7 for ; Thu, 23 Aug 2012 13:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.969 X-Spam-Level: X-Spam-Status: No, score=-9.969 tagged_above=-999 required=5 tests=[AWL=-0.470, BAYES_00=-2.599, GB_ABOUTYOU=0.5, J_CHICKENPOX_44=0.6, 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 aHGPyPZJmA0H for ; Thu, 23 Aug 2012 13:06:40 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id F030221F8685 for ; Thu, 23 Aug 2012 13:06:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9926; q=dns/txt; s=iport; t=1345752400; x=1346962000; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MI33PSgXn99ldaAv6yJ6cBE3XyIUCGBQ+hby/Stt48I=; b=ODFJWknWgFkMRJOt6LKuTBQ7JQTZLvuOEKXVlqdyMDLwpkNG5HlLYNtJ DwrJx8PqAArk9a9/g2UibOXL+Bl/3lPdOoWAIFmAcc1WwZmbUP2t41f+k zzIK6Fo7xDsNlOUYVO9FwFwXVrU3yo3KW2tsHnYSSnPg/0S9DtVGLtdqf Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABuMNlCtJV2c/2dsb2JhbABFuk+BB4IgAQEBAwEBAQELBAEUEysJCwULAgEIDhQUECcLJQEBBA4FCBMHh2UGC5lXoEMEix2GHGADpAGBZ4JjgVk X-IronPort-AV: E=Sophos;i="4.80,301,1344211200"; d="scan'208";a="111683392" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 23 Aug 2012 20:06:39 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q7NK6d6m012582 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Aug 2012 20:06:39 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0298.004; Thu, 23 Aug 2012 15:06:38 -0500 From: "Eric Osborne (eosborne)" To: Yaacov Weingarten Thread-Topic: [mpls] Comments on draft-ietf-mpls-tp-ring-protection Thread-Index: Ac2Am22fhY+HY5maSCeDdFLvV1CsxwAhJ6+AABEitcA= Date: Thu, 23 Aug 2012 20:06:38 +0000 Message-ID: <20ECF67871905846A80F77F8F4A275720F54DAB3@xmb-rcd-x09.cisco.com> References: <20ECF67871905846A80F77F8F4A275720F54C73E@xmb-rcd-x09.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.98.23.92] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19134.001 x-tm-as-result: No--53.064400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" Subject: Re: [mpls] Comments on draft-ietf-mpls-tp-ring-protection 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, 23 Aug 2012 20:06:41 -0000 Hi Yaacov- Inline with EO#. ... > One comment on link vs node protection. There are few places, e.g. > section 2.4, which say that providing both link and node protection are > difficult. I do not believe this to be true. I am familiar with two > implementations that are easily able to do this today. The algorithm is > simple; if the thing you're protecting ends on the next-hop, use link > protection. Otherwise use node. I agree that with a statically configur= ed > network it becomes the responsibility of the NMS to make sure this is don= e > right, but it's a simple thing to do. >=20 >=20 > yw>> Yes, you are correct and previous versions of the draft actually inc= luded > such a solution. However, there were many comments from different > members that when we use such a scheme that the traffic is no longer usin= g > the same path in both directions and the protection path is "non- > deterministic" which is bothersome to many transport service providers.=20 EO# I either don't get it or don't agree. In a ring, you can go CW or CCW= . If the normal traffic goes CW, both the link and node protection tunnels= must follow the CCW path. There is only one way to go; that's what people= seem to like about rings. How is taking the exact same path non-determini= stic? > We > found that trying to address these comments complicated issues and > therefore we suggest that the SP decide a-priori for each working path > whether they want to apply link or node protection. EO# Depending on how you set up the "node protection" LSP, you may or may = not find that link protection is mandatory. Consider a 5-node ring, A-B-C-D-E-A. =20 If B protects against the failure of link BC, it will have a protect LSP of= B-A-E-D-C. If B protects against the failure of node C, it will have a protect LSP of = B-A-E-D. This works just fine if there are no LSPs which cross link BC and which egr= ess the ring at C. =20 But if there's an LSP A-B-C which egresses the ring at C, B *cannot* use th= e node protection tunnel for traffic which egresses at C.=20 It gets hairier with p2mp. Consider the same ring, with two p2mp LSPs, A-B-[C]-[D]-E and A-B-[C]-[D]-[= E]. With traditional node protection (that is, a p2p tunnel which delivers traf= fic to the NNHOP which then merges and continues downstream), B's LSP prote= cting against the failure of C would be B-A-E-D. This, too, leaves you unp= rotected if link BC fails but C is reachable via D. You could build both a link and a node protection tunnel, i.e. B-A-E-D-C a= nd B-A-E-D. One might instead be tempted to optimize and protect against both link and = node with a single tunnel, e.g. B-A-E-[D]-[C]. This gets trickier, though,= since C needs to see a different label in this case than it would have rec= eived were it still directly connected to B. It's not intractable, but if = some people's heads explode in the presence of both link and node protectio= n I'm not sure they'll be able to handle this optimization. >=20 >=20 > Also, it looks like the draft makes two assumptions, which I've spelled > out below. Can you confirm or deny? >=20 > i) > It looks like your protection mechanisms all assume that when traffic > enters the ring, it either goes CW or CCW. In other words, take your Fig= ure 6. > The protected LSP is A->B->[C]->[D]->E->[F]. This implies that you do no= t > allow mcast traffic to enter at A and branch both right and left. In oth= er > words, the following p2mp is not allowed: >=20 > A > ->[F]->E->[D] > ->E-[C] >=20 > Is that correct? >=20 >=20 > yw>> not 100% correct. There is a general transport industry assumption > that all working traffic will (most probably for historical, i.e. SDH, re= asons) > always traverse a ring in only one direction, however, you should note th= at > the protection that is described in section 3.2 of the document actually = could > split the traffic to go in both directions for p2mp traffic. In addition= , see my > comment to your next comment. >=20 EO# OK, so I'm assuming the p2mp LSP I've described above is legal. It ce= rtainly would be if we had an arbitrary IP/MPLS topology. >=20 >=20 >=20 > ii) > Does the draft assume that I can have a W LSP in two directions? For > a four-node ring A-B-C-D-A, can I have both W:A-B-C and W:A-D-C? This > won't apply in all cases but it may be desirable to load-balance traffic = in both > directions across the ring. This has implications on the wrapping protec= tion > methods. >=20 >=20 > yw> Yes, the draft assumes protection per LSP that traverses the ring, > therefore you could setup protection for two LSPs one that goes A-B-C and > additional protection for the working LSP that traverses A-D-C >=20 EO# I think you answered my question, but I realized I phrased it poorly a= nd would like to rephrase. Rather than "a W LSP in two directions" I shoul= d have said "two W LSPs with the same ingress/egress pair, taking two diffe= rent directions". But it looks you figured out this is what I was asking, = and so you answered it. >=20 >=20 > I'd also like to very much see a scale analysis of the five protection > mechanisms discussed in the draft. I started work on one but realized I > needed to clear up my questions about your assumptions. I think the p2mp > mechanisms may have serious scale challenges, but I want to make sure I g= et > the assumptions right before discussing the scale. Once I understand the > assumptions better, I'll send out my thoughts on scale. >=20 EO# As promised, here's my stab at scale for the five methods. p2p wrapping: this is just FRR. The draft claims that the scale of link+no= de is 2N, but I think that's incorrect. It seems to only consider traffic = in one direction. It's true that if all my traffic flows CW that I only ne= ed protection tunnels to flow CCW. This is where you get 2N for link+node.= But if I have primary traffic which flows both CW and CCW, you now need 2= N for *each* of link and node protection. In other words, to protect again= st the failure of link BC, node B needs a B->C protection LSP and node C ne= eds a C->B protection LSP. p2p steering: You need a protect SPME for each node pair on the ring. So t= he upper limit on the number of protect LSPs is N^2. p2mp Wrapping: just like p2p wrapping; in effect, wrapping is ignorant of t= he type of traffic that it is protecting. Note that this precludes the ide= a of a combination link+node protection LSP, as that would be multicast-spe= cific. p2mp ROM-Wrapping: If I've understood it properly, I think this scales very= poorly. This is because the ROM-Wrapping protection LSP mirrors the tree = which it protects, and thus things scale by a combination of the number of = protected p2mp LSPs and the number of nodes on the ring. Consider the ring= A-B-C-D-E-A. There is one mcast tree on this ring: A-B-[C]-[D]-E. To pro= tect against the failure of link BC, node B needs a ROM-Wrapping LSP B-A-E-= [D]-[C]. Similarly, nodes A, C, D and E all need a ROM-Wrapping LSP whic= h mirrors the protected tree A-B-[C]-[D]-E but in the reverse direction, in= order to protect against the failure of their outgoing link/next-hop node. Add one more mcast tree to the ring: A-B-[C]-D-[E]. To protect this tree a= gainst the failure of link BC, node B needs another ROM-Wrapping LSP: B-A-[= E]-D-[C]. And as above, every other node needs one of these as well. I th= ink this may be what you meant by " ROM-Wrapping is an LSP based protection= mechanism, as opposed to the SPME based protection mechanisms". But I thi= nk that sentence glosses over the scale limitations here. The number of po= ssible mcast trees in a ring is huge. If you assume mcast traffic can only= go CW, you have N*[2^(n-1)] possible mcast trees which may need protection= . Allowing split mcast trees (e.g. A: ->[F]->E->[D] and A->E-[C] as in my= earlier question) only makes this worse. I'm tempted to say it increases = the potential number of primary mcast trees by something like (N-1)!, which= gets pretty big pretty quickly. For each of these primary LSPs, you need a protection LSP with the reverse = topology on every node. I believe this would be a serious concern for any = service provider of any real scale. A 16-node ring (the traditional ITU ma= ximum but by no means impossible in an IP/MPLS network) could have in exces= s of a half-million protection LSPs on it. A 17-node ring would require mor= e LSPs than are possible with today's technology. Again, this is the maximum number of LSPs, and not everyone deploys the max= imum, but I believe it is imperative that operators clearly understand the = cost of an approach like this before deploying it. And I have to ask - is = the cost of ROM-Wrapping worth the benefit? p2mp steering: I'm not clear why the draft requires that this be 1+1. I th= ink it would be cleaner to allow either 1+1 or 1:1, as the operator desires= , regardless of protection type. =20 I think the scale here is OK, but it depends very much on exactly how you a= pply context labels. If you have only two contexts - CW and CCW - then you= should be OK. But if you allow split LSPs as described earlier, you need = far more sophistication. It seems like you either need a context label per= possible tree or you need a lot more knowledge in the context table at eac= h hop. Can you explain how p2mp steering would work in the presence of spl= it p2mp LSPs? thanks! eric > thanks! >=20 >=20 >=20 >=20 >=20 > eric > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 From david.i.allan@ericsson.com Thu Aug 23 14:52: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 2593421F860E for ; Thu, 23 Aug 2012 14:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[AWL=0.497, 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 15hs-gPvWHc5 for ; Thu, 23 Aug 2012 14:52:24 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 96C6021F85C0 for ; Thu, 23 Aug 2012 14:52:24 -0700 (PDT) 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 q7NLrZYn018792; Thu, 23 Aug 2012 16:53:40 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.2.164]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 23 Aug 2012 17:52:11 -0400 From: David Allan I To: Alexander Vainshtein , "swallow@cisco.com" , "John E Drake (jdrake@juniper.net)" Date: Thu, 23 Aug 2012 17:52:12 -0400 Thread-Topic: A question regarding RFC 6428 Thread-Index: Ac2BNZvbMCmkHjiATrqyQfEmO1rwEAAP9o7Q Message-ID: <60C093A41B5E45409A19D42CF7786DFD5CFCBF4D63@EUSAACMS0703.eamcs.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_60C093A41B5E45409A19D42CF7786DFD5CFCBF4D63EUSAACMS0703e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "robrennison@gmail.com" , Mishael Wexler Subject: Re: [mpls] A question regarding RFC 6428 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, 23 Aug 2012 21:52:28 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD5CFCBF4D63EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI Sasha: I have serious doubts regarding one of the modifications to the BFD FSM tha= t has been introduced in RFC 6428. The BFD FSM diagram (Figure 7) for coordinated BFD operation in Section 3.7= .5 "State Machines" indicates that the BFD session transits from UP to DOWN= upon receiving an LDI (and, optionally, LKR) message. We simply have two more protocol inputs into the state machine as MPLS-TP i= ntroduced the ability for intermediate nodes to introduce transactions of O= AM significance into an LSP. Could you please explain the rationale for such a change in the BFD state m= achine vs. what has been as described in RFC 5880? (The text in 6428 explains that the state machine is modified in order to s= upport mis-connectivity defect, but I do not see how this is related to LDI= ). Hmm I read it exactly backwards, the introductury texts to section 3.7.5 sh= ould have mentioned mis-connectivity as well as LDI/LDR instead of just LKR= . This change is introduced in addition to a requirement from Section 3.7.2 t= hat receiving Link Down Indication (be it a local link failure or an MPLS-T= P LDI message) results in entering a (presumably, Loss of Continuity) MEP d= efect state. Further, section 3.7.2 states that "receiving nothing" (i.e., = expiration of the BFD session timer) has higher priority that reception of = LDI. My reading of these results in the following: 1. If LDI is received after the session timer expiration it is ignore= d. Correct, that could happen if the CC rate was such that losing 3 occurred f= aster than the local criteria for issuing LDI. However that was not the use= case LDI was invented for. 2. If LDI is received before the session timer expiration, the sessio= n first goes down and sends back RDI with the Path Down diagnostic code. It= is not clear whether the BFD session timer expiration results in changing = the diagnostic code to "Control Detection Timer Expired" or not . What diagnostic code to use for an LDI could be clarified. 3. In the situation when BFD session timer does not expire while LDI = state remains active (e.g., because the LSP uses FRR or segment protection = to bypass the failed link), the session would cycle thru DOWN->INIT-->UP-->= DOWN - session flapping/churn. Agreed, once you have multiple mechanisms involved, they do have the possib= ility of disagreeing. But you would not want to use FRR and LDI together. O= f course, that does not mean that someone won't do it. 4. It is not clear what is supposed to happen if the BFD session went= DOWN because an LDI message has been received and then LDI state has been = cleared (e.g., using the fast clearance mechanism defined in Section 5.2 of= RFC 6427) befor= e the session timer has expired. If you get an LDI you would transition to DOWN, you would then have to go t= hrough INIT etc. so I'm not sure there is an issue here. It came first, so = I think the timers are rendered irrelevant by the session re-starting. To make my position clear, I do not see any issues with adding LDI as a tri= gger for sending the MEP to its DOWN state. I simply do not understand why = this requires modification of the BFD State machine. How does the MEP get to a down state using LDI as a trigger without LDI as = an input to the state machine?... this kinda sounds like the "via several m= iracles" picture ;-) It is simply a remote version of a local LOF/LOL indic= ation. At best this would speed up generation of RDI towards the remote MEP, but = the price does not seem to justify the effort. Note that RDI is not used a= s a trigger for protection actions; if bidirectional LSP protection is requ= ired, this is achieved via the PSC - e.g., as defined in RFC 6378. It would also enhance the accuracy of PM associated with availability as ev= en with a slow CC rate, the LSP would enter the unavailable state faster. B= ut more fundamentally, my take of figure 1 in 6378 is that CC/RDI are OAM i= ndications as inputs into PSC, else why are we bothering. CC/RDI is a trigg= er for protection actions. I hope this helps Dave This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. --_000_60C093A41B5E45409A19D42CF7786DFD5CFCBF4D63EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
HI=20 Sasha:

I have serious doubts regarding one of the modificatio= ns to=20 the BFD FSM that has been introduced in RFC=20 6428.

The BFD FSM diagram (Figure 7) for coordinated BFD ope= ration=20 in Section 3.7.5 “State Machines” indicates that the BFD= session transits=20 from UP to DOWN upon receiving an LDI (and, optionally, LKR) message. 

 

We simply have two more protocol inputs into the state machine= as=20 MPLS-TP introduced the ability for intermediate nodes to introduce transact= ions=20 of OAM significance into an LSP.

 

Could you please explain the rationale for such a chan= ge in=20 the BFD state machine vs. what has been as described in RFC=20 5880?

(The text in 6428 explains that the state machine is m= odified=20 in order to support mis-connectivity defect, but I do not see how this is=20 related to LDI). 

 

Hmm I read it exactly backwards, the introductury texts t= o=20 section 3.7.5 should have mentioned mis-connectivity as well as LDI/LD= R=20 instead of just LKR.  

 

This change is introduced in addition to a requirement= from=20 Section 3.7.2 that receiving Link Down Indication (be it a local link failu= re or=20 an MPLS-TP LDI message) results in entering a (presumably, Loss of Continui= ty)=20 MEP defect state. Further, section 3.7.2 states that “receiving nothi= ng” (i.e.,=20 expiration of the BFD session timer) has higher priority that reception of = LDI.=20 My reading of these results in the following:

1.      = =20 If LDI is received after the= =20 session timer expiration it is ignored. 

 

Correct, that could happen if the CC rate was such that losing= 3=20 occurred faster than the local criteria for issuing LDI. However that was n= ot=20 the use case LDI was invented for.

 

2.      = =20 If LDI is received before th= e=20 session timer expiration, the session first goes down and sends back RDI wi= th=20 the Path Down diagnostic code. It is not clear whether the BFD session time= r=20 expiration results in changing the diagnostic code to “Control Detect= ion Timer=20 Expired” or not .

What diagnostic code to use for an LDI could be clarified.=20

 

3.      = =20 In the situation when BFD se= ssion=20 timer does not expire while LDI state remains active (e.g., because the LSP= uses=20 FRR or segment protection to bypass the failed link), the session would cyc= le=20 thru DOWN->INIT-->UP--> DOWN – session flapping/churn. 

 

Agreed, once you have multiple mechanisms involved, they do ha= ve the=20 possibility of disagreeing. But you would not want to use FRR and LDI toget= her.=20 Of course, that does not mean that someone won't do it.

 

4.      = =20 It is not clear what is supp= osed to=20 happen if the BFD session went DOWN because an LDI message has been receive= d and=20 then LDI state has been cleared (e.g., using the fast clearance mechanism=20 defined in Section 5.2 of RFC 6427= )=20 before the session timer has expired.  

If you get an LDI you would transition to DOWN, you would= then=20 have to go through INIT etc. so I'm not sure there is an issue=20 here. It came first= , so I=20 think the timers are rendered irrelevant by the session=20 re-starting.

 

To make my position clear, I do not see any issues wit= h=20 adding LDI as a trigger for sending the MEP to its DOWN state. I simply do = not=20 understand why this requires modification of the BFD State machine.  

 

How does the MEP get to a down state using LDI as a trigger wi= thout=20 LDI as an input to the state machine?... this kinda sounds like the "via se= veral=20 miracles" picture ;-) It is simply a remote version of a local LOF/LOL=20 indication.

 

 At best = this=20 would speed up generation of RDI towards the remote MEP, but the price does= not=20 seem to justify the effort.  Note that RDI is not used as a trigger fo= r=20 protection actions; if bidirectional LSP protection is required, this is=20 achieved via the PSC – e.g., as defined in RFC 6378= .=20

 

It would also enhance the accuracy of PM associated w= ith=20 availability as even with a slow CC rate, the LSP would enter the unavailab= le=20 state faster. But more fundamentally, my take of figure 1 in 6378 is that C= C/RDI=20 are OAM indications as inputs into PSC, else why are we bothering= .=20 CC/RDI is a trigger for protection actions.

 

I hope this helps

Dave 

This e-mail message is intended for the recipient only and contains=20 information which is CONFIDENTIAL and which may be proprietary to ECI Telec= om.=20 If you have received this transmission in error, please inform us by e-mail= ,=20 phone or fax, and then delete the original and all copies thereof.=20

--_000_60C093A41B5E45409A19D42CF7786DFD5CFCBF4D63EUSAACMS0703e_-- From Alexander.Vainshtein@ecitele.com Thu Aug 23 22:02: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 D201B21F851C for ; Thu, 23 Aug 2012 22:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.201 X-Spam-Level: X-Spam-Status: No, score=-5.201 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, 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 9Yk4n6d93LMi for ; Thu, 23 Aug 2012 22:02:55 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5628921F851B for ; Thu, 23 Aug 2012 22:02:53 -0700 (PDT) Received: from [85.158.138.51:26060] by server-1.bemta-3.messagelabs.com id F5/B3-09327-CFA07305; Fri, 24 Aug 2012 05:02:52 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1345784572!27478517!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.6.1.3; banners=-,-,- Received: (qmail 21736 invoked from network); 24 Aug 2012 05:02:52 -0000 Received: from unknown (HELO fridlpvsb005.ecitele.com) (168.87.1.157) by server-4.tower-174.messagelabs.com with SMTP; 24 Aug 2012 05:02:52 -0000 X-AuditID: a8571406-b7f176d000000aff-e9-50370b0abac7 Received: from FRIDWPPCH001.ecitele.com (Unknown_Domain [10.1.16.52]) by fridlpvsb005.ecitele.com (Symantec Messaging Gateway) with SMTP id E7.0A.02815.A0B07305; Fri, 24 Aug 2012 07:03:06 +0200 (CEST) Received: from FRIDWPPMB002.ecitele.com ([169.254.4.244]) by FRIDWPPCH001.ecitele.com ([10.1.16.52]) with mapi id 14.01.0339.001; Fri, 24 Aug 2012 07:02:51 +0200 From: Alexander Vainshtein To: David Allan I Thread-Topic: A question regarding RFC 6428 Thread-Index: Ac2BNZvbMCmkHjiATrqyQfEmO1rwEAAP9o7QAA6F8KA= Date: Fri, 24 Aug 2012 05:02:50 +0000 Message-ID: References: , <60C093A41B5E45409A19D42CF7786DFD5CFCBF4D63@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD5CFCBF4D63@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.1] Content-Type: multipart/alternative; boundary="_000_F9336571731ADE42A5397FC831CEAA020D89DAFRIDWPPMB002ecite_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTXWwUVRj17szsTrcduUxL97ISHSahDzQt29TKimz9C2apEpZKQsUHGHZu dyfuzkxmhobyYDaNopJIixa1TaFaCllr7WarRCEGpAlJd5vyE2lqWlfUQhR8gIcS5K/rzE6p ffFlcuZ85zvnu3e+oQk25fLSkmxgTRZivNNNusFj3qri4rUh3x+z0P/7he8If0/uZf/UsS8p /+mDWco/3dkGXqCCnffTVPDe7Qln8GR3zhXs77/rCE62TbhC1PYEWC/IsmIIBuZErIcDfEiT WoRwK89JYoCv4Tk1JoRxHMtGgBdUFcsiX+9eb5KSzGE5rIiSHAnwG1/fXOX31z1bVcPXb41K Ooer4oIU4+JY14UI5kzGGlwWscg1KxpnRDGn4bCkSnjnh0R07Nv3KTX/I9gzN/4NmQBn+8B+ UEQj+DRqP9JL2rgcXfw15bQwC7MA/TVab+NjAE2d2WphJwyg4a9yBU0ZrEaDl+5T+4GbJmCS QMO3HxRMS+FqlJhNU7aoEh14kCFsvA59fCVf0JBwFRo68anJ0zQDN6HOfLHlw8IugM69M1oI KIJNqD37j8vCwBzuTnbQYWECetDU1V6HPTRE/T9cIGy8DF2fmaNs/BS6dOu3eb2C9h1NFHIZ uBRluq7OH3g5Opv8mewA5d2LbLsXtXQvarF5H7p5vpewcSU6/sXf83gNSs+Og8X858A1AFCz JokxtUXf5fPVVZufw8AxXB1W4sPA3K7ktjLn9yDRUT0CIA34EgYdeCbEUkKL3hofActpB7+M OUWuDbGP71LE1qigR3dou2NYHwGIJvgypnfGlDOi0LoXa8qj0gbzcg8S3uKwYq2DsaPW5/v/ F97DpBrrN7MwYq7nWxirWHvks4KmecRcLzLjl2o4gvc0SzHjv7KDLrLGKDHHGLI0jK4KcV2K 2PUsqKHzmUwO0EfnrOe1yfEcYElZkbHXw9yzGqDVEN0tL3jeAB7zEkqZJW6zWmIu84LbDTPI YQZVTNRaQeavtFDyJgD92fE3v+aSgdKxkelU14vqtXj68MmBwcqKyuefaNi0b2BjRS13Jv9J 40zPaM+hhnV9oUATf5n9iH3Yd5Pc0PFTxZDRtiJ9eM2VaBN57u1TWyQhc/lJ9oOVp2tX3d07 +XB729wdx63nplN1r402vvFKD+t599BLybHyV39pIM7/+d6Wdpon9ahQs5rQdOFf1hINxEIE AAA= Cc: "mpls@ietf.org" , "robrennison@gmail.com" , Mishael Wexler Subject: Re: [mpls] A question regarding RFC 6428 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, 24 Aug 2012 05:02:57 -0000 --_000_F9336571731ADE42A5397FC831CEAA020D89DAFRIDWPPMB002ecite_ Content-Type: text/plain; charset="Windows-1252" content-transfer-encoding: quoted-printable Dave, Lots of thanks for a prompt and informative response. A couple of comments i= f you do not mind. Your response is (consistent with RFC 6428) essentially says that the BFD s= ession state machine is the MEP state machine. This is implied by your stat= ement "How does the MEP get to a down state using LDI as a trigger without L= DI as an input to the state machine?... this kinda sounds like the "via seve= ral miracles" picture ;-) It is simply a remote version of a local LOF/LOL i= ndication". Of course (and I've tried to explain that) LDI is an input to th= e MEP state machine. But it does not have to be an input to the BFD state ma= chine IMO - unless you want to merge them into a single complicated one. One= implication of this approach is that you cannot implement an MPLS-TP MEP wi= thout implementing BFD. This is not exactly what RFC 6427 says. Regarding the need for fast RDI: 1. To the best of my understanding RDI is not defined as a trigger for pr= otection - at least not in RFC 6378. (For the reference, Line RDI is not def= ined as a trigger for APS in GR-253, so this is not something that tradition= al transport networks do.) 2. I agree that fast RDI would, in theory, improve the count of "remote u= navailable seconds" in some scenarios if these are counted. However I do not= see any IETF documents that define how these are counted, nor am I sure tha= t these are defined in any relevant ITU-T documents with specific reference= to the BFD diagnostic codes - because with BFD used for RDI the state of th= e BFD session receiving RDI would be DOWN just as in the case of the session= timer going down; the only difference is the diagnostic code. (Taking into= account that ITU-T goes full speed towards an alternative CC/CV/RDI mechani= sm for LSPs, I doubt this is going to happen, but this is just a not very ed= ucated guess:-). I would also like to bring to your attention the following statement from Se= ction 6.8.16 "Administrative Control" of RFC 5880" If signaling is received from outside BFD that the underlying path has failed, an implementation MAY administratively disable the session with the diagnostic Path Down. Other scenarios MAY use the diagnostic Administratively Down. BFD Control packets SHOULD be transmitted for at least a Detection Time after transitioning to AdminDown state in order to ensure that the remote system is aware of the state change. BFD Control packets MAY be transmitted indefinitely after transitioning to AdminDown state in order to maintain session state in each system My reading of this fragment is that 5880 takes a different approach to treat= ing "external" signals - and IMO LDI is exactly that. Last but not least, RFC 6428 is not marked as updating RFC 5880 (I've checke= d both the IETF data tracker and the RFC Editor site). Regards, Sasha ________________________________ From: David Allan I [david.i.allan@ericsson.com] Sent: Thursday, August 23, 2012 11:52 PM To: Alexander Vainshtein; swallow@cisco.com; John E Drake (jdrake@juniper.ne= t) Cc: Rotem Cohen; Mishael Wexler; Andrew Sergeev; Yechiel Rosengarten; Jagrat= i Shringi; robrennison@gmail.com; mpls@ietf.org Subject: RE: A question regarding RFC 6428 HI Sasha: I have serious doubts regarding one of the modifications to the BFD FSM that= has been introduced in RFC 6428. The BFD FSM diagram (Figure 7) for coordinated BFD operation in Section 3.7.= 5 =93State Machines=94 indicates that the BFD session transits from UP to DO= WN upon receiving an LDI (and, optionally, LKR) message. We simply have two more protocol inputs into the state machine as MPLS-TP in= troduced the ability for intermediate nodes to introduce transactions of OAM= significance into an LSP. Could you please explain the rationale for such a change in the BFD state ma= chine vs. what has been as described in RFC 5880? (The text in 6428 explains that the state machine is modified in order to su= pport mis-connectivity defect, but I do not see how this is related to LDI). Hmm I read it exactly backwards, the introductury texts to section 3.7.5 sho= uld have mentioned mis-connectivity as well as LDI/LDR instead of just LKR. This change is introduced in addition to a requirement from Section 3.7.2 th= at receiving Link Down Indication (be it a local link failure or an MPLS-TP= LDI message) results in entering a (presumably, Loss of Continuity) MEP def= ect state. Further, section 3.7.2 states that =93receiving nothing=94 (i.e.,= expiration of the BFD session timer) has higher priority that reception of= LDI. My reading of these results in the following: 1. If LDI is received after the session timer expiration it is ignored= . Correct, that could happen if the CC rate was such that losing 3 occurred fa= ster than the local criteria for issuing LDI. However that was not the use c= ase LDI was invented for. 2. If LDI is received before the session timer expiration, the session= first goes down and sends back RDI with the Path Down diagnostic code. It i= s not clear whether the BFD session timer expiration results in changing the= diagnostic code to =93Control Detection Timer Expired=94 or not . What diagnostic code to use for an LDI could be clarified. 3. In the situation when BFD session timer does not expire while LDI s= tate remains active (e.g., because the LSP uses FRR or segment protection to= bypass the failed link), the session would cycle thru DOWN->INIT-->UP--> DO= WN =96 session flapping/churn. Agreed, once you have multiple mechanisms involved, they do have the possibi= lity of disagreeing. But you would not want to use FRR and LDI together. Of= course, that does not mean that someone won't do it. 4. It is not clear what is supposed to happen if the BFD session went= DOWN because an LDI message has been received and then LDI state has been c= leared (e.g., using the fast clearance mechanism defined in Section 5.2 of R= FC 6427) before t= he session timer has expired. If you get an LDI you would transition to DOWN, you would then have to go th= rough INIT etc. so I'm not sure there is an issue here. It came first, so I= think the timers are rendered irrelevant by the session re-starting. To make my position clear, I do not see any issues with adding LDI as a trig= ger for sending the MEP to its DOWN state. I simply do not understand why th= is requires modification of the BFD State machine. How does the MEP get to a down state using LDI as a trigger without LDI as a= n input to the state machine?... this kinda sounds like the "via several mir= acles" picture ;-) It is simply a remote version of a local LOF/LOL indicati= on. At best this would speed up generation of RDI towards the remote MEP, but t= he price does not seem to justify the effort. Note that RDI is not used as= a trigger for protection actions; if bidirectional LSP protection is requir= ed, this is achieved via the PSC =96 e.g., as defined in RFC 6378. It would also enhance the accuracy of PM associated with availability as eve= n with a slow CC rate, the LSP would enter the unavailable state faster. But= more fundamentally, my take of figure 1 in 6378 is that CC/RDI are OAM indi= cations as inputs into PSC, else why are we bothering. CC/RDI is a trigger f= or protection actions. I hope this helps Dave This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_F9336571731ADE42A5397FC831CEAA020D89DAFRIDWPPMB002ecite_ Content-Type: text/html; charset="Windows-1252" content-transfer-encoding: quoted-printable

Dave,

Lots of thanks for a prompt and informative response. A couple of comment= s if you do not mind.

 

Your response is (consistent with  RFC 6428) essentially s= ays that the BFD session state machine is  the MEP s= tate machine. This is implied by your statement "How does the MEP get to a down state using LDI as a trigger without LDI as an input= to the state machine?... this kinda sounds like the &quo= t;via several miracles" picture ;-) It is simply a remote version of a= local LOF/LOL indication". Of course (and I've tried to explain that) LDI is an input to the MEP state machine.= But it does not have to be an input to the BFD state machine IMO - unless y= ou want to merge them into a single complicated one. One implication of this= approach is that you cannot implement an MPLS-TP MEP without implementing BFD. This is not exactly what RFC 6427= says.

 

Regarding the need for fast RDI:

  1. To the best of my understanding RDI is not defined as a trig= ger for protection - at least not in RFC 6378. (For the reference,= Line RDI is not defined as a trigger for APS in GR-253, so this is not= something that traditional transport networks do.)
  2. I agree that fast RDI would, in theory, improve the count of= "remote unavailable seconds" in some scenarios if these are count= ed. However I do not see any IETF documents that define how these are counte= d, nor am I sure that these are defined in any relevant ITU-T documents with specific reference to the BFD diagn= ostic codes - because with BFD used for RDI the state of the BFD= session receiving RDI would be DOWN just as in the case of the session= timer going down; the only difference is the diagnostic code. (Taking into account that ITU-T goes full speed towards an alternativ= e CC/CV/RDI mechanism for LSPs, I doubt this is going to happen, but this is= just a not very educated guess:-).

 

I would also like to bring to your attention the following statement from= Section 6.8.16 "Administrative Control" of RFC 5880"

 

<quote>

   If signaling is received from outside BFD that the underlyin= g path
   has failed, an implementation MAY administratively disable= the
   session with the diagnostic Path Down.

   Other scenarios MAY use the diagnostic Administratively Down.
   BFD Control packets SHOULD be transmitted for at least a Detect= ion
   Time after transitioning to AdminDown state= in order to ensure that
   the remote system is aware of the state change.  BFD Contr= ol packets
   MAY be transmitted indefinitely after transitioning to Adm= inDown
   state in order to maintain session state in each system

<end quote>

 

My reading of this fragment is that 5880 takes a different approach= to treating "external" signals - and IMO LDI is exactly that.

 

Last but not least, RFC 6428 is not marked as updating RFC 5880= (I've checked both the IETF data tracker and the RFC Editor site).

 

Regards,

     Sasha

 

 

From: David Allan I [david.i.allan@ericsson.= com]
Sent: Thursday, August 23, 2012 11:52 PM
To: Alexander Vainshtein; swallow@cisco.com; John E Drake (jdrake@jun= iper.net)
Cc: Rotem Cohen; Mishael Wexler; Andrew Sergeev; Yechiel Rosengarten;= Jagrati Shringi; robrennison@gmail.com; mpls@ietf.org
Subject: RE: A question regarding RFC 6428

HI Sasha:

I have serious doubts regarding one of the modificati= ons to the BFD FSM that has been introduced in RFC 6428.

The BFD FSM diagram (Figure 7) for coordinated BFD op= eration in Section 3.7.5 =93State Machines=94 indicates that the BFD= session transits from UP to DOWN upon receiving an LDI (and, optionally, LK= R) message. 

 

We simply have two more protocol inputs into= the state machine as MPLS-TP introduced the ability for intermediate nodes= to introduce transactions of OAM significance into an LSP.

 

Could you please explain the rationale for such a cha= nge in the BFD state machine vs. what has been as described in RFC 5880?

(The text in 6428 explains that the state machine is= modified in order to support mis-connectivity defect, but I do not see how= this is related to LDI). 

 

Hmm I read it exactly backwards, the in= troductury texts to section 3.7.5 should have mentioned mis-connectivit= y as well as LDI/LDR instead of just LKR.  

 

This change is introduced in addition to a requiremen= t from Section 3.7.2 that receiving Link Down Indication (be it a local link= failure or an MPLS-TP LDI message) results in entering a (presumably, Loss= of Continuity) MEP defect state. Further, section 3.7.2 states that =93receiving nothing=94 (i.e., expiratio= n of the BFD session timer) has higher priority that reception of LDI. My re= ading of these results in the following:

1.       If LDI is received after the session= timer expiration it is ignored. 

<= /span> 

Correct,= that could happen if the CC rate was such that losing 3 occurred faster tha= n the local criteria for issuing LDI. However that was not the use case LDI was invented for.

<= /span> 

2.       If LDI is received before the session= timer expiration, the session first goes down and sends back RDI with the P= ath Down diagnostic code. It is not clear whether the BFD session timer expi= ration results in changing the diagnostic code to =93Control Detection Timer Expired=94 or not&n= bsp;.

What dia= gnostic code to use for an LDI could be clarified.

 

3.       In the situation when BFD session tim= er does not expire while LDI state remains active (e.g., because the LSP use= s FRR or segment protection to bypass the failed link), the session would cy= cle thru DOWN->INIT-->UP--> DOWN =96 session flapping/churn. 

<= /span> 

Agreed,= once you have multiple mechanisms involved, they do have the possibility of= disagreeing. But you would not want to use FRR and LDI together. Of course, that does not mean that someone won't do i= t.

 

4.       It is not clear what is supposed to h= appen if the BFD session went DOWN because an LDI message has been received= and then LDI state has been cleared (e.g., using the fast clearance mechani= sm defined in Section 5.2 of RFC 6427) before the session timer has expired. &n= bsp;

If you g= et an LDI you would transition to DOWN, you would then have to go throu= gh INIT etc. so I'm not sure there is an issue here. It came= first, so I think the timers are rendered irrelevant by the session re-star= ting.

 

To make my position clear, I do not see any issues wi= th adding LDI as a trigger for sending the MEP to its DOWN state. I simply d= o not understand why this requires modification of the BFD State machine.&nb= sp; 

 

How does the MEP get to a down state using L= DI as a trigger without LDI as an input to the state machine?... this kinda= sounds like the "via several miracles" picture ;-) It is simply a remote version of a local LOF/LOL indication.

 

 At be= st this would speed up generation of RDI towards the remote MEP, but the pri= ce does not seem to justify the effort.  Note that RDI is not used as a= trigger for protection actions; if bidirectional LSP protection is required, this is achieved via the PSC =96 e.g., as defin= ed in RFC 6378.

 

It would also enhance the accuracy of PM ass= ociated with availability as even with a slow CC rate, the LSP would enter t= he unavailable state faster. But more fundamentally, my take of figure 1 in 6378 is that CC/RDI are OAM indications as = ;inputs into PSC, else why are we bothering. CC/RDI is a trigger for protect= ion actions.

 

I hope this helps

Da= ve 

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

--_000_F9336571731ADE42A5397FC831CEAA020D89DAFRIDWPPMB002ecite_-- From loa@pi.nu Fri Aug 24 04:24: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 7ED5921F86CB for ; Fri, 24 Aug 2012 04:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 DKhycm2o8yIU for ; Fri, 24 Aug 2012 04:24:26 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD0021F86DF for ; Fri, 24 Aug 2012 04:24:25 -0700 (PDT) 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) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id AA3B42A8003; Fri, 24 Aug 2012 13:24:23 +0200 (CEST) Message-ID: <50376462.8080408@pi.nu> Date: Fri, 24 Aug 2012 13:24:18 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , Martin Vigoureux , "mpls-ads@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] new milestones for the MPLS working group 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, 24 Aug 2012 11:24:27 -0000 Working Group, Our ADs has been nagging the working groups chairs that we are bad not managing the working group goals and milestones. A quick look at our charter page confirms that they are right :)! Well AD's are right sometimes. All our goals and milestones are marked "DONE" and we are busier than ever. The working group chairs have discussed new milestones for the working group and come up with the list below. We will add the new milestones to the charter end of next week, but we have wanted to give the authors of the working group draft a chance to commit to the schedule for their drafts. Please do so in a *unidirectional* mail addressed to the chairs and to the working group secretary. We have used the working group drafts as the first order milestones, but we have also grouped them and the groups also form milestones. The consequence is that the group has a target date equal to the draft with the latest target date. If we add a new draft with a later target than any other in the group, the target date will be moved. Here is the list of the new milestones: MPLS Working Group Milestones ============================= Complete the MPLS-TP drafts (2013-06) ------------------------------------- - draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf (2013-03) - draft-ietf-mpls-tp-1ton-protection (2013-06) - draft-ietf-mpls-tp-ethernet-addressing (2012-12) - draft-ietf-mpls-tp-itu-t-identifiers (2012-11) - draft-ietf-mpls-tp-mip-mep-map (2013-06) - draft-ietf-mpls-tp-oam-id-mib (2012-12) - draft-ietf-mpls-tp-ring-protection (2012-12) - draft-ietf-mpls-tp-security-framework (2012-12) - draft-ietf-mpls-tp-te-mib (2012-12) - draft-ietf-mpls-tp-temporal-hitless-psm (2013-06) - draft-ietf-mpls-tp-use-cases-and-design (2012-12) - draft-ietf-mpls-tp-rosetta-stone (2013-06) Complete Generic Associated Channel Enhancements (2012-12) ---------------------------------------------------------- - draft-ietf-mpls-gach-adv (2012-12) Address IPv6 aspects of MPLS (2012-12) -------------------------------------- - draft-ietf-mpls-ipv6-pw-lsp-ping (2012-12) - draft-ietf-mpls-ldp-ipv6 (2012-12) Address MPLS architecture issues (2013-03) ------------------------------------------ - draft-ietf-mpls-entropy-label (2012-11) - draft-ietf-mpls-seamless-mcast (2013-03) - draft-ietf-mpls-seamless-mpls (2013-03) Complete LDP enhancements (2013-06) ----------------------------------- - draft-ietf-mpls-ldp-applicability-label-adv (2013-03) - draft-ietf-mpls-ldp-dod (2013-03) - draft-ietf-mpls-ldp-gtsm (done) - draft-ietf-mpls-ldp-hello-crypto-auth (2013-06) - draft-ietf-mpls-ldp-ip-pw-capability (2013-04) - draft-ietf-mpls-ldp-multi-topology (2013-05) Complete LSP PIng Enhancements (2013-03) ---------------------------------------- - draft-ietf-mpls-lsp-ping-ttl-tlv (2013-03) - draft-ietf-mpls-return-path-specified-lsp-ping (2012-12) Complete mLDP Enhancements (2013-06) ------------------------------------ - draft-ietf-mpls-mldp-in-band-signaling (2012-12) - draft-ietf-mpls-targeted-mldp (2013-06) /Loa for the working group 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 ietf-ipr@ietf.org Fri Aug 24 11:02: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 2CD1821F856F; Fri, 24 Aug 2012 11:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.423 X-Spam-Level: X-Spam-Status: No, score=-102.423 tagged_above=-999 required=5 tests=[AWL=0.176, 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 d6eBi-HFhyH6; Fri, 24 Aug 2012 11:02:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E662B21F852D; Fri, 24 Aug 2012 11:02:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: aatlas@avici.com, swallow@cisco.com, ppan@hammerheadsystems.com X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120824180257.12742.30016.idtracker@ietfa.amsl.com> Date: Fri, 24 Aug 2012 11:02:57 -0700 Cc: mpls@ietf.org, rcallon@juniper.net, ipr-announce@ietf.org Subject: [mpls] IPR Disclosure: Koninklijke KPN N.V.'s Statement about IPR related to RFC 4090 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, 24 Aug 2012 18:02:59 -0000 Dear Alia Atlas, George Swallow, Ping Pan: An IPR disclosure that pertains to your RFC entitled "Fast Reroute Extensi= ons to RSVP-TE for LSP Tunnels" (RFC4090) was submitted to the IETF Secretariat= on 2012-08-22 and has been posted on the "IETF Page of Intellectual Property R= ights Disclosures" (https://datatracker.ietf.org/ipr/1870/). The title of the IPR disclosure is "Koninklijke KPN N.V.'s Statement about IPR related to RFC 4090.""); The IETF Secretariat From wwwrun@rfc-editor.org Fri Aug 24 16:22: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 2694721F8650; Fri, 24 Aug 2012 16:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.004 X-Spam-Level: X-Spam-Status: No, score=-102.004 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 jAsHOqZfq9bl; Fri, 24 Aug 2012 16:22:28 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id B69BB21F8648; Fri, 24 Aug 2012 16:22:28 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8DFE4B1E00A; Fri, 24 Aug 2012 16:20:26 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120824232026.8DFE4B1E00A@rfc-editor.org> Date: Fri, 24 Aug 2012 16:20:26 -0700 (PDT) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 6720 on The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP) 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, 24 Aug 2012 23:22:29 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6720 Title: The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP) Author: C. Pignataro, R. Asati Status: Standards Track Stream: IETF Date: August 2012 Mailbox: cpignata@cisco.com, rajiva@cisco.com Pages: 8 Characters: 17823 Updates: RFC5036 I-D Tag: draft-ietf-mpls-ldp-gtsm-09.txt URL: http://www.rfc-editor.org/rfc/rfc6720.txt The Generalized TTL Security Mechanism (GTSM) describes a generalized use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify that the packet was sourced by a node on a connected link, thereby protecting the router's IP control plane from CPU utilization-based attacks. This technique improves security and is used by many protocols. This document defines the GTSM use for the Label Distribution Protocol (LDP). This specification uses a bit reserved in RFC 5036 and therefore updates RFC 5036. [STANDARDS-TRACK] This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From loa@pi.nu Mon Aug 27 01:52: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 60E5021F855A for ; Mon, 27 Aug 2012 01:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 UQ0gnlSc6tS2 for ; Mon, 27 Aug 2012 01:52:33 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id C173A21F851E for ; Mon, 27 Aug 2012 01:52:32 -0700 (PDT) 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) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 042152A8003; Mon, 27 Aug 2012 10:52:30 +0200 (CEST) Message-ID: <503B354E.3080401@pi.nu> Date: Mon, 27 Aug 2012 10:52:30 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , Martin Vigoureux , "draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] implemetations of draft-ietf-mpls-return-path-specified-lsp-ping ?? 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, 27 Aug 2012 08:52:33 -0000 Working Group, we are getting closer to send a publication request for draft-ietf-mpls-return-path-specified-lsp-ping. before we do so we need to know about plans to implement or existing implementations. If you plan to implement or have an implementation of draft-ietf-mpls-return-path-specified-lsp-ping please let the working group chairs know. /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 kireeti@juniper.net Mon Aug 27 11:37: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 BD69121F843F for ; Mon, 27 Aug 2012 11:37:52 -0700 (PDT) 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 hfPhWGPNZQe9 for ; Mon, 27 Aug 2012 11:37:52 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id B703D21F841E for ; Mon, 27 Aug 2012 11:37:45 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUDu+eBDi5FfFPVaGsPeIm5sxePcLCX/7@postini.com; Mon, 27 Aug 2012 11:37:52 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 27 Aug 2012 11:36:02 -0700 From: Kireeti Kompella To: "mpls@ietf.org" Date: Mon, 27 Aug 2012 11:36:02 -0700 Thread-Topic: AD review of draft-ietf-mpls-entropy-label Thread-Index: Ac2Egs+Rc65Iem9XT/eb/amLNPzolg== Message-ID: <34E3FE47-EA63-4719-8557-42E067316877@juniper.net> References: <0dc501cd7bb1$d318ad10$794a0730$@olddog.co.uk> <0edf01cd7c43$94feec00$befcc400$@olddog.co.uk> <3E2B22DB-9FF6-41D0-92C3-85E25FF57ECF@juniper.net> <10c101cd7d65$7bd332e0$737998a0$@olddog.co.uk> <129201cd7f03$4168d070$c43a7150$@olddog.co.uk> In-Reply-To: <129201cd7f03$4168d070$c43a7150$@olddog.co.uk> 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 Cc: "draft-ietf-mpls-entropy-label@tools.ietf.org" Subject: Re: [mpls] AD review of draft-ietf-mpls-entropy-label 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, 27 Aug 2012 18:37:52 -0000 Hi Group, In consolidating text on the setting of TTL, TC and BoS, I noticed that the= current text says that the TTL of an EL SHOULD be zero. I think this is a= case for MUST (to prevent accidental forwarding based on an EL), and will = reflect that in the next revision. If there are any objections to a MUST instead of SHOULD, please reply! Thanks, Kireeti. On Aug 20, 2012, at 11:40 , Adrian Farrel wrote: > Hi, >=20 > Take it as an IETF last call comment (since I already started IETF last c= all). >=20 > Thanks, > Adrian >=20 >> -----Original Message----- >> From: Kireeti Kompella [mailto:kireeti@juniper.net] >> Sent: 20 August 2012 19:30 >> To: adrian@olddog.co.uk >> Cc: Kireeti Kompella; draft-ietf-mpls-entropy-label@tools.ietf.org; > mpls@ietf.org >> Subject: Re: AD review of draft-ietf-mpls-entropy-label >>=20 >> On Aug 18, 2012, at 10:18 , Adrian Farrel wrote: >>=20 >>> Yeah, and it is great that you give a reason for doing it, but by using > SHOULD >>> you have to explain why you might vary. That was what my MAY sentence w= as >> trying >>> to do. If I got the reason wrong then sorry, please add your own reason= . >>=20 >> Okay. Proposed text: >>=20 >> X MAY choose different values for the TTL and TC fields if it is >> known that the ELI will not be exposed as the top label at any point >> along the LSP. >>=20 >> If this is acceptable, can this wait, or should we spin an -06? >>=20 >> Kireeti. >>=20 >>> But if >>> your reason is, because there might turn out to be a reason one day in = the >>> future, then use MUST and write a new I-D sometime in the future. >>>=20 >>> A >>>=20 >>>> -----Original Message----- >>>> From: Kireeti Kompella [mailto:kireeti@juniper.net] >>>> Sent: 17 August 2012 19:02 >>>> To: adrian@olddog.co.uk >>>> Cc: Kireeti Kompella; draft-ietf-mpls-entropy-label@tools.ietf.org; >>> mpls@ietf.org >>>> Subject: Re: AD review of draft-ietf-mpls-entropy-label >>>>=20 >>>> On Aug 16, 2012, at 23:43 , Adrian Farrel wrote: >>>>=20 >>>>> So... >>>>> OLD >>>>> X SHOULD put the same TTL and TC fields for the ELI as >>>>> it does for TL. >>>>> NEW >>>>> X SHOULD put the same TTL and TC fields for the ELI as >>>>> it does for TL to protect LSP behavior in cases where PHP is used >>>>> and the ELI and EL are not stripped at the previous hop (see Section >>>>> 4.4). If it is known that PHP is not used or that PHP will strip the = ELI >>>>> and EL, the TTL and TC of the ELI MAY be set differently. >>>>> END >>>>=20 >>>> X will likely be blissfully unaware of whether PHP will be used (and > whether >>> the >>>> PHP LSR will pop ELI+EL), unless this is a very short LSP. >>>>=20 >>>>> ***or*** >>>>>=20 >>>>> s/SHOULD/MUST/ >>>>=20 >>>> I have a pathological fear of MUST. >>>>=20 >>>> How about: >>>>=20 >>>> NEW >>>> X SHOULD put the same TTL and TC fields for the ELI as >>>> it does for TL. This protects LSP behavior in cases where PHP is used >>>> and the ELI and EL are not stripped at the penultimate hop (see Sectio= n >>>> 4.4). >>>> END >>>>=20 >>>> I'd better get out a new version before the list of things to do gets = any >>> longer. >>>>=20 >>>> Kireeti.=3D >>>=20 >=20 From zhang.fei3@zte.com.cn Mon Aug 27 19:52: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 4676E21E8037 for ; Mon, 27 Aug 2012 19:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.492 X-Spam-Level: X-Spam-Status: No, score=-96.492 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 CSQBnc8HYIRa for ; Mon, 27 Aug 2012 19:52:09 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id DAF8711E808E for ; Mon, 27 Aug 2012 19:52:08 -0700 (PDT) Received: from [192.168.168.119] by mx5.zte.com.cn with surfront esmtp id 23255806486374; Tue, 28 Aug 2012 10:45:47 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 9010076CD67; Tue, 28 Aug 2012 10:47:53 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q7S2pnja041058; Tue, 28 Aug 2012 10:51:49 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD5CFC7DA5BF@EUSAACMS0703.eamcs.ericsson.se> To: David Allan I MIME-Version: 1.0 X-KeepSent: 37313C0A:4395567A-48257A68:000D1B19; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Tue, 28 Aug 2012 10:51:47 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-28 10:51:47, Serialize complete at 2012-08-28 10:51:47 Content-Type: multipart/alternative; boundary="=_alternative 000FA3B248257A68_=" X-MAIL: mse01.zte.com.cn q7S2pnja041058 Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-weingarten-mpls-smp-requirements-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: Tue, 28 Aug 2012 02:52:11 -0000 This is a multipart message in MIME format. --=_alternative 000FA3B248257A68_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgRGF2ZQ0KDQpTb3JyeSBmb3IgdGhlIGRlbGF5ZWQgcmVzcG9uc2UsIHNlZSBteSBub3RlcyB0 YWdnZWQgd2l0aCA8ZmVpPg0KDQoNClRoYW5rcw0KDQpGZWkNCg0KDQoNCkRhdmlkIEFsbGFuIEkg PGRhdmlkLmkuYWxsYW5AZXJpY3Nzb24uY29tPiANCjIwMTItMDgtMjIgMDE6MjkNCg0KytW8/sjL DQoiemhhbmcuZmVpM0B6dGUuY29tLmNuIiA8emhhbmcuZmVpM0B6dGUuY29tLmNuPiwgR3JlZ29y eSBNaXJza3kgDQo8Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPg0Ks63LzQ0KIm1wbHNAaWV0 Zi5vcmciIDxtcGxzQGlldGYub3JnPg0K1vfM4g0KUkU6IFttcGxzXSBDb21tZW50cyBvbiBkcmFm dC13ZWluZ2FydGVuLW1wbHMtc21wLXJlcXVpcmVtZW50cy0wMC50eHQNCg0KDQoNCg0KDQoNCkhp IEZlaToNCiANCkkgc2VlICJhIiBwcm9wb3NlZCBzb2x1dGlvbiBpbiB0aGUgZHJhZnQgeW91IHJl ZmVyZW5jZSwgYnV0IG5vdCBhIHByb2JsZW0gDQpzdGF0ZW1lbnQgb3IgYW5hbHN5c2lzDQoNCjxm ZWk+ICBUaGUgcHJvcG9zZWQgc29sdXRpb24gaXMgYmFzZSBvbiB0aGUgY29udHJvbCBwbGFuZSBl eHRlbnNpb25zLCBhbmQgDQp0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgc2FpZCAiIFtSRkM0ODcyXSBk ZWZpbmVzIHRoZSBzaGFyZWQgbWVzaCByZXN0b3JhdGlvbiANCnNjaGVtZXMgYmFzZWQgb24NCiAg IGNvbnRyb2wgcGxhbmUgZXh0ZW5zaW9ucywgYnV0IGRvZXMgbm90IGNvdmVyIHRoZSBzaGFyZWQg bWVzaCBwcm90ZWN0aW9uIA0Kc2NlbmFyaW9zLiINCiANClRoZSBwcmVlbXB0aW9uIGNvdWxkIHNp bXBseSBiZSBwZXJmb3JtZWQgYXQgbm9kZSBFLiBDdXJyZW50bHkgdGhlIG1vZGVsIGlzIA0KdGhh dCB0aGUgTEVScyBuZWVkIHRvIG5vdGlmeSBub2RlIEUgd2hlbiB0aGUgUCBwYXRoIGlzIGJlaW5n IHVzZWQsIGFuZCBFIA0KbmVlZHMgdG8gbm90aWZ5IHRoZSBMRVJzIG9mIHRoZSBjdXJyZW50IHN0 YXRlIG9mIHRoZSBzaGFyZWQgcmVzb3VyY2UuIFRoaXMgDQphcHBlYXJzIHRvIGRlcGVuZCBvbiB0 aGUgcHJlZW1wdGVkIExTUiB0byAiZG8gdGhlIHJpZ2h0IHRoaW5nIiBhbmQgbGVhZHMgDQp0byBh biBJTU8gdW5yZWFzb25hYmxlIHdpbmRvdyBvZiBjb250ZW50aW9uIGZvciB0aGUgc2hhcmVkIHJl c291cmNlcy4NCg0KICA8ZmVpPiBQcmVlbXB0aW9uIG1lYW5zIHRoYXQgIHRoZXJlIHdpbGwgYmUg YSB3aW5kb3cgb2YgY29udGVudGlvbiwgd2h5IA0KaXQgaXMgdW5yZWFzb25hYmxlPw0KDQpJTU8g RSBzaG91bGQgYmUgZG9pbmcgdGhlIHByZWVtcHRpb24sIGFuZCBJJ3ZlIHN0aWxsIG5vdCByZWFs bHkgc2VlbiBhIA0KbmVlZCBmb3IgaGVhZCBlbmQgbm90aWZpY2F0aW9uIG9mIHByZWVtcHRpb24g dW5sZXNzIG9uZSBzdGFydHMgcGxhbm5pbmcgDQpiYWNrdXBzIGZvciBiYWNrdXBzLg0KDQogIDxm ZWk+IElNSE8sIHRoZXJlIGFyZSB0d28gcHJpb3JpdGllcyBuZWVkIHRvIGJlIGhhbmRsZWQgaW4g c2hhcmVkIG1lc2ggDQpwcm90ZWN0aW9uIHNjZW5hcmlvcywgdGhlIHBhdGggcHJpb3JpdHkgYW5k IHRoZSBzZXJ2aWNlIHByaW9yaXR5IChQSEIpLiBJZiANCm5vZGUgRSBkb2VzIHRoZSBwcmVlbXB0 aW9uLCBob3cgdG8gDQpkZWFsIHdpdGggdGhlIHBhdGggcHJpb3JpdHksIHdoaWNoIGlzIG5vdCBj YXJyaWVkIGluIHRyYWZmaWMgcGFja2V0LiANCiANCklmIHlvdSBoYXZlIG1vcmUgaW5mb3JtYXRp b24sIGNvdWxkIHlvdSBlbGFib3JhYmxlPw0KRGF2ZQ0KIA0KIA0KDQpGcm9tOiBtcGxzLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiAN CnpoYW5nLmZlaTNAenRlLmNvbS5jbg0KU2VudDogTW9uZGF5LCBBdWd1c3QgMjAsIDIwMTIgNDow MyBBTQ0KVG86IEdyZWdvcnkgTWlyc2t5DQpDYzogbXBsc0BpZXRmLm9yZzsgbXBscy1ib3VuY2Vz QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21wbHNdIENvbW1lbnRzIG9uIA0KZHJhZnQtd2Vpbmdh cnRlbi1tcGxzLXNtcC1yZXF1aXJlbWVudHMtMDAudHh0DQoNCg0KR3JlZywgc25pcHBlZCANCklu IHRoZSBsYXN0IHNlbnRlbmNlIG9mIFNlY3Rpb24gMy4xIG5vbi1jb250cm9sIHBsYW5lIGNvb3Jk aW5hdGlvbiBvZiANCnNoYXJlZCByZXNvdXJjZXMgcHJlc2VudGVkIGFzIGFub3RoZXIgcmVxdWly ZW1lbnQuIEFuZCBhZ2FpbiBJIGNhbiBub3QgDQpmaW5kIGhvdyB3ZSBjb21lIHRvIHN1Y2ggY29u Y2x1c2lvbiwgd2hlcmUgdGhlIHNvdXJjZSBvZiB0aGlzIHJlcXVpcmVtZW50LiANCldvdWxkIGV4 aXN0aW5nIGNvbnRyb2wgcGxhbmUgc2lnbmFsaW5nIHNvbHV0aW9uIGJlIHN1ZmZpY2llbnQgZm9y IGEgTVBMUyANCm5ldHdvcms/IA0KDQo8RmVpPiBJIGRvIG5vdCB0aGluayB0aGUgZXhpc3Rpbmcg Y29udHJvbCBwbGFuZSAoZGVmaW5lZCBpbiBSRkM0ODcyKSBpcyANCnN1ZmZpY2llbnQgZm9yIGEg TVBMUyBuZXR3b3JrLCBhbmQgdGhlcmUgaXMgYW4gYW5hbHlzaXMgaW4gdGhlIGRyYWZ0IA0KaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGUtY2NhbXAtbm90aWZpY2F0aW9uLXNoYXJl ZC1tZXNoLXByb3RlY3Rpb24tMDANCi4gDQoNCg0KQmVzdCByZWdhcmRzIA0KDQpGZWkgDQoNCg0K DQpHcmVnb3J5IE1pcnNreSA8Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPiANCreivP7Iyzog IG1wbHMtYm91bmNlc0BpZXRmLm9yZyANCjIwMTItMDgtMTYgMDY6NDUgDQoNCg0KytW8/sjLDQpQ YWJsbyBGcmFuayA8cGFibG9pc25vdEBnbWFpbC5jb20+LCBZYWFjb3YgV2VpbmdhcnRlbiA8d3lh YWNvdkBnbWFpbC5jb20+IA0Ks63LzQ0KIm1wbHNAaWV0Zi5vcmciIDxtcGxzQGlldGYub3JnPiAN Ctb3zOINClJlOiBbbXBsc10gQ29tbWVudHMgb24gZHJhZnQtd2VpbmdhcnRlbi1tcGxzLXNtcC1y ZXF1aXJlbWVudHMtMDAudHh0DQoNCg0KDQoNCg0KDQoNCg0KRGVhciBQYWJsbywgWWFhY292LCBl dCBhbC4sIA0KSSd2ZSBiZWVuIGZvbGxvd2luZyBkaXNjdXNzaW9uIHdpdGggZ3JlYXQgZGVhbCBv ZiBpbnRlcmVzdC4gSSBoYXZlIHNvbWUgDQpxdWVzdGlvbnMgaW4gYWRkaXRpb24gdG8gb25lcyBi ZWluZyBicm91Z2h0IHVwIGJ5IFBhYmxvOiANClNlY3Rpb24gMS4yIHJlZmVycyB0byBvcGVyYXRv cidzIGRlc2lyZSB0byBoYXZlIHNlcnZpY2UgcmVzdG9yYXRpb24gbW9yZSANCmV4cGVkaWVudCB0 aGFuIG9uZSBhY2hpZXZhYmxlIHdpdGggY29udHJvbCBwbGFuZS4gSSBoYXZlbid0IHNlZW4gYW55 IA0KcXVhbnRhdGl2ZSBpbmZvcm1hdGlvbiB0byBjb21wYXJlIHdpdGguIFdoYXQgaXMgImV4cGVk aWVudCBlbm91Z2giIGZvciANClNNUD8gDQpTZWN0aW9uIDMuMSBkZXNyY2liZXMsIHdoYXQgY2Fu IGJlIGNhbGxlZCwgImluc3RhbnQgZGV0ZXJtaW5pc20iIGluIHJlZ2FyZCANCnRvIFNNUCByZXNv dXJjZSBhdmFpYWxhYmlsaXR5LiBJIHRoaW5rIHRoYXQgdGhlcmUncyBub3QgZW5vdWdoIHJlYXNv bmluZyANCnRvIGNvbmNsdWRlIHRoYXQgYWxtb3N0IGluc3RhbnRlbmVvdXMgdXBkYXRlIG9mIFNN UCByZXNvdXJjZXMgDQphdmFpYWxhYmlsaXR5IGlzIHJlcXVpcmVkLiANCkluIHRoZSBsYXN0IHNl bnRlbmNlIG9mIFNlY3Rpb24gMy4xIG5vbi1jb250cm9sIHBsYW5lIGNvb3JkaW5hdGlvbiBvZiAN CnNoYXJlZCByZXNvdXJjZXMgcHJlc2VudGVkIGFzIGFub3RoZXIgcmVxdWlyZW1lbnQuIEFuZCBh Z2FpbiBJIGNhbiBub3QgDQpmaW5kIGhvdyB3ZSBjb21lIHRvIHN1Y2ggY29uY2x1c2lvbiwgd2hl cmUgdGhlIHNvdXJjZSBvZiB0aGlzIHJlcXVpcmVtZW50LiANCldvdWxkIGV4aXN0aW5nIGNvbnRy b2wgcGxhbmUgc2lnbmFsaW5nIHNvbHV0aW9uIGJlIHN1ZmZpY2llbnQgZm9yIGEgTVBMUyANCm5l dHdvcms/IA0KSSd2ZSBub3RpY2VkIHRoYXQgbWFueSByZXF1aXJlbWVudHMgYmVpbmcgcmVmZXJy ZWQgdG8gTVBMUy1UUCwgbm90IE1QTFMsIA0KbmV0d29ya3MuIFdvdWxkIHRoYXQgYmUgYSBnb29k IHJlYXNvbiB0byBuYXJyb3cgc2NvcGUgb2YgdGhlIGRvY3VtZW50IHRvIA0KTVBMUy1UUCBuZXR3 b3JrcyBvbmx5LCBzdGFydGluZyB3aXRoIHRoZSBuYW1lIG9mIHRoZSBkb2N1bWVudD8NCiAgICBS ZWdhcmRzLCANCiAgICAgICAgR3JlZyANCg0KRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgDQpQYWJsbyBGcmFuaw0K U2VudDogRnJpZGF5LCBBdWd1c3QgMTAsIDIwMTIgNzoyMyBBTQ0KVG86IFlhYWNvdiBXZWluZ2Fy dGVuDQpDYzogbXBsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFttcGxzXSBDb21tZW50cyBvbiAN CmRyYWZ0LXdlaW5nYXJ0ZW4tbXBscy1zbXAtcmVxdWlyZW1lbnRzLTAwLnR4dA0KDQpIaSBZYWFj b3YsIA0KDQpTb21lIG1vcmUgY29tbWVudHMgaW5saW5lLi4uIFBGPj4NCg0KT24gTW9uLCBBdWcg NiwgMjAxMiBhdCA4OjU2IEFNLCBZYWFjb3YgV2VpbmdhcnRlbiA8d3lhYWNvdkBnbWFpbC5jb20+ IA0Kd3JvdGU6IA0KSGksIA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMuICBQbGVhc2Ug c2VlIG15IGNvbW1lbnRzIGlubGluZSBiZWxvdy4gDQoNCkJSLCANCnlhYWNvdg0KDQpPbiBUdWUs IEp1bCAxNywgMjAxMiBhdCAxMTo1MSBQTSwgUGFibG8gRnJhbmsgPHBhYmxvaXNub3RAZ21haWwu Y29tPiANCndyb3RlOiANCkdvb2QgZHJhZnQgYW5kIGNlcnRhaW5seSBzb21ldGhpbmcgdGhhdCBu ZWVkcyB0byBiZSBkb25lIGJlZm9yZSB3ZSBjYW4gDQpzdGFydCBkaXNjdXNzaW5nIHNwZWNpZmlj IHNvbHV0aW9ucy4gDQoNCk9ubHkgYSBmZXcgY29tbWVudHMgLyBxdWVzdGlvbnM6IA0KDQotIElu IDQuMS4xLCBpZiBvbmUgaXMgb3BlcmF0aW5nIGluIGFuIE1QTFMtVFAgbmV0d29yayB0aGF0IHJl cXVpcmVzIA0KZXhjbHVzaXZlIHVzZSBvZiB0aGUgcHJvdGVjdGlvbiByZXNvdXJjZXMsIGRvZXNu J3QgdGhpcyBTSE9VTEQgcmVxdWlyZW1lbnQgDQpiZWNvbWUgYSBNVVNUIHJlcXVpcmVtZW50PyAN Cg0KeXc+PiBTb3JyeSAtIGJ1dCBjb3VsZCB5b3UgZXhwbGFpbiBtb3JlIGZ1bGx5IHRoaXMgY29t bWVudC4gDQoNClBGPj4gIElmIHlvdSdyZSB0cnlpbmcgdG8gbWVldCBSRkMgNTY1NCByZXEgNThi IGluIHBhcnRpY3VsYXIsIEkgd291bGQgDQp0aGluayB5b3UgTVVTVCB2YWxpZGF0ZSB0aGF0IGVu b3VnaCBwcm90ZWN0aW9uIHJlc291cmNlcyBhcmUgYXZhaWxhYmxlIChvciANCmFyZSBwcmVlbXB0 aWJsZSkgdG8gY2FycnkgMTAwJSBvZiB0aGUgc2VydmljZSB0cmFmZmljIHRoYXQgaXMgYmVpbmcg DQpyZXN0b3JlZC4gIEluIGV4aXN0aW5nIHRyYW5zcG9ydCBuZXR3b3JrcyAoaS5lLiBPVE4gLyBz b25ldCksIHRoaXMgaXMgDQp0eXBpY2FsbHkgZG9uZSBiZWZvcmUgeW91IHN3aXRjaCB0cmFmZmlj IHRvIHRoZSBwcm90ZWN0aW9uIHBhdGguICBGcm9tIGEgDQpzb2x1dGlvbiBwZXJzcGVjdGl2ZSwg SSB0aGluayB5b3UnbGwgcHJvYmFibHkgd2FudCB0byBsZXZlcmFnZSBzb21ldGhpbmcgDQpsaWtl IHRoZSBsb2NraW5nIG1vZGUgdGhhdCBpcyBiZWluZyBwcm9wb3NlZCBmb3IgdGhlIDE6biBkcmFm dC4gDQoNCi0gTml0OiB5b3UgbWlnaHQgd2FudCB0byBhdm9pZCB1c2luZyB0aGUgInF1ZXJ5IiB2 ZXJiIGluIHRoZSB0aXRsZSBvZiANCjQuMS4xIGJlY2F1c2UgaXQgc3VidGx5IHN1Z2dlc3RzIHNv bWUga2luZCBvZiBwcm90b2NvbCBtZXNzYWdpbmcgaXMgDQpyZXF1aXJlZC4gIEkgd291bGQgdXNl IHRoZSBtb3JlIGdlbmVyaWMgdmVyYiAiY2hlY2tpbmciIG9yICJ2ZXJpZnlpbmciLiANCnl3Pj4g U291bmRzIE9LIHRvIG1lLiANCi0gSW4gNC4zLCB0aGVyZSBpcyBubyBzdWdnZXN0aW9uIGZvciB3 aGF0IHNob3VsZCBoYXBwZW4gaWYgb25lIG9yIG1vcmUgDQpmYWlsaW5nIHBhdGhzIGluIGFuIE1Q TFMtVFAgbmV0d29yayBhcmUgb2YgZXF1YWwgcHJpb3JpdHkuICBJIHByZXN1bWUgaXQgDQp3aWxs IGJlIHNvbWUga2luZCBvZiBmaXJzdC1jb21lLCBmaXJzdC1zZXJ2ZSByZXF1aXJlbWVudCBidXQg dGhpcyB3aWxsIA0KYnJpbmcgdXAgdGhlIHF1ZXN0aW9uIG9mIGhvdyB0byBicmVhayB0aWVzLiAN Cnl3Pj4gVGhpcyBjb3VsZCBiZSByZXNvbHZlZCBhbG9uZyB0aGUgbGluZXMgdGhhdCBpdCB3YXMg YWRkcmVzc2VkIGluIHRoZSANCjE6biBwcm90ZWN0aW9uIA0KDQpQRj4+IEV4Y2VwdCB0aGF0IHlv dSBndXlzIHJlbW92ZWQgc2VwYXJhdGUgcGF0aCBwcmlvcml0eSBmcm9tIHRoZSBsYXRlc3QgDQp2 ZXJzaW9uIG9mIHRoZSAxOm4gZHJhZnQuICBJbiB0aGUgbGF0ZXN0IHZlcnNpb24sIGVhY2ggcGF0 aCBoYXMgYSBzdHJpY3QgDQpwcmlvcml0eSBkZWZpbmVkIGJ5IGl0cyBwYXRoIElEIHNvIHRpZXMg d2VyZSBub3QgcG9zc2libGUuICBJIGRvbid0IHRoaW5rIA0KdGhhdCBzb2x1dGlvbiB3aWxsIHdv cmsgZm9yIFNNUCBiZWNhdXNlIEkgaGF2ZSBhIGhhcmQgdGltZSBzZWVpbmcgaG93IGFsbCANCnRo ZSB2YXJpb3VzIGVuZHBvaW50cyBpbnZvbHZlZCBpbiBhIHNoYXJlZCBtZXNoIGNvdWxkIGNvb3Jk aW5hdGUgDQpub24tb3ZlcmxhcHBpbmcgcGF0aCBJRHMsIHdoaWxlIGF0IHRoZSBzYW1lIHRpbWUg bm90IGV4Y2VlZGluZyB0aGUgbGltaXQgDQpvZiAyNTUgcGF0aCBJRHMuIA0KDQoNCi0gQWxzbyBp biA0LjMsIHRoZXJlIGlzIGFuIGFsbG93YW5jZSBmb3IgYSBoaWdoIHByaW9yaXR5IHBhdGggYW5k IGEgbG93ZXIgDQpwcmlvcml0eSBwYXRoIHRvIHRlbXBvcmFyaWx5IHNoYXJlIHRoZSBwcm90ZWN0 aW9uIHJlc291cmNlcyB3aGlsZSANCnByZWVtcHRpb24gaXMgdGFraW5nIHBsYWNlLiAgVHdvIHF1 ZXN0aW9uczogDQotIElzIHRoZSBpbmdyZXNzIG5vZGUgdG8gdGhlIHNoYXJlZCBzZWdtZW50IGV4 cGVjdGVkIHRvIGRpc2NhcmQgZXhjZXNzIA0KdHJhZmZpYyBub3cgdGhhdCB0aGUgcHJvdGVjdGlv bi1wYXRoIGlzIHRlbXBvcmFyaWx5IG92ZXJzdWJzY3JpYmVkPyANCnl3Pj4gdGhpcyB3b3VsZCBt b3N0IHByb2JhYmx5IGZvbGxvdyBzdGFuZGFyZCBNUExTIGJlaGF2aW9yIGFzIGRlc2NyaWJlZCAN CmVsc2V3aGVyZSANCg0KUEY+PiBJIGd1ZXNzIEknbGwgYXNrIHdoYXQgaXMgdGhlIHN0YW5kYXJk IGJlaGF2aW91cj8gIEFuZCBpcyBpdCANCmFwcGxpY2FibGUgdG8gTVBMUy1UUCBuZXR3b3Jrcz8g DQogDQotIElmIG5vdCwgaG93IGRvIHdlIGVuc3VyZSB0aGF0IG90aGVyIHRyYW5zcG9ydCBwYXRo cyBhcmUgdW5hZmZlY3RlZD8gDQotIFRoZSBmaXJzdCBwYXJhZ3JhcGggb2YgNC40IGFwcGVhcnMg dG8gY29udHJhZGljdCA0LjEuMS4gIDQuNCBzZWVtcyB0byANCnN1Z2dlc3QgdGhhdCBvbmUgTVVT VCBzd2l0Y2ggdGhlIHRyYWZmaWMgb250byB0aGUgcHJvdGVjdGlvbiBwYXRoIGZpcnN0IA0KYW5k IHRoZW4gZ2V0IG5vdGlmaWVkIGlmIHRoZXJlJ3Mgbm90IGVub3VnaCByZXNvdXJjZXMuICBUaGF0 J3MgcHJvYmFibHkgDQpva2F5IGluIHRoZSBnZW5lcmFsIGNhc2UuICBCdXQgaW4gYW4gTVBMUy1U UCBuZXR3b3JrLCBJIGRvbid0IHRoaW5rIGl0J3MgYSANCmdvb2QgaWRlYSB0byBibGluZGx5IHN3 aXRjaCBsb3cgcHJpb3JpdHkgdHJhZmZpYyBvbnRvIHRoZSBwcm90ZWN0aW9uIHBhdGggDQphbmQg cG9zc2libHkgZGlzcnVwdCBhIGhpZ2ggcHJpb3JpdHkgcGF0aCB0aGF0IGlzIGFscmVhZHkgdXNp bmcgdGhhdCANCnJlc291cmNlLiANCnl3Pj4gVGhpcyBpcyBkZXBlbmRlbnQgdXBvbiB0aGUgYWN0 dWFsIG1lY2hhbmlzbSB0aGF0IGlzIGRldmVsb3BlZCBieSB0aGUgDQpXRy4gIEZvciBleGFtcGxl LCBvbmUgc3VnZ2VzdGlvbiBmb3IgdGhlIG1lY2hhbmlzbSBoYXMgbm90aWZpY2F0aW9ucyBzZW50 IA0KdG8gbG93ZXIgcHJpb3JpdHkgd29ya2luZyBwYXRocyBtYWtpbmcgdGhlIHByb3RlY3Rpb24g cGF0aCB1bmF2YWlsYWJsZSBpZiANCml0IGlzIGluIHVzZSBieSBhIGhpZ2gtcHJpb3JpdHkgd29y a2luZyBwYXRoLiANCiANCi0gSW4gc2VjdGlvbiA0LjUsIHRoZXJlJ3MgYW4gYXR0ZW1wdCB0byBk ZWZpbmUgInByb3RlY3Rpb24gc3dpdGNoaW5nIHRpbWUiIA0KYXMgbm90IGluY2x1ZGluZyBwcmVl bXB0aW9uIHRpbWUuICBJIGRvbid0IHRoaW5rIGVuZC11c2VycyByZWFsbHkgY2FyZSANCmFib3V0 ICJwcm90ZWN0aW9uIHN3aXRjaGluZyB0aW1lIi4gIFRoZXkgY2FyZSBhYm91dCByZWNvdmVyeSB0 aW1lIGFuZCBJTU8sIA0KdGhhdCBzaG91bGQgYWxzbyBpbmNsdWRlIGZhdWx0IGRldGVjdGlvbiB0 aW1lIChhbHRob3VnaCBpdCBkb2Vzbid0IHBlciBSRkMgDQo1NjU0KSBhbmQgYW55IHByZWVtcHRp b24gdGltZS4gDQp5dz4+IHdlIGRvIHRyeSB0byB3b3JrIHdpdGhpbiB0aGUgYWNjZXB0ZWQgZGVm aW5pdGlvbnMgb2YgdGhlIElFVEYhIA0KDQpQRj4+IEkgZ3Vlc3MgdGhlcmUncyB0d28gc2VwYXJh dGUgY29tbWVudHMgaGVyZSB0aGF0IEkga2luZGEgY29uZmxhdGVkIA0KdG9nZXRoZXIuICBPbmUg d2FzIG1vcmUgb2YgYSBncmlwZTogd2h5IGRpZCB3ZSBleGNsdWRlIGZhdWx0IGRldGVjdGlvbiAN CnRpbWUgZnJvbSB0aGUgNTBtcyByZXN0b3JhdGlvbiB0aW1lIHJlcXVpcmVtZW50IGluIFJGQyA1 NjU0PyAgSSBrbm93IHRoYXQgDQpteSBjdXN0b21lcnMgbWVhc3VyZSBvbmx5IG9uZSB0aGluZzog aG93IG1hbnkgbXMgb2YgdHJhZmZpYyBkbyB0aGV5IGxvc2UgDQphZnRlciBhIGJyZWFrYWdlLiAg SSBkb24ndCBnZXQgYSBmcmVlIHBhc3Mgb24gdGhlIH4xMG1zIGl0IHRha2VzIGZvciBCRkQgDQp0 byBkZXRlY3QgdGhlIGZhaWx1cmUuICBBY2NvcmRpbmcgdG8gUkZDIDU2NTQsIEkgY291bGQgdXNl IDYwc2VjIENDTXMgYW5kIA0Kc3RpbGwgbWVldCB0aGUgNTBtcyByZXF1aXJlbWVudCEgDQoNClRo ZSAybmQgY29tbWVudCB3YXMgcmVhbGx5IGFib3V0IHRoaXMgZHJhZnQgbm93IHRyeWluZyB0byBl eGNsdWRlIA0KcHJlZW1wdGlvbiB0aW1lIGZyb20gcmVzdG9yYXRpb24gdGltZSBhcyB3ZWxsLiAg SU1PLCBpZiBpdCB0YWtlcyBhIGZldyANCnNlY29uZHMgZm9yIGEgaGlnaCBwcmlvcml0eSBzZXJ2 aWNlIHRvIGZpbmlzaCBwcmVlbXB0aW5nIGEgbG93ZXIgcHJpb3JpdHkgDQpzZXJ2aWNlLCB0aGVu IHdlIGhhdmVuJ3QgbWV0IHRoZSA1MG1zIHJlc3RvcmF0aW9uIHRpbWUgcmVxdWlyZW1lbnQuIA0K RXNwZWNpYWxseSBzaW5jZSBpdCdzIHR5cGljYWxseSBteSBoaWdoZXIgcHJpb3JpdHkgc2Vydmlj ZXMgdGhhdCB3YW50IDUwbXMgDQpyZXN0b3JhdGlvbiB0aW1lcyBpbiB0aGUgZmlyc3QgcGxhY2Us IHNvIHRoZXknbGwgYmUgbW9yZSBvZnRlbiBpbiBhIA0KcG9zaXRpb24gdG8gcHJlZW1wdC4gIElu IG90aGVyIHdvcmRzLCBJIHRoaW5rIHdlIHdhbnQgcHJlZW1wdGlvbiB0byBiZSANCmZhc3QgYW5k IGlzIGEgY3JpdGljYWwgY29tcG9uZW50IG9mIHByb3RlY3Rpb24gc3dpdGNoaW5nLiANCiANCg0K cmVnYXJkcywgDQpQYWJsbyANCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0Bp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg0K --=_alternative 000FA3B248257A68_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIERhdmU8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlNvcnJ5IGZvciB0aGUgZGVsYXll ZCByZXNwb25zZSwgc2VlDQpteSBub3RlcyB0YWdnZWQgd2l0aCAmbHQ7ZmVpJmd0OzwvZm9udD4N Cjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5GZWk8L2ZvbnQ+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0K PHRkIHdpZHRoPTM2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+RGF2aWQgQWxs YW4gSSAmbHQ7ZGF2aWQuaS5hbGxhbkBlcmljc3Nvbi5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPHA+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTItMDgtMjIgMDE6Mjk8L2ZvbnQ+DQo8 dGQgd2lkdGg9NjMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N CjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7Iyzwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7emhh bmcuZmVpM0B6dGUuY29tLmNuJnF1b3Q7ICZsdDt6aGFuZy5mZWkzQHp0ZS5jb20uY24mZ3Q7LA0K R3JlZ29yeSBNaXJza3kgJmx0O2dyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbSZndDs8L2ZvbnQ+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPiZxdW90O21wbHNAaWV0Zi5vcmcmcXVvdDsgJmx0O21wbHNAaWV0Zi5vcmcm Z3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SRTogW21wbHNdIENvbW1lbnRzIG9uIGRyYWZ0LXdlaW5n YXJ0ZW4tbXBscy1zbXAtcmVxdWlyZW1lbnRzLTAwLnR4dDwvZm9udD48L3RhYmxlPg0KPGJyPg0K PHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxl Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj5I aSBGZWk6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPkkgc2VlICZx dW90O2EmcXVvdDsgcHJvcG9zZWQgc29sdXRpb24NCmluIHRoZSBkcmFmdCB5b3UgcmVmZXJlbmNl LCBidXQgbm90IGEgcHJvYmxlbSBzdGF0ZW1lbnQgb3IgYW5hbHN5c2lzPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+Jmx0O2ZlaSZndDsgJm5ic3A7VGhlIHByb3Bv c2VkIHNvbHV0aW9uIGlzDQpiYXNlIG9uIHRoZSBjb250cm9sIHBsYW5lIGV4dGVuc2lvbnMsIGFu ZCB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgc2FpZCAmcXVvdDsNCltSRkM0ODcyXSBkZWZpbmVzIHRo ZSBzaGFyZWQgbWVzaCByZXN0b3JhdGlvbiBzY2hlbWVzIGJhc2VkIG9uPGJyPg0KICZuYnNwOyBj b250cm9sIHBsYW5lIGV4dGVuc2lvbnMsIGJ1dCBkb2VzIG5vdCBjb3ZlciB0aGUgc2hhcmVkIG1l c2ggJm5ic3A7cHJvdGVjdGlvbg0Kc2NlbmFyaW9zLiZxdW90OzwvZm9udD4NCjxicj48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBj b2xvcj1ibHVlIGZhY2U9IkFyaWFsIj5UaGUgcHJlZW1wdGlvbiBjb3VsZCBzaW1wbHkgYmUNCnBl cmZvcm1lZCBhdCBub2RlIEUuIEN1cnJlbnRseSB0aGUgbW9kZWwgaXMgdGhhdCB0aGUgTEVScyBu ZWVkIHRvIG5vdGlmeQ0Kbm9kZSBFIHdoZW4gdGhlIFAgcGF0aCBpcyBiZWluZyB1c2VkLCBhbmQg RSBuZWVkcyB0byBub3RpZnkgdGhlIExFUnMgb2YNCnRoZSBjdXJyZW50IHN0YXRlIG9mIHRoZSBz aGFyZWQgcmVzb3VyY2UuICZuYnNwO1RoaXMgYXBwZWFycyB0byBkZXBlbmQNCm9uIHRoZSBwcmVl bXB0ZWQgTFNSIHRvICZxdW90O2RvIHRoZSByaWdodCB0aGluZyZxdW90OyBhbmQgbGVhZHMgdG8g YW4NCklNTyB1bnJlYXNvbmFibGUgd2luZG93IG9mIGNvbnRlbnRpb24gZm9yIHRoZSBzaGFyZWQg cmVzb3VyY2VzLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPiZu YnNwOyAmbHQ7ZmVpJmd0OyBQcmVlbXB0aW9uIG1lYW5zIHRoYXQNCiZuYnNwO3RoZXJlIHdpbGwg YmUgYSB3aW5kb3cgb2YgY29udGVudGlvbiwgd2h5IGl0IGlzIHVucmVhc29uYWJsZT88L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPklNTyBFIHNo b3VsZCBiZSBkb2luZyB0aGUgcHJlZW1wdGlvbiwNCmFuZCBJJ3ZlIHN0aWxsIG5vdCByZWFsbHkg c2VlbiBhIG5lZWQgZm9yIGhlYWQgZW5kIG5vdGlmaWNhdGlvbiBvZiBwcmVlbXB0aW9uDQp1bmxl c3Mgb25lIHN0YXJ0cyBwbGFubmluZyBiYWNrdXBzIGZvciBiYWNrdXBzLjwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPiZuYnNwOyAmbHQ7ZmVpJmd0OyBJTUhPLCB0 aGVyZSBhcmUgdHdvIHByaW9yaXRpZXMNCm5lZWQgdG8gYmUgaGFuZGxlZCBpbiBzaGFyZWQgbWVz aCBwcm90ZWN0aW9uIHNjZW5hcmlvcywgdGhlIHBhdGggcHJpb3JpdHkNCmFuZCB0aGUgc2Vydmlj ZSBwcmlvcml0eSAoUEhCKS4gSWYgbm9kZSBFIGRvZXMgdGhlIHByZWVtcHRpb24sIGhvdyB0byA8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj5kZWFsIHdpdGggdGhlIHBhdGgg cHJpb3JpdHksIHdoaWNoIGlzIG5vdA0KY2FycmllZCBpbiB0cmFmZmljIHBhY2tldC4gPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPklmIHlvdSBoYXZlIG1vcmUgaW5m b3JtYXRpb24sDQpjb3VsZCB5b3UgZWxhYm9yYWJsZT88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPkRhdmU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPg0KPGJyPg0KPGhyPjxmb250IHNpemU9MiBmYWNl PSJUYWhvbWEiPjxiPkZyb206PC9iPiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxz LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPnpoYW5nLmZlaTNAenRlLmNv bS5jbjxiPjxicj4NClNlbnQ6PC9iPiBNb25kYXksIEF1Z3VzdCAyMCwgMjAxMiA0OjAzIEFNPGI+ PGJyPg0KVG86PC9iPiBHcmVnb3J5IE1pcnNreTxiPjxicj4NCkNjOjwvYj4gbXBsc0BpZXRmLm9y ZzsgbXBscy1ib3VuY2VzQGlldGYub3JnPGI+PGJyPg0KU3ViamVjdDo8L2I+IFJlOiBbbXBsc10g Q29tbWVudHMgb24gZHJhZnQtd2VpbmdhcnRlbi1tcGxzLXNtcC1yZXF1aXJlbWVudHMtMDAudHh0 PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkdyZWcsIHNuaXBwZWQ8L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+DQo8dWw+DQo8bGk+PGZvbnQg c2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPkluIHRoZSBsYXN0IHNlbnRlbmNlIG9mIFNl Y3Rpb24NCjMuMSBub24tY29udHJvbCBwbGFuZSBjb29yZGluYXRpb24gb2Ygc2hhcmVkIHJlc291 cmNlcyBwcmVzZW50ZWQgYXMgYW5vdGhlcg0KcmVxdWlyZW1lbnQuIEFuZCBhZ2FpbiBJIGNhbiBu b3QgZmluZCBob3cgd2UgY29tZSB0byBzdWNoIGNvbmNsdXNpb24sIHdoZXJlDQp0aGUgc291cmNl IG9mIHRoaXMgcmVxdWlyZW1lbnQuIFdvdWxkIGV4aXN0aW5nIGNvbnRyb2wgcGxhbmUgc2lnbmFs aW5nDQpzb2x1dGlvbiBiZSBzdWZmaWNpZW50IGZvciBhIE1QTFMgbmV0d29yaz8gPC9mb250Pjwv dWw+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCiZsdDtGZWkmZ3Q7IEkgZG8g bm90IHRoaW5rIHRoZSBleGlzdGluZyBjb250cm9sIHBsYW5lIChkZWZpbmVkIGluIFJGQzQ4NzIp DQppcyBzdWZmaWNpZW50IGZvciBhIE1QTFMgbmV0d29yaywgYW5kIHRoZXJlIGlzIGFuIGFuYWx5 c2lzIGluIHRoZSBkcmFmdA0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGUtY2Nh bXAtbm90aWZpY2F0aW9uLXNoYXJlZC1tZXNoLXByb3RlY3Rpb24tMDAuDQo8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KQmVzdCByZWdhcmRzPC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj48YnI+DQpGZWk8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+ DQo8YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkIHdpZHRoPTM5JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+R3JlZ29y eSBNaXJza3kgJmx0O2dyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbSZndDs8L2I+DQo8YnI+DQq3 orz+yMs6ICZuYnNwO21wbHMtYm91bmNlc0BpZXRmLm9yZzwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+MjAxMi0wOC0xNiAwNjo0NTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ DQo8L2ZvbnQ+DQo8dGQgd2lkdGg9NjAlPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZCB3aWR0aD03JT4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZCB3aWR0aD05MiU+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlBhYmxvIEZyYW5rICZsdDtwYWJsb2lzbm90QGdt YWlsLmNvbSZndDssDQpZYWFjb3YgV2VpbmdhcnRlbiAmbHQ7d3lhYWNvdkBnbWFpbC5jb20mZ3Q7 PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+JnF1b3Q7bXBsc0BpZXRmLm9yZyZxdW90OyAmbHQ7bXBsc0BpZXRmLm9yZyZndDs8L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W 98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTog W21wbHNdIENvbW1lbnRzIG9uIGRyYWZ0LXdlaW5nYXJ0ZW4tbXBscy1zbXAtcmVxdWlyZW1lbnRz LTAwLnR4dDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD01MCU+DQo8dGQgd2lkdGg9NTAlPjwvdGFibGU+DQo8 YnI+PC90YWJsZT4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJy Pg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48YnI+DQpEZWFy IFBhYmxvLCBZYWFjb3YsIGV0IGFsLiw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjxicj4NCkkn dmUgYmVlbiBmb2xsb3dpbmcgZGlzY3Vzc2lvbiB3aXRoIGdyZWF0IGRlYWwgb2YgaW50ZXJlc3Qu IEkgaGF2ZSBzb21lDQpxdWVzdGlvbnMgaW4gYWRkaXRpb24gdG8gb25lcyBiZWluZyBicm91Z2h0 IHVwIGJ5IFBhYmxvOjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2Zv bnQ+DQo8dWw+DQo8bGk+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPlNlY3Rp b24gMS4yIHJlZmVycyB0byBvcGVyYXRvcidzDQpkZXNpcmUgdG8gaGF2ZSBzZXJ2aWNlIHJlc3Rv cmF0aW9uIG1vcmUgZXhwZWRpZW50IHRoYW4gb25lIGFjaGlldmFibGUgd2l0aA0KY29udHJvbCBw bGFuZS4gSSBoYXZlbid0IHNlZW4gYW55IHF1YW50YXRpdmUgaW5mb3JtYXRpb24gdG8gY29tcGFy ZSB3aXRoLg0KV2hhdCBpcyAmcXVvdDtleHBlZGllbnQgZW5vdWdoJnF1b3Q7IGZvciBTTVA/PC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjxsaT48Zm9udCBz aXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+U2VjdGlvbiAzLjEgZGVzcmNpYmVzLCB3aGF0 IGNhbg0KYmUgY2FsbGVkLCAmcXVvdDtpbnN0YW50IGRldGVybWluaXNtJnF1b3Q7IGluIHJlZ2Fy ZCB0byBTTVAgcmVzb3VyY2UgYXZhaWFsYWJpbGl0eS4NCkkgdGhpbmsgdGhhdCB0aGVyZSdzIG5v dCBlbm91Z2ggcmVhc29uaW5nIHRvIGNvbmNsdWRlIHRoYXQgYWxtb3N0IGluc3RhbnRlbmVvdXMN CnVwZGF0ZSBvZiBTTVAgcmVzb3VyY2VzIGF2YWlhbGFiaWxpdHkgaXMgcmVxdWlyZWQuPC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjxsaT48Zm9udCBzaXpl PTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+SW4gdGhlIGxhc3Qgc2VudGVuY2Ugb2YgU2VjdGlv bg0KMy4xIG5vbi1jb250cm9sIHBsYW5lIGNvb3JkaW5hdGlvbiBvZiBzaGFyZWQgcmVzb3VyY2Vz IHByZXNlbnRlZCBhcyBhbm90aGVyDQpyZXF1aXJlbWVudC4gQW5kIGFnYWluIEkgY2FuIG5vdCBm aW5kIGhvdyB3ZSBjb21lIHRvIHN1Y2ggY29uY2x1c2lvbiwgd2hlcmUNCnRoZSBzb3VyY2Ugb2Yg dGhpcyByZXF1aXJlbWVudC4gV291bGQgZXhpc3RpbmcgY29udHJvbCBwbGFuZSBzaWduYWxpbmcN CnNvbHV0aW9uIGJlIHN1ZmZpY2llbnQgZm9yIGEgTVBMUyBuZXR3b3JrPzwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8bGk+PGZvbnQgc2l6ZT0yIGNvbG9y PWJsdWUgZmFjZT0iQXJpYWwiPkkndmUgbm90aWNlZCB0aGF0IG1hbnkgcmVxdWlyZW1lbnRzDQpi ZWluZyByZWZlcnJlZCB0byBNUExTLVRQLCBub3QgTVBMUywgbmV0d29ya3MuIFdvdWxkIHRoYXQg YmUgYSBnb29kIHJlYXNvbg0KdG8gbmFycm93IHNjb3BlIG9mIHRoZSBkb2N1bWVudCB0byBNUExT LVRQIG5ldHdvcmtzIG9ubHksIHN0YXJ0aW5nIHdpdGgNCnRoZSBuYW1lIG9mIHRoZSBkb2N1bWVu dD88L2ZvbnQ+PC91bD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+Jm5ic3A7 DQombmJzcDsgUmVnYXJkcyw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8 YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xv cj1ibHVlIGZhY2U9IkFyaWFsIj5HcmVnPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj4NCjxicj4NCjxicj4NCjwvZm9udD4NCjxocj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21h Ij48Yj5Gcm9tOjwvYj4gbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2Vz QGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5QYWJsbyBGcmFuazxiPjxicj4NClNlbnQ6 PC9iPiBGcmlkYXksIEF1Z3VzdCAxMCwgMjAxMiA3OjIzIEFNPGI+PGJyPg0KVG86PC9iPiBZYWFj b3YgV2VpbmdhcnRlbjxiPjxicj4NCkNjOjwvYj4gbXBsc0BpZXRmLm9yZzxiPjxicj4NClN1Ympl Y3Q6PC9iPiBSZTogW21wbHNdIENvbW1lbnRzIG9uIGRyYWZ0LXdlaW5nYXJ0ZW4tbXBscy1zbXAt cmVxdWlyZW1lbnRzLTAwLnR4dDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ PGJyPg0KPGJyPg0KSGkgWWFhY292LCA8YnI+DQo8YnI+DQpTb21lIG1vcmUgY29tbWVudHMgaW5s aW5lLi4uIFBGJmd0OyZndDs8YnI+DQo8YnI+DQpPbiBNb24sIEF1ZyA2LCAyMDEyIGF0IDg6NTYg QU0sIFlhYWNvdiBXZWluZ2FydGVuICZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86d3lhYWNvdkBn bWFpbC5jb20gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5z LXNlcmlmIj48dT53eWFhY292QGdtYWlsLmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4mZ3Q7DQp3cm90ZTogPGJyPg0KSGksIDxicj4NCjxicj4NClRoYW5r IHlvdSBmb3IgeW91ciBjb21tZW50cy4gJm5ic3A7UGxlYXNlIHNlZSBteSBjb21tZW50cyBpbmxp bmUgYmVsb3cuDQo8YnI+DQo8YnI+DQpCUiwgPGJyPg0KeWFhY292PGJyPg0KPGJyPg0KT24gVHVl LCBKdWwgMTcsIDIwMTIgYXQgMTE6NTEgUE0sIFBhYmxvIEZyYW5rICZsdDs8L2ZvbnQ+PGEgaHJl Zj1tYWlsdG86cGFibG9pc25vdEBnbWFpbC5jb20gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMg Y29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5wYWJsb2lzbm90QGdtYWlsLmNvbTwvdT48 L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7DQp3cm90ZTogPGJy Pg0KR29vZCBkcmFmdCBhbmQgY2VydGFpbmx5IHNvbWV0aGluZyB0aGF0IG5lZWRzIHRvIGJlIGRv bmUgYmVmb3JlIHdlIGNhbg0Kc3RhcnQgZGlzY3Vzc2luZyBzcGVjaWZpYyBzb2x1dGlvbnMuIDxi cj4NCjxicj4NCk9ubHkgYSBmZXcgY29tbWVudHMgLyBxdWVzdGlvbnM6IDxicj4NCjxicj4NCi0g SW4gNC4xLjEsIGlmIG9uZSBpcyBvcGVyYXRpbmcgaW4gYW4gTVBMUy1UUCBuZXR3b3JrIHRoYXQg cmVxdWlyZXMgZXhjbHVzaXZlDQp1c2Ugb2YgdGhlIHByb3RlY3Rpb24gcmVzb3VyY2VzLCBkb2Vz bid0IHRoaXMgU0hPVUxEIHJlcXVpcmVtZW50IGJlY29tZQ0KYSBNVVNUIHJlcXVpcmVtZW50PyA8 YnI+DQo8YnI+DQp5dyZndDsmZ3Q7IFNvcnJ5IC0gYnV0IGNvdWxkIHlvdSBleHBsYWluIG1vcmUg ZnVsbHkgdGhpcyBjb21tZW50LiA8YnI+DQo8YnI+DQpQRiZndDsmZ3Q7ICZuYnNwO0lmIHlvdSdy ZSB0cnlpbmcgdG8gbWVldCBSRkMgNTY1NCByZXEgNThiIGluIHBhcnRpY3VsYXIsDQpJIHdvdWxk IHRoaW5rIHlvdSBNVVNUIHZhbGlkYXRlIHRoYXQgZW5vdWdoIHByb3RlY3Rpb24gcmVzb3VyY2Vz IGFyZSBhdmFpbGFibGUNCihvciBhcmUgcHJlZW1wdGlibGUpIHRvIGNhcnJ5IDEwMCUgb2YgdGhl IHNlcnZpY2UgdHJhZmZpYyB0aGF0IGlzIGJlaW5nDQpyZXN0b3JlZC4gJm5ic3A7SW4gZXhpc3Rp bmcgdHJhbnNwb3J0IG5ldHdvcmtzIChpLmUuIE9UTiAvIHNvbmV0KSwgdGhpcw0KaXMgdHlwaWNh bGx5IGRvbmUgYmVmb3JlIHlvdSBzd2l0Y2ggdHJhZmZpYyB0byB0aGUgcHJvdGVjdGlvbiBwYXRo LiAmbmJzcDtGcm9tDQphIHNvbHV0aW9uIHBlcnNwZWN0aXZlLCBJIHRoaW5rIHlvdSdsbCBwcm9i YWJseSB3YW50IHRvIGxldmVyYWdlIHNvbWV0aGluZw0KbGlrZSB0aGUgbG9ja2luZyBtb2RlIHRo YXQgaXMgYmVpbmcgcHJvcG9zZWQgZm9yIHRoZSAxOm4gZHJhZnQuIDxicj4NCjxicj4NCi0gTml0 OiB5b3UgbWlnaHQgd2FudCB0byBhdm9pZCB1c2luZyB0aGUgJnF1b3Q7cXVlcnkmcXVvdDsgdmVy YiBpbiB0aGUNCnRpdGxlIG9mIDQuMS4xIGJlY2F1c2UgaXQgc3VidGx5IHN1Z2dlc3RzIHNvbWUg a2luZCBvZiBwcm90b2NvbCBtZXNzYWdpbmcNCmlzIHJlcXVpcmVkLiAmbmJzcDtJIHdvdWxkIHVz ZSB0aGUgbW9yZSBnZW5lcmljIHZlcmIgJnF1b3Q7Y2hlY2tpbmcmcXVvdDsNCm9yICZxdW90O3Zl cmlmeWluZyZxdW90Oy4gPGJyPg0KeXcmZ3Q7Jmd0OyBTb3VuZHMgT0sgdG8gbWUuIDxicj4NCi0g SW4gNC4zLCB0aGVyZSBpcyBubyBzdWdnZXN0aW9uIGZvciB3aGF0IHNob3VsZCBoYXBwZW4gaWYg b25lIG9yIG1vcmUNCmZhaWxpbmcgcGF0aHMgaW4gYW4gTVBMUy1UUCBuZXR3b3JrIGFyZSBvZiBl cXVhbCBwcmlvcml0eS4gJm5ic3A7SSBwcmVzdW1lDQppdCB3aWxsIGJlIHNvbWUga2luZCBvZiBm aXJzdC1jb21lLCBmaXJzdC1zZXJ2ZSByZXF1aXJlbWVudCBidXQgdGhpcyB3aWxsDQpicmluZyB1 cCB0aGUgcXVlc3Rpb24gb2YgaG93IHRvIGJyZWFrIHRpZXMuIDxicj4NCnl3Jmd0OyZndDsgVGhp cyBjb3VsZCBiZSByZXNvbHZlZCBhbG9uZyB0aGUgbGluZXMgdGhhdCBpdCB3YXMgYWRkcmVzc2Vk DQppbiB0aGUgMTpuIHByb3RlY3Rpb24gPGJyPg0KPGJyPg0KUEYmZ3Q7Jmd0OyBFeGNlcHQgdGhh dCB5b3UgZ3V5cyByZW1vdmVkIHNlcGFyYXRlIHBhdGggcHJpb3JpdHkgZnJvbSB0aGUNCmxhdGVz dCB2ZXJzaW9uIG9mIHRoZSAxOm4gZHJhZnQuICZuYnNwO0luIHRoZSBsYXRlc3QgdmVyc2lvbiwg ZWFjaCBwYXRoDQpoYXMgYSBzdHJpY3QgcHJpb3JpdHkgZGVmaW5lZCBieSBpdHMgcGF0aCBJRCBz byB0aWVzIHdlcmUgbm90IHBvc3NpYmxlLg0KJm5ic3A7SSBkb24ndCB0aGluayB0aGF0IHNvbHV0 aW9uIHdpbGwgd29yayBmb3IgU01QIGJlY2F1c2UgSSBoYXZlIGEgaGFyZA0KdGltZSBzZWVpbmcg aG93IGFsbCB0aGUgdmFyaW91cyBlbmRwb2ludHMgaW52b2x2ZWQgaW4gYSBzaGFyZWQgbWVzaCBj b3VsZA0KY29vcmRpbmF0ZSBub24tb3ZlcmxhcHBpbmcgcGF0aCBJRHMsIHdoaWxlIGF0IHRoZSBz YW1lIHRpbWUgbm90IGV4Y2VlZGluZw0KdGhlIGxpbWl0IG9mIDI1NSBwYXRoIElEcy4gPGJyPg0K PGJyPg0KPGJyPg0KLSBBbHNvIGluIDQuMywgdGhlcmUgaXMgYW4gYWxsb3dhbmNlIGZvciBhIGhp Z2ggcHJpb3JpdHkgcGF0aCBhbmQgYSBsb3dlcg0KcHJpb3JpdHkgcGF0aCB0byB0ZW1wb3Jhcmls eSBzaGFyZSB0aGUgcHJvdGVjdGlvbiByZXNvdXJjZXMgd2hpbGUgcHJlZW1wdGlvbg0KaXMgdGFr aW5nIHBsYWNlLiAmbmJzcDtUd28gcXVlc3Rpb25zOiA8YnI+DQotIElzIHRoZSBpbmdyZXNzIG5v ZGUgdG8gdGhlIHNoYXJlZCBzZWdtZW50IGV4cGVjdGVkIHRvIGRpc2NhcmQgZXhjZXNzDQp0cmFm ZmljIG5vdyB0aGF0IHRoZSBwcm90ZWN0aW9uLXBhdGggaXMgdGVtcG9yYXJpbHkgb3ZlcnN1YnNj cmliZWQ/IDxicj4NCnl3Jmd0OyZndDsgdGhpcyB3b3VsZCBtb3N0IHByb2JhYmx5IGZvbGxvdyBz dGFuZGFyZCBNUExTIGJlaGF2aW9yIGFzIGRlc2NyaWJlZA0KZWxzZXdoZXJlIDxicj4NCjxicj4N ClBGJmd0OyZndDsgSSBndWVzcyBJJ2xsIGFzayB3aGF0IGlzIHRoZSBzdGFuZGFyZCBiZWhhdmlv dXI/ICZuYnNwO0FuZCBpcw0KaXQgYXBwbGljYWJsZSB0byBNUExTLVRQIG5ldHdvcmtzPyA8YnI+ DQogJm5ic3A7PGJyPg0KLSBJZiBub3QsIGhvdyBkbyB3ZSBlbnN1cmUgdGhhdCBvdGhlciB0cmFu c3BvcnQgcGF0aHMgYXJlIHVuYWZmZWN0ZWQ/IDxicj4NCi0gVGhlIGZpcnN0IHBhcmFncmFwaCBv ZiA0LjQgYXBwZWFycyB0byBjb250cmFkaWN0IDQuMS4xLiAmbmJzcDs0LjQgc2VlbXMNCnRvIHN1 Z2dlc3QgdGhhdCBvbmUgTVVTVCBzd2l0Y2ggdGhlIHRyYWZmaWMgb250byB0aGUgcHJvdGVjdGlv biBwYXRoIGZpcnN0DQphbmQgdGhlbiBnZXQgbm90aWZpZWQgaWYgdGhlcmUncyBub3QgZW5vdWdo IHJlc291cmNlcy4gJm5ic3A7VGhhdCdzIHByb2JhYmx5DQpva2F5IGluIHRoZSBnZW5lcmFsIGNh c2UuICZuYnNwO0J1dCBpbiBhbiBNUExTLVRQIG5ldHdvcmssIEkgZG9uJ3QgdGhpbmsNCml0J3Mg YSBnb29kIGlkZWEgdG8gYmxpbmRseSBzd2l0Y2ggbG93IHByaW9yaXR5IHRyYWZmaWMgb250byB0 aGUgcHJvdGVjdGlvbg0KcGF0aCBhbmQgcG9zc2libHkgZGlzcnVwdCBhIGhpZ2ggcHJpb3JpdHkg cGF0aCB0aGF0IGlzIGFscmVhZHkgdXNpbmcgdGhhdA0KcmVzb3VyY2UuIDxicj4NCnl3Jmd0OyZn dDsgVGhpcyBpcyBkZXBlbmRlbnQgdXBvbiB0aGUgYWN0dWFsIG1lY2hhbmlzbSB0aGF0IGlzIGRl dmVsb3BlZA0KYnkgdGhlIFdHLiAmbmJzcDtGb3IgZXhhbXBsZSwgb25lIHN1Z2dlc3Rpb24gZm9y IHRoZSBtZWNoYW5pc20gaGFzIG5vdGlmaWNhdGlvbnMNCnNlbnQgdG8gbG93ZXIgcHJpb3JpdHkg d29ya2luZyBwYXRocyBtYWtpbmcgdGhlIHByb3RlY3Rpb24gcGF0aCB1bmF2YWlsYWJsZQ0KaWYg aXQgaXMgaW4gdXNlIGJ5IGEgaGlnaC1wcmlvcml0eSB3b3JraW5nIHBhdGguIDxicj4NCiAmbmJz cDs8YnI+DQotIEluIHNlY3Rpb24gNC41LCB0aGVyZSdzIGFuIGF0dGVtcHQgdG8gZGVmaW5lICZx dW90O3Byb3RlY3Rpb24gc3dpdGNoaW5nDQp0aW1lJnF1b3Q7IGFzIG5vdCBpbmNsdWRpbmcgcHJl ZW1wdGlvbiB0aW1lLiAmbmJzcDtJIGRvbid0IHRoaW5rIGVuZC11c2Vycw0KcmVhbGx5IGNhcmUg YWJvdXQgJnF1b3Q7cHJvdGVjdGlvbiBzd2l0Y2hpbmcgdGltZSZxdW90Oy4gJm5ic3A7VGhleSBj YXJlDQphYm91dCByZWNvdmVyeSB0aW1lIGFuZCBJTU8sIHRoYXQgc2hvdWxkIGFsc28gaW5jbHVk ZSBmYXVsdCBkZXRlY3Rpb24gdGltZQ0KKGFsdGhvdWdoIGl0IGRvZXNuJ3QgcGVyIFJGQyA1NjU0 KSBhbmQgYW55IHByZWVtcHRpb24gdGltZS4gPGJyPg0KeXcmZ3Q7Jmd0OyB3ZSBkbyB0cnkgdG8g d29yayB3aXRoaW4gdGhlIGFjY2VwdGVkIGRlZmluaXRpb25zIG9mIHRoZSBJRVRGIQ0KPGJyPg0K PGJyPg0KUEYmZ3Q7Jmd0OyBJIGd1ZXNzIHRoZXJlJ3MgdHdvIHNlcGFyYXRlIGNvbW1lbnRzIGhl cmUgdGhhdCBJIGtpbmRhIGNvbmZsYXRlZA0KdG9nZXRoZXIuICZuYnNwO09uZSB3YXMgbW9yZSBv ZiBhIGdyaXBlOiB3aHkgZGlkIHdlIGV4Y2x1ZGUgZmF1bHQgZGV0ZWN0aW9uDQp0aW1lIGZyb20g dGhlIDUwbXMgcmVzdG9yYXRpb24gdGltZSByZXF1aXJlbWVudCBpbiBSRkMgNTY1ND8gJm5ic3A7 SSBrbm93DQp0aGF0IG15IGN1c3RvbWVycyBtZWFzdXJlIG9ubHkgb25lIHRoaW5nOiBob3cgbWFu eSBtcyBvZiB0cmFmZmljIGRvIHRoZXkNCmxvc2UgYWZ0ZXIgYSBicmVha2FnZS4gJm5ic3A7SSBk b24ndCBnZXQgYSBmcmVlIHBhc3Mgb24gdGhlIH4xMG1zIGl0IHRha2VzDQpmb3IgQkZEIHRvIGRl dGVjdCB0aGUgZmFpbHVyZS4gJm5ic3A7QWNjb3JkaW5nIHRvIFJGQyA1NjU0LCBJIGNvdWxkIHVz ZQ0KNjBzZWMgQ0NNcyBhbmQgc3RpbGwgbWVldCB0aGUgNTBtcyByZXF1aXJlbWVudCEgPGJyPg0K PGJyPg0KVGhlIDJuZCBjb21tZW50IHdhcyByZWFsbHkgYWJvdXQgdGhpcyBkcmFmdCBub3cgdHJ5 aW5nIHRvIGV4Y2x1ZGUgcHJlZW1wdGlvbg0KdGltZSBmcm9tIHJlc3RvcmF0aW9uIHRpbWUgYXMg d2VsbC4gJm5ic3A7SU1PLCBpZiBpdCB0YWtlcyBhIGZldyBzZWNvbmRzDQpmb3IgYSBoaWdoIHBy aW9yaXR5IHNlcnZpY2UgdG8gZmluaXNoIHByZWVtcHRpbmcgYSBsb3dlciBwcmlvcml0eSBzZXJ2 aWNlLA0KdGhlbiB3ZSBoYXZlbid0IG1ldCB0aGUgNTBtcyByZXN0b3JhdGlvbiB0aW1lIHJlcXVp cmVtZW50LiAmbmJzcDtFc3BlY2lhbGx5DQpzaW5jZSBpdCdzIHR5cGljYWxseSBteSBoaWdoZXIg cHJpb3JpdHkgc2VydmljZXMgdGhhdCB3YW50IDUwbXMgcmVzdG9yYXRpb24NCnRpbWVzIGluIHRo ZSBmaXJzdCBwbGFjZSwgc28gdGhleSdsbCBiZSBtb3JlIG9mdGVuIGluIGEgcG9zaXRpb24gdG8g cHJlZW1wdC4NCiZuYnNwO0luIG90aGVyIHdvcmRzLCBJIHRoaW5rIHdlIHdhbnQgcHJlZW1wdGlv biB0byBiZSBmYXN0IGFuZCBpcyBhIGNyaXRpY2FsDQpjb21wb25lbnQgb2YgcHJvdGVjdGlvbiBz d2l0Y2hpbmcuICZuYnNwOyA8YnI+DQogJm5ic3A7PGJyPg0KPGJyPg0KcmVnYXJkcywgPGJyPg0K UGFibG8gPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQptcGxzIG1haWxpbmcgbGlzdDwvZm9udD48Zm9udCBzaXplPTMg Y29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9 bWFpbHRvOm1wbHNAaWV0Zi5vcmcgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1 ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5tcGxzQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQg c2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+PGJyPg0KPC91PjwvZm9udD48 YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscyB0YXJnZXQ9 X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczwvdT48L2ZvbnQ+PC9hPjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQo8L2ZvbnQ+PHR0Pjxmb250IHNp emU9Mj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCm1wbHMgbWFpbGluZyBsaXN0PGJyPg0KbXBsc0BpZXRmLm9yZzxicj4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczwvZm9udD48L3R0Pjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+DQo8YnI+DQo= --=_alternative 000FA3B248257A68_=-- From david.i.allan@ericsson.com Mon Aug 27 22:48: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 BC47E21F841E for ; Mon, 27 Aug 2012 22:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.018 X-Spam-Level: X-Spam-Status: No, score=-4.018 tagged_above=-999 required=5 tests=[AWL=-1.623, 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 M9A0E4mmVl2B for ; Mon, 27 Aug 2012 22:48:26 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id D67E721F843E for ; Mon, 27 Aug 2012 22:48:25 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q7S5oFXZ011297; Tue, 28 Aug 2012 00:50:16 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.2.164]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 28 Aug 2012 01:48:18 -0400 From: David Allan I To: "zhang.fei3@zte.com.cn" Date: Tue, 28 Aug 2012 01:48:16 -0400 Thread-Topic: [mpls] Comments on draft-weingarten-mpls-smp-requirements-00.txt Thread-Index: Ac2EyCBZsatFwjX1R/uFX2+RRelX+gAGCYqw Message-ID: <60C093A41B5E45409A19D42CF7786DFD5CFCCC91C5@EUSAACMS0703.eamcs.ericsson.se> References: <60C093A41B5E45409A19D42CF7786DFD5CFC7DA5BF@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_60C093A41B5E45409A19D42CF7786DFD5CFCCC91C5EUSAACMS0703e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-weingarten-mpls-smp-requirements-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: Tue, 28 Aug 2012 05:48:27 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD5CFCCC91C5EUSAACMS0703e_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SEkgRmVpOg0KDQpZb3Ugd3JvdGU6DQogPGZlaT4gSU1ITywgdGhlcmUgYXJlIHR3byBwcmlvcml0 aWVzIG5lZWQgdG8gYmUgaGFuZGxlZCBpbiBzaGFyZWQgbWVzaCBwcm90ZWN0aW9uIHNjZW5hcmlv cywgdGhlIHBhdGggcHJpb3JpdHkgYW5kIHRoZSBzZXJ2aWNlIHByaW9yaXR5IChQSEIpLiBJZiBu b2RlIEUgZG9lcyB0aGUgcHJlZW1wdGlvbiwgaG93IHRvDQpkZWFsIHdpdGggdGhlIHBhdGggcHJp b3JpdHksIHdoaWNoIGlzIG5vdCBjYXJyaWVkIGluIHRyYWZmaWMgcGFja2V0Lg0KTXkgdW5kZXJz dGFuZGluZyBvZiB5b3VyIHByb3Bvc2FsIGlzIHRoYXQgdmlhIGNvbnRyb2wgcGxhbmUgZXhjaGFu Z2UsIEUga25vd3MgdGhlIHBhdGggcHJpb3JpdHkuIENlcnRhaW5seSB0aGUgaW5ncmVzc2VzIGFy ZSB1bmF3YXJlIG9mIGVhY2ggb3RoZXIgd2l0aG91dCBhIGNvb3JkaW5hdGlvbiBtZWNoYW5pc20g d2hpY2ggYXMgY3VycmVudGx5IGRlc2NyaWJlZCBpcyBub3RpZmljYXRpb25zIG9yaWdpbmF0aW5n IHdpdGggRS4gTXkgc3VnZ2VzdGlvbiBpcyB0aGF0IHRoZSBFIGFzIHRoZSBwcmVlbXB0aW9uIHBv aW50IGhhcyBzdWZmaWNpZW50IGtub3dsZWRnZSB0byBwZXJmb3JtIHRoaXMgZnVuY3Rpb24sIGFu ZCB3b3VsZCBkbyBpdCB3aXRoIGxlc3MgbGF0ZW5jeSB0aGFuIGhlYWQgZW5kIG5vdGlmaWNhdGlv biBhbmQgdGhlIGhlYWQgZW5kIGFzIHRoZSBwcmVlbXB0aW9uIHBvaW50LiBJdCBoYXMgdGhlIGFk ZGVkIHBsdXMgb2Ygbm90IGJlaW5nIGRlcGVuZGVudCBvbiB0aGUgaGVhZCBlbmQgbm90IGJlaW5n IGJyYWluIGRlYWQuLi4uDQoNCkkgaG9wZSB0aGlzIGhlbHBzDQpEYXZlDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiB6aGFuZy5mZWkzQHp0ZS5jb20uY24gW21haWx0 bzp6aGFuZy5mZWkzQHp0ZS5jb20uY25dDQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMjgsIDIwMTIg NTo1MiBBTQ0KVG86IERhdmlkIEFsbGFuIEkNCkNjOiBHcmVnb3J5IE1pcnNreTsgbXBsc0BpZXRm Lm9yZw0KU3ViamVjdDogUkU6IFttcGxzXSBDb21tZW50cyBvbiBkcmFmdC13ZWluZ2FydGVuLW1w bHMtc21wLXJlcXVpcmVtZW50cy0wMC50eHQNCg0KDQpIaSBEYXZlDQoNClNvcnJ5IGZvciB0aGUg ZGVsYXllZCByZXNwb25zZSwgc2VlIG15IG5vdGVzIHRhZ2dlZCB3aXRoIDxmZWk+DQoNCg0KVGhh bmtzDQoNCkZlaQ0KDQoNCkRhdmlkIEFsbGFuIEkgPGRhdmlkLmkuYWxsYW5AZXJpY3Nzb24uY29t Pg0KDQoyMDEyLTA4LTIyIDAxOjI5DQoNCsrVvP7Iyw0KInpoYW5nLmZlaTNAenRlLmNvbS5jbiIg PHpoYW5nLmZlaTNAenRlLmNvbS5jbj4sIEdyZWdvcnkgTWlyc2t5IDxncmVnb3J5Lm1pcnNreUBl cmljc3Nvbi5jb20+DQqzrcvNDQoibXBsc0BpZXRmLm9yZyIgPG1wbHNAaWV0Zi5vcmc+DQrW98zi DQpSRTogW21wbHNdIENvbW1lbnRzIG9uIGRyYWZ0LXdlaW5nYXJ0ZW4tbXBscy1zbXAtcmVxdWly ZW1lbnRzLTAwLnR4dA0KDQoNCg0KDQoNCkhpIEZlaToNCg0KSSBzZWUgImEiIHByb3Bvc2VkIHNv bHV0aW9uIGluIHRoZSBkcmFmdCB5b3UgcmVmZXJlbmNlLCBidXQgbm90IGEgcHJvYmxlbSBzdGF0 ZW1lbnQgb3IgYW5hbHN5c2lzDQoNCjxmZWk+ICBUaGUgcHJvcG9zZWQgc29sdXRpb24gaXMgYmFz ZSBvbiB0aGUgY29udHJvbCBwbGFuZSBleHRlbnNpb25zLCBhbmQgdGhlIHByb2JsZW0gc3RhdGVt ZW50IHNhaWQgIiBbUkZDNDg3Ml0gZGVmaW5lcyB0aGUgc2hhcmVkIG1lc2ggcmVzdG9yYXRpb24g c2NoZW1lcyBiYXNlZCBvbg0KICBjb250cm9sIHBsYW5lIGV4dGVuc2lvbnMsIGJ1dCBkb2VzIG5v dCBjb3ZlciB0aGUgc2hhcmVkIG1lc2ggIHByb3RlY3Rpb24gc2NlbmFyaW9zLiINCg0KVGhlIHBy ZWVtcHRpb24gY291bGQgc2ltcGx5IGJlIHBlcmZvcm1lZCBhdCBub2RlIEUuIEN1cnJlbnRseSB0 aGUgbW9kZWwgaXMgdGhhdCB0aGUgTEVScyBuZWVkIHRvIG5vdGlmeSBub2RlIEUgd2hlbiB0aGUg UCBwYXRoIGlzIGJlaW5nIHVzZWQsIGFuZCBFIG5lZWRzIHRvIG5vdGlmeSB0aGUgTEVScyBvZiB0 aGUgY3VycmVudCBzdGF0ZSBvZiB0aGUgc2hhcmVkIHJlc291cmNlLiAgVGhpcyBhcHBlYXJzIHRv IGRlcGVuZCBvbiB0aGUgcHJlZW1wdGVkIExTUiB0byAiZG8gdGhlIHJpZ2h0IHRoaW5nIiBhbmQg bGVhZHMgdG8gYW4gSU1PIHVucmVhc29uYWJsZSB3aW5kb3cgb2YgY29udGVudGlvbiBmb3IgdGhl IHNoYXJlZCByZXNvdXJjZXMuDQoNCiAgPGZlaT4gUHJlZW1wdGlvbiBtZWFucyB0aGF0ICB0aGVy ZSB3aWxsIGJlIGEgd2luZG93IG9mIGNvbnRlbnRpb24sIHdoeSBpdCBpcyB1bnJlYXNvbmFibGU/ DQoNCklNTyBFIHNob3VsZCBiZSBkb2luZyB0aGUgcHJlZW1wdGlvbiwgYW5kIEkndmUgc3RpbGwg bm90IHJlYWxseSBzZWVuIGEgbmVlZCBmb3IgaGVhZCBlbmQgbm90aWZpY2F0aW9uIG9mIHByZWVt cHRpb24gdW5sZXNzIG9uZSBzdGFydHMgcGxhbm5pbmcgYmFja3VwcyBmb3IgYmFja3Vwcy4NCg0K ICA8ZmVpPiBJTUhPLCB0aGVyZSBhcmUgdHdvIHByaW9yaXRpZXMgbmVlZCB0byBiZSBoYW5kbGVk IGluIHNoYXJlZCBtZXNoIHByb3RlY3Rpb24gc2NlbmFyaW9zLCB0aGUgcGF0aCBwcmlvcml0eSBh bmQgdGhlIHNlcnZpY2UgcHJpb3JpdHkgKFBIQikuIElmIG5vZGUgRSBkb2VzIHRoZSBwcmVlbXB0 aW9uLCBob3cgdG8NCmRlYWwgd2l0aCB0aGUgcGF0aCBwcmlvcml0eSwgd2hpY2ggaXMgbm90IGNh cnJpZWQgaW4gdHJhZmZpYyBwYWNrZXQuDQoNCklmIHlvdSBoYXZlIG1vcmUgaW5mb3JtYXRpb24s IGNvdWxkIHlvdSBlbGFib3JhYmxlPw0KRGF2ZQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCkZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIHpoYW5nLmZlaTNAenRlLmNvbS5jbg0KU2VudDog TW9uZGF5LCBBdWd1c3QgMjAsIDIwMTIgNDowMyBBTQ0KVG86IEdyZWdvcnkgTWlyc2t5DQpDYzog bXBsc0BpZXRmLm9yZzsgbXBscy1ib3VuY2VzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21wbHNd IENvbW1lbnRzIG9uIGRyYWZ0LXdlaW5nYXJ0ZW4tbXBscy1zbXAtcmVxdWlyZW1lbnRzLTAwLnR4 dA0KDQoNCkdyZWcsIHNuaXBwZWQNCg0KICogICBJbiB0aGUgbGFzdCBzZW50ZW5jZSBvZiBTZWN0 aW9uIDMuMSBub24tY29udHJvbCBwbGFuZSBjb29yZGluYXRpb24gb2Ygc2hhcmVkIHJlc291cmNl cyBwcmVzZW50ZWQgYXMgYW5vdGhlciByZXF1aXJlbWVudC4gQW5kIGFnYWluIEkgY2FuIG5vdCBm aW5kIGhvdyB3ZSBjb21lIHRvIHN1Y2ggY29uY2x1c2lvbiwgd2hlcmUgdGhlIHNvdXJjZSBvZiB0 aGlzIHJlcXVpcmVtZW50LiBXb3VsZCBleGlzdGluZyBjb250cm9sIHBsYW5lIHNpZ25hbGluZyBz b2x1dGlvbiBiZSBzdWZmaWNpZW50IGZvciBhIE1QTFMgbmV0d29yaz8NCg0KPEZlaT4gSSBkbyBu b3QgdGhpbmsgdGhlIGV4aXN0aW5nIGNvbnRyb2wgcGxhbmUgKGRlZmluZWQgaW4gUkZDNDg3Mikg aXMgc3VmZmljaWVudCBmb3IgYSBNUExTIG5ldHdvcmssIGFuZCB0aGVyZSBpcyBhbiBhbmFseXNp cyBpbiB0aGUgZHJhZnQgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGUtY2NhbXAt bm90aWZpY2F0aW9uLXNoYXJlZC1tZXNoLXByb3RlY3Rpb24tMDAuDQoNCg0KQmVzdCByZWdhcmRz DQoNCkZlaQ0KDQoNCkdyZWdvcnkgTWlyc2t5IDxncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20+ DQq3orz+yMs6ICBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcNCg0KMjAxMi0wOC0xNiAwNjo0NQ0KDQrK 1bz+yMsNClBhYmxvIEZyYW5rIDxwYWJsb2lzbm90QGdtYWlsLmNvbT4sIFlhYWNvdiBXZWluZ2Fy dGVuIDx3eWFhY292QGdtYWlsLmNvbT4NCrOty80NCiJtcGxzQGlldGYub3JnIiA8bXBsc0BpZXRm Lm9yZz4NCtb3zOINClJlOiBbbXBsc10gQ29tbWVudHMgb24gZHJhZnQtd2VpbmdhcnRlbi1tcGxz LXNtcC1yZXF1aXJlbWVudHMtMDAudHh0DQoNCg0KDQoNCg0KDQoNCkRlYXIgUGFibG8sIFlhYWNv diwgZXQgYWwuLA0KSSd2ZSBiZWVuIGZvbGxvd2luZyBkaXNjdXNzaW9uIHdpdGggZ3JlYXQgZGVh bCBvZiBpbnRlcmVzdC4gSSBoYXZlIHNvbWUgcXVlc3Rpb25zIGluIGFkZGl0aW9uIHRvIG9uZXMg YmVpbmcgYnJvdWdodCB1cCBieSBQYWJsbzoNCg0KICogICBTZWN0aW9uIDEuMiByZWZlcnMgdG8g b3BlcmF0b3IncyBkZXNpcmUgdG8gaGF2ZSBzZXJ2aWNlIHJlc3RvcmF0aW9uIG1vcmUgZXhwZWRp ZW50IHRoYW4gb25lIGFjaGlldmFibGUgd2l0aCBjb250cm9sIHBsYW5lLiBJIGhhdmVuJ3Qgc2Vl biBhbnkgcXVhbnRhdGl2ZSBpbmZvcm1hdGlvbiB0byBjb21wYXJlIHdpdGguIFdoYXQgaXMgImV4 cGVkaWVudCBlbm91Z2giIGZvciBTTVA/DQogKiAgIFNlY3Rpb24gMy4xIGRlc3JjaWJlcywgd2hh dCBjYW4gYmUgY2FsbGVkLCAiaW5zdGFudCBkZXRlcm1pbmlzbSIgaW4gcmVnYXJkIHRvIFNNUCBy ZXNvdXJjZSBhdmFpYWxhYmlsaXR5LiBJIHRoaW5rIHRoYXQgdGhlcmUncyBub3QgZW5vdWdoIHJl YXNvbmluZyB0byBjb25jbHVkZSB0aGF0IGFsbW9zdCBpbnN0YW50ZW5lb3VzIHVwZGF0ZSBvZiBT TVAgcmVzb3VyY2VzIGF2YWlhbGFiaWxpdHkgaXMgcmVxdWlyZWQuDQogKiAgIEluIHRoZSBsYXN0 IHNlbnRlbmNlIG9mIFNlY3Rpb24gMy4xIG5vbi1jb250cm9sIHBsYW5lIGNvb3JkaW5hdGlvbiBv ZiBzaGFyZWQgcmVzb3VyY2VzIHByZXNlbnRlZCBhcyBhbm90aGVyIHJlcXVpcmVtZW50LiBBbmQg YWdhaW4gSSBjYW4gbm90IGZpbmQgaG93IHdlIGNvbWUgdG8gc3VjaCBjb25jbHVzaW9uLCB3aGVy ZSB0aGUgc291cmNlIG9mIHRoaXMgcmVxdWlyZW1lbnQuIFdvdWxkIGV4aXN0aW5nIGNvbnRyb2wg cGxhbmUgc2lnbmFsaW5nIHNvbHV0aW9uIGJlIHN1ZmZpY2llbnQgZm9yIGEgTVBMUyBuZXR3b3Jr Pw0KICogICBJJ3ZlIG5vdGljZWQgdGhhdCBtYW55IHJlcXVpcmVtZW50cyBiZWluZyByZWZlcnJl ZCB0byBNUExTLVRQLCBub3QgTVBMUywgbmV0d29ya3MuIFdvdWxkIHRoYXQgYmUgYSBnb29kIHJl YXNvbiB0byBuYXJyb3cgc2NvcGUgb2YgdGhlIGRvY3VtZW50IHRvIE1QTFMtVFAgbmV0d29ya3Mg b25seSwgc3RhcnRpbmcgd2l0aCB0aGUgbmFtZSBvZiB0aGUgZG9jdW1lbnQ/DQoNCiAgICBSZWdh cmRzLA0KICAgICAgIEdyZWcNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZy b206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIFBhYmxvIEZyYW5rDQpTZW50OiBGcmlkYXksIEF1Z3VzdCAxMCwgMjAxMiA3 OjIzIEFNDQpUbzogWWFhY292IFdlaW5nYXJ0ZW4NCkNjOiBtcGxzQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW21wbHNdIENvbW1lbnRzIG9uIGRyYWZ0LXdlaW5nYXJ0ZW4tbXBscy1zbXAtcmVxdWly ZW1lbnRzLTAwLnR4dA0KDQpIaSBZYWFjb3YsDQoNClNvbWUgbW9yZSBjb21tZW50cyBpbmxpbmUu Li4gUEY+Pg0KDQpPbiBNb24sIEF1ZyA2LCAyMDEyIGF0IDg6NTYgQU0sIFlhYWNvdiBXZWluZ2Fy dGVuIDx3eWFhY292QGdtYWlsLmNvbTxtYWlsdG86d3lhYWNvdkBnbWFpbC5jb20+PiB3cm90ZToN CkhpLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMuICBQbGVhc2Ugc2VlIG15IGNvbW1l bnRzIGlubGluZSBiZWxvdy4NCg0KQlIsDQp5YWFjb3YNCg0KT24gVHVlLCBKdWwgMTcsIDIwMTIg YXQgMTE6NTEgUE0sIFBhYmxvIEZyYW5rIDxwYWJsb2lzbm90QGdtYWlsLmNvbTxtYWlsdG86cGFi bG9pc25vdEBnbWFpbC5jb20+PiB3cm90ZToNCkdvb2QgZHJhZnQgYW5kIGNlcnRhaW5seSBzb21l dGhpbmcgdGhhdCBuZWVkcyB0byBiZSBkb25lIGJlZm9yZSB3ZSBjYW4gc3RhcnQgZGlzY3Vzc2lu ZyBzcGVjaWZpYyBzb2x1dGlvbnMuDQoNCk9ubHkgYSBmZXcgY29tbWVudHMgLyBxdWVzdGlvbnM6 DQoNCi0gSW4gNC4xLjEsIGlmIG9uZSBpcyBvcGVyYXRpbmcgaW4gYW4gTVBMUy1UUCBuZXR3b3Jr IHRoYXQgcmVxdWlyZXMgZXhjbHVzaXZlIHVzZSBvZiB0aGUgcHJvdGVjdGlvbiByZXNvdXJjZXMs IGRvZXNuJ3QgdGhpcyBTSE9VTEQgcmVxdWlyZW1lbnQgYmVjb21lIGEgTVVTVCByZXF1aXJlbWVu dD8NCg0KeXc+PiBTb3JyeSAtIGJ1dCBjb3VsZCB5b3UgZXhwbGFpbiBtb3JlIGZ1bGx5IHRoaXMg Y29tbWVudC4NCg0KUEY+PiAgSWYgeW91J3JlIHRyeWluZyB0byBtZWV0IFJGQyA1NjU0IHJlcSA1 OGIgaW4gcGFydGljdWxhciwgSSB3b3VsZCB0aGluayB5b3UgTVVTVCB2YWxpZGF0ZSB0aGF0IGVu b3VnaCBwcm90ZWN0aW9uIHJlc291cmNlcyBhcmUgYXZhaWxhYmxlIChvciBhcmUgcHJlZW1wdGli bGUpIHRvIGNhcnJ5IDEwMCUgb2YgdGhlIHNlcnZpY2UgdHJhZmZpYyB0aGF0IGlzIGJlaW5nIHJl c3RvcmVkLiAgSW4gZXhpc3RpbmcgdHJhbnNwb3J0IG5ldHdvcmtzIChpLmUuIE9UTiAvIHNvbmV0 KSwgdGhpcyBpcyB0eXBpY2FsbHkgZG9uZSBiZWZvcmUgeW91IHN3aXRjaCB0cmFmZmljIHRvIHRo ZSBwcm90ZWN0aW9uIHBhdGguICBGcm9tIGEgc29sdXRpb24gcGVyc3BlY3RpdmUsIEkgdGhpbmsg eW91J2xsIHByb2JhYmx5IHdhbnQgdG8gbGV2ZXJhZ2Ugc29tZXRoaW5nIGxpa2UgdGhlIGxvY2tp bmcgbW9kZSB0aGF0IGlzIGJlaW5nIHByb3Bvc2VkIGZvciB0aGUgMTpuIGRyYWZ0Lg0KDQotIE5p dDogeW91IG1pZ2h0IHdhbnQgdG8gYXZvaWQgdXNpbmcgdGhlICJxdWVyeSIgdmVyYiBpbiB0aGUg dGl0bGUgb2YgNC4xLjEgYmVjYXVzZSBpdCBzdWJ0bHkgc3VnZ2VzdHMgc29tZSBraW5kIG9mIHBy b3RvY29sIG1lc3NhZ2luZyBpcyByZXF1aXJlZC4gIEkgd291bGQgdXNlIHRoZSBtb3JlIGdlbmVy aWMgdmVyYiAiY2hlY2tpbmciIG9yICJ2ZXJpZnlpbmciLg0KeXc+PiBTb3VuZHMgT0sgdG8gbWUu DQotIEluIDQuMywgdGhlcmUgaXMgbm8gc3VnZ2VzdGlvbiBmb3Igd2hhdCBzaG91bGQgaGFwcGVu IGlmIG9uZSBvciBtb3JlIGZhaWxpbmcgcGF0aHMgaW4gYW4gTVBMUy1UUCBuZXR3b3JrIGFyZSBv ZiBlcXVhbCBwcmlvcml0eS4gIEkgcHJlc3VtZSBpdCB3aWxsIGJlIHNvbWUga2luZCBvZiBmaXJz dC1jb21lLCBmaXJzdC1zZXJ2ZSByZXF1aXJlbWVudCBidXQgdGhpcyB3aWxsIGJyaW5nIHVwIHRo ZSBxdWVzdGlvbiBvZiBob3cgdG8gYnJlYWsgdGllcy4NCnl3Pj4gVGhpcyBjb3VsZCBiZSByZXNv bHZlZCBhbG9uZyB0aGUgbGluZXMgdGhhdCBpdCB3YXMgYWRkcmVzc2VkIGluIHRoZSAxOm4gcHJv dGVjdGlvbg0KDQpQRj4+IEV4Y2VwdCB0aGF0IHlvdSBndXlzIHJlbW92ZWQgc2VwYXJhdGUgcGF0 aCBwcmlvcml0eSBmcm9tIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgMTpuIGRyYWZ0LiAgSW4g dGhlIGxhdGVzdCB2ZXJzaW9uLCBlYWNoIHBhdGggaGFzIGEgc3RyaWN0IHByaW9yaXR5IGRlZmlu ZWQgYnkgaXRzIHBhdGggSUQgc28gdGllcyB3ZXJlIG5vdCBwb3NzaWJsZS4gIEkgZG9uJ3QgdGhp bmsgdGhhdCBzb2x1dGlvbiB3aWxsIHdvcmsgZm9yIFNNUCBiZWNhdXNlIEkgaGF2ZSBhIGhhcmQg dGltZSBzZWVpbmcgaG93IGFsbCB0aGUgdmFyaW91cyBlbmRwb2ludHMgaW52b2x2ZWQgaW4gYSBz aGFyZWQgbWVzaCBjb3VsZCBjb29yZGluYXRlIG5vbi1vdmVybGFwcGluZyBwYXRoIElEcywgd2hp bGUgYXQgdGhlIHNhbWUgdGltZSBub3QgZXhjZWVkaW5nIHRoZSBsaW1pdCBvZiAyNTUgcGF0aCBJ RHMuDQoNCg0KLSBBbHNvIGluIDQuMywgdGhlcmUgaXMgYW4gYWxsb3dhbmNlIGZvciBhIGhpZ2gg cHJpb3JpdHkgcGF0aCBhbmQgYSBsb3dlciBwcmlvcml0eSBwYXRoIHRvIHRlbXBvcmFyaWx5IHNo YXJlIHRoZSBwcm90ZWN0aW9uIHJlc291cmNlcyB3aGlsZSBwcmVlbXB0aW9uIGlzIHRha2luZyBw bGFjZS4gIFR3byBxdWVzdGlvbnM6DQotIElzIHRoZSBpbmdyZXNzIG5vZGUgdG8gdGhlIHNoYXJl ZCBzZWdtZW50IGV4cGVjdGVkIHRvIGRpc2NhcmQgZXhjZXNzIHRyYWZmaWMgbm93IHRoYXQgdGhl IHByb3RlY3Rpb24tcGF0aCBpcyB0ZW1wb3JhcmlseSBvdmVyc3Vic2NyaWJlZD8NCnl3Pj4gdGhp cyB3b3VsZCBtb3N0IHByb2JhYmx5IGZvbGxvdyBzdGFuZGFyZCBNUExTIGJlaGF2aW9yIGFzIGRl c2NyaWJlZCBlbHNld2hlcmUNCg0KUEY+PiBJIGd1ZXNzIEknbGwgYXNrIHdoYXQgaXMgdGhlIHN0 YW5kYXJkIGJlaGF2aW91cj8gIEFuZCBpcyBpdCBhcHBsaWNhYmxlIHRvIE1QTFMtVFAgbmV0d29y a3M/DQoNCi0gSWYgbm90LCBob3cgZG8gd2UgZW5zdXJlIHRoYXQgb3RoZXIgdHJhbnNwb3J0IHBh dGhzIGFyZSB1bmFmZmVjdGVkPw0KLSBUaGUgZmlyc3QgcGFyYWdyYXBoIG9mIDQuNCBhcHBlYXJz IHRvIGNvbnRyYWRpY3QgNC4xLjEuICA0LjQgc2VlbXMgdG8gc3VnZ2VzdCB0aGF0IG9uZSBNVVNU IHN3aXRjaCB0aGUgdHJhZmZpYyBvbnRvIHRoZSBwcm90ZWN0aW9uIHBhdGggZmlyc3QgYW5kIHRo ZW4gZ2V0IG5vdGlmaWVkIGlmIHRoZXJlJ3Mgbm90IGVub3VnaCByZXNvdXJjZXMuICBUaGF0J3Mg cHJvYmFibHkgb2theSBpbiB0aGUgZ2VuZXJhbCBjYXNlLiAgQnV0IGluIGFuIE1QTFMtVFAgbmV0 d29yaywgSSBkb24ndCB0aGluayBpdCdzIGEgZ29vZCBpZGVhIHRvIGJsaW5kbHkgc3dpdGNoIGxv dyBwcmlvcml0eSB0cmFmZmljIG9udG8gdGhlIHByb3RlY3Rpb24gcGF0aCBhbmQgcG9zc2libHkg ZGlzcnVwdCBhIGhpZ2ggcHJpb3JpdHkgcGF0aCB0aGF0IGlzIGFscmVhZHkgdXNpbmcgdGhhdCBy ZXNvdXJjZS4NCnl3Pj4gVGhpcyBpcyBkZXBlbmRlbnQgdXBvbiB0aGUgYWN0dWFsIG1lY2hhbmlz bSB0aGF0IGlzIGRldmVsb3BlZCBieSB0aGUgV0cuICBGb3IgZXhhbXBsZSwgb25lIHN1Z2dlc3Rp b24gZm9yIHRoZSBtZWNoYW5pc20gaGFzIG5vdGlmaWNhdGlvbnMgc2VudCB0byBsb3dlciBwcmlv cml0eSB3b3JraW5nIHBhdGhzIG1ha2luZyB0aGUgcHJvdGVjdGlvbiBwYXRoIHVuYXZhaWxhYmxl IGlmIGl0IGlzIGluIHVzZSBieSBhIGhpZ2gtcHJpb3JpdHkgd29ya2luZyBwYXRoLg0KDQotIElu IHNlY3Rpb24gNC41LCB0aGVyZSdzIGFuIGF0dGVtcHQgdG8gZGVmaW5lICJwcm90ZWN0aW9uIHN3 aXRjaGluZyB0aW1lIiBhcyBub3QgaW5jbHVkaW5nIHByZWVtcHRpb24gdGltZS4gIEkgZG9uJ3Qg dGhpbmsgZW5kLXVzZXJzIHJlYWxseSBjYXJlIGFib3V0ICJwcm90ZWN0aW9uIHN3aXRjaGluZyB0 aW1lIi4gIFRoZXkgY2FyZSBhYm91dCByZWNvdmVyeSB0aW1lIGFuZCBJTU8sIHRoYXQgc2hvdWxk IGFsc28gaW5jbHVkZSBmYXVsdCBkZXRlY3Rpb24gdGltZSAoYWx0aG91Z2ggaXQgZG9lc24ndCBw ZXIgUkZDIDU2NTQpIGFuZCBhbnkgcHJlZW1wdGlvbiB0aW1lLg0KeXc+PiB3ZSBkbyB0cnkgdG8g d29yayB3aXRoaW4gdGhlIGFjY2VwdGVkIGRlZmluaXRpb25zIG9mIHRoZSBJRVRGIQ0KDQpQRj4+ IEkgZ3Vlc3MgdGhlcmUncyB0d28gc2VwYXJhdGUgY29tbWVudHMgaGVyZSB0aGF0IEkga2luZGEg Y29uZmxhdGVkIHRvZ2V0aGVyLiAgT25lIHdhcyBtb3JlIG9mIGEgZ3JpcGU6IHdoeSBkaWQgd2Ug ZXhjbHVkZSBmYXVsdCBkZXRlY3Rpb24gdGltZSBmcm9tIHRoZSA1MG1zIHJlc3RvcmF0aW9uIHRp bWUgcmVxdWlyZW1lbnQgaW4gUkZDIDU2NTQ/ICBJIGtub3cgdGhhdCBteSBjdXN0b21lcnMgbWVh c3VyZSBvbmx5IG9uZSB0aGluZzogaG93IG1hbnkgbXMgb2YgdHJhZmZpYyBkbyB0aGV5IGxvc2Ug YWZ0ZXIgYSBicmVha2FnZS4gIEkgZG9uJ3QgZ2V0IGEgZnJlZSBwYXNzIG9uIHRoZSB+MTBtcyBp dCB0YWtlcyBmb3IgQkZEIHRvIGRldGVjdCB0aGUgZmFpbHVyZS4gIEFjY29yZGluZyB0byBSRkMg NTY1NCwgSSBjb3VsZCB1c2UgNjBzZWMgQ0NNcyBhbmQgc3RpbGwgbWVldCB0aGUgNTBtcyByZXF1 aXJlbWVudCENCg0KVGhlIDJuZCBjb21tZW50IHdhcyByZWFsbHkgYWJvdXQgdGhpcyBkcmFmdCBu b3cgdHJ5aW5nIHRvIGV4Y2x1ZGUgcHJlZW1wdGlvbiB0aW1lIGZyb20gcmVzdG9yYXRpb24gdGlt ZSBhcyB3ZWxsLiAgSU1PLCBpZiBpdCB0YWtlcyBhIGZldyBzZWNvbmRzIGZvciBhIGhpZ2ggcHJp b3JpdHkgc2VydmljZSB0byBmaW5pc2ggcHJlZW1wdGluZyBhIGxvd2VyIHByaW9yaXR5IHNlcnZp Y2UsIHRoZW4gd2UgaGF2ZW4ndCBtZXQgdGhlIDUwbXMgcmVzdG9yYXRpb24gdGltZSByZXF1aXJl bWVudC4gIEVzcGVjaWFsbHkgc2luY2UgaXQncyB0eXBpY2FsbHkgbXkgaGlnaGVyIHByaW9yaXR5 IHNlcnZpY2VzIHRoYXQgd2FudCA1MG1zIHJlc3RvcmF0aW9uIHRpbWVzIGluIHRoZSBmaXJzdCBw bGFjZSwgc28gdGhleSdsbCBiZSBtb3JlIG9mdGVuIGluIGEgcG9zaXRpb24gdG8gcHJlZW1wdC4g IEluIG90aGVyIHdvcmRzLCBJIHRoaW5rIHdlIHdhbnQgcHJlZW1wdGlvbiB0byBiZSBmYXN0IGFu ZCBpcyBhIGNyaXRpY2FsIGNvbXBvbmVudCBvZiBwcm90ZWN0aW9uIHN3aXRjaGluZy4NCg0KDQpy ZWdhcmRzLA0KUGFibG8NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBt YWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbXBscw0KDQo= --_000_60C093A41B5E45409A19D42CF7786DFD5CFCCC91C5EUSAACMS0703e_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
HI=20 Fei:
 
You=20 wrote:
 <fei> = IMHO,=20 there are two priorities need to be handled in shared mesh protection scena= rios,=20 the path priority and the service priority (PHB). If node E does the preemp= tion,=20 how to
deal with the path priority, which is not carried= in=20 traffic packet.
My=20 understanding of your proposal is that via control plane exchange, E knows = the=20 path priority. Certainly the ingresses are unaware of each other without a= =20 coordination mechanism which as currently described is notifications origin= ating=20 with E. My suggestion is that the E as the preemption point has sufficient= =20 knowledge to perform this function, and would do it with less latency than = head=20 end notification and the head end as the preemption point. It has the added= plus=20 of not being dependent on the head end not being brain=20 dead....
 
I hope=20 this helps
Dave

From: zhang.fei3@zte.com.cn=20 [mailto:zhang.fei3@zte.com.cn]
Sent: Tuesday, August 28, 2012 5:= 52=20 AM
To: David Allan I
Cc: Gregory Mirsky;=20 mpls@ietf.org
Subject: RE: [mpls] Comments on=20 draft-weingarten-mpls-smp-requirements-00.txt


Hi Dave

Sorry for the delayed response, see my notes tagged with= =20 <fei>


Thanks=20

Fei


David Allan I=20 <david.i.allan@ericsson.com>

2012-08-22 01:29

=CA=D5=BC= =FE=C8=CB
"zhang.fei3@zte.com.cn"=20 <zhang.fei3@zte.com.cn>, Gregory Mirsky=20 <gregory.mirsky@ericsson.com>=20
=B3=AD=CB= =CD
"mpls@ietf.org"=20 <mpls@ietf.org>=20
=D6=F7=CC= =E2
RE: [mpls] Comments on=20 draft-weingarten-mpls-smp-requirements-00.txt





Hi Fei:
&= nbsp;=20
I see "a" proposed solution in= the draft=20 you reference, but not a problem statement or analsysis

<fei>  The proposed solution is base on th= e control=20 plane extensions, and the problem statement said " [RFC4872] defines the sh= ared=20 mesh restoration schemes based on
  control plane extensions, but d= oes=20 not cover the shared mesh  protection scenarios."
 
The=20 preemption could simply be performed at node E. Currently the model is that= the=20 LERs need to notify node E when the P path is being used, and E needs to no= tify=20 the LERs of the current state of the shared resource.  This appears to= =20 depend on the preempted LSR to "do the right thing" and leads to an IMO=20 unreasonable window of contention for the shared resources.

=   <fei> Preemption means that  there = will be a=20 window of contention, why it is unreasonable?

IMO E should be doing the preemption, and I've still = not=20 really seen a need for head end notification of preemption unless one start= s=20 planning backups for backups.

&n= bsp;=20 <fei> IMHO, there are two priorities need to be handled in shared mes= h=20 protection scenarios, the path priority and the service priority (PHB). If = node=20 E does the preemption, how to
deal w= ith the=20 path priority, which is not carried in traffic packet.
 
If you have=20 more information, could you elaborable?
Dave
 =
 

From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of=20 zhang.fei3@zte.com.cn
Sent: Monday, August 20, 2012 4:03=20 AM
To: Gregory Mirsky
Cc: mpls@ietf.org;=20 mpls-bounces@ietf.org
Subject: Re: [mpls] Comments on=20 draft-weingarten-mpls-smp-requirements-00.txt


Greg,= =20 snipped
  • In the last sentence of Sect= ion 3.1=20 non-control plane coordination of shared resources presented as another=20 requirement. And again I can not find how we come to such conclusion, whe= re=20 the source of this requirement. Would existing control plane signaling=20 solution be sufficient for a MPLS network?

<Fei> I do not think the existing control plane= =20 (defined in RFC4872) is sufficient for a MPLS network, and there is an anal= ysis=20 in the draft=20 http://tools.ietf.org/html/draft-he-ccamp-notification-shared-mesh-protecti= on-00.=20


Best regards= =20

Fei


Gregory Mirsky=20 <gregory.mirsky@ericsson.com>
=B7=A2=BC=FE=C8=CB:=20  mpls-bounces@ietf.org <= /FONT>

2012-08-16 06:45


=CA=D5=BC= =FE=C8=CB
Pablo Frank=20 <pabloisnot@gmail.com>, Yaacov Weingarten=20 <wyaacov@gmail.com>=20
=B3=AD=CB= =CD
"mpls@ietf.org"=20 <mpls@ietf.org> <= /FONT>
=D6=F7=CC= =E2
Re: [mpls] Comments on=20 draft-weingarten-mpls-smp-requirements-00.txt



<= BR>

<= BR>Dear=20 Pablo, Yaacov, et al.,
I've been following discussion with = great deal=20 of interest. I have some questions in addition to ones being brought up by= =20 Pablo:
  • Section 1.2 refers to operat= or's desire=20 to have service restoration more expedient than one achievable with contr= ol=20 plane. I haven't seen any quantative information to compare with. What is= =20 "expedient enough" for SMP?
  • Section 3.1 desrcibes, what = can be=20 called, "instant determinism" in regard to SMP resource avaialability. I = think=20 that there's not enough reasoning to conclude that almost instanteneous u= pdate=20 of SMP resources avaialability is required.
  • In the last sentence of Sect= ion 3.1=20 non-control plane coordination of shared resources presented as another=20 requirement. And again I can not find how we come to such conclusion, whe= re=20 the source of this requirement. Would existing control plane signaling=20 solution be sufficient for a MPLS network?=20
  • I've noticed that many requi= rements=20 being referred to MPLS-TP, not MPLS, networks. Would that be a good reaso= n to=20 narrow scope of the document to MPLS-TP networks only, starting with the = name=20 of the document?
 =20   Regards,
    &= nbsp;=20  Greg

From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of Pablo Frank
Sent:<= /B>=20 Friday, August 10, 2012 7:23 AM
To: Yaacov Weingarten
Cc:=20 mpls@ietf.org
Subject: Re: [mpls] Comments on=20 draft-weingarten-mpls-smp-requirements-00.txt

Hi Yaacov,

Some more comments inline...=20 PF>>

On Mon, Aug 6, 2012 at 8:56 AM, Yaacov Weingarten=20 <wyaacov@gmail.com> wrote:
Hi,

Thank you for your comments.= =20  Please see my comments inline below.

BR,
yaacov

On= Tue,=20 Jul 17, 2012 at 11:51 PM, Pablo Frank <pabloisnot@gmail.com> wrote:
Good draft and certainly something that n= eeds to=20 be done before we can start discussing specific solutions.

Only a f= ew=20 comments / questions:

- In 4.1.1, if one is operating in an MPLS-TP= =20 network that requires exclusive use of the protection resources, doesn't th= is=20 SHOULD requirement become a MUST requirement?

yw>> Sorry - bu= t=20 could you explain more fully this comment.

PF>>  If you'= re=20 trying to meet RFC 5654 req 58b in particular, I would think you MUST valid= ate=20 that enough protection resources are available (or are preemptible) to carr= y=20 100% of the service traffic that is being restored.  In existing trans= port=20 networks (i.e. OTN / sonet), this is typically done before you switch traff= ic to=20 the protection path.  From a solution perspective, I think you'll prob= ably=20 want to leverage something like the locking mode that is being proposed for= the=20 1:n draft.

- Nit: you might want to avoid using the "query" verb in= the=20 title of 4.1.1 because it subtly suggests some kind of protocol messaging i= s=20 required.  I would use the more generic verb "checking" or "verifying"= .=20
yw>> Sounds OK to me.
- In 4.3, there is no suggestion for wh= at=20 should happen if one or more failing paths in an MPLS-TP network are of equ= al=20 priority.  I presume it will be some kind of first-come, first-serve=20 requirement but this will bring up the question of how to break ties.=20
yw>> This could be resolved along the lines that it was addressed= in=20 the 1:n protection

PF>> Except that you guys removed separate= path=20 priority from the latest version of the 1:n draft.  In the latest vers= ion,=20 each path has a strict priority defined by its path ID so ties were not=20 possible.  I don't think that solution will work for SMP because I hav= e a=20 hard time seeing how all the various endpoints involved in a shared mesh co= uld=20 coordinate non-overlapping path IDs, while at the same time not exceeding t= he=20 limit of 255 path IDs.


- Also in 4.3, there is an allowance for= a=20 high priority path and a lower priority path to temporarily share the prote= ction=20 resources while preemption is taking place.  Two questions:
- Is t= he=20 ingress node to the shared segment expected to discard excess traffic now t= hat=20 the protection-path is temporarily oversubscribed?
yw>> this woul= d=20 most probably follow standard MPLS behavior as described elsewhere=20

PF>> I guess I'll ask what is the standard behaviour?  A= nd is=20 it applicable to MPLS-TP networks?
 
- If not, how do we ensure= that=20 other transport paths are unaffected?
- The first paragraph of 4.4 appe= ars=20 to contradict 4.1.1.  4.4 seems to suggest that one MUST switch the tr= affic=20 onto the protection path first and then get notified if there's not enough= =20 resources.  That's probably okay in the general case.  But in an= =20 MPLS-TP network, I don't think it's a good idea to blindly switch low prior= ity=20 traffic onto the protection path and possibly disrupt a high priority path = that=20 is already using that resource.
yw>> This is dependent upon the a= ctual=20 mechanism that is developed by the WG.  For example, one suggestion fo= r the=20 mechanism has notifications sent to lower priority working paths making the= =20 protection path unavailable if it is in use by a high-priority working path= .=20
 
- In section 4.5, there's an attempt to define "protection=20 switching time" as not including preemption time.  I don't think end-u= sers=20 really care about "protection switching time".  They care about recove= ry=20 time and IMO, that should also include fault detection time (although it do= esn't=20 per RFC 5654) and any preemption time.
yw>> we do try to work wit= hin=20 the accepted definitions of the IETF!

PF>> I guess there's tw= o=20 separate comments here that I kinda conflated together.  One was more = of a=20 gripe: why did we exclude fault detection time from the 50ms restoration ti= me=20 requirement in RFC 5654?  I know that my customers measure only one th= ing:=20 how many ms of traffic do they lose after a breakage.  I don't get a f= ree=20 pass on the ~10ms it takes for BFD to detect the failure.  According t= o RFC=20 5654, I could use 60sec CCMs and still meet the 50ms requirement!

T= he=20 2nd comment was really about this draft now trying to exclude preemption ti= me=20 from restoration time as well.  IMO, if it takes a few seconds for a h= igh=20 priority service to finish preempting a lower priority service, then we hav= en't=20 met the 50ms restoration time requirement.  Especially since it's typi= cally=20 my higher priority services that want 50ms restoration times in the first p= lace,=20 so they'll be more often in a position to preempt.  In other words, I = think=20 we want preemption to be fast and is a critical component of protection=20 switching.  
 

regards,
Pablo=20


_______________________________________________
mpls mailing= =20 list
= mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls<= /A>


_______________________________________________
mpls mailin= g=20 list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls<= /TT>

--_000_60C093A41B5E45409A19D42CF7786DFD5CFCCC91C5EUSAACMS0703e_-- From zhang.fei3@zte.com.cn Mon Aug 27 23:30: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 E5FDC11E80AE for ; Mon, 27 Aug 2012 23:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.008 X-Spam-Level: X-Spam-Status: No, score=-96.008 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_BAD_ID=2.837, 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 TsHrD2bxLRlk for ; Mon, 27 Aug 2012 23:30:46 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 3680911E808E for ; Mon, 27 Aug 2012 23:30:45 -0700 (PDT) Received: from [10.30.3.21] by mx5.zte.com.cn with surfront esmtp id 232554375048883(version=TLSv1/SSLv3 cipher=SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA bits=128 verify=NO); Tue, 28 Aug 2012 14:24:22 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q7S6UZnC017594; Tue, 28 Aug 2012 14:30:35 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD5CFCCC91C5@EUSAACMS0703.eamcs.ericsson.se> To: David Allan I MIME-Version: 1.0 X-KeepSent: 6D22D36F:D9907A66-48257A68:0021E2A1; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Tue, 28 Aug 2012 14:30:33 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-28 14:30:35, Serialize complete at 2012-08-28 14:30:35 Content-Type: multipart/alternative; boundary="=_alternative 0023AB6248257A68_=" X-MAIL: mse02.zte.com.cn q7S6UZnC017594 Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-weingarten-mpls-smp-requirements-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: Tue, 28 Aug 2012 06:30:48 -0000 This is a multipart message in MIME format. --=_alternative 0023AB6248257A68_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgRGF2ZQ0KDQpUaGFuayB5b3UgZm9yIHlvdXIgbmljZSByZXNwb25zZQ0KDQpTZWUgaW4gbGlu ZSB3aXRoIDxmZWkxPg0KDQpUaGFua3MNCg0KRmVpDQoNCg0KDQpEYXZpZCBBbGxhbiBJIDxkYXZp ZC5pLmFsbGFuQGVyaWNzc29uLmNvbT4gDQoyMDEyLTA4LTI4IDEzOjQ4DQoNCsrVvP7Iyw0KInpo YW5nLmZlaTNAenRlLmNvbS5jbiIgPHpoYW5nLmZlaTNAenRlLmNvbS5jbj4NCrOty80NCkdyZWdv cnkgTWlyc2t5IDxncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20+LCAibXBsc0BpZXRmLm9yZyIg DQo8bXBsc0BpZXRmLm9yZz4NCtb3zOINClJFOiBbbXBsc10gQ29tbWVudHMgb24gZHJhZnQtd2Vp bmdhcnRlbi1tcGxzLXNtcC1yZXF1aXJlbWVudHMtMDAudHh0DQoNCg0KDQoNCg0KDQpISSBGZWk6 DQogDQpZb3Ugd3JvdGU6DQogPGZlaT4gSU1ITywgdGhlcmUgYXJlIHR3byBwcmlvcml0aWVzIG5l ZWQgdG8gYmUgaGFuZGxlZCBpbiBzaGFyZWQgbWVzaCANCnByb3RlY3Rpb24gc2NlbmFyaW9zLCB0 aGUgcGF0aCBwcmlvcml0eSBhbmQgdGhlIHNlcnZpY2UgcHJpb3JpdHkgKFBIQikuIElmIA0Kbm9k ZSBFIGRvZXMgdGhlIHByZWVtcHRpb24sIGhvdyB0byANCmRlYWwgd2l0aCB0aGUgcGF0aCBwcmlv cml0eSwgd2hpY2ggaXMgbm90IGNhcnJpZWQgaW4gdHJhZmZpYyBwYWNrZXQuIA0KTXkgdW5kZXJz dGFuZGluZyBvZiB5b3VyIHByb3Bvc2FsIGlzIHRoYXQgdmlhIGNvbnRyb2wgcGxhbmUgZXhjaGFu Z2UsIEUgDQprbm93cyB0aGUgcGF0aCBwcmlvcml0eS4gQ2VydGFpbmx5IHRoZSBpbmdyZXNzZXMg YXJlIHVuYXdhcmUgb2YgZWFjaCBvdGhlciANCndpdGhvdXQgYSBjb29yZGluYXRpb24gbWVjaGFu aXNtIHdoaWNoIGFzIGN1cnJlbnRseSBkZXNjcmliZWQgaXMgDQpub3RpZmljYXRpb25zIG9yaWdp bmF0aW5nIHdpdGggRS4gTXkgc3VnZ2VzdGlvbiBpcyB0aGF0IHRoZSBFIGFzIHRoZSANCnByZWVt cHRpb24gcG9pbnQgaGFzIHN1ZmZpY2llbnQga25vd2xlZGdlIHRvIHBlcmZvcm0gdGhpcyBmdW5j dGlvbiwgYW5kIA0Kd291bGQgZG8gaXQgd2l0aCBsZXNzIGxhdGVuY3kgdGhhbiBoZWFkIGVuZCBu b3RpZmljYXRpb24gYW5kIHRoZSBoZWFkIGVuZCANCmFzIHRoZSBwcmVlbXB0aW9uIHBvaW50LiBJ dCBoYXMgdGhlIGFkZGVkIHBsdXMgb2Ygbm90IGJlaW5nIGRlcGVuZGVudCBvbiANCnRoZSBoZWFk IGVuZCBub3QgYmVpbmcgYnJhaW4gZGVhZC4uLi4NCg0KIDxmZWkxPiBPaywgSSB0aGluayBJIHVu ZGVyc3RhbmQgeW91ciBpZGVhIG5vdy4gIElNSE8sICBhbHRob3VnaCB0aGUgDQpyZXF1aXJlbWVu dHMgYXJlIGNvbWluZyBmcm9tIE1QTFMtVFAsIHRoZSBzdGFuZGFyZCBoYWQgYmV0dGVyIGNvdmVy aW5nIHRoZSANCm90aGVyIHNjZW5hcmlvcy4gQ29uc2lkZXIgdGhlIE9EVTIgcGF0aCBhcyB0aGUg c2hhcmVkIHBhdGggc2VnbWVudCwgYW5kIA0KdGhlIG5vZGUgRSBhcyB0aGUgcHJlZW1wdGlvbiBw b2ludCAoanVzdCBhcyB5b3Ugc2FpZCkuDQoNCnQwIEgtRS1GLUctSyBhcyB0aGUgcHJvdGVjdGlu ZyBwYXRoIGFyZSBwcm90ZWN0aW5nIHRoZSB3b3JrIHBhdGggSC1JLUotSw0KdDEgQS1CLUMtRCBp cyBicm9rZW4sIG5vZGUgQSBzd2l0Y2hlcyB0aGUgdHJhZmZpYyB0byBBLUUNCnQyIG5vZGUgRSBz d2l0Y2hlcyB0aGUgY3Jvc3Njb25uZWN0IGZyb20gSC1FIHRvIEEtRSAocGF0aCBBLUItQy1EIGhh cyANCmhpZ2hlciBwcmlvcml0eSB0aGFuIEgtSS1KLUspDQoNCkhvd2V2ZXIsIG5vZGUgRyBjYW4g bm90IG1ha2Ugc3VyZSB0byBzd2l0Y2ggdGhlIGNyb3NzY29ubmVjdCBmcm9tIEctSyB0byANCkct RCBzaW11bHRhbmVvdXNseSBhcyBhdCBub2RlIEUuIE1pc2Nvbm5lY3Rpb24gd2lsbCBoYXBwZW4u DQoNCkkgaG9wZSB0aGlzIGhlbHBzDQpEYXZlDQoNCkZyb206IHpoYW5nLmZlaTNAenRlLmNvbS5j biBbbWFpbHRvOnpoYW5nLmZlaTNAenRlLmNvbS5jbl0gDQpTZW50OiBUdWVzZGF5LCBBdWd1c3Qg MjgsIDIwMTIgNTo1MiBBTQ0KVG86IERhdmlkIEFsbGFuIEkNCkNjOiBHcmVnb3J5IE1pcnNreTsg bXBsc0BpZXRmLm9yZw0KU3ViamVjdDogUkU6IFttcGxzXSBDb21tZW50cyBvbiANCmRyYWZ0LXdl aW5nYXJ0ZW4tbXBscy1zbXAtcmVxdWlyZW1lbnRzLTAwLnR4dA0KDQoNCkhpIERhdmUgDQoNClNv cnJ5IGZvciB0aGUgZGVsYXllZCByZXNwb25zZSwgc2VlIG15IG5vdGVzIHRhZ2dlZCB3aXRoIDxm ZWk+IA0KDQoNClRoYW5rcyANCg0KRmVpIA0KDQoNCkRhdmlkIEFsbGFuIEkgPGRhdmlkLmkuYWxs YW5AZXJpY3Nzb24uY29tPiANCjIwMTItMDgtMjIgMDE6MjkgDQoNCg0KytW8/sjLDQoiemhhbmcu ZmVpM0B6dGUuY29tLmNuIiA8emhhbmcuZmVpM0B6dGUuY29tLmNuPiwgR3JlZ29yeSBNaXJza3kg DQo8Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPiANCrOty80NCiJtcGxzQGlldGYub3JnIiA8 bXBsc0BpZXRmLm9yZz4gDQrW98ziDQpSRTogW21wbHNdIENvbW1lbnRzIG9uIGRyYWZ0LXdlaW5n YXJ0ZW4tbXBscy1zbXAtcmVxdWlyZW1lbnRzLTAwLnR4dA0KDQoNCg0KDQoNCg0KDQoNCkhpIEZl aTogDQogIA0KSSBzZWUgImEiIHByb3Bvc2VkIHNvbHV0aW9uIGluIHRoZSBkcmFmdCB5b3UgcmVm ZXJlbmNlLCBidXQgbm90IGEgcHJvYmxlbSANCnN0YXRlbWVudCBvciBhbmFsc3lzaXMgDQoNCjxm ZWk+ICBUaGUgcHJvcG9zZWQgc29sdXRpb24gaXMgYmFzZSBvbiB0aGUgY29udHJvbCBwbGFuZSBl eHRlbnNpb25zLCBhbmQgDQp0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgc2FpZCAiIFtSRkM0ODcyXSBk ZWZpbmVzIHRoZSBzaGFyZWQgbWVzaCByZXN0b3JhdGlvbiANCnNjaGVtZXMgYmFzZWQgb24NCiAg Y29udHJvbCBwbGFuZSBleHRlbnNpb25zLCBidXQgZG9lcyBub3QgY292ZXIgdGhlIHNoYXJlZCBt ZXNoICBwcm90ZWN0aW9uIA0Kc2NlbmFyaW9zLiIgDQogIA0KVGhlIHByZWVtcHRpb24gY291bGQg c2ltcGx5IGJlIHBlcmZvcm1lZCBhdCBub2RlIEUuIEN1cnJlbnRseSB0aGUgbW9kZWwgaXMgDQp0 aGF0IHRoZSBMRVJzIG5lZWQgdG8gbm90aWZ5IG5vZGUgRSB3aGVuIHRoZSBQIHBhdGggaXMgYmVp bmcgdXNlZCwgYW5kIEUgDQpuZWVkcyB0byBub3RpZnkgdGhlIExFUnMgb2YgdGhlIGN1cnJlbnQg c3RhdGUgb2YgdGhlIHNoYXJlZCByZXNvdXJjZS4gVGhpcyANCmFwcGVhcnMgdG8gZGVwZW5kIG9u IHRoZSBwcmVlbXB0ZWQgTFNSIHRvICJkbyB0aGUgcmlnaHQgdGhpbmciIGFuZCBsZWFkcyANCnRv IGFuIElNTyB1bnJlYXNvbmFibGUgd2luZG93IG9mIGNvbnRlbnRpb24gZm9yIHRoZSBzaGFyZWQg cmVzb3VyY2VzLiANCg0KICA8ZmVpPiBQcmVlbXB0aW9uIG1lYW5zIHRoYXQgIHRoZXJlIHdpbGwg YmUgYSB3aW5kb3cgb2YgY29udGVudGlvbiwgd2h5IA0KaXQgaXMgdW5yZWFzb25hYmxlPyANCg0K SU1PIEUgc2hvdWxkIGJlIGRvaW5nIHRoZSBwcmVlbXB0aW9uLCBhbmQgSSd2ZSBzdGlsbCBub3Qg cmVhbGx5IHNlZW4gYSANCm5lZWQgZm9yIGhlYWQgZW5kIG5vdGlmaWNhdGlvbiBvZiBwcmVlbXB0 aW9uIHVubGVzcyBvbmUgc3RhcnRzIHBsYW5uaW5nIA0KYmFja3VwcyBmb3IgYmFja3Vwcy4gDQoN CiAgPGZlaT4gSU1ITywgdGhlcmUgYXJlIHR3byBwcmlvcml0aWVzIG5lZWQgdG8gYmUgaGFuZGxl ZCBpbiBzaGFyZWQgbWVzaCANCnByb3RlY3Rpb24gc2NlbmFyaW9zLCB0aGUgcGF0aCBwcmlvcml0 eSBhbmQgdGhlIHNlcnZpY2UgcHJpb3JpdHkgKFBIQikuIElmIA0Kbm9kZSBFIGRvZXMgdGhlIHBy ZWVtcHRpb24sIGhvdyB0byANCmRlYWwgd2l0aCB0aGUgcGF0aCBwcmlvcml0eSwgd2hpY2ggaXMg bm90IGNhcnJpZWQgaW4gdHJhZmZpYyBwYWNrZXQuIA0KICANCklmIHlvdSBoYXZlIG1vcmUgaW5m b3JtYXRpb24sIGNvdWxkIHlvdSBlbGFib3JhYmxlPyANCkRhdmUgDQogDQogDQoNCkZyb206IG1w bHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIA0KemhhbmcuZmVpM0B6dGUuY29tLmNuDQpTZW50OiBNb25kYXksIEF1Z3VzdCAyMCwg MjAxMiA0OjAzIEFNDQpUbzogR3JlZ29yeSBNaXJza3kNCkNjOiBtcGxzQGlldGYub3JnOyBtcGxz LWJvdW5jZXNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbXBsc10gQ29tbWVudHMgb24gDQpkcmFm dC13ZWluZ2FydGVuLW1wbHMtc21wLXJlcXVpcmVtZW50cy0wMC50eHQNCg0KDQpHcmVnLCBzbmlw cGVkIA0KSW4gdGhlIGxhc3Qgc2VudGVuY2Ugb2YgU2VjdGlvbiAzLjEgbm9uLWNvbnRyb2wgcGxh bmUgY29vcmRpbmF0aW9uIG9mIA0Kc2hhcmVkIHJlc291cmNlcyBwcmVzZW50ZWQgYXMgYW5vdGhl ciByZXF1aXJlbWVudC4gQW5kIGFnYWluIEkgY2FuIG5vdCANCmZpbmQgaG93IHdlIGNvbWUgdG8g c3VjaCBjb25jbHVzaW9uLCB3aGVyZSB0aGUgc291cmNlIG9mIHRoaXMgcmVxdWlyZW1lbnQuIA0K V291bGQgZXhpc3RpbmcgY29udHJvbCBwbGFuZSBzaWduYWxpbmcgc29sdXRpb24gYmUgc3VmZmlj aWVudCBmb3IgYSBNUExTIA0KbmV0d29yaz8gDQoNCjxGZWk+IEkgZG8gbm90IHRoaW5rIHRoZSBl eGlzdGluZyBjb250cm9sIHBsYW5lIChkZWZpbmVkIGluIFJGQzQ4NzIpIGlzIA0Kc3VmZmljaWVu dCBmb3IgYSBNUExTIG5ldHdvcmssIGFuZCB0aGVyZSBpcyBhbiBhbmFseXNpcyBpbiB0aGUgZHJh ZnQgDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oZS1jY2FtcC1ub3RpZmljYXRp b24tc2hhcmVkLW1lc2gtcHJvdGVjdGlvbi0wMA0KLiANCg0KDQpCZXN0IHJlZ2FyZHMgDQoNCkZl aSANCg0KDQpHcmVnb3J5IE1pcnNreSA8Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPiANCrei vP7IyzogIG1wbHMtYm91bmNlc0BpZXRmLm9yZyANCjIwMTItMDgtMTYgMDY6NDUgDQoNCg0KytW8 /sjLDQpQYWJsbyBGcmFuayA8cGFibG9pc25vdEBnbWFpbC5jb20+LCBZYWFjb3YgV2VpbmdhcnRl biA8d3lhYWNvdkBnbWFpbC5jb20+IA0Ks63LzQ0KIm1wbHNAaWV0Zi5vcmciIDxtcGxzQGlldGYu b3JnPiANCtb3zOINClJlOiBbbXBsc10gQ29tbWVudHMgb24gZHJhZnQtd2VpbmdhcnRlbi1tcGxz LXNtcC1yZXF1aXJlbWVudHMtMDAudHh0DQoNCg0KDQoNCg0KDQoNCg0KDQoNCkRlYXIgUGFibG8s IFlhYWNvdiwgZXQgYWwuLCANCkkndmUgYmVlbiBmb2xsb3dpbmcgZGlzY3Vzc2lvbiB3aXRoIGdy ZWF0IGRlYWwgb2YgaW50ZXJlc3QuIEkgaGF2ZSBzb21lIA0KcXVlc3Rpb25zIGluIGFkZGl0aW9u IHRvIG9uZXMgYmVpbmcgYnJvdWdodCB1cCBieSBQYWJsbzogDQpTZWN0aW9uIDEuMiByZWZlcnMg dG8gb3BlcmF0b3IncyBkZXNpcmUgdG8gaGF2ZSBzZXJ2aWNlIHJlc3RvcmF0aW9uIG1vcmUgDQpl eHBlZGllbnQgdGhhbiBvbmUgYWNoaWV2YWJsZSB3aXRoIGNvbnRyb2wgcGxhbmUuIEkgaGF2ZW4n dCBzZWVuIGFueSANCnF1YW50YXRpdmUgaW5mb3JtYXRpb24gdG8gY29tcGFyZSB3aXRoLiBXaGF0 IGlzICJleHBlZGllbnQgZW5vdWdoIiBmb3IgDQpTTVA/IA0KU2VjdGlvbiAzLjEgZGVzcmNpYmVz LCB3aGF0IGNhbiBiZSBjYWxsZWQsICJpbnN0YW50IGRldGVybWluaXNtIiBpbiByZWdhcmQgDQp0 byBTTVAgcmVzb3VyY2UgYXZhaWFsYWJpbGl0eS4gSSB0aGluayB0aGF0IHRoZXJlJ3Mgbm90IGVu b3VnaCByZWFzb25pbmcgDQp0byBjb25jbHVkZSB0aGF0IGFsbW9zdCBpbnN0YW50ZW5lb3VzIHVw ZGF0ZSBvZiBTTVAgcmVzb3VyY2VzIA0KYXZhaWFsYWJpbGl0eSBpcyByZXF1aXJlZC4gDQpJbiB0 aGUgbGFzdCBzZW50ZW5jZSBvZiBTZWN0aW9uIDMuMSBub24tY29udHJvbCBwbGFuZSBjb29yZGlu YXRpb24gb2YgDQpzaGFyZWQgcmVzb3VyY2VzIHByZXNlbnRlZCBhcyBhbm90aGVyIHJlcXVpcmVt ZW50LiBBbmQgYWdhaW4gSSBjYW4gbm90IA0KZmluZCBob3cgd2UgY29tZSB0byBzdWNoIGNvbmNs dXNpb24sIHdoZXJlIHRoZSBzb3VyY2Ugb2YgdGhpcyByZXF1aXJlbWVudC4gDQpXb3VsZCBleGlz dGluZyBjb250cm9sIHBsYW5lIHNpZ25hbGluZyBzb2x1dGlvbiBiZSBzdWZmaWNpZW50IGZvciBh IE1QTFMgDQpuZXR3b3JrPyANCkkndmUgbm90aWNlZCB0aGF0IG1hbnkgcmVxdWlyZW1lbnRzIGJl aW5nIHJlZmVycmVkIHRvIE1QTFMtVFAsIG5vdCBNUExTLCANCm5ldHdvcmtzLiBXb3VsZCB0aGF0 IGJlIGEgZ29vZCByZWFzb24gdG8gbmFycm93IHNjb3BlIG9mIHRoZSBkb2N1bWVudCB0byANCk1Q TFMtVFAgbmV0d29ya3Mgb25seSwgc3RhcnRpbmcgd2l0aCB0aGUgbmFtZSBvZiB0aGUgZG9jdW1l bnQ/DQogICAgUmVnYXJkcywgDQogICAgICAgR3JlZyANCg0KRnJvbTogbXBscy1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgDQpQYWJs byBGcmFuaw0KU2VudDogRnJpZGF5LCBBdWd1c3QgMTAsIDIwMTIgNzoyMyBBTQ0KVG86IFlhYWNv diBXZWluZ2FydGVuDQpDYzogbXBsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFttcGxzXSBDb21t ZW50cyBvbiANCmRyYWZ0LXdlaW5nYXJ0ZW4tbXBscy1zbXAtcmVxdWlyZW1lbnRzLTAwLnR4dA0K DQpIaSBZYWFjb3YsIA0KDQpTb21lIG1vcmUgY29tbWVudHMgaW5saW5lLi4uIFBGPj4NCg0KT24g TW9uLCBBdWcgNiwgMjAxMiBhdCA4OjU2IEFNLCBZYWFjb3YgV2VpbmdhcnRlbiA8d3lhYWNvdkBn bWFpbC5jb20+IA0Kd3JvdGU6IA0KSGksIA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMu ICBQbGVhc2Ugc2VlIG15IGNvbW1lbnRzIGlubGluZSBiZWxvdy4gDQoNCkJSLCANCnlhYWNvdg0K DQpPbiBUdWUsIEp1bCAxNywgMjAxMiBhdCAxMTo1MSBQTSwgUGFibG8gRnJhbmsgPHBhYmxvaXNu b3RAZ21haWwuY29tPiANCndyb3RlOiANCkdvb2QgZHJhZnQgYW5kIGNlcnRhaW5seSBzb21ldGhp bmcgdGhhdCBuZWVkcyB0byBiZSBkb25lIGJlZm9yZSB3ZSBjYW4gDQpzdGFydCBkaXNjdXNzaW5n IHNwZWNpZmljIHNvbHV0aW9ucy4gDQoNCk9ubHkgYSBmZXcgY29tbWVudHMgLyBxdWVzdGlvbnM6 IA0KDQotIEluIDQuMS4xLCBpZiBvbmUgaXMgb3BlcmF0aW5nIGluIGFuIE1QTFMtVFAgbmV0d29y ayB0aGF0IHJlcXVpcmVzIA0KZXhjbHVzaXZlIHVzZSBvZiB0aGUgcHJvdGVjdGlvbiByZXNvdXJj ZXMsIGRvZXNuJ3QgdGhpcyBTSE9VTEQgcmVxdWlyZW1lbnQgDQpiZWNvbWUgYSBNVVNUIHJlcXVp cmVtZW50PyANCg0KeXc+PiBTb3JyeSAtIGJ1dCBjb3VsZCB5b3UgZXhwbGFpbiBtb3JlIGZ1bGx5 IHRoaXMgY29tbWVudC4gDQoNClBGPj4gIElmIHlvdSdyZSB0cnlpbmcgdG8gbWVldCBSRkMgNTY1 NCByZXEgNThiIGluIHBhcnRpY3VsYXIsIEkgd291bGQgDQp0aGluayB5b3UgTVVTVCB2YWxpZGF0 ZSB0aGF0IGVub3VnaCBwcm90ZWN0aW9uIHJlc291cmNlcyBhcmUgYXZhaWxhYmxlIChvciANCmFy ZSBwcmVlbXB0aWJsZSkgdG8gY2FycnkgMTAwJSBvZiB0aGUgc2VydmljZSB0cmFmZmljIHRoYXQg aXMgYmVpbmcgDQpyZXN0b3JlZC4gIEluIGV4aXN0aW5nIHRyYW5zcG9ydCBuZXR3b3JrcyAoaS5l LiBPVE4gLyBzb25ldCksIHRoaXMgaXMgDQp0eXBpY2FsbHkgZG9uZSBiZWZvcmUgeW91IHN3aXRj aCB0cmFmZmljIHRvIHRoZSBwcm90ZWN0aW9uIHBhdGguICBGcm9tIGEgDQpzb2x1dGlvbiBwZXJz cGVjdGl2ZSwgSSB0aGluayB5b3UnbGwgcHJvYmFibHkgd2FudCB0byBsZXZlcmFnZSBzb21ldGhp bmcgDQpsaWtlIHRoZSBsb2NraW5nIG1vZGUgdGhhdCBpcyBiZWluZyBwcm9wb3NlZCBmb3IgdGhl IDE6biBkcmFmdC4gDQoNCi0gTml0OiB5b3UgbWlnaHQgd2FudCB0byBhdm9pZCB1c2luZyB0aGUg InF1ZXJ5IiB2ZXJiIGluIHRoZSB0aXRsZSBvZiANCjQuMS4xIGJlY2F1c2UgaXQgc3VidGx5IHN1 Z2dlc3RzIHNvbWUga2luZCBvZiBwcm90b2NvbCBtZXNzYWdpbmcgaXMgDQpyZXF1aXJlZC4gIEkg d291bGQgdXNlIHRoZSBtb3JlIGdlbmVyaWMgdmVyYiAiY2hlY2tpbmciIG9yICJ2ZXJpZnlpbmci LiANCnl3Pj4gU291bmRzIE9LIHRvIG1lLiANCi0gSW4gNC4zLCB0aGVyZSBpcyBubyBzdWdnZXN0 aW9uIGZvciB3aGF0IHNob3VsZCBoYXBwZW4gaWYgb25lIG9yIG1vcmUgDQpmYWlsaW5nIHBhdGhz IGluIGFuIE1QTFMtVFAgbmV0d29yayBhcmUgb2YgZXF1YWwgcHJpb3JpdHkuICBJIHByZXN1bWUg aXQgDQp3aWxsIGJlIHNvbWUga2luZCBvZiBmaXJzdC1jb21lLCBmaXJzdC1zZXJ2ZSByZXF1aXJl bWVudCBidXQgdGhpcyB3aWxsIA0KYnJpbmcgdXAgdGhlIHF1ZXN0aW9uIG9mIGhvdyB0byBicmVh ayB0aWVzLiANCnl3Pj4gVGhpcyBjb3VsZCBiZSByZXNvbHZlZCBhbG9uZyB0aGUgbGluZXMgdGhh dCBpdCB3YXMgYWRkcmVzc2VkIGluIHRoZSANCjE6biBwcm90ZWN0aW9uIA0KDQpQRj4+IEV4Y2Vw dCB0aGF0IHlvdSBndXlzIHJlbW92ZWQgc2VwYXJhdGUgcGF0aCBwcmlvcml0eSBmcm9tIHRoZSBs YXRlc3QgDQp2ZXJzaW9uIG9mIHRoZSAxOm4gZHJhZnQuICBJbiB0aGUgbGF0ZXN0IHZlcnNpb24s IGVhY2ggcGF0aCBoYXMgYSBzdHJpY3QgDQpwcmlvcml0eSBkZWZpbmVkIGJ5IGl0cyBwYXRoIElE IHNvIHRpZXMgd2VyZSBub3QgcG9zc2libGUuICBJIGRvbid0IHRoaW5rIA0KdGhhdCBzb2x1dGlv biB3aWxsIHdvcmsgZm9yIFNNUCBiZWNhdXNlIEkgaGF2ZSBhIGhhcmQgdGltZSBzZWVpbmcgaG93 IGFsbCANCnRoZSB2YXJpb3VzIGVuZHBvaW50cyBpbnZvbHZlZCBpbiBhIHNoYXJlZCBtZXNoIGNv dWxkIGNvb3JkaW5hdGUgDQpub24tb3ZlcmxhcHBpbmcgcGF0aCBJRHMsIHdoaWxlIGF0IHRoZSBz YW1lIHRpbWUgbm90IGV4Y2VlZGluZyB0aGUgbGltaXQgDQpvZiAyNTUgcGF0aCBJRHMuIA0KDQoN Ci0gQWxzbyBpbiA0LjMsIHRoZXJlIGlzIGFuIGFsbG93YW5jZSBmb3IgYSBoaWdoIHByaW9yaXR5 IHBhdGggYW5kIGEgbG93ZXIgDQpwcmlvcml0eSBwYXRoIHRvIHRlbXBvcmFyaWx5IHNoYXJlIHRo ZSBwcm90ZWN0aW9uIHJlc291cmNlcyB3aGlsZSANCnByZWVtcHRpb24gaXMgdGFraW5nIHBsYWNl LiAgVHdvIHF1ZXN0aW9uczogDQotIElzIHRoZSBpbmdyZXNzIG5vZGUgdG8gdGhlIHNoYXJlZCBz ZWdtZW50IGV4cGVjdGVkIHRvIGRpc2NhcmQgZXhjZXNzIA0KdHJhZmZpYyBub3cgdGhhdCB0aGUg cHJvdGVjdGlvbi1wYXRoIGlzIHRlbXBvcmFyaWx5IG92ZXJzdWJzY3JpYmVkPyANCnl3Pj4gdGhp cyB3b3VsZCBtb3N0IHByb2JhYmx5IGZvbGxvdyBzdGFuZGFyZCBNUExTIGJlaGF2aW9yIGFzIGRl c2NyaWJlZCANCmVsc2V3aGVyZSANCg0KUEY+PiBJIGd1ZXNzIEknbGwgYXNrIHdoYXQgaXMgdGhl IHN0YW5kYXJkIGJlaGF2aW91cj8gIEFuZCBpcyBpdCANCmFwcGxpY2FibGUgdG8gTVBMUy1UUCBu ZXR3b3Jrcz8gDQogDQotIElmIG5vdCwgaG93IGRvIHdlIGVuc3VyZSB0aGF0IG90aGVyIHRyYW5z cG9ydCBwYXRocyBhcmUgdW5hZmZlY3RlZD8gDQotIFRoZSBmaXJzdCBwYXJhZ3JhcGggb2YgNC40 IGFwcGVhcnMgdG8gY29udHJhZGljdCA0LjEuMS4gIDQuNCBzZWVtcyB0byANCnN1Z2dlc3QgdGhh dCBvbmUgTVVTVCBzd2l0Y2ggdGhlIHRyYWZmaWMgb250byB0aGUgcHJvdGVjdGlvbiBwYXRoIGZp cnN0IA0KYW5kIHRoZW4gZ2V0IG5vdGlmaWVkIGlmIHRoZXJlJ3Mgbm90IGVub3VnaCByZXNvdXJj ZXMuICBUaGF0J3MgcHJvYmFibHkgDQpva2F5IGluIHRoZSBnZW5lcmFsIGNhc2UuICBCdXQgaW4g YW4gTVBMUy1UUCBuZXR3b3JrLCBJIGRvbid0IHRoaW5rIGl0J3MgYSANCmdvb2QgaWRlYSB0byBi bGluZGx5IHN3aXRjaCBsb3cgcHJpb3JpdHkgdHJhZmZpYyBvbnRvIHRoZSBwcm90ZWN0aW9uIHBh dGggDQphbmQgcG9zc2libHkgZGlzcnVwdCBhIGhpZ2ggcHJpb3JpdHkgcGF0aCB0aGF0IGlzIGFs cmVhZHkgdXNpbmcgdGhhdCANCnJlc291cmNlLiANCnl3Pj4gVGhpcyBpcyBkZXBlbmRlbnQgdXBv biB0aGUgYWN0dWFsIG1lY2hhbmlzbSB0aGF0IGlzIGRldmVsb3BlZCBieSB0aGUgDQpXRy4gIEZv ciBleGFtcGxlLCBvbmUgc3VnZ2VzdGlvbiBmb3IgdGhlIG1lY2hhbmlzbSBoYXMgbm90aWZpY2F0 aW9ucyBzZW50IA0KdG8gbG93ZXIgcHJpb3JpdHkgd29ya2luZyBwYXRocyBtYWtpbmcgdGhlIHBy b3RlY3Rpb24gcGF0aCB1bmF2YWlsYWJsZSBpZiANCml0IGlzIGluIHVzZSBieSBhIGhpZ2gtcHJp b3JpdHkgd29ya2luZyBwYXRoLiANCiANCi0gSW4gc2VjdGlvbiA0LjUsIHRoZXJlJ3MgYW4gYXR0 ZW1wdCB0byBkZWZpbmUgInByb3RlY3Rpb24gc3dpdGNoaW5nIHRpbWUiIA0KYXMgbm90IGluY2x1 ZGluZyBwcmVlbXB0aW9uIHRpbWUuICBJIGRvbid0IHRoaW5rIGVuZC11c2VycyByZWFsbHkgY2Fy ZSANCmFib3V0ICJwcm90ZWN0aW9uIHN3aXRjaGluZyB0aW1lIi4gIFRoZXkgY2FyZSBhYm91dCBy ZWNvdmVyeSB0aW1lIGFuZCBJTU8sIA0KdGhhdCBzaG91bGQgYWxzbyBpbmNsdWRlIGZhdWx0IGRl dGVjdGlvbiB0aW1lIChhbHRob3VnaCBpdCBkb2Vzbid0IHBlciBSRkMgDQo1NjU0KSBhbmQgYW55 IHByZWVtcHRpb24gdGltZS4gDQp5dz4+IHdlIGRvIHRyeSB0byB3b3JrIHdpdGhpbiB0aGUgYWNj ZXB0ZWQgZGVmaW5pdGlvbnMgb2YgdGhlIElFVEYhIA0KDQpQRj4+IEkgZ3Vlc3MgdGhlcmUncyB0 d28gc2VwYXJhdGUgY29tbWVudHMgaGVyZSB0aGF0IEkga2luZGEgY29uZmxhdGVkIA0KdG9nZXRo ZXIuICBPbmUgd2FzIG1vcmUgb2YgYSBncmlwZTogd2h5IGRpZCB3ZSBleGNsdWRlIGZhdWx0IGRl dGVjdGlvbiANCnRpbWUgZnJvbSB0aGUgNTBtcyByZXN0b3JhdGlvbiB0aW1lIHJlcXVpcmVtZW50 IGluIFJGQyA1NjU0PyAgSSBrbm93IHRoYXQgDQpteSBjdXN0b21lcnMgbWVhc3VyZSBvbmx5IG9u ZSB0aGluZzogaG93IG1hbnkgbXMgb2YgdHJhZmZpYyBkbyB0aGV5IGxvc2UgDQphZnRlciBhIGJy ZWFrYWdlLiAgSSBkb24ndCBnZXQgYSBmcmVlIHBhc3Mgb24gdGhlIH4xMG1zIGl0IHRha2VzIGZv ciBCRkQgDQp0byBkZXRlY3QgdGhlIGZhaWx1cmUuICBBY2NvcmRpbmcgdG8gUkZDIDU2NTQsIEkg Y291bGQgdXNlIDYwc2VjIENDTXMgYW5kIA0Kc3RpbGwgbWVldCB0aGUgNTBtcyByZXF1aXJlbWVu dCEgDQoNClRoZSAybmQgY29tbWVudCB3YXMgcmVhbGx5IGFib3V0IHRoaXMgZHJhZnQgbm93IHRy eWluZyB0byBleGNsdWRlIA0KcHJlZW1wdGlvbiB0aW1lIGZyb20gcmVzdG9yYXRpb24gdGltZSBh cyB3ZWxsLiAgSU1PLCBpZiBpdCB0YWtlcyBhIGZldyANCnNlY29uZHMgZm9yIGEgaGlnaCBwcmlv cml0eSBzZXJ2aWNlIHRvIGZpbmlzaCBwcmVlbXB0aW5nIGEgbG93ZXIgcHJpb3JpdHkgDQpzZXJ2 aWNlLCB0aGVuIHdlIGhhdmVuJ3QgbWV0IHRoZSA1MG1zIHJlc3RvcmF0aW9uIHRpbWUgcmVxdWly ZW1lbnQuIA0KRXNwZWNpYWxseSBzaW5jZSBpdCdzIHR5cGljYWxseSBteSBoaWdoZXIgcHJpb3Jp dHkgc2VydmljZXMgdGhhdCB3YW50IDUwbXMgDQpyZXN0b3JhdGlvbiB0aW1lcyBpbiB0aGUgZmly c3QgcGxhY2UsIHNvIHRoZXknbGwgYmUgbW9yZSBvZnRlbiBpbiBhIA0KcG9zaXRpb24gdG8gcHJl ZW1wdC4gIEluIG90aGVyIHdvcmRzLCBJIHRoaW5rIHdlIHdhbnQgcHJlZW1wdGlvbiB0byBiZSAN CmZhc3QgYW5kIGlzIGEgY3JpdGljYWwgY29tcG9uZW50IG9mIHByb3RlY3Rpb24gc3dpdGNoaW5n LiANCiANCg0KcmVnYXJkcywgDQpQYWJsbyANCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlz dA0KbXBsc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t cGxzDQoNCg0K --=_alternative 0023AB6248257A68_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIERhdmU8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rIHlvdSBmb3IgeW91ciBu aWNlIHJlc3BvbnNlPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5TZWUgaW4gbGluZSB3aXRoICZsdDtmZWkxJmd0OzwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5GZWk8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8 dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM2JT48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+RGF2aWQgQWxsYW4gSSAmbHQ7ZGF2aWQuaS5hbGxh bkBlcmljc3Nvbi5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPjIwMTItMDgtMjggMTM6NDg8L2ZvbnQ+DQo8dGQgd2lkdGg9NjMlPg0KPHRhYmxl IHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7emhhbmcuZmVpM0B6dGUuY29tLmNuJnF1 b3Q7ICZsdDt6aGFuZy5mZWkzQHp0ZS5jb20uY24mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6z rcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5HcmVn b3J5IE1pcnNreSAmbHQ7Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tJmd0OywNCiZxdW90O21w bHNAaWV0Zi5vcmcmcXVvdDsgJmx0O21wbHNAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGln bj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij5SRTogW21wbHNdIENvbW1lbnRzIG9uIGRyYWZ0LXdlaW5nYXJ0ZW4tbXBscy1zbXAtcmVxdWly ZW1lbnRzLTAwLnR4dDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj5ISSBGZWk6PC9mb250Pg0KPGJyPjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPllvdSB3cm90ZTo8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0zIGZhY2U9IkFyaWFsIj4mbmJzcDsmbHQ7ZmVpJmd0OyBJTUhPLCB0aGVyZSBhcmUgdHdv IHByaW9yaXRpZXMNCm5lZWQgdG8gYmUgaGFuZGxlZCBpbiBzaGFyZWQgbWVzaCBwcm90ZWN0aW9u IHNjZW5hcmlvcywgdGhlIHBhdGggcHJpb3JpdHkNCmFuZCB0aGUgc2VydmljZSBwcmlvcml0eSAo UEhCKS4gSWYgbm9kZSBFIGRvZXMgdGhlIHByZWVtcHRpb24sIGhvdyB0byA8YnI+DQpkZWFsIHdp dGggdGhlIHBhdGggcHJpb3JpdHksIHdoaWNoIGlzIG5vdCBjYXJyaWVkIGluIHRyYWZmaWMgcGFj a2V0LiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPk15 IHVuZGVyc3RhbmRpbmcgb2YgeW91ciBwcm9wb3NhbA0KaXMgdGhhdCB2aWEgY29udHJvbCBwbGFu ZSBleGNoYW5nZSwgRSBrbm93cyB0aGUgcGF0aCBwcmlvcml0eS4gQ2VydGFpbmx5DQp0aGUgaW5n cmVzc2VzIGFyZSB1bmF3YXJlIG9mIGVhY2ggb3RoZXIgd2l0aG91dCBhIGNvb3JkaW5hdGlvbiBt ZWNoYW5pc20NCndoaWNoIGFzIGN1cnJlbnRseSBkZXNjcmliZWQgaXMgbm90aWZpY2F0aW9ucyBv cmlnaW5hdGluZyB3aXRoIEUuIE15IHN1Z2dlc3Rpb24NCmlzIHRoYXQgdGhlIEUgYXMgdGhlIHBy ZWVtcHRpb24gcG9pbnQgaGFzIHN1ZmZpY2llbnQga25vd2xlZGdlIHRvIHBlcmZvcm0NCnRoaXMg ZnVuY3Rpb24sIGFuZCB3b3VsZCBkbyBpdCB3aXRoIGxlc3MgbGF0ZW5jeSB0aGFuIGhlYWQgZW5k IG5vdGlmaWNhdGlvbg0KYW5kIHRoZSBoZWFkIGVuZCBhcyB0aGUgcHJlZW1wdGlvbiBwb2ludC4g SXQgaGFzIHRoZSBhZGRlZCBwbHVzIG9mIG5vdA0KYmVpbmcgZGVwZW5kZW50IG9uIHRoZSBoZWFk IGVuZCBub3QgYmVpbmcgYnJhaW4gZGVhZC4uLi48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0zIGZhY2U9IkFyaWFsIj4mbmJzcDsmbHQ7ZmVpMSZndDsgT2ssIEkgdGhpbmsgSSB1bmRlcnN0 YW5kDQp5b3VyIGlkZWEgbm93LiAmbmJzcDtJTUhPLCAmbmJzcDthbHRob3VnaCB0aGUgcmVxdWly ZW1lbnRzIGFyZSBjb21pbmcgZnJvbQ0KTVBMUy1UUCwgdGhlIHN0YW5kYXJkIGhhZCBiZXR0ZXIg Y292ZXJpbmcgdGhlIG90aGVyIHNjZW5hcmlvcy4gQ29uc2lkZXINCnRoZSBPRFUyIHBhdGggYXMg dGhlIHNoYXJlZCBwYXRoIHNlZ21lbnQsIGFuZCB0aGUgbm9kZSBFIGFzIHRoZSBwcmVlbXB0aW9u DQpwb2ludCAoanVzdCBhcyB5b3Ugc2FpZCkuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MyBmYWNlPSJBcmlhbCI+dDAgSC1FLUYtRy1LIGFzIHRoZSBwcm90ZWN0aW5nIHBhdGggYXJlIHBy b3RlY3RpbmcNCnRoZSB3b3JrIHBhdGggSC1JLUotSzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMg ZmFjZT0iQXJpYWwiPnQxIEEtQi1DLUQgaXMgYnJva2VuLCBub2RlIEEgc3dpdGNoZXMgdGhlDQp0 cmFmZmljIHRvIEEtRTwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPnQyIG5v ZGUgRSBzd2l0Y2hlcyB0aGUgY3Jvc3Njb25uZWN0IGZyb20NCkgtRSB0byBBLUUgKHBhdGggQS1C LUMtRCBoYXMgaGlnaGVyIHByaW9yaXR5IHRoYW4gSC1JLUotSyk8L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj5Ib3dldmVyLCBub2RlIEcgY2FuIG5vdCBtYWtlIHN1 cmUgdG8gc3dpdGNoDQp0aGUgY3Jvc3Njb25uZWN0IGZyb20gRy1LIHRvIEctRCBzaW11bHRhbmVv dXNseSBhcyBhdCBub2RlIEUuIE1pc2Nvbm5lY3Rpb24NCndpbGwgaGFwcGVuLjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+SSBob3BlIHRoaXMg aGVscHM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPkRh dmU8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8aHI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+ RnJvbTo8L2I+IHpoYW5nLmZlaTNAenRlLmNvbS5jbiBbbWFpbHRvOnpoYW5nLmZlaTNAenRlLmNv bS5jbl0NCjxiPjxicj4NClNlbnQ6PC9iPiBUdWVzZGF5LCBBdWd1c3QgMjgsIDIwMTIgNTo1MiBB TTxiPjxicj4NClRvOjwvYj4gRGF2aWQgQWxsYW4gSTxiPjxicj4NCkNjOjwvYj4gR3JlZ29yeSBN aXJza3k7IG1wbHNAaWV0Zi5vcmc8Yj48YnI+DQpTdWJqZWN0OjwvYj4gUkU6IFttcGxzXSBDb21t ZW50cyBvbiBkcmFmdC13ZWluZ2FydGVuLW1wbHMtc21wLXJlcXVpcmVtZW50cy0wMC50eHQ8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KSGkgRGF2ZTwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+PGJyPg0KU29ycnkgZm9yIHRoZSBkZWxheWVkIHJlc3BvbnNlLCBzZWUgbXkgbm90 ZXMgdGFnZ2VkIHdpdGggJmx0O2ZlaSZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPg0KPGJyPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij48YnI+DQpUaGFua3M8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+ DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkZlaTwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjxicj4NCjwvZm9udD4NCjx0YWJs ZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzMlPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5EYXZpZCBBbGxhbiBJICZsdDtkYXZpZC5pLmFsbGFuQGVy aWNzc29uLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+MjAxMi0wOC0yMiAwMToyOTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+DQo8L2ZvbnQ+DQo8dGQgd2lkdGg9NjYlPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD01JT4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZCB3aWR0aD05NCU+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O3poYW5nLmZlaTNAenRlLmNvbS5j biZxdW90Ow0KJmx0O3poYW5nLmZlaTNAenRlLmNvbS5jbiZndDssIEdyZWdvcnkgTWlyc2t5ICZs dDtncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20mZ3Q7PC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGln bj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4N Cjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7bXBsc0BpZXRmLm9yZyZx dW90OyAmbHQ7bXBsc0BpZXRmLm9yZyZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPg0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SRTogW21wbHNdIENvbW1lbnRzIG9uIGRyYWZ0 LXdlaW5nYXJ0ZW4tbXBscy1zbXAtcmVxdWlyZW1lbnRzLTAwLnR4dDwvZm9udD48L3RhYmxlPg0K PGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0 aD01MCU+DQo8dGQgd2lkdGg9NTAlPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBj b2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48YnI+DQpIaSBGZWk6PC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9 Ymx1ZSBmYWNlPSJBcmlhbCI+PGJyPg0KSSBzZWUgJnF1b3Q7YSZxdW90OyBwcm9wb3NlZCBzb2x1 dGlvbiBpbiB0aGUgZHJhZnQgeW91IHJlZmVyZW5jZSwgYnV0IG5vdA0KYSBwcm9ibGVtIHN0YXRl bWVudCBvciBhbmFsc3lzaXM8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0K PGJyPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+PGJyPg0KJmx0O2ZlaSZndDsg Jm5ic3A7VGhlIHByb3Bvc2VkIHNvbHV0aW9uIGlzIGJhc2Ugb24gdGhlIGNvbnRyb2wgcGxhbmUg ZXh0ZW5zaW9ucywNCmFuZCB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgc2FpZCAmcXVvdDsgW1JGQzQ4 NzJdIGRlZmluZXMgdGhlIHNoYXJlZCBtZXNoDQpyZXN0b3JhdGlvbiBzY2hlbWVzIGJhc2VkIG9u PGJyPg0KICZuYnNwO2NvbnRyb2wgcGxhbmUgZXh0ZW5zaW9ucywgYnV0IGRvZXMgbm90IGNvdmVy IHRoZSBzaGFyZWQgbWVzaCAmbmJzcDtwcm90ZWN0aW9uDQpzY2VuYXJpb3MuJnF1b3Q7PC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KICZuYnNwOzwvZm9udD48Zm9u dCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PGJyPg0KVGhlIHByZWVtcHRpb24gY291 bGQgc2ltcGx5IGJlIHBlcmZvcm1lZCBhdCBub2RlIEUuIEN1cnJlbnRseSB0aGUgbW9kZWwNCmlz IHRoYXQgdGhlIExFUnMgbmVlZCB0byBub3RpZnkgbm9kZSBFIHdoZW4gdGhlIFAgcGF0aCBpcyBi ZWluZyB1c2VkLCBhbmQNCkUgbmVlZHMgdG8gbm90aWZ5IHRoZSBMRVJzIG9mIHRoZSBjdXJyZW50 IHN0YXRlIG9mIHRoZSBzaGFyZWQgcmVzb3VyY2UuDQombmJzcDtUaGlzIGFwcGVhcnMgdG8gZGVw ZW5kIG9uIHRoZSBwcmVlbXB0ZWQgTFNSIHRvICZxdW90O2RvIHRoZSByaWdodA0KdGhpbmcmcXVv dDsgYW5kIGxlYWRzIHRvIGFuIElNTyB1bnJlYXNvbmFibGUgd2luZG93IG9mIGNvbnRlbnRpb24g Zm9yIHRoZQ0Kc2hhcmVkIHJlc291cmNlcy48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48YnI+DQogJm5i c3A7Jmx0O2ZlaSZndDsgUHJlZW1wdGlvbiBtZWFucyB0aGF0ICZuYnNwO3RoZXJlIHdpbGwgYmUg YSB3aW5kb3cgb2YNCmNvbnRlbnRpb24sIHdoeSBpdCBpcyB1bnJlYXNvbmFibGU/PC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIg Y29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PGJyPg0KSU1PIEUgc2hvdWxkIGJlIGRvaW5nIHRoZSBw cmVlbXB0aW9uLCBhbmQgSSd2ZSBzdGlsbCBub3QgcmVhbGx5IHNlZW4gYQ0KbmVlZCBmb3IgaGVh ZCBlbmQgbm90aWZpY2F0aW9uIG9mIHByZWVtcHRpb24gdW5sZXNzIG9uZSBzdGFydHMgcGxhbm5p bmcNCmJhY2t1cHMgZm9yIGJhY2t1cHMuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+PGJyPg0KICZuYnNw OyZsdDtmZWkmZ3Q7IElNSE8sIHRoZXJlIGFyZSB0d28gcHJpb3JpdGllcyBuZWVkIHRvIGJlIGhh bmRsZWQgaW4NCnNoYXJlZCBtZXNoIHByb3RlY3Rpb24gc2NlbmFyaW9zLCB0aGUgcGF0aCBwcmlv cml0eSBhbmQgdGhlIHNlcnZpY2UgcHJpb3JpdHkNCihQSEIpLiBJZiBub2RlIEUgZG9lcyB0aGUg cHJlZW1wdGlvbiwgaG93IHRvIDxicj4NCmRlYWwgd2l0aCB0aGUgcGF0aCBwcmlvcml0eSwgd2hp Y2ggaXMgbm90IGNhcnJpZWQgaW4gdHJhZmZpYyBwYWNrZXQuIDwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9 Ymx1ZSBmYWNlPSJBcmlhbCI+PGJyPg0KSWYgeW91IGhhdmUgbW9yZSBpbmZvcm1hdGlvbiwgY291 bGQgeW91IGVsYWJvcmFibGU/PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4N CjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PGJyPg0KRGF2ZTwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCiAmbmJzcDs8YnI+DQog Jm5ic3A7PGJyPg0KPGJyPg0KPC9mb250Pg0KPGhyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEi PjxiPkZyb206PC9iPiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNA aWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPnpoYW5nLmZlaTNAenRlLmNvbS5jbjxiPjxi cj4NClNlbnQ6PC9iPiBNb25kYXksIEF1Z3VzdCAyMCwgMjAxMiA0OjAzIEFNPGI+PGJyPg0KVG86 PC9iPiBHcmVnb3J5IE1pcnNreTxiPjxicj4NCkNjOjwvYj4gbXBsc0BpZXRmLm9yZzsgbXBscy1i b3VuY2VzQGlldGYub3JnPGI+PGJyPg0KU3ViamVjdDo8L2I+IFJlOiBbbXBsc10gQ29tbWVudHMg b24gZHJhZnQtd2VpbmdhcnRlbi1tcGxzLXNtcC1yZXF1aXJlbWVudHMtMDAudHh0PC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCkdyZWcsIHNuaXBwZWQ8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+DQo8dWw+DQo8bGk+PGZvbnQgc2l6ZT0yIGNv bG9yPWJsdWUgZmFjZT0iQXJpYWwiPkluIHRoZSBsYXN0IHNlbnRlbmNlIG9mIFNlY3Rpb24NCjMu MSBub24tY29udHJvbCBwbGFuZSBjb29yZGluYXRpb24gb2Ygc2hhcmVkIHJlc291cmNlcyBwcmVz ZW50ZWQgYXMgYW5vdGhlcg0KcmVxdWlyZW1lbnQuIEFuZCBhZ2FpbiBJIGNhbiBub3QgZmluZCBo b3cgd2UgY29tZSB0byBzdWNoIGNvbmNsdXNpb24sIHdoZXJlDQp0aGUgc291cmNlIG9mIHRoaXMg cmVxdWlyZW1lbnQuIFdvdWxkIGV4aXN0aW5nIGNvbnRyb2wgcGxhbmUgc2lnbmFsaW5nDQpzb2x1 dGlvbiBiZSBzdWZmaWNpZW50IGZvciBhIE1QTFMgbmV0d29yaz8gPC9mb250PjwvdWw+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCiZsdDtGZWkmZ3Q7IEkgZG8gbm90IHRoaW5r IHRoZSBleGlzdGluZyBjb250cm9sIHBsYW5lIChkZWZpbmVkIGluIFJGQzQ4NzIpDQppcyBzdWZm aWNpZW50IGZvciBhIE1QTFMgbmV0d29yaywgYW5kIHRoZXJlIGlzIGFuIGFuYWx5c2lzIGluIHRo ZSBkcmFmdA0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGUtY2NhbXAtbm90aWZp Y2F0aW9uLXNoYXJlZC1tZXNoLXByb3RlY3Rpb24tMDAuDQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+PGJyPg0KPGJyPg0KQmVzdCByZWdhcmRzPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+ DQpGZWk8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8YnI+DQo8 L2ZvbnQ+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM5 JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+R3JlZ29yeSBNaXJza3kgJmx0O2dy ZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbSZndDs8L2I+DQo8YnI+DQq3orz+yMs6ICZuYnNwO21w bHMtYm91bmNlc0BpZXRmLm9yZzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMi0wOC0xNiAw Njo0NTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dGQg d2lkdGg9NjAlPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZCB3aWR0aD03JT4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZCB3aWR0aD05MiU+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPlBhYmxvIEZyYW5rICZsdDtwYWJsb2lzbm90QGdtYWlsLmNvbSZndDssDQpZ YWFjb3YgV2VpbmdhcnRlbiAmbHQ7d3lhYWNvdkBnbWFpbC5jb20mZ3Q7PC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9u dD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7bXBsc0Bp ZXRmLm9yZyZxdW90OyAmbHQ7bXBsc0BpZXRmLm9yZyZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2 Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW21wbHNdIENvbW1lbnRz IG9uIGRyYWZ0LXdlaW5nYXJ0ZW4tbXBscy1zbXAtcmVxdWlyZW1lbnRzLTAwLnR4dDwvZm9udD48 L3RhYmxlPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+ DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTUw JT4NCjx0ZCB3aWR0aD01MCU+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9y PWJsdWUgZmFjZT0iQXJpYWwiPjxicj4NCjxicj4NCkRlYXIgUGFibG8sIFlhYWNvdiwgZXQgYWwu LDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXpl PTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PGJyPg0KSSd2ZSBiZWVuIGZvbGxvd2luZyBkaXNj dXNzaW9uIHdpdGggZ3JlYXQgZGVhbCBvZiBpbnRlcmVzdC4gSSBoYXZlIHNvbWUNCnF1ZXN0aW9u cyBpbiBhZGRpdGlvbiB0byBvbmVzIGJlaW5nIGJyb3VnaHQgdXAgYnkgUGFibG86PC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx1bD4NCjxsaT48Zm9udCBz aXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+U2VjdGlvbiAxLjIgcmVmZXJzIHRvIG9wZXJh dG9yJ3MNCmRlc2lyZSB0byBoYXZlIHNlcnZpY2UgcmVzdG9yYXRpb24gbW9yZSBleHBlZGllbnQg dGhhbiBvbmUgYWNoaWV2YWJsZSB3aXRoDQpjb250cm9sIHBsYW5lLiBJIGhhdmVuJ3Qgc2VlbiBh bnkgcXVhbnRhdGl2ZSBpbmZvcm1hdGlvbiB0byBjb21wYXJlIHdpdGguDQpXaGF0IGlzICZxdW90 O2V4cGVkaWVudCBlbm91Z2gmcXVvdDsgZm9yIFNNUD88L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPGxpPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9 IkFyaWFsIj5TZWN0aW9uIDMuMSBkZXNyY2liZXMsIHdoYXQgY2FuDQpiZSBjYWxsZWQsICZxdW90 O2luc3RhbnQgZGV0ZXJtaW5pc20mcXVvdDsgaW4gcmVnYXJkIHRvIFNNUCByZXNvdXJjZSBhdmFp YWxhYmlsaXR5Lg0KSSB0aGluayB0aGF0IHRoZXJlJ3Mgbm90IGVub3VnaCByZWFzb25pbmcgdG8g Y29uY2x1ZGUgdGhhdCBhbG1vc3QgaW5zdGFudGVuZW91cw0KdXBkYXRlIG9mIFNNUCByZXNvdXJj ZXMgYXZhaWFsYWJpbGl0eSBpcyByZXF1aXJlZC48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPg0KPC9mb250Pg0KPGxpPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFy aWFsIj5JbiB0aGUgbGFzdCBzZW50ZW5jZSBvZiBTZWN0aW9uDQozLjEgbm9uLWNvbnRyb2wgcGxh bmUgY29vcmRpbmF0aW9uIG9mIHNoYXJlZCByZXNvdXJjZXMgcHJlc2VudGVkIGFzIGFub3RoZXIN CnJlcXVpcmVtZW50LiBBbmQgYWdhaW4gSSBjYW4gbm90IGZpbmQgaG93IHdlIGNvbWUgdG8gc3Vj aCBjb25jbHVzaW9uLCB3aGVyZQ0KdGhlIHNvdXJjZSBvZiB0aGlzIHJlcXVpcmVtZW50LiBXb3Vs ZCBleGlzdGluZyBjb250cm9sIHBsYW5lIHNpZ25hbGluZw0Kc29sdXRpb24gYmUgc3VmZmljaWVu dCBmb3IgYSBNUExTIG5ldHdvcms/PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij4NCjwvZm9udD4NCjxsaT48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+SSd2 ZSBub3RpY2VkIHRoYXQgbWFueSByZXF1aXJlbWVudHMNCmJlaW5nIHJlZmVycmVkIHRvIE1QTFMt VFAsIG5vdCBNUExTLCBuZXR3b3Jrcy4gV291bGQgdGhhdCBiZSBhIGdvb2QgcmVhc29uDQp0byBu YXJyb3cgc2NvcGUgb2YgdGhlIGRvY3VtZW50IHRvIE1QTFMtVFAgbmV0d29ya3Mgb25seSwgc3Rh cnRpbmcgd2l0aA0KdGhlIG5hbWUgb2YgdGhlIGRvY3VtZW50PzwvZm9udD48L3VsPjxmb250IHNp emU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj4mbmJzcDsNCiZuYnNwOyBSZWdhcmRzLDwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCiAmbmJzcDsgJm5ic3A7ICZu YnNwOyA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPkdyZWc8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KPGJyPg0KPC9mb250Pg0K PGhyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPkZyb206PC9iPiBtcGxzLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPlBhYmxvIEZyYW5rPGI+PGJyPg0KU2VudDo8L2I+IEZyaWRheSwgQXVndXN0IDEwLCAyMDEy IDc6MjMgQU08Yj48YnI+DQpUbzo8L2I+IFlhYWNvdiBXZWluZ2FydGVuPGI+PGJyPg0KQ2M6PC9i PiBtcGxzQGlldGYub3JnPGI+PGJyPg0KU3ViamVjdDo8L2I+IFJlOiBbbXBsc10gQ29tbWVudHMg b24gZHJhZnQtd2VpbmdhcnRlbi1tcGxzLXNtcC1yZXF1aXJlbWVudHMtMDAudHh0PC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQpIaSBZYWFjb3YsIDxicj4N Cjxicj4NClNvbWUgbW9yZSBjb21tZW50cyBpbmxpbmUuLi4gUEYmZ3Q7Jmd0Ozxicj4NCjxicj4N Ck9uIE1vbiwgQXVnIDYsIDIwMTIgYXQgODo1NiBBTSwgWWFhY292IFdlaW5nYXJ0ZW4gJmx0Ozwv Zm9udD48YSBocmVmPW1haWx0bzp3eWFhY292QGdtYWlsLmNvbSB0YXJnZXQ9X2JsYW5rPjxmb250 IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pnd5YWFjb3ZAZ21haWwuY29t PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZndDsNCndyb3Rl OiA8YnI+DQpIaSwgPGJyPg0KPGJyPg0KVGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnRzLiAmbmJz cDtQbGVhc2Ugc2VlIG15IGNvbW1lbnRzIGlubGluZSBiZWxvdy4NCjxicj4NCjxicj4NCkJSLCA8 YnI+DQp5YWFjb3Y8YnI+DQo8YnI+DQpPbiBUdWUsIEp1bCAxNywgMjAxMiBhdCAxMTo1MSBQTSwg UGFibG8gRnJhbmsgJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzpwYWJsb2lzbm90QGdtYWlsLmNv bSB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYi Pjx1PnBhYmxvaXNub3RAZ21haWwuY29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPiZndDsNCndyb3RlOiA8YnI+DQpHb29kIGRyYWZ0IGFuZCBjZXJ0YWlubHkg c29tZXRoaW5nIHRoYXQgbmVlZHMgdG8gYmUgZG9uZSBiZWZvcmUgd2UgY2FuDQpzdGFydCBkaXNj dXNzaW5nIHNwZWNpZmljIHNvbHV0aW9ucy4gPGJyPg0KPGJyPg0KT25seSBhIGZldyBjb21tZW50 cyAvIHF1ZXN0aW9uczogPGJyPg0KPGJyPg0KLSBJbiA0LjEuMSwgaWYgb25lIGlzIG9wZXJhdGlu ZyBpbiBhbiBNUExTLVRQIG5ldHdvcmsgdGhhdCByZXF1aXJlcyBleGNsdXNpdmUNCnVzZSBvZiB0 aGUgcHJvdGVjdGlvbiByZXNvdXJjZXMsIGRvZXNuJ3QgdGhpcyBTSE9VTEQgcmVxdWlyZW1lbnQg YmVjb21lDQphIE1VU1QgcmVxdWlyZW1lbnQ/IDxicj4NCjxicj4NCnl3Jmd0OyZndDsgU29ycnkg LSBidXQgY291bGQgeW91IGV4cGxhaW4gbW9yZSBmdWxseSB0aGlzIGNvbW1lbnQuIDxicj4NCjxi cj4NClBGJmd0OyZndDsgJm5ic3A7SWYgeW91J3JlIHRyeWluZyB0byBtZWV0IFJGQyA1NjU0IHJl cSA1OGIgaW4gcGFydGljdWxhciwNCkkgd291bGQgdGhpbmsgeW91IE1VU1QgdmFsaWRhdGUgdGhh dCBlbm91Z2ggcHJvdGVjdGlvbiByZXNvdXJjZXMgYXJlIGF2YWlsYWJsZQ0KKG9yIGFyZSBwcmVl bXB0aWJsZSkgdG8gY2FycnkgMTAwJSBvZiB0aGUgc2VydmljZSB0cmFmZmljIHRoYXQgaXMgYmVp bmcNCnJlc3RvcmVkLiAmbmJzcDtJbiBleGlzdGluZyB0cmFuc3BvcnQgbmV0d29ya3MgKGkuZS4g T1ROIC8gc29uZXQpLCB0aGlzDQppcyB0eXBpY2FsbHkgZG9uZSBiZWZvcmUgeW91IHN3aXRjaCB0 cmFmZmljIHRvIHRoZSBwcm90ZWN0aW9uIHBhdGguICZuYnNwO0Zyb20NCmEgc29sdXRpb24gcGVy c3BlY3RpdmUsIEkgdGhpbmsgeW91J2xsIHByb2JhYmx5IHdhbnQgdG8gbGV2ZXJhZ2Ugc29tZXRo aW5nDQpsaWtlIHRoZSBsb2NraW5nIG1vZGUgdGhhdCBpcyBiZWluZyBwcm9wb3NlZCBmb3IgdGhl IDE6biBkcmFmdC4gPGJyPg0KPGJyPg0KLSBOaXQ6IHlvdSBtaWdodCB3YW50IHRvIGF2b2lkIHVz aW5nIHRoZSAmcXVvdDtxdWVyeSZxdW90OyB2ZXJiIGluIHRoZQ0KdGl0bGUgb2YgNC4xLjEgYmVj YXVzZSBpdCBzdWJ0bHkgc3VnZ2VzdHMgc29tZSBraW5kIG9mIHByb3RvY29sIG1lc3NhZ2luZw0K aXMgcmVxdWlyZWQuICZuYnNwO0kgd291bGQgdXNlIHRoZSBtb3JlIGdlbmVyaWMgdmVyYiAmcXVv dDtjaGVja2luZyZxdW90Ow0Kb3IgJnF1b3Q7dmVyaWZ5aW5nJnF1b3Q7LiA8YnI+DQp5dyZndDsm Z3Q7IFNvdW5kcyBPSyB0byBtZS4gPGJyPg0KLSBJbiA0LjMsIHRoZXJlIGlzIG5vIHN1Z2dlc3Rp b24gZm9yIHdoYXQgc2hvdWxkIGhhcHBlbiBpZiBvbmUgb3IgbW9yZQ0KZmFpbGluZyBwYXRocyBp biBhbiBNUExTLVRQIG5ldHdvcmsgYXJlIG9mIGVxdWFsIHByaW9yaXR5LiAmbmJzcDtJIHByZXN1 bWUNCml0IHdpbGwgYmUgc29tZSBraW5kIG9mIGZpcnN0LWNvbWUsIGZpcnN0LXNlcnZlIHJlcXVp cmVtZW50IGJ1dCB0aGlzIHdpbGwNCmJyaW5nIHVwIHRoZSBxdWVzdGlvbiBvZiBob3cgdG8gYnJl YWsgdGllcy4gPGJyPg0KeXcmZ3Q7Jmd0OyBUaGlzIGNvdWxkIGJlIHJlc29sdmVkIGFsb25nIHRo ZSBsaW5lcyB0aGF0IGl0IHdhcyBhZGRyZXNzZWQNCmluIHRoZSAxOm4gcHJvdGVjdGlvbiA8YnI+ DQo8YnI+DQpQRiZndDsmZ3Q7IEV4Y2VwdCB0aGF0IHlvdSBndXlzIHJlbW92ZWQgc2VwYXJhdGUg cGF0aCBwcmlvcml0eSBmcm9tIHRoZQ0KbGF0ZXN0IHZlcnNpb24gb2YgdGhlIDE6biBkcmFmdC4g Jm5ic3A7SW4gdGhlIGxhdGVzdCB2ZXJzaW9uLCBlYWNoIHBhdGgNCmhhcyBhIHN0cmljdCBwcmlv cml0eSBkZWZpbmVkIGJ5IGl0cyBwYXRoIElEIHNvIHRpZXMgd2VyZSBub3QgcG9zc2libGUuDQom bmJzcDtJIGRvbid0IHRoaW5rIHRoYXQgc29sdXRpb24gd2lsbCB3b3JrIGZvciBTTVAgYmVjYXVz ZSBJIGhhdmUgYSBoYXJkDQp0aW1lIHNlZWluZyBob3cgYWxsIHRoZSB2YXJpb3VzIGVuZHBvaW50 cyBpbnZvbHZlZCBpbiBhIHNoYXJlZCBtZXNoIGNvdWxkDQpjb29yZGluYXRlIG5vbi1vdmVybGFw cGluZyBwYXRoIElEcywgd2hpbGUgYXQgdGhlIHNhbWUgdGltZSBub3QgZXhjZWVkaW5nDQp0aGUg bGltaXQgb2YgMjU1IHBhdGggSURzLiA8YnI+DQo8YnI+DQo8YnI+DQotIEFsc28gaW4gNC4zLCB0 aGVyZSBpcyBhbiBhbGxvd2FuY2UgZm9yIGEgaGlnaCBwcmlvcml0eSBwYXRoIGFuZCBhIGxvd2Vy DQpwcmlvcml0eSBwYXRoIHRvIHRlbXBvcmFyaWx5IHNoYXJlIHRoZSBwcm90ZWN0aW9uIHJlc291 cmNlcyB3aGlsZSBwcmVlbXB0aW9uDQppcyB0YWtpbmcgcGxhY2UuICZuYnNwO1R3byBxdWVzdGlv bnM6IDxicj4NCi0gSXMgdGhlIGluZ3Jlc3Mgbm9kZSB0byB0aGUgc2hhcmVkIHNlZ21lbnQgZXhw ZWN0ZWQgdG8gZGlzY2FyZCBleGNlc3MNCnRyYWZmaWMgbm93IHRoYXQgdGhlIHByb3RlY3Rpb24t cGF0aCBpcyB0ZW1wb3JhcmlseSBvdmVyc3Vic2NyaWJlZD8gPGJyPg0KeXcmZ3Q7Jmd0OyB0aGlz IHdvdWxkIG1vc3QgcHJvYmFibHkgZm9sbG93IHN0YW5kYXJkIE1QTFMgYmVoYXZpb3IgYXMgZGVz Y3JpYmVkDQplbHNld2hlcmUgPGJyPg0KPGJyPg0KUEYmZ3Q7Jmd0OyBJIGd1ZXNzIEknbGwgYXNr IHdoYXQgaXMgdGhlIHN0YW5kYXJkIGJlaGF2aW91cj8gJm5ic3A7QW5kIGlzDQppdCBhcHBsaWNh YmxlIHRvIE1QTFMtVFAgbmV0d29ya3M/IDxicj4NCiA8YnI+DQotIElmIG5vdCwgaG93IGRvIHdl IGVuc3VyZSB0aGF0IG90aGVyIHRyYW5zcG9ydCBwYXRocyBhcmUgdW5hZmZlY3RlZD8gPGJyPg0K LSBUaGUgZmlyc3QgcGFyYWdyYXBoIG9mIDQuNCBhcHBlYXJzIHRvIGNvbnRyYWRpY3QgNC4xLjEu ICZuYnNwOzQuNCBzZWVtcw0KdG8gc3VnZ2VzdCB0aGF0IG9uZSBNVVNUIHN3aXRjaCB0aGUgdHJh ZmZpYyBvbnRvIHRoZSBwcm90ZWN0aW9uIHBhdGggZmlyc3QNCmFuZCB0aGVuIGdldCBub3RpZmll ZCBpZiB0aGVyZSdzIG5vdCBlbm91Z2ggcmVzb3VyY2VzLiAmbmJzcDtUaGF0J3MgcHJvYmFibHkN Cm9rYXkgaW4gdGhlIGdlbmVyYWwgY2FzZS4gJm5ic3A7QnV0IGluIGFuIE1QTFMtVFAgbmV0d29y aywgSSBkb24ndCB0aGluaw0KaXQncyBhIGdvb2QgaWRlYSB0byBibGluZGx5IHN3aXRjaCBsb3cg cHJpb3JpdHkgdHJhZmZpYyBvbnRvIHRoZSBwcm90ZWN0aW9uDQpwYXRoIGFuZCBwb3NzaWJseSBk aXNydXB0IGEgaGlnaCBwcmlvcml0eSBwYXRoIHRoYXQgaXMgYWxyZWFkeSB1c2luZyB0aGF0DQpy ZXNvdXJjZS4gPGJyPg0KeXcmZ3Q7Jmd0OyBUaGlzIGlzIGRlcGVuZGVudCB1cG9uIHRoZSBhY3R1 YWwgbWVjaGFuaXNtIHRoYXQgaXMgZGV2ZWxvcGVkDQpieSB0aGUgV0cuICZuYnNwO0ZvciBleGFt cGxlLCBvbmUgc3VnZ2VzdGlvbiBmb3IgdGhlIG1lY2hhbmlzbSBoYXMgbm90aWZpY2F0aW9ucw0K c2VudCB0byBsb3dlciBwcmlvcml0eSB3b3JraW5nIHBhdGhzIG1ha2luZyB0aGUgcHJvdGVjdGlv biBwYXRoIHVuYXZhaWxhYmxlDQppZiBpdCBpcyBpbiB1c2UgYnkgYSBoaWdoLXByaW9yaXR5IHdv cmtpbmcgcGF0aC4gPGJyPg0KIDxicj4NCi0gSW4gc2VjdGlvbiA0LjUsIHRoZXJlJ3MgYW4gYXR0 ZW1wdCB0byBkZWZpbmUgJnF1b3Q7cHJvdGVjdGlvbiBzd2l0Y2hpbmcNCnRpbWUmcXVvdDsgYXMg bm90IGluY2x1ZGluZyBwcmVlbXB0aW9uIHRpbWUuICZuYnNwO0kgZG9uJ3QgdGhpbmsgZW5kLXVz ZXJzDQpyZWFsbHkgY2FyZSBhYm91dCAmcXVvdDtwcm90ZWN0aW9uIHN3aXRjaGluZyB0aW1lJnF1 b3Q7LiAmbmJzcDtUaGV5IGNhcmUNCmFib3V0IHJlY292ZXJ5IHRpbWUgYW5kIElNTywgdGhhdCBz aG91bGQgYWxzbyBpbmNsdWRlIGZhdWx0IGRldGVjdGlvbiB0aW1lDQooYWx0aG91Z2ggaXQgZG9l c24ndCBwZXIgUkZDIDU2NTQpIGFuZCBhbnkgcHJlZW1wdGlvbiB0aW1lLiA8YnI+DQp5dyZndDsm Z3Q7IHdlIGRvIHRyeSB0byB3b3JrIHdpdGhpbiB0aGUgYWNjZXB0ZWQgZGVmaW5pdGlvbnMgb2Yg dGhlIElFVEYhDQo8YnI+DQo8YnI+DQpQRiZndDsmZ3Q7IEkgZ3Vlc3MgdGhlcmUncyB0d28gc2Vw YXJhdGUgY29tbWVudHMgaGVyZSB0aGF0IEkga2luZGEgY29uZmxhdGVkDQp0b2dldGhlci4gJm5i c3A7T25lIHdhcyBtb3JlIG9mIGEgZ3JpcGU6IHdoeSBkaWQgd2UgZXhjbHVkZSBmYXVsdCBkZXRl Y3Rpb24NCnRpbWUgZnJvbSB0aGUgNTBtcyByZXN0b3JhdGlvbiB0aW1lIHJlcXVpcmVtZW50IGlu IFJGQyA1NjU0PyAmbmJzcDtJIGtub3cNCnRoYXQgbXkgY3VzdG9tZXJzIG1lYXN1cmUgb25seSBv bmUgdGhpbmc6IGhvdyBtYW55IG1zIG9mIHRyYWZmaWMgZG8gdGhleQ0KbG9zZSBhZnRlciBhIGJy ZWFrYWdlLiAmbmJzcDtJIGRvbid0IGdldCBhIGZyZWUgcGFzcyBvbiB0aGUgfjEwbXMgaXQgdGFr ZXMNCmZvciBCRkQgdG8gZGV0ZWN0IHRoZSBmYWlsdXJlLiAmbmJzcDtBY2NvcmRpbmcgdG8gUkZD IDU2NTQsIEkgY291bGQgdXNlDQo2MHNlYyBDQ01zIGFuZCBzdGlsbCBtZWV0IHRoZSA1MG1zIHJl cXVpcmVtZW50ISA8YnI+DQo8YnI+DQpUaGUgMm5kIGNvbW1lbnQgd2FzIHJlYWxseSBhYm91dCB0 aGlzIGRyYWZ0IG5vdyB0cnlpbmcgdG8gZXhjbHVkZSBwcmVlbXB0aW9uDQp0aW1lIGZyb20gcmVz dG9yYXRpb24gdGltZSBhcyB3ZWxsLiAmbmJzcDtJTU8sIGlmIGl0IHRha2VzIGEgZmV3IHNlY29u ZHMNCmZvciBhIGhpZ2ggcHJpb3JpdHkgc2VydmljZSB0byBmaW5pc2ggcHJlZW1wdGluZyBhIGxv d2VyIHByaW9yaXR5IHNlcnZpY2UsDQp0aGVuIHdlIGhhdmVuJ3QgbWV0IHRoZSA1MG1zIHJlc3Rv cmF0aW9uIHRpbWUgcmVxdWlyZW1lbnQuICZuYnNwO0VzcGVjaWFsbHkNCnNpbmNlIGl0J3MgdHlw aWNhbGx5IG15IGhpZ2hlciBwcmlvcml0eSBzZXJ2aWNlcyB0aGF0IHdhbnQgNTBtcyByZXN0b3Jh dGlvbg0KdGltZXMgaW4gdGhlIGZpcnN0IHBsYWNlLCBzbyB0aGV5J2xsIGJlIG1vcmUgb2Z0ZW4g aW4gYSBwb3NpdGlvbiB0byBwcmVlbXB0Lg0KJm5ic3A7SW4gb3RoZXIgd29yZHMsIEkgdGhpbmsg d2Ugd2FudCBwcmVlbXB0aW9uIHRvIGJlIGZhc3QgYW5kIGlzIGEgY3JpdGljYWwNCmNvbXBvbmVu dCBvZiBwcm90ZWN0aW9uIHN3aXRjaGluZy4gJm5ic3A7IDxicj4NCiA8YnI+DQo8YnI+DQpyZWdh cmRzLCA8YnI+DQpQYWJsbyA8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1wbHMgbWFpbGluZyBsaXN0PC9mb250Pjxm b250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pjxicj4NCjwvdT48L2Zv bnQ+PGEgaHJlZj1tYWlsdG86bXBsc0BpZXRmLm9yZyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9 MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pm1wbHNAaWV0Zi5vcmc8L3U+PC9mb250 PjwvYT48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT48YnI+DQo8 L3U+PC9mb250PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t cGxzIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJp ZiI+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPC91PjwvZm9u dD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD48dHQ+PGZv bnQgc2l6ZT0yPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KbXBscyBtYWlsaW5nIGxpc3Q8YnI+DQptcGxzQGlldGYub3JnPGJy Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPC9mb250PjwvdHQ+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD4NCjxicj4NCg== --=_alternative 0023AB6248257A68_=-- From david.i.allan@ericsson.com Mon Aug 27 23:35: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 7D96311E808E for ; Mon, 27 Aug 2012 23:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.96 X-Spam-Level: X-Spam-Status: No, score=-3.96 tagged_above=-999 required=5 tests=[AWL=-1.565, 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 15fdY-sp4Gaf for ; Mon, 27 Aug 2012 23:35:27 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id CE77011E80AE for ; Mon, 27 Aug 2012 23:35:26 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q7S6bAiL012250; Tue, 28 Aug 2012 01:37:12 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.2.164]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 28 Aug 2012 02:35:17 -0400 From: David Allan I To: "zhang.fei3@zte.com.cn" Date: Tue, 28 Aug 2012 02:35:15 -0400 Thread-Topic: [mpls] Comments on draft-weingarten-mpls-smp-requirements-00.txt Thread-Index: Ac2E5rQGE+aHdP1qSn+Iwf6/jEJ/6wAAD0tw Message-ID: <60C093A41B5E45409A19D42CF7786DFD5CFCCC91C9@EUSAACMS0703.eamcs.ericsson.se> References: <60C093A41B5E45409A19D42CF7786DFD5CFCCC91C5@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_60C093A41B5E45409A19D42CF7786DFD5CFCCC91C9EUSAACMS0703e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-weingarten-mpls-smp-requirements-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: Tue, 28 Aug 2012 06:35:32 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD5CFCCC91C9EUSAACMS0703e_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Rm9yIGNpcmN1aXQgdGVjaG5vbG9neSBJIGFncmVlLCByZXNvdXJjZSBjb25zdW1wdGlvbiBhbmQg Y29ubmVjdGl2aXR5IGFyZSBsaW5rZWQgYW5kIGNvb3JkaW5hdGlvbiBpcyByZXF1aXJlZC4gQnV0 IHRoYXQgc3RpbGwgc3VnZ2VzdHMgdGhhdCBhbGwgcHJlZW1wdGlvbiBhY3Rpdml0eSBpcyBvciBj YW4gYmUgY29uZmluZWQgdG8gdGhlIHNoYXJlZCBwYXJ0IG9mIHRoZSBwYXRoLiBJbiB0aGF0IHJl Z2FyZCBJIHRoaW5rIHdlIGFyZSBkaWdyZXNzaW5nIGZyb20gdGhlIG9yaWdpbmFsIGlzc3Vlcy4u LndoaWNoIHdhcyBhbnkgcmVxdWlyZW1lbnQgZm9yIGhlYWQgZW5kIG5vdGlmaWNhdGlvbi4NCg0K RGF2ZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogemhhbmcuZmVp M0B6dGUuY29tLmNuIFttYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuXQ0KU2VudDogVHVlc2Rh eSwgQXVndXN0IDI4LCAyMDEyIDk6MzEgQU0NClRvOiBEYXZpZCBBbGxhbiBJDQpDYzogR3JlZ29y eSBNaXJza3k7IG1wbHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbbXBsc10gQ29tbWVudHMgb24g ZHJhZnQtd2VpbmdhcnRlbi1tcGxzLXNtcC1yZXF1aXJlbWVudHMtMDAudHh0DQoNCg0KSGkgRGF2 ZQ0KDQpUaGFuayB5b3UgZm9yIHlvdXIgbmljZSByZXNwb25zZQ0KDQpTZWUgaW4gbGluZSB3aXRo IDxmZWkxPg0KDQpUaGFua3MNCg0KRmVpDQoNCg0KRGF2aWQgQWxsYW4gSSA8ZGF2aWQuaS5hbGxh bkBlcmljc3Nvbi5jb20+DQoNCjIwMTItMDgtMjggMTM6NDgNCg0KytW8/sjLDQoiemhhbmcuZmVp M0B6dGUuY29tLmNuIiA8emhhbmcuZmVpM0B6dGUuY29tLmNuPg0Ks63LzQ0KR3JlZ29yeSBNaXJz a3kgPGdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbT4sICJtcGxzQGlldGYub3JnIiA8bXBsc0Bp ZXRmLm9yZz4NCtb3zOINClJFOiBbbXBsc10gQ29tbWVudHMgb24gZHJhZnQtd2VpbmdhcnRlbi1t cGxzLXNtcC1yZXF1aXJlbWVudHMtMDAudHh0DQoNCg0KDQoNCg0KSEkgRmVpOg0KDQpZb3Ugd3Jv dGU6DQogPGZlaT4gSU1ITywgdGhlcmUgYXJlIHR3byBwcmlvcml0aWVzIG5lZWQgdG8gYmUgaGFu ZGxlZCBpbiBzaGFyZWQgbWVzaCBwcm90ZWN0aW9uIHNjZW5hcmlvcywgdGhlIHBhdGggcHJpb3Jp dHkgYW5kIHRoZSBzZXJ2aWNlIHByaW9yaXR5IChQSEIpLiBJZiBub2RlIEUgZG9lcyB0aGUgcHJl ZW1wdGlvbiwgaG93IHRvDQpkZWFsIHdpdGggdGhlIHBhdGggcHJpb3JpdHksIHdoaWNoIGlzIG5v dCBjYXJyaWVkIGluIHRyYWZmaWMgcGFja2V0Lg0KTXkgdW5kZXJzdGFuZGluZyBvZiB5b3VyIHBy b3Bvc2FsIGlzIHRoYXQgdmlhIGNvbnRyb2wgcGxhbmUgZXhjaGFuZ2UsIEUga25vd3MgdGhlIHBh dGggcHJpb3JpdHkuIENlcnRhaW5seSB0aGUgaW5ncmVzc2VzIGFyZSB1bmF3YXJlIG9mIGVhY2gg b3RoZXIgd2l0aG91dCBhIGNvb3JkaW5hdGlvbiBtZWNoYW5pc20gd2hpY2ggYXMgY3VycmVudGx5 IGRlc2NyaWJlZCBpcyBub3RpZmljYXRpb25zIG9yaWdpbmF0aW5nIHdpdGggRS4gTXkgc3VnZ2Vz dGlvbiBpcyB0aGF0IHRoZSBFIGFzIHRoZSBwcmVlbXB0aW9uIHBvaW50IGhhcyBzdWZmaWNpZW50 IGtub3dsZWRnZSB0byBwZXJmb3JtIHRoaXMgZnVuY3Rpb24sIGFuZCB3b3VsZCBkbyBpdCB3aXRo IGxlc3MgbGF0ZW5jeSB0aGFuIGhlYWQgZW5kIG5vdGlmaWNhdGlvbiBhbmQgdGhlIGhlYWQgZW5k IGFzIHRoZSBwcmVlbXB0aW9uIHBvaW50LiBJdCBoYXMgdGhlIGFkZGVkIHBsdXMgb2Ygbm90IGJl aW5nIGRlcGVuZGVudCBvbiB0aGUgaGVhZCBlbmQgbm90IGJlaW5nIGJyYWluIGRlYWQuLi4uDQoN CiA8ZmVpMT4gT2ssIEkgdGhpbmsgSSB1bmRlcnN0YW5kIHlvdXIgaWRlYSBub3cuICBJTUhPLCAg YWx0aG91Z2ggdGhlIHJlcXVpcmVtZW50cyBhcmUgY29taW5nIGZyb20gTVBMUy1UUCwgdGhlIHN0 YW5kYXJkIGhhZCBiZXR0ZXIgY292ZXJpbmcgdGhlIG90aGVyIHNjZW5hcmlvcy4gQ29uc2lkZXIg dGhlIE9EVTIgcGF0aCBhcyB0aGUgc2hhcmVkIHBhdGggc2VnbWVudCwgYW5kIHRoZSBub2RlIEUg YXMgdGhlIHByZWVtcHRpb24gcG9pbnQgKGp1c3QgYXMgeW91IHNhaWQpLg0KDQp0MCBILUUtRi1H LUsgYXMgdGhlIHByb3RlY3RpbmcgcGF0aCBhcmUgcHJvdGVjdGluZyB0aGUgd29yayBwYXRoIEgt SS1KLUsNCnQxIEEtQi1DLUQgaXMgYnJva2VuLCBub2RlIEEgc3dpdGNoZXMgdGhlIHRyYWZmaWMg dG8gQS1FDQp0MiBub2RlIEUgc3dpdGNoZXMgdGhlIGNyb3NzY29ubmVjdCBmcm9tIEgtRSB0byBB LUUgKHBhdGggQS1CLUMtRCBoYXMgaGlnaGVyIHByaW9yaXR5IHRoYW4gSC1JLUotSykNCg0KSG93 ZXZlciwgbm9kZSBHIGNhbiBub3QgbWFrZSBzdXJlIHRvIHN3aXRjaCB0aGUgY3Jvc3Njb25uZWN0 IGZyb20gRy1LIHRvIEctRCBzaW11bHRhbmVvdXNseSBhcyBhdCBub2RlIEUuIE1pc2Nvbm5lY3Rp b24gd2lsbCBoYXBwZW4uDQoNCkkgaG9wZSB0aGlzIGhlbHBzDQpEYXZlDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiB6aGFuZy5mZWkzQHp0ZS5jb20uY24gW21haWx0 bzp6aGFuZy5mZWkzQHp0ZS5jb20uY25dDQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMjgsIDIwMTIg NTo1MiBBTQ0KVG86IERhdmlkIEFsbGFuIEkNCkNjOiBHcmVnb3J5IE1pcnNreTsgbXBsc0BpZXRm Lm9yZw0KU3ViamVjdDogUkU6IFttcGxzXSBDb21tZW50cyBvbiBkcmFmdC13ZWluZ2FydGVuLW1w bHMtc21wLXJlcXVpcmVtZW50cy0wMC50eHQNCg0KDQpIaSBEYXZlDQoNClNvcnJ5IGZvciB0aGUg ZGVsYXllZCByZXNwb25zZSwgc2VlIG15IG5vdGVzIHRhZ2dlZCB3aXRoIDxmZWk+DQoNCg0KVGhh bmtzDQoNCkZlaQ0KDQpEYXZpZCBBbGxhbiBJIDxkYXZpZC5pLmFsbGFuQGVyaWNzc29uLmNvbT4N Cg0KMjAxMi0wOC0yMiAwMToyOQ0KDQrK1bz+yMsNCiJ6aGFuZy5mZWkzQHp0ZS5jb20uY24iIDx6 aGFuZy5mZWkzQHp0ZS5jb20uY24+LCBHcmVnb3J5IE1pcnNreSA8Z3JlZ29yeS5taXJza3lAZXJp Y3Nzb24uY29tPg0Ks63LzQ0KIm1wbHNAaWV0Zi5vcmciIDxtcGxzQGlldGYub3JnPg0K1vfM4g0K UkU6IFttcGxzXSBDb21tZW50cyBvbiBkcmFmdC13ZWluZ2FydGVuLW1wbHMtc21wLXJlcXVpcmVt ZW50cy0wMC50eHQNCg0KDQoNCg0KDQoNCg0KSGkgRmVpOg0KDQpJIHNlZSAiYSIgcHJvcG9zZWQg c29sdXRpb24gaW4gdGhlIGRyYWZ0IHlvdSByZWZlcmVuY2UsIGJ1dCBub3QgYSBwcm9ibGVtIHN0 YXRlbWVudCBvciBhbmFsc3lzaXMNCg0KPGZlaT4gIFRoZSBwcm9wb3NlZCBzb2x1dGlvbiBpcyBi YXNlIG9uIHRoZSBjb250cm9sIHBsYW5lIGV4dGVuc2lvbnMsIGFuZCB0aGUgcHJvYmxlbSBzdGF0 ZW1lbnQgc2FpZCAiIFtSRkM0ODcyXSBkZWZpbmVzIHRoZSBzaGFyZWQgbWVzaCByZXN0b3JhdGlv biBzY2hlbWVzIGJhc2VkIG9uDQogY29udHJvbCBwbGFuZSBleHRlbnNpb25zLCBidXQgZG9lcyBu b3QgY292ZXIgdGhlIHNoYXJlZCBtZXNoICBwcm90ZWN0aW9uIHNjZW5hcmlvcy4iDQoNClRoZSBw cmVlbXB0aW9uIGNvdWxkIHNpbXBseSBiZSBwZXJmb3JtZWQgYXQgbm9kZSBFLiBDdXJyZW50bHkg dGhlIG1vZGVsIGlzIHRoYXQgdGhlIExFUnMgbmVlZCB0byBub3RpZnkgbm9kZSBFIHdoZW4gdGhl IFAgcGF0aCBpcyBiZWluZyB1c2VkLCBhbmQgRSBuZWVkcyB0byBub3RpZnkgdGhlIExFUnMgb2Yg dGhlIGN1cnJlbnQgc3RhdGUgb2YgdGhlIHNoYXJlZCByZXNvdXJjZS4gIFRoaXMgYXBwZWFycyB0 byBkZXBlbmQgb24gdGhlIHByZWVtcHRlZCBMU1IgdG8gImRvIHRoZSByaWdodCB0aGluZyIgYW5k IGxlYWRzIHRvIGFuIElNTyB1bnJlYXNvbmFibGUgd2luZG93IG9mIGNvbnRlbnRpb24gZm9yIHRo ZSBzaGFyZWQgcmVzb3VyY2VzLg0KDQogPGZlaT4gUHJlZW1wdGlvbiBtZWFucyB0aGF0ICB0aGVy ZSB3aWxsIGJlIGEgd2luZG93IG9mIGNvbnRlbnRpb24sIHdoeSBpdCBpcyB1bnJlYXNvbmFibGU/ DQoNCklNTyBFIHNob3VsZCBiZSBkb2luZyB0aGUgcHJlZW1wdGlvbiwgYW5kIEkndmUgc3RpbGwg bm90IHJlYWxseSBzZWVuIGEgbmVlZCBmb3IgaGVhZCBlbmQgbm90aWZpY2F0aW9uIG9mIHByZWVt cHRpb24gdW5sZXNzIG9uZSBzdGFydHMgcGxhbm5pbmcgYmFja3VwcyBmb3IgYmFja3Vwcy4NCg0K IDxmZWk+IElNSE8sIHRoZXJlIGFyZSB0d28gcHJpb3JpdGllcyBuZWVkIHRvIGJlIGhhbmRsZWQg aW4gc2hhcmVkIG1lc2ggcHJvdGVjdGlvbiBzY2VuYXJpb3MsIHRoZSBwYXRoIHByaW9yaXR5IGFu ZCB0aGUgc2VydmljZSBwcmlvcml0eSAoUEhCKS4gSWYgbm9kZSBFIGRvZXMgdGhlIHByZWVtcHRp b24sIGhvdyB0bw0KZGVhbCB3aXRoIHRoZSBwYXRoIHByaW9yaXR5LCB3aGljaCBpcyBub3QgY2Fy cmllZCBpbiB0cmFmZmljIHBhY2tldC4NCg0KSWYgeW91IGhhdmUgbW9yZSBpbmZvcm1hdGlvbiwg Y291bGQgeW91IGVsYWJvcmFibGU/DQpEYXZlDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgemhhbmcuZmVpM0B6dGUuY29tLmNuDQpTZW50OiBN b25kYXksIEF1Z3VzdCAyMCwgMjAxMiA0OjAzIEFNDQpUbzogR3JlZ29yeSBNaXJza3kNCkNjOiBt cGxzQGlldGYub3JnOyBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbXBsc10g Q29tbWVudHMgb24gZHJhZnQtd2VpbmdhcnRlbi1tcGxzLXNtcC1yZXF1aXJlbWVudHMtMDAudHh0 DQoNCg0KR3JlZywgc25pcHBlZA0KDQogKiAgIEluIHRoZSBsYXN0IHNlbnRlbmNlIG9mIFNlY3Rp b24gMy4xIG5vbi1jb250cm9sIHBsYW5lIGNvb3JkaW5hdGlvbiBvZiBzaGFyZWQgcmVzb3VyY2Vz IHByZXNlbnRlZCBhcyBhbm90aGVyIHJlcXVpcmVtZW50LiBBbmQgYWdhaW4gSSBjYW4gbm90IGZp bmQgaG93IHdlIGNvbWUgdG8gc3VjaCBjb25jbHVzaW9uLCB3aGVyZSB0aGUgc291cmNlIG9mIHRo aXMgcmVxdWlyZW1lbnQuIFdvdWxkIGV4aXN0aW5nIGNvbnRyb2wgcGxhbmUgc2lnbmFsaW5nIHNv bHV0aW9uIGJlIHN1ZmZpY2llbnQgZm9yIGEgTVBMUyBuZXR3b3JrPw0KDQo8RmVpPiBJIGRvIG5v dCB0aGluayB0aGUgZXhpc3RpbmcgY29udHJvbCBwbGFuZSAoZGVmaW5lZCBpbiBSRkM0ODcyKSBp cyBzdWZmaWNpZW50IGZvciBhIE1QTFMgbmV0d29yaywgYW5kIHRoZXJlIGlzIGFuIGFuYWx5c2lz IGluIHRoZSBkcmFmdCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oZS1jY2FtcC1u b3RpZmljYXRpb24tc2hhcmVkLW1lc2gtcHJvdGVjdGlvbi0wMC4NCg0KDQpCZXN0IHJlZ2FyZHMN Cg0KRmVpDQoNCkdyZWdvcnkgTWlyc2t5IDxncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20+DQq3 orz+yMs6ICBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcNCg0KMjAxMi0wOC0xNiAwNjo0NQ0KDQrK1bz+ yMsNClBhYmxvIEZyYW5rIDxwYWJsb2lzbm90QGdtYWlsLmNvbT4sIFlhYWNvdiBXZWluZ2FydGVu IDx3eWFhY292QGdtYWlsLmNvbT4NCrOty80NCiJtcGxzQGlldGYub3JnIiA8bXBsc0BpZXRmLm9y Zz4NCtb3zOINClJlOiBbbXBsc10gQ29tbWVudHMgb24gZHJhZnQtd2VpbmdhcnRlbi1tcGxzLXNt cC1yZXF1aXJlbWVudHMtMDAudHh0DQoNCg0KDQoNCg0KDQoNCg0KDQpEZWFyIFBhYmxvLCBZYWFj b3YsIGV0IGFsLiwNCkkndmUgYmVlbiBmb2xsb3dpbmcgZGlzY3Vzc2lvbiB3aXRoIGdyZWF0IGRl YWwgb2YgaW50ZXJlc3QuIEkgaGF2ZSBzb21lIHF1ZXN0aW9ucyBpbiBhZGRpdGlvbiB0byBvbmVz IGJlaW5nIGJyb3VnaHQgdXAgYnkgUGFibG86DQoNCiAqICAgU2VjdGlvbiAxLjIgcmVmZXJzIHRv IG9wZXJhdG9yJ3MgZGVzaXJlIHRvIGhhdmUgc2VydmljZSByZXN0b3JhdGlvbiBtb3JlIGV4cGVk aWVudCB0aGFuIG9uZSBhY2hpZXZhYmxlIHdpdGggY29udHJvbCBwbGFuZS4gSSBoYXZlbid0IHNl ZW4gYW55IHF1YW50YXRpdmUgaW5mb3JtYXRpb24gdG8gY29tcGFyZSB3aXRoLiBXaGF0IGlzICJl eHBlZGllbnQgZW5vdWdoIiBmb3IgU01QPw0KICogICBTZWN0aW9uIDMuMSBkZXNyY2liZXMsIHdo YXQgY2FuIGJlIGNhbGxlZCwgImluc3RhbnQgZGV0ZXJtaW5pc20iIGluIHJlZ2FyZCB0byBTTVAg cmVzb3VyY2UgYXZhaWFsYWJpbGl0eS4gSSB0aGluayB0aGF0IHRoZXJlJ3Mgbm90IGVub3VnaCBy ZWFzb25pbmcgdG8gY29uY2x1ZGUgdGhhdCBhbG1vc3QgaW5zdGFudGVuZW91cyB1cGRhdGUgb2Yg U01QIHJlc291cmNlcyBhdmFpYWxhYmlsaXR5IGlzIHJlcXVpcmVkLg0KICogICBJbiB0aGUgbGFz dCBzZW50ZW5jZSBvZiBTZWN0aW9uIDMuMSBub24tY29udHJvbCBwbGFuZSBjb29yZGluYXRpb24g b2Ygc2hhcmVkIHJlc291cmNlcyBwcmVzZW50ZWQgYXMgYW5vdGhlciByZXF1aXJlbWVudC4gQW5k IGFnYWluIEkgY2FuIG5vdCBmaW5kIGhvdyB3ZSBjb21lIHRvIHN1Y2ggY29uY2x1c2lvbiwgd2hl cmUgdGhlIHNvdXJjZSBvZiB0aGlzIHJlcXVpcmVtZW50LiBXb3VsZCBleGlzdGluZyBjb250cm9s IHBsYW5lIHNpZ25hbGluZyBzb2x1dGlvbiBiZSBzdWZmaWNpZW50IGZvciBhIE1QTFMgbmV0d29y az8NCiAqICAgSSd2ZSBub3RpY2VkIHRoYXQgbWFueSByZXF1aXJlbWVudHMgYmVpbmcgcmVmZXJy ZWQgdG8gTVBMUy1UUCwgbm90IE1QTFMsIG5ldHdvcmtzLiBXb3VsZCB0aGF0IGJlIGEgZ29vZCBy ZWFzb24gdG8gbmFycm93IHNjb3BlIG9mIHRoZSBkb2N1bWVudCB0byBNUExTLVRQIG5ldHdvcmtz IG9ubHksIHN0YXJ0aW5nIHdpdGggdGhlIG5hbWUgb2YgdGhlIGRvY3VtZW50Pw0KDQogICAgUmVn YXJkcywNCiAgICAgIEdyZWcNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZy b206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIFBhYmxvIEZyYW5rDQpTZW50OiBGcmlkYXksIEF1Z3VzdCAxMCwgMjAxMiA3 OjIzIEFNDQpUbzogWWFhY292IFdlaW5nYXJ0ZW4NCkNjOiBtcGxzQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW21wbHNdIENvbW1lbnRzIG9uIGRyYWZ0LXdlaW5nYXJ0ZW4tbXBscy1zbXAtcmVxdWly ZW1lbnRzLTAwLnR4dA0KDQpIaSBZYWFjb3YsDQoNClNvbWUgbW9yZSBjb21tZW50cyBpbmxpbmUu Li4gUEY+Pg0KDQpPbiBNb24sIEF1ZyA2LCAyMDEyIGF0IDg6NTYgQU0sIFlhYWNvdiBXZWluZ2Fy dGVuIDx3eWFhY292QGdtYWlsLmNvbTxtYWlsdG86d3lhYWNvdkBnbWFpbC5jb20+PiB3cm90ZToN CkhpLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMuICBQbGVhc2Ugc2VlIG15IGNvbW1l bnRzIGlubGluZSBiZWxvdy4NCg0KQlIsDQp5YWFjb3YNCg0KT24gVHVlLCBKdWwgMTcsIDIwMTIg YXQgMTE6NTEgUE0sIFBhYmxvIEZyYW5rIDxwYWJsb2lzbm90QGdtYWlsLmNvbTxtYWlsdG86cGFi bG9pc25vdEBnbWFpbC5jb20+PiB3cm90ZToNCkdvb2QgZHJhZnQgYW5kIGNlcnRhaW5seSBzb21l dGhpbmcgdGhhdCBuZWVkcyB0byBiZSBkb25lIGJlZm9yZSB3ZSBjYW4gc3RhcnQgZGlzY3Vzc2lu ZyBzcGVjaWZpYyBzb2x1dGlvbnMuDQoNCk9ubHkgYSBmZXcgY29tbWVudHMgLyBxdWVzdGlvbnM6 DQoNCi0gSW4gNC4xLjEsIGlmIG9uZSBpcyBvcGVyYXRpbmcgaW4gYW4gTVBMUy1UUCBuZXR3b3Jr IHRoYXQgcmVxdWlyZXMgZXhjbHVzaXZlIHVzZSBvZiB0aGUgcHJvdGVjdGlvbiByZXNvdXJjZXMs IGRvZXNuJ3QgdGhpcyBTSE9VTEQgcmVxdWlyZW1lbnQgYmVjb21lIGEgTVVTVCByZXF1aXJlbWVu dD8NCg0KeXc+PiBTb3JyeSAtIGJ1dCBjb3VsZCB5b3UgZXhwbGFpbiBtb3JlIGZ1bGx5IHRoaXMg Y29tbWVudC4NCg0KUEY+PiAgSWYgeW91J3JlIHRyeWluZyB0byBtZWV0IFJGQyA1NjU0IHJlcSA1 OGIgaW4gcGFydGljdWxhciwgSSB3b3VsZCB0aGluayB5b3UgTVVTVCB2YWxpZGF0ZSB0aGF0IGVu b3VnaCBwcm90ZWN0aW9uIHJlc291cmNlcyBhcmUgYXZhaWxhYmxlIChvciBhcmUgcHJlZW1wdGli bGUpIHRvIGNhcnJ5IDEwMCUgb2YgdGhlIHNlcnZpY2UgdHJhZmZpYyB0aGF0IGlzIGJlaW5nIHJl c3RvcmVkLiAgSW4gZXhpc3RpbmcgdHJhbnNwb3J0IG5ldHdvcmtzIChpLmUuIE9UTiAvIHNvbmV0 KSwgdGhpcyBpcyB0eXBpY2FsbHkgZG9uZSBiZWZvcmUgeW91IHN3aXRjaCB0cmFmZmljIHRvIHRo ZSBwcm90ZWN0aW9uIHBhdGguICBGcm9tIGEgc29sdXRpb24gcGVyc3BlY3RpdmUsIEkgdGhpbmsg eW91J2xsIHByb2JhYmx5IHdhbnQgdG8gbGV2ZXJhZ2Ugc29tZXRoaW5nIGxpa2UgdGhlIGxvY2tp bmcgbW9kZSB0aGF0IGlzIGJlaW5nIHByb3Bvc2VkIGZvciB0aGUgMTpuIGRyYWZ0Lg0KDQotIE5p dDogeW91IG1pZ2h0IHdhbnQgdG8gYXZvaWQgdXNpbmcgdGhlICJxdWVyeSIgdmVyYiBpbiB0aGUg dGl0bGUgb2YgNC4xLjEgYmVjYXVzZSBpdCBzdWJ0bHkgc3VnZ2VzdHMgc29tZSBraW5kIG9mIHBy b3RvY29sIG1lc3NhZ2luZyBpcyByZXF1aXJlZC4gIEkgd291bGQgdXNlIHRoZSBtb3JlIGdlbmVy aWMgdmVyYiAiY2hlY2tpbmciIG9yICJ2ZXJpZnlpbmciLg0KeXc+PiBTb3VuZHMgT0sgdG8gbWUu DQotIEluIDQuMywgdGhlcmUgaXMgbm8gc3VnZ2VzdGlvbiBmb3Igd2hhdCBzaG91bGQgaGFwcGVu IGlmIG9uZSBvciBtb3JlIGZhaWxpbmcgcGF0aHMgaW4gYW4gTVBMUy1UUCBuZXR3b3JrIGFyZSBv ZiBlcXVhbCBwcmlvcml0eS4gIEkgcHJlc3VtZSBpdCB3aWxsIGJlIHNvbWUga2luZCBvZiBmaXJz dC1jb21lLCBmaXJzdC1zZXJ2ZSByZXF1aXJlbWVudCBidXQgdGhpcyB3aWxsIGJyaW5nIHVwIHRo ZSBxdWVzdGlvbiBvZiBob3cgdG8gYnJlYWsgdGllcy4NCnl3Pj4gVGhpcyBjb3VsZCBiZSByZXNv bHZlZCBhbG9uZyB0aGUgbGluZXMgdGhhdCBpdCB3YXMgYWRkcmVzc2VkIGluIHRoZSAxOm4gcHJv dGVjdGlvbg0KDQpQRj4+IEV4Y2VwdCB0aGF0IHlvdSBndXlzIHJlbW92ZWQgc2VwYXJhdGUgcGF0 aCBwcmlvcml0eSBmcm9tIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgMTpuIGRyYWZ0LiAgSW4g dGhlIGxhdGVzdCB2ZXJzaW9uLCBlYWNoIHBhdGggaGFzIGEgc3RyaWN0IHByaW9yaXR5IGRlZmlu ZWQgYnkgaXRzIHBhdGggSUQgc28gdGllcyB3ZXJlIG5vdCBwb3NzaWJsZS4gIEkgZG9uJ3QgdGhp bmsgdGhhdCBzb2x1dGlvbiB3aWxsIHdvcmsgZm9yIFNNUCBiZWNhdXNlIEkgaGF2ZSBhIGhhcmQg dGltZSBzZWVpbmcgaG93IGFsbCB0aGUgdmFyaW91cyBlbmRwb2ludHMgaW52b2x2ZWQgaW4gYSBz aGFyZWQgbWVzaCBjb3VsZCBjb29yZGluYXRlIG5vbi1vdmVybGFwcGluZyBwYXRoIElEcywgd2hp bGUgYXQgdGhlIHNhbWUgdGltZSBub3QgZXhjZWVkaW5nIHRoZSBsaW1pdCBvZiAyNTUgcGF0aCBJ RHMuDQoNCg0KLSBBbHNvIGluIDQuMywgdGhlcmUgaXMgYW4gYWxsb3dhbmNlIGZvciBhIGhpZ2gg cHJpb3JpdHkgcGF0aCBhbmQgYSBsb3dlciBwcmlvcml0eSBwYXRoIHRvIHRlbXBvcmFyaWx5IHNo YXJlIHRoZSBwcm90ZWN0aW9uIHJlc291cmNlcyB3aGlsZSBwcmVlbXB0aW9uIGlzIHRha2luZyBw bGFjZS4gIFR3byBxdWVzdGlvbnM6DQotIElzIHRoZSBpbmdyZXNzIG5vZGUgdG8gdGhlIHNoYXJl ZCBzZWdtZW50IGV4cGVjdGVkIHRvIGRpc2NhcmQgZXhjZXNzIHRyYWZmaWMgbm93IHRoYXQgdGhl IHByb3RlY3Rpb24tcGF0aCBpcyB0ZW1wb3JhcmlseSBvdmVyc3Vic2NyaWJlZD8NCnl3Pj4gdGhp cyB3b3VsZCBtb3N0IHByb2JhYmx5IGZvbGxvdyBzdGFuZGFyZCBNUExTIGJlaGF2aW9yIGFzIGRl c2NyaWJlZCBlbHNld2hlcmUNCg0KUEY+PiBJIGd1ZXNzIEknbGwgYXNrIHdoYXQgaXMgdGhlIHN0 YW5kYXJkIGJlaGF2aW91cj8gIEFuZCBpcyBpdCBhcHBsaWNhYmxlIHRvIE1QTFMtVFAgbmV0d29y a3M/DQoNCi0gSWYgbm90LCBob3cgZG8gd2UgZW5zdXJlIHRoYXQgb3RoZXIgdHJhbnNwb3J0IHBh dGhzIGFyZSB1bmFmZmVjdGVkPw0KLSBUaGUgZmlyc3QgcGFyYWdyYXBoIG9mIDQuNCBhcHBlYXJz IHRvIGNvbnRyYWRpY3QgNC4xLjEuICA0LjQgc2VlbXMgdG8gc3VnZ2VzdCB0aGF0IG9uZSBNVVNU IHN3aXRjaCB0aGUgdHJhZmZpYyBvbnRvIHRoZSBwcm90ZWN0aW9uIHBhdGggZmlyc3QgYW5kIHRo ZW4gZ2V0IG5vdGlmaWVkIGlmIHRoZXJlJ3Mgbm90IGVub3VnaCByZXNvdXJjZXMuICBUaGF0J3Mg cHJvYmFibHkgb2theSBpbiB0aGUgZ2VuZXJhbCBjYXNlLiAgQnV0IGluIGFuIE1QTFMtVFAgbmV0 d29yaywgSSBkb24ndCB0aGluayBpdCdzIGEgZ29vZCBpZGVhIHRvIGJsaW5kbHkgc3dpdGNoIGxv dyBwcmlvcml0eSB0cmFmZmljIG9udG8gdGhlIHByb3RlY3Rpb24gcGF0aCBhbmQgcG9zc2libHkg ZGlzcnVwdCBhIGhpZ2ggcHJpb3JpdHkgcGF0aCB0aGF0IGlzIGFscmVhZHkgdXNpbmcgdGhhdCBy ZXNvdXJjZS4NCnl3Pj4gVGhpcyBpcyBkZXBlbmRlbnQgdXBvbiB0aGUgYWN0dWFsIG1lY2hhbmlz bSB0aGF0IGlzIGRldmVsb3BlZCBieSB0aGUgV0cuICBGb3IgZXhhbXBsZSwgb25lIHN1Z2dlc3Rp b24gZm9yIHRoZSBtZWNoYW5pc20gaGFzIG5vdGlmaWNhdGlvbnMgc2VudCB0byBsb3dlciBwcmlv cml0eSB3b3JraW5nIHBhdGhzIG1ha2luZyB0aGUgcHJvdGVjdGlvbiBwYXRoIHVuYXZhaWxhYmxl IGlmIGl0IGlzIGluIHVzZSBieSBhIGhpZ2gtcHJpb3JpdHkgd29ya2luZyBwYXRoLg0KDQotIElu IHNlY3Rpb24gNC41LCB0aGVyZSdzIGFuIGF0dGVtcHQgdG8gZGVmaW5lICJwcm90ZWN0aW9uIHN3 aXRjaGluZyB0aW1lIiBhcyBub3QgaW5jbHVkaW5nIHByZWVtcHRpb24gdGltZS4gIEkgZG9uJ3Qg dGhpbmsgZW5kLXVzZXJzIHJlYWxseSBjYXJlIGFib3V0ICJwcm90ZWN0aW9uIHN3aXRjaGluZyB0 aW1lIi4gIFRoZXkgY2FyZSBhYm91dCByZWNvdmVyeSB0aW1lIGFuZCBJTU8sIHRoYXQgc2hvdWxk IGFsc28gaW5jbHVkZSBmYXVsdCBkZXRlY3Rpb24gdGltZSAoYWx0aG91Z2ggaXQgZG9lc24ndCBw ZXIgUkZDIDU2NTQpIGFuZCBhbnkgcHJlZW1wdGlvbiB0aW1lLg0KeXc+PiB3ZSBkbyB0cnkgdG8g d29yayB3aXRoaW4gdGhlIGFjY2VwdGVkIGRlZmluaXRpb25zIG9mIHRoZSBJRVRGIQ0KDQpQRj4+ IEkgZ3Vlc3MgdGhlcmUncyB0d28gc2VwYXJhdGUgY29tbWVudHMgaGVyZSB0aGF0IEkga2luZGEg Y29uZmxhdGVkIHRvZ2V0aGVyLiAgT25lIHdhcyBtb3JlIG9mIGEgZ3JpcGU6IHdoeSBkaWQgd2Ug ZXhjbHVkZSBmYXVsdCBkZXRlY3Rpb24gdGltZSBmcm9tIHRoZSA1MG1zIHJlc3RvcmF0aW9uIHRp bWUgcmVxdWlyZW1lbnQgaW4gUkZDIDU2NTQ/ICBJIGtub3cgdGhhdCBteSBjdXN0b21lcnMgbWVh c3VyZSBvbmx5IG9uZSB0aGluZzogaG93IG1hbnkgbXMgb2YgdHJhZmZpYyBkbyB0aGV5IGxvc2Ug YWZ0ZXIgYSBicmVha2FnZS4gIEkgZG9uJ3QgZ2V0IGEgZnJlZSBwYXNzIG9uIHRoZSB+MTBtcyBp dCB0YWtlcyBmb3IgQkZEIHRvIGRldGVjdCB0aGUgZmFpbHVyZS4gIEFjY29yZGluZyB0byBSRkMg NTY1NCwgSSBjb3VsZCB1c2UgNjBzZWMgQ0NNcyBhbmQgc3RpbGwgbWVldCB0aGUgNTBtcyByZXF1 aXJlbWVudCENCg0KVGhlIDJuZCBjb21tZW50IHdhcyByZWFsbHkgYWJvdXQgdGhpcyBkcmFmdCBu b3cgdHJ5aW5nIHRvIGV4Y2x1ZGUgcHJlZW1wdGlvbiB0aW1lIGZyb20gcmVzdG9yYXRpb24gdGlt ZSBhcyB3ZWxsLiAgSU1PLCBpZiBpdCB0YWtlcyBhIGZldyBzZWNvbmRzIGZvciBhIGhpZ2ggcHJp b3JpdHkgc2VydmljZSB0byBmaW5pc2ggcHJlZW1wdGluZyBhIGxvd2VyIHByaW9yaXR5IHNlcnZp Y2UsIHRoZW4gd2UgaGF2ZW4ndCBtZXQgdGhlIDUwbXMgcmVzdG9yYXRpb24gdGltZSByZXF1aXJl bWVudC4gIEVzcGVjaWFsbHkgc2luY2UgaXQncyB0eXBpY2FsbHkgbXkgaGlnaGVyIHByaW9yaXR5 IHNlcnZpY2VzIHRoYXQgd2FudCA1MG1zIHJlc3RvcmF0aW9uIHRpbWVzIGluIHRoZSBmaXJzdCBw bGFjZSwgc28gdGhleSdsbCBiZSBtb3JlIG9mdGVuIGluIGEgcG9zaXRpb24gdG8gcHJlZW1wdC4g IEluIG90aGVyIHdvcmRzLCBJIHRoaW5rIHdlIHdhbnQgcHJlZW1wdGlvbiB0byBiZSBmYXN0IGFu ZCBpcyBhIGNyaXRpY2FsIGNvbXBvbmVudCBvZiBwcm90ZWN0aW9uIHN3aXRjaGluZy4NCg0KDQpy ZWdhcmRzLA0KUGFibG8NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBt YWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbXBscw0KDQo= --_000_60C093A41B5E45409A19D42CF7786DFD5CFCCC91C9EUSAACMS0703e_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
For=20 circuit technology I agree, resource consumption and connectivity are linke= d and=20 coordination is required. But that still suggests that all preemption activ= ity=20 is or can be confined to the shared part of the path. In that regard I thin= k we=20 are digressing from the original issues...which was any requirement for hea= d end=20 notification.
 
Dave

From: zhang.fei3@zte.com.cn=20 [mailto:zhang.fei3@zte.com.cn]
Sent: Tuesday, August 28, 2012 9:= 31=20 AM
To: David Allan I
Cc: Gregory Mirsky;=20 mpls@ietf.org
Subject: RE: [mpls] Comments on=20 draft-weingarten-mpls-smp-requirements-00.txt


Hi Dave

Thank you for your nice response

See in line with <fei1>

Thanks

Fe= i=20


David Allan I=20 <david.i.allan@ericsson.com>

2012-08-28 13:48

=CA=D5=BC= =FE=C8=CB
"zhang.fei3@zte.com.cn"=20 <zhang.fei3@zte.com.cn>=20
=B3=AD=CB= =CD
Gregory Mirsky=20 <gregory.mirsky@ericsson.com>, "mpls@ietf.org"=20 <mpls@ietf.org>=20
=D6=F7=CC= =E2
RE: [mpls] Comments on=20 draft-weingarten-mpls-smp-requirements-00.txt





HI Fei:
&= nbsp;=20
You wrote:
 <fei> IMHO, there are two priorities need to be ha= ndled=20 in shared mesh protection scenarios, the path priority and the service prio= rity=20 (PHB). If node E does the preemption, how to
deal with the path priorit= y,=20 which is not carried in traffic packet.
My understanding of your proposal is that via control plane ex= change,=20 E knows the path priority. Certainly the ingresses are unaware of each othe= r=20 without a coordination mechanism which as currently described is notificati= ons=20 originating with E. My suggestion is that the E as the preemption point has= =20 sufficient knowledge to perform this function, and would do it with less la= tency=20 than head end notification and the head end as the preemption point. It has= the=20 added plus of not being dependent on the head end not being brain=20 dead....

 <fei1> Ok, = I think I=20 understand your idea now.  IMHO,  although the requirements are c= oming=20 from MPLS-TP, the standard had better covering the other scenarios. Conside= r the=20 ODU2 path as the shared path segment, and the node E as the preemption poin= t=20 (just as you said).

t0 H-E-F-G-K= as the=20 protecting path are protecting the work path H-I-J-K
t1 A-B-C-D is broken, node A switches the traffic to A-E=20
t2 node E switches the crossconnect from H-= E to A-E=20 (path A-B-C-D has higher priority than H-I-J-K)

However, node G can not make sure to switch the crossconnect f= rom G-K=20 to G-D simultaneously as at node E. Misconnection will happen.=20

I hope this helps <= BR>Dave

From: zhang.fei3@zte.com.cn=20 [mailto:zhang.fei3@zte.com.cn]
Sent: Tuesday, August 28, 2012 5:= 52=20 AM
To: David Allan I
Cc: Gregory Mirsky;=20 mpls@ietf.org
Subject: RE: [mpls] Comments on=20 draft-weingarten-mpls-smp-requirements-00.txt


Hi=20 Dave

Sorry for the delayed response, see my notes tagged w= ith=20 <fei>


Thanks

Fei= =20

David Allan I=20 <david.i.allan@ericsson.com>

2012-08-22 01:29


=CA=D5=BC= =FE=C8=CB
"zhang.fei3@zt= e.com.cn"=20 <zhang.fei3@zte.com.cn>, Gregory Mirsky=20 <gregory.mirsky@ericsson.com>
=B3=AD=CB= =CD
"mpls@ietf.org"=20 <mpls@ietf.org> <= /FONT>
=D6=F7=CC= =E2
RE: [mpls] Comments on=20 draft-weingarten-mpls-smp-requirements-00.txt



<= BR>

<= BR>Hi=20 Fei:
 
I see "a" proposed solution in the draft you refe= rence,=20 but not a problem statement or analsysis=20

<fei>  The proposed s= olution=20 is base on the control plane extensions, and the problem statement said "=20 [RFC4872] defines the shared mesh restoration schemes based on
 con= trol=20 plane extensions, but does not cover the shared mesh  protection=20 scenarios."
 
The preemption could simply be perfo= rmed at=20 node E. Currently the model is that the LERs need to notify node E when the= P=20 path is being used, and E needs to notify the LERs of the current state of = the=20 shared resource.  This appears to depend on the preempted LSR to "do t= he=20 right thing" and leads to an IMO unreasonable window of contention for the= =20 shared resources.

 <fei> Preemption means that  there will b= e a=20 window of contention, why it is unreasonable?

= IMO E should=20 be doing the preemption, and I've still not really seen a need for head end= =20 notification of preemption unless one starts planning backups for=20 backups.

 <fei> IMHO, there are two priorities need to b= e=20 handled in shared mesh protection scenarios, the path priority and the serv= ice=20 priority (PHB). If node E does the preemption, how to
deal with the pat= h=20 priority, which is not carried in traffic packet.
 
If you=20 have more information, could you elaborable?=20
Dave
 
 
From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of=20 zhang.fei3@zte.com.cn
Sent: Monday, August 20, 2012 4:03=20 AM
To: Gregory Mirsky
Cc: mpls@ietf.org;=20 mpls-bounces@ietf.org
Subject: Re: [mpls] Comments on=20 draft-weingarten-mpls-smp-requirements-00.txt


Greg,= =20 snipped
  • In the last sentence of Sect= ion 3.1=20 non-control plane coordination of shared resources presented as another=20 requirement. And again I can not find how we come to such conclusion, whe= re=20 the source of this requirement. Would existing control plane signaling=20 solution be sufficient for a MPLS network?

<Fei> I do not think the existing control plane= =20 (defined in RFC4872) is sufficient for a MPLS network, and there is an anal= ysis=20 in the draft=20 http://tools.ietf.org/html/draft-he-ccamp-notification-shared-mesh-protecti= on-00.=20


Best regards=20

Fei

Gregory Mirsky=20 <gregory.mirsky@ericsson.com>
=B7=A2=BC=FE=C8=CB:=20  mpls-bounces@ietf.org <= /FONT>

2012-08-16 06:45


=CA=D5=BC= =FE=C8=CB
Pablo Frank=20 <pabloisnot@gmail.com>, Yaacov Weingarten=20 <wyaacov@gmail.com>=20
=B3=AD=CB= =CD
"mpls@ietf.org"=20 <mpls@ietf.org> <= /FONT>
=D6=F7=CC= =E2
Re: [mpls] Comments on=20 draft-weingarten-mpls-smp-requirements-00.txt




<= BR>

<= BR>
Dear=20 Pablo, Yaacov, et al.,
I've been following discussion with = great deal=20 of interest. I have some questions in addition to ones being brought up by= =20 Pablo:
  • Section 1.2 refers to operat= or's desire=20 to have service restoration more expedient than one achievable with contr= ol=20 plane. I haven't seen any quantative information to compare with. What is= =20 "expedient enough" for SMP?
  • Section 3.1 desrcibes, what = can be=20 called, "instant determinism" in regard to SMP resource avaialability. I = think=20 that there's not enough reasoning to conclude that almost instanteneous u= pdate=20 of SMP resources avaialability is required.
  • In the last sentence of Sect= ion 3.1=20 non-control plane coordination of shared resources presented as another=20 requirement. And again I can not find how we come to such conclusion, whe= re=20 the source of this requirement. Would existing control plane signaling=20 solution be sufficient for a MPLS network?=20
  • I've noticed that many requi= rements=20 being referred to MPLS-TP, not MPLS, networks. Would that be a good reaso= n to=20 narrow scope of the document to MPLS-TP networks only, starting with the = name=20 of the document?
 =20   Regards,
    &= nbsp;=20 Greg

From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of Pablo Frank
Sent:<= /B>=20 Friday, August 10, 2012 7:23 AM
To: Yaacov Weingarten
Cc:=20 mpls@ietf.org
Subject: Re: [mpls] Comments on=20 draft-weingarten-mpls-smp-requirements-00.txt

Hi Yaacov,

Some more comments inline...=20 PF>>

On Mon, Aug 6, 2012 at 8:56 AM, Yaacov Weingarten=20 <wyaacov@gmail.com> wrote:
Hi,

Thank you for your comments.= =20  Please see my comments inline below.

BR,
yaacov

On= Tue,=20 Jul 17, 2012 at 11:51 PM, Pablo Frank <pabloisnot@gmail.com> wrote:
Good draft and certainly something that n= eeds to=20 be done before we can start discussing specific solutions.

Only a f= ew=20 comments / questions:

- In 4.1.1, if one is operating in an MPLS-TP= =20 network that requires exclusive use of the protection resources, doesn't th= is=20 SHOULD requirement become a MUST requirement?

yw>> Sorry - bu= t=20 could you explain more fully this comment.

PF>>  If you'= re=20 trying to meet RFC 5654 req 58b in particular, I would think you MUST valid= ate=20 that enough protection resources are available (or are preemptible) to carr= y=20 100% of the service traffic that is being restored.  In existing trans= port=20 networks (i.e. OTN / sonet), this is typically done before you switch traff= ic to=20 the protection path.  From a solution perspective, I think you'll prob= ably=20 want to leverage something like the locking mode that is being proposed for= the=20 1:n draft.

- Nit: you might want to avoid using the "query" verb in= the=20 title of 4.1.1 because it subtly suggests some kind of protocol messaging i= s=20 required.  I would use the more generic verb "checking" or "verifying"= .=20
yw>> Sounds OK to me.
- In 4.3, there is no suggestion for wh= at=20 should happen if one or more failing paths in an MPLS-TP network are of equ= al=20 priority.  I presume it will be some kind of first-come, first-serve=20 requirement but this will bring up the question of how to break ties.=20
yw>> This could be resolved along the lines that it was addressed= in=20 the 1:n protection

PF>> Except that you guys removed separate= path=20 priority from the latest version of the 1:n draft.  In the latest vers= ion,=20 each path has a strict priority defined by its path ID so ties were not=20 possible.  I don't think that solution will work for SMP because I hav= e a=20 hard time seeing how all the various endpoints involved in a shared mesh co= uld=20 coordinate non-overlapping path IDs, while at the same time not exceeding t= he=20 limit of 255 path IDs.


- Also in 4.3, there is an allowance for= a=20 high priority path and a lower priority path to temporarily share the prote= ction=20 resources while preemption is taking place.  Two questions:
- Is t= he=20 ingress node to the shared segment expected to discard excess traffic now t= hat=20 the protection-path is temporarily oversubscribed?
yw>> this woul= d=20 most probably follow standard MPLS behavior as described elsewhere=20

PF>> I guess I'll ask what is the standard behaviour?  A= nd is=20 it applicable to MPLS-TP networks?

- If not, how do we ensure that = other=20 transport paths are unaffected?
- The first paragraph of 4.4 appears to= =20 contradict 4.1.1.  4.4 seems to suggest that one MUST switch the traff= ic=20 onto the protection path first and then get notified if there's not enough= =20 resources.  That's probably okay in the general case.  But in an= =20 MPLS-TP network, I don't think it's a good idea to blindly switch low prior= ity=20 traffic onto the protection path and possibly disrupt a high priority path = that=20 is already using that resource.
yw>> This is dependent upon the a= ctual=20 mechanism that is developed by the WG.  For example, one suggestion fo= r the=20 mechanism has notifications sent to lower priority working paths making the= =20 protection path unavailable if it is in use by a high-priority working path= .=20

- In section 4.5, there's an attempt to define "protection switchin= g=20 time" as not including preemption time.  I don't think end-users reall= y=20 care about "protection switching time".  They care about recovery time= and=20 IMO, that should also include fault detection time (although it doesn't per= RFC=20 5654) and any preemption time.
yw>> we do try to work within the= =20 accepted definitions of the IETF!

PF>> I guess there's two=20 separate comments here that I kinda conflated together.  One was more = of a=20 gripe: why did we exclude fault detection time from the 50ms restoration ti= me=20 requirement in RFC 5654?  I know that my customers measure only one th= ing:=20 how many ms of traffic do they lose after a breakage.  I don't get a f= ree=20 pass on the ~10ms it takes for BFD to detect the failure.  According t= o RFC=20 5654, I could use 60sec CCMs and still meet the 50ms requirement!

T= he=20 2nd comment was really about this draft now trying to exclude preemption ti= me=20 from restoration time as well.  IMO, if it takes a few seconds for a h= igh=20 priority service to finish preempting a lower priority service, then we hav= en't=20 met the 50ms restoration time requirement.  Especially since it's typi= cally=20 my higher priority services that want 50ms restoration times in the first p= lace,=20 so they'll be more often in a position to preempt.  In other words, I = think=20 we want preemption to be fast and is a critical component of protection=20 switching.  


regards,
Pablo=20


_______________________________________________
mpls mailing= =20 list
= mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls<= /A>


_______________________________________________
mpls ma= iling=20 list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls<= /TT>

--_000_60C093A41B5E45409A19D42CF7786DFD5CFCCC91C9EUSAACMS0703e_-- From zhang.fei3@zte.com.cn Mon Aug 27 23:50: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 410C621E804B for ; Mon, 27 Aug 2012 23:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.958 X-Spam-Level: X-Spam-Status: No, score=-95.958 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_BAD_ID=2.837, 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 fHYtaB4Jy9p7 for ; Mon, 27 Aug 2012 23:50:00 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5F211E808E for ; Mon, 27 Aug 2012 23:49:59 -0700 (PDT) Received: from [10.30.3.21] by mx5.zte.com.cn with surfront esmtp id 232554375048883(version=TLSv1/SSLv3 cipher=SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA bits=128 verify=NO); Tue, 28 Aug 2012 14:43:37 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q7S6nmvE046504; Tue, 28 Aug 2012 14:49:48 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD5CFCCC91C9@EUSAACMS0703.eamcs.ericsson.se> To: David Allan I MIME-Version: 1.0 X-KeepSent: 34B072DB:C76B1BE4-48257A68:0024F3F0; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Tue, 28 Aug 2012 14:49:46 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-28 14:49:47, Serialize complete at 2012-08-28 14:49:47 Content-Type: multipart/alternative; boundary="=_alternative 00256D6E48257A68_=" X-MAIL: mse02.zte.com.cn q7S6nmvE046504 Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-weingarten-mpls-smp-requirements-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: Tue, 28 Aug 2012 06:50:02 -0000 This is a multipart message in MIME format. --=_alternative 00256D6E48257A68_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 RGF2ZSwgDQoNCkZvciBNUExTIG5ldHdvcmtzLCBJIGFncmVlIHdpdGggeW91IHRoYXQgbm9kZSBF IGNhbiBwcmUtc3RvcmUgdGhlIHBhdGggDQpwcmlvcml0eSBhbmQgZG8gdGhlIHN3aXRjaCBhbmQg bm90aWZpY2F0aW9uLiA6LSkNCg0KSWYgd2UgY29uc2lkZXIgYSB1bmlmb3JtIG1lY2hhbmlzbSBm b3IgdGhlIGJhY2tib25lIG5ldHdvcmtzIChNUExTLVRQLCANCk9UTiwgU09ORS9TREgsIFdTT04p LCBJIHRlbmQgdG8gdGhpbmsgaGVhZCBlbmQgbm90aWZpY2F0aW9uIHdpbnMuDQoNCkhvcGUgdGhp cyBjbGFyaWZ5IG15IG9waW5pb24NCg0KcmVnYXJkcw0KDQpGZWkNCg0KDQoNCkRhdmlkIEFsbGFu IEkgPGRhdmlkLmkuYWxsYW5AZXJpY3Nzb24uY29tPiANCjIwMTItMDgtMjggMTQ6MzUNCg0KytW8 /sjLDQoiemhhbmcuZmVpM0B6dGUuY29tLmNuIiA8emhhbmcuZmVpM0B6dGUuY29tLmNuPg0Ks63L zQ0KR3JlZ29yeSBNaXJza3kgPGdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbT4sICJtcGxzQGll dGYub3JnIiANCjxtcGxzQGlldGYub3JnPg0K1vfM4g0KUkU6IFttcGxzXSBDb21tZW50cyBvbiBk cmFmdC13ZWluZ2FydGVuLW1wbHMtc21wLXJlcXVpcmVtZW50cy0wMC50eHQNCg0KDQoNCg0KDQoN CkZvciBjaXJjdWl0IHRlY2hub2xvZ3kgSSBhZ3JlZSwgcmVzb3VyY2UgY29uc3VtcHRpb24gYW5k IGNvbm5lY3Rpdml0eSBhcmUgDQpsaW5rZWQgYW5kIGNvb3JkaW5hdGlvbiBpcyByZXF1aXJlZC4g QnV0IHRoYXQgc3RpbGwgc3VnZ2VzdHMgdGhhdCBhbGwgDQpwcmVlbXB0aW9uIGFjdGl2aXR5IGlz IG9yIGNhbiBiZSBjb25maW5lZCB0byB0aGUgc2hhcmVkIHBhcnQgb2YgdGhlIHBhdGguIA0KSW4g dGhhdCByZWdhcmQgSSB0aGluayB3ZSBhcmUgZGlncmVzc2luZyBmcm9tIHRoZSBvcmlnaW5hbCBp c3N1ZXMuLi53aGljaCANCndhcyBhbnkgcmVxdWlyZW1lbnQgZm9yIGhlYWQgZW5kIG5vdGlmaWNh dGlvbi4NCiANCkRhdmUNCg0KRnJvbTogemhhbmcuZmVpM0B6dGUuY29tLmNuIFttYWlsdG86emhh bmcuZmVpM0B6dGUuY29tLmNuXSANClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAyOCwgMjAxMiA5OjMx IEFNDQpUbzogRGF2aWQgQWxsYW4gSQ0KQ2M6IEdyZWdvcnkgTWlyc2t5OyBtcGxzQGlldGYub3Jn DQpTdWJqZWN0OiBSRTogW21wbHNdIENvbW1lbnRzIG9uIA0KZHJhZnQtd2VpbmdhcnRlbi1tcGxz LXNtcC1yZXF1aXJlbWVudHMtMDAudHh0DQoNCg0KSGkgRGF2ZSANCg0KVGhhbmsgeW91IGZvciB5 b3VyIG5pY2UgcmVzcG9uc2UgDQoNClNlZSBpbiBsaW5lIHdpdGggPGZlaTE+IA0KDQpUaGFua3Mg DQoNCkZlaSANCg0KDQpEYXZpZCBBbGxhbiBJIDxkYXZpZC5pLmFsbGFuQGVyaWNzc29uLmNvbT4g DQoyMDEyLTA4LTI4IDEzOjQ4IA0KDQoNCsrVvP7Iyw0KInpoYW5nLmZlaTNAenRlLmNvbS5jbiIg PHpoYW5nLmZlaTNAenRlLmNvbS5jbj4gDQqzrcvNDQpHcmVnb3J5IE1pcnNreSA8Z3JlZ29yeS5t aXJza3lAZXJpY3Nzb24uY29tPiwgIm1wbHNAaWV0Zi5vcmciIA0KPG1wbHNAaWV0Zi5vcmc+IA0K 1vfM4g0KUkU6IFttcGxzXSBDb21tZW50cyBvbiBkcmFmdC13ZWluZ2FydGVuLW1wbHMtc21wLXJl cXVpcmVtZW50cy0wMC50eHQNCg0KDQoNCg0KDQoNCg0KDQpISSBGZWk6IA0KICANCllvdSB3cm90 ZTogDQogPGZlaT4gSU1ITywgdGhlcmUgYXJlIHR3byBwcmlvcml0aWVzIG5lZWQgdG8gYmUgaGFu ZGxlZCBpbiBzaGFyZWQgbWVzaCANCnByb3RlY3Rpb24gc2NlbmFyaW9zLCB0aGUgcGF0aCBwcmlv cml0eSBhbmQgdGhlIHNlcnZpY2UgcHJpb3JpdHkgKFBIQikuIElmIA0Kbm9kZSBFIGRvZXMgdGhl IHByZWVtcHRpb24sIGhvdyB0byANCmRlYWwgd2l0aCB0aGUgcGF0aCBwcmlvcml0eSwgd2hpY2gg aXMgbm90IGNhcnJpZWQgaW4gdHJhZmZpYyBwYWNrZXQuIA0KTXkgdW5kZXJzdGFuZGluZyBvZiB5 b3VyIHByb3Bvc2FsIGlzIHRoYXQgdmlhIGNvbnRyb2wgcGxhbmUgZXhjaGFuZ2UsIEUgDQprbm93 cyB0aGUgcGF0aCBwcmlvcml0eS4gQ2VydGFpbmx5IHRoZSBpbmdyZXNzZXMgYXJlIHVuYXdhcmUg b2YgZWFjaCBvdGhlciANCndpdGhvdXQgYSBjb29yZGluYXRpb24gbWVjaGFuaXNtIHdoaWNoIGFz IGN1cnJlbnRseSBkZXNjcmliZWQgaXMgDQpub3RpZmljYXRpb25zIG9yaWdpbmF0aW5nIHdpdGgg RS4gTXkgc3VnZ2VzdGlvbiBpcyB0aGF0IHRoZSBFIGFzIHRoZSANCnByZWVtcHRpb24gcG9pbnQg aGFzIHN1ZmZpY2llbnQga25vd2xlZGdlIHRvIHBlcmZvcm0gdGhpcyBmdW5jdGlvbiwgYW5kIA0K d291bGQgZG8gaXQgd2l0aCBsZXNzIGxhdGVuY3kgdGhhbiBoZWFkIGVuZCBub3RpZmljYXRpb24g YW5kIHRoZSBoZWFkIGVuZCANCmFzIHRoZSBwcmVlbXB0aW9uIHBvaW50LiBJdCBoYXMgdGhlIGFk ZGVkIHBsdXMgb2Ygbm90IGJlaW5nIGRlcGVuZGVudCBvbiANCnRoZSBoZWFkIGVuZCBub3QgYmVp bmcgYnJhaW4gZGVhZC4uLi4gDQoNCiA8ZmVpMT4gT2ssIEkgdGhpbmsgSSB1bmRlcnN0YW5kIHlv dXIgaWRlYSBub3cuICBJTUhPLCAgYWx0aG91Z2ggdGhlIA0KcmVxdWlyZW1lbnRzIGFyZSBjb21p bmcgZnJvbSBNUExTLVRQLCB0aGUgc3RhbmRhcmQgaGFkIGJldHRlciBjb3ZlcmluZyB0aGUgDQpv dGhlciBzY2VuYXJpb3MuIENvbnNpZGVyIHRoZSBPRFUyIHBhdGggYXMgdGhlIHNoYXJlZCBwYXRo IHNlZ21lbnQsIGFuZCANCnRoZSBub2RlIEUgYXMgdGhlIHByZWVtcHRpb24gcG9pbnQgKGp1c3Qg YXMgeW91IHNhaWQpLiANCg0KdDAgSC1FLUYtRy1LIGFzIHRoZSBwcm90ZWN0aW5nIHBhdGggYXJl IHByb3RlY3RpbmcgdGhlIHdvcmsgcGF0aCBILUktSi1LIA0KdDEgQS1CLUMtRCBpcyBicm9rZW4s IG5vZGUgQSBzd2l0Y2hlcyB0aGUgdHJhZmZpYyB0byBBLUUgDQp0MiBub2RlIEUgc3dpdGNoZXMg dGhlIGNyb3NzY29ubmVjdCBmcm9tIEgtRSB0byBBLUUgKHBhdGggQS1CLUMtRCBoYXMgDQpoaWdo ZXIgcHJpb3JpdHkgdGhhbiBILUktSi1LKSANCg0KSG93ZXZlciwgbm9kZSBHIGNhbiBub3QgbWFr ZSBzdXJlIHRvIHN3aXRjaCB0aGUgY3Jvc3Njb25uZWN0IGZyb20gRy1LIHRvIA0KRy1EIHNpbXVs dGFuZW91c2x5IGFzIGF0IG5vZGUgRS4gTWlzY29ubmVjdGlvbiB3aWxsIGhhcHBlbi4gDQoNCkkg aG9wZSB0aGlzIGhlbHBzIA0KRGF2ZSANCg0KRnJvbTogemhhbmcuZmVpM0B6dGUuY29tLmNuIFtt YWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuXSANClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAyOCwg MjAxMiA1OjUyIEFNDQpUbzogRGF2aWQgQWxsYW4gSQ0KQ2M6IEdyZWdvcnkgTWlyc2t5OyBtcGxz QGlldGYub3JnDQpTdWJqZWN0OiBSRTogW21wbHNdIENvbW1lbnRzIG9uIA0KZHJhZnQtd2Vpbmdh cnRlbi1tcGxzLXNtcC1yZXF1aXJlbWVudHMtMDAudHh0DQoNCg0KSGkgRGF2ZSANCg0KU29ycnkg Zm9yIHRoZSBkZWxheWVkIHJlc3BvbnNlLCBzZWUgbXkgbm90ZXMgdGFnZ2VkIHdpdGggPGZlaT4g DQoNCg0KVGhhbmtzIA0KDQpGZWkgDQoNCkRhdmlkIEFsbGFuIEkgPGRhdmlkLmkuYWxsYW5AZXJp Y3Nzb24uY29tPiANCjIwMTItMDgtMjIgMDE6MjkgDQoNCg0KytW8/sjLDQoiemhhbmcuZmVpM0B6 dGUuY29tLmNuIiA8emhhbmcuZmVpM0B6dGUuY29tLmNuPiwgR3JlZ29yeSBNaXJza3kgDQo8Z3Jl Z29yeS5taXJza3lAZXJpY3Nzb24uY29tPiANCrOty80NCiJtcGxzQGlldGYub3JnIiA8bXBsc0Bp ZXRmLm9yZz4gDQrW98ziDQpSRTogW21wbHNdIENvbW1lbnRzIG9uIGRyYWZ0LXdlaW5nYXJ0ZW4t bXBscy1zbXAtcmVxdWlyZW1lbnRzLTAwLnR4dA0KDQoNCg0KDQoNCg0KDQoNCg0KDQpIaSBGZWk6 IA0KIA0KSSBzZWUgImEiIHByb3Bvc2VkIHNvbHV0aW9uIGluIHRoZSBkcmFmdCB5b3UgcmVmZXJl bmNlLCBidXQgbm90IGEgcHJvYmxlbSANCnN0YXRlbWVudCBvciBhbmFsc3lzaXMgDQoNCjxmZWk+ ICBUaGUgcHJvcG9zZWQgc29sdXRpb24gaXMgYmFzZSBvbiB0aGUgY29udHJvbCBwbGFuZSBleHRl bnNpb25zLCBhbmQgDQp0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgc2FpZCAiIFtSRkM0ODcyXSBkZWZp bmVzIHRoZSBzaGFyZWQgbWVzaCByZXN0b3JhdGlvbiANCnNjaGVtZXMgYmFzZWQgb24NCiBjb250 cm9sIHBsYW5lIGV4dGVuc2lvbnMsIGJ1dCBkb2VzIG5vdCBjb3ZlciB0aGUgc2hhcmVkIG1lc2gg IHByb3RlY3Rpb24gDQpzY2VuYXJpb3MuIiANCiANClRoZSBwcmVlbXB0aW9uIGNvdWxkIHNpbXBs eSBiZSBwZXJmb3JtZWQgYXQgbm9kZSBFLiBDdXJyZW50bHkgdGhlIG1vZGVsIGlzIA0KdGhhdCB0 aGUgTEVScyBuZWVkIHRvIG5vdGlmeSBub2RlIEUgd2hlbiB0aGUgUCBwYXRoIGlzIGJlaW5nIHVz ZWQsIGFuZCBFIA0KbmVlZHMgdG8gbm90aWZ5IHRoZSBMRVJzIG9mIHRoZSBjdXJyZW50IHN0YXRl IG9mIHRoZSBzaGFyZWQgcmVzb3VyY2UuIFRoaXMgDQphcHBlYXJzIHRvIGRlcGVuZCBvbiB0aGUg cHJlZW1wdGVkIExTUiB0byAiZG8gdGhlIHJpZ2h0IHRoaW5nIiBhbmQgbGVhZHMgDQp0byBhbiBJ TU8gdW5yZWFzb25hYmxlIHdpbmRvdyBvZiBjb250ZW50aW9uIGZvciB0aGUgc2hhcmVkIHJlc291 cmNlcy4gDQoNCiA8ZmVpPiBQcmVlbXB0aW9uIG1lYW5zIHRoYXQgIHRoZXJlIHdpbGwgYmUgYSB3 aW5kb3cgb2YgY29udGVudGlvbiwgd2h5IGl0IA0KaXMgdW5yZWFzb25hYmxlPyANCg0KSU1PIEUg c2hvdWxkIGJlIGRvaW5nIHRoZSBwcmVlbXB0aW9uLCBhbmQgSSd2ZSBzdGlsbCBub3QgcmVhbGx5 IHNlZW4gYSANCm5lZWQgZm9yIGhlYWQgZW5kIG5vdGlmaWNhdGlvbiBvZiBwcmVlbXB0aW9uIHVu bGVzcyBvbmUgc3RhcnRzIHBsYW5uaW5nIA0KYmFja3VwcyBmb3IgYmFja3Vwcy4gDQoNCiA8ZmVp PiBJTUhPLCB0aGVyZSBhcmUgdHdvIHByaW9yaXRpZXMgbmVlZCB0byBiZSBoYW5kbGVkIGluIHNo YXJlZCBtZXNoIA0KcHJvdGVjdGlvbiBzY2VuYXJpb3MsIHRoZSBwYXRoIHByaW9yaXR5IGFuZCB0 aGUgc2VydmljZSBwcmlvcml0eSAoUEhCKS4gSWYgDQpub2RlIEUgZG9lcyB0aGUgcHJlZW1wdGlv biwgaG93IHRvIA0KZGVhbCB3aXRoIHRoZSBwYXRoIHByaW9yaXR5LCB3aGljaCBpcyBub3QgY2Fy cmllZCBpbiB0cmFmZmljIHBhY2tldC4gDQogDQpJZiB5b3UgaGF2ZSBtb3JlIGluZm9ybWF0aW9u LCBjb3VsZCB5b3UgZWxhYm9yYWJsZT8gDQpEYXZlIA0KIA0KIA0KDQpGcm9tOiBtcGxzLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiAN CnpoYW5nLmZlaTNAenRlLmNvbS5jbg0KU2VudDogTW9uZGF5LCBBdWd1c3QgMjAsIDIwMTIgNDow MyBBTQ0KVG86IEdyZWdvcnkgTWlyc2t5DQpDYzogbXBsc0BpZXRmLm9yZzsgbXBscy1ib3VuY2Vz QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21wbHNdIENvbW1lbnRzIG9uIA0KZHJhZnQtd2Vpbmdh cnRlbi1tcGxzLXNtcC1yZXF1aXJlbWVudHMtMDAudHh0DQoNCg0KR3JlZywgc25pcHBlZCANCklu IHRoZSBsYXN0IHNlbnRlbmNlIG9mIFNlY3Rpb24gMy4xIG5vbi1jb250cm9sIHBsYW5lIGNvb3Jk aW5hdGlvbiBvZiANCnNoYXJlZCByZXNvdXJjZXMgcHJlc2VudGVkIGFzIGFub3RoZXIgcmVxdWly ZW1lbnQuIEFuZCBhZ2FpbiBJIGNhbiBub3QgDQpmaW5kIGhvdyB3ZSBjb21lIHRvIHN1Y2ggY29u Y2x1c2lvbiwgd2hlcmUgdGhlIHNvdXJjZSBvZiB0aGlzIHJlcXVpcmVtZW50LiANCldvdWxkIGV4 aXN0aW5nIGNvbnRyb2wgcGxhbmUgc2lnbmFsaW5nIHNvbHV0aW9uIGJlIHN1ZmZpY2llbnQgZm9y IGEgTVBMUyANCm5ldHdvcms/IA0KDQo8RmVpPiBJIGRvIG5vdCB0aGluayB0aGUgZXhpc3Rpbmcg Y29udHJvbCBwbGFuZSAoZGVmaW5lZCBpbiBSRkM0ODcyKSBpcyANCnN1ZmZpY2llbnQgZm9yIGEg TVBMUyBuZXR3b3JrLCBhbmQgdGhlcmUgaXMgYW4gYW5hbHlzaXMgaW4gdGhlIGRyYWZ0IA0KaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGUtY2NhbXAtbm90aWZpY2F0aW9uLXNoYXJl ZC1tZXNoLXByb3RlY3Rpb24tMDANCi4gDQoNCg0KQmVzdCByZWdhcmRzIA0KDQpGZWkgDQoNCkdy ZWdvcnkgTWlyc2t5IDxncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20+IA0Kt6K8/sjLOiAgbXBs cy1ib3VuY2VzQGlldGYub3JnIA0KMjAxMi0wOC0xNiAwNjo0NSANCg0KDQrK1bz+yMsNClBhYmxv IEZyYW5rIDxwYWJsb2lzbm90QGdtYWlsLmNvbT4sIFlhYWNvdiBXZWluZ2FydGVuIDx3eWFhY292 QGdtYWlsLmNvbT4gDQqzrcvNDQoibXBsc0BpZXRmLm9yZyIgPG1wbHNAaWV0Zi5vcmc+IA0K1vfM 4g0KUmU6IFttcGxzXSBDb21tZW50cyBvbiBkcmFmdC13ZWluZ2FydGVuLW1wbHMtc21wLXJlcXVp cmVtZW50cy0wMC50eHQNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkRlYXIgUGFibG8sIFlhYWNv diwgZXQgYWwuLCANCkkndmUgYmVlbiBmb2xsb3dpbmcgZGlzY3Vzc2lvbiB3aXRoIGdyZWF0IGRl YWwgb2YgaW50ZXJlc3QuIEkgaGF2ZSBzb21lIA0KcXVlc3Rpb25zIGluIGFkZGl0aW9uIHRvIG9u ZXMgYmVpbmcgYnJvdWdodCB1cCBieSBQYWJsbzogDQpTZWN0aW9uIDEuMiByZWZlcnMgdG8gb3Bl cmF0b3IncyBkZXNpcmUgdG8gaGF2ZSBzZXJ2aWNlIHJlc3RvcmF0aW9uIG1vcmUgDQpleHBlZGll bnQgdGhhbiBvbmUgYWNoaWV2YWJsZSB3aXRoIGNvbnRyb2wgcGxhbmUuIEkgaGF2ZW4ndCBzZWVu IGFueSANCnF1YW50YXRpdmUgaW5mb3JtYXRpb24gdG8gY29tcGFyZSB3aXRoLiBXaGF0IGlzICJl eHBlZGllbnQgZW5vdWdoIiBmb3IgDQpTTVA/IA0KU2VjdGlvbiAzLjEgZGVzcmNpYmVzLCB3aGF0 IGNhbiBiZSBjYWxsZWQsICJpbnN0YW50IGRldGVybWluaXNtIiBpbiByZWdhcmQgDQp0byBTTVAg cmVzb3VyY2UgYXZhaWFsYWJpbGl0eS4gSSB0aGluayB0aGF0IHRoZXJlJ3Mgbm90IGVub3VnaCBy ZWFzb25pbmcgDQp0byBjb25jbHVkZSB0aGF0IGFsbW9zdCBpbnN0YW50ZW5lb3VzIHVwZGF0ZSBv ZiBTTVAgcmVzb3VyY2VzIA0KYXZhaWFsYWJpbGl0eSBpcyByZXF1aXJlZC4gDQpJbiB0aGUgbGFz dCBzZW50ZW5jZSBvZiBTZWN0aW9uIDMuMSBub24tY29udHJvbCBwbGFuZSBjb29yZGluYXRpb24g b2YgDQpzaGFyZWQgcmVzb3VyY2VzIHByZXNlbnRlZCBhcyBhbm90aGVyIHJlcXVpcmVtZW50LiBB bmQgYWdhaW4gSSBjYW4gbm90IA0KZmluZCBob3cgd2UgY29tZSB0byBzdWNoIGNvbmNsdXNpb24s IHdoZXJlIHRoZSBzb3VyY2Ugb2YgdGhpcyByZXF1aXJlbWVudC4gDQpXb3VsZCBleGlzdGluZyBj b250cm9sIHBsYW5lIHNpZ25hbGluZyBzb2x1dGlvbiBiZSBzdWZmaWNpZW50IGZvciBhIE1QTFMg DQpuZXR3b3JrPyANCkkndmUgbm90aWNlZCB0aGF0IG1hbnkgcmVxdWlyZW1lbnRzIGJlaW5nIHJl ZmVycmVkIHRvIE1QTFMtVFAsIG5vdCBNUExTLCANCm5ldHdvcmtzLiBXb3VsZCB0aGF0IGJlIGEg Z29vZCByZWFzb24gdG8gbmFycm93IHNjb3BlIG9mIHRoZSBkb2N1bWVudCB0byANCk1QTFMtVFAg bmV0d29ya3Mgb25seSwgc3RhcnRpbmcgd2l0aCB0aGUgbmFtZSBvZiB0aGUgZG9jdW1lbnQ/DQog ICAgUmVnYXJkcywgDQogICAgICBHcmVnIA0KDQpGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiANClBhYmxvIEZyYW5r DQpTZW50OiBGcmlkYXksIEF1Z3VzdCAxMCwgMjAxMiA3OjIzIEFNDQpUbzogWWFhY292IFdlaW5n YXJ0ZW4NCkNjOiBtcGxzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21wbHNdIENvbW1lbnRzIG9u IA0KZHJhZnQtd2VpbmdhcnRlbi1tcGxzLXNtcC1yZXF1aXJlbWVudHMtMDAudHh0DQoNCkhpIFlh YWNvdiwgDQoNClNvbWUgbW9yZSBjb21tZW50cyBpbmxpbmUuLi4gUEY+Pg0KDQpPbiBNb24sIEF1 ZyA2LCAyMDEyIGF0IDg6NTYgQU0sIFlhYWNvdiBXZWluZ2FydGVuIDx3eWFhY292QGdtYWlsLmNv bT4gDQp3cm90ZTogDQpIaSwgDQoNClRoYW5rIHlvdSBmb3IgeW91ciBjb21tZW50cy4gIFBsZWFz ZSBzZWUgbXkgY29tbWVudHMgaW5saW5lIGJlbG93LiANCg0KQlIsIA0KeWFhY292DQoNCk9uIFR1 ZSwgSnVsIDE3LCAyMDEyIGF0IDExOjUxIFBNLCBQYWJsbyBGcmFuayA8cGFibG9pc25vdEBnbWFp bC5jb20+IA0Kd3JvdGU6IA0KR29vZCBkcmFmdCBhbmQgY2VydGFpbmx5IHNvbWV0aGluZyB0aGF0 IG5lZWRzIHRvIGJlIGRvbmUgYmVmb3JlIHdlIGNhbiANCnN0YXJ0IGRpc2N1c3Npbmcgc3BlY2lm aWMgc29sdXRpb25zLiANCg0KT25seSBhIGZldyBjb21tZW50cyAvIHF1ZXN0aW9uczogDQoNCi0g SW4gNC4xLjEsIGlmIG9uZSBpcyBvcGVyYXRpbmcgaW4gYW4gTVBMUy1UUCBuZXR3b3JrIHRoYXQg cmVxdWlyZXMgDQpleGNsdXNpdmUgdXNlIG9mIHRoZSBwcm90ZWN0aW9uIHJlc291cmNlcywgZG9l c24ndCB0aGlzIFNIT1VMRCByZXF1aXJlbWVudCANCmJlY29tZSBhIE1VU1QgcmVxdWlyZW1lbnQ/ IA0KDQp5dz4+IFNvcnJ5IC0gYnV0IGNvdWxkIHlvdSBleHBsYWluIG1vcmUgZnVsbHkgdGhpcyBj b21tZW50LiANCg0KUEY+PiAgSWYgeW91J3JlIHRyeWluZyB0byBtZWV0IFJGQyA1NjU0IHJlcSA1 OGIgaW4gcGFydGljdWxhciwgSSB3b3VsZCANCnRoaW5rIHlvdSBNVVNUIHZhbGlkYXRlIHRoYXQg ZW5vdWdoIHByb3RlY3Rpb24gcmVzb3VyY2VzIGFyZSBhdmFpbGFibGUgKG9yIA0KYXJlIHByZWVt cHRpYmxlKSB0byBjYXJyeSAxMDAlIG9mIHRoZSBzZXJ2aWNlIHRyYWZmaWMgdGhhdCBpcyBiZWlu ZyANCnJlc3RvcmVkLiAgSW4gZXhpc3RpbmcgdHJhbnNwb3J0IG5ldHdvcmtzIChpLmUuIE9UTiAv IHNvbmV0KSwgdGhpcyBpcyANCnR5cGljYWxseSBkb25lIGJlZm9yZSB5b3Ugc3dpdGNoIHRyYWZm aWMgdG8gdGhlIHByb3RlY3Rpb24gcGF0aC4gIEZyb20gYSANCnNvbHV0aW9uIHBlcnNwZWN0aXZl LCBJIHRoaW5rIHlvdSdsbCBwcm9iYWJseSB3YW50IHRvIGxldmVyYWdlIHNvbWV0aGluZyANCmxp a2UgdGhlIGxvY2tpbmcgbW9kZSB0aGF0IGlzIGJlaW5nIHByb3Bvc2VkIGZvciB0aGUgMTpuIGRy YWZ0LiANCg0KLSBOaXQ6IHlvdSBtaWdodCB3YW50IHRvIGF2b2lkIHVzaW5nIHRoZSAicXVlcnki IHZlcmIgaW4gdGhlIHRpdGxlIG9mIA0KNC4xLjEgYmVjYXVzZSBpdCBzdWJ0bHkgc3VnZ2VzdHMg c29tZSBraW5kIG9mIHByb3RvY29sIG1lc3NhZ2luZyBpcyANCnJlcXVpcmVkLiAgSSB3b3VsZCB1 c2UgdGhlIG1vcmUgZ2VuZXJpYyB2ZXJiICJjaGVja2luZyIgb3IgInZlcmlmeWluZyIuIA0KeXc+ PiBTb3VuZHMgT0sgdG8gbWUuIA0KLSBJbiA0LjMsIHRoZXJlIGlzIG5vIHN1Z2dlc3Rpb24gZm9y IHdoYXQgc2hvdWxkIGhhcHBlbiBpZiBvbmUgb3IgbW9yZSANCmZhaWxpbmcgcGF0aHMgaW4gYW4g TVBMUy1UUCBuZXR3b3JrIGFyZSBvZiBlcXVhbCBwcmlvcml0eS4gIEkgcHJlc3VtZSBpdCANCndp bGwgYmUgc29tZSBraW5kIG9mIGZpcnN0LWNvbWUsIGZpcnN0LXNlcnZlIHJlcXVpcmVtZW50IGJ1 dCB0aGlzIHdpbGwgDQpicmluZyB1cCB0aGUgcXVlc3Rpb24gb2YgaG93IHRvIGJyZWFrIHRpZXMu IA0KeXc+PiBUaGlzIGNvdWxkIGJlIHJlc29sdmVkIGFsb25nIHRoZSBsaW5lcyB0aGF0IGl0IHdh cyBhZGRyZXNzZWQgaW4gdGhlIA0KMTpuIHByb3RlY3Rpb24gDQoNClBGPj4gRXhjZXB0IHRoYXQg eW91IGd1eXMgcmVtb3ZlZCBzZXBhcmF0ZSBwYXRoIHByaW9yaXR5IGZyb20gdGhlIGxhdGVzdCAN CnZlcnNpb24gb2YgdGhlIDE6biBkcmFmdC4gIEluIHRoZSBsYXRlc3QgdmVyc2lvbiwgZWFjaCBw YXRoIGhhcyBhIHN0cmljdCANCnByaW9yaXR5IGRlZmluZWQgYnkgaXRzIHBhdGggSUQgc28gdGll cyB3ZXJlIG5vdCBwb3NzaWJsZS4gIEkgZG9uJ3QgdGhpbmsgDQp0aGF0IHNvbHV0aW9uIHdpbGwg d29yayBmb3IgU01QIGJlY2F1c2UgSSBoYXZlIGEgaGFyZCB0aW1lIHNlZWluZyBob3cgYWxsIA0K dGhlIHZhcmlvdXMgZW5kcG9pbnRzIGludm9sdmVkIGluIGEgc2hhcmVkIG1lc2ggY291bGQgY29v cmRpbmF0ZSANCm5vbi1vdmVybGFwcGluZyBwYXRoIElEcywgd2hpbGUgYXQgdGhlIHNhbWUgdGlt ZSBub3QgZXhjZWVkaW5nIHRoZSBsaW1pdCANCm9mIDI1NSBwYXRoIElEcy4gDQoNCg0KLSBBbHNv IGluIDQuMywgdGhlcmUgaXMgYW4gYWxsb3dhbmNlIGZvciBhIGhpZ2ggcHJpb3JpdHkgcGF0aCBh bmQgYSBsb3dlciANCnByaW9yaXR5IHBhdGggdG8gdGVtcG9yYXJpbHkgc2hhcmUgdGhlIHByb3Rl Y3Rpb24gcmVzb3VyY2VzIHdoaWxlIA0KcHJlZW1wdGlvbiBpcyB0YWtpbmcgcGxhY2UuICBUd28g cXVlc3Rpb25zOiANCi0gSXMgdGhlIGluZ3Jlc3Mgbm9kZSB0byB0aGUgc2hhcmVkIHNlZ21lbnQg ZXhwZWN0ZWQgdG8gZGlzY2FyZCBleGNlc3MgDQp0cmFmZmljIG5vdyB0aGF0IHRoZSBwcm90ZWN0 aW9uLXBhdGggaXMgdGVtcG9yYXJpbHkgb3ZlcnN1YnNjcmliZWQ/IA0KeXc+PiB0aGlzIHdvdWxk IG1vc3QgcHJvYmFibHkgZm9sbG93IHN0YW5kYXJkIE1QTFMgYmVoYXZpb3IgYXMgZGVzY3JpYmVk IA0KZWxzZXdoZXJlIA0KDQpQRj4+IEkgZ3Vlc3MgSSdsbCBhc2sgd2hhdCBpcyB0aGUgc3RhbmRh cmQgYmVoYXZpb3VyPyAgQW5kIGlzIGl0IA0KYXBwbGljYWJsZSB0byBNUExTLVRQIG5ldHdvcmtz PyANCg0KLSBJZiBub3QsIGhvdyBkbyB3ZSBlbnN1cmUgdGhhdCBvdGhlciB0cmFuc3BvcnQgcGF0 aHMgYXJlIHVuYWZmZWN0ZWQ/IA0KLSBUaGUgZmlyc3QgcGFyYWdyYXBoIG9mIDQuNCBhcHBlYXJz IHRvIGNvbnRyYWRpY3QgNC4xLjEuICA0LjQgc2VlbXMgdG8gDQpzdWdnZXN0IHRoYXQgb25lIE1V U1Qgc3dpdGNoIHRoZSB0cmFmZmljIG9udG8gdGhlIHByb3RlY3Rpb24gcGF0aCBmaXJzdCANCmFu ZCB0aGVuIGdldCBub3RpZmllZCBpZiB0aGVyZSdzIG5vdCBlbm91Z2ggcmVzb3VyY2VzLiAgVGhh dCdzIHByb2JhYmx5IA0Kb2theSBpbiB0aGUgZ2VuZXJhbCBjYXNlLiAgQnV0IGluIGFuIE1QTFMt VFAgbmV0d29yaywgSSBkb24ndCB0aGluayBpdCdzIGEgDQpnb29kIGlkZWEgdG8gYmxpbmRseSBz d2l0Y2ggbG93IHByaW9yaXR5IHRyYWZmaWMgb250byB0aGUgcHJvdGVjdGlvbiBwYXRoIA0KYW5k IHBvc3NpYmx5IGRpc3J1cHQgYSBoaWdoIHByaW9yaXR5IHBhdGggdGhhdCBpcyBhbHJlYWR5IHVz aW5nIHRoYXQgDQpyZXNvdXJjZS4gDQp5dz4+IFRoaXMgaXMgZGVwZW5kZW50IHVwb24gdGhlIGFj dHVhbCBtZWNoYW5pc20gdGhhdCBpcyBkZXZlbG9wZWQgYnkgdGhlIA0KV0cuICBGb3IgZXhhbXBs ZSwgb25lIHN1Z2dlc3Rpb24gZm9yIHRoZSBtZWNoYW5pc20gaGFzIG5vdGlmaWNhdGlvbnMgc2Vu dCANCnRvIGxvd2VyIHByaW9yaXR5IHdvcmtpbmcgcGF0aHMgbWFraW5nIHRoZSBwcm90ZWN0aW9u IHBhdGggdW5hdmFpbGFibGUgaWYgDQppdCBpcyBpbiB1c2UgYnkgYSBoaWdoLXByaW9yaXR5IHdv cmtpbmcgcGF0aC4gDQoNCi0gSW4gc2VjdGlvbiA0LjUsIHRoZXJlJ3MgYW4gYXR0ZW1wdCB0byBk ZWZpbmUgInByb3RlY3Rpb24gc3dpdGNoaW5nIHRpbWUiIA0KYXMgbm90IGluY2x1ZGluZyBwcmVl bXB0aW9uIHRpbWUuICBJIGRvbid0IHRoaW5rIGVuZC11c2VycyByZWFsbHkgY2FyZSANCmFib3V0 ICJwcm90ZWN0aW9uIHN3aXRjaGluZyB0aW1lIi4gIFRoZXkgY2FyZSBhYm91dCByZWNvdmVyeSB0 aW1lIGFuZCBJTU8sIA0KdGhhdCBzaG91bGQgYWxzbyBpbmNsdWRlIGZhdWx0IGRldGVjdGlvbiB0 aW1lIChhbHRob3VnaCBpdCBkb2Vzbid0IHBlciBSRkMgDQo1NjU0KSBhbmQgYW55IHByZWVtcHRp b24gdGltZS4gDQp5dz4+IHdlIGRvIHRyeSB0byB3b3JrIHdpdGhpbiB0aGUgYWNjZXB0ZWQgZGVm aW5pdGlvbnMgb2YgdGhlIElFVEYhIA0KDQpQRj4+IEkgZ3Vlc3MgdGhlcmUncyB0d28gc2VwYXJh dGUgY29tbWVudHMgaGVyZSB0aGF0IEkga2luZGEgY29uZmxhdGVkIA0KdG9nZXRoZXIuICBPbmUg d2FzIG1vcmUgb2YgYSBncmlwZTogd2h5IGRpZCB3ZSBleGNsdWRlIGZhdWx0IGRldGVjdGlvbiAN CnRpbWUgZnJvbSB0aGUgNTBtcyByZXN0b3JhdGlvbiB0aW1lIHJlcXVpcmVtZW50IGluIFJGQyA1 NjU0PyAgSSBrbm93IHRoYXQgDQpteSBjdXN0b21lcnMgbWVhc3VyZSBvbmx5IG9uZSB0aGluZzog aG93IG1hbnkgbXMgb2YgdHJhZmZpYyBkbyB0aGV5IGxvc2UgDQphZnRlciBhIGJyZWFrYWdlLiAg SSBkb24ndCBnZXQgYSBmcmVlIHBhc3Mgb24gdGhlIH4xMG1zIGl0IHRha2VzIGZvciBCRkQgDQp0 byBkZXRlY3QgdGhlIGZhaWx1cmUuICBBY2NvcmRpbmcgdG8gUkZDIDU2NTQsIEkgY291bGQgdXNl IDYwc2VjIENDTXMgYW5kIA0Kc3RpbGwgbWVldCB0aGUgNTBtcyByZXF1aXJlbWVudCEgDQoNClRo ZSAybmQgY29tbWVudCB3YXMgcmVhbGx5IGFib3V0IHRoaXMgZHJhZnQgbm93IHRyeWluZyB0byBl eGNsdWRlIA0KcHJlZW1wdGlvbiB0aW1lIGZyb20gcmVzdG9yYXRpb24gdGltZSBhcyB3ZWxsLiAg SU1PLCBpZiBpdCB0YWtlcyBhIGZldyANCnNlY29uZHMgZm9yIGEgaGlnaCBwcmlvcml0eSBzZXJ2 aWNlIHRvIGZpbmlzaCBwcmVlbXB0aW5nIGEgbG93ZXIgcHJpb3JpdHkgDQpzZXJ2aWNlLCB0aGVu IHdlIGhhdmVuJ3QgbWV0IHRoZSA1MG1zIHJlc3RvcmF0aW9uIHRpbWUgcmVxdWlyZW1lbnQuIA0K RXNwZWNpYWxseSBzaW5jZSBpdCdzIHR5cGljYWxseSBteSBoaWdoZXIgcHJpb3JpdHkgc2Vydmlj ZXMgdGhhdCB3YW50IDUwbXMgDQpyZXN0b3JhdGlvbiB0aW1lcyBpbiB0aGUgZmlyc3QgcGxhY2Us IHNvIHRoZXknbGwgYmUgbW9yZSBvZnRlbiBpbiBhIA0KcG9zaXRpb24gdG8gcHJlZW1wdC4gIElu IG90aGVyIHdvcmRzLCBJIHRoaW5rIHdlIHdhbnQgcHJlZW1wdGlvbiB0byBiZSANCmZhc3QgYW5k IGlzIGEgY3JpdGljYWwgY29tcG9uZW50IG9mIHByb3RlY3Rpb24gc3dpdGNoaW5nLiANCg0KDQpy ZWdhcmRzLCANClBhYmxvIA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0KDQo= --=_alternative 00256D6E48257A68_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkRhdmUsIDwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Rm9yIE1QTFMgbmV0d29ya3MsIEkg YWdyZWUgd2l0aCB5b3UNCnRoYXQgbm9kZSBFIGNhbiBwcmUtc3RvcmUgdGhlIHBhdGggcHJpb3Jp dHkgYW5kIGRvIHRoZSBzd2l0Y2ggYW5kIG5vdGlmaWNhdGlvbi4NCjotKTwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SWYgd2UgY29uc2lkZXIgYSB1bmlm b3JtIG1lY2hhbmlzbSBmb3INCnRoZSBiYWNrYm9uZSBuZXR3b3JrcyAoTVBMUy1UUCwgT1ROLCBT T05FL1NESCwgV1NPTiksIEkgdGVuZCB0byB0aGluayBoZWFkDQplbmQgbm90aWZpY2F0aW9uIHdp bnMuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Ib3Bl IHRoaXMgY2xhcmlmeSBteSBvcGluaW9uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5yZWdhcmRzPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5GZWk8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lk dGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM2JT48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+PGI+RGF2aWQgQWxsYW4gSSAmbHQ7ZGF2aWQuaS5hbGxhbkBlcmljc3Nv bi5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PjIwMTItMDgtMjggMTQ6MzU8L2ZvbnQ+DQo8dGQgd2lkdGg9NjMlPg0KPHRhYmxlIHdpZHRoPTEw MCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7emhhbmcuZmVpM0B6dGUuY29tLmNuJnF1b3Q7ICZsdDt6 aGFuZy5mZWkzQHp0ZS5jb20uY24mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8 ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250 PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5HcmVnb3J5IE1pcnNr eSAmbHQ7Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tJmd0OywNCiZxdW90O21wbHNAaWV0Zi5v cmcmcXVvdDsgJmx0O21wbHNAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98zi PC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SRTogW21w bHNdIENvbW1lbnRzIG9uIGRyYWZ0LXdlaW5nYXJ0ZW4tbXBscy1zbXAtcmVxdWlyZW1lbnRzLTAw LnR4dDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj5Gb3IgY2lyY3VpdCB0ZWNobm9sb2d5IEkgYWdyZWUs DQpyZXNvdXJjZSBjb25zdW1wdGlvbiBhbmQgY29ubmVjdGl2aXR5IGFyZSBsaW5rZWQgYW5kIGNv b3JkaW5hdGlvbiBpcyByZXF1aXJlZC4NCkJ1dCB0aGF0IHN0aWxsIHN1Z2dlc3RzIHRoYXQgYWxs IHByZWVtcHRpb24gYWN0aXZpdHkgaXMgb3IgY2FuIGJlIGNvbmZpbmVkDQp0byB0aGUgc2hhcmVk IHBhcnQgb2YgdGhlIHBhdGguIEluIHRoYXQgcmVnYXJkIEkgdGhpbmsgd2UgYXJlIGRpZ3Jlc3Np bmcNCmZyb20gdGhlIG9yaWdpbmFsIGlzc3Vlcy4uLndoaWNoIHdhcyBhbnkgcmVxdWlyZW1lbnQg Zm9yIGhlYWQgZW5kIG5vdGlmaWNhdGlvbi48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBm YWNlPSJBcmlhbCI+RGF2ZTwvZm9udD4NCjxicj4NCjxicj4NCjxocj48Zm9udCBzaXplPTIgZmFj ZT0iVGFob21hIj48Yj5Gcm9tOjwvYj4gemhhbmcuZmVpM0B6dGUuY29tLmNuIFttYWlsdG86emhh bmcuZmVpM0B6dGUuY29tLmNuXQ0KPGI+PGJyPg0KU2VudDo8L2I+IFR1ZXNkYXksIEF1Z3VzdCAy OCwgMjAxMiA5OjMxIEFNPGI+PGJyPg0KVG86PC9iPiBEYXZpZCBBbGxhbiBJPGI+PGJyPg0KQ2M6 PC9iPiBHcmVnb3J5IE1pcnNreTsgbXBsc0BpZXRmLm9yZzxiPjxicj4NClN1YmplY3Q6PC9iPiBS RTogW21wbHNdIENvbW1lbnRzIG9uIGRyYWZ0LXdlaW5nYXJ0ZW4tbXBscy1zbXAtcmVxdWlyZW1l bnRzLTAwLnR4dDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpIaSBEYXZlPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpUaGFuayB5b3UgZm9yIHlvdXIgbmljZSByZXNw b25zZTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NClNlZSBpbiBsaW5lIHdpdGggJmx0 O2ZlaTEmZ3Q7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPC9m b250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpUaGFua3M8L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPjxicj4NCkZlaTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1z ZXJpZiI+IDxicj4NCjxicj4NCjwvZm9udD4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGln bj10b3A+DQo8dGQgd2lkdGg9MzclPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5E YXZpZCBBbGxhbiBJICZsdDtkYXZpZC5pLmFsbGFuQGVyaWNzc29uLmNvbSZndDs8L2I+DQo8L2Zv bnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMi0wOC0yOCAxMzo0ODwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dGQgd2lkdGg9 NjIlPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0 aD03JT4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrV vP7IyzwvZm9udD48L2Rpdj4NCjx0ZCB3aWR0aD05MiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPiZxdW90O3poYW5nLmZlaTNAenRlLmNvbS5jbiZxdW90Ow0KJmx0O3poYW5nLmZlaTNA enRlLmNvbS5jbiZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2Zv bnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPkdyZWdvcnkgTWlyc2t5ICZsdDtncmVnb3J5Lm1pcnNreUBlcmljc3Nv bi5jb20mZ3Q7LA0KJnF1b3Q7bXBsc0BpZXRmLm9yZyZxdW90OyAmbHQ7bXBsc0BpZXRmLm9yZyZn dDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj5SRTogW21wbHNdIENvbW1lbnRzIG9uIGRyYWZ0LXdlaW5nYXJ0ZW4tbXBscy1zbXAtcmVx dWlyZW1lbnRzLTAwLnR4dDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRo PTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD01MCU+DQo8dGQgd2lkdGg9NTAlPjwv dGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ PGJyPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48 YnI+DQpISSBGZWk6PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0K ICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PGJyPg0K WW91IHdyb3RlOjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxicj4NCiAmbHQ7ZmVpJmd0OyBJTUhPLCB0aGVyZSBh cmUgdHdvIHByaW9yaXRpZXMgbmVlZCB0byBiZSBoYW5kbGVkIGluIHNoYXJlZA0KbWVzaCBwcm90 ZWN0aW9uIHNjZW5hcmlvcywgdGhlIHBhdGggcHJpb3JpdHkgYW5kIHRoZSBzZXJ2aWNlIHByaW9y aXR5IChQSEIpLg0KSWYgbm9kZSBFIGRvZXMgdGhlIHByZWVtcHRpb24sIGhvdyB0byA8YnI+DQpk ZWFsIHdpdGggdGhlIHBhdGggcHJpb3JpdHksIHdoaWNoIGlzIG5vdCBjYXJyaWVkIGluIHRyYWZm aWMgcGFja2V0LiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjxi cj4NCk15IHVuZGVyc3RhbmRpbmcgb2YgeW91ciBwcm9wb3NhbCBpcyB0aGF0IHZpYSBjb250cm9s IHBsYW5lIGV4Y2hhbmdlLCBFDQprbm93cyB0aGUgcGF0aCBwcmlvcml0eS4gQ2VydGFpbmx5IHRo ZSBpbmdyZXNzZXMgYXJlIHVuYXdhcmUgb2YgZWFjaCBvdGhlcg0Kd2l0aG91dCBhIGNvb3JkaW5h dGlvbiBtZWNoYW5pc20gd2hpY2ggYXMgY3VycmVudGx5IGRlc2NyaWJlZCBpcyBub3RpZmljYXRp b25zDQpvcmlnaW5hdGluZyB3aXRoIEUuIE15IHN1Z2dlc3Rpb24gaXMgdGhhdCB0aGUgRSBhcyB0 aGUgcHJlZW1wdGlvbiBwb2ludA0KaGFzIHN1ZmZpY2llbnQga25vd2xlZGdlIHRvIHBlcmZvcm0g dGhpcyBmdW5jdGlvbiwgYW5kIHdvdWxkIGRvIGl0IHdpdGgNCmxlc3MgbGF0ZW5jeSB0aGFuIGhl YWQgZW5kIG5vdGlmaWNhdGlvbiBhbmQgdGhlIGhlYWQgZW5kIGFzIHRoZSBwcmVlbXB0aW9uDQpw b2ludC4gSXQgaGFzIHRoZSBhZGRlZCBwbHVzIG9mIG5vdCBiZWluZyBkZXBlbmRlbnQgb24gdGhl IGhlYWQgZW5kIG5vdA0KYmVpbmcgYnJhaW4gZGVhZC4uLi48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48 YnI+DQogJmx0O2ZlaTEmZ3Q7IE9rLCBJIHRoaW5rIEkgdW5kZXJzdGFuZCB5b3VyIGlkZWEgbm93 LiAmbmJzcDtJTUhPLCAmbmJzcDthbHRob3VnaA0KdGhlIHJlcXVpcmVtZW50cyBhcmUgY29taW5n IGZyb20gTVBMUy1UUCwgdGhlIHN0YW5kYXJkIGhhZCBiZXR0ZXIgY292ZXJpbmcNCnRoZSBvdGhl ciBzY2VuYXJpb3MuIENvbnNpZGVyIHRoZSBPRFUyIHBhdGggYXMgdGhlIHNoYXJlZCBwYXRoIHNl Z21lbnQsDQphbmQgdGhlIG5vZGUgRSBhcyB0aGUgcHJlZW1wdGlvbiBwb2ludCAoanVzdCBhcyB5 b3Ugc2FpZCkuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxicj4NCnQwIEgtRS1GLUctSyBhcyB0aGUg cHJvdGVjdGluZyBwYXRoIGFyZSBwcm90ZWN0aW5nIHRoZSB3b3JrIHBhdGggSC1JLUotSzwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9IkFyaWFsIj48YnI+DQp0MSBBLUItQy1EIGlzIGJyb2tlbiwgbm9kZSBBIHN3aXRjaGVzIHRo ZSB0cmFmZmljIHRvIEEtRTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48YnI+DQp0MiBub2RlIEUgc3dpdGNoZXMg dGhlIGNyb3NzY29ubmVjdCBmcm9tIEgtRSB0byBBLUUgKHBhdGggQS1CLUMtRCBoYXMgaGlnaGVy DQpwcmlvcml0eSB0aGFuIEgtSS1KLUspPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+PGJyPg0KSG93ZXZl ciwgbm9kZSBHIGNhbiBub3QgbWFrZSBzdXJlIHRvIHN3aXRjaCB0aGUgY3Jvc3Njb25uZWN0IGZy b20gRy1LIHRvDQpHLUQgc2ltdWx0YW5lb3VzbHkgYXMgYXQgbm9kZSBFLiBNaXNjb25uZWN0aW9u IHdpbGwgaGFwcGVuLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+ DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjxicj4NCkkgaG9w ZSB0aGlzIGhlbHBzPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250 Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48YnI+DQpEYXZlPC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPGJyPg0KPC9mb250Pg0KPGhyPjxm b250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPkZyb206PC9iPiB6aGFuZy5mZWkzQHp0ZS5jb20u Y24gW21haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20uY25dDQo8Yj48YnI+DQpTZW50OjwvYj4gVHVl c2RheSwgQXVndXN0IDI4LCAyMDEyIDU6NTIgQU08Yj48YnI+DQpUbzo8L2I+IERhdmlkIEFsbGFu IEk8Yj48YnI+DQpDYzo8L2I+IEdyZWdvcnkgTWlyc2t5OyBtcGxzQGlldGYub3JnPGI+PGJyPg0K U3ViamVjdDo8L2I+IFJFOiBbbXBsc10gQ29tbWVudHMgb24gZHJhZnQtd2VpbmdhcnRlbi1tcGxz LXNtcC1yZXF1aXJlbWVudHMtMDAudHh0PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxi cj4NCkhpIERhdmU8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NClNvcnJ5IGZvciB0aGUg ZGVsYXllZCByZXNwb25zZSwgc2VlIG15IG5vdGVzIHRhZ2dlZCB3aXRoICZsdDtmZWkmZ3Q7PC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjwvZm9udD48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KVGhhbmtzPC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj48YnI+DQo8YnI+DQpGZWk8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi PiA8YnI+DQo8L2ZvbnQ+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRk IHdpZHRoPTMzJT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+RGF2aWQgQWxsYW4g SSAmbHQ7ZGF2aWQuaS5hbGxhbkBlcmljc3Nvbi5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTItMDgtMjIgMDE6Mjk8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRkIHdpZHRoPTY2JT4NCjxicj4N Cjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NSU+DQo8ZGl2 IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+ PC9kaXY+DQo8dGQgd2lkdGg9OTQlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVv dDt6aGFuZy5mZWkzQHp0ZS5jb20uY24mcXVvdDsNCiZsdDt6aGFuZy5mZWkzQHp0ZS5jb20uY24m Z3Q7LCBHcmVnb3J5IE1pcnNreSAmbHQ7Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tJmd0Ozwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PiZxdW90O21wbHNAaWV0Zi5vcmcmcXVvdDsgJmx0O21wbHNAaWV0Zi5vcmcmZ3Q7PC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM 4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UkU6IFtt cGxzXSBDb21tZW50cyBvbiBkcmFmdC13ZWluZ2FydGVuLW1wbHMtc21wLXJlcXVpcmVtZW50cy0w MC50eHQ8L2ZvbnQ+PC90YWJsZT4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ PGJyPg0KPC9mb250Pg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZCB3aWR0aD01MCU+DQo8dGQgd2lkdGg9NTAlPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxi cj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KPC9mb250Pjxmb250 IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48YnI+DQo8YnI+DQpIaSBGZWk6PC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KIDwvZm9udD48Zm9udCBzaXpl PTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PGJyPg0KSSBzZWUgJnF1b3Q7YSZxdW90OyBwcm9w b3NlZCBzb2x1dGlvbiBpbiB0aGUgZHJhZnQgeW91IHJlZmVyZW5jZSwgYnV0IG5vdA0KYSBwcm9i bGVtIHN0YXRlbWVudCBvciBhbmFsc3lzaXM8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+PGJyPg0KPGJyPg0KJmx0 O2ZlaSZndDsgJm5ic3A7VGhlIHByb3Bvc2VkIHNvbHV0aW9uIGlzIGJhc2Ugb24gdGhlIGNvbnRy b2wgcGxhbmUgZXh0ZW5zaW9ucywNCmFuZCB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgc2FpZCAmcXVv dDsgW1JGQzQ4NzJdIGRlZmluZXMgdGhlIHNoYXJlZCBtZXNoDQpyZXN0b3JhdGlvbiBzY2hlbWVz IGJhc2VkIG9uPGJyPg0KIGNvbnRyb2wgcGxhbmUgZXh0ZW5zaW9ucywgYnV0IGRvZXMgbm90IGNv dmVyIHRoZSBzaGFyZWQgbWVzaCAmbmJzcDtwcm90ZWN0aW9uDQpzY2VuYXJpb3MuJnF1b3Q7PC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KIDwvZm9udD48Zm9udCBz aXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PGJyPg0KVGhlIHByZWVtcHRpb24gY291bGQg c2ltcGx5IGJlIHBlcmZvcm1lZCBhdCBub2RlIEUuIEN1cnJlbnRseSB0aGUgbW9kZWwNCmlzIHRo YXQgdGhlIExFUnMgbmVlZCB0byBub3RpZnkgbm9kZSBFIHdoZW4gdGhlIFAgcGF0aCBpcyBiZWlu ZyB1c2VkLCBhbmQNCkUgbmVlZHMgdG8gbm90aWZ5IHRoZSBMRVJzIG9mIHRoZSBjdXJyZW50IHN0 YXRlIG9mIHRoZSBzaGFyZWQgcmVzb3VyY2UuDQombmJzcDtUaGlzIGFwcGVhcnMgdG8gZGVwZW5k IG9uIHRoZSBwcmVlbXB0ZWQgTFNSIHRvICZxdW90O2RvIHRoZSByaWdodA0KdGhpbmcmcXVvdDsg YW5kIGxlYWRzIHRvIGFuIElNTyB1bnJlYXNvbmFibGUgd2luZG93IG9mIGNvbnRlbnRpb24gZm9y IHRoZQ0Kc2hhcmVkIHJlc291cmNlcy48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48YnI+DQo8YnI+DQogJmx0O2Zl aSZndDsgUHJlZW1wdGlvbiBtZWFucyB0aGF0ICZuYnNwO3RoZXJlIHdpbGwgYmUgYSB3aW5kb3cg b2YgY29udGVudGlvbiwNCndoeSBpdCBpcyB1bnJlYXNvbmFibGU/PC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9 IkFyaWFsIj48YnI+DQo8YnI+DQpJTU8gRSBzaG91bGQgYmUgZG9pbmcgdGhlIHByZWVtcHRpb24s IGFuZCBJJ3ZlIHN0aWxsIG5vdCByZWFsbHkgc2VlbiBhDQpuZWVkIGZvciBoZWFkIGVuZCBub3Rp ZmljYXRpb24gb2YgcHJlZW1wdGlvbiB1bmxlc3Mgb25lIHN0YXJ0cyBwbGFubmluZw0KYmFja3Vw cyBmb3IgYmFja3Vwcy48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48YnI+DQo8YnI+DQogJmx0O2ZlaSZndDsgSU1I TywgdGhlcmUgYXJlIHR3byBwcmlvcml0aWVzIG5lZWQgdG8gYmUgaGFuZGxlZCBpbiBzaGFyZWQN Cm1lc2ggcHJvdGVjdGlvbiBzY2VuYXJpb3MsIHRoZSBwYXRoIHByaW9yaXR5IGFuZCB0aGUgc2Vy dmljZSBwcmlvcml0eSAoUEhCKS4NCklmIG5vZGUgRSBkb2VzIHRoZSBwcmVlbXB0aW9uLCBob3cg dG8gPGJyPg0KZGVhbCB3aXRoIHRoZSBwYXRoIHByaW9yaXR5LCB3aGljaCBpcyBub3QgY2Fycmll ZCBpbiB0cmFmZmljIHBhY2tldC4gPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij48YnI+DQogPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48YnI+ DQpJZiB5b3UgaGF2ZSBtb3JlIGluZm9ybWF0aW9uLCBjb3VsZCB5b3UgZWxhYm9yYWJsZT88L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBj b2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48YnI+DQpEYXZlPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj4gPGJyPg0KIDxicj4NCiA8YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8aHI+PGZv bnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+RnJvbTo8L2I+IG1wbHMtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+emhh bmcuZmVpM0B6dGUuY29tLmNuPGI+PGJyPg0KU2VudDo8L2I+IE1vbmRheSwgQXVndXN0IDIwLCAy MDEyIDQ6MDMgQU08Yj48YnI+DQpUbzo8L2I+IEdyZWdvcnkgTWlyc2t5PGI+PGJyPg0KQ2M6PC9i PiBtcGxzQGlldGYub3JnOyBtcGxzLWJvdW5jZXNAaWV0Zi5vcmc8Yj48YnI+DQpTdWJqZWN0Ojwv Yj4gUmU6IFttcGxzXSBDb21tZW50cyBvbiBkcmFmdC13ZWluZ2FydGVuLW1wbHMtc21wLXJlcXVp cmVtZW50cy0wMC50eHQ8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4N Cjxicj4NCjxicj4NCkdyZWcsIHNuaXBwZWQ8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPiA8L2ZvbnQ+DQo8dWw+DQo8bGk+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0i QXJpYWwiPkluIHRoZSBsYXN0IHNlbnRlbmNlIG9mIFNlY3Rpb24NCjMuMSBub24tY29udHJvbCBw bGFuZSBjb29yZGluYXRpb24gb2Ygc2hhcmVkIHJlc291cmNlcyBwcmVzZW50ZWQgYXMgYW5vdGhl cg0KcmVxdWlyZW1lbnQuIEFuZCBhZ2FpbiBJIGNhbiBub3QgZmluZCBob3cgd2UgY29tZSB0byBz dWNoIGNvbmNsdXNpb24sIHdoZXJlDQp0aGUgc291cmNlIG9mIHRoaXMgcmVxdWlyZW1lbnQuIFdv dWxkIGV4aXN0aW5nIGNvbnRyb2wgcGxhbmUgc2lnbmFsaW5nDQpzb2x1dGlvbiBiZSBzdWZmaWNp ZW50IGZvciBhIE1QTFMgbmV0d29yaz8gPC9mb250PjwvdWw+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPjxicj4NCiZsdDtGZWkmZ3Q7IEkgZG8gbm90IHRoaW5rIHRoZSBleGlzdGluZyBj b250cm9sIHBsYW5lIChkZWZpbmVkIGluIFJGQzQ4NzIpDQppcyBzdWZmaWNpZW50IGZvciBhIE1Q TFMgbmV0d29yaywgYW5kIHRoZXJlIGlzIGFuIGFuYWx5c2lzIGluIHRoZSBkcmFmdA0KaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGUtY2NhbXAtbm90aWZpY2F0aW9uLXNoYXJlZC1t ZXNoLXByb3RlY3Rpb24tMDAuDQo8YnI+DQo8YnI+DQo8YnI+DQpCZXN0IHJlZ2FyZHM8L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCkZlaTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+IDxicj4NCjwvZm9udD4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQgd2lkdGg9MzklPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5HcmVn b3J5IE1pcnNreSAmbHQ7Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tJmd0OzwvYj4NCjxicj4N CreivP7IyzogJm5ic3A7bXBscy1ib3VuY2VzQGlldGYub3JnPC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj4yMDEyLTA4LTE2IDA2OjQ1PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij4NCjwvZm9udD4NCjx0ZCB3aWR0aD02MCU+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTclPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkIHdpZHRoPTkyJT48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UGFibG8gRnJhbmsgJmx0O3BhYmxvaXNub3RA Z21haWwuY29tJmd0OywNCllhYWNvdiBXZWluZ2FydGVuICZsdDt3eWFhY292QGdtYWlsLmNvbSZn dDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj4mcXVvdDttcGxzQGlldGYub3JnJnF1b3Q7ICZsdDttcGxzQGlldGYub3JnJmd0OzwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi Ptb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJl OiBbbXBsc10gQ29tbWVudHMgb24gZHJhZnQtd2VpbmdhcnRlbi1tcGxzLXNtcC1yZXF1aXJlbWVu dHMtMDAudHh0PC9mb250PjwvdGFibGU+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPjxicj4NCjxicj4NCjwvZm9udD4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQgd2lkdGg9NTAlPg0KPHRkIHdpZHRoPTUwJT48L3RhYmxlPg0KPGJyPjwv dGFibGU+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCjwv Zm9udD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PGJyPg0KPGJyPg0KPGJy Pg0KRGVhciBQYWJsbywgWWFhY292LCBldCBhbC4sPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48 YnI+DQpJJ3ZlIGJlZW4gZm9sbG93aW5nIGRpc2N1c3Npb24gd2l0aCBncmVhdCBkZWFsIG9mIGlu dGVyZXN0LiBJIGhhdmUgc29tZQ0KcXVlc3Rpb25zIGluIGFkZGl0aW9uIHRvIG9uZXMgYmVpbmcg YnJvdWdodCB1cCBieSBQYWJsbzo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi Pg0KPC9mb250Pg0KPHVsPg0KPGxpPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFs Ij5TZWN0aW9uIDEuMiByZWZlcnMgdG8gb3BlcmF0b3Incw0KZGVzaXJlIHRvIGhhdmUgc2Vydmlj ZSByZXN0b3JhdGlvbiBtb3JlIGV4cGVkaWVudCB0aGFuIG9uZSBhY2hpZXZhYmxlIHdpdGgNCmNv bnRyb2wgcGxhbmUuIEkgaGF2ZW4ndCBzZWVuIGFueSBxdWFudGF0aXZlIGluZm9ybWF0aW9uIHRv IGNvbXBhcmUgd2l0aC4NCldoYXQgaXMgJnF1b3Q7ZXhwZWRpZW50IGVub3VnaCZxdW90OyBmb3Ig U01QPzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8bGk+ PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPlNlY3Rpb24gMy4xIGRlc3JjaWJl cywgd2hhdCBjYW4NCmJlIGNhbGxlZCwgJnF1b3Q7aW5zdGFudCBkZXRlcm1pbmlzbSZxdW90OyBp biByZWdhcmQgdG8gU01QIHJlc291cmNlIGF2YWlhbGFiaWxpdHkuDQpJIHRoaW5rIHRoYXQgdGhl cmUncyBub3QgZW5vdWdoIHJlYXNvbmluZyB0byBjb25jbHVkZSB0aGF0IGFsbW9zdCBpbnN0YW50 ZW5lb3VzDQp1cGRhdGUgb2YgU01QIHJlc291cmNlcyBhdmFpYWxhYmlsaXR5IGlzIHJlcXVpcmVk LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8bGk+PGZv bnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPkluIHRoZSBsYXN0IHNlbnRlbmNlIG9m IFNlY3Rpb24NCjMuMSBub24tY29udHJvbCBwbGFuZSBjb29yZGluYXRpb24gb2Ygc2hhcmVkIHJl c291cmNlcyBwcmVzZW50ZWQgYXMgYW5vdGhlcg0KcmVxdWlyZW1lbnQuIEFuZCBhZ2FpbiBJIGNh biBub3QgZmluZCBob3cgd2UgY29tZSB0byBzdWNoIGNvbmNsdXNpb24sIHdoZXJlDQp0aGUgc291 cmNlIG9mIHRoaXMgcmVxdWlyZW1lbnQuIFdvdWxkIGV4aXN0aW5nIGNvbnRyb2wgcGxhbmUgc2ln bmFsaW5nDQpzb2x1dGlvbiBiZSBzdWZmaWNpZW50IGZvciBhIE1QTFMgbmV0d29yaz88L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPGxpPjxmb250IHNpemU9 MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj5JJ3ZlIG5vdGljZWQgdGhhdCBtYW55IHJlcXVpcmVt ZW50cw0KYmVpbmcgcmVmZXJyZWQgdG8gTVBMUy1UUCwgbm90IE1QTFMsIG5ldHdvcmtzLiBXb3Vs ZCB0aGF0IGJlIGEgZ29vZCByZWFzb24NCnRvIG5hcnJvdyBzY29wZSBvZiB0aGUgZG9jdW1lbnQg dG8gTVBMUy1UUCBuZXR3b3JrcyBvbmx5LCBzdGFydGluZyB3aXRoDQp0aGUgbmFtZSBvZiB0aGUg ZG9jdW1lbnQ/PC9mb250PjwvdWw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwi PiZuYnNwOw0KJm5ic3A7IFJlZ2FyZHMsPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj4gPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xv cj1ibHVlIGZhY2U9IkFyaWFsIj5HcmVnPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj4NCjxicj4NCjxicj4NCjwvZm9udD4NCjxocj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21h Ij48Yj5Gcm9tOjwvYj4gbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2Vz QGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5QYWJsbyBGcmFuazxiPjxicj4NClNlbnQ6 PC9iPiBGcmlkYXksIEF1Z3VzdCAxMCwgMjAxMiA3OjIzIEFNPGI+PGJyPg0KVG86PC9iPiBZYWFj b3YgV2VpbmdhcnRlbjxiPjxicj4NCkNjOjwvYj4gbXBsc0BpZXRmLm9yZzxiPjxicj4NClN1Ympl Y3Q6PC9iPiBSZTogW21wbHNdIENvbW1lbnRzIG9uIGRyYWZ0LXdlaW5nYXJ0ZW4tbXBscy1zbXAt cmVxdWlyZW1lbnRzLTAwLnR4dDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ PGJyPg0KPGJyPg0KSGkgWWFhY292LCA8YnI+DQo8YnI+DQpTb21lIG1vcmUgY29tbWVudHMgaW5s aW5lLi4uIFBGJmd0OyZndDs8YnI+DQo8YnI+DQpPbiBNb24sIEF1ZyA2LCAyMDEyIGF0IDg6NTYg QU0sIFlhYWNvdiBXZWluZ2FydGVuICZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86d3lhYWNvdkBn bWFpbC5jb20gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5z LXNlcmlmIj48dT53eWFhY292QGdtYWlsLmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4mZ3Q7DQp3cm90ZTogPGJyPg0KSGksIDxicj4NCjxicj4NClRoYW5r IHlvdSBmb3IgeW91ciBjb21tZW50cy4gJm5ic3A7UGxlYXNlIHNlZSBteSBjb21tZW50cyBpbmxp bmUgYmVsb3cuDQo8YnI+DQo8YnI+DQpCUiwgPGJyPg0KeWFhY292PGJyPg0KPGJyPg0KT24gVHVl LCBKdWwgMTcsIDIwMTIgYXQgMTE6NTEgUE0sIFBhYmxvIEZyYW5rICZsdDs8L2ZvbnQ+PGEgaHJl Zj1tYWlsdG86cGFibG9pc25vdEBnbWFpbC5jb20gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMg Y29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5wYWJsb2lzbm90QGdtYWlsLmNvbTwvdT48 L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7DQp3cm90ZTogPGJy Pg0KR29vZCBkcmFmdCBhbmQgY2VydGFpbmx5IHNvbWV0aGluZyB0aGF0IG5lZWRzIHRvIGJlIGRv bmUgYmVmb3JlIHdlIGNhbg0Kc3RhcnQgZGlzY3Vzc2luZyBzcGVjaWZpYyBzb2x1dGlvbnMuIDxi cj4NCjxicj4NCk9ubHkgYSBmZXcgY29tbWVudHMgLyBxdWVzdGlvbnM6IDxicj4NCjxicj4NCi0g SW4gNC4xLjEsIGlmIG9uZSBpcyBvcGVyYXRpbmcgaW4gYW4gTVBMUy1UUCBuZXR3b3JrIHRoYXQg cmVxdWlyZXMgZXhjbHVzaXZlDQp1c2Ugb2YgdGhlIHByb3RlY3Rpb24gcmVzb3VyY2VzLCBkb2Vz bid0IHRoaXMgU0hPVUxEIHJlcXVpcmVtZW50IGJlY29tZQ0KYSBNVVNUIHJlcXVpcmVtZW50PyA8 YnI+DQo8YnI+DQp5dyZndDsmZ3Q7IFNvcnJ5IC0gYnV0IGNvdWxkIHlvdSBleHBsYWluIG1vcmUg ZnVsbHkgdGhpcyBjb21tZW50LiA8YnI+DQo8YnI+DQpQRiZndDsmZ3Q7ICZuYnNwO0lmIHlvdSdy ZSB0cnlpbmcgdG8gbWVldCBSRkMgNTY1NCByZXEgNThiIGluIHBhcnRpY3VsYXIsDQpJIHdvdWxk IHRoaW5rIHlvdSBNVVNUIHZhbGlkYXRlIHRoYXQgZW5vdWdoIHByb3RlY3Rpb24gcmVzb3VyY2Vz IGFyZSBhdmFpbGFibGUNCihvciBhcmUgcHJlZW1wdGlibGUpIHRvIGNhcnJ5IDEwMCUgb2YgdGhl IHNlcnZpY2UgdHJhZmZpYyB0aGF0IGlzIGJlaW5nDQpyZXN0b3JlZC4gJm5ic3A7SW4gZXhpc3Rp bmcgdHJhbnNwb3J0IG5ldHdvcmtzIChpLmUuIE9UTiAvIHNvbmV0KSwgdGhpcw0KaXMgdHlwaWNh bGx5IGRvbmUgYmVmb3JlIHlvdSBzd2l0Y2ggdHJhZmZpYyB0byB0aGUgcHJvdGVjdGlvbiBwYXRo LiAmbmJzcDtGcm9tDQphIHNvbHV0aW9uIHBlcnNwZWN0aXZlLCBJIHRoaW5rIHlvdSdsbCBwcm9i YWJseSB3YW50IHRvIGxldmVyYWdlIHNvbWV0aGluZw0KbGlrZSB0aGUgbG9ja2luZyBtb2RlIHRo YXQgaXMgYmVpbmcgcHJvcG9zZWQgZm9yIHRoZSAxOm4gZHJhZnQuIDxicj4NCjxicj4NCi0gTml0 OiB5b3UgbWlnaHQgd2FudCB0byBhdm9pZCB1c2luZyB0aGUgJnF1b3Q7cXVlcnkmcXVvdDsgdmVy YiBpbiB0aGUNCnRpdGxlIG9mIDQuMS4xIGJlY2F1c2UgaXQgc3VidGx5IHN1Z2dlc3RzIHNvbWUg a2luZCBvZiBwcm90b2NvbCBtZXNzYWdpbmcNCmlzIHJlcXVpcmVkLiAmbmJzcDtJIHdvdWxkIHVz ZSB0aGUgbW9yZSBnZW5lcmljIHZlcmIgJnF1b3Q7Y2hlY2tpbmcmcXVvdDsNCm9yICZxdW90O3Zl cmlmeWluZyZxdW90Oy4gPGJyPg0KeXcmZ3Q7Jmd0OyBTb3VuZHMgT0sgdG8gbWUuIDxicj4NCi0g SW4gNC4zLCB0aGVyZSBpcyBubyBzdWdnZXN0aW9uIGZvciB3aGF0IHNob3VsZCBoYXBwZW4gaWYg b25lIG9yIG1vcmUNCmZhaWxpbmcgcGF0aHMgaW4gYW4gTVBMUy1UUCBuZXR3b3JrIGFyZSBvZiBl cXVhbCBwcmlvcml0eS4gJm5ic3A7SSBwcmVzdW1lDQppdCB3aWxsIGJlIHNvbWUga2luZCBvZiBm aXJzdC1jb21lLCBmaXJzdC1zZXJ2ZSByZXF1aXJlbWVudCBidXQgdGhpcyB3aWxsDQpicmluZyB1 cCB0aGUgcXVlc3Rpb24gb2YgaG93IHRvIGJyZWFrIHRpZXMuIDxicj4NCnl3Jmd0OyZndDsgVGhp cyBjb3VsZCBiZSByZXNvbHZlZCBhbG9uZyB0aGUgbGluZXMgdGhhdCBpdCB3YXMgYWRkcmVzc2Vk DQppbiB0aGUgMTpuIHByb3RlY3Rpb24gPGJyPg0KPGJyPg0KUEYmZ3Q7Jmd0OyBFeGNlcHQgdGhh dCB5b3UgZ3V5cyByZW1vdmVkIHNlcGFyYXRlIHBhdGggcHJpb3JpdHkgZnJvbSB0aGUNCmxhdGVz dCB2ZXJzaW9uIG9mIHRoZSAxOm4gZHJhZnQuICZuYnNwO0luIHRoZSBsYXRlc3QgdmVyc2lvbiwg ZWFjaCBwYXRoDQpoYXMgYSBzdHJpY3QgcHJpb3JpdHkgZGVmaW5lZCBieSBpdHMgcGF0aCBJRCBz byB0aWVzIHdlcmUgbm90IHBvc3NpYmxlLg0KJm5ic3A7SSBkb24ndCB0aGluayB0aGF0IHNvbHV0 aW9uIHdpbGwgd29yayBmb3IgU01QIGJlY2F1c2UgSSBoYXZlIGEgaGFyZA0KdGltZSBzZWVpbmcg aG93IGFsbCB0aGUgdmFyaW91cyBlbmRwb2ludHMgaW52b2x2ZWQgaW4gYSBzaGFyZWQgbWVzaCBj b3VsZA0KY29vcmRpbmF0ZSBub24tb3ZlcmxhcHBpbmcgcGF0aCBJRHMsIHdoaWxlIGF0IHRoZSBz YW1lIHRpbWUgbm90IGV4Y2VlZGluZw0KdGhlIGxpbWl0IG9mIDI1NSBwYXRoIElEcy4gPGJyPg0K PGJyPg0KPGJyPg0KLSBBbHNvIGluIDQuMywgdGhlcmUgaXMgYW4gYWxsb3dhbmNlIGZvciBhIGhp Z2ggcHJpb3JpdHkgcGF0aCBhbmQgYSBsb3dlcg0KcHJpb3JpdHkgcGF0aCB0byB0ZW1wb3Jhcmls eSBzaGFyZSB0aGUgcHJvdGVjdGlvbiByZXNvdXJjZXMgd2hpbGUgcHJlZW1wdGlvbg0KaXMgdGFr aW5nIHBsYWNlLiAmbmJzcDtUd28gcXVlc3Rpb25zOiA8YnI+DQotIElzIHRoZSBpbmdyZXNzIG5v ZGUgdG8gdGhlIHNoYXJlZCBzZWdtZW50IGV4cGVjdGVkIHRvIGRpc2NhcmQgZXhjZXNzDQp0cmFm ZmljIG5vdyB0aGF0IHRoZSBwcm90ZWN0aW9uLXBhdGggaXMgdGVtcG9yYXJpbHkgb3ZlcnN1YnNj cmliZWQ/IDxicj4NCnl3Jmd0OyZndDsgdGhpcyB3b3VsZCBtb3N0IHByb2JhYmx5IGZvbGxvdyBz dGFuZGFyZCBNUExTIGJlaGF2aW9yIGFzIGRlc2NyaWJlZA0KZWxzZXdoZXJlIDxicj4NCjxicj4N ClBGJmd0OyZndDsgSSBndWVzcyBJJ2xsIGFzayB3aGF0IGlzIHRoZSBzdGFuZGFyZCBiZWhhdmlv dXI/ICZuYnNwO0FuZCBpcw0KaXQgYXBwbGljYWJsZSB0byBNUExTLVRQIG5ldHdvcmtzPyA8YnI+ DQo8YnI+DQotIElmIG5vdCwgaG93IGRvIHdlIGVuc3VyZSB0aGF0IG90aGVyIHRyYW5zcG9ydCBw YXRocyBhcmUgdW5hZmZlY3RlZD8gPGJyPg0KLSBUaGUgZmlyc3QgcGFyYWdyYXBoIG9mIDQuNCBh cHBlYXJzIHRvIGNvbnRyYWRpY3QgNC4xLjEuICZuYnNwOzQuNCBzZWVtcw0KdG8gc3VnZ2VzdCB0 aGF0IG9uZSBNVVNUIHN3aXRjaCB0aGUgdHJhZmZpYyBvbnRvIHRoZSBwcm90ZWN0aW9uIHBhdGgg Zmlyc3QNCmFuZCB0aGVuIGdldCBub3RpZmllZCBpZiB0aGVyZSdzIG5vdCBlbm91Z2ggcmVzb3Vy Y2VzLiAmbmJzcDtUaGF0J3MgcHJvYmFibHkNCm9rYXkgaW4gdGhlIGdlbmVyYWwgY2FzZS4gJm5i c3A7QnV0IGluIGFuIE1QTFMtVFAgbmV0d29yaywgSSBkb24ndCB0aGluaw0KaXQncyBhIGdvb2Qg aWRlYSB0byBibGluZGx5IHN3aXRjaCBsb3cgcHJpb3JpdHkgdHJhZmZpYyBvbnRvIHRoZSBwcm90 ZWN0aW9uDQpwYXRoIGFuZCBwb3NzaWJseSBkaXNydXB0IGEgaGlnaCBwcmlvcml0eSBwYXRoIHRo YXQgaXMgYWxyZWFkeSB1c2luZyB0aGF0DQpyZXNvdXJjZS4gPGJyPg0KeXcmZ3Q7Jmd0OyBUaGlz IGlzIGRlcGVuZGVudCB1cG9uIHRoZSBhY3R1YWwgbWVjaGFuaXNtIHRoYXQgaXMgZGV2ZWxvcGVk DQpieSB0aGUgV0cuICZuYnNwO0ZvciBleGFtcGxlLCBvbmUgc3VnZ2VzdGlvbiBmb3IgdGhlIG1l Y2hhbmlzbSBoYXMgbm90aWZpY2F0aW9ucw0Kc2VudCB0byBsb3dlciBwcmlvcml0eSB3b3JraW5n IHBhdGhzIG1ha2luZyB0aGUgcHJvdGVjdGlvbiBwYXRoIHVuYXZhaWxhYmxlDQppZiBpdCBpcyBp biB1c2UgYnkgYSBoaWdoLXByaW9yaXR5IHdvcmtpbmcgcGF0aC4gPGJyPg0KPGJyPg0KLSBJbiBz ZWN0aW9uIDQuNSwgdGhlcmUncyBhbiBhdHRlbXB0IHRvIGRlZmluZSAmcXVvdDtwcm90ZWN0aW9u IHN3aXRjaGluZw0KdGltZSZxdW90OyBhcyBub3QgaW5jbHVkaW5nIHByZWVtcHRpb24gdGltZS4g Jm5ic3A7SSBkb24ndCB0aGluayBlbmQtdXNlcnMNCnJlYWxseSBjYXJlIGFib3V0ICZxdW90O3By b3RlY3Rpb24gc3dpdGNoaW5nIHRpbWUmcXVvdDsuICZuYnNwO1RoZXkgY2FyZQ0KYWJvdXQgcmVj b3ZlcnkgdGltZSBhbmQgSU1PLCB0aGF0IHNob3VsZCBhbHNvIGluY2x1ZGUgZmF1bHQgZGV0ZWN0 aW9uIHRpbWUNCihhbHRob3VnaCBpdCBkb2Vzbid0IHBlciBSRkMgNTY1NCkgYW5kIGFueSBwcmVl bXB0aW9uIHRpbWUuIDxicj4NCnl3Jmd0OyZndDsgd2UgZG8gdHJ5IHRvIHdvcmsgd2l0aGluIHRo ZSBhY2NlcHRlZCBkZWZpbml0aW9ucyBvZiB0aGUgSUVURiENCjxicj4NCjxicj4NClBGJmd0OyZn dDsgSSBndWVzcyB0aGVyZSdzIHR3byBzZXBhcmF0ZSBjb21tZW50cyBoZXJlIHRoYXQgSSBraW5k YSBjb25mbGF0ZWQNCnRvZ2V0aGVyLiAmbmJzcDtPbmUgd2FzIG1vcmUgb2YgYSBncmlwZTogd2h5 IGRpZCB3ZSBleGNsdWRlIGZhdWx0IGRldGVjdGlvbg0KdGltZSBmcm9tIHRoZSA1MG1zIHJlc3Rv cmF0aW9uIHRpbWUgcmVxdWlyZW1lbnQgaW4gUkZDIDU2NTQ/ICZuYnNwO0kga25vdw0KdGhhdCBt eSBjdXN0b21lcnMgbWVhc3VyZSBvbmx5IG9uZSB0aGluZzogaG93IG1hbnkgbXMgb2YgdHJhZmZp YyBkbyB0aGV5DQpsb3NlIGFmdGVyIGEgYnJlYWthZ2UuICZuYnNwO0kgZG9uJ3QgZ2V0IGEgZnJl ZSBwYXNzIG9uIHRoZSB+MTBtcyBpdCB0YWtlcw0KZm9yIEJGRCB0byBkZXRlY3QgdGhlIGZhaWx1 cmUuICZuYnNwO0FjY29yZGluZyB0byBSRkMgNTY1NCwgSSBjb3VsZCB1c2UNCjYwc2VjIENDTXMg YW5kIHN0aWxsIG1lZXQgdGhlIDUwbXMgcmVxdWlyZW1lbnQhIDxicj4NCjxicj4NClRoZSAybmQg Y29tbWVudCB3YXMgcmVhbGx5IGFib3V0IHRoaXMgZHJhZnQgbm93IHRyeWluZyB0byBleGNsdWRl IHByZWVtcHRpb24NCnRpbWUgZnJvbSByZXN0b3JhdGlvbiB0aW1lIGFzIHdlbGwuICZuYnNwO0lN TywgaWYgaXQgdGFrZXMgYSBmZXcgc2Vjb25kcw0KZm9yIGEgaGlnaCBwcmlvcml0eSBzZXJ2aWNl IHRvIGZpbmlzaCBwcmVlbXB0aW5nIGEgbG93ZXIgcHJpb3JpdHkgc2VydmljZSwNCnRoZW4gd2Ug aGF2ZW4ndCBtZXQgdGhlIDUwbXMgcmVzdG9yYXRpb24gdGltZSByZXF1aXJlbWVudC4gJm5ic3A7 RXNwZWNpYWxseQ0Kc2luY2UgaXQncyB0eXBpY2FsbHkgbXkgaGlnaGVyIHByaW9yaXR5IHNlcnZp Y2VzIHRoYXQgd2FudCA1MG1zIHJlc3RvcmF0aW9uDQp0aW1lcyBpbiB0aGUgZmlyc3QgcGxhY2Us IHNvIHRoZXknbGwgYmUgbW9yZSBvZnRlbiBpbiBhIHBvc2l0aW9uIHRvIHByZWVtcHQuDQombmJz cDtJbiBvdGhlciB3b3JkcywgSSB0aGluayB3ZSB3YW50IHByZWVtcHRpb24gdG8gYmUgZmFzdCBh bmQgaXMgYSBjcml0aWNhbA0KY29tcG9uZW50IG9mIHByb3RlY3Rpb24gc3dpdGNoaW5nLiAmbmJz cDsgPGJyPg0KPGJyPg0KPGJyPg0KcmVnYXJkcywgPGJyPg0KUGFibG8gPGJyPg0KPGJyPg0KPGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpt cGxzIG1haWxpbmcgbGlzdDwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5z LXNlcmlmIj48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9bWFpbHRvOm1wbHNAaWV0Zi5vcmcg dGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48 dT5tcGxzQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFj ZT0ic2Fucy1zZXJpZiI+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPWh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBj b2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbXBsczwvdT48L2ZvbnQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KPGJy Pg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQptcGxzIG1haWxpbmcgbGlzdDxicj4NCm1wbHNAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8L2ZvbnQ+PC90dD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pg0KPGJyPg0K --=_alternative 00256D6E48257A68_=-- From ietf-ipr@ietf.org Tue Aug 28 12:29: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 A20AD11E80F8; Tue, 28 Aug 2012 12:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 IkZK5quQb00a; Tue, 28 Aug 2012 12:29:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E38221F85A0; Tue, 28 Aug 2012 12:29:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: wu.bo@zte.com.cn, daniele.ceccarelli@ericsson.com, diego.caviglia@ericsson.com, francesco.fondelli@ericsson.com, nurit.sprecher@nsn.com, stbryant@cisco.com, dai.xuehui@zte.com.cn, wyaacov@gmail.com, corsi.marco@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120828192952.16911.31018.idtracker@ietfa.amsl.com> Date: Tue, 28 Aug 2012 12:29:52 -0700 Cc: mpls@ietf.org, rcallon@juniper.net, ipr-announce@ietf.org Subject: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-mpls-tp-ring-protection-02 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, 28 Aug 2012 19:29:52 -0000 Dear Wu Bo, Daniele Ceccarelli, Diego Caviglia, Francesco Fondelli, Nurit S= precher, Stewart Bryant, Xuehui Dai, Yaacov Weingarten, Marco Corsi: An IPR disclosure that pertains to your Internet-Draft entitled "Applicabi= lity of MPLS-TP Linear Protection for Ring Topologies" (draft-ietf-mpls-tp-ring- protection) was submitted to the IETF Secretariat on 2012-08-25 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1872/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-mp= ls- tp-ring-protection-02.""); The IETF Secretariat From internet-drafts@ietf.org Wed Aug 29 07:47: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 CCE5C11E80E2; Wed, 29 Aug 2012 07:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.068, 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 6Z0FD-Ct8R1G; Wed, 29 Aug 2012 07:47:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3318F11E80CC; Wed, 29 Aug 2012 07:47:02 -0700 (PDT) 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.34 Message-ID: <20120829144702.17565.56511.idtracker@ietfa.amsl.com> Date: Wed, 29 Aug 2012 07:47:02 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-itu-t-identifiers-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: Wed, 29 Aug 2012 14:47:03 -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 Identifiers Following ITU-T Conventions Author(s) : Rolf Winter Eric Gray Huub van Helvoort Malcolm Betts Filename : draft-ietf-mpls-tp-itu-t-identifiers-04.txt Pages : 12 Date : 2012-08-29 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-itu-t-identifiers There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-itu-t-identifiers-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-itu-t-identifiers-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lizhenbin@huawei.com Thu Aug 30 01:41: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 1B9FB21F84B9 for ; Thu, 30 Aug 2012 01:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.788 X-Spam-Level: ** X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 bjHbFYcHNLiZ for ; Thu, 30 Aug 2012 01:41:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CDA1E21F84A5 for ; Thu, 30 Aug 2012 01:41:28 -0700 (PDT) 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 AKE04621; Thu, 30 Aug 2012 08:41:28 +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; Thu, 30 Aug 2012 09:40:56 +0100 Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 30 Aug 2012 09:41:26 +0100 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.168]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.01.0323.003; Thu, 30 Aug 2012 16:41:22 +0800 From: Lizhenbin To: Loa Andersson , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , Martin Vigoureux , "draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org" Thread-Topic: [mpls] implemetations of draft-ietf-mpls-return-path-specified-lsp-ping ?? Thread-Index: AQHNhDGyE+24pYPWjEWIFfFJ5oH9HpdyC2SQ Date: Thu, 30 Aug 2012 08:41:21 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D07799315@szxeml525-mbx.china.huawei.com> References: <503B354E.3080401@pi.nu> In-Reply-To: <503B354E.3080401@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.75] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [mpls] =?gb2312?b?tPC4tDogIGltcGxlbWV0YXRpb25zIG9mIGRyYWZ0LWll?= =?gb2312?b?dGYtbXBscy1yZXR1cm4tcGF0aC1zcGVjaWZpZWQtbHNwLXBpbmcgPz8=?= 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, 30 Aug 2012 08:41:30 -0000 SGkgTG9hLA0KV2UgYXJlIGJvdGhlcmVkIHdpdGggdGhlIHJldHVybiBwYXRoIGlzc3VlIHByb3Bv c2VkIGJ5IHRoZSBleGlzdGluZyBCRkQtZm9yLUxTUC4gSXQgd2lsbCBjYXVzZSB0aGUgd3Jvbmcg dHJhZmZpYyBzd2l0Y2ggaXNzdWUgaWYgZmFpbHVyZSBoYXBwZW5zIGluIHRoZSByZXR1cm4gcGF0 aC4gV2Ugd2lsbCBwYW4gdG8gaW1wbGVtZW50IHRoZSBMU1AgcGluZyBleHRlbnNpb24gcHJvcG9z ZWQgYnkgdGhlIGRyYWZ0IHRvIHVzZSBpdCBmb3IgQkZELWZvci1MU1AuDQoNClRoYW5rcywNClpo ZW5iaW4NCg0KDQoNCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IG1wbHMtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBMb2EgQW5kZXJzc29u DQq3osvNyrG85DogMjAxMsTqONTCMjfI1SAxNjo1Mw0KytW8/sjLOiBtcGxzQGlldGYub3JnOyBt cGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgTWFydGluIFZpZ291cmV1eDsgZHJhZnQtaWV0Zi1t cGxzLXJldHVybi1wYXRoLXNwZWNpZmllZC1sc3AtcGluZ0B0b29scy5pZXRmLm9yZw0K1vfM4jog W21wbHNdIGltcGxlbWV0YXRpb25zIG9mIGRyYWZ0LWlldGYtbXBscy1yZXR1cm4tcGF0aC1zcGVj aWZpZWQtbHNwLXBpbmcgPz8NCg0KV29ya2luZyBHcm91cCwNCg0Kd2UgYXJlIGdldHRpbmcgY2xv c2VyIHRvIHNlbmQgYSBwdWJsaWNhdGlvbiByZXF1ZXN0IGZvcg0KZHJhZnQtaWV0Zi1tcGxzLXJl dHVybi1wYXRoLXNwZWNpZmllZC1sc3AtcGluZy4gYmVmb3JlIHdlIGRvDQpzbyB3ZSBuZWVkIHRv IGtub3cgYWJvdXQgcGxhbnMgdG8gaW1wbGVtZW50IG9yIGV4aXN0aW5nDQppbXBsZW1lbnRhdGlv bnMuDQoNCklmIHlvdSBwbGFuIHRvIGltcGxlbWVudCBvciBoYXZlIGFuIGltcGxlbWVudGF0aW9u IG9mDQpkcmFmdC1pZXRmLW1wbHMtcmV0dXJuLXBhdGgtc3BlY2lmaWVkLWxzcC1waW5nIHBsZWFz ZSBsZXQNCnRoZSB3b3JraW5nIGdyb3VwIGNoYWlycyBrbm93Lg0KDQovTG9hDQpmb3IgdGhlIHdn IGNvLWNoYWlycw0KLS0gDQoNCg0KTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAg ICBlbWFpbDogbG9hLmFuZGVyc3NvbkBlcmljc3Nvbi5jb20NClNyIFN0cmF0ZWd5IGFuZCBTdGFu ZGFyZHMgTWFuYWdlciAgICAgICAgICAgIGxvYUBwaS5udQ0KRXJpY3Nzb24gSW5jICAgICAgICAg ICAgICAgICAgICAgICAgICBwaG9uZTogKzQ2IDEwIDcxNyA1MiAxMw0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICs0NiA3NjcgNzIgOTIgMTMNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlz dA0KbXBsc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t cGxzDQo= From lizhong.jin@zte.com.cn Thu Aug 30 08:07: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 7A6AF21F8618 for ; Thu, 30 Aug 2012 08:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.978 X-Spam-Level: X-Spam-Status: No, score=-100.978 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 JD66Mi5zd135 for ; Thu, 30 Aug 2012 08:07:15 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 5112821F8617 for ; Thu, 30 Aug 2012 08:07:15 -0700 (PDT) Received: from [192.168.168.119] by mx5.zte.com.cn with surfront esmtp id 10723806486374; Thu, 30 Aug 2012 22:50:43 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id B108D17BA376; Thu, 30 Aug 2012 23:02:58 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q7UF72hv057847; Thu, 30 Aug 2012 23:07:02 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: <503DDC69.606@pi.nu> To: draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Thu, 30 Aug 2012 23:06:13 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-30 23:06:59, Serialize complete at 2012-08-30 23:06:59 Content-Type: multipart/alternative; boundary="=_alternative 00530A2F48257A6A_=" X-MAIL: mse02.zte.com.cn q7UF72hv057847 Cc: mpls@ietf.org, "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org 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, 30 Aug 2012 15:07:16 -0000 This is a multipart message in MIME format. --=_alternative 00530A2F48257A6A_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgQXV0aG9ycywNCkkgcmV2aWV3IHRoaXMgZHJhZnQsIGFuZCBoYXZlIGZvbGxvd2luZyBxdWVz dGlvbnM6DQoxLiBGYXRlIHNlcGFyYXRpb24gaXMgbm90IGVhc3kgYnkgdXNpbmcgbXVsdGlwbGUg aW5zdGFuY2UsIHlvdSBzdGlsbCBzaGFyZSANCnNhbWUgQ1BVLCBtZW1vcnksIG9yIGV2ZW4gc2Ft ZSBwaHlzaWNhbCBpbnRlcmZhY2UuIEFueXdheSwgdGhpcyBpcyBub3QgYSANCnF1ZXN0aW9uLg0K Mi4gRm9yIExEUCBtdWx0aXBsZSBpbnN0YW5jZSwgaXMgaXQgYWxsb3dlZCBmb3IgZHVwbGljYXRl ZCBGRUMgYmV0d2VlbiB0d28gDQppbnN0YW5jZT8NCjMuIElmIGR1cGxpY2F0ZWQgRkVDcyBhcmUg cG9zc2libGUgYmV0d2VlbiB0d28gaW5zdGFuY2UsIHJlY2VpdmluZyBzYW1lIA0KbGFiZWwgbWFw cGluZyBmcm9tIHBhcmFsbGVsIG11bHRpLWxzciBwZWVyaW5nIHNlc3Npb25zIGNvdWxkIG5vdCBp bnRlcnByZXQgDQphcyBsb29wLCByaWdodD8NCjQuIEluIGNhc2UgMX40LCBvbmUgaW50ZXJmYWNl IHdpbGwgc2VydmUgbXVsdGlwbGUgaW5zdGFuY2UsIEkgZ3Vlc3MsIHRoZSANCmludGVyZmFjZSB5 b3UgcmVmZXIgaXMgcGh5c2ljYWwgaW50ZXJmYWNlLCBhbmQgd2hlbiBzaGFyaW5nIG9uZSBwaHlz aWNhbCANCmludGVyZmFjZSwgdGhlbiBvbmUgc3ViLWludGVyZmFjZSBmb3IgZWFjaCBpbnN0YW5j ZSBpcyBzdGlsbCByZXF1aXJlZCwgDQpyaWdodD8gSW4gbXkgdW5kZXJzdGFuZGluZywgb25lIElQ IGludGVyZmFjZSBjb3VsZCBub3QgYmUgc2hhcmVkIGJ5IA0KbXVsdGlwbGUgTERQIGluc3RhbmNl LCBvdGhlcndpc2UgaG93IHRvIHRyZWF0IHRoZSBwcmVmaXggb2YgdGhhdCANCmludGVyZmFjZS4N Cg0KSG9wZSB0byBzZWUgeW91ciBjbGFyaWZpY2F0aW9uLiBUaGFua3MuDQoNCkxpemhvbmcNCiAN Cg0KTG9hIEFuZGVyc3NvbiA8bG9hQHBpLm51PiB3cm90ZSAyMDEyLzA4LzI5IDE3OjEwOjAxOg0K DQo+IEthbXJhbi4gRXJpYyBhbmQgTGl6aG9uZywNCj4gDQo+IFlvdSBoYXZlIGJlZW4gc2VsZWN0 ZWQgYXMgYW4gTVBMUyBSZXZpZXcgdGVhbSByZXZpZXdlcnMgZm9yDQo+IGRyYWZ0LXBkdXR0YS1t cGxzLW11bHRpLWxkcC1pbnN0YW5jZS0wMC50eHQuDQo+IA0KPiBOb3RlIHRvIGF1dGhvcnM6IFlv dSBoYXZlIGJlZW4gQ0Ohr2Qgb24gdGhpcyBlbWFpbCBzbyB0aGF0IHlvdSBjYW4ga25vdw0KPiB0 aGF0IHRoaXMgcmV2aWV3IGlzIGdvaW5nIG9uLiBIb3dldmVyLCBwbGVhc2UgZG8gbm90IHJldmll dyB5b3VyIG93bg0KPiBkb2N1bWVudC4NCj4gDQo+IFJldmlld3Mgc2hvdWxkIGNvbW1lbnQgb24g d2hldGhlciB0aGUgZG9jdW1lbnQgaXMgY29oZXJlbnQsIGlzIGl0IHVzZWZ1bA0KPiAoaWUsIGlz IGl0IGxpa2VseSB0byBiZSBhY3R1YWxseSB1c2VmdWwgaW4gb3BlcmF0aW9uYWwgbmV0d29ya3Mp LCBhbmQgaXMNCj4gdGhlIGRvY3VtZW50IHRlY2huaWNhbGx5IHNvdW5kPyAgV2UgYXJlIGludGVy ZXN0ZWQgaW4ga25vd2luZyB3aGV0aGVyDQo+IHRoZSBkb2N1bWVudCBpcyByZWFkeSB0byBiZSBj b25zaWRlcmVkIGZvciBXRyBhZG9wdGlvbiAoaWUsIGl0IGRvZXNuoa90DQo+IGhhdmUgdG8gYmUg cGVyZmVjdCBhdCB0aGlzIHBvaW50LCBidXQgc2hvdWxkIGJlIGEgZ29vZCBzdGFydCkuDQo+IA0K PiBSZXZpZXdzIHNob3VsZCBiZSBzZW50IHRvIHRoZSBkb2N1bWVudCBhdXRob3JzLCBXRyBjby1j aGFpcnMgYW5kDQo+IHNlY3JldGFyeSwgYW5kIENDoa9kIHRvIHRoZSBNUExTIFdHIGVtYWlsIGxp c3QuIElmIG5lY2Vzc2FyeSwgY29tbWVudHMNCj4gbWF5IGJlIHNlbnQgcHJpdmF0ZWx5IHRvIG9u bHkgdGhlIFdHIGNoYWlycy4NCj4gDQo+IEFyZSB5b3UgYWJsZSB0byByZXZpZXcgdGhpcyBkcmFm dCBieSBTZXAgMTMsIDIwMTI/DQo+IA0KPiBUaGFua3MsIExvYQ0KPiAoYXMgTVBMUyBXRyBjaGFp cikNCj4gLS0gDQo+IA0KPiANCj4gTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAg ICBlbWFpbDogbG9hLmFuZGVyc3NvbkBlcmljc3Nvbi5jb20NCj4gU3IgU3RyYXRlZ3kgYW5kIFN0 YW5kYXJkcyBNYW5hZ2VyICAgICAgICAgICAgbG9hQHBpLm51DQo+IEVyaWNzc29uIEluYyAgICAg ICAgICAgICAgICAgICAgICAgICAgcGhvbmU6ICs0NiAxMCA3MTcgNTIgMTMNCj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICs0NiA3NjcgNzIgOTIgMTMNCj4g DQoNCg== --=_alternative 00530A2F48257A6A_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEF1dGhvcnMsPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIHJldmlldyB0aGlzIGRyYWZ0LCBh bmQgaGF2ZSBmb2xsb3dpbmcNCnF1ZXN0aW9uczo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPjEuIEZhdGUgc2VwYXJhdGlvbiBpcyBub3QgZWFzeSBieSB1c2luZw0K bXVsdGlwbGUgaW5zdGFuY2UsIHlvdSBzdGlsbCBzaGFyZSBzYW1lIENQVSwgbWVtb3J5LCBvciBl dmVuIHNhbWUgcGh5c2ljYWwNCmludGVyZmFjZS4gQW55d2F5LCB0aGlzIGlzIG5vdCBhIHF1ZXN0 aW9uLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Mi4gRm9yIExE UCBtdWx0aXBsZSBpbnN0YW5jZSwgaXMgaXQNCmFsbG93ZWQgZm9yIGR1cGxpY2F0ZWQgRkVDIGJl dHdlZW4gdHdvIGluc3RhbmNlPzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+My4gSWYgZHVwbGljYXRlZCBGRUNzIGFyZSBwb3NzaWJsZSBiZXR3ZWVuDQp0d28gaW5z dGFuY2UsIHJlY2VpdmluZyBzYW1lIGxhYmVsIG1hcHBpbmcgZnJvbSBwYXJhbGxlbCBtdWx0aS1s c3IgcGVlcmluZw0Kc2Vzc2lvbnMgY291bGQgbm90IGludGVycHJldCBhcyBsb29wLCByaWdodD88 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjQuIEluIGNhc2UgMX40 LCBvbmUgaW50ZXJmYWNlIHdpbGwgc2VydmUNCm11bHRpcGxlIGluc3RhbmNlLCBJIGd1ZXNzLCB0 aGUgaW50ZXJmYWNlIHlvdSByZWZlciBpcyBwaHlzaWNhbCBpbnRlcmZhY2UsDQphbmQgd2hlbiBz aGFyaW5nIG9uZSBwaHlzaWNhbCBpbnRlcmZhY2UsIHRoZW4gb25lIHN1Yi1pbnRlcmZhY2UgZm9y IGVhY2gNCmluc3RhbmNlIGlzIHN0aWxsIHJlcXVpcmVkLCByaWdodD8gSW4gbXkgdW5kZXJzdGFu ZGluZywgb25lIElQIGludGVyZmFjZQ0KY291bGQgbm90IGJlIHNoYXJlZCBieSBtdWx0aXBsZSBM RFAgaW5zdGFuY2UsIG90aGVyd2lzZSBob3cgdG8gdHJlYXQgdGhlDQpwcmVmaXggb2YgdGhhdCBp bnRlcmZhY2UuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5Ib3BlIHRvIHNlZSB5b3VyIGNsYXJpZmljYXRpb24uIFRoYW5rcy48L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkxpemhvbmc8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+TG9hIEFuZGVyc3NvbiAmbHQ7bG9hQHBpLm51Jmd0 OyB3cm90ZQ0KMjAxMi8wOC8yOSAxNzoxMDowMTo8YnI+DQo8YnI+DQomZ3Q7IEthbXJhbi4gRXJp YyBhbmQgTGl6aG9uZyw8YnI+DQomZ3Q7IDxicj4NCiZndDsgWW91IGhhdmUgYmVlbiBzZWxlY3Rl ZCBhcyBhbiBNUExTIFJldmlldyB0ZWFtIHJldmlld2VycyBmb3I8YnI+DQomZ3Q7IGRyYWZ0LXBk dXR0YS1tcGxzLW11bHRpLWxkcC1pbnN0YW5jZS0wMC50eHQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IE5vdGUgdG8gYXV0aG9yczogWW91IGhhdmUgYmVlbiBDQ6GvZCBvbiB0aGlzIGVtYWlsIHNvIHRo YXQgeW91IGNhbg0Ka25vdzxicj4NCiZndDsgdGhhdCB0aGlzIHJldmlldyBpcyBnb2luZyBvbi4g SG93ZXZlciwgcGxlYXNlIGRvIG5vdCByZXZpZXcgeW91ciBvd248YnI+DQomZ3Q7IGRvY3VtZW50 Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBSZXZpZXdzIHNob3VsZCBjb21tZW50IG9uIHdoZXRoZXIg dGhlIGRvY3VtZW50IGlzIGNvaGVyZW50LCBpcyBpdA0KdXNlZnVsPGJyPg0KJmd0OyAoaWUsIGlz IGl0IGxpa2VseSB0byBiZSBhY3R1YWxseSB1c2VmdWwgaW4gb3BlcmF0aW9uYWwgbmV0d29ya3Mp LA0KYW5kIGlzPGJyPg0KJmd0OyB0aGUgZG9jdW1lbnQgdGVjaG5pY2FsbHkgc291bmQ/ICZuYnNw O1dlIGFyZSBpbnRlcmVzdGVkIGluIGtub3dpbmcNCndoZXRoZXI8YnI+DQomZ3Q7IHRoZSBkb2N1 bWVudCBpcyByZWFkeSB0byBiZSBjb25zaWRlcmVkIGZvciBXRyBhZG9wdGlvbiAoaWUsIGl0IGRv ZXNuoa90PGJyPg0KJmd0OyBoYXZlIHRvIGJlIHBlcmZlY3QgYXQgdGhpcyBwb2ludCwgYnV0IHNo b3VsZCBiZSBhIGdvb2Qgc3RhcnQpLjxicj4NCiZndDsgPGJyPg0KJmd0OyBSZXZpZXdzIHNob3Vs ZCBiZSBzZW50IHRvIHRoZSBkb2N1bWVudCBhdXRob3JzLCBXRyBjby1jaGFpcnMgYW5kPGJyPg0K Jmd0OyBzZWNyZXRhcnksIGFuZCBDQ6GvZCB0byB0aGUgTVBMUyBXRyBlbWFpbCBsaXN0LiBJZiBu ZWNlc3NhcnksIGNvbW1lbnRzPGJyPg0KJmd0OyBtYXkgYmUgc2VudCBwcml2YXRlbHkgdG8gb25s eSB0aGUgV0cgY2hhaXJzLjxicj4NCiZndDsgPGJyPg0KJmd0OyBBcmUgeW91IGFibGUgdG8gcmV2 aWV3IHRoaXMgZHJhZnQgYnkgU2VwIDEzLCAyMDEyPzxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGFu a3MsIExvYTxicj4NCiZndDsgKGFzIE1QTFMgV0cgY2hhaXIpPGJyPg0KJmd0OyAtLSA8YnI+DQom Z3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBMb2EgQW5kZXJzc29uICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBlbWFpbDogbG9hLmFuZGVyc3NvbkBlcmljc3Nvbi5jb208YnI+DQomZ3Q7IFNy IFN0cmF0ZWd5IGFuZCBTdGFuZGFyZHMgTWFuYWdlciAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7DQombmJzcDtsb2FAcGkubnU8YnI+DQomZ3Q7IEVyaWNzc29uIEluYyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGhvbmU6ICs0NiAxMCA3MTcgNTIgMTM8YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyArNDYg NzY3IDcyIDkyIDEzPGJyPg0KJmd0OyA8YnI+DQo8L2ZvbnQ+DQo= --=_alternative 00530A2F48257A6A_=-- From pranjal.dutta@alcatel-lucent.com Thu Aug 30 10:01: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 798C621F8575 for ; Thu, 30 Aug 2012 10:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.429 X-Spam-Level: X-Spam-Status: No, score=-7.429 tagged_above=-999 required=5 tests=[AWL=-0.831, 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 Nxrk3WGNfeSp for ; Thu, 30 Aug 2012 10:01:10 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1E38821F855E for ; Thu, 30 Aug 2012 10:01:04 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q7UH0v1N013039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Aug 2012 12:01:00 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7UH0tfn013411 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 30 Aug 2012 22:30:56 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Thu, 30 Aug 2012 22:30:55 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Lizhong Jin , "draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org" Date: Thu, 30 Aug 2012 22:30:53 +0530 Thread-Topic: [mpls] MPLS-RT review of draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org Thread-Index: Ac2GwSqNC8xUPu8iSAewgkE02hACXQACkDIA Message-ID: References: <503DDC69.606@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C584046466ED224CA92C1BC3313B963E13F0B8C864INBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org 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, 30 Aug 2012 17:01:13 -0000 --_000_C584046466ED224CA92C1BC3313B963E13F0B8C864INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lizhong, Thanks for your review. Pls refer my answers inline. Thanks, Pranjal ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Liz= hong Jin Sent: Thursday, August 30, 2012 8:06 AM To: draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org Subject: Re: [mpls] MPLS-RT review of draft-pdutta-mpls-multi-ldp-instance@= tools.ietf.org Hi Authors, I review this draft, and have following questions: 1. Fate separation is not easy by using multiple instance, you still share = same CPU, memory, or even same physical interface. Anyway, this is not a qu= estion. [Pranjal] Fate separation has different contexts such as - TCP channel sepa= ration, avoid head of line blocking between families sharing same TCP channel (e.g intensive PW status signaling blocking other transport tun= nel events such as mLdp MBB failover etc) or fate separation of physical/computational resources. Within a single chassis/system there are = techniques to separate fate separation of computational resources to a "certain extent". However the least common denominator for control pla= ne fate separation is separation of TCP sessions, which the draft addresses. It is also possible that loopbacks used for each || TCP session = are fate separated by IGP multi-topology/Routing policies etc. 2. For LDP multiple instance, is it allowed for duplicated FEC between two = instance? [Pranjal] Duplicated FECs won't be allowed. The parallel sessions between t= wo peering systems needs to be disjoint with respect to the working set - the FECs. This needs to be ensured thru various FEC specific session capa= bilities. Each || session must advertise disjoint FEC capabilities. Section 2.1.1 explains the use of LDP session capabilities (RFC5561) to keep the FE= C distribution mutually exclusive. What criteria to be used for segregation of FECs are to be decided on case to case basic. This draft provides the fu= ndamental building block for control plane fate separation. 3. If duplicated FECs are possible between two instance, receiving same lab= el mapping from parallel multi-lsr peering sessions could not interpret as = loop, right? [Pranjal] Duplicated FECs are not allowed across . But what if a peering sy= stem misbehaves or peering system not supporting the solution (thus agnosti= c Of the fact that a few sessions are terminated in same peering system) leak= s FECs on all || sessions? That may result in a loop for some applications and "Section 3. Detection of multi-instance peering" addresses that issue. = It lets a system aware of || sessions and thus can take necessary actions. 4. In case 1~4, one interface will serve multiple instance, I guess, the in= terface you refer is physical interface, and when sharing one physical inte= rface, then one sub-interface for each instance is still required, right? I= n my understanding, one IP interface could not be shared by multiple LDP in= stance, otherwise how to treat the prefix of that interface. [Pranjal] I won't view it as sub-interface since all instances are running = in same FEC database. So if we think from a "virtual router" point of view = (each Virtual Router is separated across all verticals in RIB/LFIB/FIB and self-s= ufficient) then all the multiple LSR instances would be running within same Virtual Router and thus can share interfaces assigned to that Virtual Route= r. Although the draft does not prevent usage of same Interface across all L= SRs in practice it is desirable to fate separate the physical topology to achie= ve separation across entire vertical. Separation of physical topology can b= e achieved by LDP Multi-topology that synchronizes IGP and LDP's view (http:/= /tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-04) or by using hel= lo adjacency capabilities at LDP level (http://tools.ietf.org/html/draft-pdutt= a-mpls-ldp-adj-capability-00). Hope to see your clarification. Thanks. Lizhong Loa Andersson wrote 2012/08/29 17:10:01: > Kamran. Eric and Lizhong, > > You have been selected as an MPLS Review team reviewers for > draft-pdutta-mpls-multi-ldp-instance-00.txt. > > 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 Sep 13, 2012? > > Thanks, Loa > (as MPLS WG 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 > --_000_C584046466ED224CA92C1BC3313B963E13F0B8C864INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Lizhong,

      &n= bsp;           Thanks for your review. Pls refer my answers inline.

 

Thanks,

Pranjal

 

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Lizhong Jin
Sent: Thursday, August 30, 2= 012 8:06 AM
To: draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org
Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org
Subject: Re: [mpls] MPLS-RT = review of draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org

 


Hi Authors,
I review this draft, and have following questions:
1. Fate separation is not easy by using multiple instance, you still share sam= e CPU, memory, or even same physical interface. Anyway, this is not a questio= n.

 

[Pranjal] Fate separation has differen= t contexts such as – TCP channel separation, avoid head of line blockin= g between families sharing same

TCP channel (e.g intensive PW status signaling blocking other transport tunnel events such as mLdp MBB failover = etc) or fate separation of

physical/computational resources. With= in a single chassis/system there are techniques to separate fate separation of computational resources

to a “certain extent”. How= ever the least common denominator for control plane fate separation is separatio= n of TCP sessions, which the draft
addresses. It is also possible that loopbacks used for each || TCP session = are fate separated by IGP multi-topology/Routing policies etc.


2. For LDP multiple instance, is it allowed for duplicated FEC between two instance?

 

[Pranjal] Duplicated FECs won’t = be allowed. The parallel sessions between two peering systems needs to be disj= oint with respect to the working set
– the FECs. This needs to be ensured thru various FEC specific sessio= n capabilities. Each || session must advertise disjoint FEC capabilities. Sec= tion

2.1.1 explains the use of LDP session capabilities (RFC5561) to keep the FEC distribution mutually exclusive. Wha= t criteria to be used for segregation

of FECs are to be decided on case to c= ase basic. This draft provides the fundamental building block for control plane fate separation.


3. If duplicated FECs are possible between two instance, receiving same label mapping from parallel multi-lsr peering sess= ions could not interpret as loop, right?

 

[Pranjal] Duplicated FECs are not allo= wed across . But what if a peering system misbehaves or peering system not supporting the solution (thus agnostic

Of the fact that a few sessions are terminated in same peering system) leaks FECs on all || sessions? That may result in a loop for some applications
and “Section 3. Detection of multi-instance peering” addresses = that issue.  It lets a system aware of || sessions and thus can take necess= ary actions.


4. In case 1~4, one interface will serve multiple instance, I guess, the interface you refer is physical interface, and when sharing one physical interface, then one sub-interface for each instance is still required, right? In my understanding, one IP interface could not be shared by multiple LDP instance, otherwise how to treat the prefix of that interface.

[Pranjal] I won’t view it as sub-interface since all instances are running in same FEC database. So if w= e think from a “virtual router” point of view (each
Virtual Router is separated across all verticals in RIB/LFIB/FIB and self-sufficient) then all the multiple LSR instances would be running withi= n same
Virtual Router and thus can share interfaces assigned to that Virtual Route= r. Although the draft does not prevent usage of same Interface across all LSRs
in practice it is desirable to fate separate the physical topology to achie= ve separation across entire vertical. Separation of physical topology can be <= br> achieved by LDP Multi-topology that synchronizes IGP and LDP’s view (= h= ttp://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-04) or by using hello
adjacency capabilities at LDP level (http://tools.ietf.org/html/draft-pdutta-mpls-ldp-adj-capability-00).

 


Hope to see your clarification. Thanks.

Lizhong
 

Loa Andersson <loa@pi.nu> wrote 2012/08/29 17:10:01:

> Kamran. Eric and Lizhong,
>
> You have been selected as an MPLS Review team reviewers for
> draft-pdutta-mpls-multi-ldp-instance-00.txt.
>
> Note to authors: You have been CC’d on this email so that you ca= n 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 usef= ul
> (ie, is it likely to be actually useful in operational networks), and = is
> the document technically sound?  We are interested in knowing whe= ther
> 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 Sep 13, 2012?
>
> Thanks, Loa
> (as MPLS WG chair)
> --
>
>
> Loa Andersson   &nbs= p;                     email: loa.andersson@ericsson.com
> Sr Strategy and Standards Manager           &= nbsp;loa@pi.nu
> Ericsson Inc                 &= nbsp;        phone: +46 10 717 52 13
>                     =                        = ;   +46 767 72 92 13
>

--_000_C584046466ED224CA92C1BC3313B963E13F0B8C864INBANSXCHMBSA_-- From internet-drafts@ietf.org Thu Aug 30 18:19: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 52DAA21F8508; Thu, 30 Aug 2012 18:19:55 -0700 (PDT) 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 V3oq5GsAHArC; Thu, 30 Aug 2012 18:19:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D8921F850C; Thu, 30 Aug 2012 18:19:54 -0700 (PDT) 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.34 Message-ID: <20120831011954.9389.53104.idtracker@ietfa.amsl.com> Date: Thu, 30 Aug 2012 18:19:54 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-return-path-specified-lsp-ping-08.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: Fri, 31 Aug 2012 01:19:55 -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 : Return Path Specified LSP Ping Author(s) : Mach(Guoyi) Chen Wei Cao So Ning Frederic Jounay Simon Delord Filename : draft-ietf-mpls-return-path-specified-lsp-ping-08.txt Pages : 21 Date : 2012-08-30 Abstract: This document defines extensions to the failure-detection protocol for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) known as "LSP Ping" that allow selection of the LSP to use for the echo reply return path. Enforcing a specific return path can be used to verify bidirectional connectivity and also increase LSP ping robustness. It may also be used by Bidirectional Forwarding Detection (BFD) for MPLS bootstrap signaling thereby making BFD for MPLS more robust. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-return-path-specified-lsp-= ping There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-return-path-specified-lsp-ping-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-return-path-specified-ls= p-ping-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lizhong.jin@zte.com.cn Thu Aug 30 23:44: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 6E4C821F852A for ; Thu, 30 Aug 2012 23:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.975 X-Spam-Level: X-Spam-Status: No, score=-100.975 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 SQ0Lkt+aioLp for ; Thu, 30 Aug 2012 23:44:53 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id C78FB21F8526 for ; Thu, 30 Aug 2012 23:44:52 -0700 (PDT) Received: from [192.168.168.119] by mx5.zte.com.cn with surfront esmtp id 10723806486374; Fri, 31 Aug 2012 14:28:15 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id B2265193ACF8; Fri, 31 Aug 2012 14:39:15 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q7V6hG5s078538; Fri, 31 Aug 2012 14:43:16 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: "Dutta, Pranjal K (Pranjal)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Fri, 31 Aug 2012 14:42:23 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-31 14:43:09, Serialize complete at 2012-08-31 14:43:09 Content-Type: multipart/alternative; boundary="=_alternative 0024EA8048257A6B_=" X-MAIL: mse01.zte.com.cn q7V6hG5s078538 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org 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, 31 Aug 2012 06:44:54 -0000 This is a multipart message in MIME format. --=_alternative 0024EA8048257A6B_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgUHJhbmphbCwNClRoYW5rcyBmb3IgdGhlIGNsYXJpZmljYXRpb24sIG11Y2ggY2xlYXIgdGhh biBiZWZvcmUgZm9yIG1lIG5vdy4gUGxlYXNlIA0Kc2VlIGlubGluZSBmb3IgYWRkdGlvbmFsIGNv bW1lbnRzLg0KDQpPbmUgbW9yZSBxdWVzdGlvbiBmb3Igc2VjdGlvbiAzLg0KIldoZW4gYSBMU1Ig cmVjZWl2ZXMgYSBGRUMgbGFiZWwgbWFwcGluZyBmcm9tIGEgcGVlcmluZyBzZXNzaW9uIGJ1dCBz YW1lIA0KRkVDIG1hcHBpbmcgaGFzIGJlZW4gYWxyZWFkeSByZWNlaXZlciBvdmVyIGFub3RoZXIg cGVlcmluZyBzZXNzaW9uIA0KYXNzb2NpYXRlZCB3aXRoIHNhbWUgTm9kZS1JRCB0aGVuIHRoZSBy ZWNlaXZpbmcgTFNSIE1VU1Qgc2VuZCBhIExhYmVsIA0KUmVsZWFzZSB0byB0aGUgcGVlcmluZyBz ZXNzaW9uIHdpdGggc3RhdHVjIGNvZGUiDQpIb3cgYSBMU1IgY291bGQga25vdyB0aGUgRkVDIG1h cHBpbmcgaW5mb3JtYXRpb24gZnJvbSBhbm90aGVyIGluc3RhbmNlPyBEbyANCnlvdSBtZWFuIHRo ZSB0d28gaW5zdGFuY2UgbmVlZCB0byBzeW5jaHJvbml6ZSBGRUMgbWFwcGluZyBpbmZvcm1hdGlv bj8NCg0KVGhhbmtzDQpMaXpob25nDQoNCiJEdXR0YSwgUHJhbmphbCBLIChQcmFuamFsKSIgPHBy YW5qYWwuZHV0dGFAYWxjYXRlbC1sdWNlbnQuY29tPiB3cm90ZSANCjIwMTIvMDgvMzEgMDE6MDA6 NTM6DQoNCj4gMi4gRm9yIExEUCBtdWx0aXBsZSBpbnN0YW5jZSwgaXMgaXQgYWxsb3dlZCBmb3Ig ZHVwbGljYXRlZCBGRUMgDQo+IGJldHdlZW4gdHdvIGluc3RhbmNlPyANCj4gDQo+IFtQcmFuamFs XSBEdXBsaWNhdGVkIEZFQ3Mgd29uoa90IGJlIGFsbG93ZWQuIFRoZSBwYXJhbGxlbCBzZXNzaW9u cyANCj4gYmV0d2VlbiB0d28gcGVlcmluZyBzeXN0ZW1zIG5lZWRzIHRvIGJlIGRpc2pvaW50IHdp dGggcmVzcGVjdCB0byB0aGUNCj4gd29ya2luZyBzZXQgDQo+IKhDIHRoZSBGRUNzLiBUaGlzIG5l ZWRzIHRvIGJlIGVuc3VyZWQgdGhydSB2YXJpb3VzIEZFQyBzcGVjaWZpYyANCj4gc2Vzc2lvbiBj YXBhYmlsaXRpZXMuIEVhY2ggfHwgc2Vzc2lvbiBtdXN0IGFkdmVydGlzZSBkaXNqb2ludCBGRUMg DQo+IGNhcGFiaWxpdGllcy4gU2VjdGlvbiANCj4gMi4xLjEgZXhwbGFpbnMgdGhlIHVzZSBvZiBM RFAgc2Vzc2lvbiBjYXBhYmlsaXRpZXMgKFJGQzU1NjEpIHRvIGtlZXANCj4gdGhlIEZFQyBkaXN0 cmlidXRpb24gbXV0dWFsbHkgZXhjbHVzaXZlLiBXaGF0IGNyaXRlcmlhIHRvIGJlIHVzZWQgDQo+ IGZvciBzZWdyZWdhdGlvbiANCj4gb2YgRkVDcyBhcmUgdG8gYmUgZGVjaWRlZCBvbiBjYXNlIHRv IGNhc2UgYmFzaWMuIFRoaXMgZHJhZnQgcHJvdmlkZXMNCj4gdGhlIGZ1bmRhbWVudGFsIGJ1aWxk aW5nIGJsb2NrIGZvciBjb250cm9sIHBsYW5lIGZhdGUgc2VwYXJhdGlvbi4NCltMaXpob25nXSBU aGVuIGRvZXMgdGhlIExEUCBtdWx0aXBsZSBpbnN0YW5jZSBpbiB0aGlzIGRyYWZ0IGRvZXMgbm90 IA0KaW5jbHVkZSB0aGUgVlJGIGNhc2U/IEl0IGlzIGJldHRlciB0byBleHBsaWNpdCBkZXNjcmli ZSB0aGlzLCBvdGhlcndpc2UgaXQgDQppcyBjb25mdXNpbmcuIEluIHRoZSBWUkYgY2FzZSwgdGhl IEZFQyB3aWxsIGJlIGR1cGxpY2F0ZWQgYmV0d2VlbiANCmRpZmZlcmVudCBpbnN0YW5jZXMuDQoN Cj4gDQo+IDMuIElmIGR1cGxpY2F0ZWQgRkVDcyBhcmUgcG9zc2libGUgYmV0d2VlbiB0d28gaW5z dGFuY2UsIHJlY2VpdmluZyANCj4gc2FtZSBsYWJlbCBtYXBwaW5nIGZyb20gcGFyYWxsZWwgbXVs dGktbHNyIHBlZXJpbmcgc2Vzc2lvbnMgY291bGQgDQo+IG5vdCBpbnRlcnByZXQgYXMgbG9vcCwg cmlnaHQ/IA0KPiANCj4gW1ByYW5qYWxdIER1cGxpY2F0ZWQgRkVDcyBhcmUgbm90IGFsbG93ZWQg YWNyb3NzIC4gQnV0IHdoYXQgaWYgYSANCj4gcGVlcmluZyBzeXN0ZW0gbWlzYmVoYXZlcyBvciBw ZWVyaW5nIHN5c3RlbSBub3Qgc3VwcG9ydGluZyB0aGUgDQo+IHNvbHV0aW9uICh0aHVzIGFnbm9z dGljIA0KPiBPZiB0aGUgZmFjdCB0aGF0IGEgZmV3IHNlc3Npb25zIGFyZSB0ZXJtaW5hdGVkIGlu IHNhbWUgcGVlcmluZyANCj4gc3lzdGVtKSBsZWFrcyBGRUNzIG9uIGFsbCB8fCBzZXNzaW9ucz8g VGhhdCBtYXkgcmVzdWx0IGluIGEgbG9vcCBmb3INCj4gc29tZSBhcHBsaWNhdGlvbnMgDQo+IGFu ZCChsFNlY3Rpb24gMy4gRGV0ZWN0aW9uIG9mIG11bHRpLWluc3RhbmNlIHBlZXJpbmehsSBhZGRy ZXNzZXMgdGhhdCANCj4gaXNzdWUuICBJdCBsZXRzIGEgc3lzdGVtIGF3YXJlIG9mIHx8IHNlc3Np b25zIGFuZCB0aHVzIGNhbiB0YWtlIA0KPiBuZWNlc3NhcnkgYWN0aW9ucy4NCltMaXpob25nXSBJ ZiB0aGUgRkVDIHNldCAoaWRlbnRpZmllZCBieSBjYXBhYmlsaXR5KSBpcyB0b3RhbGx5IGRpc2pv aW50IA0KYmV0d2VlbiB0d28gaW5zdGFuY2UsIGl0IGNvdWxkIGJlIHNpbXBseSBkaXNjYXJkIHRo ZSBGRUMgbGFiZWwgbWFwcGluZyBpZiANCm5vdCBtYXRjaCBjYXBhYmlsaXR5IHRvIGF2b2lkIGxv b3AsIHdoeSB3ZSBzdGlsbCBuZWVkIE5vZGUtSUQgVExWo78NCg0KPiANCj4gNC4gSW4gY2FzZSAx fjQsIG9uZSBpbnRlcmZhY2Ugd2lsbCBzZXJ2ZSBtdWx0aXBsZSBpbnN0YW5jZSwgSSBndWVzcywN Cj4gdGhlIGludGVyZmFjZSB5b3UgcmVmZXIgaXMgcGh5c2ljYWwgaW50ZXJmYWNlLCBhbmQgd2hl biBzaGFyaW5nIG9uZSANCj4gcGh5c2ljYWwgaW50ZXJmYWNlLCB0aGVuIG9uZSBzdWItaW50ZXJm YWNlIGZvciBlYWNoIGluc3RhbmNlIGlzIA0KPiBzdGlsbCByZXF1aXJlZCwgcmlnaHQ/IEluIG15 IHVuZGVyc3RhbmRpbmcsIG9uZSBJUCBpbnRlcmZhY2UgY291bGQgDQo+IG5vdCBiZSBzaGFyZWQg YnkgbXVsdGlwbGUgTERQIGluc3RhbmNlLCBvdGhlcndpc2UgaG93IHRvIHRyZWF0IHRoZSANCj4g cHJlZml4IG9mIHRoYXQgaW50ZXJmYWNlLiANCg0KPiBbUHJhbmphbF0gSSB3b26hr3QgdmlldyBp dCBhcyBzdWItaW50ZXJmYWNlIHNpbmNlIGFsbCBpbnN0YW5jZXMgYXJlIA0KPiBydW5uaW5nIGlu IHNhbWUgRkVDIGRhdGFiYXNlLiBTbyBpZiB3ZSB0aGluayBmcm9tIGEgobB2aXJ0dWFsIHJvdXRl cqGxDQo+IHBvaW50IG9mIHZpZXcgKGVhY2ggDQo+IFZpcnR1YWwgUm91dGVyIGlzIHNlcGFyYXRl ZCBhY3Jvc3MgYWxsIHZlcnRpY2FscyBpbiBSSUIvTEZJQi9GSUIgYW5kDQo+IHNlbGYtc3VmZmlj aWVudCkgdGhlbiBhbGwgdGhlIG11bHRpcGxlIExTUiBpbnN0YW5jZXMgd291bGQgYmUgDQo+IHJ1 bm5pbmcgd2l0aGluIHNhbWUgDQo+IFZpcnR1YWwgUm91dGVyIGFuZCB0aHVzIGNhbiBzaGFyZSBp bnRlcmZhY2VzIGFzc2lnbmVkIHRvIHRoYXQgDQo+IFZpcnR1YWwgUm91dGVyLiBBbHRob3VnaCB0 aGUgZHJhZnQgZG9lcyBub3QgcHJldmVudCB1c2FnZSBvZiBzYW1lIA0KPiBJbnRlcmZhY2UgYWNy b3NzIGFsbCBMU1JzIA0KPiBpbiBwcmFjdGljZSBpdCBpcyBkZXNpcmFibGUgdG8gZmF0ZSBzZXBh cmF0ZSB0aGUgcGh5c2ljYWwgdG9wb2xvZ3kgDQo+IHRvIGFjaGlldmUgc2VwYXJhdGlvbiBhY3Jv c3MgZW50aXJlIHZlcnRpY2FsLiBTZXBhcmF0aW9uIG9mIHBoeXNpY2FsDQo+IHRvcG9sb2d5IGNh biBiZSANCj4gYWNoaWV2ZWQgYnkgTERQIE11bHRpLXRvcG9sb2d5IHRoYXQgc3luY2hyb25pemVz IElHUCBhbmQgTERQoa9zIHZpZXcgKA0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW1wbHMtbGRwLW11bHRpLXRvcG9sb2d5LTA0KSBvcg0KPiBieSB1c2luZyBoZWxsbyAN Cj4gYWRqYWNlbmN5IGNhcGFiaWxpdGllcyBhdCBMRFAgbGV2ZWwgKGh0dHA6Ly90b29scy5pZXRm Lg0KPiBvcmcvaHRtbC9kcmFmdC1wZHV0dGEtbXBscy1sZHAtYWRqLWNhcGFiaWxpdHktMDApLg0K PiANCj4gDQo+IEhvcGUgdG8gc2VlIHlvdXIgY2xhcmlmaWNhdGlvbi4gVGhhbmtzLiANCj4gDQo+ IExpemhvbmcgDQo+IA0KPiANCj4gTG9hIEFuZGVyc3NvbiA8bG9hQHBpLm51PiB3cm90ZSAyMDEy LzA4LzI5IDE3OjEwOjAxOg0KPiANCj4gPiBLYW1yYW4uIEVyaWMgYW5kIExpemhvbmcsDQo+ID4g DQo+ID4gWW91IGhhdmUgYmVlbiBzZWxlY3RlZCBhcyBhbiBNUExTIFJldmlldyB0ZWFtIHJldmll d2VycyBmb3INCj4gPiBkcmFmdC1wZHV0dGEtbXBscy1tdWx0aS1sZHAtaW5zdGFuY2UtMDAudHh0 Lg0KPiA+IA0KPiA+IE5vdGUgdG8gYXV0aG9yczogWW91IGhhdmUgYmVlbiBDQ6GvZCBvbiB0aGlz IGVtYWlsIHNvIHRoYXQgeW91IGNhbiANCmtub3cNCj4gPiB0aGF0IHRoaXMgcmV2aWV3IGlzIGdv aW5nIG9uLiBIb3dldmVyLCBwbGVhc2UgZG8gbm90IHJldmlldyB5b3VyIG93bg0KPiA+IGRvY3Vt ZW50Lg0KPiA+IA0KPiA+IFJldmlld3Mgc2hvdWxkIGNvbW1lbnQgb24gd2hldGhlciB0aGUgZG9j dW1lbnQgaXMgY29oZXJlbnQsIGlzIGl0IA0KdXNlZnVsDQo+ID4gKGllLCBpcyBpdCBsaWtlbHkg dG8gYmUgYWN0dWFsbHkgdXNlZnVsIGluIG9wZXJhdGlvbmFsIG5ldHdvcmtzKSwgYW5kIA0KaXMN Cj4gPiB0aGUgZG9jdW1lbnQgdGVjaG5pY2FsbHkgc291bmQ/ICBXZSBhcmUgaW50ZXJlc3RlZCBp biBrbm93aW5nIHdoZXRoZXINCj4gPiB0aGUgZG9jdW1lbnQgaXMgcmVhZHkgdG8gYmUgY29uc2lk ZXJlZCBmb3IgV0cgYWRvcHRpb24gKGllLCBpdCBkb2VzbqGvDQp0DQo+ID4gaGF2ZSB0byBiZSBw ZXJmZWN0IGF0IHRoaXMgcG9pbnQsIGJ1dCBzaG91bGQgYmUgYSBnb29kIHN0YXJ0KS4NCj4gPiAN Cj4gPiBSZXZpZXdzIHNob3VsZCBiZSBzZW50IHRvIHRoZSBkb2N1bWVudCBhdXRob3JzLCBXRyBj by1jaGFpcnMgYW5kDQo+ID4gc2VjcmV0YXJ5LCBhbmQgQ0Ohr2QgdG8gdGhlIE1QTFMgV0cgZW1h aWwgbGlzdC4gSWYgbmVjZXNzYXJ5LCBjb21tZW50cw0KPiA+IG1heSBiZSBzZW50IHByaXZhdGVs eSB0byBvbmx5IHRoZSBXRyBjaGFpcnMuDQo+ID4gDQo+ID4gQXJlIHlvdSBhYmxlIHRvIHJldmll dyB0aGlzIGRyYWZ0IGJ5IFNlcCAxMywgMjAxMj8NCj4gPiANCj4gPiBUaGFua3MsIExvYQ0KPiA+ IChhcyBNUExTIFdHIGNoYWlyKQ0KPiA+IC0tIA0KPiA+IA0KPiA+IA0KPiA+IExvYSBBbmRlcnNz b24gICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6IA0KbG9hLmFuZGVyc3NvbkBlcmljc3Nv bi5jb20NCj4gPiBTciBTdHJhdGVneSBhbmQgU3RhbmRhcmRzIE1hbmFnZXIgICAgICAgICAgICBs b2FAcGkubnUNCj4gPiBFcmljc3NvbiBJbmMgICAgICAgICAgICAgICAgICAgICAgICAgIHBob25l OiArNDYgMTAgNzE3IDUyIDEzDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICs0NiA3NjcgNzIgOTIgMTMNCj4gPiANCg== --=_alternative 0024EA8048257A6B_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFByYW5qYWwsPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3MgZm9yIHRoZSBjbGFyaWZp Y2F0aW9uLCBtdWNoIGNsZWFyDQp0aGFuIGJlZm9yZSBmb3IgbWUgbm93LiBQbGVhc2Ugc2VlIGlu bGluZSBmb3IgYWRkdGlvbmFsIGNvbW1lbnRzLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+T25lIG1vcmUgcXVlc3Rpb24gZm9yIHNlY3Rpb24gMy48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O1doZW4gYSBMU1Ig cmVjZWl2ZXMgYSBGRUMgbGFiZWwNCm1hcHBpbmcgZnJvbSBhIHBlZXJpbmcgc2Vzc2lvbiBidXQg c2FtZSBGRUMgbWFwcGluZyBoYXMgYmVlbiBhbHJlYWR5IHJlY2VpdmVyDQpvdmVyIGFub3RoZXIg cGVlcmluZyBzZXNzaW9uIGFzc29jaWF0ZWQgd2l0aCBzYW1lIE5vZGUtSUQgdGhlbiB0aGUgcmVj ZWl2aW5nDQpMU1IgTVVTVCBzZW5kIGEgTGFiZWwgUmVsZWFzZSB0byB0aGUgcGVlcmluZyBzZXNz aW9uIHdpdGggc3RhdHVjIGNvZGUmcXVvdDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPkhvdyBhIExTUiBjb3VsZCBrbm93IHRoZSBGRUMgbWFwcGluZw0KaW5mb3Jt YXRpb24gZnJvbSBhbm90aGVyIGluc3RhbmNlPyBEbyB5b3UgbWVhbiB0aGUgdHdvIGluc3RhbmNl IG5lZWQgdG8NCnN5bmNocm9uaXplIEZFQyBtYXBwaW5nIGluZm9ybWF0aW9uPzwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5MaXpob25nPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtEdXR0YSwgUHJhbmphbCBLIChQ cmFuamFsKSZxdW90Ow0KJmx0O3ByYW5qYWwuZHV0dGFAYWxjYXRlbC1sdWNlbnQuY29tJmd0OyB3 cm90ZSAyMDEyLzA4LzMxIDAxOjAwOjUzOjxicj4NCjxicj4NCiZndDsgMi4gRm9yIExEUCBtdWx0 aXBsZSBpbnN0YW5jZSwgaXMgaXQgYWxsb3dlZCBmb3IgZHVwbGljYXRlZCBGRUMgPGJyPg0KJmd0 OyBiZXR3ZWVuIHR3byBpbnN0YW5jZT8gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj4mZ3Q7ICZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+Jmd0OyBbUHJhbmphbF0gRHVwbGljYXRlZCBGRUNzIHdvbqGvdA0KYmUgYWxsb3dl ZC4gVGhlIHBhcmFsbGVsIHNlc3Npb25zIDxicj4NCiZndDsgYmV0d2VlbiB0d28gcGVlcmluZyBz eXN0ZW1zIG5lZWRzIHRvIGJlIGRpc2pvaW50IHdpdGggcmVzcGVjdCB0byB0aGU8YnI+DQomZ3Q7 IHdvcmtpbmcgc2V0IDxicj4NCiZndDsgqEMgdGhlIEZFQ3MuIFRoaXMgbmVlZHMgdG8gYmUgZW5z dXJlZCB0aHJ1IHZhcmlvdXMgRkVDIHNwZWNpZmljIDxicj4NCiZndDsgc2Vzc2lvbiBjYXBhYmls aXRpZXMuIEVhY2ggfHwgc2Vzc2lvbiBtdXN0IGFkdmVydGlzZSBkaXNqb2ludCBGRUMNCjxicj4N CiZndDsgY2FwYWJpbGl0aWVzLiBTZWN0aW9uIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+Jmd0OyAyLjEuMSBleHBsYWlucyB0aGUgdXNlIG9mIExEUCBzZXNzaW9u DQpjYXBhYmlsaXRpZXMgKFJGQzU1NjEpIHRvIGtlZXA8YnI+DQomZ3Q7IHRoZSBGRUMgZGlzdHJp YnV0aW9uIG11dHVhbGx5IGV4Y2x1c2l2ZS4gV2hhdCBjcml0ZXJpYSB0byBiZSB1c2VkDQo8YnI+ DQomZ3Q7IGZvciBzZWdyZWdhdGlvbiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPiZndDsgb2YgRkVDcyBhcmUgdG8gYmUgZGVjaWRlZCBvbiBjYXNlDQp0byBjYXNl IGJhc2ljLiBUaGlzIGRyYWZ0IHByb3ZpZGVzPGJyPg0KJmd0OyB0aGUgZnVuZGFtZW50YWwgYnVp bGRpbmcgYmxvY2sgZm9yIGNvbnRyb2wgcGxhbmUgZmF0ZSBzZXBhcmF0aW9uLjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+W0xpemhvbmddIFRoZW4gZG9lcyB0aGUg TERQIG11bHRpcGxlDQppbnN0YW5jZSBpbiB0aGlzIGRyYWZ0IGRvZXMgbm90IGluY2x1ZGUgdGhl IFZSRiBjYXNlPyBJdCBpcyBiZXR0ZXIgdG8gZXhwbGljaXQNCmRlc2NyaWJlIHRoaXMsIG90aGVy d2lzZSBpdCBpcyBjb25mdXNpbmcuIEluIHRoZSBWUkYgY2FzZSwgdGhlIEZFQyB3aWxsDQpiZSBk dXBsaWNhdGVkIGJldHdlZW4gZGlmZmVyZW50IGluc3RhbmNlcy48L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgPGJyPg0KJmd0OyAzLiBJZiBkdXBs aWNhdGVkIEZFQ3MgYXJlIHBvc3NpYmxlIGJldHdlZW4gdHdvIGluc3RhbmNlLCByZWNlaXZpbmcN Cjxicj4NCiZndDsgc2FtZSBsYWJlbCBtYXBwaW5nIGZyb20gcGFyYWxsZWwgbXVsdGktbHNyIHBl ZXJpbmcgc2Vzc2lvbnMgY291bGQNCjxicj4NCiZndDsgbm90IGludGVycHJldCBhcyBsb29wLCBy aWdodD8gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7ICZu YnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyBbUHJh bmphbF0gRHVwbGljYXRlZCBGRUNzIGFyZSBub3QNCmFsbG93ZWQgYWNyb3NzIC4gQnV0IHdoYXQg aWYgYSA8YnI+DQomZ3Q7IHBlZXJpbmcgc3lzdGVtIG1pc2JlaGF2ZXMgb3IgcGVlcmluZyBzeXN0 ZW0gbm90IHN1cHBvcnRpbmcgdGhlIDxicj4NCiZndDsgc29sdXRpb24gKHRodXMgYWdub3N0aWMg PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IE9mIHRoZSBm YWN0IHRoYXQgYSBmZXcgc2Vzc2lvbnMNCmFyZSB0ZXJtaW5hdGVkIGluIHNhbWUgcGVlcmluZyA8 YnI+DQomZ3Q7IHN5c3RlbSkgbGVha3MgRkVDcyBvbiBhbGwgfHwgc2Vzc2lvbnM/IFRoYXQgbWF5 IHJlc3VsdCBpbiBhIGxvb3AgZm9yPGJyPg0KJmd0OyBzb21lIGFwcGxpY2F0aW9ucyA8YnI+DQom Z3Q7IGFuZCChsFNlY3Rpb24gMy4gRGV0ZWN0aW9uIG9mIG11bHRpLWluc3RhbmNlIHBlZXJpbmeh sSBhZGRyZXNzZXMNCnRoYXQgPGJyPg0KJmd0OyBpc3N1ZS4gJm5ic3A7SXQgbGV0cyBhIHN5c3Rl bSBhd2FyZSBvZiB8fCBzZXNzaW9ucyBhbmQgdGh1cyBjYW4gdGFrZQ0KPGJyPg0KJmd0OyBuZWNl c3NhcnkgYWN0aW9ucy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PltMaXpob25nXSBJZiB0aGUgRkVDIHNldCAoaWRlbnRpZmllZA0KYnkgY2FwYWJpbGl0eSkgaXMg dG90YWxseSBkaXNqb2ludCBiZXR3ZWVuIHR3byBpbnN0YW5jZSwgaXQgY291bGQgYmUgc2ltcGx5 DQpkaXNjYXJkIHRoZSBGRUMgbGFiZWwgbWFwcGluZyBpZiBub3QgbWF0Y2ggY2FwYWJpbGl0eSB0 byBhdm9pZCBsb29wLCB3aHkNCndlIHN0aWxsIG5lZWQgTm9kZS1JRCBUTFajvzwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyA8YnI+DQomZ3Q7IDQu IEluIGNhc2UgMX40LCBvbmUgaW50ZXJmYWNlIHdpbGwgc2VydmUgbXVsdGlwbGUgaW5zdGFuY2Us IEkgZ3Vlc3MsPGJyPg0KJmd0OyB0aGUgaW50ZXJmYWNlIHlvdSByZWZlciBpcyBwaHlzaWNhbCBp bnRlcmZhY2UsIGFuZCB3aGVuIHNoYXJpbmcgb25lDQo8YnI+DQomZ3Q7IHBoeXNpY2FsIGludGVy ZmFjZSwgdGhlbiBvbmUgc3ViLWludGVyZmFjZSBmb3IgZWFjaCBpbnN0YW5jZSBpcyA8YnI+DQom Z3Q7IHN0aWxsIHJlcXVpcmVkLCByaWdodD8gSW4gbXkgdW5kZXJzdGFuZGluZywgb25lIElQIGlu dGVyZmFjZSBjb3VsZA0KPGJyPg0KJmd0OyBub3QgYmUgc2hhcmVkIGJ5IG11bHRpcGxlIExEUCBp bnN0YW5jZSwgb3RoZXJ3aXNlIGhvdyB0byB0cmVhdCB0aGUNCjxicj4NCiZndDsgcHJlZml4IG9m IHRoYXQgaW50ZXJmYWNlLiA8YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPiZndDsgW1ByYW5qYWxdIEkgd29uoa90IHZpZXcgaXQgYXMNCnN1Yi1pbnRlcmZh Y2Ugc2luY2UgYWxsIGluc3RhbmNlcyBhcmUgPGJyPg0KJmd0OyBydW5uaW5nIGluIHNhbWUgRkVD IGRhdGFiYXNlLiBTbyBpZiB3ZSB0aGluayBmcm9tIGEgobB2aXJ0dWFsIHJvdXRlcqGxPGJyPg0K Jmd0OyBwb2ludCBvZiB2aWV3IChlYWNoIDxicj4NCiZndDsgVmlydHVhbCBSb3V0ZXIgaXMgc2Vw YXJhdGVkIGFjcm9zcyBhbGwgdmVydGljYWxzIGluIFJJQi9MRklCL0ZJQiBhbmQ8YnI+DQomZ3Q7 IHNlbGYtc3VmZmljaWVudCkgdGhlbiBhbGwgdGhlIG11bHRpcGxlIExTUiBpbnN0YW5jZXMgd291 bGQgYmUgPGJyPg0KJmd0OyBydW5uaW5nIHdpdGhpbiBzYW1lIDxicj4NCiZndDsgVmlydHVhbCBS b3V0ZXIgYW5kIHRodXMgY2FuIHNoYXJlIGludGVyZmFjZXMgYXNzaWduZWQgdG8gdGhhdCA8YnI+ DQomZ3Q7IFZpcnR1YWwgUm91dGVyLiBBbHRob3VnaCB0aGUgZHJhZnQgZG9lcyBub3QgcHJldmVu dCB1c2FnZSBvZiBzYW1lDQo8YnI+DQomZ3Q7IEludGVyZmFjZSBhY3Jvc3MgYWxsIExTUnMgPGJy Pg0KJmd0OyBpbiBwcmFjdGljZSBpdCBpcyBkZXNpcmFibGUgdG8gZmF0ZSBzZXBhcmF0ZSB0aGUg cGh5c2ljYWwgdG9wb2xvZ3kNCjxicj4NCiZndDsgdG8gYWNoaWV2ZSBzZXBhcmF0aW9uIGFjcm9z cyBlbnRpcmUgdmVydGljYWwuIFNlcGFyYXRpb24gb2YgcGh5c2ljYWw8YnI+DQomZ3Q7IHRvcG9s b2d5IGNhbiBiZSA8YnI+DQomZ3Q7IGFjaGlldmVkIGJ5IExEUCBNdWx0aS10b3BvbG9neSB0aGF0 IHN5bmNocm9uaXplcyBJR1AgYW5kIExEUKGvcyB2aWV3DQooPGJyPg0KJmd0OyBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1wbHMtbGRwLW11bHRpLXRvcG9sb2d5LTA0KQ0K b3I8YnI+DQomZ3Q7IGJ5IHVzaW5nIGhlbGxvIDxicj4NCiZndDsgYWRqYWNlbmN5IGNhcGFiaWxp dGllcyBhdCBMRFAgbGV2ZWwgKGh0dHA6Ly90b29scy5pZXRmLjxicj4NCiZndDsgb3JnL2h0bWwv ZHJhZnQtcGR1dHRhLW1wbHMtbGRwLWFkai1jYXBhYmlsaXR5LTAwKS48L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgJm5ic3A7PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IDxicj4NCiZndDsgSG9wZSB0byBzZWUgeW91 ciBjbGFyaWZpY2F0aW9uLiBUaGFua3MuIDxicj4NCiZndDsgPGJyPg0KJmd0OyBMaXpob25nIDxi cj4NCiZndDsgJm5ic3A7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBMb2EgQW5kZXJzc29uICZsdDts b2FAcGkubnUmZ3Q7IHdyb3RlIDIwMTIvMDgvMjkgMTc6MTA6MDE6PGJyPg0KJmd0OyA8YnI+DQom Z3Q7ICZndDsgS2FtcmFuLiBFcmljIGFuZCBMaXpob25nLDxicj4NCiZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgWW91IGhhdmUgYmVlbiBzZWxlY3RlZCBhcyBhbiBNUExTIFJldmlldyB0ZWFtIHJl dmlld2VycyBmb3I8YnI+DQomZ3Q7ICZndDsgZHJhZnQtcGR1dHRhLW1wbHMtbXVsdGktbGRwLWlu c3RhbmNlLTAwLnR4dC48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IE5vdGUgdG8gYXV0 aG9yczogWW91IGhhdmUgYmVlbiBDQ6GvZCBvbiB0aGlzIGVtYWlsIHNvIHRoYXQgeW91DQpjYW4g a25vdzxicj4NCiZndDsgJmd0OyB0aGF0IHRoaXMgcmV2aWV3IGlzIGdvaW5nIG9uLiBIb3dldmVy LCBwbGVhc2UgZG8gbm90IHJldmlldyB5b3VyDQpvd248YnI+DQomZ3Q7ICZndDsgZG9jdW1lbnQu PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBSZXZpZXdzIHNob3VsZCBjb21tZW50IG9u IHdoZXRoZXIgdGhlIGRvY3VtZW50IGlzIGNvaGVyZW50LCBpcw0KaXQgdXNlZnVsPGJyPg0KJmd0 OyAmZ3Q7IChpZSwgaXMgaXQgbGlrZWx5IHRvIGJlIGFjdHVhbGx5IHVzZWZ1bCBpbiBvcGVyYXRp b25hbCBuZXR3b3JrcyksDQphbmQgaXM8YnI+DQomZ3Q7ICZndDsgdGhlIGRvY3VtZW50IHRlY2hu aWNhbGx5IHNvdW5kPyAmbmJzcDtXZSBhcmUgaW50ZXJlc3RlZCBpbiBrbm93aW5nDQp3aGV0aGVy PGJyPg0KJmd0OyAmZ3Q7IHRoZSBkb2N1bWVudCBpcyByZWFkeSB0byBiZSBjb25zaWRlcmVkIGZv ciBXRyBhZG9wdGlvbiAoaWUsIGl0DQpkb2VzbqGvdDxicj4NCiZndDsgJmd0OyBoYXZlIHRvIGJl IHBlcmZlY3QgYXQgdGhpcyBwb2ludCwgYnV0IHNob3VsZCBiZSBhIGdvb2Qgc3RhcnQpLjxicj4N CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgUmV2aWV3cyBzaG91bGQgYmUgc2VudCB0byB0aGUg ZG9jdW1lbnQgYXV0aG9ycywgV0cgY28tY2hhaXJzDQphbmQ8YnI+DQomZ3Q7ICZndDsgc2VjcmV0 YXJ5LCBhbmQgQ0Ohr2QgdG8gdGhlIE1QTFMgV0cgZW1haWwgbGlzdC4gSWYgbmVjZXNzYXJ5LA0K Y29tbWVudHM8YnI+DQomZ3Q7ICZndDsgbWF5IGJlIHNlbnQgcHJpdmF0ZWx5IHRvIG9ubHkgdGhl IFdHIGNoYWlycy48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEFyZSB5b3UgYWJsZSB0 byByZXZpZXcgdGhpcyBkcmFmdCBieSBTZXAgMTMsIDIwMTI/PGJyPg0KJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyBUaGFua3MsIExvYTxicj4NCiZndDsgJmd0OyAoYXMgTVBMUyBXRyBjaGFpcik8 YnI+DQomZ3Q7ICZndDsgLS0gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgTG9hIEFuZGVyc3NvbiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZW1haWw6 IGxvYS5hbmRlcnNzb25AZXJpY3Nzb24uY29tPGJyPg0KJmd0OyAmZ3Q7IFNyIFN0cmF0ZWd5IGFu ZCBTdGFuZGFyZHMgTWFuYWdlciAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDtsb2FAcGkubnU8YnI+DQomZ3Q7ICZndDsgRXJpY3Nzb24gSW5jICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtwaG9uZTogKzQ2IDEwIDcxNyA1MiAxMzxicj4NCiZndDsgJmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgKzQ2IDc2 NyA3MiA5MiAxMzxicj4NCiZndDsgJmd0OyA8L2ZvbnQ+DQo= --=_alternative 0024EA8048257A6B_=-- From loa@pi.nu Fri Aug 31 05:16: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 AC45221F856C for ; Fri, 31 Aug 2012 05:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 gtTaRiunDk1W for ; Fri, 31 Aug 2012 05:16:47 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 02D5521F846F for ; Fri, 31 Aug 2012 05:16:46 -0700 (PDT) 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) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 32B292A8003; Fri, 31 Aug 2012 14:16:45 +0200 (CEST) Message-ID: <5040AB2F.6050508@pi.nu> Date: Fri, 31 Aug 2012 14:16:47 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: "mpls@ietf.org" , draft-jjwl-mpls-mldp-hsmp@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] IPR poll on draft-jjwl-mpls-mldp-hsmp 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, 31 Aug 2012 12:16:47 -0000 Working Group and authors; The authors of draft-jjwl-mpls-mldp-hsmp has indicated that the draft is ready to be adopted as a working group document. Before starting the poll to make the draft become 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-jjwl-mpls-mldp-hsmp? 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. Please note that this draft has changed name from draft-jin-jounay- mpls-mldp-hsmp to draft-jjwl-mpls-mldp-hsmp, there was an IPR claim filed agains draft-jin-jounay-mpls-mldp-hsmp (ID #1777). 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 pranjal.dutta@alcatel-lucent.com Fri Aug 31 10:21: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 5952921F8605 for ; Fri, 31 Aug 2012 10:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.459 X-Spam-Level: X-Spam-Status: No, score=-7.459 tagged_above=-999 required=5 tests=[AWL=-0.861, 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 90r1suz70VU5 for ; Fri, 31 Aug 2012 10:21:45 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 234A021F85C0 for ; Fri, 31 Aug 2012 10:21:45 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q7VHLaiC028002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 31 Aug 2012 12:21:38 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7VHLYEb007427 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 31 Aug 2012 22:51:34 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Fri, 31 Aug 2012 22:51:33 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Lizhong Jin Date: Fri, 31 Aug 2012 22:51:32 +0530 Thread-Topic: [mpls] MPLS-RT review of draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org Thread-Index: Ac2HRCmookePD4nRTjyBtRrdU5Kr7AAWAMTQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C584046466ED224CA92C1BC3313B963E13F0B8CAA5INBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org 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, 31 Aug 2012 17:21:48 -0000 --_000_C584046466ED224CA92C1BC3313B963E13F0B8CAA5INBANSXCHMBSA_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi Lizhong, Please refer my answers inline. Thanks, Pranjal ________________________________ From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] Sent: Thursday, August 30, 2012 11:42 PM To: Dutta, Pranjal K (Pranjal) Cc: draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org; mpls@ietf.org; mpl= s-chairs@tools.ietf.org Subject: RE: [mpls] MPLS-RT review of draft-pdutta-mpls-multi-ldp-instance@= tools.ietf.org Hi Pranjal, Thanks for the clarification, much clear than before for me now. Please see= inline for addtional comments. One more question for section 3. "When a LSR receives a FEC label mapping from a peering session but same FE= C mapping has been already receiver over another peering session associated= with same Node-ID then the receiving LSR MUST send a Label Release to the = peering session with statuc code" How a LSR could know the FEC mapping information from another instance? Do = you mean the two instance need to synchronize FEC mapping information? [Pranjal] One way to think is as follows - let=1B$B!G=1B(Bs say that detec= tion of multi-instance peering is implemented as in Section 3. Then receivi= ng system would know about the sessions terminating in same remote peering system. So the receiving system can create a group/b= undle id internally for all such || sessions and keep the FEC-label mapping= s also in the database. If there is a collision of Fec label mappings in the group-id database then label release= can be sent, keeping the first one intact. Thanks Lizhong "Dutta, Pranjal K (Pranjal)" wrote 2012/= 08/31 01:00:53: > 2. For LDP multiple instance, is it allowed for duplicated FEC > between two instance? > > [Pranjal] Duplicated FECs won=1B$B!G=1B(Bt be allowed. The parallel sessi= ons > between two peering systems needs to be disjoint with respect to the > working set > - the FECs. This needs to be ensured thru various FEC specific > session capabilities. Each || session must advertise disjoint FEC > capabilities. Section > 2.1.1 explains the use of LDP session capabilities (RFC5561) to keep > the FEC distribution mutually exclusive. What criteria to be used > for segregation > of FECs are to be decided on case to case basic. This draft provides > the fundamental building block for control plane fate separation. [Lizhong] Then does the LDP multiple instance in this draft does not includ= e the VRF case? It is better to explicit describe this, otherwise it is con= fusing. In the VRF case, the FEC will be duplicated between different insta= nces. > > 3. If duplicated FECs are possible between two instance, receiving > same label mapping from parallel multi-lsr peering sessions could > not interpret as loop, right? > > [Pranjal] Duplicated FECs are not allowed across . But what if a > peering system misbehaves or peering system not supporting the > solution (thus agnostic > Of the fact that a few sessions are terminated in same peering > system) leaks FECs on all || sessions? That may result in a loop for > some applications > and =1B$B!H=1B(BSection 3. Detection of multi-instance peering=1B$B!I=1B(= B addresses that > issue. It lets a system aware of || sessions and thus can take > necessary actions. [Lizhong] If the FEC set (identified by capability) is totally disjoint bet= ween two instance, it could be simply discard the FEC label mapping if not = match capability to avoid loop, why we still need Node-ID TLV=1B$B!)=1B(B > > 4. In case 1~4, one interface will serve multiple instance, I guess, > the interface you refer is physical interface, and when sharing one > physical interface, then one sub-interface for each instance is > still required, right? In my understanding, one IP interface could > not be shared by multiple LDP instance, otherwise how to treat the > prefix of that interface. > [Pranjal] I won=1B$B!G=1B(Bt view it as sub-interface since all instances= are > running in same FEC database. So if we think from a =1B$B!H=1B(Bvirtual r= outer=1B$B!I=1B(B > point of view (each > Virtual Router is separated across all verticals in RIB/LFIB/FIB and > self-sufficient) then all the multiple LSR instances would be > running within same > Virtual Router and thus can share interfaces assigned to that > Virtual Router. Although the draft does not prevent usage of same > Interface across all LSRs > in practice it is desirable to fate separate the physical topology > to achieve separation across entire vertical. Separation of physical > topology can be > achieved by LDP Multi-topology that synchronizes IGP and LDP=1B$B!G=1B(Bs= view ( > http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-04) or > by using hello > adjacency capabilities at LDP level (http://tools.ietf. > org/html/draft-pdutta-mpls-ldp-adj-capability-00). > > > Hope to see your clarification. Thanks. > > Lizhong > > > Loa Andersson wrote 2012/08/29 17:10:01: > > > Kamran. Eric and Lizhong, > > > > You have been selected as an MPLS Review team reviewers for > > draft-pdutta-mpls-multi-ldp-instance-00.txt. > > > > Note to authors: You have been CC=1B$B!G=1B(Bd on this email so that yo= u 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 usefu= l > > (ie, is it likely to be actually useful in operational networks), and i= s > > the document technically sound? We are interested in knowing whether > > the document is ready to be considered for WG adoption (ie, it doesn=1B= $B!G=1B(Bt > > 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=1B$B!G=1B(Bd 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 Sep 13, 2012? > > > > Thanks, Loa > > (as MPLS WG 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 > > --_000_C584046466ED224CA92C1BC3313B963E13F0B8CAA5INBANSXCHMBSA_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Hi Lizhong,

      &n= bsp;            = ;     Please refer my answers inline.

Thanks,

Pranjal

 

From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] Sent: Thursday, August 30, 2= 012 11:42 PM
To: Dutta, Pranjal K (Pranjal)
Cc: draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org; mpls@ietf.org; mpls-chairs@tools.ietf.org
Subject: RE: [mpls] MPLS-RT = review of draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org

 


Hi Pranjal,
Thanks for the clarification, much clear than before for me now. Please see inline= for addtional comments.

One more question for section 3.
"When a LSR receives a FEC label mapping from a peering session but same FEC mapp= ing has been already receiver over another peering session associated with same Node-ID then the receiving LSR MUST send a Label Release to the peering ses= sion with statuc code"
How a LSR could know the FEC mapping information from another instance? Do you = mean the two instance need to synchronize FEC mapping information?=

 

[Pranjal] One way to think is  as follows – let=1B$B!G=1B(Js say that detection of multi-instance peeri= ng is implemented as in Section 3. Then receiving system would know about the sessions terminati= ng

in same remote peering system. So the receiving system can create a group/bundle id internally for all such || sessions and keep the FEC-label mappings also in the database. If there is = a

collision of Fec label mappings in the group-id database then label release can be sent, keeping the first one int= act.



Thanks
Lizhong

"Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com> wrote 2012/08/31 01:00:53:

> 2. For LDP multiple instance, is it allowed for duplicated FEC
> between two instance?
>  
> [Pranjal] Duplicated FECs won=1B$B!G=1B(Jt be allowed. The parallel session= s
> between two peering systems needs to be disjoint with respect to the > working set
> – the FECs. This needs to be ensured thru various FEC specific <= br> > session capabilities. Each || session must advertise disjoint FEC
> capabilities. Section
> 2.1.1 explains the use of LDP session capabilities (RFC5561) to keep
> the FEC distribution mutually exclusive. What criteria to be used
> for segregation
> of FECs are to be decided on case to case basic. This draft provides
> the fundamental building block for control plane fate separation.
[Lizhong] Then does the LDP multiple instance in this draft does not include the VRF = case? It is better to explicit describe this, otherwise it is confusing. In the V= RF case, the FEC will be duplicated between different instances.=

>
> 3. If duplicated FECs are possible between two instance, receiving > same label mapping from parallel multi-lsr peering sessions could
> not interpret as loop, right?
>  
> [Pranjal] Duplicated FECs are not allowed across . But what if a
> peering system misbehaves or peering system not supporting the
> solution (thus agnostic
> Of the fact that a few sessions are terminated in same peering
> system) leaks FECs on all || sessions? That may result in a loop for > some applications
> and =1B$B!H=1B(JSection 3. Detection of multi-instance peering=1B$B!I= =1B(J addresses that
> issue.  It lets a system aware of || sessions and thus can take <= br> > necessary actions.
[Lizhong] If the FEC set (identified by capability) is totally disjoint between two instance, it could be simply discard the FEC label mapping if not match capability to avoid loop, why we still need Node-ID TLV=1B$B!)=1B(J<= /font>

>
> 4. In case 1~4, one interface will serve multiple instance, I guess, > the interface you refer is physical interface, and when sharing one > physical interface, then one sub-interface for each instance is
> still required, right? In my understanding, one IP interface could > not be shared by multiple LDP instance, otherwise how to treat the > prefix of that interface.

> [Pranjal] I won=1B$B!G=1B(Jt view it as sub-interface since all instances a= re
> running in same FEC database. So if we think from a =1B$B!H=1B(Jvirtua= l router=1B$B!I=1B(J
> point of view (each
> Virtual Router is separated across all verticals in RIB/LFIB/FIB and > self-sufficient) then all the multiple LSR instances would be
> running within same
> Virtual Router and thus can share interfaces assigned to that
> Virtual Router. Although the draft does not prevent usage of same
> Interface across all LSRs
> in practice it is desirable to fate separate the physical topology > to achieve separation across entire vertical. Separation of physical > topology can be
> achieved by LDP Multi-topology that synchronizes IGP and LDP=1B$B!G=1B= (Js view (
> http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-04) or > by using hello
> adjacency capabilities at LDP level (http://tools.ietf.
> org/html/draft-pdutta-mpls-ldp-adj-capability-00).
>  
>
> Hope to see your clarification. Thanks.
>
> Lizhong
>  
>
> Loa Andersson <loa@pi.= nu> wrote 2012/08/29 17:10:01:
>
> > Kamran. Eric and Lizhong,
> >
> > You have been selected as an MPLS Review team reviewers for
> > draft-pdutta-mpls-multi-ldp-instance-00.txt.
> >
> > Note to authors: You have been CC=1B$B!G=1B(Jd on this email so t= hat 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 knowin= g whether
> > the document is ready to be considered for WG adoption (ie, it do= esn=1B$B!G=1B(Jt
> > 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<= br> > > secretary, and CC=1B$B!G=1B(Jd to the MPLS WG email list. If nece= ssary, comments
> > may be sent privately to only the WG chairs.
> >
> > Are you able to review this draft by Sep 13, 2012?
> >
> > Thanks, Loa
> > (as MPLS WG chair)
> > --
> >
> >
> > Loa Andersson  =                       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
> >                   &n= bsp;                      = ;     +46 767 72 92 13
> >

--_000_C584046466ED224CA92C1BC3313B963E13F0B8CAA5INBANSXCHMBSA_-- From pranjal.dutta@alcatel-lucent.com Fri Aug 31 10: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 9A11121F8624 for ; Fri, 31 Aug 2012 10:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.434 X-Spam-Level: X-Spam-Status: No, score=-9.434 tagged_above=-999 required=5 tests=[AWL=1.164, 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 LR-rDCWLDjEr for ; Fri, 31 Aug 2012 10:38:57 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id A75AE21F8622 for ; Fri, 31 Aug 2012 10:38:57 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q7VHcigO025712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 31 Aug 2012 12:38:46 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7VHcgXt003180 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 31 Aug 2012 23:08:42 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Fri, 31 Aug 2012 23:08:41 +0530 From: "Dutta, Pranjal K (Pranjal)" To: "Dutta, Pranjal K (Pranjal)" , Lizhong Jin Date: Fri, 31 Aug 2012 23:08:39 +0530 Thread-Topic: [mpls] MPLS-RT review of draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org Thread-Index: Ac2HRCmookePD4nRTjyBtRrdU5Kr7AAWAMTQAABcL4A= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C584046466ED224CA92C1BC3313B963E13F0B8CAA6INBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org 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, 31 Aug 2012 17:39:01 -0000 --_000_C584046466ED224CA92C1BC3313B963E13F0B8CAA6INBANSXCHMBSA_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi Lizhong, I think I didn=1B$B!G=1B(Bt clarify on - =1B$B!H=1B(BD= o you mean the two instance need to synchronize FEC mapping information=1B$= B!I=1B(B. The multi-instance peering that we described about Is a little different from multi-instance IGPs. In multi-instance LDP case = by default the FEC database would be shared in the sense that all label map= ping would share the same global label space and thus following is possible/desirable. System A = System B System C LSR-A1----------------------------LSR-B1 X= LSR-B3--------------------------LSR-C1 LSR-A2 ---------------------------LSR-B2 X= LSR-B4--------------------------LSR-C2 There can be a seamless LSP/Tunnel between System A an= d System C for FEC F1. C->B label mapping L1 is exchanged using B3-C1 LSR t= uples and B->A label mapping L2 is exchanged using B2-A2 LSR tuples. This is because = the FEC-Label mapping database continue to exist in system B in same way as it does today. There would be only one FEC F1 in the LIB : = F1 --> egress label L1 (Local LSR B3---Remote LSR C1) = --->ingress label L2 (Local LSR B2---Remote LSR A2) The X connect at system B is L1->L2 Thanks, Pranjal ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Dut= ta, Pranjal K (Pranjal) Sent: Friday, August 31, 2012 10:22 AM To: Lizhong Jin Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-pdutta-mpls-multi-ldp-= instance@tools.ietf.org Subject: Re: [mpls] MPLS-RT review of draft-pdutta-mpls-multi-ldp-instance@= tools.ietf.org Hi Lizhong, Please refer my answers inline. Thanks, Pranjal ________________________________ From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] Sent: Thursday, August 30, 2012 11:42 PM To: Dutta, Pranjal K (Pranjal) Cc: draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org; mpls@ietf.org; mpl= s-chairs@tools.ietf.org Subject: RE: [mpls] MPLS-RT review of draft-pdutta-mpls-multi-ldp-instance@= tools.ietf.org Hi Pranjal, Thanks for the clarification, much clear than before for me now. Please see= inline for addtional comments. One more question for section 3. "When a LSR receives a FEC label mapping from a peering session but same FE= C mapping has been already receiver over another peering session associated= with same Node-ID then the receiving LSR MUST send a Label Release to the = peering session with statuc code" How a LSR could know the FEC mapping information from another instance? Do = you mean the two instance need to synchronize FEC mapping information? [Pranjal] One way to think is as follows - let=1B$B!G=1B(Bs say that detec= tion of multi-instance peering is implemented as in Section 3. Then receivi= ng system would know about the sessions terminating in same remote peering system. So the receiving system can create a group/b= undle id internally for all such || sessions and keep the FEC-label mapping= s also in the database. If there is a collision of Fec label mappings in the group-id database then label release= can be sent, keeping the first one intact. Thanks Lizhong "Dutta, Pranjal K (Pranjal)" wrote 2012/= 08/31 01:00:53: > 2. For LDP multiple instance, is it allowed for duplicated FEC > between two instance? > > [Pranjal] Duplicated FECs won=1B$B!G=1B(Bt be allowed. The parallel sessi= ons > between two peering systems needs to be disjoint with respect to the > working set > - the FECs. This needs to be ensured thru various FEC specific > session capabilities. Each || session must advertise disjoint FEC > capabilities. Section > 2.1.1 explains the use of LDP session capabilities (RFC5561) to keep > the FEC distribution mutually exclusive. What criteria to be used > for segregation > of FECs are to be decided on case to case basic. This draft provides > the fundamental building block for control plane fate separation. [Lizhong] Then does the LDP multiple instance in this draft does not includ= e the VRF case? It is better to explicit describe this, otherwise it is con= fusing. In the VRF case, the FEC will be duplicated between different insta= nces. > > 3. If duplicated FECs are possible between two instance, receiving > same label mapping from parallel multi-lsr peering sessions could > not interpret as loop, right? > > [Pranjal] Duplicated FECs are not allowed across . But what if a > peering system misbehaves or peering system not supporting the > solution (thus agnostic > Of the fact that a few sessions are terminated in same peering > system) leaks FECs on all || sessions? That may result in a loop for > some applications > and =1B$B!H=1B(BSection 3. Detection of multi-instance peering=1B$B!I=1B(= B addresses that > issue. It lets a system aware of || sessions and thus can take > necessary actions. [Lizhong] If the FEC set (identified by capability) is totally disjoint bet= ween two instance, it could be simply discard the FEC label mapping if not = match capability to avoid loop, why we still need Node-ID TLV=1B$B!)=1B(B > > 4. In case 1~4, one interface will serve multiple instance, I guess, > the interface you refer is physical interface, and when sharing one > physical interface, then one sub-interface for each instance is > still required, right? In my understanding, one IP interface could > not be shared by multiple LDP instance, otherwise how to treat the > prefix of that interface. > [Pranjal] I won=1B$B!G=1B(Bt view it as sub-interface since all instances= are > running in same FEC database. So if we think from a =1B$B!H=1B(Bvirtual r= outer=1B$B!I=1B(B > point of view (each > Virtual Router is separated across all verticals in RIB/LFIB/FIB and > self-sufficient) then all the multiple LSR instances would be > running within same > Virtual Router and thus can share interfaces assigned to that > Virtual Router. Although the draft does not prevent usage of same > Interface across all LSRs > in practice it is desirable to fate separate the physical topology > to achieve separation across entire vertical. Separation of physical > topology can be > achieved by LDP Multi-topology that synchronizes IGP and LDP=1B$B!G=1B(Bs= view ( > http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-04) or > by using hello > adjacency capabilities at LDP level (http://tools.ietf. > org/html/draft-pdutta-mpls-ldp-adj-capability-00). > > > Hope to see your clarification. Thanks. > > Lizhong > > > Loa Andersson wrote 2012/08/29 17:10:01: > > > Kamran. Eric and Lizhong, > > > > You have been selected as an MPLS Review team reviewers for > > draft-pdutta-mpls-multi-ldp-instance-00.txt. > > > > Note to authors: You have been CC=1B$B!G=1B(Bd on this email so that yo= u 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 usefu= l > > (ie, is it likely to be actually useful in operational networks), and i= s > > the document technically sound? We are interested in knowing whether > > the document is ready to be considered for WG adoption (ie, it doesn=1B= $B!G=1B(Bt > > 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=1B$B!G=1B(Bd 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 Sep 13, 2012? > > > > Thanks, Loa > > (as MPLS WG 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 > > --_000_C584046466ED224CA92C1BC3313B963E13F0B8CAA6INBANSXCHMBSA_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Hi Lizhong,

      &n= bsp;            = ;  I think I didn=1B$B!G=1B(Bt clarify on – =1B$B!H=1B(BDo you mean the two instance n= eed to synchronize FEC mapping information=1B$B!I=1B(B. The multi-instance peering= that we described about

Is a little different from multi-instance IGPs. In multi-instance LDP case by default the FEC database would be shared in the sense that all label mapping would share the same =

global label space and thus following is possible/desira= ble.

 

         &n= bsp;            = ;    System A            &n= bsp;            = ;            &n= bsp;   System B            &n= bsp;            = ;        System C

         &n= bsp;            = ;        LSR-A1---------------------------= -LSR-B1    X    LSR-B3--------------------------LSR-C1

         &n= bsp;            = ;        LSR-A2 ---------------------------LSR-B2    X  &nb= sp; LSR-B4--------------------------LSR-C2

 

 

         &n= bsp;           There can be a seamless LSP/Tunnel between System A and System C for FEC F1= . C->B label mapping L1 is exchanged using B3-C1 LSR tuples and =

B->A label mapping L2 is exchanged using B2-A2 LSR tuples. This is because the FEC-Label mapping database continue to exist in system B in same

way as it does today. There would be only one FEC F1 in = the LIB :

 

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;     F1  --> egress label L1 (Local LSR B3---Remote LSR C1)

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;           -àingress label L2 (Local LSR B2---Remote LSR A2)

 

         &n= bsp;           The X connect at system B is L1->L2

         &n= bsp;            = ;          

 

 

Thanks,

Pranjal

From: mpls-bou= nces@ietf.org [mailto:mpls-bounces@ietf.org] On Behal= f Of Dutta, Pranjal K (Pranjal)
Sent: Friday, August 31, 201= 2 10:22 AM
To: Lizhong Jin
Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org
Subject: Re: [mpls] MPLS-RT = review of draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org

 

Hi Lizhong,

      &n= bsp;            = ;     Please refer my answers inline.

Thanks,

Pranjal

 

From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] Sent: Thursday, August 30, 2= 012 11:42 PM
To: Dutta, Pranjal K (Pranjal)
Cc: draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org; mpls@ietf.org; mpls-chairs@tools.ietf.org
Subject: RE: [mpls] MPLS-RT = review of draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org

 


Hi Pranjal,
Thanks for the clarification, much clear than before for me now. Please see inline= for addtional comments.

One more question for section 3.
"When a LSR receives a FEC label mapping from a peering session but same FEC mapp= ing has been already receiver over another peering session associated with same Node-ID then the receiving LSR MUST send a Label Release to the peering ses= sion with statuc code"
How a LSR could know the FEC mapping information from another instance? Do you me= an the two instance need to synchronize FEC mapping information?=

 

[Pranjal] One way to think is  as= follows – let=1B$B!G=1B(Bs say that detection of multi-instance peering is im= plemented as in Section 3. Then receiving system would know about the sessions terminating<= o:p>

in same remote peering system. So the receiving system can create a group/bundle id internally for all such || sessions and keep the FEC-label mappings also in the database. If there is = a

collision of Fec label mappings in the group-id database then label release can be sent, keeping the first one int= act.



Thanks
Lizhong

"Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com> wrote 2012/08/31 01:00:53:

> 2. For LDP multiple instance, is it allowed for duplicated FEC
> between two instance?
>  
> [Pranjal] Duplicated FECs won=1B$B!G=1B(Bt be allowed. The parallel session= s
> between two peering systems needs to be disjoint with respect to the > working set
> – the FECs. This needs to be ensured thru various FEC specific <= br> > session capabilities. Each || session must advertise disjoint FEC
> capabilities. Section
> 2.1.1 explains the use of LDP session capabilities (RFC5561) to keep
> the FEC distribution mutually exclusive. What criteria to be used
> for segregation
> of FECs are to be decided on case to case basic. This draft provides
> the fundamental building block for control plane fate separation.
[Lizhong] Then does the LDP multiple instance in this draft does not include the VRF case? It is better to explicit describe this, otherwise it is confusing. In= the VRF case, the FEC will be duplicated between different instances.

>
> 3. If duplicated FECs are possible between two instance, receiving > same label mapping from parallel multi-lsr peering sessions could
> not interpret as loop, right?
>  
> [Pranjal] Duplicated FECs are not allowed across . But what if a
> peering system misbehaves or peering system not supporting the
> solution (thus agnostic
> Of the fact that a few sessions are terminated in same peering
> system) leaks FECs on all || sessions? That may result in a loop for > some applications
> and =1B$B!H=1B(BSection 3. Detection of multi-instance peering=1B$B!I= =1B(B addresses that
> issue.  It lets a system aware of || sessions and thus can take <= br> > necessary actions.
[Lizhong] If the FEC set (identified by capability) is totally disjoint between two instance, it could be simply discard the FEC label mapping if not match capability to avoid loop, why we still need Node-ID TLV=1B$B!)=1B(B<= /font>

>
> 4. In case 1~4, one interface will serve multiple instance, I guess, > the interface you refer is physical interface, and when sharing one > physical interface, then one sub-interface for each instance is
> still required, right? In my understanding, one IP interface could > not be shared by multiple LDP instance, otherwise how to treat the > prefix of that interface.

> [Pranjal] I won=1B$B!G=1B(Bt view it as sub-interface since all instances a= re
> running in same FEC database. So if we think from a =1B$B!H=1B(Bvirtua= l router=1B$B!I=1B(B
> point of view (each
> Virtual Router is separated across all verticals in RIB/LFIB/FIB and > self-sufficient) then all the multiple LSR instances would be
> running within same
> Virtual Router and thus can share interfaces assigned to that
> Virtual Router. Although the draft does not prevent usage of same
> Interface across all LSRs
> in practice it is desirable to fate separate the physical topology > to achieve separation across entire vertical. Separation of physical > topology can be
> achieved by LDP Multi-topology that synchronizes IGP and LDP=1B$B!G=1B= (Bs view (
> http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-04) or > by using hello
> adjacency capabilities at LDP level (http://tools.ietf.
> org/html/draft-pdutta-mpls-ldp-adj-capability-00).
>  
>
> Hope to see your clarification. Thanks.
>
> Lizhong
>  
>
> Loa Andersson <loa@pi.= nu> wrote 2012/08/29 17:10:01:
>
> > Kamran. Eric and Lizhong,
> >
> > You have been selected as an MPLS Review team reviewers for
> > draft-pdutta-mpls-multi-ldp-instance-00.txt.
> >
> > Note to authors: You have been CC=1B$B!G=1B(Bd on this email so t= hat 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 knowin= g whether
> > the document is ready to be considered for WG adoption (ie, it doesn=1B$B!G=1B(Bt
> > 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<= br> > > secretary, and CC=1B$B!G=1B(Bd to the MPLS WG email list. If nece= ssary, comments
> > may be sent privately to only the WG chairs.
> >
> > Are you able to review this draft by Sep 13, 2012?
> >
> > Thanks, Loa
> > (as MPLS WG chair)
> > --
> >
> >
> > Loa Andersson                        = ; 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
> >                   &n= bsp;                      = ;     +46 767 72 92 13
> >

--_000_C584046466ED224CA92C1BC3313B963E13F0B8CAA6INBANSXCHMBSA_--