From fanpeng@chinamobile.com Mon Apr 1 03:54:22 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D762421F88EF for ; Mon, 1 Apr 2013 03:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.224 X-Spam-Level: ** X-Spam-Status: No, score=2.224 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RELAY_IS_221=2.222] 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 I5w0Li1l7Q6S for ; Mon, 1 Apr 2013 03:54:20 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 8E16C21F88E8 for ; Mon, 1 Apr 2013 03:54:19 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee2515967381b4-891b4; Mon, 01 Apr 2013 18:53:45 +0800 (CST) X-RM-TRANSID: 2ee2515967381b4-891b4 Received: from X6X8D79D8F49E2 (unknown[10.2.43.115]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee35159673986e-c651e; Mon, 01 Apr 2013 18:53:45 +0800 (CST) X-RM-TRANSID: 2ee35159673986e-c651e From: "Fan Peng" To: Date: Mon, 1 Apr 2013 18:54:12 +0800 Message-ID: <006c01ce2ec7$3ee2e5b0$bca8b110$@chinamobile.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006D_01CE2F0A.4D086FA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4uxL4KupRh6XCgSFOBqD83EaTZBw== Content-Language: zh-cn Subject: Re: [CCAMP] poll on making draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05 aWG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 10:54:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_006D_01CE2F0A.4D086FA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I would like to support this document. FP ------=_NextPart_000_006D_01CE2F0A.4D086FA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would like = to support this document.

 

FP<= /span>

------=_NextPart_000_006D_01CE2F0A.4D086FA0-- From francesco.fondelli@gmail.com Mon Apr 1 09:19:35 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9B31F0C74 for ; Mon, 1 Apr 2013 09:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 Tt+Wm9Sute-r for ; Mon, 1 Apr 2013 09:19:35 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id DE85D1F0D14 for ; Mon, 1 Apr 2013 09:19:34 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id u12so1874292wey.5 for ; Mon, 01 Apr 2013 09:19:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=qAqZ6jsmGfe2nHd7iO/YBquDlCeXwvqnLYz2KArsko8=; b=Ioio3xgyo6+h+f3DIfbNPduOlI4bityMHrtwJD48+pn/+f3IWuLD5iTjxiwJhrJCrL z1WoL4EbIYp6YpiwTDyMAo65+Mi85Lc7jd4St/SwAG7WFHoEvSGpvTOOgOT97AV4utjB yuB6Tes14ir0V9usgcddzWAAhGBhUJn1iAXQ61IJ1rcvX1L40UZy4XI625KATzfvSpBy fE+e0c629g89N3MxO05iLI48EpQnFlqhx9NoG0sNZI1IhenCRhf5Bm5Dldr64ejN3K7H tiZ2L2wJnKIFrzYRZ0Aw74SLbQ3X0YjhASApW8FmcEI/j5eaz96Y9iT6hc2euYnr0M+t +svg== MIME-Version: 1.0 X-Received: by 10.195.12.133 with SMTP id eq5mr16379068wjd.52.1364833173882; Mon, 01 Apr 2013 09:19:33 -0700 (PDT) Received: by 10.194.22.36 with HTTP; Mon, 1 Apr 2013 09:19:33 -0700 (PDT) Date: Mon, 1 Apr 2013 18:19:33 +0200 Message-ID: From: Francesco Fondelli To: "ccamp@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 16:19:36 -0000 quoting item 15, from www.ietf.org/proceedings/86/minutes/minutes-86-ccamp Lou Berger: I think you misunderstood my comment from the last meeting. You should look at leveraging the OAM configuration work which came after the earlier versions of your draft. Zafar Ali: this is applicable to multiple technologies. Lou Berger: yes, the OAM configuration framework is also applicable to multiple technologies. You need a strong reason not to follow the WG in this area. Please look at the OAM configuration document [draft-ietf-ccamp-oam-configuration-fwk] and either follow it or state why your work is justified in not following the existing WG solution in this area. --- Hi all, the OAM configuration framework [1] is about OAM. Therefore, it is used in order to signal OAM functionalities: CC/CV and PM/FM in MPLS-TP [2], CC/CV TTI/SAPI/DAPI in SONET/SDH/OTN [3]... while our draft [4] is about *protection switching*. HOFF, WTR and SNC sub-type are protection switching parameters. I believe HOFF, WTR and SNC sub-type are outside of the OAM configuration framework scope and should be signaled as any other protection switching params (i.e. via PROTECTION object). I hope this answer Lou question reported above (item 15, IETF 86 ccamp minutes). Authors of [4] would like to understand WG's view about this point and are soliciting for comments. thank you ciao FF [1] http://tools.ietf.org/html/draft-ietf-ccamp-oam-configuration-fwk-09 [2] http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-11 [3] http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-05 [4] http://tools.ietf.org/html/draft-takacs-ccamp-revertive-ps-08 From gregory.mirsky@ericsson.com Mon Apr 1 10:26:42 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA0C1F0D12 for ; Mon, 1 Apr 2013 10:26:42 -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 l4IjGQP5mW9Y for ; Mon, 1 Apr 2013 10:26:41 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 50EC71F0D0F for ; Mon, 1 Apr 2013 10:26:41 -0700 (PDT) X-AuditID: c6180641-b7faf6d00000096b-62-5159c350336c Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 06.03.02411.053C9515; Mon, 1 Apr 2013 19:26:40 +0200 (CEST) Received: from EUSAAMB106.ericsson.se ([147.117.188.123]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0318.004; Mon, 1 Apr 2013 13:26:39 -0400 From: Gregory Mirsky To: Lou Berger , "ccamp@ietf.org" Thread-Topic: [CCAMP] poll on making draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05 a WG document Thread-Index: AQHOK77gydyWrfFX+EOkNO0nfWgFU5jBpJAQ Date: Mon, 1 Apr 2013 17:26:37 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B47D0A9@eusaamb106.ericsson.se> References: <51545098.4060609@labn.net> In-Reply-To: <51545098.4060609@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUyuXRPrG7A4chAg7eXbSyezLnBYtHR/JbF gcljyZKfTB4fNjWzBTBFcdmkpOZklqUW6dslcGXMWPGdsaCJveJnz2LWBsanrF2MnBwSAiYS R9duZYKwxSQu3FvPBmILCRxllGjYIdDFyAVkL2OUaGy5yAKSYBMwknixsYe9i5GDQ0TAReLJ +lgQU1ggVuL9ZSWIaJxEW382SLEIUPGT+Z/YQWwWARWJjlVfWEBKeAV8Ja5vtoFYpC7x8shk RhCbU0BD4tGLh2A2I9Ax30+tATuMWUBc4taT+VBHCkgs2XOeGcIWlXj5+B/UI8oSS57sZ4Go 15FYsPsTG4StLbFs4Wuwel4BQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKAkWUVI0dpcWpZbrqR 4SZGYBQck2Bz3MG44JPlIUZpDhYlcd5Q1wsBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhhL 3T1iVwneyma1k3w90/XdhVXe99kWGa0qt9giu5n92q5pd95mz/wUadPDzd9xYfObh6ckDxau vtATl/7lQan7cu2gCNsppVaCcXsTPoWI9bzf8ELdRHGXaeyLJ1unRGyu+39Ze1JO2o2tm4PL rqcIK87/yvY18fhzDc89iQsWLrv2Q9BQQYldiaU4I9FQi7moOBEA5OU1o1ACAAA= Subject: Re: [CCAMP] poll on making draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05 a WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 17:26:42 -0000 Yes/support Regards, Greg=20 -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= ou Berger Sent: Thursday, March 28, 2013 7:16 AM To: ccamp@ietf.org Subject: [CCAMP] poll on making draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05 a= WG document All, This is to start a two week poll on making draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05 a ccamp working group document. P= lease send mail to the list indicating "yes/support" or "no/do not support". If indicating no, please state your technical rese= rvations with the document. All authors have stated that they are not aware of any IPR that applies to = the draft. The poll ends Thursday April 11. Much thanks, Lou (and Deborah) _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From db3546@att.com Mon Apr 1 11:06:43 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA6B21E804A for ; Mon, 1 Apr 2013 11:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 ombaTPmhM1kw for ; Mon, 1 Apr 2013 11:06:42 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFF61F0C74 for ; Mon, 1 Apr 2013 11:06:42 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 2bcc9515.73f9c940.244235.00-565.677972.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 01 Apr 2013 18:06:42 +0000 (UTC) X-MXL-Hash: 5159ccb276f52454-86f260e99db8048020301e0178ccda3d6c6095aa Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id eacc9515.0.244196.00-407.677853.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 01 Apr 2013 18:06:38 +0000 (UTC) X-MXL-Hash: 5159ccae0a1b8688-6d74c39b4fc360bf58c8e1bba3404937813fd6fe Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r31I6b9i032645; Mon, 1 Apr 2013 14:06:37 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r31I6UlP032468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Apr 2013 14:06:32 -0400 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Mon, 1 Apr 2013 19:06:19 +0100 Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.02.0342.003; Mon, 1 Apr 2013 14:06:19 -0400 From: "BRUNGARD, DEBORAH A" To: Francesco Fondelli , "ccamp@ietf.org" Thread-Topic: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps Thread-Index: AQHOLvS35E5gvsW8qk+nQPJ9P69loZjBomHw Date: Mon, 1 Apr 2013 18:06:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=DLo4FVxb c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=RWEAq7CW3jcA:10 a=OIZjW_EDwrwA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=Axtq_jpKRe8A:10 a=48vgC7mUAAAA:8 a=T2tGs_0Zn0oO0D] X-AnalysisOut: [xfRvMA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10] Subject: Re: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 18:06:43 -0000 Hi Francesco, While these may be protection switching parameters, this draft is about con= figuration of these parameters. Protection switching provisioning has alway= s been treated as a common equipment management functionality - same as per= formance management and fault management (refer to G.7710 section 8). So it= is in scope of OAM configuration. CCAMP's OAM configuration work has been = focused on PM and FM but it is generally applicable (hopefully) to any equi= pment management configuration. Lou's comment is that the WG has chosen the approach used in the OAM framew= ork document for configuration. Instead of updating the protection object a= t this time as your draft proposes, the question is have you considered usi= ng the OAM configuration TLV? First, we need to understand why you have cho= sen to not use this approach. Then we can discuss pros and cons. BR- Deborah -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of F= rancesco Fondelli Sent: Monday, April 01, 2013 12:20 PM To: ccamp@ietf.org Subject: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps quoting item 15, from www.ietf.org/proceedings/86/minutes/minutes-86-ccamp Lou Berger: I think you misunderstood my comment from the last meeting. You should look at leveraging the OAM configuration work which came after the earlier versions of your draft. Zafar Ali: this is applicable to multiple technologies. Lou Berger: yes, the OAM configuration framework is also applicable to multiple technologies. You need a strong reason not to follow the WG in this area. Please look at the OAM configuration document [draft-ietf-ccamp-oam-configuration-fwk] and either follow it or state why your work is justified in not following the existing WG solution in this area. --- Hi all, the OAM configuration framework [1] is about OAM. Therefore, it is used = in order to signal OAM functionalities: CC/CV and PM/FM in MPLS-TP [2], CC/CV TTI/SAPI/DAPI in SONET/SDH/OTN [3]... while our draft [4] is about *protect= ion switching*. HOFF, WTR and SNC sub-type are protection switching parameters= . I believe HOFF, WTR and SNC sub-type are outside of the OAM configuration framework scope and should be signaled as any other protection switching params (i.e. via PROTECTION object). I hope this answer Lou question reported above (item 15, IETF 86 ccamp minutes). Authors of [4] would like to understand WG's view about this poi= nt and are soliciting for comments. thank you ciao FF [1] http://tools.ietf.org/html/draft-ietf-ccamp-oam-configuration-fwk-09 [2] http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-11 [3] http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-05 [4] http://tools.ietf.org/html/draft-takacs-ccamp-revertive-ps-08 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From daniele.ceccarelli@ericsson.com Tue Apr 2 00:13:09 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6FF521F8499 for ; Tue, 2 Apr 2013 00:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 kSyKp+hl7NHS for ; Tue, 2 Apr 2013 00:13:09 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 893E721F8D31 for ; Tue, 2 Apr 2013 00:13:07 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-6b-515a84fbbb2f Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 29.1C.19728.BF48A515; Tue, 2 Apr 2013 09:12:59 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.208]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0318.004; Tue, 2 Apr 2013 09:12:57 +0200 From: Daniele Ceccarelli To: Lou Berger , "ccamp@ietf.org" Thread-Topic: [CCAMP] poll on making draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05 a WG document Thread-Index: AQHOK77Xe3Upjd7Op0CuAjlOx/DT8ZjCi3uQ Date: Tue, 2 Apr 2013 07:12:58 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE480A8046@ESESSMB301.ericsson.se> References: <51545098.4060609@labn.net> In-Reply-To: <51545098.4060609@labn.net> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUyM+Jvre7vlqhAg3MbhCyezLnBYtHR/JbF gcljyZKfTB4fNjWzBTBFcdmkpOZklqUW6dslcGXMnPiesWA+e8X718/YGxg72boYOTkkBEwk Hu3cxAJhi0lcuLceKM7FISRwmFGiY1o3K4SzmFFixc9zQA4HB5uAlcSTQz4gpoiAi8ST9bEg prBArMT7y0oQ0TiJtv5skIkiAkYSPy69ZwKxWQRUJG5P28IIYvMKeEv8WvYB7AIhAXWJl0cm g8U5BTQkHr14CGYzCshKTNi9CMxmFhCXuPVkPhPElQISS/acZ4awRSVePv7HCmErSuw8284M Ua8ncWPqFDYIW1ti2cLXzBB7BSVOznzCMoFRdBaSsbOQtMxC0jILScsCRpZVjOy5iZk56eVG mxiBUXBwy2/VHYx3zokcYpTmYFES5w13vRAgJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgTEo 8Ug/i1rfjYWqOXyz8zzy82+IqqfaGuwQFVW8E7C7kmXCih7fxJXsp9JVC18d27LR31rpUMaP fzUbFxVKZ0cUvr1Q9eTK+fVPmDtv+95vvpPo7+BXYCuy7tCZCyaS8bt5Xyw8827HgVkvZVjv To4RWPJmfmvLMscut1NhYlesrkRmbov35FRiKc5INNRiLipOBAD+pz9nUAIAAA== Subject: Re: [CCAMP] poll on making draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05 a WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 07:13:09 -0000 Yes/support BR Daniele=20 >-----Original Message----- >From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]=20 >On Behalf Of Lou Berger >Sent: gioved=EC 28 marzo 2013 15.16 >To: ccamp@ietf.org >Subject: [CCAMP] poll on making=20 >draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05 a WG document > >All, > >This is to start a two week poll on making >draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05 a ccamp working=20 >group document. Please send mail to the list indicating "yes/support" >or "no/do not support". If indicating no, please state your=20 >technical reservations with the document. > >All authors have stated that they are not aware of any IPR=20 >that applies to the draft. > >The poll ends Thursday April 11. > >Much thanks, >Lou (and Deborah) > > >_______________________________________________ >CCAMP mailing list >CCAMP@ietf.org >https://www.ietf.org/mailman/listinfo/ccamp >= From zhang.xian@huawei.com Tue Apr 2 01:02:24 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E796021F9840 for ; Tue, 2 Apr 2013 01:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 tmAGFMFlf7rK for ; Tue, 2 Apr 2013 01:02:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB4821F984A for ; Tue, 2 Apr 2013 01:02:23 -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 ARI21142; Tue, 02 Apr 2013 08:02:22 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 2 Apr 2013 09:02:03 +0100 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 2 Apr 2013 16:02:11 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.3.139]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.007; Tue, 2 Apr 2013 16:02:06 +0800 From: "Zhangxian (Xian)" To: Lou Berger , "ccamp@ietf.org" Thread-Topic: [CCAMP] poll on making draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05 a WG document Thread-Index: AQHOK77ZSXpA5WsA+ky9oDLpsT/DVpjCmOcA Date: Tue, 2 Apr 2013 08:02:06 +0000 Message-ID: References: <51545098.4060609@labn.net> In-Reply-To: <51545098.4060609@labn.net> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [CCAMP] poll on making draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05 a WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 08:02:25 -0000 WWVzL3N1cHBvcnQuDQoNClJlZ2FyZHMsDQpYaWFuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIExvdSBCZXJnZXINClNlbnQ6IDIwMTPE6jPUwjI4yNUgMjI6 MTYNClRvOiBjY2FtcEBpZXRmLm9yZw0KU3ViamVjdDogW0NDQU1QXSBwb2xsIG9uIG1ha2luZyBk cmFmdC1kb25nLWNjYW1wLXJzdnAtdGUtbXBscy10cC1saS1sYi0wNSBhIFdHIGRvY3VtZW50DQoN CkFsbCwNCg0KVGhpcyBpcyB0byBzdGFydCBhIHR3byB3ZWVrIHBvbGwgb24gbWFraW5nDQpkcmFm dC1kb25nLWNjYW1wLXJzdnAtdGUtbXBscy10cC1saS1sYi0wNSBhIGNjYW1wIHdvcmtpbmcNCmdy b3VwIGRvY3VtZW50LiBQbGVhc2Ugc2VuZCBtYWlsIHRvIHRoZSBsaXN0IGluZGljYXRpbmcgInll cy9zdXBwb3J0Ig0Kb3IgIm5vL2RvIG5vdCBzdXBwb3J0Ii4gIElmIGluZGljYXRpbmcgbm8sIHBs ZWFzZSBzdGF0ZSB5b3VyIHRlY2huaWNhbA0KcmVzZXJ2YXRpb25zIHdpdGggdGhlIGRvY3VtZW50 Lg0KDQpBbGwgYXV0aG9ycyBoYXZlIHN0YXRlZCB0aGF0IHRoZXkgYXJlIG5vdCBhd2FyZSBvZiBh bnkgSVBSIHRoYXQgYXBwbGllcw0KdG8gdGhlIGRyYWZ0Lg0KDQpUaGUgcG9sbCBlbmRzIFRodXJz ZGF5IEFwcmlsIDExLg0KDQpNdWNoIHRoYW5rcywNCkxvdSAoYW5kIERlYm9yYWgpDQoNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNDQU1QIG1haWxp bmcgbGlzdA0KQ0NBTVBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vY2NhbXANCg== From mach.chen@huawei.com Tue Apr 2 01:03:34 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069E521F86B9 for ; Tue, 2 Apr 2013 01:03:34 -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 uHV9Jxiiiqxm for ; Tue, 2 Apr 2013 01:03:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E69D021F9832 for ; Tue, 2 Apr 2013 01:03:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APZ39571; Tue, 02 Apr 2013 08:03:31 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 2 Apr 2013 09:03:21 +0100 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 2 Apr 2013 09:03:28 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.247]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.007; Tue, 2 Apr 2013 16:03:22 +0800 From: Mach Chen To: Lou Berger , "ccamp@ietf.org" Thread-Topic: [CCAMP] poll on making draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05 a WG document Thread-Index: AQHOK77ZLNoY7bEoXkGUJlovYZG64pjCmPvg Date: Tue, 2 Apr 2013 08:03:22 +0000 Message-ID: References: <51545098.4060609@labn.net> In-Reply-To: <51545098.4060609@labn.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [CCAMP] poll on making draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05 a WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 08:03:34 -0000 Yes/Support (as co-author) Best regards, Mach > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Lou Berger > Sent: Thursday, March 28, 2013 10:16 PM > To: ccamp@ietf.org > Subject: [CCAMP] poll on making draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05= a > WG document >=20 > All, >=20 > This is to start a two week poll on making > draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05 a ccamp working > group document. Please send mail to the list indicating "yes/support" > or "no/do not support". If indicating no, please state your technical > reservations with the document. >=20 > All authors have stated that they are not aware of any IPR that applies > to the draft. >=20 > The poll ends Thursday April 11. >=20 > Much thanks, > Lou (and Deborah) >=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From zhangfatai@huawei.com Tue Apr 2 01:11:12 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D89A21F9809 for ; Tue, 2 Apr 2013 01:11:12 -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 psq7SF+v5kl7 for ; Tue, 2 Apr 2013 01:11:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B2BBF21F97F8 for ; Tue, 2 Apr 2013 01:11:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APZ40382; Tue, 02 Apr 2013 08:11:04 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 2 Apr 2013 09:10:51 +0100 Received: from SZXEML456-HUB.china.huawei.com (10.82.67.199) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 2 Apr 2013 09:10:59 +0100 Received: from SZXEML552-MBS.china.huawei.com ([169.254.2.42]) by szxeml456-hub.china.huawei.com ([10.82.67.199]) with mapi id 14.01.0323.007; Tue, 2 Apr 2013 16:10:54 +0800 From: Fatai Zhang To: Lou Berger , "ccamp@ietf.org" Thread-Topic: [CCAMP] poll on making draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05 a WG document Thread-Index: AQHOK77YQOeZ/cCUEUSaT66LkO4wBZjCm6AQ Date: Tue, 2 Apr 2013 08:10:53 +0000 Message-ID: References: <51545098.4060609@labn.net> In-Reply-To: <51545098.4060609@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [CCAMP] poll on making draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05 a WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 08:11:12 -0000 Yes/Support. Best Regards Fatai -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= ou Berger Sent: Thursday, March 28, 2013 10:16 PM To: ccamp@ietf.org Subject: [CCAMP] poll on making draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05 a= WG document All, This is to start a two week poll on making draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05 a ccamp working group document. Please send mail to the list indicating "yes/support" or "no/do not support". If indicating no, please state your technical reservations with the document. All authors have stated that they are not aware of any IPR that applies to the draft. The poll ends Thursday April 11. Much thanks, Lou (and Deborah) _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From francesco.fondelli@gmail.com Tue Apr 2 02:22:26 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372E021F9772 for ; Tue, 2 Apr 2013 02:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 ytrBMFg6U0lF for ; Tue, 2 Apr 2013 02:22:25 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 3154121F86D5 for ; Tue, 2 Apr 2013 02:22:25 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id c10so2952725wiw.0 for ; Tue, 02 Apr 2013 02:22:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=xja4vbxEz/pQ82GWpQXXCFs4IRwolhdJ4cLPVoMS+XY=; b=ec3+VkgvtJpIgznPW4uj+Q6UnvD5PdeCZHRErBVx0783rbN81uFqK0O9DeXRl5r7Zp nhbpfDKTF5d+v0lakCl4jgLX35+GgT9UH/jkevZJrmfccqd/yZFw/vLo9RpBHxiGjPXl NHnNGJZF8OhyNNulbIb8AFZh/pnxFh0qTUp8Qx+FRwJ+vjOUP5jZ3mVFsIb7GharP/sV jD3TUcNxxr1XJhRz/HGUdoRTkDAX9DKXqp0g4AjdTx5OXo9+u1zd9Xve8MkJtbzY22kx vzxZ3Fnw7ExurSJHvfoTgSo4w0QFAHabN4Ns1tPFRNwL2jyd4J3Hbem1L2mBUG6oH3Le aDzA== MIME-Version: 1.0 X-Received: by 10.195.12.133 with SMTP id eq5mr20132819wjd.52.1364894544359; Tue, 02 Apr 2013 02:22:24 -0700 (PDT) Received: by 10.194.22.36 with HTTP; Tue, 2 Apr 2013 02:22:24 -0700 (PDT) In-Reply-To: References: Date: Tue, 2 Apr 2013 11:22:24 +0200 Message-ID: From: Francesco Fondelli To: "BRUNGARD, DEBORAH A" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 09:22:26 -0000 On Mon, Apr 1, 2013 at 8:06 PM, BRUNGARD, DEBORAH A wrote: > Hi Francesco, Hi Deborah, > While these may be protection switching parameters, this draft is about c= onfiguration of these parameters. Protection switching provisioning has alw= ays been treated as a common equipment management functionality - same as p= erformance management and fault management (refer to G.7710 section 8). So = it is in scope of OAM configuration. CCAMP's OAM configuration work has bee= n focused on PM and FM but it is generally applicable (hopefully) to any eq= uipment management configuration. Puzzled. If we follow this reasoning (i.e. common equipment management functionalities =3D> should use OAM framework) then almost any aspect of networking can be applicable to OAM and so any operation should exploit the OAM framework draft. For example, G.7710 section 8.6.1 describes the provisioning of cross-connections but this does not imply that we are going to use the OAM framework to establish label binding in the next GMPLS controlled technology, I guess we will continue to use LABEL_REQUEST/LABEL objects (plus any other relevant info). > Lou's comment is that the WG has chosen the approach used in the OAM fram= ework document for configuration. Instead of updating the protection object= at this time as your draft proposes, the question is have you considered u= sing the OAM configuration TLV? First, we need to understand why you have c= hosen to not use this approach. Then we can discuss pros and cons. Well, at the beginning we did not take it into consideration because [4] predate [1]. Later we did not take [1] into consideration simply because we thought [4] was out of OAM framework scope. Having said that, I have no problem rewriting [4] using OAM configuration TLV. It's just weird to me but I can live with it. > BR- > Deborah thank you ciao fra > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of= Francesco Fondelli > Sent: Monday, April 01, 2013 12:20 PM > To: ccamp@ietf.org > Subject: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps > > quoting item 15, from www.ietf.org/proceedings/86/minutes/minutes-86-ccam= p > > Lou Berger: I think you misunderstood my comment from the last meeting. Y= ou > should look at leveraging the OAM configuration work which came after the > earlier versions of your draft. > Zafar Ali: this is applicable to multiple technologies. > Lou Berger: yes, the OAM configuration framework is also applicable to > multiple technologies. You need a strong reason not to follow the WG in > this area. Please look at the OAM configuration document > [draft-ietf-ccamp-oam-configuration-fwk] and either follow it or state wh= y > your work is justified in not following the existing WG solution in this > area. > > --- > > Hi all, > > the OAM configuration framework [1] is about OAM. Therefore, it is use= d in > order to signal OAM functionalities: CC/CV and PM/FM in MPLS-TP [2], CC/C= V > TTI/SAPI/DAPI in SONET/SDH/OTN [3]... while our draft [4] is about *prote= ction > switching*. HOFF, WTR and SNC sub-type are protection switching paramete= rs. > > I believe HOFF, WTR and SNC sub-type are outside of the OAM configurati= on > framework scope and should be signaled as any other protection switching > params (i.e. via PROTECTION object). > > I hope this answer Lou question reported above (item 15, IETF 86 ccamp > minutes). Authors of [4] would like to understand WG's view about this p= oint > and are soliciting for comments. > > thank you > ciao > FF > > [1] > http://tools.ietf.org/html/draft-ietf-ccamp-oam-configuration-fwk-09 > > [2] > http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-11 > > [3] > http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-05 > > [4] > http://tools.ietf.org/html/draft-takacs-ccamp-revertive-ps-08 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From dhruv.ietf@gmail.com Tue Apr 2 06:36:10 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5D021F8820 for ; Tue, 2 Apr 2013 06:36:10 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 lD5RcN4-8CRe for ; Tue, 2 Apr 2013 06:36:09 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 41B2D21F874E for ; Tue, 2 Apr 2013 06:36:09 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id c10so383002ieb.17 for ; Tue, 02 Apr 2013 06:36:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:x-google-sender-delegation :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=jfpOBiWpyeIaxxEBG4gHLFn2zE+3Xea3L43Vt2i4F5c=; b=q9MrePHCHM0ZVeH32u60TjZHUFluFOV8D7XkgVR1sN87GTH6rz+2sMI9lqmkgnWJb/ +TSOryYlXF4tBRh81fIFsmdvxGYlNYpYLI15McrVV37S0lkulvpINSpQIlaSm0epyDev bF51Gy9+YG0cLBGWafUq1BAnoAL55VNCXPUmed3OOhUrq1YAKKBCylG3B17pt8yZ7xak g0wLm11EXrM2SllUt1dak+MVosDez4GHrnalChLksMp1GTWcOdGj9XaeBzPYjNMpSAsz /W9DPxqCf1xBTbsaHtYJJlfkt9GewKAmDejw0qZEYK2+AK4DZa0xmOO3wy9UPdRZmyBa qLdw== MIME-Version: 1.0 X-Received: by 10.50.5.180 with SMTP id t20mr5026987igt.80.1364909768909; Tue, 02 Apr 2013 06:36:08 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.25.2 with HTTP; Tue, 2 Apr 2013 06:36:08 -0700 (PDT) In-Reply-To: <20130402131432.29840.65469.idtracker@ietfa.amsl.com> References: <20130402131432.29840.65469.idtracker@ietfa.amsl.com> Date: Tue, 2 Apr 2013 19:06:08 +0530 X-Google-Sender-Auth: 0LsVoljI6IzJsaQgSkSnGcX6ehk Message-ID: From: Dhruv Dhody To: ccamp@ietf.org Content-Type: multipart/alternative; boundary=e89a8f502548ed292304d960d1ea Subject: [CCAMP] Fwd: New Version Notification for draft-dhody-ccamp-rsvp-te-domain-subobjects-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 13:36:10 -0000 --e89a8f502548ed292304d960d1ea Content-Type: text/plain; charset=ISO-8859-1 Hi, *A Quick Recap: * * We presented the Domain-Subobject draft in the Atlanta Meeting [ http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-22.pdf] * This work is complementary to the PCE WG ID for domain-sequence. [ http://www.ietf.org/id/draft-ietf-pce-pcep-domain-sequence-02.txt] In this revision we have handled the comment given during the IETF meeting by adding an example section which clarifies the usage of the domain-subobjects. Comments/feedback is always welcome! Thanks, Dhruv (on behalf of co-authors) ---------- Forwarded message ---------- From: Date: Tue, Apr 2, 2013 at 6:44 PM Subject: New Version Notification for draft-dhody-ccamp-rsvp-te-domain-subobjects-01.txt To: dhruv.ietf@gmail.com Cc: ramon.casellas@cttc.es, dhruv.dhody@huawei.com, venugopalreddyk@huawei.com, udayasree.palle@huawei.com A new version of I-D, draft-dhody-ccamp-rsvp-te-domain-subobjects-01.txt has been successfully submitted by Dhruv Dhody and posted to the IETF repository. Filename: draft-dhody-ccamp-rsvp-te-domain-subobjects Revision: 01 Title: Domain Subobjects for Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) Creation date: 2013-04-02 Group: Individual Submission Number of pages: 16 URL: http://www.ietf.org/internet-drafts/draft-dhody-ccamp-rsvp-te-domain-subobjects-01.txt Status: http://datatracker.ietf.org/doc/draft-dhody-ccamp-rsvp-te-domain-subobjects Htmlized: http://tools.ietf.org/html/draft-dhody-ccamp-rsvp-te-domain-subobjects-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-dhody-ccamp-rsvp-te-domain-subobjects-01 Abstract: The RSVP-TE specification [RFC3209] and the GMPLS extensions to RSVP-TE [RFC3473] allow abstract nodes and resources to be explicitly included in a path setup. Further Exclude Routes extensions [RFC4874] allow abstract nodes and resources to be explicitly excluded in a path setup. This document specifies new subobjects to include or exclude domains during path setup where domain is a collection of network elements within a common sphere of address management or path computational responsibility (such as an IGP area or an AS (4-Byte)). Note that the use of Autonomous Number (AS) (2-Byte) as an abstract node representing domain is already defined in [RFC3209] and [RFC4874]. The IETF Secretariat --e89a8f502548ed292304d960d1ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

A Quick Recap:=A0
* We presented the Domain-Subobject draft in the Atl= anta Meeting [http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-22.pdf<= /a>]

In this revision we have handled the comment gi= ven during the IETF meeting by adding an example section which clarifies th= e usage of the domain-subobjects.=A0

=
Comments/feedback= is always welcome! =A0

Thanks,
Dhruv (on behalf of co-authors)= =A0

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Tue, Apr= 2, 2013 at 6:44 PM
Subject: New Version Notification for draft-dhody-ccamp-rsvp-te-domain-subo= bjects-01.txt
To: dhruv.ietf@gmail.com
Cc: ramon.casellas@cttc.es, dhruv.dhody@huawei.com, venugopalreddyk@huawei.c= om, uda= yasree.palle@huawei.com



A new version of I-D, draft-dhody-ccamp-rsvp-te-domain-subobjects-01.txt has been successfully submitted by Dhruv Dhody and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-dhody-ccamp-rsvp-te-domain-subobjects
Revision: =A0 =A0 =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 Domain Subobjects for Resource ReserVation Proto= col - Traffic Engineering (RSVP-TE)
Creation date: =A0 2013-04-02
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 16
URL: =A0 =A0 =A0 =A0 =A0 =A0 http= ://www.ietf.org/internet-drafts/draft-dhody-ccamp-rsvp-te-domain-subobjects= -01.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracke= r.ietf.org/doc/draft-dhody-ccamp-rsvp-te-domain-subobjects
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org= /html/draft-dhody-ccamp-rsvp-te-domain-subobjects-01
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://ww= w.ietf.org/rfcdiff?url2=3Ddraft-dhody-ccamp-rsvp-te-domain-subobjects-01

Abstract:
=A0 =A0The RSVP-TE specification [RFC3209] and the GMPLS extensions to
=A0 =A0RSVP-TE [RFC3473] allow abstract nodes and resources to be explicitl= y
=A0 =A0included in a path setup. =A0Further Exclude Routes extensions
=A0 =A0[RFC4874] allow abstract nodes and resources to be explicitly
=A0 =A0excluded in a path setup.

=A0 =A0This document specifies new subobjects to include or exclude domains=
=A0 =A0during path setup where domain is a collection of network elements =A0 =A0within a common sphere of address management or path computational =A0 =A0responsibility (such as an IGP area or an AS (4-Byte)). =A0Note that=
=A0 =A0the use of Autonomous Number (AS) (2-Byte) as an abstract node
=A0 =A0representing domain is already defined in [RFC3209] and [RFC4874].



The IETF Secretariat


--e89a8f502548ed292304d960d1ea-- From jie.dong@huawei.com Wed Apr 3 00:42:08 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5161C21F860A for ; Wed, 3 Apr 2013 00:42:08 -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 vJm7HRVlMf21 for ; Wed, 3 Apr 2013 00:42:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2141921F85E8 for ; Wed, 3 Apr 2013 00:42:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARJ09533; Wed, 03 Apr 2013 07:42:04 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 3 Apr 2013 08:41:48 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 3 Apr 2013 08:42:00 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.21]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.01.0323.007; Wed, 3 Apr 2013 15:41:57 +0800 From: Jie Dong To: Lou Berger , "ccamp@ietf.org" Thread-Topic: [CCAMP] poll on making draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05 a WG document Thread-Index: AQHOK77ZP4+HufhHbESwo6+kVwgbrZjEJdoQ Date: Wed, 3 Apr 2013 07:41:56 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927331A4F03@nkgeml512-mbx.china.huawei.com> References: <51545098.4060609@labn.net> In-Reply-To: <51545098.4060609@labn.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.193.214] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [CCAMP] poll on making draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05 a WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 07:42:08 -0000 Yes/support (as co-author) Best regards, Jie > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf Of Lou Berger > Sent: Thursday, March 28, 2013 5:16 PM > To: ccamp@ietf.org > Subject: [CCAMP] poll on making draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05 > a WG document >=20 > All, >=20 > This is to start a two week poll on making > draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05 a ccamp working group > document. Please send mail to the list indicating "yes/support" > or "no/do not support". If indicating no, please state your technical > reservations with the document. >=20 > All authors have stated that they are not aware of any IPR that applies t= o > the draft. >=20 > The poll ends Thursday April 11. >=20 > Much thanks, > Lou (and Deborah) >=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From loa@mail01.huawei.com Wed Apr 3 03:17:38 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90ACC21F8A1B for ; Wed, 3 Apr 2013 03:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 G-3aijP4uIs0 for ; Wed, 3 Apr 2013 03:17:38 -0700 (PDT) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 0F15D21F8A18 for ; Wed, 3 Apr 2013 03:17:38 -0700 (PDT) Received: from [192.168.10.101] (unknown [121.54.51.84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id 49E96823B5 for ; Wed, 3 Apr 2013 12:17:32 +0200 (CEST) Message-ID: <515C01BC.1050709@mail01.huawei.com> Date: Wed, 03 Apr 2013 12:17:32 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: ccamp@ietf.org References: <51545098.4060609@labn.net> In-Reply-To: <51545098.4060609@labn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 03 Apr 2013 04:47:11 -0700 Subject: Re: [CCAMP] poll on making draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05 a WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 10:17:38 -0000 WG, this document aligns well with other documents extending the GMPLS control for MPLS-TP and therefore I support making it a working group document. /Loa On 2013-03-28 15:15, Lou Berger wrote: > All, > > This is to start a two week poll on making > draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05 a ccamp working > group document. Please send mail to the list indicating "yes/support" > or "no/do not support". If indicating no, please state your technical > reservations with the document. > > All authors have stated that they are not aware of any IPR that applies > to the draft. > > The poll ends Thursday April 11. > > Much thanks, > Lou (and Deborah) > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From francesco.fondelli@gmail.com Wed Apr 3 09:59:21 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D5321F8FAA for ; Wed, 3 Apr 2013 09:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 pMEZrMyY6DpT for ; Wed, 3 Apr 2013 09:59:21 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id BDB9921F8F06 for ; Wed, 3 Apr 2013 09:59:20 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id hm14so3858621wib.15 for ; Wed, 03 Apr 2013 09:59:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=ii93pRe9iNM7FJ8Wt7Q41RtJqYIWry1TxJb+MNCCFtA=; b=BxIz+8yVf515uHeRRu8LFt5Sw4ocnB1g9L1mNnivaL8VC17BjuBJinF0R3A35GwNAk thRgdYzWbNrX6wYiVGcs32x94vakZ3WkE5GeK5zzhxchhXI6/ybbOArj9Fbs7lVLCNGM 2HW9k6MokKLEPfU4ZQml+ukq/u7cv9ME72Qnbk7ibaFKtq2sJyXXjNB+aNYuSq+CPfDW jnMpfQDK2ptq/V9V1pujySSmunmSIy6TFdtSdUTF/UPk5mcpKpmjNzvSD15THt4/b4OM lYgADjaizPktgY2FEBvUL+uAiSJxeOrs5+xkjUz6LQxUD14kHQY3Iurj6jJCHASV84Qa fnbw== MIME-Version: 1.0 X-Received: by 10.194.77.110 with SMTP id r14mr4202926wjw.2.1365008359832; Wed, 03 Apr 2013 09:59:19 -0700 (PDT) Received: by 10.194.135.212 with HTTP; Wed, 3 Apr 2013 09:59:19 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Apr 2013 18:59:19 +0200 Message-ID: From: Francesco Fondelli To: "BRUNGARD, DEBORAH A" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 16:59:21 -0000 Hi Deborah, all, > Having said that, I have no problem rewriting [4] using OAM > configuration TLV. It's just weird to me but I can live with it. sorry, I changed my mind, I cannot use the OAM TLV. The more I read about OAM in IETF the more I think protection switching provisioning is completely out-of-scope. I spent some hours looking for the OAM definition within the IETF context(s). The most recent and enlightening (to me at least) documents I found are [A] and [B]. As far as I understand, [1] is perfectly aligned with them. At the same time I cannot find any support of your statement: > Protection switching provisioning has always been treated as a > common equipment management functionality [cut]. So it is in scope > of OAM configuration. Maybe I'm just missing something big (?) Can someone shed some light on this? thank you ciao fra [A] http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08 [B] http://tools.ietf.org/html/rfc6291 On Tue, Apr 2, 2013 at 11:22 AM, Francesco Fondelli wrote: > On Mon, Apr 1, 2013 at 8:06 PM, BRUNGARD, DEBORAH A wrot= e: >> Hi Francesco, > > Hi Deborah, > >> While these may be protection switching parameters, this draft is about = configuration of these parameters. Protection switching provisioning has al= ways been treated as a common equipment management functionality - same as = performance management and fault management (refer to G.7710 section 8). So= it is in scope of OAM configuration. CCAMP's OAM configuration work has be= en focused on PM and FM but it is generally applicable (hopefully) to any e= quipment management configuration. > > Puzzled. If we follow this reasoning (i.e. common equipment management > functionalities =3D> should use OAM framework) then almost any aspect of > networking can be applicable to OAM and so any operation should exploit > the OAM framework draft. > > For example, G.7710 section 8.6.1 describes the provisioning > of cross-connections but this does not imply that we are going to use the > OAM framework to establish label binding in the next GMPLS controlled > technology, I guess we will continue to use LABEL_REQUEST/LABEL objects > (plus any other relevant info). > >> Lou's comment is that the WG has chosen the approach used in the OAM fra= mework document for configuration. Instead of updating the protection objec= t at this time as your draft proposes, the question is have you considered = using the OAM configuration TLV? First, we need to understand why you have = chosen to not use this approach. Then we can discuss pros and cons. > > Well, at the beginning we did not take it into consideration > because [4] predate [1]. Later we did not take [1] into consideration > simply because we thought [4] was out of OAM framework scope. > > Having said that, I have no problem rewriting [4] using OAM > configuration TLV. It's just weird to me but I can live with it. > >> BR- >> Deborah > > thank you > ciao > fra > >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf O= f Francesco Fondelli >> Sent: Monday, April 01, 2013 12:20 PM >> To: ccamp@ietf.org >> Subject: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps >> >> quoting item 15, from www.ietf.org/proceedings/86/minutes/minutes-86-cca= mp >> >> Lou Berger: I think you misunderstood my comment from the last meeting. = You >> should look at leveraging the OAM configuration work which came after th= e >> earlier versions of your draft. >> Zafar Ali: this is applicable to multiple technologies. >> Lou Berger: yes, the OAM configuration framework is also applicable to >> multiple technologies. You need a strong reason not to follow the WG in >> this area. Please look at the OAM configuration document >> [draft-ietf-ccamp-oam-configuration-fwk] and either follow it or state w= hy >> your work is justified in not following the existing WG solution in this >> area. >> >> --- >> >> Hi all, >> >> the OAM configuration framework [1] is about OAM. Therefore, it is us= ed in >> order to signal OAM functionalities: CC/CV and PM/FM in MPLS-TP [2], CC/= CV >> TTI/SAPI/DAPI in SONET/SDH/OTN [3]... while our draft [4] is about *prot= ection >> switching*. HOFF, WTR and SNC sub-type are protection switching paramet= ers. >> >> I believe HOFF, WTR and SNC sub-type are outside of the OAM configurat= ion >> framework scope and should be signaled as any other protection switching >> params (i.e. via PROTECTION object). >> >> I hope this answer Lou question reported above (item 15, IETF 86 ccamp >> minutes). Authors of [4] would like to understand WG's view about this = point >> and are soliciting for comments. >> >> thank you >> ciao >> FF >> >> [1] >> http://tools.ietf.org/html/draft-ietf-ccamp-oam-configuration-fwk-09 >> >> [2] >> http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-11 >> >> [3] >> http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-05 >> >> [4] >> http://tools.ietf.org/html/draft-takacs-ccamp-revertive-ps-08 >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp From zali@cisco.com Wed Apr 3 10:28:03 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A203521F8CE9 for ; Wed, 3 Apr 2013 10:28:03 -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 MTJ8sJzLx-+F for ; Wed, 3 Apr 2013 10:28:02 -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 BB5FA21F8DA6 for ; Wed, 3 Apr 2013 10:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6328; q=dns/txt; s=iport; t=1365010082; x=1366219682; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=zeUgViPdG4ivFaWLI2EB4VT1bYUo8IMgS8owSleARpk=; b=XbOHp7tDHeltUhFzZ9y9KWkqfE75zJQ1cYEvhLBEGOjzl+xNNmWdl1pk xjwfPED/bLinUEb+nKAdhEovgk5wNLzzdeDGuLMmPYmA5xwadTRiB2PdQ NFm/BEk5RgpDGlXmPuH0nPX6KvcV9zm6F5oiEafYFP9PORNGbGTrJ/C0S 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4FAEJmXFGtJV2Y/2dsb2JhbABDgwc2wEWBDBZ0gh8BAQEEAQEBawsMBgEIEQMBAQEBCh0oBgsUCQgCBA4FCAESh2cDDwy2Xw2JW4xHgiEmCwcGgllhA5MlgWaCf4pRhRuDC4Io X-IronPort-AV: E=Sophos;i="4.87,402,1363132800"; d="scan'208";a="194655793" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 03 Apr 2013 17:28:02 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r33HS2eM003385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Apr 2013 17:28:02 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Wed, 3 Apr 2013 12:28:02 -0500 From: "Zafar Ali (zali)" To: Francesco Fondelli , "BRUNGARD, DEBORAH A" Thread-Topic: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps Thread-Index: AQHOLvS39bpyTqTPkUSHnkgWwL1MfZjB/SCAgAD/8wCAAhH+gP//xPWA Date: Wed, 3 Apr 2013 17:28:01 +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.252.193] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 17:28:03 -0000 Hi all-=20 In addition, I see draft-takacs-ccamp-revertive-ps something that was not addressed by 4872 but very much in-line with the rest of the mechanics of 4872. Even if we can define something using a different object, I feel use of protection object is more in-line with the spirit of this draft. Thanks Regards =8A Zafar -----Original Message----- From: Francesco Fondelli Date: Wednesday, April 3, 2013 12:59 PM To: "BRUNGARD, DEBORAH A" Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps >Hi Deborah, all, > >> Having said that, I have no problem rewriting [4] using OAM >> configuration TLV. It's just weird to me but I can live with it. > > sorry, I changed my mind, I cannot use the OAM TLV. The more I read >about OAM in IETF the more I think protection switching provisioning >is completely out-of-scope. > > I spent some hours looking for the OAM definition within the >IETF context(s). The most recent and enlightening (to me at least) >documents I found are [A] and [B]. As far as I understand, [1] is >perfectly aligned with them. At the same time I cannot find any >support of your statement: > >> Protection switching provisioning has always been treated as a >> common equipment management functionality [cut]. So it is in scope >> of OAM configuration. > > Maybe I'm just missing something big (?) Can someone shed some light on >this? > >thank you >ciao >fra > >[A] >http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08 > >[B] >http://tools.ietf.org/html/rfc6291 > >On Tue, Apr 2, 2013 at 11:22 AM, Francesco Fondelli > wrote: >> On Mon, Apr 1, 2013 at 8:06 PM, BRUNGARD, DEBORAH A >>wrote: >>> Hi Francesco, >> >> Hi Deborah, >> >>> While these may be protection switching parameters, this draft is >>>about configuration of these parameters. Protection switching >>>provisioning has always been treated as a common equipment management >>>functionality - same as performance management and fault management >>>(refer to G.7710 section 8). So it is in scope of OAM configuration. >>>CCAMP's OAM configuration work has been focused on PM and FM but it is >>>generally applicable (hopefully) to any equipment management >>>configuration. >> >> Puzzled. If we follow this reasoning (i.e. common equipment >>management >> functionalities =3D> should use OAM framework) then almost any aspect of >> networking can be applicable to OAM and so any operation should exploit >> the OAM framework draft. >> >> For example, G.7710 section 8.6.1 describes the provisioning >> of cross-connections but this does not imply that we are going to use >>the >> OAM framework to establish label binding in the next GMPLS controlled >> technology, I guess we will continue to use LABEL_REQUEST/LABEL objects >> (plus any other relevant info). >> >>> Lou's comment is that the WG has chosen the approach used in the OAM >>>framework document for configuration. Instead of updating the >>>protection object at this time as your draft proposes, the question is >>>have you considered using the OAM configuration TLV? First, we need to >>>understand why you have chosen to not use this approach. Then we can >>>discuss pros and cons. >> >> Well, at the beginning we did not take it into consideration >> because [4] predate [1]. Later we did not take [1] into consideration >> simply because we thought [4] was out of OAM framework scope. >> >> Having said that, I have no problem rewriting [4] using OAM >> configuration TLV. It's just weird to me but I can live with it. >> >>> BR- >>> Deborah >> >> thank you >> ciao >> fra >> >>> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >>>Of Francesco Fondelli >>> Sent: Monday, April 01, 2013 12:20 PM >>> To: ccamp@ietf.org >>> Subject: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps >>> >>> quoting item 15, from >>>www.ietf.org/proceedings/86/minutes/minutes-86-ccamp >>> >>> Lou Berger: I think you misunderstood my comment from the last >>>meeting. You >>> should look at leveraging the OAM configuration work which came after >>>the >>> earlier versions of your draft. >>> Zafar Ali: this is applicable to multiple technologies. >>> Lou Berger: yes, the OAM configuration framework is also applicable to >>> multiple technologies. You need a strong reason not to follow the WG in >>> this area. Please look at the OAM configuration document >>> [draft-ietf-ccamp-oam-configuration-fwk] and either follow it or state >>>why >>> your work is justified in not following the existing WG solution in >>>this >>> area. >>> >>> --- >>> >>> Hi all, >>> >>> the OAM configuration framework [1] is about OAM. Therefore, it is >>>used in >>> order to signal OAM functionalities: CC/CV and PM/FM in MPLS-TP [2], >>>CC/CV >>> TTI/SAPI/DAPI in SONET/SDH/OTN [3]... while our draft [4] is about >>>*protection >>> switching*. HOFF, WTR and SNC sub-type are protection switching >>>parameters. >>> >>> I believe HOFF, WTR and SNC sub-type are outside of the OAM >>>configuration >>> framework scope and should be signaled as any other protection >>>switching >>> params (i.e. via PROTECTION object). >>> >>> I hope this answer Lou question reported above (item 15, IETF 86 >>>ccamp >>> minutes). Authors of [4] would like to understand WG's view about >>>this point >>> and are soliciting for comments. >>> >>> thank you >>> ciao >>> FF >>> >>> [1] >>> http://tools.ietf.org/html/draft-ietf-ccamp-oam-configuration-fwk-09 >>> >>> [2] >>> http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-11 >>> >>> [3] >>> http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-05 >>> >>> [4] >>> http://tools.ietf.org/html/draft-takacs-ccamp-revertive-ps-08 >>> _______________________________________________ >>> 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 From db3546@att.com Thu Apr 4 07:50:07 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C8521F940D for ; Thu, 4 Apr 2013 07:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 iVdozOa81GTV for ; Thu, 4 Apr 2013 07:50:04 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id E572C21F8F0E for ; Thu, 4 Apr 2013 07:50:02 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id a139d515.2aaade823940.126023.00-599.350502.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 04 Apr 2013 14:50:02 +0000 (UTC) X-MXL-Hash: 515d931a4db3d65e-7a8d0d6dc07b88458cc1dd3c563135a97f2331a0 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 9139d515.0.126009.00-413.350451.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 04 Apr 2013 14:50:02 +0000 (UTC) X-MXL-Hash: 515d931a61b03905-a9f2b15954612ce46b3dbf2b24664245e9d58143 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r34Eo08J008996; Thu, 4 Apr 2013 10:50:01 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r34EnpEB008783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Apr 2013 10:49:53 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Thu, 4 Apr 2013 15:49:32 +0100 Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.02.0342.003; Thu, 4 Apr 2013 10:49:32 -0400 From: "BRUNGARD, DEBORAH A" To: Francesco Fondelli Thread-Topic: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps Thread-Index: AQHOMIyU5E5gvsW8qk+nQPJ9P69loZjGEmhw Date: Thu, 4 Apr 2013 14:49:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=MJHXbrll c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=RWEAq7CW3jcA:10 a=OIZjW_EDwrwA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=IkcTkHD0fZMA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=Axtq_jpKRe8A:10 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8] X-AnalysisOut: [ a=SpezpsmYVRz-eOi4vRgA:9 a=QEXdDO2ut3YA:10 a=MSl-tDqOz04A] X-AnalysisOut: [:10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0cA:10] Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 14:50:07 -0000 SGkgRnJhbmNlc2NvLA0KDQpUaGF0IHdhcyBhIGZhc3QgYW5hbHlzaXM6LSkNCg0KU3VnZ2VzdCB5 b3UgZmlyc3QgZXhwYW5kIG9uIHRoZSByZXF1aXJlbWVudHMgdGhhdCB5b3Ugd2FudCB0byBzdXBw b3J0IHZzLiBzb2x1dGlvbi4gV2hlbiB5b3UgZGV0YWlsIGFzcGVjdHMgb2YgU05DL04sIFNOQy9J LCBhbmQgU05DL1MsIHlvdSB3aWxsIGZpbmQgdGhhdCB5b3UgYWxzbyBuZWVkIE9BTSBjb25maWd1 cmF0aW9uIHRvIHN1cHBvcnQgKE4vSS9TIGNvbmZpZ3VyYXRpb24gKGUuZy4gREVHLCBUVEkpKSBh bmQgeW91IHdpbGwgbmVlZCB0byBjb25maWd1cmUgd2hpY2ggZGVmZWN0cyBjb250cmlidXRlIHRv IGEgImZhaWx1cmUiLiBUaGlzIHdpbGwgYWxsIG5lZWQgdG8gYmUgY29vcmRpbmF0ZWQgd2l0aCB0 aGUgTFNQIE9BTSBjb25maWd1cmF0aW9uLg0KDQpBbHNvIG9uIFNOQy9OLCBTTkMvSSwgYW5kIFNO Qy9TLCBpcyB0aGlzIGZvciBhIHNlZ21lbnQgb3IgZS0yLWU/IFRoZSBkcmFmdCBuZWVkcyBtb3Jl IGRldGFpbCBhbmQgYWxpZ25tZW50IHdpdGggR01QTFMgcHJvdGVjdGlvbiB0ZXJtaW5vbG9neSBh bmQgbWVjaGFuaXNtcy4NCg0KQWZ0ZXIgaGF2aW5nIGEgYmV0dGVyIHNjb3BlIG9mIHRoZSByZXF1 aXJlbWVudHMsIHdlIGNhbiBkaXNjdXNzIHRoZSBzb2x1dGlvbiB0cmFkZW9mZnMuIFRoZXJlIGFy ZSBhbHdheXMgbXVsdGlwbGUgd2F5cyB0byBzb2x2ZSwgZmlyc3Qgd2UgbmVlZCB0byB1bmRlcnN0 YW5kIHdoYXQgaXMgbmVlZGVkLg0KDQpUaGFua3MsDQpEZWJvcmFoDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBGcmFuY2VzY28gRm9uZGVsbGkgW21haWx0bzpmcmFuY2VzY28u Zm9uZGVsbGlAZ21haWwuY29tXSANClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMDMsIDIwMTMgMTI6 NTkgUE0NClRvOiBCUlVOR0FSRCwgREVCT1JBSCBBDQpDYzogY2NhbXBAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbQ0NBTVBdIGNsYXJpZmljYXRpb24gYWJvdXQgZHJhZnQtdGFrYWNzLWNjYW1wLXJl dmVydGl2ZS1wcw0KDQpIaSBEZWJvcmFoLCBhbGwsDQoNCj4gICBIYXZpbmcgc2FpZCB0aGF0LCBJ IGhhdmUgbm8gcHJvYmxlbSByZXdyaXRpbmcgWzRdIHVzaW5nIE9BTQ0KPiBjb25maWd1cmF0aW9u IFRMVi4gIEl0J3MganVzdCB3ZWlyZCB0byBtZSBidXQgSSBjYW4gbGl2ZSB3aXRoIGl0Lg0KDQog IHNvcnJ5LCBJIGNoYW5nZWQgbXkgbWluZCwgSSBjYW5ub3QgdXNlIHRoZSBPQU0gVExWLiAgVGhl IG1vcmUgSSByZWFkDQphYm91dCBPQU0gaW4gSUVURiB0aGUgbW9yZSBJIHRoaW5rIHByb3RlY3Rp b24gc3dpdGNoaW5nIHByb3Zpc2lvbmluZw0KaXMgY29tcGxldGVseSBvdXQtb2Ytc2NvcGUuDQoN CiAgSSBzcGVudCBzb21lIGhvdXJzIGxvb2tpbmcgZm9yIHRoZSBPQU0gZGVmaW5pdGlvbiB3aXRo aW4gdGhlDQpJRVRGIGNvbnRleHQocykuICBUaGUgbW9zdCByZWNlbnQgYW5kIGVubGlnaHRlbmlu ZyAodG8gbWUgYXQgbGVhc3QpDQpkb2N1bWVudHMgSSBmb3VuZCBhcmUgW0FdIGFuZCBbQl0uICBB cyBmYXIgYXMgSSB1bmRlcnN0YW5kLCBbMV0gaXMNCnBlcmZlY3RseSBhbGlnbmVkIHdpdGggdGhl bS4gIEF0IHRoZSBzYW1lIHRpbWUgSSBjYW5ub3QgZmluZCBhbnkNCnN1cHBvcnQgb2YgeW91ciBz dGF0ZW1lbnQ6DQoNCj4gUHJvdGVjdGlvbiBzd2l0Y2hpbmcgcHJvdmlzaW9uaW5nIGhhcyBhbHdh eXMgYmVlbiB0cmVhdGVkIGFzIGENCj4gY29tbW9uIGVxdWlwbWVudCBtYW5hZ2VtZW50IGZ1bmN0 aW9uYWxpdHkgW2N1dF0uIFNvIGl0IGlzIGluIHNjb3BlDQo+IG9mIE9BTSBjb25maWd1cmF0aW9u Lg0KDQogIE1heWJlIEknbSBqdXN0IG1pc3Npbmcgc29tZXRoaW5nIGJpZyAoPykgQ2FuIHNvbWVv bmUgc2hlZCBzb21lIGxpZ2h0IG9uDQp0aGlzPw0KDQp0aGFuayB5b3UNCmNpYW8NCmZyYQ0KDQpb QV0NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb3BzYXdnLW9hbS1vdmVy dmlldy0wOA0KDQpbQl0NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYyOTENCg0KT24g VHVlLCBBcHIgMiwgMjAxMyBhdCAxMToyMiBBTSwgRnJhbmNlc2NvIEZvbmRlbGxpDQo8ZnJhbmNl c2NvLmZvbmRlbGxpQGdtYWlsLmNvbT4gd3JvdGU6DQo+IE9uIE1vbiwgQXByIDEsIDIwMTMgYXQg ODowNiBQTSwgQlJVTkdBUkQsIERFQk9SQUggQSA8ZGIzNTQ2QGF0dC5jb20+IHdyb3RlOg0KPj4g SGkgRnJhbmNlc2NvLA0KPg0KPiBIaSBEZWJvcmFoLA0KPg0KPj4gV2hpbGUgdGhlc2UgbWF5IGJl IHByb3RlY3Rpb24gc3dpdGNoaW5nIHBhcmFtZXRlcnMsIHRoaXMgZHJhZnQgaXMgYWJvdXQgY29u ZmlndXJhdGlvbiBvZiB0aGVzZSBwYXJhbWV0ZXJzLiBQcm90ZWN0aW9uIHN3aXRjaGluZyBwcm92 aXNpb25pbmcgaGFzIGFsd2F5cyBiZWVuIHRyZWF0ZWQgYXMgYSBjb21tb24gZXF1aXBtZW50IG1h bmFnZW1lbnQgZnVuY3Rpb25hbGl0eSAtIHNhbWUgYXMgcGVyZm9ybWFuY2UgbWFuYWdlbWVudCBh bmQgZmF1bHQgbWFuYWdlbWVudCAocmVmZXIgdG8gRy43NzEwIHNlY3Rpb24gOCkuIFNvIGl0IGlz IGluIHNjb3BlIG9mIE9BTSBjb25maWd1cmF0aW9uLiBDQ0FNUCdzIE9BTSBjb25maWd1cmF0aW9u IHdvcmsgaGFzIGJlZW4gZm9jdXNlZCBvbiBQTSBhbmQgRk0gYnV0IGl0IGlzIGdlbmVyYWxseSBh cHBsaWNhYmxlIChob3BlZnVsbHkpIHRvIGFueSBlcXVpcG1lbnQgbWFuYWdlbWVudCBjb25maWd1 cmF0aW9uLg0KPg0KPiAgIFB1enpsZWQuICBJZiB3ZSBmb2xsb3cgdGhpcyByZWFzb25pbmcgKGku ZS4gY29tbW9uIGVxdWlwbWVudCBtYW5hZ2VtZW50DQo+IGZ1bmN0aW9uYWxpdGllcyA9PiBzaG91 bGQgdXNlIE9BTSBmcmFtZXdvcmspIHRoZW4gYWxtb3N0IGFueSBhc3BlY3Qgb2YNCj4gbmV0d29y a2luZyBjYW4gYmUgYXBwbGljYWJsZSB0byBPQU0gYW5kIHNvIGFueSBvcGVyYXRpb24gc2hvdWxk IGV4cGxvaXQNCj4gdGhlIE9BTSBmcmFtZXdvcmsgZHJhZnQuDQo+DQo+ICAgRm9yIGV4YW1wbGUs IEcuNzcxMCBzZWN0aW9uIDguNi4xIGRlc2NyaWJlcyB0aGUgcHJvdmlzaW9uaW5nDQo+IG9mIGNy b3NzLWNvbm5lY3Rpb25zIGJ1dCB0aGlzIGRvZXMgbm90IGltcGx5IHRoYXQgd2UgYXJlIGdvaW5n IHRvIHVzZSB0aGUNCj4gT0FNIGZyYW1ld29yayB0byBlc3RhYmxpc2ggbGFiZWwgYmluZGluZyBp biB0aGUgbmV4dCBHTVBMUyBjb250cm9sbGVkDQo+IHRlY2hub2xvZ3ksIEkgZ3Vlc3Mgd2Ugd2ls bCBjb250aW51ZSB0byB1c2UgTEFCRUxfUkVRVUVTVC9MQUJFTCBvYmplY3RzDQo+IChwbHVzIGFu eSBvdGhlciByZWxldmFudCBpbmZvKS4NCj4NCj4+IExvdSdzIGNvbW1lbnQgaXMgdGhhdCB0aGUg V0cgaGFzIGNob3NlbiB0aGUgYXBwcm9hY2ggdXNlZCBpbiB0aGUgT0FNIGZyYW1ld29yayBkb2N1 bWVudCBmb3IgY29uZmlndXJhdGlvbi4gSW5zdGVhZCBvZiB1cGRhdGluZyB0aGUgcHJvdGVjdGlv biBvYmplY3QgYXQgdGhpcyB0aW1lIGFzIHlvdXIgZHJhZnQgcHJvcG9zZXMsIHRoZSBxdWVzdGlv biBpcyBoYXZlIHlvdSBjb25zaWRlcmVkIHVzaW5nIHRoZSBPQU0gY29uZmlndXJhdGlvbiBUTFY/ IEZpcnN0LCB3ZSBuZWVkIHRvIHVuZGVyc3RhbmQgd2h5IHlvdSBoYXZlIGNob3NlbiB0byBub3Qg dXNlIHRoaXMgYXBwcm9hY2guIFRoZW4gd2UgY2FuIGRpc2N1c3MgcHJvcyBhbmQgY29ucy4NCj4N Cj4gICBXZWxsLCBhdCB0aGUgYmVnaW5uaW5nIHdlIGRpZCBub3QgdGFrZSBpdCBpbnRvIGNvbnNp ZGVyYXRpb24NCj4gYmVjYXVzZSBbNF0gcHJlZGF0ZSBbMV0uICBMYXRlciB3ZSBkaWQgbm90IHRh a2UgWzFdIGludG8gY29uc2lkZXJhdGlvbg0KPiBzaW1wbHkgYmVjYXVzZSB3ZSB0aG91Z2h0IFs0 XSB3YXMgb3V0IG9mIE9BTSBmcmFtZXdvcmsgc2NvcGUuDQo+DQo+ICAgSGF2aW5nIHNhaWQgdGhh dCwgSSBoYXZlIG5vIHByb2JsZW0gcmV3cml0aW5nIFs0XSB1c2luZyBPQU0NCj4gY29uZmlndXJh dGlvbiBUTFYuICBJdCdzIGp1c3Qgd2VpcmQgdG8gbWUgYnV0IEkgY2FuIGxpdmUgd2l0aCBpdC4N Cj4NCj4+IEJSLQ0KPj4gRGVib3JhaA0KPg0KPiB0aGFuayB5b3UNCj4gY2lhbw0KPiBmcmENCj4N Cj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogY2NhbXAtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBG cmFuY2VzY28gRm9uZGVsbGkNCj4+IFNlbnQ6IE1vbmRheSwgQXByaWwgMDEsIDIwMTMgMTI6MjAg UE0NCj4+IFRvOiBjY2FtcEBpZXRmLm9yZw0KPj4gU3ViamVjdDogW0NDQU1QXSBjbGFyaWZpY2F0 aW9uIGFib3V0IGRyYWZ0LXRha2Fjcy1jY2FtcC1yZXZlcnRpdmUtcHMNCj4+DQo+PiBxdW90aW5n IGl0ZW0gMTUsIGZyb20gd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzg2L21pbnV0ZXMvbWludXRl cy04Ni1jY2FtcA0KPj4NCj4+IExvdSBCZXJnZXI6IEkgdGhpbmsgeW91IG1pc3VuZGVyc3Rvb2Qg bXkgY29tbWVudCBmcm9tIHRoZSBsYXN0IG1lZXRpbmcuIFlvdQ0KPj4gc2hvdWxkIGxvb2sgYXQg bGV2ZXJhZ2luZyB0aGUgT0FNIGNvbmZpZ3VyYXRpb24gd29yayB3aGljaCBjYW1lIGFmdGVyIHRo ZQ0KPj4gZWFybGllciB2ZXJzaW9ucyBvZiB5b3VyIGRyYWZ0Lg0KPj4gWmFmYXIgQWxpOiB0aGlz IGlzIGFwcGxpY2FibGUgdG8gbXVsdGlwbGUgdGVjaG5vbG9naWVzLg0KPj4gTG91IEJlcmdlcjog eWVzLCB0aGUgT0FNIGNvbmZpZ3VyYXRpb24gZnJhbWV3b3JrIGlzIGFsc28gYXBwbGljYWJsZSB0 bw0KPj4gbXVsdGlwbGUgdGVjaG5vbG9naWVzLiBZb3UgbmVlZCBhIHN0cm9uZyByZWFzb24gbm90 IHRvIGZvbGxvdyB0aGUgV0cgaW4NCj4+IHRoaXMgYXJlYS4gUGxlYXNlIGxvb2sgYXQgdGhlIE9B TSBjb25maWd1cmF0aW9uIGRvY3VtZW50DQo+PiBbZHJhZnQtaWV0Zi1jY2FtcC1vYW0tY29uZmln dXJhdGlvbi1md2tdIGFuZCBlaXRoZXIgZm9sbG93IGl0IG9yIHN0YXRlIHdoeQ0KPj4geW91ciB3 b3JrIGlzIGp1c3RpZmllZCBpbiBub3QgZm9sbG93aW5nIHRoZSBleGlzdGluZyBXRyBzb2x1dGlv biBpbiB0aGlzDQo+PiBhcmVhLg0KPj4NCj4+IC0tLQ0KPj4NCj4+IEhpIGFsbCwNCj4+DQo+PiAg IHRoZSBPQU0gY29uZmlndXJhdGlvbiBmcmFtZXdvcmsgWzFdIGlzIGFib3V0IE9BTS4gIFRoZXJl Zm9yZSwgaXQgaXMgdXNlZCBpbg0KPj4gb3JkZXIgdG8gc2lnbmFsIE9BTSBmdW5jdGlvbmFsaXRp ZXM6IENDL0NWIGFuZCBQTS9GTSBpbiBNUExTLVRQIFsyXSwgQ0MvQ1YNCj4+IFRUSS9TQVBJL0RB UEkgaW4gU09ORVQvU0RIL09UTiBbM10uLi4gd2hpbGUgb3VyIGRyYWZ0IFs0XSBpcyBhYm91dCAq cHJvdGVjdGlvbg0KPj4gc3dpdGNoaW5nKi4gIEhPRkYsIFdUUiBhbmQgU05DIHN1Yi10eXBlIGFy ZSBwcm90ZWN0aW9uIHN3aXRjaGluZyBwYXJhbWV0ZXJzLg0KPj4NCj4+ICAgSSBiZWxpZXZlIEhP RkYsIFdUUiBhbmQgU05DIHN1Yi10eXBlIGFyZSBvdXRzaWRlIG9mIHRoZSBPQU0gY29uZmlndXJh dGlvbg0KPj4gZnJhbWV3b3JrIHNjb3BlIGFuZCBzaG91bGQgYmUgc2lnbmFsZWQgYXMgYW55IG90 aGVyIHByb3RlY3Rpb24gc3dpdGNoaW5nDQo+PiBwYXJhbXMgKGkuZS4gdmlhIFBST1RFQ1RJT04g b2JqZWN0KS4NCj4+DQo+PiAgIEkgaG9wZSB0aGlzIGFuc3dlciBMb3UgcXVlc3Rpb24gcmVwb3J0 ZWQgYWJvdmUgKGl0ZW0gMTUsIElFVEYgODYgY2NhbXANCj4+IG1pbnV0ZXMpLiAgQXV0aG9ycyBv ZiBbNF0gd291bGQgbGlrZSB0byB1bmRlcnN0YW5kIFdHJ3MgdmlldyBhYm91dCB0aGlzIHBvaW50 DQo+PiBhbmQgYXJlIHNvbGljaXRpbmcgZm9yIGNvbW1lbnRzLg0KPj4NCj4+IHRoYW5rIHlvdQ0K Pj4gY2lhbw0KPj4gRkYNCj4+DQo+PiBbMV0NCj4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtY2NhbXAtb2FtLWNvbmZpZ3VyYXRpb24tZndrLTA5DQo+Pg0KPj4gWzJdDQo+ PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNjYW1wLXJzdnAtdGUtbXBs cy10cC1vYW0tZXh0LTExDQo+Pg0KPj4gWzNdDQo+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWNjYW1wLXJzdnAtdGUtc2RoLW90bi1vYW0tZXh0LTA1DQo+Pg0KPj4gWzRd DQo+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10YWthY3MtY2NhbXAtcmV2ZXJ0 aXZlLXBzLTA4DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+PiBDQ0FNUEBpZXRmLm9yZw0KPj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0K From internet-drafts@ietf.org Thu Apr 4 08:29:06 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D7021F8FFA; Thu, 4 Apr 2013 08:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 yVmbZh9S8HmL; Thu, 4 Apr 2013 08:29:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F9F21F8F28; Thu, 4 Apr 2013 08:29:05 -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.43 Message-ID: <20130404152905.17308.62746.idtracker@ietfa.amsl.com> Date: Thu, 04 Apr 2013 08:29:05 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-otn-g709-info-model-07.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 15:29:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Evaluation of existing GMPLS encoding against G.709v3 Op= tical Transport Networks (OTN) Author(s) : Sergio Belotti Pietro Vittorio Grandi Daniele Ceccarelli Diego Caviglia Fatai Zhang Dan Li Filename : draft-ietf-ccamp-otn-g709-info-model-07.txt Pages : 22 Date : 2013-04-04 Abstract: ITU-T recommendation G.709 [G.709-2012] has introduced new fixed and flexible Optical Data Unit (ODU) containers in Optical Transport Networks (OTNs). This document provides an evaluation of existing Generalized Multiprotocol Label Switching (GMPLS) routing and signaling methods against the G.709 [G.709-2012] OTN networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-otn-g709-info-model There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-otn-g709-info-model-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-otn-g709-info-model-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Apr 4 08:39:30 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E530421F9577; Thu, 4 Apr 2013 08:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 ZM4jjDckksqw; Thu, 4 Apr 2013 08:39:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 842DB21F8CA5; Thu, 4 Apr 2013 08:39:30 -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.43 Message-ID: <20130404153930.512.48160.idtracker@ietfa.amsl.com> Date: Thu, 04 Apr 2013 08:39:30 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 15:39:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Traffic Engineering Extensions to OSPF for Generalized M= PLS (GMPLS) Control of Evolving G.709 OTN Networks Author(s) : Daniele Ceccarelli Diego Caviglia Fatai Zhang Dan Li Sergio Belotti Pietro Vittorio Grandi Rajan Rao Khuzema Pithewan John E Drake Filename : draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt Pages : 35 Date : 2013-04-04 Abstract: ITU-T Recommendation G.709 [G.709-2012] has introduced new fixed and flexible Optical Data Unit (ODU) containers, enabling optimized support for an increasingly abundant service mix. This document describes Open Shortest Path First - Traffic Engineering (OSPF-TE) routing protocol extensions to support Generalized MPLS (GMPLS) control of all currently defined ODU containers, in support of both sub-lambda and lambda level routing granularity. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-ospf-g709v3 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-gmpls-ospf-g709v3-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From daniele.ceccarelli@ericsson.com Thu Apr 4 08:46:10 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA8821F93D1 for ; Thu, 4 Apr 2013 08:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 cCfQZ3m7uYRL for ; Thu, 4 Apr 2013 08:46:10 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id EEFB621F93C2 for ; Thu, 4 Apr 2013 08:46:09 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-1d-515da040d67d Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 4D.65.19728.040AD515; Thu, 4 Apr 2013 17:46:09 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.208]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0318.004; Thu, 4 Apr 2013 17:46:08 +0200 From: Daniele Ceccarelli To: "ccamp@ietf.org" Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt Thread-Index: AQHOMUqcqrw6KEYeXEevrzCZSajLdpjGMs0g Date: Thu, 4 Apr 2013 15:46:07 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE480A9BAC@ESESSMB301.ericsson.se> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLLMWRmVeSWpSXmKPExsUyM+Jvra7jgthAgxONbBZP5txgcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRtvm96wFp0QqDv+dz9bAeIq/i5GTQ0LAROLziW4WCFtM4sK9 9WxdjFwcQgKHGSX2bLnCAuEsZpRY+fkpexcjBwebgJXEk0M+IA0iAqoSZ25eZASxhQW8JBZ8 vM4OEfeWOL7zOyuEbSRx++QHsBoWARWJbwdmM4PYvEA1l/tvgC1mFJCVmLB7EVgNs4C4xK0n 85kgDhKQWLLnPDOELSrx8vE/VpATJAQUJZb3y0GU60ncmDqFDcLWlli28DXUeEGJkzOfsExg FJ6FZOosJC2zkLTMQtKygJFlFSN7bmJmTnq50SZGYBAf3PJbdQfjnXMihxilOViUxHnDXS8E CAmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamAsfnNUplo0/OVUT6fMbSZXGDRq92jHSptsq++r /9QtXJd7S8/6/1yZCPNFD/4tXJbzIFTN3HiKu1DigVkpm5ba5aQ5yFy2Ng8PTtIOevHYwqyA YZZwUE5WcV6ESZH4kWQuoYW9xmmHXrCvNnm8xdBw8ZNbt9n190qz83myWivLzt0Rtu5tvRJL cUaioRZzUXEiAPoow2UwAgAA Subject: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 15:46:11 -0000 Dear OTNers, Info model and OSPF drafts have been updated accordingly to the discussion = in Orlando. The OSPF draft also includes some last call comments that had n= ot been addressed in v05 and suggestions received on the list. On the other side the framework draft doesn't need any change, while the si= gnaling will be updated soon. BR Daniele, Sergio, Fatai >-----Original Message----- >From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]=20 >On Behalf Of internet-drafts@ietf.org >Sent: gioved=EC 4 aprile 2013 17.40 >To: i-d-announce@ietf.org >Cc: ccamp@ietf.org >Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt > > >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. > This draft is a work item of the Common Control and=20 >Measurement Plane Working Group of the IETF. > > Title : Traffic Engineering Extensions to=20 >OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709=20 >OTN Networks > Author(s) : Daniele Ceccarelli > Diego Caviglia > Fatai Zhang > Dan Li > Sergio Belotti > Pietro Vittorio Grandi > Rajan Rao > Khuzema Pithewan > John E Drake > Filename : draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt > Pages : 35 > Date : 2013-04-04 > >Abstract: > ITU-T Recommendation G.709 [G.709-2012] has introduced new fixed and > flexible Optical Data Unit (ODU) containers, enabling optimized > support for an increasingly abundant service mix. > > This document describes Open Shortest Path First - Traffic > Engineering (OSPF-TE) routing protocol extensions to support > Generalized MPLS (GMPLS) control of all currently defined ODU > containers, in support of both sub-lambda and lambda level routing > granularity. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-ospf-g709v3 > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-06 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-gmpls-ospf-g709v3-06 > > >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 >= From daniele.ceccarelli@ericsson.com Thu Apr 4 08:47:22 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16AFD21F9616 for ; Thu, 4 Apr 2013 08:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 q1ogjrOwa0TK for ; Thu, 4 Apr 2013 08:47:17 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id E099E21F93D1 for ; Thu, 4 Apr 2013 08:47:16 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-3e-515da083ab12 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 63.C6.10459.380AD515; Thu, 4 Apr 2013 17:47:15 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.208]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0318.004; Thu, 4 Apr 2013 17:47:15 +0200 From: Daniele Ceccarelli To: "Gruman, Fred" Thread-Topic: Examples in draft-ietf-ccamp-gmpls-ospf-g709v3-05 Thread-Index: AQHOJzDgoNGNlLL7W02ltwWM964GQ5jGSLYA Date: Thu, 4 Apr 2013 15:47:15 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE480A9BBD@ESESSMB301.ericsson.se> References: <650AA355E323C34D9D4AAEED952E053D3FB173C6@SV-EXDB-PROD2.infinera.com> <0182DEA5604B3A44A2EE61F3EE3ED69E1B2BA7D1@BL2PRD0510MB349.namprd05.prod.outlook.com> <13d65dd005e.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1B2BBB14@BL2PRD0510MB349.namprd05.prod.outlook.com> <514103A5.3010609@labn.net> <650AA355E323C34D9D4AAEED952E053D3FB179F0@SV-EXDB-PROD2.infinera.com> <4A1562797D64E44993C5CBF38CF1BE4809F811@ESESSMB301.ericsson.se> <650AA355E323C34D9D4AAEED952E053D3FB18338@SV-EXDB-PROD2.infinera.com> <4A1562797D64E44993C5CBF38CF1BE4809F863@ESESSMB301.ericsson.se> <5DF87403A81B0C43AF3EB1626511B2924400AD16@RCHEXMBP1.fnc.net.local> In-Reply-To: <5DF87403A81B0C43AF3EB1626511B2924400AD16@RCHEXMBP1.fnc.net.local> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+JvrW7zgthAg8NLbCyezLnBYtHfOpvV gcljyZKfTB7Tfq1hC2CK4rJJSc3JLEst0rdL4MpY8ewxW8FSnoo5j6YzNTB+5exi5OSQEDCR mHlpISuELSZx4d56ti5GLg4hgcOMEhfunGOBcBYzSlw99Y2xi5GDg03ASuLJIR+QBhEBfYme Dz/YQcLMAroSK9a5goSFBewkWnZMZYQosZeY3DWJCcI2kvizfBmYzSKgInF96WcWEJtXwFvi 47IGZohVbWwS/zYcZAdJcAr4Sxxa1A5mMwrISkzYvQhsKLOAuMStJ/OZII4WkFiy5zwzhC0q 8fLxP1aQeyQEFCWW98tBlOtJ3Jg6hQ3C1pZYtvA1M8ReQYmTM5+wTGAUm4Vk6iwkLbOQtMxC 0rKAkWUVI3tuYmZOernhJkZghBzc8lt3B+OpcyKHGKU5WJTEecNcLwQICaQnlqRmp6YWpBbF F5XmpBYfYmTi4JRqYGwoutERn1DxaPYnAwb/Dfw9MtvCf589fmSRy5sD+2bf5Ey98nrabZE9 ci9fH353M/v5qjXpPJLR7gE9m6O+OsTFOO/POVo+ucNy2fGF/GmTGA4tsb/m5HjdpXztNluB hOYJVfmRsnXl/5JPzMzK5hV5ePDui0bFsxFvOj4GmbPMc3prwDBhl7wSS3FGoqEWc1FxIgBF 0NXnXgIAAA== Cc: "CCAMP \(ccamp@ietf.org\)" Subject: Re: [CCAMP] Examples in draft-ietf-ccamp-gmpls-ospf-g709v3-05 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 15:47:24 -0000 Hi Fred, Thanks a lot for the comments/suggestions. All of them have been addressed = in v06. Many thanks and BR Daniele=20 >-----Original Message----- >From: Gruman, Fred [mailto:fred.gruman@us.fujitsu.com]=20 >Sent: venerd=EC 22 marzo 2013 20.10 >To: Daniele Ceccarelli >Cc: CCAMP (ccamp@ietf.org) >Subject: Examples in draft-ietf-ccamp-gmpls-ospf-g709v3-05 > >Hi Daniele, > >I'm looking through the examples in Section 5.2 and have the=20 >following comments regarding the setting of TSG: > >1) Example Fig 8. This example has ODU1 -> ODU2 -> ODU3 > >I do not think the ODU1 TSG should be 1 (1.25/2.5G) since this=20 >ODU1 is not being advertised to support ODU0. In this case, I=20 >think TSG=3D0 (Ignored). > >2) Section 5.2.1, Fig 9. This example has ODU1 -> ODU2 -> ODU3. > >This example doesn't show the advertisement of all ODU rates.=20 >Because of this, I would recommend changing the Sig Type =3D=20 >ODU2 instead of ODU1 in both SCSIs in Fig 9. The reason is=20 >that it is the ODU2 (and perhaps the ODU3) that would support=20 >the different TSG values depending on [RFC 4328] vs G.709-2012=20 >with fallback disabled. > >3) Section 5.5, Figure 13. > >I believe the first Sig type=3DODU2 (where #stages=3D1,=20 >stages=3DODU4) should have the TSG =3D either 1 or 3. > >Note that this example is not consistent in populating the TSG=20 >fields for all ODU rates. I would recommend explicitly showing=20 >the TSG values for all ODU rates as this provides useful information. > >Best Regards, >Fred > > >= From francesco.fondelli@gmail.com Thu Apr 4 15:00:52 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A2B21F8F0E for ; Thu, 4 Apr 2013 15:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 sCXxjq07msJm for ; Thu, 4 Apr 2013 15:00:51 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E027721F8EDA for ; Thu, 4 Apr 2013 15:00:50 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id hj8so28144wib.1 for ; Thu, 04 Apr 2013 15:00:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=BL/5VOj67HewoLma+mrrw86xCUOLzy00fuFXj9z6r10=; b=P4mL9oYGgFsYK0fmDsjs2TT0AEhal9YCzPSqhCBbuoLTkoDwPSsjBuUSh2+6KH9N6U 799huJZSlbrpgREixG84gZS9NUIVkdY0k/3TBzWfWYa/L3lPXYYxtiZ9xZvfCCNbxt18 SQsgi7Kruv5UfcWYKu9Rku/F+weOunWOQXh29cJI+AKGSluh+hYM/92Hmpxj1hxe6z9D jOdfflKZuM4EpprEfKrUYlo4ZqWmIlFit+TEHNMoNtmHCi9lclUC57fxCQoMHjyAIMeS VqrhZUDU3QmiEINDxWGdgSRlnyPnymP5bU8CYV0k7Ec2Rh8MVd0962P4+msNb4wIi2GQ KZFg== MIME-Version: 1.0 X-Received: by 10.180.185.239 with SMTP id ff15mr162679wic.2.1365112850054; Thu, 04 Apr 2013 15:00:50 -0700 (PDT) Received: by 10.194.135.212 with HTTP; Thu, 4 Apr 2013 15:00:49 -0700 (PDT) In-Reply-To: References: Date: Fri, 5 Apr 2013 00:00:49 +0200 Message-ID: From: Francesco Fondelli To: "BRUNGARD, DEBORAH A" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 22:00:52 -0000 On Thu, Apr 4, 2013 at 4:49 PM, BRUNGARD, DEBORAH A wrote: > Hi Francesco, Hi Deborah, > That was a fast analysis:-) > > Suggest you first expand on the requirements that you want to support vs.= solution. When you detail aspects of SNC/N, SNC/I, and SNC/S, you will fin= d that you also need OAM configuration to support (N/I/S configuration (e.g= . DEG, TTI)) and you will need to configure which defects contribute to a "= failure". This will all need to be coordinated with the LSP OAM configurati= on. SNC sub-type has been introduced only recently in [4] and is a Zafar Ali's contribution; I think he can expand/elaborate this topic here on the list or in the next draft version. In my emails I was referring exclusively to hold off and wtr ([4] is about hold off and wtr since day zero: July, 2008), sorry if this was not clear. > Also on SNC/N, SNC/I, and SNC/S, is this for a segment or e-2-e? The draf= t needs more detail and alignment with GMPLS protection terminology and mec= hanisms. I think [4] addresses both e2e and segment (note: I'm talking about hold off and wtr). > After having a better scope of the requirements, we can discuss the solut= ion tradeoffs. There are always multiple ways to solve, first we need to un= derstand what is needed. The requirement is straightforward: in order to set up protection switching you need hold off and wtr. Either you use default values for any LSP on a given network (which is what is happening today) or you signal these values (hoff and wtr) on a per LSP basis. The draft tries to provide support for the latter. > Thanks, > Deborah thank you Ciao Fra > -----Original Message----- > From: Francesco Fondelli [mailto:francesco.fondelli@gmail.com] > Sent: Wednesday, April 03, 2013 12:59 PM > To: BRUNGARD, DEBORAH A > Cc: ccamp@ietf.org > Subject: Re: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps > > Hi Deborah, all, > >> Having said that, I have no problem rewriting [4] using OAM >> configuration TLV. It's just weird to me but I can live with it. > > sorry, I changed my mind, I cannot use the OAM TLV. The more I read > about OAM in IETF the more I think protection switching provisioning > is completely out-of-scope. > > I spent some hours looking for the OAM definition within the > IETF context(s). The most recent and enlightening (to me at least) > documents I found are [A] and [B]. As far as I understand, [1] is > perfectly aligned with them. At the same time I cannot find any > support of your statement: > >> Protection switching provisioning has always been treated as a >> common equipment management functionality [cut]. So it is in scope >> of OAM configuration. > > Maybe I'm just missing something big (?) Can someone shed some light on > this? > > thank you > ciao > fra > > [A] > http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08 > > [B] > http://tools.ietf.org/html/rfc6291 > > On Tue, Apr 2, 2013 at 11:22 AM, Francesco Fondelli > wrote: >> On Mon, Apr 1, 2013 at 8:06 PM, BRUNGARD, DEBORAH A wro= te: >>> Hi Francesco, >> >> Hi Deborah, >> >>> While these may be protection switching parameters, this draft is about= configuration of these parameters. Protection switching provisioning has a= lways been treated as a common equipment management functionality - same as= performance management and fault management (refer to G.7710 section 8). S= o it is in scope of OAM configuration. CCAMP's OAM configuration work has b= een focused on PM and FM but it is generally applicable (hopefully) to any = equipment management configuration. >> >> Puzzled. If we follow this reasoning (i.e. common equipment managemen= t >> functionalities =3D> should use OAM framework) then almost any aspect of >> networking can be applicable to OAM and so any operation should exploit >> the OAM framework draft. >> >> For example, G.7710 section 8.6.1 describes the provisioning >> of cross-connections but this does not imply that we are going to use th= e >> OAM framework to establish label binding in the next GMPLS controlled >> technology, I guess we will continue to use LABEL_REQUEST/LABEL objects >> (plus any other relevant info). >> >>> Lou's comment is that the WG has chosen the approach used in the OAM fr= amework document for configuration. Instead of updating the protection obje= ct at this time as your draft proposes, the question is have you considered= using the OAM configuration TLV? First, we need to understand why you have= chosen to not use this approach. Then we can discuss pros and cons. >> >> Well, at the beginning we did not take it into consideration >> because [4] predate [1]. Later we did not take [1] into consideration >> simply because we thought [4] was out of OAM framework scope. >> >> Having said that, I have no problem rewriting [4] using OAM >> configuration TLV. It's just weird to me but I can live with it. >> >>> BR- >>> Deborah >> >> thank you >> ciao >> fra >> >>> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of Francesco Fondelli >>> Sent: Monday, April 01, 2013 12:20 PM >>> To: ccamp@ietf.org >>> Subject: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps >>> >>> quoting item 15, from www.ietf.org/proceedings/86/minutes/minutes-86-cc= amp >>> >>> Lou Berger: I think you misunderstood my comment from the last meeting.= You >>> should look at leveraging the OAM configuration work which came after t= he >>> earlier versions of your draft. >>> Zafar Ali: this is applicable to multiple technologies. >>> Lou Berger: yes, the OAM configuration framework is also applicable to >>> multiple technologies. You need a strong reason not to follow the WG in >>> this area. Please look at the OAM configuration document >>> [draft-ietf-ccamp-oam-configuration-fwk] and either follow it or state = why >>> your work is justified in not following the existing WG solution in thi= s >>> area. >>> >>> --- >>> >>> Hi all, >>> >>> the OAM configuration framework [1] is about OAM. Therefore, it is u= sed in >>> order to signal OAM functionalities: CC/CV and PM/FM in MPLS-TP [2], CC= /CV >>> TTI/SAPI/DAPI in SONET/SDH/OTN [3]... while our draft [4] is about *pro= tection >>> switching*. HOFF, WTR and SNC sub-type are protection switching parame= ters. >>> >>> I believe HOFF, WTR and SNC sub-type are outside of the OAM configura= tion >>> framework scope and should be signaled as any other protection switchin= g >>> params (i.e. via PROTECTION object). >>> >>> I hope this answer Lou question reported above (item 15, IETF 86 ccam= p >>> minutes). Authors of [4] would like to understand WG's view about this= point >>> and are soliciting for comments. >>> >>> thank you >>> ciao >>> FF >>> >>> [1] >>> http://tools.ietf.org/html/draft-ietf-ccamp-oam-configuration-fwk-09 >>> >>> [2] >>> http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-11 >>> >>> [3] >>> http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-05 >>> >>> [4] >>> http://tools.ietf.org/html/draft-takacs-ccamp-revertive-ps-08 >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Thu Apr 4 15:06:10 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D2F21F8F7D for ; Thu, 4 Apr 2013 15:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 3jSy3rJCdQai for ; Thu, 4 Apr 2013 15:06:08 -0700 (PDT) Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id D5C1B21F8EF1 for ; Thu, 4 Apr 2013 15:06:08 -0700 (PDT) Received: (qmail 17288 invoked by uid 0); 4 Apr 2013 22:06:08 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy14.unifiedlayer.com with SMTP; 4 Apr 2013 22:06:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=yKIxDIDW9BwOLqN1DkO6+skt8sFg4tDm14g1bsMfA2I=; b=Ztq2yYgbqgLDiH7Axd8e7NZUc8/cFK9QnpHlcOnPQ/Khsi6s4qHSfm6Au7ReK+VInfO70dFgg3WHg4CB0LSiwXGD5S1K3W0zpWxpLuNs/1FZhjXLYXgBo+v6Mja6Ovxh; Received: from box313.bluehost.com ([69.89.31.113]:53129 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UNsIJ-0005OK-NR; Thu, 04 Apr 2013 16:06:08 -0600 Message-ID: <515DF956.1020305@labn.net> Date: Thu, 04 Apr 2013 18:06:14 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Leeyoung References: <8DC6547C806B644F998A0566E79E15920F7DFF60@DEMUMBX006.nsn-intra.net> <7AEB3D6833318045B4AE71C2C87E8E172911828D@dfweml511-mbs.china.huawei.com> <8DC6547C806B644F998A0566E79E15920F7E1284@DEMUMBX006.nsn-intra.net> <7AEB3D6833318045B4AE71C2C87E8E172911D7BA@dfweml511-mbs.china.huawei.com> <51471168.3000400@labn.net> <7AEB3D6833318045B4AE71C2C87E8E172911DC5E@dfweml511-mbs.china.huawei.com> <514895C5.7080300@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729121785@dfweml511-mbs.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729121785@dfweml511-mbs.china.huawei.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP , "draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org" Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 22:06:10 -0000 Young, Please see below. On 3/27/2013 1:59 PM, Leeyoung wrote: > Hi Lou, > > Please see my comments in-line. > > Thanks. > Young > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Tuesday, March 19, 2013 11:44 AM > To: Leeyoung > Cc: CCAMP; Margaria, Cyril (NSN - DE/Munich); draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org > Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 > > > Young, > See below. > On 3/18/2013 1:02 PM, Leeyoung wrote: >> Hi Lou, >> >> The encoding is a part of the Resource Block > > Understood, but my comment was more on the definition of > / encoding. > >> (that includes Regenerators and Wavelength converters) which is a WSON specific entity. > > So I agree that the need for transit nodes to have detailed encoding and > adaptation information to support 3R and certain other types of > switching is (at least to my understanding) specific to WSON. > Y> YOUNG>> RFC 3471 and RFC 4328 discuss G-PID as part of Generalized Y> Label Request parameters to indicate client/tributary layer of the Y> LSP at the source/sink. Y> Y> I was not clear on what you meant "trib side resources." If you meant Y> "trib side resources" are LSP encoding type, Switching Type and G-PID Y> (which are covered by RFC 3471/4328), I believe RFC 3471/4328 are Y> sufficient; if not could you elaborate? trib side = add/drop port at ingress/egress resources = attributes related to data that port can transport > > But unless I misunderstand the WSON info draft, this same information can be > advertised in support of the trib side resources (i.e., at the > source/destination for add/drop) and this is a generic requirement > shared with other technologies. > y> YOUNG>> Here you seemed to allude the need for advertizing the y> Source/Destination tributary resource information using IGP. In y> general, OSPF does not advertise the trib-side information, does it? y> I believe signaling check on the tributary resource info on LSP level y> is good enough per RFC 3471/4328. Please correct me if my y> understanding is wrong. I agree that that is how it is normally done, but WSON seems to be changing this in two respects: 1) By advertising G-PID at all, 2) By advertising add/drop ports, where prior GMPLS approaches have only advertised the network facing interfaces. Did I misunderstand the intent of mentioning drop ports in several places in Section 6 of the info document? > > So this lead me to ask about changing the G-PID list encoding to be > defined in the generic drafts (to facilitate PID advertisement for > non-WSON technologies.) Perhaps just having a generic encoding for a > G-PID list won't be of much value, but I suspect that we'll end up > needing it for other technologies too. > Y> YOUNG>> This point is carried from the above discussion. G-PID has Y> been specified to cover all GMPLS related technologies. Agreed that this is a derivative point and can wait until the above is clarified. > -- For what it's worth I am having some trouble understanding how G-PID > is advertised for add/drop. As far as I can tell, you have a > per add/drop port, mapped to , to a > and infer output G-PID from the . > At least that's how I'm reading the info draft. Y> YOUNG>> Actually G-PID is advertised as part of the Node Y> information: ::= [...] Y> [] Got that. That's what I was referring to when I said " mapped to " > > Look at the diagram below from info draft: > > I1 +-------------+ +-------------+ E1 > ----->| | +--------+ | |-----> > I2 | +------+ Rb #1 +-------+ | E2 > ----->| | +--------+ | |-----> > | | | | > | Resource | +--------+ | Resource | > | Pool +------+ +-------+ Pool | > | | + Rb #2 + | | > | Input +------+ +-------| Output | > | Connection | +--------+ | Connection | > | Matrix | . | Matrix | > | | . | | > | | . | | > IN | | +--------+ | | EM > ----->| +------+ Rb #P +-------+ |-----> > | | +--------+ | | > +-------------+ ^ ^ +-------------+ > | | > | | > | | > | | > > Input wavelength Output wavelength > constraints for constraints for > each resource each resource > > Figure 1 Schematic diagram of resource pool model. > > Add/Drop ports to/from Resource Pool (i.e., I1,...IN and E1,..EN) is > part of link information and advertised as link-TLV; however Resource > Blocks and its internal connectivity is not modeled as node property > as they are internal to Resource Pool. > > ::= ... > [...] [...] > [] > > We modeled how RB's are accessible via matrices (input/ouput), if > there are wavelength limitations and if RB's are available. All of > these are modeled as the node property. > > And within RBinfo, we included Input/Output Constraints where ClientSignalList (GPID) is specified. > > ::= ([] > [] )* > > Where > ::= [] > [] > > > > I was delaying asking if a couple of related questions until the above > was resolved, but perhaps it makes sense to ask them now: > - Shouldn't also be allowed under ? > > YOUNG>> It is implied. is checked in and has obviously the same property. We can add this comment to clarify. > So there is/will never (be) a case where the differ from the ? As you say, this certainly should be made explicit. > - Doesn't it make sense to simplify the add/drop G-PID identification by > adding somewhere under (generic) ? > y> YOUNG>> I think you meant doing this at the source/destination. sure, but aren't add/drop always at source/destination? (I guess you can come up with a case where they aren't, but this isn't the norm...) Y> Again y> I am not sure if we really need to advertise tributary client signal y> as link TLV. We have signaling mechanism to verify this. As you say, this point is covered above. > Thanks, > Lou > >> >> Regards, >> Young >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Monday, March 18, 2013 8:07 AM >> To: Leeyoung; CCAMP >> Cc: Margaria, Cyril (NSN - DE/Munich); draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >> Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 >> >> Young/All, >> >> Some of the discussions last week (on 709 and dimitri's) got me thinking >> more about the inclusion of G-PID on the wson specific encoding. As >> G-PID and other client/input information is not technology specific, and >> it looks like there's a likely a need for a general solution, shouldn't >> the G-PID (and other 'client/input') information be in >> draft-ietf-ccamp-general-constraint-encode? >> >> Thoughts? >> >> Lou >> >> On 3/15/2013 5:35 AM, Leeyoung wrote: >>> Thanks. >>> >>> Young >>> >>> -----Original Message----- >>> From: Margaria, Cyril (NSN - DE/Munich) [mailto:cyril.margaria@nsn.com] >>> Sent: Thursday, March 14, 2013 5:53 PM >>> To: Leeyoung; CCAMP; draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >>> Subject: RE: Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>> >>> >>> Hi, >>> >>> Thanks for the quick feedback. As this introduce a dependency with the GPID, >>> the text should indicate that the number of bit rate MUST match the number of GPID. >>> >>> Other than that I think this is acceptable >>> >>> >>> >>> Best regards / Mit freundlichen Grüßen >>> Cyril Margaria >>> >>> >>>> -----Original Message----- >>>> From: ext Leeyoung [mailto:leeyoung@huawei.com] >>>> Sent: Wednesday, March 13, 2013 9:33 PM >>>> To: Margaria, Cyril (NSN - DE/Munich); CCAMP; draft-ietf-ccamp-rwa- >>>> wson-encode@tools.ietf.org >>>> Subject: RE: Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>>> >>>> Hi Cyril, >>>> >>>> Thanks for your comment. >>>> >>>> This refers to the "Input Bit Rate" of the associated client Signal >>>> Type in the RB. >>>> Below is a new section 5.4 that defines Input Bit Rate List Sub-Sub- >>>> TLV. We removed "range" from this Sub-Sub-TLV. >>>> >>>> Let me know if this is acceptable. >>>> >>>> Thanks. >>>> Young >>>> >>>> --------------------------------------------------------------------- >>>> >>>> 5.4. Input Bit Rate List Sub-Sub-TLV >>>> >>>> This sub-sub-TLV contains a list of bit rate of each input client >>>> signal types specified in the Input Client Signal List Sub-Sub-TLV. >>>> Type := Input Bit Rate List >>>> Value := IEEE 32-bit IEEE Floating Point >>>> >>>> 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 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Input Bit Rate of GPID #1 | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> : : >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Input Bit Rate of GPID #N | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >>>> Of Margaria, Cyril (NSN - DE/Munich) >>>> Sent: Wednesday, March 13, 2013 8:54 AM >>>> To: CCAMP; draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >>>> Subject: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>>> >>>> Dear Authors, >>>> >>>> I have the following comments on draft-ietf-ccamp-rwa-wson-encode-19 >>>> >>>> Section 5.1 Resource Block Information Sub-TLV >>>> >>>> The sub-TLV format defines the "Input Bit Rate Range List Sub-Sub-TLV >>>> (opt)" >>>> No section defines the Input Bit range List Sub-Sub-TLV, while it was >>>> present in the previous version. >>>> >>>> I think the section should be re-added. >>>> >>>> >>>> Mit freundlichen Grüßen / Best Regards >>>> Cyril Margaria >>>> >>>> Nokia Siemens Networks Optical GmbH >>>> St.Martin-Str. 76 >>>> D-81541 München >>>> Germany >>>> mailto:cyril.margaria@nsn.com >>>> Phone: +49-89-5159-16934 >>>> Fax: +49-89-5159-44-16934 >>>> ---------------------------------------------------------------- >>>> Nokia Siemens Networks Optical GmbH >>>> Geschäftsleitung / Board of Directors: Gero Neumeier, Dr. Rolf Nauerz >>>> Sitz der Gesellschaft: München / Registered office: Munich >>>> Registergericht: München / Commercial registry: Munich, HRB 197143 >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >>> >>> >> >> >> >> > > > > From ietfc@btconnect.com Fri Apr 5 02:12:56 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E244921F96FF for ; Fri, 5 Apr 2013 02:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, 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 w0uc4b-pRo7C for ; Fri, 5 Apr 2013 02:12:55 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6489521F9705 for ; Fri, 5 Apr 2013 02:12:52 -0700 (PDT) Received: from mail181-tx2-R.bigfish.com (10.9.14.240) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.23; Fri, 5 Apr 2013 09:12:48 +0000 Received: from mail181-tx2 (localhost [127.0.0.1]) by mail181-tx2-R.bigfish.com (Postfix) with ESMTP id 589FC1A0886; Fri, 5 Apr 2013 09:12:48 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.197; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0710HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -18 X-BigFish: PS-18(zz9371I542Izz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah304l1155h) Received: from mail181-tx2 (localhost.localdomain [127.0.0.1]) by mail181-tx2 (MessageSwitch) id 1365153167189585_9298; Fri, 5 Apr 2013 09:12:47 +0000 (UTC) Received: from TX2EHSMHS038.bigfish.com (unknown [10.9.14.250]) by mail181-tx2.bigfish.com (Postfix) with ESMTP id 290E0420048; Fri, 5 Apr 2013 09:12:47 +0000 (UTC) Received: from DBXPRD0710HT001.eurprd07.prod.outlook.com (157.56.253.197) by TX2EHSMHS038.bigfish.com (10.9.99.138) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 5 Apr 2013 09:12:47 +0000 Received: from DBXPRD0611HT002.eurprd06.prod.outlook.com (157.56.254.85) by pod51017.outlook.com (10.255.79.164) with Microsoft SMTP Server (TLS) id 14.16.287.8; Fri, 5 Apr 2013 09:12:37 +0000 Message-ID: <00e801ce31dd$1785c820$4001a8c0@gateway.2wire.net> From: t.petch To: "BRUNGARD, DEBORAH A" , References: Date: Fri, 5 Apr 2013 10:00:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.254.85] X-FOPE-CRA-SourceIpAddress: 157.56.253.197 X-FOPE-CRA-DRYRUN: 1207119;1 X-FOPE-BFA-SENDER: ietfc@btconnect.com X-FOPE-BFA-RECEIVER: ccamp@ietf.org X-FOPE-BFA-RECEIVER: db3546@att.com X-OriginatorOrg: btconnect.com Subject: Re: [CCAMP] IETF-86 minutes posted X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 09:12:56 -0000 It is a shame that these minutes are formatted in Adobe Acrobat Control for ActiveX which my office PC regards as too dangerous to view:-( Tom Petch ----- Original Message ----- From: "BRUNGARD, DEBORAH A" To: Sent: Friday, March 29, 2013 4:01 PM Subject: [CCAMP] IETF-86 minutes posted Hi, Minutes from our meeting are posted: http://www.ietf.org/proceedings/86/minutes/minutes-86-ccamp Much thanks to our WG Secretaries, Dan and Daniele. Let us know if any comments- Deborah ------------------------------------------------------------------------ -------- > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From internet-drafts@ietf.org Sun Apr 7 20:50:26 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3602F21F9049; Sun, 7 Apr 2013 20:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.111, 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 q+MTbtVjqhZE; Sun, 7 Apr 2013 20:50:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 750C621F9033; Sun, 7 Apr 2013 20:50:25 -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.43.p3 Message-ID: <20130408035025.28093.1772.idtracker@ietfa.amsl.com> Date: Sun, 07 Apr 2013 20:50:25 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-signaling-g709v3-08.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 03:50:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Generalized Multi-Protocol Label Switching (GMPLS) Signa= ling Extensions for the evolving G.709 Optical Transport Networks Control Author(s) : Fatai Zhang Guoying Zhang Sergio Belotti Daniele Ceccarelli Khuzema Pithewan Filename : draft-ietf-ccamp-gmpls-signaling-g709v3-08.txt Pages : 27 Date : 2013-04-07 Abstract: ITU-T Recommendation G.709 [G709-2012] has introduced new Optical channel Data Unit (ODU) containers (ODU0, ODU4, ODU2e and ODUflex) and enhanced Optical Transport Networking (OTN) flexibility. This document updates RFC4328 to provide the extensions to the Generalized Multi-Protocol Label Switching (GMPLS) signaling to control the evolving OTN addressing ODUk multiplexing and new features including ODU0, ODU4, ODU2e and ODUflex. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-signaling-g709v3 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-gmpls-signaling-g709v3-= 08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From zhangfatai@huawei.com Sun Apr 7 20:53:52 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B92221F8556 for ; Sun, 7 Apr 2013 20:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 1T+yIRcCFMrb for ; Sun, 7 Apr 2013 20:53:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6E47521F8546 for ; Sun, 7 Apr 2013 20:53:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AQD77258; Mon, 08 Apr 2013 03:53:50 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 8 Apr 2013 04:53:23 +0100 Received: from SZXEML449-HUB.china.huawei.com (10.82.67.192) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 8 Apr 2013 04:53:46 +0100 Received: from SZXEML552-MBS.china.huawei.com ([169.254.2.42]) by szxeml449-hub.china.huawei.com ([10.82.67.192]) with mapi id 14.01.0323.007; Mon, 8 Apr 2013 11:53:41 +0800 From: Fatai Zhang To: "ccamp@ietf.org" Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-signaling-g709v3-08.txt Thread-Index: AQHONAw7JlWdkZhkDkOFVW+MVc3MFZjLsHfQ Date: Mon, 8 Apr 2013 03:53:40 +0000 Message-ID: References: <20130408035025.28093.1772.idtracker@ietfa.amsl.com> In-Reply-To: <20130408035025.28093.1772.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-signaling-g709v3-08.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 03:53:52 -0000 Hi all, A new version has been posted. Major changes are as follows: (1) Removed "Tolerance" field as the WG agreed in the Orlando meeting. (2) Addressed some missed minor comments.=20 Best Regards Fatai -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org Sent: Monday, April 08, 2013 11:50 AM To: i-d-announce@ietf.org Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-signaling-g709v3-08.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Generalized Multi-Protocol Label Switching (GMPLS) Signa= ling Extensions for the evolving G.709 Optical Transport Networks Control Author(s) : Fatai Zhang Guoying Zhang Sergio Belotti Daniele Ceccarelli Khuzema Pithewan Filename : draft-ietf-ccamp-gmpls-signaling-g709v3-08.txt Pages : 27 Date : 2013-04-07 Abstract: ITU-T Recommendation G.709 [G709-2012] has introduced new Optical channel Data Unit (ODU) containers (ODU0, ODU4, ODU2e and ODUflex) and enhanced Optical Transport Networking (OTN) flexibility. This document updates RFC4328 to provide the extensions to the Generalized Multi-Protocol Label Switching (GMPLS) signaling to control the evolving OTN addressing ODUk multiplexing and new features including ODU0, ODU4, ODU2e and ODUflex. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-signaling-g709v3 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-gmpls-signaling-g709v3-= 08 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 From scott.mansfield@ericsson.com Mon Apr 8 22:43:06 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDE921F8B49; Mon, 8 Apr 2013 22:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 VhaQsScqWfh0; Mon, 8 Apr 2013 22:43:05 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 1D31521F8B25; Mon, 8 Apr 2013 22:43:05 -0700 (PDT) X-AuditID: c6180641-b7faf6d00000096b-1c-5163aa684908 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id C4.8B.02411.86AA3615; Tue, 9 Apr 2013 07:43:04 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.004; Tue, 9 Apr 2013 01:43:03 -0400 From: Scott Mansfield To: "mpls@ietf.org" Thread-Topic: MPLS related liaison from ITU-T SG15 Thread-Index: Ac405Rmb3zdg4nn9RKG+pm3W94QHWg== Date: Tue, 9 Apr 2013 05:43:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_EF35EE4B92789843B1DECBC0E24558642195EDeusaamb105ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyuXRPuG7GquRAg6vL5S2ezLnBYnFr6UpW i75PW1gcmD2WLPnJFMAYxWWTkpqTWZZapG+XwJWxavVHloKPEhX79y1jamDsEuti5OSQEDCR +Lmwix3CFpO4cG89WxcjF4eQwFFGieczd7JDOMsYJW7fe88MUsUG1LF113RGEFtEQFniyMRu VhCbWcBN4svj/0ANHBzCAroSrXfYIUqMJPZfW8EGYetJnFl1hQnEZhFQkdjT2gHWyivgLXH+ 3DmwOCPQEd9PrWGCGCkucevJfCaI4wQkluw5zwxhi0q8fPyPFcJWlvg+5xELRH2+xNsDe6Bm CkqcnPmEZQKj8Cwko2YhKZuFpAwiriOxYPcnNghbW2LZwtfMMPaZA4+ZkMUXMLKvYuQoLU4t y003MtzECIySYxJsjjsYF3yyPMQozcGiJM4b6nohQEggPbEkNTs1tSC1KL6oNCe1+BAjEwen VAOjGtdikXM268X0NT/P3/xzn6/q/Cc5L3hWTtv7Ykl/3Qc395jS9yefPwrI8HhsKZhx/Mvk ohds5zrrH6smzvPPXNHob+vDHr1kfobjfS9/42u7Hra9ehNTzb1k3rSfRonXMg0E7QoezS74 enGxMvcl+XNct8XjBBLL2B9yHpaRPsl2gsl66uQzSizFGYmGWsxFxYkAtGclxWACAAA= Cc: "ccamp@ietf.org" , "pwe3@ietf.org" Subject: [CCAMP] MPLS related liaison from ITU-T SG15 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 05:43:06 -0000 --_000_EF35EE4B92789843B1DECBC0E24558642195EDeusaamb105ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see the informational liaison http://datatracker.ietf.org/liaison/12= 49/ from the ITU-T SG15. The liaison provides a list of the new and revised MPLS-TP related document= s that will enter the approval process at the next SG15 plenary meeting (1-= 15 July 2013). Regards, -scott. Scott Mansfield Ericsson Inc. +1 724 931 9316 --_000_EF35EE4B92789843B1DECBC0E24558642195EDeusaamb105ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Please see the informational liaison http://datatracker.ietf.org/liaison/1249/ from the ITU-T SG15.

The liaison provides a list of the new and revised M= PLS-TP related documents that will enter the approval process at the next S= G15 plenary meeting (1-15 July 2013).

 

Regards,

-scott.

 

Scott Mansfield

Ericsson Inc.

+1 724 931 9316

 

--_000_EF35EE4B92789843B1DECBC0E24558642195EDeusaamb105ericsso_-- From stbryant@cisco.com Tue Apr 9 00:23:29 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB8C21F905A; Tue, 9 Apr 2013 00:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMOJvsdyt-CV; Tue, 9 Apr 2013 00:23:27 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 188AC21F9184; Tue, 9 Apr 2013 00:23:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4228; q=dns/txt; s=iport; t=1365492201; x=1366701801; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=MRxN+5O822QUVAplYSQ6kr6A21D+WUNm3c3M/NLGBfg=; b=MtjCSzbmC6oHPhBS+7n6oDmN/n8b/CWiDqKPp5IbcGB9XLax4aRE6nDh 4sG0DKFCcri8BJ3kKaNlaF8VvKEEDY1F4Oybn+GakfgGEjxzoOYRqqHSX QSBLsRYXSMb3Wq+FnK8TXP89ZlMwVTNrsbyKd/Vqeh84xzgE+vJSmYhfk c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAP3AY1GQ/khR/2dsb2JhbABOA4JCRDaJCbg3gREWdIIfAQEBBAEBASpBCgEQCxgJFg8JAwIBAgEVMAYNAQUCAQGIEAytVpAviQqGCBAHEYMwA5Z0gSGPbIMM X-IronPort-AV: E=Sophos;i="4.87,436,1363132800"; d="scan'208,217";a="81852224" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 09 Apr 2013 07:23:14 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r397NCAM014048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Apr 2013 07:23:12 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r397NB4a004176; Tue, 9 Apr 2013 08:23:11 +0100 (BST) Message-ID: <5163C1DF.1080006@cisco.com> Date: Tue, 09 Apr 2013 08:23:11 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Scott Mansfield References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020106090003050807050009" Cc: "mpls@ietf.org" , "ccamp@ietf.org" , "pwe3@ietf.org" Subject: Re: [CCAMP] [mpls] MPLS related liaison from ITU-T SG15 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 07:23:29 -0000 This is a multi-part message in MIME format. --------------020106090003050807050009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/04/2013 06:43, Scott Mansfield wrote: > > Please see the informational liaison > http://datatracker.ietf.org/liaison/1249/ > from the ITU-T SG15. > > The liaison provides a list of the new and revised MPLS-TP related > documents that will enter the approval process at the next SG15 > plenary meeting (1-15 July 2013). > > Regards, > > -scott. > > Scott Mansfield > > Ericsson Inc. > > +1 724 931 9316 > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls Scott, I see a list of document names, but no document text to review. Stewart --------------020106090003050807050009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 09/04/2013 06:43, Scott Mansfield wrote:

 

Please see the informational liaison http://datatracker.ietf.org/liaison/1249/ from the ITU-T SG15.

The liaison provides a list of the new and revised MPLS-TP related documents that will enter the approval process at the next SG15 plenary meeting (1-15 July 2013).

 

Regards,

-scott.

 

Scott Mansfield

Ericsson Inc.

+1 724 931 9316

 



_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Scott, I see a list of document names, but no document text to review.

Stewart
--------------020106090003050807050009-- From scott.mansfield@ericsson.com Tue Apr 9 01:37:48 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F58C21F8F24; Tue, 9 Apr 2013 01:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 PSrbSI8k62Gu; Tue, 9 Apr 2013 01:37:47 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4D821F88BF; Tue, 9 Apr 2013 01:37:47 -0700 (PDT) X-AuditID: c618062d-b7f0d6d00000097e-b2-5163d35a5227 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 7E.47.02430.A53D3615; Tue, 9 Apr 2013 10:37:46 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.004; Tue, 9 Apr 2013 04:37:45 -0400 From: Scott Mansfield To: "stbryant@cisco.com" Thread-Topic: [mpls] MPLS related liaison from ITU-T SG15 Thread-Index: Ac405Rmb3zdg4nn9RKG+pm3W94QHWgAL4SWAAAYB3xA= Date: Tue, 9 Apr 2013 08:37:44 +0000 Message-ID: References: <5163C1DF.1080006@cisco.com> In-Reply-To: <5163C1DF.1080006@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_EF35EE4B92789843B1DECBC0E2455864219FE2eusaamb105ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyuXRPuG7U5eRAg5M/ZS2ezLnBYnFr6UpW i75PW1gszj2dw+jA4jHl90ZWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZSzYdZC9oMe6YuW6/awN jOeNuxg5OCQETCR2LM3uYuQEMsUkLtxbz9bFyMUhJHCUUeLs5Z+sIAkhgWWMEgs/m4PYbED1 W3dNZwSxRQR0JWZvuAFmMwtkSqw6fIcNxBYWsJCY+WoyE0SNpcThFfOYIWwriebHT8HiLAIq Ek+u/mABsXkFvCUOHdnHDLErS2LBvedsILdxCmhK7LhsCxJmBLrt+6k1TBCrxCVuPZnPBHGz gMSSPeeZIWxRiZeP/7FC2MoS3+c8YoGoz5eYufwtM8QqQYmTM5+wTGAUnYVk1CwkZbOQlEHE dSQW7P7EBmFrSyxb+JoZxj5z4DETsvgCRvZVjBylxalluelGBpsYgVF2TIJNdwfjnpeWhxil OViUxHmDXC8ECAmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDsMOzvSi62e9nH1ya49sfhLf3z X9UYvV37qDzd587J2MjMKU627+8UxPEZFEz8aM97MWKPmHL2gY/xn87OSVNbHC+4knVO2AIx 9YTML3+X+Gcyhy2dqxjj/iibuyDqcXjaG53Fy1RqTpyffUqh/YPatuNzY6zUN1z9oF76QcLo T1Tl/ursdRZKLMUZiYZazEXFiQDYg4HAgAIAAA== Cc: "mpls@ietf.org" , "ccamp@ietf.org" , "pwe3@ietf.org" Subject: Re: [CCAMP] [mpls] MPLS related liaison from ITU-T SG15 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 08:37:48 -0000 --_000_EF35EE4B92789843B1DECBC0E2455864219FE2eusaamb105ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The liaison is simply listing the documents that will be considered at the = meeting. The text will be available about 1 month before the meeting. The= text was not liaised, as the liaison states, the normal ITU-T process will= be used. Which means that only members of the ITU will have access to the= text and have the ability to comment. We can try asking for access for no= n-ITU-T members if there is interest in reviewing the documents. We can ex= ercise section 2.4 of RFC 6756 for those that are not ITU-T members, but th= is will have to be done on a case-by-case basis. Regards, -scott. From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Tuesday, April 09, 2013 3:23 AM To: Scott Mansfield Cc: mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org Subject: Re: [mpls] MPLS related liaison from ITU-T SG15 On 09/04/2013 06:43, Scott Mansfield wrote: Please see the informational liaison http://datatracker.ietf.org/liaison/12= 49/ from the ITU-T SG15. The liaison provides a list of the new and revised MPLS-TP related document= s that will enter the approval process at the next SG15 plenary meeting (1-= 15 July 2013). Regards, -scott. Scott Mansfield Ericsson Inc. +1 724 931 9316 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls Scott, I see a list of document names, but no document text to review. Stewart --_000_EF35EE4B92789843B1DECBC0E2455864219FE2eusaamb105ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The liaison is simply = listing the documents that will be considered at the meeting.  The tex= t will be available about 1 month before the meeting.  The text was no= t liaised, as the liaison states, the normal ITU-T process will be used.  Which means that only members of the ITU will = have access to the text and have the ability to comment.  We can try a= sking for access for non-ITU-T members if there is interest in reviewing th= e documents.  We can exercise section 2.4 of RFC 6756 for those that are not ITU-T members, but this will have to be= done on a case-by-case basis.

 

Regards,

-scott.

 

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Tuesday, April 09, 2013 3:23 AM
To: Scott Mansfield
Cc: mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org
Subject: Re: [mpls] MPLS related liaison from ITU-T SG15<= /span>

 

On 09/04/2013 06:43, Scott Mansfield wrote:

 

Please see the informational liaison http://datatracker.ietf.org/liaison/1249/ from the ITU-T SG15.

The liaison provides a list of the new and revised M= PLS-TP related documents that will enter the approval process at the next S= G15 plenary meeting (1-15 July 2013).

 

Regards,

-scott.

 

Scott Mansfield

Ericsson Inc.

+1 724 931 9316

 




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

Scott, I see a list of document name= s, but no document text to review.

Stewart

--_000_EF35EE4B92789843B1DECBC0E2455864219FE2eusaamb105ericsso_-- From stbryant@cisco.com Tue Apr 9 02:34:30 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D6E21F91B7; Tue, 9 Apr 2013 02:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dI2x4XcPa019; Tue, 9 Apr 2013 02:34:29 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 6923621F913C; Tue, 9 Apr 2013 02:34:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10177; q=dns/txt; s=iport; t=1365500068; x=1366709668; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=8aMBvqdgZ2tknEB9/WnaoEdaUkvDh1PW7ZAszJ37AO4=; b=DHfHisrERuDTPUpuF0R3/gkSBuwgV9hJCwHtYHkAuW4mj2Oaj3e1Et7y 8R3mMRsvM6vfYpvPfz14VLh5dC7XiBoQPmvLOIteznGQMxzupPQvaUS0Z ztjA78NkdZ/eNYWtqZbzEXLWY1mVsVxcLCbvKs+5QfdZd2ditMcRgqiOi c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAHzfY1GQ/khM/2dsb2JhbABOA4JCRDaJCbg3gRIWdIIfAQEBBAEBASpBCgEQCxEEAQEBCRYIBwkDAgECARUfCQgGDQEFAgEBiBAMrgOQPYkKhggFCwYBEYMwA5Z0gSGPbIMM X-IronPort-AV: E=Sophos;i="4.87,437,1363132800"; d="scan'208,217";a="13203158" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 09 Apr 2013 09:34:27 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r399YPk4005455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Apr 2013 09:34:25 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r399YNSC010508; Tue, 9 Apr 2013 10:34:24 +0100 (BST) Message-ID: <5163E09F.4060105@cisco.com> Date: Tue, 09 Apr 2013 10:34:23 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Scott Mansfield References: <5163C1DF.1080006@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000907090609060609030206" Cc: "mpls@ietf.org" , "ccamp@ietf.org" , "pwe3@ietf.org" Subject: Re: [CCAMP] [mpls] MPLS related liaison from ITU-T SG15 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 09:34:30 -0000 This is a multi-part message in MIME format. --------------000907090609060609030206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit So I believe the correct response is: Thank you for your liaison. Please can you make the text of these documents available to the IETF in sufficient time that members of the IETF who are not also members of the ITU can pass any review comments that they have to IETF colleagues who are members of the ITU for possible incorporation into their own review comments. - Stewart On 09/04/2013 09:37, Scott Mansfield wrote: > > The liaison is simply listing the documents that will be considered at > the meeting. The text will be available about 1 month before the > meeting. The text was not liaised, as the liaison states, the normal > ITU-T process will be used. Which means that only members of the ITU > will have access to the text and have the ability to comment. We can > try asking for access for non-ITU-T members if there is interest in > reviewing the documents. We can exercise section 2.4 of RFC 6756 for > those that are not ITU-T members, but this will have to be done on a > case-by-case basis. > > Regards, > > -scott. > > *From:*Stewart Bryant [mailto:stbryant@cisco.com] > *Sent:* Tuesday, April 09, 2013 3:23 AM > *To:* Scott Mansfield > *Cc:* mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org > *Subject:* Re: [mpls] MPLS related liaison from ITU-T SG15 > > On 09/04/2013 06:43, Scott Mansfield wrote: > > Please see the informational liaison > http://datatracker.ietf.org/liaison/1249/ > from the ITU-T SG15. > > The liaison provides a list of the new and revised MPLS-TP related > documents that will enter the approval process at the next SG15 > plenary meeting (1-15 July 2013). > > Regards, > > -scott. > > Scott Mansfield > > Ericsson Inc. > > +1 724 931 9316 > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > Scott, I see a list of document names, but no document text to review. > > Stewart > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------000907090609060609030206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
So I believe the correct response is:

Thank you for your liaison.

Please can you make the text of these documents available to the IETF in sufficient time that members of the IETF who are not also members of the ITU can pass any review comments that they have to IETF colleagues who are members of the ITU for possible incorporation into their own review comments.

- Stewart



On 09/04/2013 09:37, Scott Mansfield wrote:

The liaison is simply listing the documents that will be considered at the meeting.  The text will be available about 1 month before the meeting.  The text was not liaised, as the liaison states, the normal ITU-T process will be used.  Which means that only members of the ITU will have access to the text and have the ability to comment.  We can try asking for access for non-ITU-T members if there is interest in reviewing the documents.  We can exercise section 2.4 of RFC 6756 for those that are not ITU-T members, but this will have to be done on a case-by-case basis.

 

Regards,

-scott.

 

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Tuesday, April 09, 2013 3:23 AM
To: Scott Mansfield
Cc: mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org
Subject: Re: [mpls] MPLS related liaison from ITU-T SG15

 

On 09/04/2013 06:43, Scott Mansfield wrote:

 

Please see the informational liaison http://datatracker.ietf.org/liaison/1249/ from the ITU-T SG15.

The liaison provides a list of the new and revised MPLS-TP related documents that will enter the approval process at the next SG15 plenary meeting (1-15 July 2013).

 

Regards,

-scott.

 

Scott Mansfield

Ericsson Inc.

+1 724 931 9316

 




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

Scott, I see a list of document names, but no document text to review.

Stewart



-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------000907090609060609030206-- From adrian@olddog.co.uk Tue Apr 9 07:52:27 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C9A21F936F for ; Tue, 9 Apr 2013 07:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 5wTf-kjdVLwa for ; Tue, 9 Apr 2013 07:52:11 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 4460E21F9322 for ; Tue, 9 Apr 2013 07:52:07 -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 r39Eq5se024983 for ; Tue, 9 Apr 2013 15:52:05 +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 r39Eq4gn024957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 9 Apr 2013 15:52:04 +0100 From: "Adrian Farrel" To: Date: Tue, 9 Apr 2013 15:52:03 +0100 Message-ID: <012d01ce3531$cc8486b0$658d9410$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac41MV8b00K+7cA2RLOIjZH7fan4Bg== Content-Language: en-gb Subject: [CCAMP] FW: New Version Notification for draft-farrkingel-ccamp-flexigrid-lambda-label-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 14:52:27 -0000 Hi, Just FYI. We continue to apply layer after layer of polish to this document while = we wait for the WG to start its forward charge on flexible lamdas. Adrian > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 09 April 2013 15:40 > To: adrian@olddog.co.uk > Cc: daniel@olddog.co.uk; wsliguotou@hotmail.com > Subject: New Version Notification for = draft-farrkingel-ccamp-flexigrid-lambda- > label-06.txt >=20 >=20 > A new version of I-D, = draft-farrkingel-ccamp-flexigrid-lambda-label-06.txt > has been successfully submitted by Adrian Farrel and posted to the > IETF repository. >=20 > Filename: draft-farrkingel-ccamp-flexigrid-lambda-label > Revision: 06 > Title: Generalized Labels for the Flexi-Grid in Lambda Switch = Capable > (LSC) Label Switching Routers > Creation date: 2013-04-09 > Group: Individual Submission > Number of pages: 10 > URL: = http://www.ietf.org/internet-drafts/draft-farrkingel-ccamp-flexigrid- > lambda-label-06.txt > Status: = http://datatracker.ietf.org/doc/draft-farrkingel-ccamp-flexigrid- > lambda-label > Htmlized: = http://tools.ietf.org/html/draft-farrkingel-ccamp-flexigrid-lambda- > label-06 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-farrkingel-ccamp-flexigrid- > lambda-label-06 >=20 > Abstract: > GMPLS supports the description of optical switching by identifying > entries in fixed lists of switchable wavelengths (called grids) > through the encoding of lambda labels. Work within the ITU-T Study > Group 15 has defined a finer granularity grid, and the facility to > flexibly select different widths of spectrum from the grid. This > document defines a new GMPLS lambda label format to support this > flexi-grid. >=20 > This document updates RFC 3471 and RFC 6205 by introducing a new > label format. >=20 >=20 >=20 >=20 > The IETF Secretariat From lberger@labn.net Tue Apr 9 14:53:23 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306AF21F997F for ; Tue, 9 Apr 2013 14:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.665 X-Spam-Level: X-Spam-Status: No, score=-101.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=0.6, 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 uk8keHRPhSfU for ; Tue, 9 Apr 2013 14:53:22 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 868E821F9980 for ; Tue, 9 Apr 2013 14:53:22 -0700 (PDT) Received: (qmail 8605 invoked by uid 0); 9 Apr 2013 21:52:53 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 9 Apr 2013 21:52:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=zynnOpIAk9hDePj3D05nH5Ed1Sp85zb9LAVfAXfBteQ=; b=Lw1hG2bDw3cUDFT3jjgzfaMrKQSk422tdCMErkcE2zE13Xph6d6TGkGQimLfZ4Io1WutEsu00zjbaqXAf/G4O58a7r9n9VlbF6WjLubG6xi7Qmay7VC7v1Mn3U1S/Nru; Received: from box313.bluehost.com ([69.89.31.113]:53154 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UPgTE-0007xl-Uz; Tue, 09 Apr 2013 15:52:53 -0600 Message-ID: <51648DB4.2070708@labn.net> Date: Tue, 09 Apr 2013 17:52:52 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "t.petch" References: <00e801ce31dd$1785c820$4001a8c0@gateway.2wire.net> In-Reply-To: <00e801ce31dd$1785c820$4001a8c0@gateway.2wire.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ccamp@ietf.org Subject: Re: [CCAMP] IETF-86 minutes posted X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 21:53:23 -0000 Yuck! Apologies, now fixed. On 4/5/2013 5:00 AM, t.petch wrote: > It is a shame that these minutes are formatted in > Adobe Acrobat Control for ActiveX > which my office PC regards as too dangerous to view:-( > > Tom Petch > > > ----- Original Message ----- > From: "BRUNGARD, DEBORAH A" > To: > Sent: Friday, March 29, 2013 4:01 PM > Subject: [CCAMP] IETF-86 minutes posted > > > Hi, > > Minutes from our meeting are posted: > http://www.ietf.org/proceedings/86/minutes/minutes-86-ccamp > > Much thanks to our WG Secretaries, Dan and Daniele. > > Let us know if any comments- > Deborah > > > > > > ------------------------------------------------------------------------ > -------- > > >> _______________________________________________ >> 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 > > > > From kpithewan@infinera.com Fri Apr 12 04:12:34 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21DCC21F859C for ; Fri, 12 Apr 2013 04:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 STITdo24i+L0 for ; Fri, 12 Apr 2013 04:12:30 -0700 (PDT) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3412D21F8539 for ; Fri, 12 Apr 2013 04:12:29 -0700 (PDT) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.02.0342.003; Fri, 12 Apr 2013 04:12:29 -0700 From: Khuzema Pithewan To: Igor Bryskin , Dieter Beller , Vishnu Pavan Beeram Thread-Topic: [CCAMP] MELGs - Q&A Thread-Index: AQHOIGPek8R0zdnmbUizkEjN3z7415ivh4owgAA2TQCAATLDIIAAeV3g///IfQCABM8nkIABeO8AgAELY4CAGhSNwA== Date: Fri, 12 Apr 2013 11:12:28 +0000 Message-ID: References: <5150C704.2040007@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: multipart/alternative; boundary="_000_D8D01B39D6B38C45AA37C06ECC1D65D53FCEC067SVEXDBPROD1infi_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] MELGs - Q&A X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 11:12:34 -0000 --_000_D8D01B39D6B38C45AA37C06ECC1D65D53FCEC067SVEXDBPROD1infi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Igor, If my understanding of MELG is correct, It works only (or has use only) for= a specific case of centralized parallel path computation in 2 layer networ= k. 1. When Network has more than 2 layer i.e. Packet-OTN-DWDM, the Packe= t (client) layer will be talking to its immediate server layer i.e. OTN, wh= ich in turn is talking to DWDM layer. Using MELG, client layer path computa= tion can take care of resource exclusivity of virtual link for immediate se= rver layer i.e. OTN layer. However if there is resource exclusivity at DWD= M layer, this mechanism doesn't work. You need to do loose routing or use d= istributed PCE model 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. Thanks Khuzema From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of I= gor Bryskin Sent: Tuesday, March 26, 2013 7:19 PM To: Dieter Beller; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Dieter, You said: >> I guess we are coming back to the essential point: "and how often concur= rent path computation will be >> used." To be honest, this surprises me quite a bit, Let me give you some of many r= easons as to why concurrent path computations are needed and why this is be= tter than computing one path at a time: 1. Computing several diverse paths for the same service in the context= of service recovery. I hope you realize that computing one path at a time = on many configurations produces no or sub-optimal results. I also hope you = realize the problem of selecting two paths with one of them having a link = with common MELG with a link from another path; 2. Computing paths for multiple services to be sufficiently disjoint f= rom each other; 3. Computing paths for multiple services to achieve a global optimizat= ion criteria (e.g. minimal summary total cost); 4. Computing paths for multiple services for the purpose of removing t= he bandwidth fragmentations; 5. Computing paths for multiple services to plan shared mesh protectio= n/restoration schemes 6. Etc. Also think about this: 1. If concurrent path computation was not important, why PCEP includes= the machinery to do that? 2. My understanding of the statefull PCE is that it does pretty much n= othing but concurrent path computations You also said: >> I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the >> TE-DB, MELG routing extensions are not needed because the information ab= out mutual >>exclusive VLs can be kept in the central TE-DB when VLs are configured. How this logic does not apply to other link attributes such as SRLGs? What if path computation is not centralized? Cheers, Igor From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of D= ieter Beller Sent: Monday, March 25, 2013 5:52 PM To: Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Hi Pavan, On 25.03.2013 07:29, Fatai Zhang wrote: Hi Pavan, I am not sure how much VL (Virtual Link) will be used in the practical depl= oyment and how often concurrent path computation will be used. I guess we are coming back to the essential point: "and how often concurren= t path computation will be used." This means we are trying to figure out under which conditions MELG routing = extensions could be beneficial. IMHO, they would only make sense, if: * a path computation function supports the calculation of k shortest pa= ths concurrently * if there is only a single path computation function instance per doma= in (pce approach) If path computation is done in a distributed fashion the benefit goes away = because the instances calculate paths independently! I suppose that if a pce approach is used, i.e., path computation is central= ized including the TE-DB, MELG routing extensions are not needed because the information about= mutual exclusive VLs can be kept in the central TE-DB when VLs are configured. Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their applicability is broader. Thanks, Dieter Do you think if it makes sense to add a flag (in routing advertisement) to = indicate a link is a VL or not? Best Regards Fatai From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, March 22, 2013 8:57 PM To: Fatai Zhang Cc: Igor Bryskin; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Fatai, Hi! Good to see that you understand the construct now. This is not a corner case. The utility of the construct becomes quite signi= ficant if you have an application that does concurrent path computations on= an abstract topology. Regards, -Pavan _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp -- DIETER BELLER ALCATEL-LUCENT DEUTSCHLAND AG PROJECT MANAGER ASON/GMPLS CONTROL PLANE CORE NETWORKS BUSINESS DIVISION OPTICS BU, SWITCHING R&D Lorenzstrasse 10 70435 Stuttgart, Germany Phone: +49 711 821 43125 Mobil: +49 175 7266874 Dieter.Beller@alcatel-lucent.com Alcatel-Lucent Deutschland AG Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026 Chairman of the Supervisory Board: Michael Oppenhoff Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe --_000_D8D01B39D6B38C45AA37C06ECC1D65D53FCEC067SVEXDBPROD1infi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Igor,

 <= /p>

If my understanding of ME= LG is correct, It works only (or has use only) for a specific case of centralized parallel path computation in 2 layer network.=

 <= /p>

1.  &= nbsp;    When Network has = more than 2 layer i.e. Packet-OTN-DWDM, the Packet (client) layer will be t= alking to its immediate server layer i.e. OTN, which in turn is talking to DWDM layer. Using MELG, client layer path computation c= an take care of resource exclusivity of virtual link for immediate server l= ayer i.e. OTN layer.  However if there is resource exclusivity at DWDM= layer, this mechanism doesn’t work. You need to do loose routing or use distributed PCE model

2.  &= nbsp;    For cases of conc= urrent computation (case#2-5), you are mainly talking about global optimiza= tion and diversity among multiple services. You can do the path computation, but to actually enact the computed path the signalin= g needs to be done from the source end of those LSPs.  So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a problem to be solved by network management/planni= ng software.

 <= /p>

Thanks<= /p>

Khuzema

 <= /p>

 <= /p>

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf= .org] On Behalf Of Igor Bryskin
Sent: Tuesday, March 26, 2013 7:19 PM
To: Dieter Beller; Vishnu Pavan Beeram
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Dieter,=

 <= /p>

You said:

>> I guess we are coming back to the essential= point: "and how often concurrent path comp= utation will be >> used."

 

To be honest, this surprises me quite a bit, Let me = give you some of many reasons as to why concurrent path computations are ne= eded and why this is better than computing one path at a time:

 

1.      Computing several diverse paths for the same servic= e in the context of service recovery. I hope you realize that computing one= path at a time on many configurations produces no or sub-optimal results. = I also hope you realize the problem of selecting two paths with one of them  having a link with common ME= LG with a link from another path;

2.      Computing paths for multiple services to be suffici= ently disjoint from each other;

3.      Computing paths for multiple services to achieve a = global optimization criteria (e.g. minimal summary total cost);<= /p>

4.      Computing paths for multiple services for the purpo= se of removing the bandwidth fragmentations;

5.      Computing paths for multiple services to plan share= d mesh protection/restoration schemes

6.      Etc.

 

Also think about this:

1.      If concurrent path computation was not important, w= hy PCEP includes the machinery to do that?

2.      My understanding of the statefull PCE is that it do= es pretty much nothing but concurrent path computations

 

You also said:

>> I suppose th= at if a pce approach is used, i.e., path computation is centralized includi= ng the
>> TE-DB, MELG routing extensions are not needed because the informat= ion about mutual
>>exclusive VLs can be kept in the central TE-DB when VLs are configu= red.

How this logic does not apply to other link attribut= es such as SRLGs?

What if path computation is not centralized?

 

Cheers,

Igor

 <= /p>

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf= .org] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Hi Pavan,

On 25.03.2013 07:29, Fatai Zhang wrote:

Hi Pavan,

 <= /p>

I am not sure how much VL= (Virtual Link) will be used in the practical deployment and how often conc= urrent path computation will be used.

I guess we are coming back to the essential point: &= quot;and how often concurrent path computation w= ill be used."

This means we are trying to figure out under which conditions MELG routing = extensions
could be beneficial.

IMHO, they would only make sense, if:

  • a path computation function supports the calculation of k shortest paths co= ncurrently
  • if there is only a single path computation function instance per domain (pc= e approach)
    If path computation is done in a distributed fashion the benefit goes away = because
    the instances calculate paths independently!

I suppose that if a p= ce approach is used, i.e., path computation is centralized including the TE-DB, MELG routing extensions are not needed because the information about= mutual
exclusive VLs can be kept in the central TE-DB when VLs are configured.

Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their
applicability is broader.


Thanks,
Dieter

 <= /p>

Do you think if it makes sense to add a flag (in routing advertisement)= to indicate a link is a VL or not?

 

 

 

Best Regards

 

Fatai

 <= /p>

From: Vishnu P= avan Beeram [mailto:vishnupavan@gm= ail.com]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Fatai, Hi!

 

Good to see that you understand the construct now.

 

This is not a corner case. The utility of the constr= uct becomes quite significant if you have an application that does concurre= nt path computations on an abstract topology.

 

Regards,

-Pavan



_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ie=
tf.org/mailman/listinfo/ccamp

 

--

DIETER BELLER

ALCATEL-LUCENT DEUTSCHLAND= AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 711 821 43125
Mobil: +49 175 7266874

 

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe

--_000_D8D01B39D6B38C45AA37C06ECC1D65D53FCEC067SVEXDBPROD1infi_-- From vishnupavan@gmail.com Fri Apr 12 05:08:25 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6987921F86F5 for ; Fri, 12 Apr 2013 05:08:25 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 LXHNbphE7GHV for ; Fri, 12 Apr 2013 05:08:23 -0700 (PDT) Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAE521F86F2 for ; Fri, 12 Apr 2013 05:08:23 -0700 (PDT) Received: by mail-bk0-f47.google.com with SMTP id ik5so1311105bkc.20 for ; Fri, 12 Apr 2013 05:08:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=iHUbr9WBXYpOwhNnm+TIBoI89lB541M40Qek2NeOhPM=; b=VrPaYARXk3fPhqsTeKUO+6Csj4yqzNr6s6F4n+jdE49UEXLasHSK5PDt5JxylmtYP0 CiRnlGHm6y6n1rB05W4xsUY7MAcyqVsyWQv1fSU/uCPPqItiq1MKVb+fS+XQkc+pkSPZ 7w6jBCBHEci303KDz3FTg20nYRObdpo9T025+X37gRWQJnH345sN+pk4UQYgsYFOji0k 2BMSB35LP4vII+1kR1A2eq+KuK2BPm3/Efh0h8HaBcpvw8ejC3EkR0XR53wqtmBglsBf rBFld6MyDWWtIA5h61Cj51ITUJPWc35rKEfA49VLFwj/IMfQubtrO6D0+HX17X6gv3KO I7nw== MIME-Version: 1.0 X-Received: by 10.204.183.8 with SMTP id ce8mr4090659bkb.21.1365768502210; Fri, 12 Apr 2013 05:08:22 -0700 (PDT) Received: by 10.205.127.137 with HTTP; Fri, 12 Apr 2013 05:08:21 -0700 (PDT) In-Reply-To: References: <5150C704.2040007@alcatel-lucent.com> Date: Fri, 12 Apr 2013 08:08:21 -0400 Message-ID: From: Vishnu Pavan Beeram To: Khuzema Pithewan Content-Type: multipart/alternative; boundary=20cf301ee52f6bb3d704da28c200 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] MELGs - Q&A X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 12:08:25 -0000 --20cf301ee52f6bb3d704da28c200 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Khuzema, Hi! Please see inline.. ** 1. **When Network has more than 2 layer i.e. Packet-OTN-DWDM, the > Packet (client) layer will be talking to its immediate server layer i.e. > OTN, which in turn is talking to DWDM layer. Using MELG, client layer pat= h > computation can take care of resource exclusivity of virtual link for > immediate server layer i.e. OTN layer. However if there is resource > exclusivity at DWDM layer, this mechanism doesn=92t work. You need to do > loose routing or use distributed PCE model > [VPB] The behavior is the same as what you would do with SRLGs in a multi-layer architecture. There are architectures that allow the SRLGs in the lowest layer to be exported all the way up to the highest layer. The expectation is that MELGs would be treated in the same vein. > **** > > **2. **For cases of concurrent computation (case#2-5), you are > mainly talking about global optimization and diversity among multiple > services. You can do the path computation, but to actually enact the > computed path the signaling needs to be done from the source end of those > LSPs. So there is no point in doing concurrent computation at one networ= k > element for the services starting from multiple network elements. At best > it looks to me a problem to be solved by network management/planning > software. > [VPB] I'm not sure why you think there is no point in having a centralized computation function compute paths concurrently for LSPs with different set of end-points. Even your NMS/planning-software can interact with such computation engine, retrieve all the paths and then go about initiating the path-setup from the ingress of each LSP. Regards, -Pavan > ** > > > ** ** > > ** ** > > *From:* ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] *On Behalf > Of *Igor Bryskin > *Sent:* Tuesday, March 26, 2013 7:19 PM > *To:* Dieter Beller; Vishnu Pavan Beeram > > *Cc:* ccamp@ietf.org > *Subject:* Re: [CCAMP] MELGs - Q&A**** > > ** ** > > Dieter,**** > > ** ** > > You said:**** > > >> I guess we are coming back to the essential point: "and how often > concurrent path computation will be >> used."**** > > ** ** > > To be honest, this surprises me quite a bit, Let me give you some of many > reasons as to why concurrent path computations are needed and why this is > better than computing one path at a time:**** > > ** ** > > **1. **Computing several diverse paths for the same service in the > context of service recovery. I hope you realize that computing one path a= t > a time on many configurations produces no or sub-optimal results. I also > hope you realize the problem of selecting two paths with one of them > having a link with common MELG with a link from another path;**** > > **2. **Computing paths for multiple services to be sufficiently > disjoint from each other;**** > > **3. **Computing paths for multiple services to achieve a global > optimization criteria (e.g. minimal summary total cost);**** > > **4. **Computing paths for multiple services for the purpose of > removing the bandwidth fragmentations;**** > > **5. **Computing paths for multiple services to plan shared mesh > protection/restoration schemes**** > > **6. **Etc.**** > > ** ** > > Also think about this:**** > > **1. **If concurrent path computation was not important, why PCEP > includes the machinery to do that?**** > > **2. **My understanding of the statefull PCE is that it does pretty > much nothing but concurrent path computations**** > > ** ** > > You also said:**** > > >> I suppose that if a pce approach is used, i.e., path computation is > centralized including the > >> TE-DB, MELG routing extensions are not needed because the information > about mutual > >>exclusive VLs can be kept in the central TE-DB when VLs are configured.= * > *** > > How this logic does not apply to other link attributes such as SRLGs?**** > > What if path computation is not centralized?**** > > ** ** > > Cheers,**** > > Igor**** > > ** ** > > *From:* ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] *On Behalf > Of *Dieter Beller > *Sent:* Monday, March 25, 2013 5:52 PM > *To:* Vishnu Pavan Beeram > *Cc:* ccamp@ietf.org > *Subject:* Re: [CCAMP] MELGs - Q&A**** > > ** ** > > Hi Pavan,**** > > On 25.03.2013 07:29, Fatai Zhang wrote:**** > > Hi Pavan,**** > > **** > > I am not sure how much VL (Virtual Link) will be used in the practical > deployment and how often concurrent path computation will be used.**** > > I guess we are coming back to the essential point: "and how often > concurrent path computation will be used." > > This means we are trying to figure out under which conditions MELG routin= g > extensions > could be beneficial. > > IMHO, they would only make sense, if:**** > > - a path computation function supports the calculation of k shortest > paths concurrently**** > - if there is only a single path computation function instance per > domain (pce approach) > If path computation is done in a distributed fashion the benefit goes > away because > the instances calculate paths independently!**** > > I suppose that if a pce approach is used, i.e., path computation is > centralized including the > TE-DB, MELG routing extensions are not needed because the information > about mutual > exclusive VLs can be kept in the central TE-DB when VLs are configured. > > Hence, it is quite doubtful whether MELG routing extensions are really > useful unless their > applicability is broader. > > > Thanks, > Dieter > > **** > > **** > > Do you think if it makes sense to add a flag (in routing advertisement) t= o > indicate a link is a VL or not?**** > > **** > > **** > > **** > > Best Regards**** > > **** > > Fatai**** > > **** > > *From:* Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] > > *Sent:* Friday, March 22, 2013 8:57 PM > *To:* Fatai Zhang > *Cc:* Igor Bryskin; ccamp@ietf.org > *Subject:* Re: [CCAMP] MELGs - Q&A**** > > **** > > Fatai, Hi!**** > > **** > > Good to see that you understand the construct now.**** > > **** > > This is not a corner case. The utility of the construct becomes quite > significant if you have an application that does concurrent path > computations on an abstract topology.**** > > **** > > Regards,**** > > -Pavan**** > > > > **** > > _______________________________________________**** > > CCAMP mailing list**** > > CCAMP@ietf.org**** > > https://www.ietf.org/mailman/listinfo/ccamp**** > > ** ** > > -- **** > > *DIETER BELLER * > > ALCATEL-LUCENT DEUTSCHLAND AG > PROJECT MANAGER ASON/GMPLS CONTROL PLANE > CORE NETWORKS BUSINESS DIVISION > OPTICS BU, SWITCHING R&D > > Lorenzstrasse 10 > 70435 Stuttgart, Germany > Phone: +49 711 821 43125 > Mobil: +49 175 7266874 **** > > *Dieter.Beller@alcatel-lucent.com * > > ** ** > > Alcatel-Lucent Deutschland AG > Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026 > Chairman of the Supervisory Board: Michael Oppenhoff > Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. > Rainer Fechner =B7 Andreas Gehe **** > --20cf301ee52f6bb3d704da28c200 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Khuzema, Hi!

Please see = inline..

=A0= 1.=A0= =A0=A0=A0=A0=A0 When Network has more than 2 layer i.e. Packet= -OTN-DWDM, the Packet (client) layer will be talking to its immediate serve= r layer i.e. OTN, which in turn is talking to DWDM layer. Using MELG, client layer path computation c= an take care of resource exclusivity of virtual link for immediate server l= ayer i.e. OTN layer.=A0 However if there is resource exclusivity at DWDM la= yer, this mechanism doesn=92t work. You need to do loose routing or use distributed PCE model

=
=A0
[VPB] The behavior is the same as wha= t you would do with SRLGs in a multi-layer architecture. There are architec= tures that allow the SRLGs in the lowest layer to be exported all the way u= p to the highest layer. The expectation is that MELGs would be treated in t= he same vein.=A0

2.=A0=A0=A0=A0=A0=A0 For cases of concurr= ent computation (case#2-5), you are mainly talking about global optimizatio= n and diversity among multiple services. You can do the path computation, but to actually enact the computed path the signalin= g needs to be done from the source end of those LSPs.=A0 So there is no poi= nt in doing concurrent computation at one network element for the services = starting from multiple network elements. At best it looks to me a problem to be solved by network management/planni= ng software.=A0

[VPB] =A0I'm no= t sure why you think there is no point in having a centralized computation = function compute paths concurrently for LSPs with different set of end-poin= ts. Even your NMS/planning-software can interact with such computation engi= ne, retrieve all the paths and then go about initiating the path-setup from= the ingress of each LSP.=A0

Regards,
-Pavan
=A0


=A0<= /p>

=A0<= /p>

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Tuesday, March 26, 2013 7:19 PM
To: Dieter Beller; Vishnu Pavan Beeram


Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

=A0

Dieter,

=A0<= /p>

You said:

>> I guess we are coming back to the essential= point: "and how often concurrent path comp= utation will be >> used."

=A0

To be honest, this surprises me quite a bit, Let me = give you some of many reasons as to why concurrent path computations are ne= eded and why this is better than computing one path at a time:

=A0

1.= =A0=A0=A0=A0=A0 Computing several diverse paths for the same service i= n the context of service recovery. I hope you realize that computing one pa= th at a time on many configurations produces no or sub-optimal results. I a= lso hope you realize the problem of selecting two paths with one of them =A0having a link with common MELG = with a link from another path;

2.= =A0=A0=A0=A0=A0 Computing paths for multiple services to be sufficient= ly disjoint from each other;

3.= =A0=A0=A0=A0=A0 Computing paths for multiple services to achieve a glo= bal optimization criteria (e.g. minimal summary total cost);<= /p>

4.= =A0=A0=A0=A0=A0 Computing paths for multiple services for the purpose = of removing the bandwidth fragmentations;

5.= =A0=A0=A0=A0=A0 Computing paths for multiple services to plan shared m= esh protection/restoration schemes

6.= =A0=A0=A0=A0=A0 Etc.

=A0

Also think about this:

1.= =A0=A0=A0=A0=A0 If concurrent path computation was not important, why = PCEP includes the machinery to do that?

2.= =A0=A0=A0=A0=A0 My understanding of the statefull PCE is that it does = pretty much nothing but concurrent path computations

=A0

You also said:

>> I suppose th= at if a pce approach is used, i.e., path computation is centralized includi= ng the
>> TE-DB, MELG routing extensions are not needed because the informat= ion about mutual
>>exclusive VLs can be kept in the central TE-DB when VLs are configu= red.

How this logic does not apply to other link attribut= es such as SRLGs?

What if path computation is not centralized?<= u>

=A0

Cheers,

Igor

=A0<= /p>

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

=A0

Hi Pavan,

On 25.03.2013 07:29, Fatai Zhang wrote:<= /u>

Hi Pavan,

=A0<= /p>

I am not sure how much VL= (Virtual Link) will be used in the practical deployment and how often conc= urrent path computation will be used.

I guess we are coming back to the essential point: &= quot;and how often concurrent path computation w= ill be used."

This means we are trying to figure out under which conditions MELG routing = extensions
could be beneficial.

IMHO, they would only make sense, if:

  • a path computation function supports the calculation of k shortest paths co= ncurrently
  • if there is only a single path computation function instance per domain (pc= e approach)
    If path computation is done in a distributed fashion the benefit goes away = because
    the instances calculate paths independently!

I suppose that if a p= ce approach is used, i.e., path computation is centralized including the TE-DB, MELG routing extensions are not needed because the information about= mutual
exclusive VLs can be kept in the central TE-DB when VLs are configured.

Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their
applicability is broader.


Thanks,
Dieter

=A0<= /p>

Do you think if it makes sense to add a flag (in routing advertisement)= to indicate a link is a VL or not?

=A0

=A0

=A0

Best Regards

=A0

Fatai

=A0<= /p>

From: Vishnu P= avan Beeram [mai= lto:vishnupavan@gmail.com]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

=A0

Fatai, Hi!

=A0

Good to see that you understand the construct now.

=A0

This is not a corner case. The utility of the constr= uct becomes quite significant if you have an application that does concurre= nt path computations on an abstract topology.

=A0

Regards,

-Pavan



_______________________________________________
CCAMP mailing list
CCAMP@ietf.org=

https://www.ietf.org/mailman/listinfo/ccamp

=A0

--

DIETER BELLER

ALCATEL-LUCENT DEUTSCHLAND= AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 711 821 43125
Mobil: +49 175 7266874

=A0

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe


--20cf301ee52f6bb3d704da28c200-- From IBryskin@advaoptical.com Fri Apr 12 06:06:49 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C132D21F8C08 for ; Fri, 12 Apr 2013 06:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 0GpqBNA0uH7C for ; Fri, 12 Apr 2013 06:06:40 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id CC88521F8BE4 for ; Fri, 12 Apr 2013 06:06:39 -0700 (PDT) Received: from MUC-SRV-MAIL10B.advaoptical.com ([172.20.1.60]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id r3CD6LIw014523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Apr 2013 15:06:21 +0200 Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MAIL10B.advaoptical.com (172.20.1.60) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 12 Apr 2013 15:06:21 +0200 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0123.003; Fri, 12 Apr 2013 09:06:19 -0400 From: Igor Bryskin To: Vishnu Pavan Beeram , Khuzema Pithewan Thread-Topic: [CCAMP] MELGs - Q&A Thread-Index: AQHOIGPeoOQf0fNS1kG7ulofq5GmQJivzRoAgABxTHCAAPkpgIAAeAqAgABMBQCABErLAIABAdYAgAC6NQCAGt0OAIAAD52A///KWjA= Date: Fri, 12 Apr 2013 13:06:19 +0000 Message-ID: References: <5150C704.2040007@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.1.77] Content-Type: multipart/alternative; boundary="_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A19238C77atlsrvmail10atl_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-04-12_05:2013-04-12, 2013-04-12, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] MELGs - Q&A X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 13:06:49 -0000 --_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A19238C77atlsrvmail10atl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Khuzema, 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. Well, when an ingress node is initiating a service, it is doing so on reque= st from some management entity. This management entity can compute paths fo= r many services with some global criteria in mind, and then specify the res= ulting paths as explicit EROs in provisioning requests sent to each of the = service ingresses. How else, for example, you can set up several services = originated from different nodes that are disjoint from each other? Also, wh= at is the point in your opinion of the statefull PCE work? Cheers, Igor From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, April 12, 2013 8:08 AM To: Khuzema Pithewan Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Khuzema, Hi! Please see inline.. 1. When Network has more than 2 layer i.e. Packet-OTN-DWDM, the Pack= et (client) layer will be talking to its immediate server layer i.e. OTN, w= hich in turn is talking to DWDM layer. Using MELG, client layer path comput= ation can take care of resource exclusivity of virtual link for immediate s= erver layer i.e. OTN layer. However if there is resource exclusivity at DW= DM layer, this mechanism doesn't work. You need to do loose routing or use = distributed PCE model [VPB] The behavior is the same as what you would do with SRLGs in a multi-l= ayer architecture. There are architectures that allow the SRLGs in the lowe= st layer to be exported all the way up to the highest layer. The expectatio= n is that MELGs would be treated in the same vein. 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. [VPB] I'm not sure why you think there is no point in having a centralized= computation function compute paths concurrently for LSPs with different se= t of end-points. Even your NMS/planning-software can interact with such com= putation engine, retrieve all the paths and then go about initiating the pa= th-setup from the ingress of each LSP. Regards, -Pavan From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Igor Bryskin Sent: Tuesday, March 26, 2013 7:19 PM To: Dieter Beller; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Dieter, You said: >> I guess we are coming back to the essential point: "and how often concur= rent path computation will be >> used." To be honest, this surprises me quite a bit, Let me give you some of many r= easons as to why concurrent path computations are needed and why this is be= tter than computing one path at a time: 1. Computing several diverse paths for the same service in the context= of service recovery. I hope you realize that computing one path at a time = on many configurations produces no or sub-optimal results. I also hope you = realize the problem of selecting two paths with one of them having a link = with common MELG with a link from another path; 2. Computing paths for multiple services to be sufficiently disjoint f= rom each other; 3. Computing paths for multiple services to achieve a global optimizat= ion criteria (e.g. minimal summary total cost); 4. Computing paths for multiple services for the purpose of removing t= he bandwidth fragmentations; 5. Computing paths for multiple services to plan shared mesh protectio= n/restoration schemes 6. Etc. Also think about this: 1. If concurrent path computation was not important, why PCEP includes= the machinery to do that? 2. My understanding of the statefull PCE is that it does pretty much n= othing but concurrent path computations You also said: >> I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the >> TE-DB, MELG routing extensions are not needed because the information ab= out mutual >>exclusive VLs can be kept in the central TE-DB when VLs are configured. How this logic does not apply to other link attributes such as SRLGs? What if path computation is not centralized? Cheers, Igor From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Dieter Beller Sent: Monday, March 25, 2013 5:52 PM To: Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Hi Pavan, On 25.03.2013 07:29, Fatai Zhang wrote: Hi Pavan, I am not sure how much VL (Virtual Link) will be used in the practical depl= oyment and how often concurrent path computation will be used. I guess we are coming back to the essential point: "and how often concurren= t path computation will be used." This means we are trying to figure out under which conditions MELG routing = extensions could be beneficial. IMHO, they would only make sense, if: * a path computation function supports the calculation of k shortest pa= ths concurrently * if there is only a single path computation function instance per doma= in (pce approach) If path computation is done in a distributed fashion the benefit goes away = because the instances calculate paths independently! I suppose that if a pce approach is used, i.e., path computation is central= ized including the TE-DB, MELG routing extensions are not needed because the information about= mutual exclusive VLs can be kept in the central TE-DB when VLs are configured. Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their applicability is broader. Thanks, Dieter Do you think if it makes sense to add a flag (in routing advertisement) to = indicate a link is a VL or not? Best Regards Fatai From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, March 22, 2013 8:57 PM To: Fatai Zhang Cc: Igor Bryskin; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Fatai, Hi! Good to see that you understand the construct now. This is not a corner case. The utility of the construct becomes quite signi= ficant if you have an application that does concurrent path computations on= an abstract topology. Regards, -Pavan _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp -- DIETER BELLER ALCATEL-LUCENT DEUTSCHLAND AG PROJECT MANAGER ASON/GMPLS CONTROL PLANE CORE NETWORKS BUSINESS DIVISION OPTICS BU, SWITCHING R&D Lorenzstrasse 10 70435 Stuttgart, Germany Phone: +49 711 821 43125 Mobil: +49 175 7266874 Dieter.Beller@alcatel-lucent.com Alcatel-Lucent Deutschland AG Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026 Chairman of the Supervisory Board: Michael Oppenhoff Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe --_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A19238C77atlsrvmail10atl_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Khuzema,

 <= /p>

2.       For cases of concurrent computation (case= #2-5), you are mainly talking about global optimization and diversity among= multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from th= e source end of those LSPs.  So there is no point in doing concurrent = computation at one network element for the services starting from multiple = network elements. At best it looks to me a problem to be solved by network management/planning software.&= nbsp;

Well, when an ingress nod= e is initiating a service, it is doing so on request from some management e= ntity. This management entity can compute paths for many services with some global criteria in mind, and then specify the resulting= paths as explicit EROs in provisioning requests sent to each of the servic= e ingresses. How else, for example,  you can set up several services o= riginated from different nodes that are disjoint from each other? Also, what is the point in your opinion of the s= tatefull PCE work?

 <= /p>

Cheers,=

Igor

 <= /p>

From: Vishnu P= avan Beeram [mailto:vishnupavan@gmail.com]
Sent: Friday, April 12, 2013 8:08 AM
To: Khuzema Pithewan
Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Khuzema, Hi!


Please see inline..

 

 

 1.       When Network has more than 2 layer i.e. P= acket-OTN-DWDM, the Packet (client) layer will be talking to its immediate = server layer i.e. OTN, which in turn is talking to DWDM layer. Using MELG, client layer path computation can take care of resource= exclusivity of virtual link for immediate server layer i.e. OTN layer.&nbs= p; However if there is resource exclusivity at DWDM layer, this mechanism d= oesn’t work. You need to do loose routing or use distributed PCE model

 

[VPB] The behavior is the same as what you would do = with SRLGs in a multi-layer architecture. There are architectures that allo= w the SRLGs in the lowest layer to be exported all the way up to the highes= t layer. The expectation is that MELGs would be treated in the same vein. 

2.       For cases of concurrent computation (case= #2-5), you are mainly talking about global optimization and diversity among= multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from th= e source end of those LSPs.  So there is no point in doing concurrent = computation at one network element for the services starting from multiple = network elements. At best it looks to me a problem to be solved by network management/planning software.&= nbsp;

[VPB]  I'm not sure why you think there is no p= oint in having a centralized computation function compute paths concurrentl= y for LSPs with different set of end-points. Even your NMS/planning-softwar= e can interact with such computation engine, retrieve all the paths and then go about initiating the path-setup from th= e ingress of each LSP. 

 

Regards,

-Pavan

 

 

 

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Tuesday, March 26, 2013 7:19 PM
To: Dieter Beller; Vishnu Pavan Beeram


Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Dieter,

 

You said:

>> I guess we are coming back to the essential point: "= and how often concurrent path computation will be >> used."

 

To be honest, this surprises me quite a bit, Let me give you some = of many reasons as to why concurrent path computations are needed and why t= his is better than computing one path at a time:

 

1.      = Computing several diverse paths for the same service in the context of serv= ice recovery. I hope you realize that computing one path at a time on many = configurations produces no or sub-optimal results. I also hope you realize the problem of selecting two paths with one of them  havi= ng a link with common MELG with a link from another path;

2.      = Computing paths for multiple services to be sufficiently disjoint from each= other;

3.      = Computing paths for multiple services to achieve a global optimization crit= eria (e.g. minimal summary total cost);

4.      = Computing paths for multiple services for the purpose of removing the bandw= idth fragmentations;

5.      = Computing paths for multiple services to plan shared mesh protection/restor= ation schemes

6.      = Etc.

 

Also think about this:

1.      = If concurrent path computation was not important, why PCEP includes the mac= hinery to do that?

2.      = My understanding of the statefull PCE is that it does pretty much nothing b= ut concurrent path computations

 

You also said:

>> I suppose that if a pce approach is used, i.e., path computatio= n is centralized including the
>> TE-DB, MELG routing extensions are not needed because the informat= ion about mutual
>>exclusive VLs can be kept in the central TE-DB when VLs are configu= red.

How this logic does not apply to other link attributes such as SRL= Gs?

What if path computation is not centralized?

 

Cheers,

Igor

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Hi Pavan,

On 25.03.2013 07:29, Fat= ai Zhang wrote:

Hi Pavan,

 

I am not sure how much VL (Virtual Link= ) will be used in the practical deployment and how often concurrent path computation will be used.

I guess we are coming back to the essential point: "and how often concurrent path computation will be used."

This means we are trying to figure out under which conditions MELG routing = extensions
could be beneficial.

IMHO, they would only make sense, if:

  • a path computation function supports the calculation of k shortest paths co= ncurrently
  • if there is only a single path computation function instance per domain (pc= e approach)
    If path computation is done in a distributed fashion the benefit goes away = because
    the instances calculate paths independently!

I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the
TE-DB, MELG routing extensions are not needed because the information about= mutual
exclusive VLs can be kept in the central TE-DB when VLs are configured.

Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their
applicability is broader.


Thanks,
Dieter

 

Do you think if it makes sense to add a flag (in= routing advertisement) to indicate a link is a VL or not?

 

 

 

Best Regards

 

Fatai

 

From: Vishnu Pavan Beeram [<= a href=3D"mailto:vishnupavan@gmail.com" target=3D"_blank">mailto:vishnupava= n@gmail.com]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Fatai, Hi!

 

Good to see that you understand the construct now.

 

This is not a corner case. The utility of the construct becomes qu= ite significant if you have an application that does concurrent path comput= ations on an abstract topology.

 

Regards,

-Pavan

 

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org=

https://www.ietf.org/mailman/listinfo/ccamp

 

--

DIETER BELLER

ALCATEL-LUCENT DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 = 711 821 43125
Mobil: +49 175 = 7266874

 

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe

 

--_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A19238C77atlsrvmail10atl_-- From lberger@labn.net Fri Apr 12 07:24:16 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6722F21F8758 for ; Fri, 12 Apr 2013 07:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.308 X-Spam-Level: X-Spam-Status: No, score=-102.308 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 u57wHKH+VLjo for ; Fri, 12 Apr 2013 07:24:15 -0700 (PDT) Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 9F77921F8689 for ; Fri, 12 Apr 2013 07:24:15 -0700 (PDT) Received: (qmail 26836 invoked by uid 0); 12 Apr 2013 14:22:47 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy14.unifiedlayer.com with SMTP; 12 Apr 2013 14:22:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=gpc9HECiixCL5QTsT3MN+bhq5bCJBC56MXZnHDvTzyo=; b=urmVVjuapR7ifmsQ5zXcL0ESw9M/8sJs0qdxR4hq6LFM5CEhisl/74rKNwVgPu3HfE1SWfqJNTP6wna6KcjkUEwsR+8+vmtxFEV27inh/pJSGLqe3uigF4N8sjFnKY1z; Received: from box313.bluehost.com ([69.89.31.113]:34177 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UQesJ-0007HQ-4K; Fri, 12 Apr 2013 08:22:47 -0600 Message-ID: <5168187E.2080301@labn.net> Date: Fri, 12 Apr 2013 10:21:50 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: ccamp@ietf.org, draft-dong-ccamp-rsvp-te-mpls-tp-li-lb@tools.ietf.org References: <51545098.4060609@labn.net> In-Reply-To: <51545098.4060609@labn.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: Re: [CCAMP] poll on making draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05 a WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 14:24:16 -0000 All, This poll is closed. The document is adopted. Authors, Please resubmit with name change only to draft-ietf-ccamp-rsvp-te-li-lb Thank you, Lou (and Deborah) On 3/28/2013 10:15 AM, Lou Berger wrote: > All, > > This is to start a two week poll on making > draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05 a ccamp working > group document. Please send mail to the list indicating "yes/support" > or "no/do not support". If indicating no, please state your technical > reservations with the document. > > All authors have stated that they are not aware of any IPR that applies > to the draft. > > The poll ends Thursday April 11. > > Much thanks, > Lou (and Deborah) > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From kpithewan@infinera.com Fri Apr 12 07:55:29 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEEE221F8AC2 for ; Fri, 12 Apr 2013 07:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 o4bQsF5TQm4a for ; Fri, 12 Apr 2013 07:55:25 -0700 (PDT) Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 13D4121F8A8A for ; Fri, 12 Apr 2013 07:55:24 -0700 (PDT) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.02.0342.003; Fri, 12 Apr 2013 07:55:24 -0700 From: Khuzema Pithewan To: Igor Bryskin , Vishnu Pavan Beeram Thread-Topic: [CCAMP] MELGs - Q&A Thread-Index: AQHOIGPek8R0zdnmbUizkEjN3z7415ivh4owgAA2TQCAATLDIIAAeV3g///IfQCABM8nkIABeO8AgAELY4CAGhSNwIAAhvCAgAAQMoD//6fVoA== Date: Fri, 12 Apr 2013 14:55:23 +0000 Message-ID: References: <5150C704.2040007@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.156.128] Content-Type: multipart/alternative; boundary="_000_D8D01B39D6B38C45AA37C06ECC1D65D53FCEC408SVEXDBPROD1infi_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] MELGs - Q&A X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 14:55:29 -0000 --_000_D8D01B39D6B38C45AA37C06ECC1D65D53FCEC408SVEXDBPROD1infi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Igor, Ok. This would be useful if network architecture is based on external PCE o= r mgmt entity as PCE in client layer, but there is no counterpart in server= layer, otherwise one could have inter-PCE communication to achieve diverse= path in server layer without getting into virtual link and MELG stuff. Is that correct? Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 6:36 PM To: Vishnu Pavan Beeram; Khuzema Pithewan Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. Well, when an ingress node is initiating a service, it is doing so on reque= st from some management entity. This management entity can compute paths fo= r many services with some global criteria in mind, and then specify the res= ulting paths as explicit EROs in provisioning requests sent to each of the = service ingresses. How else, for example, you can set up several services = originated from different nodes that are disjoint from each other? Also, wh= at is the point in your opinion of the statefull PCE work? Cheers, Igor From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, April 12, 2013 8:08 AM To: Khuzema Pithewan Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Khuzema, Hi! Please see inline.. 1. When Network has more than 2 layer i.e. Packet-OTN-DWDM, the Pack= et (client) layer will be talking to its immediate server layer i.e. OTN, w= hich in turn is talking to DWDM layer. Using MELG, client layer path comput= ation can take care of resource exclusivity of virtual link for immediate s= erver layer i.e. OTN layer. However if there is resource exclusivity at DW= DM layer, this mechanism doesn't work. You need to do loose routing or use = distributed PCE model [VPB] The behavior is the same as what you would do with SRLGs in a multi-l= ayer architecture. There are architectures that allow the SRLGs in the lowe= st layer to be exported all the way up to the highest layer. The expectatio= n is that MELGs would be treated in the same vein. 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. [VPB] I'm not sure why you think there is no point in having a centralized= computation function compute paths concurrently for LSPs with different se= t of end-points. Even your NMS/planning-software can interact with such com= putation engine, retrieve all the paths and then go about initiating the pa= th-setup from the ingress of each LSP. Regards, -Pavan From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Igor Bryskin Sent: Tuesday, March 26, 2013 7:19 PM To: Dieter Beller; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Dieter, You said: >> I guess we are coming back to the essential point: "and how often concur= rent path computation will be >> used." To be honest, this surprises me quite a bit, Let me give you some of many r= easons as to why concurrent path computations are needed and why this is be= tter than computing one path at a time: 1. Computing several diverse paths for the same service in the context= of service recovery. I hope you realize that computing one path at a time = on many configurations produces no or sub-optimal results. I also hope you = realize the problem of selecting two paths with one of them having a link = with common MELG with a link from another path; 2. Computing paths for multiple services to be sufficiently disjoint f= rom each other; 3. Computing paths for multiple services to achieve a global optimizat= ion criteria (e.g. minimal summary total cost); 4. Computing paths for multiple services for the purpose of removing t= he bandwidth fragmentations; 5. Computing paths for multiple services to plan shared mesh protectio= n/restoration schemes 6. Etc. Also think about this: 1. If concurrent path computation was not important, why PCEP includes= the machinery to do that? 2. My understanding of the statefull PCE is that it does pretty much n= othing but concurrent path computations You also said: >> I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the >> TE-DB, MELG routing extensions are not needed because the information ab= out mutual >>exclusive VLs can be kept in the central TE-DB when VLs are configured. How this logic does not apply to other link attributes such as SRLGs? What if path computation is not centralized? Cheers, Igor From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Dieter Beller Sent: Monday, March 25, 2013 5:52 PM To: Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Hi Pavan, On 25.03.2013 07:29, Fatai Zhang wrote: Hi Pavan, I am not sure how much VL (Virtual Link) will be used in the practical depl= oyment and how often concurrent path computation will be used. I guess we are coming back to the essential point: "and how often concurren= t path computation will be used." This means we are trying to figure out under which conditions MELG routing = extensions could be beneficial. IMHO, they would only make sense, if: * a path computation function supports the calculation of k shortest pa= ths concurrently * if there is only a single path computation function instance per doma= in (pce approach) If path computation is done in a distributed fashion the benefit goes away = because the instances calculate paths independently! I suppose that if a pce approach is used, i.e., path computation is central= ized including the TE-DB, MELG routing extensions are not needed because the information about= mutual exclusive VLs can be kept in the central TE-DB when VLs are configured. Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their applicability is broader. Thanks, Dieter Do you think if it makes sense to add a flag (in routing advertisement) to = indicate a link is a VL or not? Best Regards Fatai From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, March 22, 2013 8:57 PM To: Fatai Zhang Cc: Igor Bryskin; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Fatai, Hi! Good to see that you understand the construct now. This is not a corner case. The utility of the construct becomes quite signi= ficant if you have an application that does concurrent path computations on= an abstract topology. Regards, -Pavan _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp -- DIETER BELLER ALCATEL-LUCENT DEUTSCHLAND AG PROJECT MANAGER ASON/GMPLS CONTROL PLANE CORE NETWORKS BUSINESS DIVISION OPTICS BU, SWITCHING R&D Lorenzstrasse 10 70435 Stuttgart, Germany Phone: +49 711 821 43125 Mobil: +49 175 7266874 Dieter.Beller@alcatel-lucent.com Alcatel-Lucent Deutschland AG Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026 Chairman of the Supervisory Board: Michael Oppenhoff Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe --_000_D8D01B39D6B38C45AA37C06ECC1D65D53FCEC408SVEXDBPROD1infi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Igor,

 <= /p>

Ok. This would be useful = if network architecture is based on external PCE or mgmt entity as PCE in c= lient layer, but there is no counterpart in server layer, otherwise one could have inter-PCE communication to achieve diverse path i= n server layer without getting into virtual link and MELG stuff.=

 <= /p>

Is that correct?

 <= /p>

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 6:36 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

2.       For cases of concurrent computation (case= #2-5), you are mainly talking about global optimization and diversity among= multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from th= e source end of those LSPs.  So there is no point in doing concurrent = computation at one network element for the services starting from multiple = network elements. At best it looks to me a problem to be solved by network management/planning software.&= nbsp;

Well, when an ingress nod= e is initiating a service, it is doing so on request from some management e= ntity. This management entity can compute paths for many services with some global criteria in mind, and then specify the resulting= paths as explicit EROs in provisioning requests sent to each of the servic= e ingresses. How else, for example,  you can set up several services o= riginated from different nodes that are disjoint from each other? Also, what is the point in your opinion of the s= tatefull PCE work?

 <= /p>

Cheers,=

Igor

 <= /p>

From: Vishnu P= avan Beeram [mailto:vishnupavan@gmail.com]
Sent: Friday, April 12, 2013 8:08 AM
To: Khuzema Pithewan
Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Khuzema, Hi!


Please see inline..

 

 

 1.       When Network has more than 2 layer i.e. P= acket-OTN-DWDM, the Packet (client) layer will be talking to its immediate = server layer i.e. OTN, which in turn is talking to DWDM layer. Using MELG, client layer path computation can take care of resource= exclusivity of virtual link for immediate server layer i.e. OTN layer.&nbs= p; However if there is resource exclusivity at DWDM layer, this mechanism d= oesn’t work. You need to do loose routing or use distributed PCE model

 

[VPB] The behavior is the same as what you would do = with SRLGs in a multi-layer architecture. There are architectures that allo= w the SRLGs in the lowest layer to be exported all the way up to the highes= t layer. The expectation is that MELGs would be treated in the same vein. 

2.       For cases of concurrent computation (case= #2-5), you are mainly talking about global optimization and diversity among= multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from th= e source end of those LSPs.  So there is no point in doing concurrent = computation at one network element for the services starting from multiple = network elements. At best it looks to me a problem to be solved by network management/planning software.&= nbsp;

[VPB]  I'm not sure why you think there is no p= oint in having a centralized computation function compute paths concurrentl= y for LSPs with different set of end-points. Even your NMS/planning-softwar= e can interact with such computation engine, retrieve all the paths and then go about initiating the path-setup from th= e ingress of each LSP. 

 

Regards,

-Pavan

 

 

 

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Tuesday, March 26, 2013 7:19 PM
To: Dieter Beller; Vishnu Pavan Beeram


Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Dieter,

 

You said:

>> I guess we are coming back to the essential point: "= and how often concurrent path computation will be >> used."

 

To be honest, this surprises me quite a bit, Let me give you some = of many reasons as to why concurrent path computations are needed and why t= his is better than computing one path at a time:

 

1.      = Computing several diverse paths for the same service in the context of serv= ice recovery. I hope you realize that computing one path at a time on many = configurations produces no or sub-optimal results. I also hope you realize the problem of selecting two paths with one of them  havi= ng a link with common MELG with a link from another path;

2.      = Computing paths for multiple services to be sufficiently disjoint from each= other;

3.      = Computing paths for multiple services to achieve a global optimization crit= eria (e.g. minimal summary total cost);

4.      = Computing paths for multiple services for the purpose of removing the bandw= idth fragmentations;

5.      = Computing paths for multiple services to plan shared mesh protection/restor= ation schemes

6.      = Etc.

 

Also think about this:

1.      = If concurrent path computation was not important, why PCEP includes the mac= hinery to do that?

2.      = My understanding of the statefull PCE is that it does pretty much nothing b= ut concurrent path computations

 

You also said:

>> I suppose that if a pce approach is used, i.e., path computatio= n is centralized including the
>> TE-DB, MELG routing extensions are not needed because the informat= ion about mutual
>>exclusive VLs can be kept in the central TE-DB when VLs are configu= red.

How this logic does not apply to other link attributes such as SRL= Gs?

What if path computation is not centralized?

 

Cheers,

Igor

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Hi Pavan,

On 25.03.2013 07:29, Fat= ai Zhang wrote:

Hi Pavan,

 

I am not sure how much VL (Virtual Link= ) will be used in the practical deployment and how often concurrent path computation will be used.

I guess we are coming back to the essential point: "and how often concurrent path computation will be used."

This means we are trying to figure out under which conditions MELG routing = extensions
could be beneficial.

IMHO, they would only make sense, if:

  • a path computation function supports the calculation of k shortest paths co= ncurrently
  • if there is only a single path computation function instance per domain (pc= e approach)
    If path computation is done in a distributed fashion the benefit goes away = because
    the instances calculate paths independently!

I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the
TE-DB, MELG routing extensions are not needed because the information about= mutual
exclusive VLs can be kept in the central TE-DB when VLs are configured.

Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their
applicability is broader.


Thanks,
Dieter

 

Do you think if it makes sense to add a flag (in= routing advertisement) to indicate a link is a VL or not?

 

 

 

Best Regards

 

Fatai

 

From: Vishnu Pavan Beeram [<= a href=3D"mailto:vishnupavan@gmail.com" target=3D"_blank">mailto:vishnupava= n@gmail.com]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Fatai, Hi!

 

Good to see that you understand the construct now.

 

This is not a corner case. The utility of the construct becomes qu= ite significant if you have an application that does concurrent path comput= ations on an abstract topology.

 

Regards,

-Pavan

 

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org=

https://www.ietf.org/mailman/listinfo/ccamp

 

--

DIETER BELLER

ALCATEL-LUCENT DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 = 711 821 43125
Mobil: +49 175 = 7266874

 

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe

 

--_000_D8D01B39D6B38C45AA37C06ECC1D65D53FCEC408SVEXDBPROD1infi_-- From IBryskin@advaoptical.com Fri Apr 12 08:09:04 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCC421F8B15 for ; Fri, 12 Apr 2013 08:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 aGDIBz4ARnrn for ; Fri, 12 Apr 2013 08:08:59 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9F121F890D for ; Fri, 12 Apr 2013 08:08:57 -0700 (PDT) Received: from MUC-SRV-MBX2.advaoptical.com ([172.20.1.96]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id r3CF8neb012338 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Apr 2013 17:08:49 +0200 Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MBX2.advaoptical.com (172.20.1.96) with Microsoft SMTP Server (TLS) id 15.0.620.29; Fri, 12 Apr 2013 17:08:49 +0200 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0123.003; Fri, 12 Apr 2013 11:08:47 -0400 From: Igor Bryskin To: Khuzema Pithewan , Vishnu Pavan Beeram Thread-Topic: [CCAMP] MELGs - Q&A Thread-Index: AQHOIGPeoOQf0fNS1kG7ulofq5GmQJivzRoAgABxTHCAAPkpgIAAeAqAgABMBQCABErLAIABAdYAgAC6NQCAGt0OAIAAD52A///KWjCAAGRRgP//wCBQ Date: Fri, 12 Apr 2013 15:08:46 +0000 Message-ID: References: <5150C704.2040007@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.1.77] Content-Type: multipart/alternative; boundary="_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A19238D39atlsrvmail10atl_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-04-12_06:2013-04-12, 2013-04-12, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] MELGs - Q&A X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 15:09:04 -0000 --_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A19238D39atlsrvmail10atl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Khuzema, I am not a fan of inter-layer path computations (nor I am a fan of inter-PC= E computations). In my mind path computation for a service or services in l= ayer X is performed only in layer X, i.e. considers only X layer links (rea= l or virtual). As Pavan mentioned SRLGs and MELGs that need to be inherited= from lower layers should be translated into X layer link SRLGs/MELGs and s= pecified with X layer specific SRLG/MELG IDs. Cheers, Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 10:55 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Ok. This would be useful if network architecture is based on external PCE o= r mgmt entity as PCE in client layer, but there is no counterpart in server= layer, otherwise one could have inter-PCE communication to achieve diverse= path in server layer without getting into virtual link and MELG stuff. Is that correct? Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 6:36 PM To: Vishnu Pavan Beeram; Khuzema Pithewan Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. Well, when an ingress node is initiating a service, it is doing so on reque= st from some management entity. This management entity can compute paths fo= r many services with some global criteria in mind, and then specify the res= ulting paths as explicit EROs in provisioning requests sent to each of the = service ingresses. How else, for example, you can set up several services = originated from different nodes that are disjoint from each other? Also, wh= at is the point in your opinion of the statefull PCE work? Cheers, Igor From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, April 12, 2013 8:08 AM To: Khuzema Pithewan Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Khuzema, Hi! Please see inline.. 1. When Network has more than 2 layer i.e. Packet-OTN-DWDM, the Pack= et (client) layer will be talking to its immediate server layer i.e. OTN, w= hich in turn is talking to DWDM layer. Using MELG, client layer path comput= ation can take care of resource exclusivity of virtual link for immediate s= erver layer i.e. OTN layer. However if there is resource exclusivity at DW= DM layer, this mechanism doesn't work. You need to do loose routing or use = distributed PCE model [VPB] The behavior is the same as what you would do with SRLGs in a multi-l= ayer architecture. There are architectures that allow the SRLGs in the lowe= st layer to be exported all the way up to the highest layer. The expectatio= n is that MELGs would be treated in the same vein. 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. [VPB] I'm not sure why you think there is no point in having a centralized= computation function compute paths concurrently for LSPs with different se= t of end-points. Even your NMS/planning-software can interact with such com= putation engine, retrieve all the paths and then go about initiating the pa= th-setup from the ingress of each LSP. Regards, -Pavan From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Igor Bryskin Sent: Tuesday, March 26, 2013 7:19 PM To: Dieter Beller; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Dieter, You said: >> I guess we are coming back to the essential point: "and how often concur= rent path computation will be >> used." To be honest, this surprises me quite a bit, Let me give you some of many r= easons as to why concurrent path computations are needed and why this is be= tter than computing one path at a time: 1. Computing several diverse paths for the same service in the context= of service recovery. I hope you realize that computing one path at a time = on many configurations produces no or sub-optimal results. I also hope you = realize the problem of selecting two paths with one of them having a link = with common MELG with a link from another path; 2. Computing paths for multiple services to be sufficiently disjoint f= rom each other; 3. Computing paths for multiple services to achieve a global optimizat= ion criteria (e.g. minimal summary total cost); 4. Computing paths for multiple services for the purpose of removing t= he bandwidth fragmentations; 5. Computing paths for multiple services to plan shared mesh protectio= n/restoration schemes 6. Etc. Also think about this: 1. If concurrent path computation was not important, why PCEP includes= the machinery to do that? 2. My understanding of the statefull PCE is that it does pretty much n= othing but concurrent path computations You also said: >> I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the >> TE-DB, MELG routing extensions are not needed because the information ab= out mutual >>exclusive VLs can be kept in the central TE-DB when VLs are configured. How this logic does not apply to other link attributes such as SRLGs? What if path computation is not centralized? Cheers, Igor From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Dieter Beller Sent: Monday, March 25, 2013 5:52 PM To: Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Hi Pavan, On 25.03.2013 07:29, Fatai Zhang wrote: Hi Pavan, I am not sure how much VL (Virtual Link) will be used in the practical depl= oyment and how often concurrent path computation will be used. I guess we are coming back to the essential point: "and how often concurren= t path computation will be used." This means we are trying to figure out under which conditions MELG routing = extensions could be beneficial. IMHO, they would only make sense, if: * a path computation function supports the calculation of k shortest pa= ths concurrently * if there is only a single path computation function instance per doma= in (pce approach) If path computation is done in a distributed fashion the benefit goes away = because the instances calculate paths independently! I suppose that if a pce approach is used, i.e., path computation is central= ized including the TE-DB, MELG routing extensions are not needed because the information about= mutual exclusive VLs can be kept in the central TE-DB when VLs are configured. Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their applicability is broader. Thanks, Dieter Do you think if it makes sense to add a flag (in routing advertisement) to = indicate a link is a VL or not? Best Regards Fatai From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, March 22, 2013 8:57 PM To: Fatai Zhang Cc: Igor Bryskin; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Fatai, Hi! Good to see that you understand the construct now. This is not a corner case. The utility of the construct becomes quite signi= ficant if you have an application that does concurrent path computations on= an abstract topology. Regards, -Pavan _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp -- DIETER BELLER ALCATEL-LUCENT DEUTSCHLAND AG PROJECT MANAGER ASON/GMPLS CONTROL PLANE CORE NETWORKS BUSINESS DIVISION OPTICS BU, SWITCHING R&D Lorenzstrasse 10 70435 Stuttgart, Germany Phone: +49 711 821 43125 Mobil: +49 175 7266874 Dieter.Beller@alcatel-lucent.com Alcatel-Lucent Deutschland AG Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026 Chairman of the Supervisory Board: Michael Oppenhoff Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe --_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A19238D39atlsrvmail10atl_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Khuzema,

 <= /p>

I am not a fan of inter-l= ayer path computations (nor I am a fan of inter-PCE computations). In my mi= nd path computation for a service or services in layer X is performed only in layer X, i.e. considers only X layer links (real or v= irtual). As Pavan mentioned SRLGs and MELGs that need to be inherited from = lower layers should be translated into X layer link SRLGs/MELGs and specifi= ed with X layer specific SRLG/MELG IDs.

 <= /p>

Cheers,=

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 10:55 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

Ok. This would be useful = if network architecture is based on external PCE or mgmt entity as PCE in c= lient layer, but there is no counterpart in server layer, otherwise one could have inter-PCE communication to achieve diverse path i= n server layer without getting into virtual link and MELG stuff.=

 <= /p>

Is that correct?

 <= /p>

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 6:36 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

2.       For cases of concurrent computation (case= #2-5), you are mainly talking about global optimization and diversity among= multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from th= e source end of those LSPs.  So there is no point in doing concurrent = computation at one network element for the services starting from multiple = network elements. At best it looks to me a problem to be solved by network management/planning software.&= nbsp;

Well, when an ingress nod= e is initiating a service, it is doing so on request from some management e= ntity. This management entity can compute paths for many services with some global criteria in mind, and then specify the resulting= paths as explicit EROs in provisioning requests sent to each of the servic= e ingresses. How else, for example,  you can set up several services o= riginated from different nodes that are disjoint from each other? Also, what is the point in your opinion of the s= tatefull PCE work?

 <= /p>

Cheers,=

Igor

 <= /p>

From: Vishnu P= avan Beeram [mailto:vishnupavan@gm= ail.com]
Sent: Friday, April 12, 2013 8:08 AM
To: Khuzema Pithewan
Cc: Igor Bryskin; Dieter Beller; c= camp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Khuzema, Hi!


Please see inline..

 

 

 1.       When Network has more than 2 layer i.e. P= acket-OTN-DWDM, the Packet (client) layer will be talking to its immediate = server layer i.e. OTN, which in turn is talking to DWDM layer. Using MELG, client layer path computation can take care of resource= exclusivity of virtual link for immediate server layer i.e. OTN layer.&nbs= p; However if there is resource exclusivity at DWDM layer, this mechanism d= oesn’t work. You need to do loose routing or use distributed PCE model

 

[VPB] The behavior is the same as what you would do = with SRLGs in a multi-layer architecture. There are architectures that allo= w the SRLGs in the lowest layer to be exported all the way up to the highes= t layer. The expectation is that MELGs would be treated in the same vein. 

2.       For cases of concurrent computation (case= #2-5), you are mainly talking about global optimization and diversity among= multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from th= e source end of those LSPs.  So there is no point in doing concurrent = computation at one network element for the services starting from multiple = network elements. At best it looks to me a problem to be solved by network management/planning software.&= nbsp;

[VPB]  I'm not sure why you think there is no p= oint in having a centralized computation function compute paths concurrentl= y for LSPs with different set of end-points. Even your NMS/planning-softwar= e can interact with such computation engine, retrieve all the paths and then go about initiating the path-setup from th= e ingress of each LSP. 

 

Regards,

-Pavan

 

 

 

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Tuesday, March 26, 2013 7:19 PM
To: Dieter Beller; Vishnu Pavan Beeram


Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Dieter,

 

You said:

>> I guess we are coming back to the essential point: "= and how often concurrent path computation will be >> used."

 

To be honest, this surprises me quite a bit, Let me give you some = of many reasons as to why concurrent path computations are needed and why t= his is better than computing one path at a time:

 

1.      = Computing several diverse paths for the same service in the context of serv= ice recovery. I hope you realize that computing one path at a time on many = configurations produces no or sub-optimal results. I also hope you realize the problem of selecting two paths with one of them  havi= ng a link with common MELG with a link from another path;

2.      = Computing paths for multiple services to be sufficiently disjoint from each= other;

3.      = Computing paths for multiple services to achieve a global optimization crit= eria (e.g. minimal summary total cost);

4.      = Computing paths for multiple services for the purpose of removing the bandw= idth fragmentations;

5.      = Computing paths for multiple services to plan shared mesh protection/restor= ation schemes

6.      = Etc.

 

Also think about this:

1.      = If concurrent path computation was not important, why PCEP includes the mac= hinery to do that?

2.      = My understanding of the statefull PCE is that it does pretty much nothing b= ut concurrent path computations

 

You also said:

>> I suppose that if a pce approach is used, i.e., path computatio= n is centralized including the
>> TE-DB, MELG routing extensions are not needed because the informat= ion about mutual
>>exclusive VLs can be kept in the central TE-DB when VLs are configu= red.

How this logic does not apply to other link attributes such as SRL= Gs?

What if path computation is not centralized?

 

Cheers,

Igor

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Hi Pavan,

On 25.03.2013 07:29, Fat= ai Zhang wrote:

Hi Pavan,

 

I am not sure how much VL (Virtual Link= ) will be used in the practical deployment and how often concurrent path computation will be used.

I guess we are coming back to the essential point: "and how often concurrent path computation will be used."

This means we are trying to figure out under which conditions MELG routing = extensions
could be beneficial.

IMHO, they would only make sense, if:

  • a path computation function supports the calculation of k shortest paths co= ncurrently
  • if there is only a single path computation function instance per domain (pc= e approach)
    If path computation is done in a distributed fashion the benefit goes away = because
    the instances calculate paths independently!

I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the
TE-DB, MELG routing extensions are not needed because the information about= mutual
exclusive VLs can be kept in the central TE-DB when VLs are configured.

Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their
applicability is broader.


Thanks,
Dieter

 

Do you think if it makes sense to add a flag (in= routing advertisement) to indicate a link is a VL or not?

 

 

 

Best Regards

 

Fatai

 

From: Vishnu Pavan Beeram [<= a href=3D"mailto:vishnupavan@gmail.com" target=3D"_blank">mailto:vishnupava= n@gmail.com]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Fatai, Hi!

 

Good to see that you understand the construct now.

 

This is not a corner case. The utility of the construct becomes qu= ite significant if you have an application that does concurrent path comput= ations on an abstract topology.

 

Regards,

-Pavan

 

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org=

https://www.ietf.org/mailman/listinfo/ccamp

 

--

DIETER BELLER

ALCATEL-LUCENT DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 = 711 821 43125
Mobil: +49 175 = 7266874

 

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe

 

--_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A19238D39atlsrvmail10atl_-- From kpithewan@infinera.com Fri Apr 12 09:06:01 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD16121F8E71 for ; Fri, 12 Apr 2013 09:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 rOo-94E3thRA for ; Fri, 12 Apr 2013 09:05:56 -0700 (PDT) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1551721F8E63 for ; Fri, 12 Apr 2013 09:05:56 -0700 (PDT) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.02.0342.003; Fri, 12 Apr 2013 09:05:55 -0700 From: Khuzema Pithewan To: Igor Bryskin , Vishnu Pavan Beeram Thread-Topic: [CCAMP] MELGs - Q&A Thread-Index: AQHOIGPek8R0zdnmbUizkEjN3z7415ivh4owgAA2TQCAATLDIIAAeV3g///IfQCABM8nkIABeO8AgAELY4CAGhSNwIAAhvCAgAAQMoD//6fVoIAAemEA//+PR9A= Date: Fri, 12 Apr 2013 16:05:54 +0000 Message-ID: References: <5150C704.2040007@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.156.128] Content-Type: multipart/alternative; boundary="_000_D8D01B39D6B38C45AA37C06ECC1D65D53FCEC509SVEXDBPROD1infi_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] MELGs - Q&A X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 16:06:01 -0000 --_000_D8D01B39D6B38C45AA37C06ECC1D65D53FCEC509SVEXDBPROD1infi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Igor, For multi-layer (more than 2) network, consider all the layers are meshy (t= hat's when virtual links are useful anyway), MELGs of virtual link will cha= nge as and when BW/wavelength availability changes, because potential paths= , a virtual link can take will change. Mapping lower layer MELGs to higher = layer MELGs won't be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all= the risk and paths (a PCE?), which can be utilized for layer specific path= computation (as it is doing it anyway). This kind of architecture has all the pieces that are required for Inter-PC= E communication (across layers), except the protocol that would actually ma= ke the 2 PCEs talk. You seem to be doing something that you don't like :) Regards Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 8:39 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, I am not a fan of inter-layer path computations (nor I am a fan of inter-PC= E computations). In my mind path computation for a service or services in l= ayer X is performed only in layer X, i.e. considers only X layer links (rea= l or virtual). As Pavan mentioned SRLGs and MELGs that need to be inherited= from lower layers should be translated into X layer link SRLGs/MELGs and s= pecified with X layer specific SRLG/MELG IDs. Cheers, Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 10:55 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Ok. This would be useful if network architecture is based on external PCE o= r mgmt entity as PCE in client layer, but there is no counterpart in server= layer, otherwise one could have inter-PCE communication to achieve diverse= path in server layer without getting into virtual link and MELG stuff. Is that correct? Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 6:36 PM To: Vishnu Pavan Beeram; Khuzema Pithewan Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. Well, when an ingress node is initiating a service, it is doing so on reque= st from some management entity. This management entity can compute paths fo= r many services with some global criteria in mind, and then specify the res= ulting paths as explicit EROs in provisioning requests sent to each of the = service ingresses. How else, for example, you can set up several services = originated from different nodes that are disjoint from each other? Also, wh= at is the point in your opinion of the statefull PCE work? Cheers, Igor From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, April 12, 2013 8:08 AM To: Khuzema Pithewan Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Khuzema, Hi! Please see inline.. 1. When Network has more than 2 layer i.e. Packet-OTN-DWDM, the Pack= et (client) layer will be talking to its immediate server layer i.e. OTN, w= hich in turn is talking to DWDM layer. Using MELG, client layer path comput= ation can take care of resource exclusivity of virtual link for immediate s= erver layer i.e. OTN layer. However if there is resource exclusivity at DW= DM layer, this mechanism doesn't work. You need to do loose routing or use = distributed PCE model [VPB] The behavior is the same as what you would do with SRLGs in a multi-l= ayer architecture. There are architectures that allow the SRLGs in the lowe= st layer to be exported all the way up to the highest layer. The expectatio= n is that MELGs would be treated in the same vein. 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. [VPB] I'm not sure why you think there is no point in having a centralized= computation function compute paths concurrently for LSPs with different se= t of end-points. Even your NMS/planning-software can interact with such com= putation engine, retrieve all the paths and then go about initiating the pa= th-setup from the ingress of each LSP. Regards, -Pavan From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Igor Bryskin Sent: Tuesday, March 26, 2013 7:19 PM To: Dieter Beller; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Dieter, You said: >> I guess we are coming back to the essential point: "and how often concur= rent path computation will be >> used." To be honest, this surprises me quite a bit, Let me give you some of many r= easons as to why concurrent path computations are needed and why this is be= tter than computing one path at a time: 1. Computing several diverse paths for the same service in the context= of service recovery. I hope you realize that computing one path at a time = on many configurations produces no or sub-optimal results. I also hope you = realize the problem of selecting two paths with one of them having a link = with common MELG with a link from another path; 2. Computing paths for multiple services to be sufficiently disjoint f= rom each other; 3. Computing paths for multiple services to achieve a global optimizat= ion criteria (e.g. minimal summary total cost); 4. Computing paths for multiple services for the purpose of removing t= he bandwidth fragmentations; 5. Computing paths for multiple services to plan shared mesh protectio= n/restoration schemes 6. Etc. Also think about this: 1. If concurrent path computation was not important, why PCEP includes= the machinery to do that? 2. My understanding of the statefull PCE is that it does pretty much n= othing but concurrent path computations You also said: >> I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the >> TE-DB, MELG routing extensions are not needed because the information ab= out mutual >>exclusive VLs can be kept in the central TE-DB when VLs are configured. How this logic does not apply to other link attributes such as SRLGs? What if path computation is not centralized? Cheers, Igor From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Dieter Beller Sent: Monday, March 25, 2013 5:52 PM To: Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Hi Pavan, On 25.03.2013 07:29, Fatai Zhang wrote: Hi Pavan, I am not sure how much VL (Virtual Link) will be used in the practical depl= oyment and how often concurrent path computation will be used. I guess we are coming back to the essential point: "and how often concurren= t path computation will be used." This means we are trying to figure out under which conditions MELG routing = extensions could be beneficial. IMHO, they would only make sense, if: * a path computation function supports the calculation of k shortest pa= ths concurrently * if there is only a single path computation function instance per doma= in (pce approach) If path computation is done in a distributed fashion the benefit goes away = because the instances calculate paths independently! I suppose that if a pce approach is used, i.e., path computation is central= ized including the TE-DB, MELG routing extensions are not needed because the information about= mutual exclusive VLs can be kept in the central TE-DB when VLs are configured. Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their applicability is broader. Thanks, Dieter Do you think if it makes sense to add a flag (in routing advertisement) to = indicate a link is a VL or not? Best Regards Fatai From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, March 22, 2013 8:57 PM To: Fatai Zhang Cc: Igor Bryskin; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Fatai, Hi! Good to see that you understand the construct now. This is not a corner case. The utility of the construct becomes quite signi= ficant if you have an application that does concurrent path computations on= an abstract topology. Regards, -Pavan _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp -- DIETER BELLER ALCATEL-LUCENT DEUTSCHLAND AG PROJECT MANAGER ASON/GMPLS CONTROL PLANE CORE NETWORKS BUSINESS DIVISION OPTICS BU, SWITCHING R&D Lorenzstrasse 10 70435 Stuttgart, Germany Phone: +49 711 821 43125 Mobil: +49 175 7266874 Dieter.Beller@alcatel-lucent.com Alcatel-Lucent Deutschland AG Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026 Chairman of the Supervisory Board: Michael Oppenhoff Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe --_000_D8D01B39D6B38C45AA37C06ECC1D65D53FCEC509SVEXDBPROD1infi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Igor,

 <= /p>

For multi-layer (more tha= n 2) network, consider all the layers are meshy (that’s when virtual = links are useful anyway), MELGs of virtual link will change as and when BW/wavelength availability changes, because potential paths, a vi= rtual link can take will change. Mapping lower layer MELGs to higher layer = MELGs won’t be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all the risk and paths (a PCE?), which ca= n be utilized for layer specific path computation (as it is doing it anyway= ).

 <= /p>

This kind of architecture= has all the pieces that are required for Inter-PCE communication (across l= ayers), except the protocol that would actually make the 2 PCEs talk.

 <= /p>

You seem to be doing some= thing that you don’t like J

 <= /p>

Regards=

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 8:39 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

I am not a fan of inter-l= ayer path computations (nor I am a fan of inter-PCE computations). In my mi= nd path computation for a service or services in layer X is performed only in layer X, i.e. considers only X layer links (real or v= irtual). As Pavan mentioned SRLGs and MELGs that need to be inherited from = lower layers should be translated into X layer link SRLGs/MELGs and specifi= ed with X layer specific SRLG/MELG IDs.

 <= /p>

Cheers,=

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 10:55 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

Ok. This would be useful = if network architecture is based on external PCE or mgmt entity as PCE in c= lient layer, but there is no counterpart in server layer, otherwise one could have inter-PCE communication to achieve diverse path i= n server layer without getting into virtual link and MELG stuff.

 <= /p>

Is that correct?

 <= /p>

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 6:36 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

2.       For cases of concurrent computation (case= #2-5), you are mainly talking about global optimization and diversity among= multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from th= e source end of those LSPs.  So there is no point in doing concurrent = computation at one network element for the services starting from multiple = network elements. At best it looks to me a problem to be solved by network management/planning software.&= nbsp;

Well, when an ingress nod= e is initiating a service, it is doing so on request from some management e= ntity. This management entity can compute paths for many services with some global criteria in mind, and then specify the resulting= paths as explicit EROs in provisioning requests sent to each of the servic= e ingresses. How else, for example,  you can set up several services o= riginated from different nodes that are disjoint from each other? Also, what is the point in your opinion of the s= tatefull PCE work?

 <= /p>

Cheers,=

Igor

 <= /p>

From: Vishnu P= avan Beeram [mailto:vishnupavan@gm= ail.com]
Sent: Friday, April 12, 2013 8:08 AM
To: Khuzema Pithewan
Cc: Igor Bryskin; Dieter Beller; c= camp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Khuzema, Hi!


Please see inline..

 

 

 1.       When Network has more than 2 layer i.e. P= acket-OTN-DWDM, the Packet (client) layer will be talking to its immediate = server layer i.e. OTN, which in turn is talking to DWDM layer. Using MELG, client layer path computation can take care of resource= exclusivity of virtual link for immediate server layer i.e. OTN layer.&nbs= p; However if there is resource exclusivity at DWDM layer, this mechanism d= oesn’t work. You need to do loose routing or use distributed PCE model

 

[VPB] The behavior is the same as what you would do = with SRLGs in a multi-layer architecture. There are architectures that allo= w the SRLGs in the lowest layer to be exported all the way up to the highes= t layer. The expectation is that MELGs would be treated in the same vein. 

2.       For cases of concurrent computation (case= #2-5), you are mainly talking about global optimization and diversity among= multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from th= e source end of those LSPs.  So there is no point in doing concurrent = computation at one network element for the services starting from multiple = network elements. At best it looks to me a problem to be solved by network management/planning software.&= nbsp;

[VPB]  I'm not sure why you think there is no p= oint in having a centralized computation function compute paths concurrentl= y for LSPs with different set of end-points. Even your NMS/planning-softwar= e can interact with such computation engine, retrieve all the paths and then go about initiating the path-setup from th= e ingress of each LSP. 

 

Regards,

-Pavan

 

 

 

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Tuesday, March 26, 2013 7:19 PM
To: Dieter Beller; Vishnu Pavan Beeram


Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Dieter,

 

You said:

>> I guess we are coming back to the essential point: "= and how often concurrent path computation will be >> used."

 

To be honest, this surprises me quite a bit, Let me give you some = of many reasons as to why concurrent path computations are needed and why t= his is better than computing one path at a time:

 

1.      = Computing several diverse paths for the same service in the context of serv= ice recovery. I hope you realize that computing one path at a time on many = configurations produces no or sub-optimal results. I also hope you realize the problem of selecting two paths with one of them  havi= ng a link with common MELG with a link from another path;

2.      = Computing paths for multiple services to be sufficiently disjoint from each= other;

3.      = Computing paths for multiple services to achieve a global optimization crit= eria (e.g. minimal summary total cost);

4.      = Computing paths for multiple services for the purpose of removing the bandw= idth fragmentations;

5.      = Computing paths for multiple services to plan shared mesh protection/restor= ation schemes

6.      = Etc.

 

Also think about this:

1.      = If concurrent path computation was not important, why PCEP includes the mac= hinery to do that?

2.      = My understanding of the statefull PCE is that it does pretty much nothing b= ut concurrent path computations

 

You also said:

>> I suppose that if a pce approach is used, i.e., path computatio= n is centralized including the
>> TE-DB, MELG routing extensions are not needed because the informat= ion about mutual
>>exclusive VLs can be kept in the central TE-DB when VLs are configu= red.

How this logic does not apply to other link attributes such as SRL= Gs?

What if path computation is not centralized?

 

Cheers,

Igor

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Hi Pavan,

On 25.03.2013 07:29, Fat= ai Zhang wrote:

Hi Pavan,

 

I am not sure how much VL (Virtual Link= ) will be used in the practical deployment and how often concurrent path computation will be used.

I guess we are coming back to the essential point: "and how often concurrent path computation will be used."

This means we are trying to figure out under which conditions MELG routing = extensions
could be beneficial.

IMHO, they would only make sense, if:

  • a path computation function supports the calculation of k shortest paths co= ncurrently
  • if there is only a single path computation function instance per domain (pc= e approach)
    If path computation is done in a distributed fashion the benefit goes away = because
    the instances calculate paths independently!

I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the
TE-DB, MELG routing extensions are not needed because the information about= mutual
exclusive VLs can be kept in the central TE-DB when VLs are configured.

Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their
applicability is broader.


Thanks,
Dieter

 

Do you think if it makes sense to add a flag (in= routing advertisement) to indicate a link is a VL or not?

 

 

 

Best Regards

 

Fatai

 

From: Vishnu Pavan Beeram [<= a href=3D"mailto:vishnupavan@gmail.com" target=3D"_blank">mailto:vishnupava= n@gmail.com]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Fatai, Hi!

 

Good to see that you understand the construct now.

 

This is not a corner case. The utility of the construct becomes qu= ite significant if you have an application that does concurrent path comput= ations on an abstract topology.

 

Regards,

-Pavan

 

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org=

https://www.ietf.org/mailman/listinfo/ccamp

 

--

DIETER BELLER

ALCATEL-LUCENT DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 = 711 821 43125
Mobil: +49 175 = 7266874

 

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe

 

--_000_D8D01B39D6B38C45AA37C06ECC1D65D53FCEC509SVEXDBPROD1infi_-- From IBryskin@advaoptical.com Fri Apr 12 09:22:43 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F93421F86D9 for ; Fri, 12 Apr 2013 09:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 RwAm95JXLzQu for ; Fri, 12 Apr 2013 09:22:31 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id 015AF21F8EFD for ; Fri, 12 Apr 2013 09:22:28 -0700 (PDT) Received: from MUC-SRV-MBX1.advaoptical.com ([172.20.1.95]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id r3CGMLaT021879 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Apr 2013 18:22:21 +0200 Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MBX1.advaoptical.com (172.20.1.95) with Microsoft SMTP Server (TLS) id 15.0.620.29; Fri, 12 Apr 2013 18:22:21 +0200 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0123.003; Fri, 12 Apr 2013 12:22:19 -0400 From: Igor Bryskin To: Khuzema Pithewan , Vishnu Pavan Beeram Thread-Topic: [CCAMP] MELGs - Q&A Thread-Index: AQHOIGPeoOQf0fNS1kG7ulofq5GmQJivzRoAgABxTHCAAPkpgIAAeAqAgABMBQCABErLAIABAdYAgAC6NQCAGt0OAIAAD52A///KWjCAAGRRgP//wCBQgABTlAD//73CwA== Date: Fri, 12 Apr 2013 16:22:18 +0000 Message-ID: References: <5150C704.2040007@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.1.77] Content-Type: multipart/alternative; boundary="_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A19238D8Eatlsrvmail10atl_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-04-12_06:2013-04-12, 2013-04-12, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] MELGs - Q&A X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 16:22:43 -0000 --_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A19238D8Eatlsrvmail10atl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Khuzema, MELGs have nothing to do with bandwidth. MELG is a concrete network resourc= e in a server layer that two or more Virtual Links in a client layer depend= on in a mutually exclusive way. An example of MELG is a WDM layer transpon= der that can terminate either of respective WDM layer tunnels (but not both= at the same time) for two OTN layer Virtual Links. If you advertise a Virt= ual Link, say, for Ethernet layer that depends on the connection in OTN lay= er going through one of the mentioned OTN links, the Ethernet VL must inher= it the MELG similarly like it does SRLGs advertised for the OTN links. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 12:06 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, For multi-layer (more than 2) network, consider all the layers are meshy (t= hat's when virtual links are useful anyway), MELGs of virtual link will cha= nge as and when BW/wavelength availability changes, because potential paths= , a virtual link can take will change. Mapping lower layer MELGs to higher = layer MELGs won't be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all= the risk and paths (a PCE?), which can be utilized for layer specific path= computation (as it is doing it anyway). This kind of architecture has all the pieces that are required for Inter-PC= E communication (across layers), except the protocol that would actually ma= ke the 2 PCEs talk. You seem to be doing something that you don't like :) Regards Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 8:39 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, I am not a fan of inter-layer path computations (nor I am a fan of inter-PC= E computations). In my mind path computation for a service or services in l= ayer X is performed only in layer X, i.e. considers only X layer links (rea= l or virtual). As Pavan mentioned SRLGs and MELGs that need to be inherited= from lower layers should be translated into X layer link SRLGs/MELGs and s= pecified with X layer specific SRLG/MELG IDs. Cheers, Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 10:55 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Ok. This would be useful if network architecture is based on external PCE o= r mgmt entity as PCE in client layer, but there is no counterpart in server= layer, otherwise one could have inter-PCE communication to achieve diverse= path in server layer without getting into virtual link and MELG stuff. Is that correct? Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 6:36 PM To: Vishnu Pavan Beeram; Khuzema Pithewan Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. Well, when an ingress node is initiating a service, it is doing so on reque= st from some management entity. This management entity can compute paths fo= r many services with some global criteria in mind, and then specify the res= ulting paths as explicit EROs in provisioning requests sent to each of the = service ingresses. How else, for example, you can set up several services = originated from different nodes that are disjoint from each other? Also, wh= at is the point in your opinion of the statefull PCE work? Cheers, Igor From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, April 12, 2013 8:08 AM To: Khuzema Pithewan Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Khuzema, Hi! Please see inline.. 1. When Network has more than 2 layer i.e. Packet-OTN-DWDM, the Pack= et (client) layer will be talking to its immediate server layer i.e. OTN, w= hich in turn is talking to DWDM layer. Using MELG, client layer path comput= ation can take care of resource exclusivity of virtual link for immediate s= erver layer i.e. OTN layer. However if there is resource exclusivity at DW= DM layer, this mechanism doesn't work. You need to do loose routing or use = distributed PCE model [VPB] The behavior is the same as what you would do with SRLGs in a multi-l= ayer architecture. There are architectures that allow the SRLGs in the lowe= st layer to be exported all the way up to the highest layer. The expectatio= n is that MELGs would be treated in the same vein. 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. [VPB] I'm not sure why you think there is no point in having a centralized= computation function compute paths concurrently for LSPs with different se= t of end-points. Even your NMS/planning-software can interact with such com= putation engine, retrieve all the paths and then go about initiating the pa= th-setup from the ingress of each LSP. Regards, -Pavan From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Igor Bryskin Sent: Tuesday, March 26, 2013 7:19 PM To: Dieter Beller; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Dieter, You said: >> I guess we are coming back to the essential point: "and how often concur= rent path computation will be >> used." To be honest, this surprises me quite a bit, Let me give you some of many r= easons as to why concurrent path computations are needed and why this is be= tter than computing one path at a time: 1. Computing several diverse paths for the same service in the context= of service recovery. I hope you realize that computing one path at a time = on many configurations produces no or sub-optimal results. I also hope you = realize the problem of selecting two paths with one of them having a link = with common MELG with a link from another path; 2. Computing paths for multiple services to be sufficiently disjoint f= rom each other; 3. Computing paths for multiple services to achieve a global optimizat= ion criteria (e.g. minimal summary total cost); 4. Computing paths for multiple services for the purpose of removing t= he bandwidth fragmentations; 5. Computing paths for multiple services to plan shared mesh protectio= n/restoration schemes 6. Etc. Also think about this: 1. If concurrent path computation was not important, why PCEP includes= the machinery to do that? 2. My understanding of the statefull PCE is that it does pretty much n= othing but concurrent path computations You also said: >> I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the >> TE-DB, MELG routing extensions are not needed because the information ab= out mutual >>exclusive VLs can be kept in the central TE-DB when VLs are configured. How this logic does not apply to other link attributes such as SRLGs? What if path computation is not centralized? Cheers, Igor From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Dieter Beller Sent: Monday, March 25, 2013 5:52 PM To: Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Hi Pavan, On 25.03.2013 07:29, Fatai Zhang wrote: Hi Pavan, I am not sure how much VL (Virtual Link) will be used in the practical depl= oyment and how often concurrent path computation will be used. I guess we are coming back to the essential point: "and how often concurren= t path computation will be used." This means we are trying to figure out under which conditions MELG routing = extensions could be beneficial. IMHO, they would only make sense, if: * a path computation function supports the calculation of k shortest pa= ths concurrently * if there is only a single path computation function instance per doma= in (pce approach) If path computation is done in a distributed fashion the benefit goes away = because the instances calculate paths independently! I suppose that if a pce approach is used, i.e., path computation is central= ized including the TE-DB, MELG routing extensions are not needed because the information about= mutual exclusive VLs can be kept in the central TE-DB when VLs are configured. Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their applicability is broader. Thanks, Dieter Do you think if it makes sense to add a flag (in routing advertisement) to = indicate a link is a VL or not? Best Regards Fatai From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, March 22, 2013 8:57 PM To: Fatai Zhang Cc: Igor Bryskin; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Fatai, Hi! Good to see that you understand the construct now. This is not a corner case. The utility of the construct becomes quite signi= ficant if you have an application that does concurrent path computations on= an abstract topology. Regards, -Pavan _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp -- DIETER BELLER ALCATEL-LUCENT DEUTSCHLAND AG PROJECT MANAGER ASON/GMPLS CONTROL PLANE CORE NETWORKS BUSINESS DIVISION OPTICS BU, SWITCHING R&D Lorenzstrasse 10 70435 Stuttgart, Germany Phone: +49 711 821 43125 Mobil: +49 175 7266874 Dieter.Beller@alcatel-lucent.com Alcatel-Lucent Deutschland AG Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026 Chairman of the Supervisory Board: Michael Oppenhoff Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe --_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A19238D8Eatlsrvmail10atl_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Khuzema,

 <= /p>

MELGs have nothing to do = with bandwidth. MELG is a concrete network resource in a server layer that = two or more Virtual Links in a client layer depend on in a mutually exclusive way. An example of MELG is a WDM layer transponder th= at can terminate either of respective WDM layer tunnels (but not both at th= e same time) for two OTN layer Virtual Links. If you advertise a Virtual Li= nk, say, for Ethernet layer that depends on the connection in OTN layer going through one of the mentioned = OTN links, the Ethernet VL must inherit the MELG similarly like it does SRL= Gs advertised for the OTN links.

 <= /p>

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 12:06 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

For multi-layer (more tha= n 2) network, consider all the layers are meshy (that’s when virtual = links are useful anyway), MELGs of virtual link will change as and when BW/wavelength availability changes, because potential paths, a vi= rtual link can take will change. Mapping lower layer MELGs to higher layer = MELGs won’t be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all the risk and paths (a PCE?), which ca= n be utilized for layer specific path computation (as it is doing it anyway= ).

 <= /p>

This kind of architecture= has all the pieces that are required for Inter-PCE communication (across l= ayers), except the protocol that would actually make the 2 PCEs talk.

 <= /p>

You seem to be doing some= thing that you don’t like J

 <= /p>

Regards=

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 8:39 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

I am not a fan of inter-l= ayer path computations (nor I am a fan of inter-PCE computations). In my mi= nd path computation for a service or services in layer X is performed only in layer X, i.e. considers only X layer links (real or v= irtual). As Pavan mentioned SRLGs and MELGs that need to be inherited from = lower layers should be translated into X layer link SRLGs/MELGs and specifi= ed with X layer specific SRLG/MELG IDs.

 <= /p>

Cheers,=

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Friday, April 12, 2013 10:55 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

Ok. This would be useful = if network architecture is based on external PCE or mgmt entity as PCE in c= lient layer, but there is no counterpart in server layer, otherwise one could have inter-PCE communication to achieve diverse path i= n server layer without getting into virtual link and MELG stuff.

 <= /p>

Is that correct?

 <= /p>

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 6:36 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

2.       For cases of concurrent computation (case= #2-5), you are mainly talking about global optimization and diversity among= multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from th= e source end of those LSPs.  So there is no point in doing concurrent = computation at one network element for the services starting from multiple = network elements. At best it looks to me a problem to be solved by network management/planning software.&= nbsp;

Well, when an ingress nod= e is initiating a service, it is doing so on request from some management e= ntity. This management entity can compute paths for many services with some global criteria in mind, and then specify the resulting= paths as explicit EROs in provisioning requests sent to each of the servic= e ingresses. How else, for example,  you can set up several services o= riginated from different nodes that are disjoint from each other? Also, what is the point in your opinion of the s= tatefull PCE work?

 <= /p>

Cheers,=

Igor

 <= /p>

From: Vishnu P= avan Beeram [mailto:vishnupavan@gm= ail.com]
Sent: Friday, April 12, 2013 8:08 AM
To: Khuzema Pithewan
Cc: Igor Bryskin; Dieter Beller; c= camp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Khuzema, Hi!


Please see inline..

 

 

 1.       When Network has more than 2 layer i.e. P= acket-OTN-DWDM, the Packet (client) layer will be talking to its immediate = server layer i.e. OTN, which in turn is talking to DWDM layer. Using MELG, client layer path computation can take care of resource= exclusivity of virtual link for immediate server layer i.e. OTN layer.&nbs= p; However if there is resource exclusivity at DWDM layer, this mechanism d= oesn’t work. You need to do loose routing or use distributed PCE model

 

[VPB] The behavior is the same as what you would do = with SRLGs in a multi-layer architecture. There are architectures that allo= w the SRLGs in the lowest layer to be exported all the way up to the highes= t layer. The expectation is that MELGs would be treated in the same vein. 

2.       For cases of concurrent computation (case= #2-5), you are mainly talking about global optimization and diversity among= multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from th= e source end of those LSPs.  So there is no point in doing concurrent = computation at one network element for the services starting from multiple = network elements. At best it looks to me a problem to be solved by network management/planning software.&= nbsp;

[VPB]  I'm not sure why you think there is no p= oint in having a centralized computation function compute paths concurrentl= y for LSPs with different set of end-points. Even your NMS/planning-softwar= e can interact with such computation engine, retrieve all the paths and then go about initiating the path-setup from th= e ingress of each LSP. 

 

Regards,

-Pavan

 

 

 

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Tuesday, March 26, 2013 7:19 PM
To: Dieter Beller; Vishnu Pavan Beeram


Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Dieter,

 

You said:

>> I guess we are coming back to the essential point: "= and how often concurrent path computation will be >> used."

 

To be honest, this surprises me quite a bit, Let me give you some = of many reasons as to why concurrent path computations are needed and why t= his is better than computing one path at a time:

 

1.      = Computing several diverse paths for the same service in the context of serv= ice recovery. I hope you realize that computing one path at a time on many = configurations produces no or sub-optimal results. I also hope you realize the problem of selecting two paths with one of them  havi= ng a link with common MELG with a link from another path;

2.      = Computing paths for multiple services to be sufficiently disjoint from each= other;

3.      = Computing paths for multiple services to achieve a global optimization crit= eria (e.g. minimal summary total cost);

4.      = Computing paths for multiple services for the purpose of removing the bandw= idth fragmentations;

5.      = Computing paths for multiple services to plan shared mesh protection/restor= ation schemes

6.      = Etc.

 

Also think about this:

1.      = If concurrent path computation was not important, why PCEP includes the mac= hinery to do that?

2.      = My understanding of the statefull PCE is that it does pretty much nothing b= ut concurrent path computations

 

You also said:

>> I suppose that if a pce approach is used, i.e., path computatio= n is centralized including the
>> TE-DB, MELG routing extensions are not needed because the informat= ion about mutual
>>exclusive VLs can be kept in the central TE-DB when VLs are configu= red.

How this logic does not apply to other link attributes such as SRL= Gs?

What if path computation is not centralized?

 

Cheers,

Igor

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Hi Pavan,

On 25.03.2013 07:29, Fat= ai Zhang wrote:

Hi Pavan,

 

I am not sure how much VL (Virtual Link= ) will be used in the practical deployment and how often concurrent path computation will be used.

I guess we are coming back to the essential point: "and how often concurrent path computation will be used."

This means we are trying to figure out under which conditions MELG routing = extensions
could be beneficial.

IMHO, they would only make sense, if:

  • a path computation function supports the calculation of k shortest paths co= ncurrently
  • if there is only a single path computation function instance per domain (pc= e approach)
    If path computation is done in a distributed fashion the benefit goes away = because
    the instances calculate paths independently!

I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the
TE-DB, MELG routing extensions are not needed because the information about= mutual
exclusive VLs can be kept in the central TE-DB when VLs are configured.

Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their
applicability is broader.


Thanks,
Dieter

 

Do you think if it makes sense to add a flag (in= routing advertisement) to indicate a link is a VL or not?

 

 

 

Best Regards

 

Fatai

 

From: Vishnu Pavan Beeram [<= a href=3D"mailto:vishnupavan@gmail.com" target=3D"_blank">mailto:vishnupava= n@gmail.com]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Fatai, Hi!

 

Good to see that you understand the construct now.

 

This is not a corner case. The utility of the construct becomes qu= ite significant if you have an application that does concurrent path comput= ations on an abstract topology.

 

Regards,

-Pavan

 

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org=

https://www.ietf.org/mailman/listinfo/ccamp

 

--

DIETER BELLER

ALCATEL-LUCENT DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 = 711 821 43125
Mobil: +49 175 = 7266874

 

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe

 

--_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A19238D8Eatlsrvmail10atl_-- From kpithewan@infinera.com Fri Apr 12 10:01:01 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD0021F8842 for ; Fri, 12 Apr 2013 10:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 IWlQzM8b69K1 for ; Fri, 12 Apr 2013 10:00:54 -0700 (PDT) Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1E221F87E0 for ; Fri, 12 Apr 2013 10:00:54 -0700 (PDT) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.02.0342.003; Fri, 12 Apr 2013 10:00:53 -0700 From: Khuzema Pithewan To: Igor Bryskin , Vishnu Pavan Beeram Thread-Topic: [CCAMP] MELGs - Q&A Thread-Index: AQHOIGPek8R0zdnmbUizkEjN3z7415ivh4owgAA2TQCAATLDIIAAeV3g///IfQCABM8nkIABeO8AgAELY4CAGhSNwIAAhvCAgAAQMoD//6fVoIAAemEA//+PR9AAEKirAAANdD1g Date: Fri, 12 Apr 2013 17:00:52 +0000 Message-ID: References: <5150C704.2040007@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.156.128] Content-Type: multipart/alternative; boundary="_000_D8D01B39D6B38C45AA37C06ECC1D65D53FCEC5D3SVEXDBPROD1infi_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] MELGs - Q&A X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 17:01:01 -0000 --_000_D8D01B39D6B38C45AA37C06ECC1D65D53FCEC5D3SVEXDBPROD1infi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Igor, Do you mean, if virtual link do not have any specific constraint, for examp= le a link in the path (not talking about egress links/interfaces) must be t= raversed to realize the virtual link, there wont be any MELG for the virtua= l link? Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 9:52 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, MELGs have nothing to do with bandwidth. MELG is a concrete network resourc= e in a server layer that two or more Virtual Links in a client layer depend= on in a mutually exclusive way. An example of MELG is a WDM layer transpon= der that can terminate either of respective WDM layer tunnels (but not both= at the same time) for two OTN layer Virtual Links. If you advertise a Virt= ual Link, say, for Ethernet layer that depends on the connection in OTN lay= er going through one of the mentioned OTN links, the Ethernet VL must inher= it the MELG similarly like it does SRLGs advertised for the OTN links. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 12:06 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, For multi-layer (more than 2) network, consider all the layers are meshy (t= hat's when virtual links are useful anyway), MELGs of virtual link will cha= nge as and when BW/wavelength availability changes, because potential paths= , a virtual link can take will change. Mapping lower layer MELGs to higher = layer MELGs won't be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all= the risk and paths (a PCE?), which can be utilized for layer specific path= computation (as it is doing it anyway). This kind of architecture has all the pieces that are required for Inter-PC= E communication (across layers), except the protocol that would actually ma= ke the 2 PCEs talk. You seem to be doing something that you don't like :) Regards Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 8:39 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, I am not a fan of inter-layer path computations (nor I am a fan of inter-PC= E computations). In my mind path computation for a service or services in l= ayer X is performed only in layer X, i.e. considers only X layer links (rea= l or virtual). As Pavan mentioned SRLGs and MELGs that need to be inherited= from lower layers should be translated into X layer link SRLGs/MELGs and s= pecified with X layer specific SRLG/MELG IDs. Cheers, Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 10:55 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Ok. This would be useful if network architecture is based on external PCE o= r mgmt entity as PCE in client layer, but there is no counterpart in server= layer, otherwise one could have inter-PCE communication to achieve diverse= path in server layer without getting into virtual link and MELG stuff. Is that correct? Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 6:36 PM To: Vishnu Pavan Beeram; Khuzema Pithewan Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. Well, when an ingress node is initiating a service, it is doing so on reque= st from some management entity. This management entity can compute paths fo= r many services with some global criteria in mind, and then specify the res= ulting paths as explicit EROs in provisioning requests sent to each of the = service ingresses. How else, for example, you can set up several services = originated from different nodes that are disjoint from each other? Also, wh= at is the point in your opinion of the statefull PCE work? Cheers, Igor From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, April 12, 2013 8:08 AM To: Khuzema Pithewan Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Khuzema, Hi! Please see inline.. 1. When Network has more than 2 layer i.e. Packet-OTN-DWDM, the Pack= et (client) layer will be talking to its immediate server layer i.e. OTN, w= hich in turn is talking to DWDM layer. Using MELG, client layer path comput= ation can take care of resource exclusivity of virtual link for immediate s= erver layer i.e. OTN layer. However if there is resource exclusivity at DW= DM layer, this mechanism doesn't work. You need to do loose routing or use = distributed PCE model [VPB] The behavior is the same as what you would do with SRLGs in a multi-l= ayer architecture. There are architectures that allow the SRLGs in the lowe= st layer to be exported all the way up to the highest layer. The expectatio= n is that MELGs would be treated in the same vein. 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. [VPB] I'm not sure why you think there is no point in having a centralized= computation function compute paths concurrently for LSPs with different se= t of end-points. Even your NMS/planning-software can interact with such com= putation engine, retrieve all the paths and then go about initiating the pa= th-setup from the ingress of each LSP. Regards, -Pavan From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Igor Bryskin Sent: Tuesday, March 26, 2013 7:19 PM To: Dieter Beller; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Dieter, You said: >> I guess we are coming back to the essential point: "and how often concur= rent path computation will be >> used." To be honest, this surprises me quite a bit, Let me give you some of many r= easons as to why concurrent path computations are needed and why this is be= tter than computing one path at a time: 1. Computing several diverse paths for the same service in the context= of service recovery. I hope you realize that computing one path at a time = on many configurations produces no or sub-optimal results. I also hope you = realize the problem of selecting two paths with one of them having a link = with common MELG with a link from another path; 2. Computing paths for multiple services to be sufficiently disjoint f= rom each other; 3. Computing paths for multiple services to achieve a global optimizat= ion criteria (e.g. minimal summary total cost); 4. Computing paths for multiple services for the purpose of removing t= he bandwidth fragmentations; 5. Computing paths for multiple services to plan shared mesh protectio= n/restoration schemes 6. Etc. Also think about this: 1. If concurrent path computation was not important, why PCEP includes= the machinery to do that? 2. My understanding of the statefull PCE is that it does pretty much n= othing but concurrent path computations You also said: >> I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the >> TE-DB, MELG routing extensions are not needed because the information ab= out mutual >>exclusive VLs can be kept in the central TE-DB when VLs are configured. How this logic does not apply to other link attributes such as SRLGs? What if path computation is not centralized? Cheers, Igor From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Dieter Beller Sent: Monday, March 25, 2013 5:52 PM To: Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Hi Pavan, On 25.03.2013 07:29, Fatai Zhang wrote: Hi Pavan, I am not sure how much VL (Virtual Link) will be used in the practical depl= oyment and how often concurrent path computation will be used. I guess we are coming back to the essential point: "and how often concurren= t path computation will be used." This means we are trying to figure out under which conditions MELG routing = extensions could be beneficial. IMHO, they would only make sense, if: * a path computation function supports the calculation of k shortest pa= ths concurrently * if there is only a single path computation function instance per doma= in (pce approach) If path computation is done in a distributed fashion the benefit goes away = because the instances calculate paths independently! I suppose that if a pce approach is used, i.e., path computation is central= ized including the TE-DB, MELG routing extensions are not needed because the information about= mutual exclusive VLs can be kept in the central TE-DB when VLs are configured. Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their applicability is broader. Thanks, Dieter Do you think if it makes sense to add a flag (in routing advertisement) to = indicate a link is a VL or not? Best Regards Fatai From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, March 22, 2013 8:57 PM To: Fatai Zhang Cc: Igor Bryskin; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Fatai, Hi! Good to see that you understand the construct now. This is not a corner case. The utility of the construct becomes quite signi= ficant if you have an application that does concurrent path computations on= an abstract topology. Regards, -Pavan _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp -- DIETER BELLER ALCATEL-LUCENT DEUTSCHLAND AG PROJECT MANAGER ASON/GMPLS CONTROL PLANE CORE NETWORKS BUSINESS DIVISION OPTICS BU, SWITCHING R&D Lorenzstrasse 10 70435 Stuttgart, Germany Phone: +49 711 821 43125 Mobil: +49 175 7266874 Dieter.Beller@alcatel-lucent.com Alcatel-Lucent Deutschland AG Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026 Chairman of the Supervisory Board: Michael Oppenhoff Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe --_000_D8D01B39D6B38C45AA37C06ECC1D65D53FCEC5D3SVEXDBPROD1infi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Igor,

 <= /p>

Do you mean, if virtual l= ink do not have any specific constraint, for example a link in the path (no= t talking about egress links/interfaces) must be traversed to realize the virtual link, there wont be any MELG for the virtual link?<= o:p>

 <= /p>

Regds

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 9:52 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

MELGs have nothing to do = with bandwidth. MELG is a concrete network resource in a server layer that = two or more Virtual Links in a client layer depend on in a mutually exclusive way. An example of MELG is a WDM layer transponder th= at can terminate either of respective WDM layer tunnels (but not both at th= e same time) for two OTN layer Virtual Links. If you advertise a Virtual Li= nk, say, for Ethernet layer that depends on the connection in OTN layer going through one of the mentioned = OTN links, the Ethernet VL must inherit the MELG similarly like it does SRL= Gs advertised for the OTN links.

 <= /p>

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 12:06 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

For multi-layer (more tha= n 2) network, consider all the layers are meshy (that’s when virtual = links are useful anyway), MELGs of virtual link will change as and when BW/wavelength availability changes, because potential paths, a vi= rtual link can take will change. Mapping lower layer MELGs to higher layer = MELGs won’t be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all the risk and paths (a PCE?), which ca= n be utilized for layer specific path computation (as it is doing it anyway= ).

 <= /p>

This kind of architecture= has all the pieces that are required for Inter-PCE communication (across l= ayers), except the protocol that would actually make the 2 PCEs talk.

 <= /p>

You seem to be doing some= thing that you don’t like J

 <= /p>

Regards=

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 8:39 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

I am not a fan of inter-l= ayer path computations (nor I am a fan of inter-PCE computations). In my mi= nd path computation for a service or services in layer X is performed only in layer X, i.e. considers only X layer links (real or v= irtual). As Pavan mentioned SRLGs and MELGs that need to be inherited from = lower layers should be translated into X layer link SRLGs/MELGs and specifi= ed with X layer specific SRLG/MELG IDs.

 <= /p>

Cheers,=

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Friday, April 12, 2013 10:55 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

Ok. This would be useful = if network architecture is based on external PCE or mgmt entity as PCE in c= lient layer, but there is no counterpart in server layer, otherwise one could have inter-PCE communication to achieve diverse path i= n server layer without getting into virtual link and MELG stuff.

 <= /p>

Is that correct?

 <= /p>

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 6:36 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

2.       For cases of concurrent computation (case= #2-5), you are mainly talking about global optimization and diversity among= multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from th= e source end of those LSPs.  So there is no point in doing concurrent = computation at one network element for the services starting from multiple = network elements. At best it looks to me a problem to be solved by network management/planning software.&= nbsp;

Well, when an ingress nod= e is initiating a service, it is doing so on request from some management e= ntity. This management entity can compute paths for many services with some global criteria in mind, and then specify the resulting= paths as explicit EROs in provisioning requests sent to each of the servic= e ingresses. How else, for example,  you can set up several services o= riginated from different nodes that are disjoint from each other? Also, what is the point in your opinion of the s= tatefull PCE work?

 <= /p>

Cheers,=

Igor

 <= /p>

From: Vishnu P= avan Beeram [mailto:vishnupavan@gm= ail.com]
Sent: Friday, April 12, 2013 8:08 AM
To: Khuzema Pithewan
Cc: Igor Bryskin; Dieter Beller; c= camp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Khuzema, Hi!


Please see inline..

 

 

 1.       When Network has more than 2 layer i.e. P= acket-OTN-DWDM, the Packet (client) layer will be talking to its immediate = server layer i.e. OTN, which in turn is talking to DWDM layer. Using MELG, client layer path computation can take care of resource= exclusivity of virtual link for immediate server layer i.e. OTN layer.&nbs= p; However if there is resource exclusivity at DWDM layer, this mechanism d= oesn’t work. You need to do loose routing or use distributed PCE model

 

[VPB] The behavior is the same as what you would do = with SRLGs in a multi-layer architecture. There are architectures that allo= w the SRLGs in the lowest layer to be exported all the way up to the highes= t layer. The expectation is that MELGs would be treated in the same vein. 

2.       For cases of concurrent computation (case= #2-5), you are mainly talking about global optimization and diversity among= multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from th= e source end of those LSPs.  So there is no point in doing concurrent = computation at one network element for the services starting from multiple = network elements. At best it looks to me a problem to be solved by network management/planning software.&= nbsp;

[VPB]  I'm not sure why you think there is no p= oint in having a centralized computation function compute paths concurrentl= y for LSPs with different set of end-points. Even your NMS/planning-softwar= e can interact with such computation engine, retrieve all the paths and then go about initiating the path-setup from th= e ingress of each LSP. 

 

Regards,

-Pavan

 

 

 

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Tuesday, March 26, 2013 7:19 PM
To: Dieter Beller; Vishnu Pavan Beeram


Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Dieter,

 

You said:

>> I guess we are coming back to the essential point: "= and how often concurrent path computation will be >> used."

 

To be honest, this surprises me quite a bit, Let me give you some = of many reasons as to why concurrent path computations are needed and why t= his is better than computing one path at a time:

 

1.      = Computing several diverse paths for the same service in the context of serv= ice recovery. I hope you realize that computing one path at a time on many = configurations produces no or sub-optimal results. I also hope you realize the problem of selecting two paths with one of them  havi= ng a link with common MELG with a link from another path;

2.      = Computing paths for multiple services to be sufficiently disjoint from each= other;

3.      = Computing paths for multiple services to achieve a global optimization crit= eria (e.g. minimal summary total cost);

4.      = Computing paths for multiple services for the purpose of removing the bandw= idth fragmentations;

5.      = Computing paths for multiple services to plan shared mesh protection/restor= ation schemes

6.      = Etc.

 

Also think about this:

1.      = If concurrent path computation was not important, why PCEP includes the mac= hinery to do that?

2.      = My understanding of the statefull PCE is that it does pretty much nothing b= ut concurrent path computations

 

You also said:

>> I suppose that if a pce approach is used, i.e., path computatio= n is centralized including the
>> TE-DB, MELG routing extensions are not needed because the informat= ion about mutual
>>exclusive VLs can be kept in the central TE-DB when VLs are configu= red.

How this logic does not apply to other link attributes such as SRL= Gs?

What if path computation is not centralized?

 

Cheers,

Igor

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Hi Pavan,

On 25.03.2013 07:29, Fat= ai Zhang wrote:

Hi Pavan,

 

I am not sure how much VL (Virtual Link= ) will be used in the practical deployment and how often concurrent path computation will be used.

I guess we are coming back to the essential point: "and how often concurrent path computation will be used."

This means we are trying to figure out under which conditions MELG routing = extensions
could be beneficial.

IMHO, they would only make sense, if:

  • a path computation function supports the calculation of k shortest paths co= ncurrently
  • if there is only a single path computation function instance per domain (pc= e approach)
    If path computation is done in a distributed fashion the benefit goes away = because
    the instances calculate paths independently!

I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the
TE-DB, MELG routing extensions are not needed because the information about= mutual
exclusive VLs can be kept in the central TE-DB when VLs are configured.

Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their
applicability is broader.


Thanks,
Dieter

 

Do you think if it makes sense to add a flag (in= routing advertisement) to indicate a link is a VL or not?

 

 

 

Best Regards

 

Fatai

 

From: Vishnu Pavan Beeram [<= a href=3D"mailto:vishnupavan@gmail.com" target=3D"_blank">mailto:vishnupava= n@gmail.com]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Fatai, Hi!

 

Good to see that you understand the construct now.

 

This is not a corner case. The utility of the construct becomes qu= ite significant if you have an application that does concurrent path comput= ations on an abstract topology.

 

Regards,

-Pavan

 

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org=

https://www.ietf.org/mailman/listinfo/ccamp

 

--

DIETER BELLER

ALCATEL-LUCENT DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 = 711 821 43125
Mobil: +49 175 = 7266874

 

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe

 

--_000_D8D01B39D6B38C45AA37C06ECC1D65D53FCEC5D3SVEXDBPROD1infi_-- From IBryskin@advaoptical.com Fri Apr 12 11:25:57 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA6621F87F5 for ; Fri, 12 Apr 2013 11:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 gmWy4j2laKIx for ; Fri, 12 Apr 2013 11:25:50 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id 98F8421F8D4E for ; Fri, 12 Apr 2013 11:25:37 -0700 (PDT) Received: from MUC-SRV-MBX1.advaoptical.com ([172.20.1.95]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id r3CIPQfW018266 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Apr 2013 20:25:26 +0200 Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MBX1.advaoptical.com (172.20.1.95) with Microsoft SMTP Server (TLS) id 15.0.620.29; Fri, 12 Apr 2013 20:25:25 +0200 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0123.003; Fri, 12 Apr 2013 14:25:23 -0400 From: Igor Bryskin To: Khuzema Pithewan , Vishnu Pavan Beeram Thread-Topic: [CCAMP] MELGs - Q&A Thread-Index: AQHOIGPeoOQf0fNS1kG7ulofq5GmQJivzRoAgABxTHCAAPkpgIAAeAqAgABMBQCABErLAIABAdYAgAC6NQCAGt0OAIAAD52A///KWjCAAGRRgP//wCBQgABTlAD//73CwAAKM0gAAAY9GCA= Date: Fri, 12 Apr 2013 18:25:23 +0000 Message-ID: References: <5150C704.2040007@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.1.77] Content-Type: multipart/alternative; boundary="_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A19238DF9atlsrvmail10atl_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-04-12_06:2013-04-12, 2013-04-12, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] MELGs - Q&A X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 18:25:57 -0000 --_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A19238DF9atlsrvmail10atl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Khuzema, Think about MELG as an SRLG that is shared between two or more links in its= entirety. When two real links have an SRLG in common, it means that two re= al links can co-exist concurrently, but there is something (e.g. common con= duit, note that the conduit has room for more than for one link) that will = bring both these links down, if this something fails (e.g. conduit is cut )= . Now consider that this something must be taken in its entirety by one of = the links to become operational . In this case SRLG becomes MELG. Note that= MELG is only meaningful for virtual links (unlike SRLG that makes sense fo= r either real or virtual link). Why would you advertise two links that mutu= ally exclude each other rather than advertising only one of them at a time,= unless the two are virtual links and hence both available for the client l= ayer connections? Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 1:01 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Do you mean, if virtual link do not have any specific constraint, for examp= le a link in the path (not talking about egress links/interfaces) must be t= raversed to realize the virtual link, there wont be any MELG for the virtua= l link? Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 9:52 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, MELGs have nothing to do with bandwidth. MELG is a concrete network resourc= e in a server layer that two or more Virtual Links in a client layer depend= on in a mutually exclusive way. An example of MELG is a WDM layer transpon= der that can terminate either of respective WDM layer tunnels (but not both= at the same time) for two OTN layer Virtual Links. If you advertise a Virt= ual Link, say, for Ethernet layer that depends on the connection in OTN lay= er going through one of the mentioned OTN links, the Ethernet VL must inher= it the MELG similarly like it does SRLGs advertised for the OTN links. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 12:06 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, For multi-layer (more than 2) network, consider all the layers are meshy (t= hat's when virtual links are useful anyway), MELGs of virtual link will cha= nge as and when BW/wavelength availability changes, because potential paths= , a virtual link can take will change. Mapping lower layer MELGs to higher = layer MELGs won't be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all= the risk and paths (a PCE?), which can be utilized for layer specific path= computation (as it is doing it anyway). This kind of architecture has all the pieces that are required for Inter-PC= E communication (across layers), except the protocol that would actually ma= ke the 2 PCEs talk. You seem to be doing something that you don't like :) Regards Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 8:39 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, I am not a fan of inter-layer path computations (nor I am a fan of inter-PC= E computations). In my mind path computation for a service or services in l= ayer X is performed only in layer X, i.e. considers only X layer links (rea= l or virtual). As Pavan mentioned SRLGs and MELGs that need to be inherited= from lower layers should be translated into X layer link SRLGs/MELGs and s= pecified with X layer specific SRLG/MELG IDs. Cheers, Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 10:55 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Ok. This would be useful if network architecture is based on external PCE o= r mgmt entity as PCE in client layer, but there is no counterpart in server= layer, otherwise one could have inter-PCE communication to achieve diverse= path in server layer without getting into virtual link and MELG stuff. Is that correct? Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 6:36 PM To: Vishnu Pavan Beeram; Khuzema Pithewan Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. Well, when an ingress node is initiating a service, it is doing so on reque= st from some management entity. This management entity can compute paths fo= r many services with some global criteria in mind, and then specify the res= ulting paths as explicit EROs in provisioning requests sent to each of the = service ingresses. How else, for example, you can set up several services = originated from different nodes that are disjoint from each other? Also, wh= at is the point in your opinion of the statefull PCE work? Cheers, Igor From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, April 12, 2013 8:08 AM To: Khuzema Pithewan Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Khuzema, Hi! Please see inline.. 1. When Network has more than 2 layer i.e. Packet-OTN-DWDM, the Pack= et (client) layer will be talking to its immediate server layer i.e. OTN, w= hich in turn is talking to DWDM layer. Using MELG, client layer path comput= ation can take care of resource exclusivity of virtual link for immediate s= erver layer i.e. OTN layer. However if there is resource exclusivity at DW= DM layer, this mechanism doesn't work. You need to do loose routing or use = distributed PCE model [VPB] The behavior is the same as what you would do with SRLGs in a multi-l= ayer architecture. There are architectures that allow the SRLGs in the lowe= st layer to be exported all the way up to the highest layer. The expectatio= n is that MELGs would be treated in the same vein. 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. [VPB] I'm not sure why you think there is no point in having a centralized= computation function compute paths concurrently for LSPs with different se= t of end-points. Even your NMS/planning-software can interact with such com= putation engine, retrieve all the paths and then go about initiating the pa= th-setup from the ingress of each LSP. Regards, -Pavan From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Igor Bryskin Sent: Tuesday, March 26, 2013 7:19 PM To: Dieter Beller; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Dieter, You said: >> I guess we are coming back to the essential point: "and how often concur= rent path computation will be >> used." To be honest, this surprises me quite a bit, Let me give you some of many r= easons as to why concurrent path computations are needed and why this is be= tter than computing one path at a time: 1. Computing several diverse paths for the same service in the context= of service recovery. I hope you realize that computing one path at a time = on many configurations produces no or sub-optimal results. I also hope you = realize the problem of selecting two paths with one of them having a link = with common MELG with a link from another path; 2. Computing paths for multiple services to be sufficiently disjoint f= rom each other; 3. Computing paths for multiple services to achieve a global optimizat= ion criteria (e.g. minimal summary total cost); 4. Computing paths for multiple services for the purpose of removing t= he bandwidth fragmentations; 5. Computing paths for multiple services to plan shared mesh protectio= n/restoration schemes 6. Etc. Also think about this: 1. If concurrent path computation was not important, why PCEP includes= the machinery to do that? 2. My understanding of the statefull PCE is that it does pretty much n= othing but concurrent path computations You also said: >> I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the >> TE-DB, MELG routing extensions are not needed because the information ab= out mutual >>exclusive VLs can be kept in the central TE-DB when VLs are configured. How this logic does not apply to other link attributes such as SRLGs? What if path computation is not centralized? Cheers, Igor From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Dieter Beller Sent: Monday, March 25, 2013 5:52 PM To: Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Hi Pavan, On 25.03.2013 07:29, Fatai Zhang wrote: Hi Pavan, I am not sure how much VL (Virtual Link) will be used in the practical depl= oyment and how often concurrent path computation will be used. I guess we are coming back to the essential point: "and how often concurren= t path computation will be used." This means we are trying to figure out under which conditions MELG routing = extensions could be beneficial. IMHO, they would only make sense, if: * a path computation function supports the calculation of k shortest pa= ths concurrently * if there is only a single path computation function instance per doma= in (pce approach) If path computation is done in a distributed fashion the benefit goes away = because the instances calculate paths independently! I suppose that if a pce approach is used, i.e., path computation is central= ized including the TE-DB, MELG routing extensions are not needed because the information about= mutual exclusive VLs can be kept in the central TE-DB when VLs are configured. Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their applicability is broader. Thanks, Dieter Do you think if it makes sense to add a flag (in routing advertisement) to = indicate a link is a VL or not? Best Regards Fatai From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, March 22, 2013 8:57 PM To: Fatai Zhang Cc: Igor Bryskin; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Fatai, Hi! Good to see that you understand the construct now. This is not a corner case. The utility of the construct becomes quite signi= ficant if you have an application that does concurrent path computations on= an abstract topology. Regards, -Pavan _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp -- DIETER BELLER ALCATEL-LUCENT DEUTSCHLAND AG PROJECT MANAGER ASON/GMPLS CONTROL PLANE CORE NETWORKS BUSINESS DIVISION OPTICS BU, SWITCHING R&D Lorenzstrasse 10 70435 Stuttgart, Germany Phone: +49 711 821 43125 Mobil: +49 175 7266874 Dieter.Beller@alcatel-lucent.com Alcatel-Lucent Deutschland AG Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026 Chairman of the Supervisory Board: Michael Oppenhoff Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe --_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A19238DF9atlsrvmail10atl_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Khuzema,

 <= /p>

Think about MELG as an SR= LG that is shared between two or more links in its entirety. When two real = links have an SRLG in common, it means that two real links can co-exist concurrently, but there is something (e.g. common conduit, no= te that the conduit has room for more than for one link) that will bring bo= th these links down, if this something fails (e.g. conduit is cut ). Now co= nsider that this something must be taken in its entirety by one of the links to become operational . In th= is case SRLG becomes MELG. Note that MELG is only meaningful for virtual li= nks (unlike SRLG that makes sense for either real or virtual link). Why wou= ld you advertise two links that mutually exclude each other rather than advertising only one of them at a = time, unless the two are virtual links and hence both available for the cli= ent layer connections?

 <= /p>

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 1:01 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

Do you mean, if virtual l= ink do not have any specific constraint, for example a link in the path (no= t talking about egress links/interfaces) must be traversed to realize the virtual link, there wont be any MELG for the virtual link?<= o:p>

 <= /p>

Regds

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 9:52 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

MELGs have nothing to do = with bandwidth. MELG is a concrete network resource in a server layer that = two or more Virtual Links in a client layer depend on in a mutually exclusive way. An example of MELG is a WDM layer transponder th= at can terminate either of respective WDM layer tunnels (but not both at th= e same time) for two OTN layer Virtual Links. If you advertise a Virtual Li= nk, say, for Ethernet layer that depends on the connection in OTN layer going through one of the mentioned = OTN links, the Ethernet VL must inherit the MELG similarly like it does SRL= Gs advertised for the OTN links.

 <= /p>

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Friday, April 12, 2013 12:06 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

For multi-layer (more tha= n 2) network, consider all the layers are meshy (that’s when virtual = links are useful anyway), MELGs of virtual link will change as and when BW/wavelength availability changes, because potential paths, a vi= rtual link can take will change. Mapping lower layer MELGs to higher layer = MELGs won’t be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all the risk and paths (a PCE?), which ca= n be utilized for layer specific path computation (as it is doing it anyway= ).

 <= /p>

This kind of architecture= has all the pieces that are required for Inter-PCE communication (across l= ayers), except the protocol that would actually make the 2 PCEs talk.

 <= /p>

You seem to be doing some= thing that you don’t like J

 <= /p>

Regards=

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 8:39 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

I am not a fan of inter-l= ayer path computations (nor I am a fan of inter-PCE computations). In my mi= nd path computation for a service or services in layer X is performed only in layer X, i.e. considers only X layer links (real or v= irtual). As Pavan mentioned SRLGs and MELGs that need to be inherited from = lower layers should be translated into X layer link SRLGs/MELGs and specifi= ed with X layer specific SRLG/MELG IDs.

 <= /p>

Cheers,=

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Friday, April 12, 2013 10:55 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

Ok. This would be useful = if network architecture is based on external PCE or mgmt entity as PCE in c= lient layer, but there is no counterpart in server layer, otherwise one could have inter-PCE communication to achieve diverse path i= n server layer without getting into virtual link and MELG stuff.

 <= /p>

Is that correct?

 <= /p>

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 6:36 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

2.       For cases of concurrent computation (case= #2-5), you are mainly talking about global optimization and diversity among= multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from th= e source end of those LSPs.  So there is no point in doing concurrent = computation at one network element for the services starting from multiple = network elements. At best it looks to me a problem to be solved by network management/planning software.&= nbsp;

Well, when an ingress nod= e is initiating a service, it is doing so on request from some management e= ntity. This management entity can compute paths for many services with some global criteria in mind, and then specify the resulting= paths as explicit EROs in provisioning requests sent to each of the servic= e ingresses. How else, for example,  you can set up several services o= riginated from different nodes that are disjoint from each other? Also, what is the point in your opinion of the s= tatefull PCE work?

 <= /p>

Cheers,=

Igor

 <= /p>

From: Vishnu P= avan Beeram [mailto:vishnupavan@gm= ail.com]
Sent: Friday, April 12, 2013 8:08 AM
To: Khuzema Pithewan
Cc: Igor Bryskin; Dieter Beller; c= camp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Khuzema, Hi!


Please see inline..

 

 

 1.       When Network has more than 2 layer i.e. P= acket-OTN-DWDM, the Packet (client) layer will be talking to its immediate = server layer i.e. OTN, which in turn is talking to DWDM layer. Using MELG, client layer path computation can take care of resource= exclusivity of virtual link for immediate server layer i.e. OTN layer.&nbs= p; However if there is resource exclusivity at DWDM layer, this mechanism d= oesn’t work. You need to do loose routing or use distributed PCE model

 

[VPB] The behavior is the same as what you would do = with SRLGs in a multi-layer architecture. There are architectures that allo= w the SRLGs in the lowest layer to be exported all the way up to the highes= t layer. The expectation is that MELGs would be treated in the same vein. 

2.       For cases of concurrent computation (case= #2-5), you are mainly talking about global optimization and diversity among= multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from th= e source end of those LSPs.  So there is no point in doing concurrent = computation at one network element for the services starting from multiple = network elements. At best it looks to me a problem to be solved by network management/planning software.&= nbsp;

[VPB]  I'm not sure why you think there is no p= oint in having a centralized computation function compute paths concurrentl= y for LSPs with different set of end-points. Even your NMS/planning-softwar= e can interact with such computation engine, retrieve all the paths and then go about initiating the path-setup from th= e ingress of each LSP. 

 

Regards,

-Pavan

 

 

 

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Tuesday, March 26, 2013 7:19 PM
To: Dieter Beller; Vishnu Pavan Beeram


Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Dieter,

 

You said:

>> I guess we are coming back to the essential point: "= and how often concurrent path computation will be >> used."

 

To be honest, this surprises me quite a bit, Let me give you some = of many reasons as to why concurrent path computations are needed and why t= his is better than computing one path at a time:

 

1.      = Computing several diverse paths for the same service in the context of serv= ice recovery. I hope you realize that computing one path at a time on many = configurations produces no or sub-optimal results. I also hope you realize the problem of selecting two paths with one of them  havi= ng a link with common MELG with a link from another path;

2.      = Computing paths for multiple services to be sufficiently disjoint from each= other;

3.      = Computing paths for multiple services to achieve a global optimization crit= eria (e.g. minimal summary total cost);

4.      = Computing paths for multiple services for the purpose of removing the bandw= idth fragmentations;

5.      = Computing paths for multiple services to plan shared mesh protection/restor= ation schemes

6.      = Etc.

 

Also think about this:

1.      = If concurrent path computation was not important, why PCEP includes the mac= hinery to do that?

2.      = My understanding of the statefull PCE is that it does pretty much nothing b= ut concurrent path computations

 

You also said:

>> I suppose that if a pce approach is used, i.e., path computatio= n is centralized including the
>> TE-DB, MELG routing extensions are not needed because the informat= ion about mutual
>>exclusive VLs can be kept in the central TE-DB when VLs are configu= red.

How this logic does not apply to other link attributes such as SRL= Gs?

What if path computation is not centralized?

 

Cheers,

Igor

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Hi Pavan,

On 25.03.2013 07:29, Fat= ai Zhang wrote:

Hi Pavan,

 

I am not sure how much VL (Virtual Link= ) will be used in the practical deployment and how often concurrent path computation will be used.

I guess we are coming back to the essential point: "and how often concurrent path computation will be used."

This means we are trying to figure out under which conditions MELG routing = extensions
could be beneficial.

IMHO, they would only make sense, if:

  • a path computation function supports the calculation of k shortest paths co= ncurrently
  • if there is only a single path computation function instance per domain (pc= e approach)
    If path computation is done in a distributed fashion the benefit goes away = because
    the instances calculate paths independently!

I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the
TE-DB, MELG routing extensions are not needed because the information about= mutual
exclusive VLs can be kept in the central TE-DB when VLs are configured.

Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their
applicability is broader.


Thanks,
Dieter

 

Do you think if it makes sense to add a flag (in= routing advertisement) to indicate a link is a VL or not?

 

 

 

Best Regards

 

Fatai

 

From: Vishnu Pavan Beeram [<= a href=3D"mailto:vishnupavan@gmail.com" target=3D"_blank">mailto:vishnupava= n@gmail.com]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Fatai, Hi!

 

Good to see that you understand the construct now.

 

This is not a corner case. The utility of the construct becomes qu= ite significant if you have an application that does concurrent path comput= ations on an abstract topology.

 

Regards,

-Pavan

 

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org=

https://www.ietf.org/mailman/listinfo/ccamp

 

--

DIETER BELLER

ALCATEL-LUCENT DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 = 711 821 43125
Mobil: +49 175 = 7266874

 

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe

 

--_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A19238DF9atlsrvmail10atl_-- From zali@cisco.com Fri Apr 12 12:19:25 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617E021F8E8F for ; Fri, 12 Apr 2013 12:19:25 -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 3gJsGKU1MytO for ; Fri, 12 Apr 2013 12:19:24 -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 E01CA21F8E79 for ; Fri, 12 Apr 2013 12:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8333; q=dns/txt; s=iport; t=1365794364; x=1367003964; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=1MpSsQyTB247nFB2HvFqT95Ne8KJyPq2cTIoOjtSayc=; b=AhsTK5V153pmX2BMJQQlOiM/qYDJJF9dQEWykxJ0SAn/KvlsuWanEHS1 Lsjp2w7udoBKl+dPJH5r9miIaFpJQlMFj7cLS89LfZLemxboxQY5nUy2j sTjvhW1ArD+PScsOWRc8YMH+HsEXphB8HqOqJFKa8mJ2a/q5HZKGi5H6e g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFACldaFGtJV2c/2dsb2JhbABQgwY2wWOBDBZ0gh8BAQEEAQEBawsMBgEIEQMBAQEBCh0oBgsUCQgCBA4FCAESh2cDDwyzFg2JXYxEgiACJgsHBoJaYQOTNoFpgwSKVIUcgwuCKA X-IronPort-AV: E=Sophos;i="4.87,464,1363132800"; d="scan'208";a="198218155" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 12 Apr 2013 19:19:18 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r3CJJHpp013068 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Apr 2013 19:19:17 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.181]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Fri, 12 Apr 2013 14:19:17 -0500 From: "Zafar Ali (zali)" To: Francesco Fondelli , "BRUNGARD, DEBORAH A" Thread-Topic: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps Thread-Index: AQHOLvS39bpyTqTPkUSHnkgWwL1MfZjB/SCAgAD/8wCAAhH+gIABbhGAgAB4gYCADCJzAA== Date: Fri, 12 Apr 2013 19:19:16 +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.241.204] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 19:19:25 -0000 Hi Deborah/ Francesco: I don't want SNC changes to become a stopper for this draft. I will be ok to take them out.=20 Thanks Regards =8A Zafar -----Original Message----- From: Francesco Fondelli Date: Thursday, April 4, 2013 6:00 PM To: "BRUNGARD, DEBORAH A" Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps >On Thu, Apr 4, 2013 at 4:49 PM, BRUNGARD, DEBORAH A >wrote: >> Hi Francesco, > >Hi Deborah, > >> That was a fast analysis:-) >> >> Suggest you first expand on the requirements that you want to support >>vs. solution. When you detail aspects of SNC/N, SNC/I, and SNC/S, you >>will find that you also need OAM configuration to support (N/I/S >>configuration (e.g. DEG, TTI)) and you will need to configure which >>defects contribute to a "failure". This will all need to be coordinated >>with the LSP OAM configuration. > > SNC sub-type has been introduced only recently in [4] and is a >Zafar Ali's contribution; I think he can expand/elaborate this >topic here on the list or in the next draft version. In my emails >I was referring exclusively to hold off and wtr ([4] is about hold off >and wtr since day zero: July, 2008), sorry if this was not clear. > >> Also on SNC/N, SNC/I, and SNC/S, is this for a segment or e-2-e? The >>draft needs more detail and alignment with GMPLS protection terminology >>and mechanisms. > > I think [4] addresses both e2e and segment (note: I'm talking about >hold off and wtr). > >> After having a better scope of the requirements, we can discuss the >>solution tradeoffs. There are always multiple ways to solve, first we >>need to understand what is needed. > > The requirement is straightforward: in order to set up protection >switching you need hold off and wtr. Either you use default values >for any LSP on a given network (which is what is happening today) or >you signal these values (hoff and wtr) on a per LSP basis. The draft >tries to provide support for the latter. > >> Thanks, >> Deborah > >thank you >Ciao >Fra > >> -----Original Message----- >> From: Francesco Fondelli [mailto:francesco.fondelli@gmail.com] >> Sent: Wednesday, April 03, 2013 12:59 PM >> To: BRUNGARD, DEBORAH A >> Cc: ccamp@ietf.org >> Subject: Re: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps >> >> Hi Deborah, all, >> >>> Having said that, I have no problem rewriting [4] using OAM >>> configuration TLV. It's just weird to me but I can live with it. >> >> sorry, I changed my mind, I cannot use the OAM TLV. The more I read >> about OAM in IETF the more I think protection switching provisioning >> is completely out-of-scope. >> >> I spent some hours looking for the OAM definition within the >> IETF context(s). The most recent and enlightening (to me at least) >> documents I found are [A] and [B]. As far as I understand, [1] is >> perfectly aligned with them. At the same time I cannot find any >> support of your statement: >> >>> Protection switching provisioning has always been treated as a >>> common equipment management functionality [cut]. So it is in scope >>> of OAM configuration. >> >> Maybe I'm just missing something big (?) Can someone shed some light >>on >> this? >> >> thank you >> ciao >> fra >> >> [A] >> http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08 >> >> [B] >> http://tools.ietf.org/html/rfc6291 >> >> On Tue, Apr 2, 2013 at 11:22 AM, Francesco Fondelli >> wrote: >>> On Mon, Apr 1, 2013 at 8:06 PM, BRUNGARD, DEBORAH A >>>wrote: >>>> Hi Francesco, >>> >>> Hi Deborah, >>> >>>> While these may be protection switching parameters, this draft is >>>>about configuration of these parameters. Protection switching >>>>provisioning has always been treated as a common equipment management >>>>functionality - same as performance management and fault management >>>>(refer to G.7710 section 8). So it is in scope of OAM configuration. >>>>CCAMP's OAM configuration work has been focused on PM and FM but it is >>>>generally applicable (hopefully) to any equipment management >>>>configuration. >>> >>> Puzzled. If we follow this reasoning (i.e. common equipment >>>management >>> functionalities =3D> should use OAM framework) then almost any aspect o= f >>> networking can be applicable to OAM and so any operation should exploit >>> the OAM framework draft. >>> >>> For example, G.7710 section 8.6.1 describes the provisioning >>> of cross-connections but this does not imply that we are going to use >>>the >>> OAM framework to establish label binding in the next GMPLS controlled >>> technology, I guess we will continue to use LABEL_REQUEST/LABEL objects >>> (plus any other relevant info). >>> >>>> Lou's comment is that the WG has chosen the approach used in the OAM >>>>framework document for configuration. Instead of updating the >>>>protection object at this time as your draft proposes, the question is >>>>have you considered using the OAM configuration TLV? First, we need to >>>>understand why you have chosen to not use this approach. Then we can >>>>discuss pros and cons. >>> >>> Well, at the beginning we did not take it into consideration >>> because [4] predate [1]. Later we did not take [1] into consideration >>> simply because we thought [4] was out of OAM framework scope. >>> >>> Having said that, I have no problem rewriting [4] using OAM >>> configuration TLV. It's just weird to me but I can live with it. >>> >>>> BR- >>>> Deborah >>> >>> thank you >>> ciao >>> fra >>> >>>> >>>> -----Original Message----- >>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>Behalf Of Francesco Fondelli >>>> Sent: Monday, April 01, 2013 12:20 PM >>>> To: ccamp@ietf.org >>>> Subject: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps >>>> >>>> quoting item 15, from >>>>www.ietf.org/proceedings/86/minutes/minutes-86-ccamp >>>> >>>> Lou Berger: I think you misunderstood my comment from the last >>>>meeting. You >>>> should look at leveraging the OAM configuration work which came after >>>>the >>>> earlier versions of your draft. >>>> Zafar Ali: this is applicable to multiple technologies. >>>> Lou Berger: yes, the OAM configuration framework is also applicable to >>>> multiple technologies. You need a strong reason not to follow the WG >>>>in >>>> this area. Please look at the OAM configuration document >>>> [draft-ietf-ccamp-oam-configuration-fwk] and either follow it or >>>>state why >>>> your work is justified in not following the existing WG solution in >>>>this >>>> area. >>>> >>>> --- >>>> >>>> Hi all, >>>> >>>> the OAM configuration framework [1] is about OAM. Therefore, it is >>>>used in >>>> order to signal OAM functionalities: CC/CV and PM/FM in MPLS-TP [2], >>>>CC/CV >>>> TTI/SAPI/DAPI in SONET/SDH/OTN [3]... while our draft [4] is about >>>>*protection >>>> switching*. HOFF, WTR and SNC sub-type are protection switching >>>>parameters. >>>> >>>> I believe HOFF, WTR and SNC sub-type are outside of the OAM >>>>configuration >>>> framework scope and should be signaled as any other protection >>>>switching >>>> params (i.e. via PROTECTION object). >>>> >>>> I hope this answer Lou question reported above (item 15, IETF 86 >>>>ccamp >>>> minutes). Authors of [4] would like to understand WG's view about >>>>this point >>>> and are soliciting for comments. >>>> >>>> thank you >>>> ciao >>>> FF >>>> >>>> [1] >>>> http://tools.ietf.org/html/draft-ietf-ccamp-oam-configuration-fwk-09 >>>> >>>> [2] >>>> http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-11 >>>> >>>> [3] >>>> http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-05 >>>> >>>> [4] >>>> http://tools.ietf.org/html/draft-takacs-ccamp-revertive-ps-08 >>>> _______________________________________________ >>>> 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 From IHussain@infinera.com Sat Apr 13 12:27:20 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0879C21F8E6E for ; Sat, 13 Apr 2013 12:27:20 -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 mpoMz5xVzNY7 for ; Sat, 13 Apr 2013 12:27:19 -0700 (PDT) Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7D89221F8E6D for ; Sat, 13 Apr 2013 12:27:19 -0700 (PDT) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.02.0342.003; Sat, 13 Apr 2013 12:27:19 -0700 From: Iftekhar Hussain To: "ccamp@ietf.org" Thread-Topic: New Version Notification for draft-hussain-ccamp-super-channel-label-05.txt Thread-Index: AQHOOGowimwsrck+A0muwkrhrIKMy5jUiBCw Date: Sat, 13 Apr 2013 19:27:17 +0000 Message-ID: References: <20130413171315.17755.51392.idtracker@ietfa.amsl.com> In-Reply-To: <20130413171315.17755.51392.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [CCAMP] FW: New Version Notification for draft-hussain-ccamp-super-channel-label-05.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 19:27:20 -0000 SGksDQoNCkp1c3QgRllJLi4uDQoNClJlZ2FyZHMsDQpJZnRla2hhcg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBTYXR1cmRheSwgQXByaWwgMTMsIDIwMTMgMTA6 MTMgQU0NClRvOiBJZnRla2hhciBIdXNzYWluDQpDYzogTWFyY28gU29zYTsgYWJpbmRlci5kaGls bG9uQHVzLmZ1aml0c3UuY29tOyBaaG9uZyBQYW47IGFuZHJldy5nLm1hbGlzQHZlcml6b24uY29t DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1c3NhaW4tY2Nh bXAtc3VwZXItY2hhbm5lbC1sYWJlbC0wNS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwg ZHJhZnQtaHVzc2Fpbi1jY2FtcC1zdXBlci1jaGFubmVsLWxhYmVsLTA1LnR4dA0KaGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBJZnRla2hhciBIdXNzYWluIGFuZCBwb3N0ZWQgdG8g dGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1odXNzYWluLWNjYW1wLXN1 cGVyLWNoYW5uZWwtbGFiZWwNClJldmlzaW9uOgkgMDUNClRpdGxlOgkJIEdlbmVyYWxpemVkIExh YmVsIGZvciBTdXBlci1DaGFubmVsIEFzc2lnbm1lbnQgb24gRmxleGlibGUgR3JpZA0KQ3JlYXRp b24gZGF0ZToJIDIwMTMtMDQtMTMNCkdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVt YmVyIG9mIHBhZ2VzOiAxNg0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1odXNzYWluLWNjYW1wLXN1cGVyLWNoYW5uZWwtbGFiZWwtMDUu dHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaHVzc2Fpbi1jY2FtcC1zdXBlci1jaGFubmVsLWxhYmVsDQpIdG1saXplZDogICAgICAgIGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWh1c3NhaW4tY2NhbXAtc3VwZXItY2hhbm5l bC1sYWJlbC0wNQ0KRGlmZjogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1odXNzYWluLWNjYW1wLXN1cGVyLWNoYW5uZWwtbGFiZWwtMDUNCg0KQWJzdHJh Y3Q6DQogICBUbyBlbmFibGUgc2NhbGluZyBvZiBleGlzdGluZyB0cmFuc3BvcnQgc3lzdGVtcyB0 byB1bHRyYSBoaWdoIGRhdGENCiAgIHJhdGVzIG9mIDEgVGJwcyBhbmQgYmV5b25kLCBuZXh0IGdl bmVyYXRpb24gc3lzdGVtcyBwcm92aWRpbmcgc3VwZXItDQogICBjaGFubmVsIHN3aXRjaGluZyBj YXBhYmlsaXR5IGFyZSBjdXJyZW50bHkgYmVpbmcgZGV2ZWxvcGVkLiBUbyBhbGxvdw0KICAgZWZm aWNpZW50IGFsbG9jYXRpb24gb2Ygb3B0aWNhbCBzcGVjdHJhbCBiYW5kd2lkdGggZm9yIHN1Y2gg aGlnaCBiaXQNCiAgIHJhdGUgc3lzdGVtcywgSW50ZXJuYXRpb25hbCBUZWxlY29tbXVuaWNhdGlv biBVbmlvbg0KICAgVGVsZWNvbW11bmljYXRpb24gU3RhbmRhcmRpemF0aW9uIFNlY3RvciAoSVRV LVQpIGlzIGV4dGVuZGluZyB0aGUNCiAgIEcuNjk0LjEgZ3JpZCBzdGFuZGFyZCAodGVybWVkICJG aXhlZC1HcmlkIikgdG8gaW5jbHVkZSBmbGV4aWJsZSBncmlkDQogICAodGVybWVkICJGbGV4LUdy aWQiKSBzdXBwb3J0IChkcmFmdCByZXZpc2VkIElUVS1UIEcuNjk0LjEsIHJldmlzaW9uDQogICAx LjQsIE9jdCAyMDExKS4gVGhpcyBuZWNlc3NpdGF0ZXMgZGVmaW5pdGlvbiBvZiBuZXcgbGFiZWwg Zm9ybWF0IGZvcg0KICAgdGhlIEZsZXgtR3JpZC4gVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgc3Vw ZXItY2hhbm5lbCBsYWJlbCBhcyBhDQogICBTdXBlci1DaGFubmVsIElkZW50aWZpZXIgYW5kIGFu IGFzc29jaWF0ZWQgbGlzdCBvZiAxMi41IEdIeiBzbGljZXMNCiAgIHJlcHJlc2VudGluZyB0aGUg b3B0aWNhbCBzcGVjdHJ1bSBvZiB0aGUgc3VwZXItY2hhbm5lbC4gVGhlIGxhYmVsDQogICBpbmZv cm1hdGlvbiBjYW4gYmUgZW5jb2RlZCB1c2luZyBhIGZpeGVkIGxlbmd0aCBvciB2YXJpYWJsZSBs ZW5ndGgNCiAgIGZvcm1hdC4gVGhpcyBsYWJlbCBmb3JtYXQgY2FuIGJlIHVzZWQgaW4gR01QTFMg c2lnbmFsaW5nIGFuZCByb3V0aW5nDQogICBwcm90b2NvbCB0byBlc3RhYmxpc2ggc3VwZXItY2hh bm5lbCBiYXNlZCBvcHRpY2FsIGxhYmVsIHN3aXRjaGVkDQogICBwYXRocyAoTFNQcykuDQoNCg0K DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From fred.gruman@us.fujitsu.com Sun Apr 14 09:02:47 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2D121F8AF8 for ; Sun, 14 Apr 2013 09:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 ss2pbgTCanVQ for ; Sun, 14 Apr 2013 09:02:47 -0700 (PDT) Received: from fncnmp03.fnc.fujitsu.com (fncnmp03.fnc.fujitsu.com [168.127.0.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0094521F87C3 for ; Sun, 14 Apr 2013 09:02:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,471,1363150800"; d="scan'208";a="30892447" Received: from rchexhcp1.fnc.net.local ([168.127.134.75]) by fncnmp01.fnc.fujitsu.com with ESMTP/TLS/AES128-SHA; 14 Apr 2013 11:02:46 -0500 Received: from RCHEXMBP1.fnc.net.local ([169.254.2.136]) by RCHEXHCP1.fnc.net.local ([168.127.134.75]) with mapi id 14.02.0309.002; Sun, 14 Apr 2013 11:02:46 -0500 From: "Gruman, Fred" To: Daniele Ceccarelli , "ccamp@ietf.org" Thread-Topic: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt Thread-Index: AQHOMUqcqrw6KEYeXEevrzCZSajLdpjGMs0ggA+4mIA= Date: Sun, 14 Apr 2013 16:02:46 +0000 Message-ID: <5DF87403A81B0C43AF3EB1626511B29263C8528D@RCHEXMBP1.fnc.net.local> References: <4A1562797D64E44993C5CBF38CF1BE480A9BAC@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE480A9BAC@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [168.127.136.253] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19798.000 x-tm-as-result: No--59.185500-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 16:02:47 -0000 Hi Daniele, Thanks for making the update to the TSG examples in Section 5.2 I have a one additional comments regarding TSG: 1) during an OIF conference call, Stephen Shew indicated that ITU may be co= nsidering additional tributary slot granularity in the future (in addition = to 1.25 and 2.5G). There was a concern about handling more complex combina= tions in the future. =20 It was suggested that perhaps instead of enumerating each combination, the = TSG be treated as bit flags where the first bit could indicate 1.25G, secon= d bit indicates 2.5G, third bit and beyond (perhaps into the reserve fields= in the future) could indicate future TSG rates. The encoding could then b= e: 00 - ignored 10 - 1.25G only 01 - 2.5G only 11 - Both 1.25G and 2.5G supported This may make it easier to understand the encoding if additional TSGs are a= dded later. I realize this comment may be coming in late so you might prefer to not mak= e any changes (this is ok with me as the current encodings are technically = correct). Best Regards, Fred -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of D= aniele Ceccarelli Sent: Thursday, April 04, 2013 10:46 AM To: ccamp@ietf.org Subject: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt Dear OTNers, Info model and OSPF drafts have been updated accordingly to the discussion = in Orlando. The OSPF draft also includes some last call comments that had n= ot been addressed in v05 and suggestions received on the list. On the other side the framework draft doesn't need any change, while the si= gnaling will be updated soon. BR Daniele, Sergio, Fatai >-----Original Message----- >From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]=20 >On Behalf Of internet-drafts@ietf.org >Sent: gioved=EC 4 aprile 2013 17.40 >To: i-d-announce@ietf.org >Cc: ccamp@ietf.org >Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt > > >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. > This draft is a work item of the Common Control and=20 >Measurement Plane Working Group of the IETF. > > Title : Traffic Engineering Extensions to=20 >OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709=20 >OTN Networks > Author(s) : Daniele Ceccarelli > Diego Caviglia > Fatai Zhang > Dan Li > Sergio Belotti > Pietro Vittorio Grandi > Rajan Rao > Khuzema Pithewan > John E Drake > Filename : draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt > Pages : 35 > Date : 2013-04-04 > >Abstract: > ITU-T Recommendation G.709 [G.709-2012] has introduced new fixed and > flexible Optical Data Unit (ODU) containers, enabling optimized > support for an increasingly abundant service mix. > > This document describes Open Shortest Path First - Traffic > Engineering (OSPF-TE) routing protocol extensions to support > Generalized MPLS (GMPLS) control of all currently defined ODU > containers, in support of both sub-lambda and lambda level routing > granularity. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-ospf-g709v3 > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-06 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-gmpls-ospf-g709v3-06 > > >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 From kpithewan@infinera.com Sun Apr 14 21:04:46 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE2C21F8FFB for ; Sun, 14 Apr 2013 21:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 L6dwaZaGFqrY for ; Sun, 14 Apr 2013 21:04:38 -0700 (PDT) Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id C2D7021F8DA0 for ; Sun, 14 Apr 2013 21:04:37 -0700 (PDT) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.02.0342.003; Sun, 14 Apr 2013 21:04:36 -0700 From: Khuzema Pithewan To: Igor Bryskin , Vishnu Pavan Beeram Thread-Topic: [CCAMP] MELGs - Q&A Thread-Index: AQHOIGPek8R0zdnmbUizkEjN3z7415ivh4owgAA2TQCAATLDIIAAeV3g///IfQCABM8nkIABeO8AgAELY4CAGhSNwIAAhvCAgAAQMoD//6fVoIAAemEA//+PR9AAEKirAAANdD1g//+2wYD//LZZoA== Date: Mon, 15 Apr 2013 04:04:35 +0000 Message-ID: References: <5150C704.2040007@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.156.128] Content-Type: multipart/alternative; boundary="_000_D8D01B39D6B38C45AA37C06ECC1D65D53FCEE545SVEXDBPROD1infi_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] MELGs - Q&A X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 04:04:46 -0000 --_000_D8D01B39D6B38C45AA37C06ECC1D65D53FCEE545SVEXDBPROD1infi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Igor, I understand the SRLG and MELG behavior you have penned . My concern was little different. With changing resource consumption (becau= se of dynamicity the network has) in the network links, potential paths a s= et of virtual link can take will change and hence its MELG, as it is tied t= o a resource it can take. So unless virtual links paths are nailed down, it= would be hard to compute MELGs in distributed way. Another point is, virtual links can be viewed as oversubscription of resour= ces (in MELG context). Taking an example (for OTN, I know it would work dif= ferently for a Wavelength in WDM), a link resources are worth 1 TB of BW, u= ser has provisioned 20 virtual links of 100G each going via that OTN link. = Physically, only 10 will get committed. But which 10? It will really depen= d on network dynamics at the time of demand to commit. MELGs are not that e= ffective here. You need some different mechanism. Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 11:55 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Think about MELG as an SRLG that is shared between two or more links in its= entirety. When two real links have an SRLG in common, it means that two re= al links can co-exist concurrently, but there is something (e.g. common con= duit, note that the conduit has room for more than for one link) that will = bring both these links down, if this something fails (e.g. conduit is cut )= . Now consider that this something must be taken in its entirety by one of = the links to become operational . In this case SRLG becomes MELG. Note that= MELG is only meaningful for virtual links (unlike SRLG that makes sense fo= r either real or virtual link). Why would you advertise two links that mutu= ally exclude each other rather than advertising only one of them at a time,= unless the two are virtual links and hence both available for the client l= ayer connections? Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 1:01 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Do you mean, if virtual link do not have any specific constraint, for examp= le a link in the path (not talking about egress links/interfaces) must be t= raversed to realize the virtual link, there wont be any MELG for the virtua= l link? Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 9:52 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, MELGs have nothing to do with bandwidth. MELG is a concrete network resourc= e in a server layer that two or more Virtual Links in a client layer depend= on in a mutually exclusive way. An example of MELG is a WDM layer transpon= der that can terminate either of respective WDM layer tunnels (but not both= at the same time) for two OTN layer Virtual Links. If you advertise a Virt= ual Link, say, for Ethernet layer that depends on the connection in OTN lay= er going through one of the mentioned OTN links, the Ethernet VL must inher= it the MELG similarly like it does SRLGs advertised for the OTN links. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 12:06 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, For multi-layer (more than 2) network, consider all the layers are meshy (t= hat's when virtual links are useful anyway), MELGs of virtual link will cha= nge as and when BW/wavelength availability changes, because potential paths= , a virtual link can take will change. Mapping lower layer MELGs to higher = layer MELGs won't be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all= the risk and paths (a PCE?), which can be utilized for layer specific path= computation (as it is doing it anyway). This kind of architecture has all the pieces that are required for Inter-PC= E communication (across layers), except the protocol that would actually ma= ke the 2 PCEs talk. You seem to be doing something that you don't like :) Regards Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 8:39 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, I am not a fan of inter-layer path computations (nor I am a fan of inter-PC= E computations). In my mind path computation for a service or services in l= ayer X is performed only in layer X, i.e. considers only X layer links (rea= l or virtual). As Pavan mentioned SRLGs and MELGs that need to be inherited= from lower layers should be translated into X layer link SRLGs/MELGs and s= pecified with X layer specific SRLG/MELG IDs. Cheers, Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 10:55 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Ok. This would be useful if network architecture is based on external PCE o= r mgmt entity as PCE in client layer, but there is no counterpart in server= layer, otherwise one could have inter-PCE communication to achieve diverse= path in server layer without getting into virtual link and MELG stuff. Is that correct? Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 6:36 PM To: Vishnu Pavan Beeram; Khuzema Pithewan Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. Well, when an ingress node is initiating a service, it is doing so on reque= st from some management entity. This management entity can compute paths fo= r many services with some global criteria in mind, and then specify the res= ulting paths as explicit EROs in provisioning requests sent to each of the = service ingresses. How else, for example, you can set up several services = originated from different nodes that are disjoint from each other? Also, wh= at is the point in your opinion of the statefull PCE work? Cheers, Igor From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, April 12, 2013 8:08 AM To: Khuzema Pithewan Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Khuzema, Hi! Please see inline.. 1. When Network has more than 2 layer i.e. Packet-OTN-DWDM, the Pack= et (client) layer will be talking to its immediate server layer i.e. OTN, w= hich in turn is talking to DWDM layer. Using MELG, client layer path comput= ation can take care of resource exclusivity of virtual link for immediate s= erver layer i.e. OTN layer. However if there is resource exclusivity at DW= DM layer, this mechanism doesn't work. You need to do loose routing or use = distributed PCE model [VPB] The behavior is the same as what you would do with SRLGs in a multi-l= ayer architecture. There are architectures that allow the SRLGs in the lowe= st layer to be exported all the way up to the highest layer. The expectatio= n is that MELGs would be treated in the same vein. 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. [VPB] I'm not sure why you think there is no point in having a centralized= computation function compute paths concurrently for LSPs with different se= t of end-points. Even your NMS/planning-software can interact with such com= putation engine, retrieve all the paths and then go about initiating the pa= th-setup from the ingress of each LSP. Regards, -Pavan From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Igor Bryskin Sent: Tuesday, March 26, 2013 7:19 PM To: Dieter Beller; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Dieter, You said: >> I guess we are coming back to the essential point: "and how often concur= rent path computation will be >> used." To be honest, this surprises me quite a bit, Let me give you some of many r= easons as to why concurrent path computations are needed and why this is be= tter than computing one path at a time: 1. Computing several diverse paths for the same service in the context= of service recovery. I hope you realize that computing one path at a time = on many configurations produces no or sub-optimal results. I also hope you = realize the problem of selecting two paths with one of them having a link = with common MELG with a link from another path; 2. Computing paths for multiple services to be sufficiently disjoint f= rom each other; 3. Computing paths for multiple services to achieve a global optimizat= ion criteria (e.g. minimal summary total cost); 4. Computing paths for multiple services for the purpose of removing t= he bandwidth fragmentations; 5. Computing paths for multiple services to plan shared mesh protectio= n/restoration schemes 6. Etc. Also think about this: 1. If concurrent path computation was not important, why PCEP includes= the machinery to do that? 2. My understanding of the statefull PCE is that it does pretty much n= othing but concurrent path computations You also said: >> I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the >> TE-DB, MELG routing extensions are not needed because the information ab= out mutual >>exclusive VLs can be kept in the central TE-DB when VLs are configured. How this logic does not apply to other link attributes such as SRLGs? What if path computation is not centralized? Cheers, Igor From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Dieter Beller Sent: Monday, March 25, 2013 5:52 PM To: Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Hi Pavan, On 25.03.2013 07:29, Fatai Zhang wrote: Hi Pavan, I am not sure how much VL (Virtual Link) will be used in the practical depl= oyment and how often concurrent path computation will be used. I guess we are coming back to the essential point: "and how often concurren= t path computation will be used." This means we are trying to figure out under which conditions MELG routing = extensions could be beneficial. IMHO, they would only make sense, if: * a path computation function supports the calculation of k shortest pa= ths concurrently * if there is only a single path computation function instance per doma= in (pce approach) If path computation is done in a distributed fashion the benefit goes away = because the instances calculate paths independently! I suppose that if a pce approach is used, i.e., path computation is central= ized including the TE-DB, MELG routing extensions are not needed because the information about= mutual exclusive VLs can be kept in the central TE-DB when VLs are configured. Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their applicability is broader. Thanks, Dieter Do you think if it makes sense to add a flag (in routing advertisement) to = indicate a link is a VL or not? Best Regards Fatai From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, March 22, 2013 8:57 PM To: Fatai Zhang Cc: Igor Bryskin; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Fatai, Hi! Good to see that you understand the construct now. This is not a corner case. The utility of the construct becomes quite signi= ficant if you have an application that does concurrent path computations on= an abstract topology. Regards, -Pavan _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp -- DIETER BELLER ALCATEL-LUCENT DEUTSCHLAND AG PROJECT MANAGER ASON/GMPLS CONTROL PLANE CORE NETWORKS BUSINESS DIVISION OPTICS BU, SWITCHING R&D Lorenzstrasse 10 70435 Stuttgart, Germany Phone: +49 711 821 43125 Mobil: +49 175 7266874 Dieter.Beller@alcatel-lucent.com Alcatel-Lucent Deutschland AG Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026 Chairman of the Supervisory Board: Michael Oppenhoff Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe --_000_D8D01B39D6B38C45AA37C06ECC1D65D53FCEE545SVEXDBPROD1infi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Igor,

 <= /p>

I understand the SRLG and= MELG behavior you have penned .

 <= /p>

My concern was little dif= ferent.  With changing resource consumption (because of dynamicity the= network has) in the network links, potential paths a set of virtual link can take will change and hence its MELG, as it is tied to a r= esource it can take. So unless virtual links paths are nailed down, it woul= d be hard to compute MELGs in distributed way.

 <= /p>

Another point is, virtual= links can be viewed as oversubscription of resources (in MELG context). Ta= king an example (for OTN, I know it would work differently for a Wavelength in WDM), a link resources are worth 1 TB of BW, user has = provisioned 20 virtual links of 100G each going via that OTN link.  Ph= ysically, only 10 will get committed. But which 10? It will really depend o= n network dynamics at the time of demand to commit. MELGs are not that effective here. You need some different mech= anism.

 <= /p>

Regds

Khuzema=

 <= /p>

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 11:55 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

Think about MELG as an SR= LG that is shared between two or more links in its entirety. When two real = links have an SRLG in common, it means that two real links can co-exist concurrently, but there is something (e.g. common conduit, no= te that the conduit has room for more than for one link) that will bring bo= th these links down, if this something fails (e.g. conduit is cut ). Now co= nsider that this something must be taken in its entirety by one of the links to become operational . In th= is case SRLG becomes MELG. Note that MELG is only meaningful for virtual li= nks (unlike SRLG that makes sense for either real or virtual link). Why wou= ld you advertise two links that mutually exclude each other rather than advertising only one of them at a = time, unless the two are virtual links and hence both available for the cli= ent layer connections?

 <= /p>

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 1:01 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

Do you mean, if virtual l= ink do not have any specific constraint, for example a link in the path (no= t talking about egress links/interfaces) must be traversed to realize the virtual link, there wont be any MELG for the virtual link?<= o:p>

 <= /p>

Regds

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 9:52 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

MELGs have nothing to do = with bandwidth. MELG is a concrete network resource in a server layer that = two or more Virtual Links in a client layer depend on in a mutually exclusive way. An example of MELG is a WDM layer transponder th= at can terminate either of respective WDM layer tunnels (but not both at th= e same time) for two OTN layer Virtual Links. If you advertise a Virtual Li= nk, say, for Ethernet layer that depends on the connection in OTN layer going through one of the mentioned = OTN links, the Ethernet VL must inherit the MELG similarly like it does SRL= Gs advertised for the OTN links.

 <= /p>

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Friday, April 12, 2013 12:06 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

For multi-layer (more tha= n 2) network, consider all the layers are meshy (that’s when virtual = links are useful anyway), MELGs of virtual link will change as and when BW/wavelength availability changes, because potential paths, a vi= rtual link can take will change. Mapping lower layer MELGs to higher layer = MELGs won’t be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all the risk and paths (a PCE?), which ca= n be utilized for layer specific path computation (as it is doing it anyway= ).

 <= /p>

This kind of architecture= has all the pieces that are required for Inter-PCE communication (across l= ayers), except the protocol that would actually make the 2 PCEs talk.

 <= /p>

You seem to be doing some= thing that you don’t like J

 <= /p>

Regards=

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 8:39 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

I am not a fan of inter-l= ayer path computations (nor I am a fan of inter-PCE computations). In my mi= nd path computation for a service or services in layer X is performed only in layer X, i.e. considers only X layer links (real or v= irtual). As Pavan mentioned SRLGs and MELGs that need to be inherited from = lower layers should be translated into X layer link SRLGs/MELGs and specifi= ed with X layer specific SRLG/MELG IDs.

 <= /p>

Cheers,=

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Friday, April 12, 2013 10:55 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

Ok. This would be useful = if network architecture is based on external PCE or mgmt entity as PCE in c= lient layer, but there is no counterpart in server layer, otherwise one could have inter-PCE communication to achieve diverse path i= n server layer without getting into virtual link and MELG stuff.

 <= /p>

Is that correct?

 <= /p>

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 6:36 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

2.       For cases of concurrent computation (case= #2-5), you are mainly talking about global optimization and diversity among= multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from th= e source end of those LSPs.  So there is no point in doing concurrent = computation at one network element for the services starting from multiple = network elements. At best it looks to me a problem to be solved by network management/planning software.&= nbsp;

Well, when an ingress nod= e is initiating a service, it is doing so on request from some management e= ntity. This management entity can compute paths for many services with some global criteria in mind, and then specify the resulting= paths as explicit EROs in provisioning requests sent to each of the servic= e ingresses. How else, for example,  you can set up several services o= riginated from different nodes that are disjoint from each other? Also, what is the point in your opinion of the s= tatefull PCE work?

 <= /p>

Cheers,=

Igor

 <= /p>

From: Vishnu P= avan Beeram [mailto:vishnupavan@gm= ail.com]
Sent: Friday, April 12, 2013 8:08 AM
To: Khuzema Pithewan
Cc: Igor Bryskin; Dieter Beller; c= camp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Khuzema, Hi!


Please see inline..

 

 

 1.       When Network has more than 2 layer i.e. P= acket-OTN-DWDM, the Packet (client) layer will be talking to its immediate = server layer i.e. OTN, which in turn is talking to DWDM layer. Using MELG, client layer path computation can take care of resource= exclusivity of virtual link for immediate server layer i.e. OTN layer.&nbs= p; However if there is resource exclusivity at DWDM layer, this mechanism d= oesn’t work. You need to do loose routing or use distributed PCE model

 

[VPB] The behavior is the same as what you would do = with SRLGs in a multi-layer architecture. There are architectures that allo= w the SRLGs in the lowest layer to be exported all the way up to the highes= t layer. The expectation is that MELGs would be treated in the same vein. 

2.       For cases of concurrent computation (case= #2-5), you are mainly talking about global optimization and diversity among= multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from th= e source end of those LSPs.  So there is no point in doing concurrent = computation at one network element for the services starting from multiple = network elements. At best it looks to me a problem to be solved by network management/planning software.&= nbsp;

[VPB]  I'm not sure why you think there is no p= oint in having a centralized computation function compute paths concurrentl= y for LSPs with different set of end-points. Even your NMS/planning-softwar= e can interact with such computation engine, retrieve all the paths and then go about initiating the path-setup from th= e ingress of each LSP. 

 

Regards,

-Pavan

 

 

 

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Tuesday, March 26, 2013 7:19 PM
To: Dieter Beller; Vishnu Pavan Beeram


Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Dieter,

 

You said:

>> I guess we are coming back to the essential point: "= and how often concurrent path computation will be >> used."

 

To be honest, this surprises me quite a bit, Let me give you some = of many reasons as to why concurrent path computations are needed and why t= his is better than computing one path at a time:

 

1.      = Computing several diverse paths for the same service in the context of serv= ice recovery. I hope you realize that computing one path at a time on many = configurations produces no or sub-optimal results. I also hope you realize the problem of selecting two paths with one of them  havi= ng a link with common MELG with a link from another path;

2.      = Computing paths for multiple services to be sufficiently disjoint from each= other;

3.      = Computing paths for multiple services to achieve a global optimization crit= eria (e.g. minimal summary total cost);

4.      = Computing paths for multiple services for the purpose of removing the bandw= idth fragmentations;

5.      = Computing paths for multiple services to plan shared mesh protection/restor= ation schemes

6.      = Etc.

 

Also think about this:

1.      = If concurrent path computation was not important, why PCEP includes the mac= hinery to do that?

2.      = My understanding of the statefull PCE is that it does pretty much nothing b= ut concurrent path computations

 

You also said:

>> I suppose that if a pce approach is used, i.e., path computatio= n is centralized including the
>> TE-DB, MELG routing extensions are not needed because the informat= ion about mutual
>>exclusive VLs can be kept in the central TE-DB when VLs are configu= red.

How this logic does not apply to other link attributes such as SRL= Gs?

What if path computation is not centralized?

 

Cheers,

Igor

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Hi Pavan,

On 25.03.2013 07:29, Fat= ai Zhang wrote:

Hi Pavan,

 

I am not sure how much VL (Virtual Link= ) will be used in the practical deployment and how often concurrent path computation will be used.

I guess we are coming back to the essential point: "and how often concurrent path computation will be used."

This means we are trying to figure out under which conditions MELG routing = extensions
could be beneficial.

IMHO, they would only make sense, if:

  • a path computation function supports the calculation of k shortest paths co= ncurrently
  • if there is only a single path computation function instance per domain (pc= e approach)
    If path computation is done in a distributed fashion the benefit goes away = because
    the instances calculate paths independently!

I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the
TE-DB, MELG routing extensions are not needed because the information about= mutual
exclusive VLs can be kept in the central TE-DB when VLs are configured.

Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their
applicability is broader.


Thanks,
Dieter

 

Do you think if it makes sense to add a flag (in= routing advertisement) to indicate a link is a VL or not?

 

 

 

Best Regards

 

Fatai

 

From: Vishnu Pavan Beeram [<= a href=3D"mailto:vishnupavan@gmail.com" target=3D"_blank">mailto:vishnupava= n@gmail.com]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Fatai, Hi!

 

Good to see that you understand the construct now.

 

This is not a corner case. The utility of the construct becomes qu= ite significant if you have an application that does concurrent path comput= ations on an abstract topology.

 

Regards,

-Pavan

 

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org=

https://www.ietf.org/mailman/listinfo/ccamp

 

--

DIETER BELLER

ALCATEL-LUCENT DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 = 711 821 43125
Mobil: +49 175 = 7266874

 

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe

 

--_000_D8D01B39D6B38C45AA37C06ECC1D65D53FCEE545SVEXDBPROD1infi_-- From IBryskin@advaoptical.com Mon Apr 15 09:14:42 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1692021F9060 for ; Mon, 15 Apr 2013 09:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001] 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 1zeTzh4ZEupq for ; Mon, 15 Apr 2013 09:14:33 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id CA13721F8F70 for ; Mon, 15 Apr 2013 09:14:32 -0700 (PDT) Received: from MUC-SRV-MBX2.advaoptical.com ([172.20.1.96]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id r3FGEMxa010995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Apr 2013 18:14:22 +0200 Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MBX2.advaoptical.com (172.20.1.96) with Microsoft SMTP Server (TLS) id 15.0.620.29; Mon, 15 Apr 2013 18:14:22 +0200 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0123.003; Mon, 15 Apr 2013 12:14:19 -0400 From: Igor Bryskin To: Khuzema Pithewan , Vishnu Pavan Beeram Thread-Topic: [CCAMP] MELGs - Q&A Thread-Index: AQHOIGPeoOQf0fNS1kG7ulofq5GmQJivzRoAgABxTHCAAPkpgIAAeAqAgABMBQCABErLAIABAdYAgAC6NQCAGt0OAIAAD52A///KWjCAAGRRgP//wCBQgABTlAD//73CwAAKM0gAAAY9GCAAdYY0gAAQgVwA Date: Mon, 15 Apr 2013 16:14:19 +0000 Message-ID: References: <5150C704.2040007@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.1.111] Content-Type: multipart/alternative; boundary="_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A192390ACatlsrvmail10atl_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-04-15_05:2013-04-15, 2013-04-15, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] MELGs - Q&A X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 16:14:42 -0000 --_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A192390ACatlsrvmail10atl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Khuzema, Please, see in-line. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Monday, April 15, 2013 12:05 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, I understand the SRLG and MELG behavior you have penned . My concern was little different. With changing resource consumption (becau= se of dynamicity the network has) in the network links, potential paths a s= et of virtual link can take will change and hence its MELG, as it is tied t= o a resource it can take. So unless virtual links paths are nailed down, it= would be hard to compute MELGs in distributed way. IB>> I think you are missing the point here. Virtual Link server layer path= s are pinned as far as fate sharing is concerned (that is, they are pinned = on server layer link level). It would make little sense to advertise VL SR= LGs if the SRLGs constantly change. The same is true for MELGs. SRLGs/MELG= s advertised for VLs normally do not change: neither over time nor when VLs= become committed/uncommitted. Another point is, virtual links can be viewed as oversubscription of resour= ces (in MELG context). Taking an example (for OTN, I know it would work dif= ferently for a Wavelength in WDM), a link resources are worth 1 TB of BW, u= ser has provisioned 20 virtual links of 100G each going via that OTN link. = Physically, only 10 will get committed. But which 10? It will really depen= d on network dynamics at the time of demand to commit. MELGs are not that e= ffective here. You need some different mechanism. IB>> As I mentioned before MELGs have nothing to do with bandwidth and were= never intended to solve the problems such as you describe (just like it wo= uld not make much sense to solve such problem with SRLGs :=3D) Again, MELG is an extreme case SRLG designed exclusively for VLs (no more = and no less). Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 11:55 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Think about MELG as an SRLG that is shared between two or more links in its= entirety. When two real links have an SRLG in common, it means that two re= al links can co-exist concurrently, but there is something (e.g. common con= duit, note that the conduit has room for more than for one link) that will = bring both these links down, if this something fails (e.g. conduit is cut )= . Now consider that this something must be taken in its entirety by one of = the links to become operational . In this case SRLG becomes MELG. Note that= MELG is only meaningful for virtual links (unlike SRLG that makes sense fo= r either real or virtual link). Why would you advertise two links that mutu= ally exclude each other rather than advertising only one of them at a time,= unless the two are virtual links and hence both available for the client l= ayer connections? Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 1:01 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Do you mean, if virtual link do not have any specific constraint, for examp= le a link in the path (not talking about egress links/interfaces) must be t= raversed to realize the virtual link, there wont be any MELG for the virtua= l link? Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 9:52 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, MELGs have nothing to do with bandwidth. MELG is a concrete network resourc= e in a server layer that two or more Virtual Links in a client layer depend= on in a mutually exclusive way. An example of MELG is a WDM layer transpon= der that can terminate either of respective WDM layer tunnels (but not both= at the same time) for two OTN layer Virtual Links. If you advertise a Virt= ual Link, say, for Ethernet layer that depends on the connection in OTN lay= er going through one of the mentioned OTN links, the Ethernet VL must inher= it the MELG similarly like it does SRLGs advertised for the OTN links. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 12:06 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, For multi-layer (more than 2) network, consider all the layers are meshy (t= hat's when virtual links are useful anyway), MELGs of virtual link will cha= nge as and when BW/wavelength availability changes, because potential paths= , a virtual link can take will change. Mapping lower layer MELGs to higher = layer MELGs won't be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all= the risk and paths (a PCE?), which can be utilized for layer specific path= computation (as it is doing it anyway). This kind of architecture has all the pieces that are required for Inter-PC= E communication (across layers), except the protocol that would actually ma= ke the 2 PCEs talk. You seem to be doing something that you don't like :) Regards Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 8:39 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, I am not a fan of inter-layer path computations (nor I am a fan of inter-PC= E computations). In my mind path computation for a service or services in l= ayer X is performed only in layer X, i.e. considers only X layer links (rea= l or virtual). As Pavan mentioned SRLGs and MELGs that need to be inherited= from lower layers should be translated into X layer link SRLGs/MELGs and s= pecified with X layer specific SRLG/MELG IDs. Cheers, Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 10:55 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Ok. This would be useful if network architecture is based on external PCE o= r mgmt entity as PCE in client layer, but there is no counterpart in server= layer, otherwise one could have inter-PCE communication to achieve diverse= path in server layer without getting into virtual link and MELG stuff. Is that correct? Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 6:36 PM To: Vishnu Pavan Beeram; Khuzema Pithewan Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. Well, when an ingress node is initiating a service, it is doing so on reque= st from some management entity. This management entity can compute paths fo= r many services with some global criteria in mind, and then specify the res= ulting paths as explicit EROs in provisioning requests sent to each of the = service ingresses. How else, for example, you can set up several services = originated from different nodes that are disjoint from each other? Also, wh= at is the point in your opinion of the statefull PCE work? Cheers, Igor From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, April 12, 2013 8:08 AM To: Khuzema Pithewan Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Khuzema, Hi! Please see inline.. 1. When Network has more than 2 layer i.e. Packet-OTN-DWDM, the Pack= et (client) layer will be talking to its immediate server layer i.e. OTN, w= hich in turn is talking to DWDM layer. Using MELG, client layer path comput= ation can take care of resource exclusivity of virtual link for immediate s= erver layer i.e. OTN layer. However if there is resource exclusivity at DW= DM layer, this mechanism doesn't work. You need to do loose routing or use = distributed PCE model [VPB] The behavior is the same as what you would do with SRLGs in a multi-l= ayer architecture. There are architectures that allow the SRLGs in the lowe= st layer to be exported all the way up to the highest layer. The expectatio= n is that MELGs would be treated in the same vein. 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. [VPB] I'm not sure why you think there is no point in having a centralized= computation function compute paths concurrently for LSPs with different se= t of end-points. Even your NMS/planning-software can interact with such com= putation engine, retrieve all the paths and then go about initiating the pa= th-setup from the ingress of each LSP. Regards, -Pavan From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Igor Bryskin Sent: Tuesday, March 26, 2013 7:19 PM To: Dieter Beller; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Dieter, You said: >> I guess we are coming back to the essential point: "and how often concur= rent path computation will be >> used." To be honest, this surprises me quite a bit, Let me give you some of many r= easons as to why concurrent path computations are needed and why this is be= tter than computing one path at a time: 1. Computing several diverse paths for the same service in the context= of service recovery. I hope you realize that computing one path at a time = on many configurations produces no or sub-optimal results. I also hope you = realize the problem of selecting two paths with one of them having a link = with common MELG with a link from another path; 2. Computing paths for multiple services to be sufficiently disjoint f= rom each other; 3. Computing paths for multiple services to achieve a global optimizat= ion criteria (e.g. minimal summary total cost); 4. Computing paths for multiple services for the purpose of removing t= he bandwidth fragmentations; 5. Computing paths for multiple services to plan shared mesh protectio= n/restoration schemes 6. Etc. Also think about this: 1. If concurrent path computation was not important, why PCEP includes= the machinery to do that? 2. My understanding of the statefull PCE is that it does pretty much n= othing but concurrent path computations You also said: >> I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the >> TE-DB, MELG routing extensions are not needed because the information ab= out mutual >>exclusive VLs can be kept in the central TE-DB when VLs are configured. How this logic does not apply to other link attributes such as SRLGs? What if path computation is not centralized? Cheers, Igor From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Dieter Beller Sent: Monday, March 25, 2013 5:52 PM To: Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Hi Pavan, On 25.03.2013 07:29, Fatai Zhang wrote: Hi Pavan, I am not sure how much VL (Virtual Link) will be used in the practical depl= oyment and how often concurrent path computation will be used. I guess we are coming back to the essential point: "and how often concurren= t path computation will be used." This means we are trying to figure out under which conditions MELG routing = extensions could be beneficial. IMHO, they would only make sense, if: * a path computation function supports the calculation of k shortest pa= ths concurrently * if there is only a single path computation function instance per doma= in (pce approach) If path computation is done in a distributed fashion the benefit goes away = because the instances calculate paths independently! I suppose that if a pce approach is used, i.e., path computation is central= ized including the TE-DB, MELG routing extensions are not needed because the information about= mutual exclusive VLs can be kept in the central TE-DB when VLs are configured. Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their applicability is broader. Thanks, Dieter Do you think if it makes sense to add a flag (in routing advertisement) to = indicate a link is a VL or not? Best Regards Fatai From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, March 22, 2013 8:57 PM To: Fatai Zhang Cc: Igor Bryskin; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Fatai, Hi! Good to see that you understand the construct now. This is not a corner case. The utility of the construct becomes quite signi= ficant if you have an application that does concurrent path computations on= an abstract topology. Regards, -Pavan _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp -- DIETER BELLER ALCATEL-LUCENT DEUTSCHLAND AG PROJECT MANAGER ASON/GMPLS CONTROL PLANE CORE NETWORKS BUSINESS DIVISION OPTICS BU, SWITCHING R&D Lorenzstrasse 10 70435 Stuttgart, Germany Phone: +49 711 821 43125 Mobil: +49 175 7266874 Dieter.Beller@alcatel-lucent.com Alcatel-Lucent Deutschland AG Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026 Chairman of the Supervisory Board: Michael Oppenhoff Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe --_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A192390ACatlsrvmail10atl_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Khuzema,

Please, see in-line.=

 <= /p>

Igor

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infinera.com]
Sent: Monday, April 15, 2013 12:05 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

I understand the SRLG and= MELG behavior you have penned .

 <= /p>

My concern was little dif= ferent.  With changing resource consumption (because of dynamicity the= network has) in the network links, potential paths a set of virtual link can take will change and hence its MELG, as it is tied to a r= esource it can take. So unless virtual links paths are nailed down, it woul= d be hard to compute MELGs in distributed way.

 <= /p>

IB>> I think you ar= e missing the point here. Virtual Link server layer paths are pinned as far= as fate sharing is concerned (that is, they are pinned on  server layer link level). It would make little sense to advertise VL SRLGs if the= SRLGs constantly change. The same is true for MELGs.  SRLGs/MELGs adv= ertised for VLs normally do not change: neither over time nor when VLs beco= me committed/uncommitted.

 <= /p>

Another point is, virtual= links can be viewed as oversubscription of resources (in MELG context). Ta= king an example (for OTN, I know it would work differently for a Wavelength in WDM), a link resources are worth 1 TB of BW, user has = provisioned 20 virtual links of 100G each going via that OTN link.  Ph= ysically, only 10 will get committed. But which 10? It will really depend o= n network dynamics at the time of demand to commit. MELGs are not that effective here. You need some different mech= anism.

 <= /p>

IB>> As I mentioned= before MELGs have nothing to do with bandwidth and were never intended to = solve the problems such as you describe (just like it would not make much sense to solve such problem with SRLGs :=3D)

Again,  MELG is an e= xtreme case SRLG designed exclusively for VLs (no more and no less).

 <= /p>

Regds

Khuzema=

 <= /p>

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 11:55 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

Think about MELG as an SR= LG that is shared between two or more links in its entirety. When two real = links have an SRLG in common, it means that two real links can co-exist concurrently, but there is something (e.g. common conduit, no= te that the conduit has room for more than for one link) that will bring bo= th these links down, if this something fails (e.g. conduit is cut ). Now co= nsider that this something must be taken in its entirety by one of the links to become operational . In th= is case SRLG becomes MELG. Note that MELG is only meaningful for virtual li= nks (unlike SRLG that makes sense for either real or virtual link). Why wou= ld you advertise two links that mutually exclude each other rather than advertising only one of them at a = time, unless the two are virtual links and hence both available for the cli= ent layer connections?

 <= /p>

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Friday, April 12, 2013 1:01 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

Do you mean, if virtual l= ink do not have any specific constraint, for example a link in the path (no= t talking about egress links/interfaces) must be traversed to realize the virtual link, there wont be any MELG for the virtual link?<= o:p>

 <= /p>

Regds

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 9:52 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

MELGs have nothing to do = with bandwidth. MELG is a concrete network resource in a server layer that = two or more Virtual Links in a client layer depend on in a mutually exclusive way. An example of MELG is a WDM layer transponder th= at can terminate either of respective WDM layer tunnels (but not both at th= e same time) for two OTN layer Virtual Links. If you advertise a Virtual Li= nk, say, for Ethernet layer that depends on the connection in OTN layer going through one of the mentioned = OTN links, the Ethernet VL must inherit the MELG similarly like it does SRL= Gs advertised for the OTN links.

 <= /p>

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Friday, April 12, 2013 12:06 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

For multi-layer (more tha= n 2) network, consider all the layers are meshy (that’s when virtual = links are useful anyway), MELGs of virtual link will change as and when BW/wavelength availability changes, because potential paths, a vi= rtual link can take will change. Mapping lower layer MELGs to higher layer = MELGs won’t be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all the risk and paths (a PCE?), which ca= n be utilized for layer specific path computation (as it is doing it anyway= ).

 <= /p>

This kind of architecture= has all the pieces that are required for Inter-PCE communication (across l= ayers), except the protocol that would actually make the 2 PCEs talk.

 <= /p>

You seem to be doing some= thing that you don’t like J

 <= /p>

Regards=

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 8:39 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

I am not a fan of inter-l= ayer path computations (nor I am a fan of inter-PCE computations). In my mi= nd path computation for a service or services in layer X is performed only in layer X, i.e. considers only X layer links (real or v= irtual). As Pavan mentioned SRLGs and MELGs that need to be inherited from = lower layers should be translated into X layer link SRLGs/MELGs and specifi= ed with X layer specific SRLG/MELG IDs.

 <= /p>

Cheers,=

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Friday, April 12, 2013 10:55 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

Ok. This would be useful = if network architecture is based on external PCE or mgmt entity as PCE in c= lient layer, but there is no counterpart in server layer, otherwise one could have inter-PCE communication to achieve diverse path i= n server layer without getting into virtual link and MELG stuff.

 <= /p>

Is that correct?

 <= /p>

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 6:36 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

2.       For cases of concurrent computation (case= #2-5), you are mainly talking about global optimization and diversity among= multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from th= e source end of those LSPs.  So there is no point in doing concurrent = computation at one network element for the services starting from multiple = network elements. At best it looks to me a problem to be solved by network management/planning software.&= nbsp;

Well, when an ingress nod= e is initiating a service, it is doing so on request from some management e= ntity. This management entity can compute paths for many services with some global criteria in mind, and then specify the resulting= paths as explicit EROs in provisioning requests sent to each of the servic= e ingresses. How else, for example,  you can set up several services o= riginated from different nodes that are disjoint from each other? Also, what is the point in your opinion of the s= tatefull PCE work?

 <= /p>

Cheers,=

Igor

 <= /p>

From: Vishnu P= avan Beeram [mailto:vishnupavan@gm= ail.com]
Sent: Friday, April 12, 2013 8:08 AM
To: Khuzema Pithewan
Cc: Igor Bryskin; Dieter Beller; c= camp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Khuzema, Hi!


Please see inline..

 

 

 1.       When Network has more than 2 layer i.e. P= acket-OTN-DWDM, the Packet (client) layer will be talking to its immediate = server layer i.e. OTN, which in turn is talking to DWDM layer. Using MELG, client layer path computation can take care of resource= exclusivity of virtual link for immediate server layer i.e. OTN layer.&nbs= p; However if there is resource exclusivity at DWDM layer, this mechanism d= oesn’t work. You need to do loose routing or use distributed PCE model

 

[VPB] The behavior is the same as what you would do = with SRLGs in a multi-layer architecture. There are architectures that allo= w the SRLGs in the lowest layer to be exported all the way up to the highes= t layer. The expectation is that MELGs would be treated in the same vein. 

2.       For cases of concurrent computation (case= #2-5), you are mainly talking about global optimization and diversity among= multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from th= e source end of those LSPs.  So there is no point in doing concurrent = computation at one network element for the services starting from multiple = network elements. At best it looks to me a problem to be solved by network management/planning software.&= nbsp;

[VPB]  I'm not sure why you think there is no p= oint in having a centralized computation function compute paths concurrentl= y for LSPs with different set of end-points. Even your NMS/planning-softwar= e can interact with such computation engine, retrieve all the paths and then go about initiating the path-setup from th= e ingress of each LSP. 

 

Regards,

-Pavan

 

 

 

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Tuesday, March 26, 2013 7:19 PM
To: Dieter Beller; Vishnu Pavan Beeram


Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Dieter,

 

You said:

>> I guess we are coming back to the essential point: "= and how often concurrent path computation will be >> used."

 

To be honest, this surprises me quite a bit, Let me give you some = of many reasons as to why concurrent path computations are needed and why t= his is better than computing one path at a time:

 

1.      = Computing several diverse paths for the same service in the context of serv= ice recovery. I hope you realize that computing one path at a time on many = configurations produces no or sub-optimal results. I also hope you realize the problem of selecting two paths with one of them  havi= ng a link with common MELG with a link from another path;

2.      = Computing paths for multiple services to be sufficiently disjoint from each= other;

3.      = Computing paths for multiple services to achieve a global optimization crit= eria (e.g. minimal summary total cost);

4.      = Computing paths for multiple services for the purpose of removing the bandw= idth fragmentations;

5.      = Computing paths for multiple services to plan shared mesh protection/restor= ation schemes

6.      = Etc.

 

Also think about this:

1.      = If concurrent path computation was not important, why PCEP includes the mac= hinery to do that?

2.      = My understanding of the statefull PCE is that it does pretty much nothing b= ut concurrent path computations

 

You also said:

>> I suppose that if a pce approach is used, i.e., path computatio= n is centralized including the
>> TE-DB, MELG routing extensions are not needed because the informat= ion about mutual
>>exclusive VLs can be kept in the central TE-DB when VLs are configu= red.

How this logic does not apply to other link attributes such as SRL= Gs?

What if path computation is not centralized?

 

Cheers,

Igor

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Hi Pavan,

On 25.03.2013 07:29, Fat= ai Zhang wrote:

Hi Pavan,

 

I am not sure how much VL (Virtual Link= ) will be used in the practical deployment and how often concurrent path computation will be used.

I guess we are coming back to the essential point: "and how often concurrent path computation will be used."

This means we are trying to figure out under which conditions MELG routing = extensions
could be beneficial.

IMHO, they would only make sense, if:

  • a path computation function supports the calculation of k shortest paths co= ncurrently
  • if there is only a single path computation function instance per domain (pc= e approach)
    If path computation is done in a distributed fashion the benefit goes away = because
    the instances calculate paths independently!

I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the
TE-DB, MELG routing extensions are not needed because the information about= mutual
exclusive VLs can be kept in the central TE-DB when VLs are configured.

Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their
applicability is broader.


Thanks,
Dieter

 

Do you think if it makes sense to add a flag (in= routing advertisement) to indicate a link is a VL or not?

 

 

 

Best Regards

 

Fatai

 

From: Vishnu Pavan Beeram [<= a href=3D"mailto:vishnupavan@gmail.com" target=3D"_blank">mailto:vishnupava= n@gmail.com]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Fatai, Hi!

 

Good to see that you understand the construct now.

 

This is not a corner case. The utility of the construct becomes qu= ite significant if you have an application that does concurrent path comput= ations on an abstract topology.

 

Regards,

-Pavan

 

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org=

https://www.ietf.org/mailman/listinfo/ccamp

 

--

DIETER BELLER

ALCATEL-LUCENT DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 = 711 821 43125
Mobil: +49 175 = 7266874

 

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe

 

--_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A192390ACatlsrvmail10atl_-- From kpithewan@infinera.com Tue Apr 16 04:08:25 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50EEF21F9682 for ; Tue, 16 Apr 2013 04:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=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 660As-UvRgbl for ; Tue, 16 Apr 2013 04:08:16 -0700 (PDT) Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8626021F8D28 for ; Tue, 16 Apr 2013 04:08:16 -0700 (PDT) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.02.0342.003; Tue, 16 Apr 2013 04:08:16 -0700 From: Khuzema Pithewan To: Igor Bryskin , Vishnu Pavan Beeram Thread-Topic: [CCAMP] MELGs - Q&A Thread-Index: AQHOIGPek8R0zdnmbUizkEjN3z7415ivh4owgAA2TQCAATLDIIAAeV3g///IfQCABM8nkIABeO8AgAELY4CAGhSNwIAAhvCAgAAQMoD//6fVoIAAemEA//+PR9AAEKirAAANdD1g//+2wYD//LZZoIAH3AeA//9AGeA= Date: Tue, 16 Apr 2013 11:08:15 +0000 Message-ID: References: <5150C704.2040007@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: multipart/alternative; boundary="_000_D8D01B39D6B38C45AA37C06ECC1D65D53FCF022ASVEXDBPROD1infi_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] MELGs - Q&A X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 11:08:25 -0000 --_000_D8D01B39D6B38C45AA37C06ECC1D65D53FCF022ASVEXDBPROD1infi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Igor, I am trying to summarize the discussion we had so far. Pls see if my conclu= sion is in sync with the idea of MELG you have MELG is useful when 1. server layer VLs are nailed down for the resources on the server l= ayer links that are shared among multiple VLs. These resources are typicall= y wavelength on a fiber (can it be anything else??). In other words, if 2 V= Ls are pinned to use a particular wavelength on a particular fiber, then th= ese 2 VLs will have MELG for the wavelength. 2. server layer do not have centralized path computation entity which= can be used by client layer to ask for concurrent diverse path computation= within server layer. 3. Client layer has a centralized path computation entity, which woul= d compute paths for client+server layer. 4. The need is to centralized concurrent computation of more than one= client+server layer path that meets some diversity and resource exclusivit= y requirements. Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Monday, April 15, 2013 9:44 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Please, see in-line. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Monday, April 15, 2013 12:05 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, I understand the SRLG and MELG behavior you have penned . My concern was little different. With changing resource consumption (becau= se of dynamicity the network has) in the network links, potential paths a s= et of virtual link can take will change and hence its MELG, as it is tied t= o a resource it can take. So unless virtual links paths are nailed down, it= would be hard to compute MELGs in distributed way. IB>> I think you are missing the point here. Virtual Link server layer path= s are pinned as far as fate sharing is concerned (that is, they are pinned = on server layer link level). It would make little sense to advertise VL SR= LGs if the SRLGs constantly change. The same is true for MELGs. SRLGs/MELG= s advertised for VLs normally do not change: neither over time nor when VLs= become committed/uncommitted. Another point is, virtual links can be viewed as oversubscription of resour= ces (in MELG context). Taking an example (for OTN, I know it would work dif= ferently for a Wavelength in WDM), a link resources are worth 1 TB of BW, u= ser has provisioned 20 virtual links of 100G each going via that OTN link. = Physically, only 10 will get committed. But which 10? It will really depen= d on network dynamics at the time of demand to commit. MELGs are not that e= ffective here. You need some different mechanism. IB>> As I mentioned before MELGs have nothing to do with bandwidth and were= never intended to solve the problems such as you describe (just like it wo= uld not make much sense to solve such problem with SRLGs :=3D) Again, MELG is an extreme case SRLG designed exclusively for VLs (no more = and no less). Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 11:55 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Think about MELG as an SRLG that is shared between two or more links in its= entirety. When two real links have an SRLG in common, it means that two re= al links can co-exist concurrently, but there is something (e.g. common con= duit, note that the conduit has room for more than for one link) that will = bring both these links down, if this something fails (e.g. conduit is cut )= . Now consider that this something must be taken in its entirety by one of = the links to become operational . In this case SRLG becomes MELG. Note that= MELG is only meaningful for virtual links (unlike SRLG that makes sense fo= r either real or virtual link). Why would you advertise two links that mutu= ally exclude each other rather than advertising only one of them at a time,= unless the two are virtual links and hence both available for the client l= ayer connections? Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 1:01 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Do you mean, if virtual link do not have any specific constraint, for examp= le a link in the path (not talking about egress links/interfaces) must be t= raversed to realize the virtual link, there wont be any MELG for the virtua= l link? Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 9:52 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, MELGs have nothing to do with bandwidth. MELG is a concrete network resourc= e in a server layer that two or more Virtual Links in a client layer depend= on in a mutually exclusive way. An example of MELG is a WDM layer transpon= der that can terminate either of respective WDM layer tunnels (but not both= at the same time) for two OTN layer Virtual Links. If you advertise a Virt= ual Link, say, for Ethernet layer that depends on the connection in OTN lay= er going through one of the mentioned OTN links, the Ethernet VL must inher= it the MELG similarly like it does SRLGs advertised for the OTN links. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 12:06 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, For multi-layer (more than 2) network, consider all the layers are meshy (t= hat's when virtual links are useful anyway), MELGs of virtual link will cha= nge as and when BW/wavelength availability changes, because potential paths= , a virtual link can take will change. Mapping lower layer MELGs to higher = layer MELGs won't be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all= the risk and paths (a PCE?), which can be utilized for layer specific path= computation (as it is doing it anyway). This kind of architecture has all the pieces that are required for Inter-PC= E communication (across layers), except the protocol that would actually ma= ke the 2 PCEs talk. You seem to be doing something that you don't like :) Regards Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 8:39 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, I am not a fan of inter-layer path computations (nor I am a fan of inter-PC= E computations). In my mind path computation for a service or services in l= ayer X is performed only in layer X, i.e. considers only X layer links (rea= l or virtual). As Pavan mentioned SRLGs and MELGs that need to be inherited= from lower layers should be translated into X layer link SRLGs/MELGs and s= pecified with X layer specific SRLG/MELG IDs. Cheers, Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 10:55 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Ok. This would be useful if network architecture is based on external PCE o= r mgmt entity as PCE in client layer, but there is no counterpart in server= layer, otherwise one could have inter-PCE communication to achieve diverse= path in server layer without getting into virtual link and MELG stuff. Is that correct? Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 6:36 PM To: Vishnu Pavan Beeram; Khuzema Pithewan Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. Well, when an ingress node is initiating a service, it is doing so on reque= st from some management entity. This management entity can compute paths fo= r many services with some global criteria in mind, and then specify the res= ulting paths as explicit EROs in provisioning requests sent to each of the = service ingresses. How else, for example, you can set up several services = originated from different nodes that are disjoint from each other? Also, wh= at is the point in your opinion of the statefull PCE work? Cheers, Igor From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, April 12, 2013 8:08 AM To: Khuzema Pithewan Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Khuzema, Hi! Please see inline.. 1. When Network has more than 2 layer i.e. Packet-OTN-DWDM, the Pack= et (client) layer will be talking to its immediate server layer i.e. OTN, w= hich in turn is talking to DWDM layer. Using MELG, client layer path comput= ation can take care of resource exclusivity of virtual link for immediate s= erver layer i.e. OTN layer. However if there is resource exclusivity at DW= DM layer, this mechanism doesn't work. You need to do loose routing or use = distributed PCE model [VPB] The behavior is the same as what you would do with SRLGs in a multi-l= ayer architecture. There are architectures that allow the SRLGs in the lowe= st layer to be exported all the way up to the highest layer. The expectatio= n is that MELGs would be treated in the same vein. 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. [VPB] I'm not sure why you think there is no point in having a centralized= computation function compute paths concurrently for LSPs with different se= t of end-points. Even your NMS/planning-software can interact with such com= putation engine, retrieve all the paths and then go about initiating the pa= th-setup from the ingress of each LSP. Regards, -Pavan From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Igor Bryskin Sent: Tuesday, March 26, 2013 7:19 PM To: Dieter Beller; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Dieter, You said: >> I guess we are coming back to the essential point: "and how often concur= rent path computation will be >> used." To be honest, this surprises me quite a bit, Let me give you some of many r= easons as to why concurrent path computations are needed and why this is be= tter than computing one path at a time: 1. Computing several diverse paths for the same service in the context= of service recovery. I hope you realize that computing one path at a time = on many configurations produces no or sub-optimal results. I also hope you = realize the problem of selecting two paths with one of them having a link = with common MELG with a link from another path; 2. Computing paths for multiple services to be sufficiently disjoint f= rom each other; 3. Computing paths for multiple services to achieve a global optimizat= ion criteria (e.g. minimal summary total cost); 4. Computing paths for multiple services for the purpose of removing t= he bandwidth fragmentations; 5. Computing paths for multiple services to plan shared mesh protectio= n/restoration schemes 6. Etc. Also think about this: 1. If concurrent path computation was not important, why PCEP includes= the machinery to do that? 2. My understanding of the statefull PCE is that it does pretty much n= othing but concurrent path computations You also said: >> I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the >> TE-DB, MELG routing extensions are not needed because the information ab= out mutual >>exclusive VLs can be kept in the central TE-DB when VLs are configured. How this logic does not apply to other link attributes such as SRLGs? What if path computation is not centralized? Cheers, Igor From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Dieter Beller Sent: Monday, March 25, 2013 5:52 PM To: Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Hi Pavan, On 25.03.2013 07:29, Fatai Zhang wrote: Hi Pavan, I am not sure how much VL (Virtual Link) will be used in the practical depl= oyment and how often concurrent path computation will be used. I guess we are coming back to the essential point: "and how often concurren= t path computation will be used." This means we are trying to figure out under which conditions MELG routing = extensions could be beneficial. IMHO, they would only make sense, if: * a path computation function supports the calculation of k shortest pa= ths concurrently * if there is only a single path computation function instance per doma= in (pce approach) If path computation is done in a distributed fashion the benefit goes away = because the instances calculate paths independently! I suppose that if a pce approach is used, i.e., path computation is central= ized including the TE-DB, MELG routing extensions are not needed because the information about= mutual exclusive VLs can be kept in the central TE-DB when VLs are configured. Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their applicability is broader. Thanks, Dieter Do you think if it makes sense to add a flag (in routing advertisement) to = indicate a link is a VL or not? Best Regards Fatai From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, March 22, 2013 8:57 PM To: Fatai Zhang Cc: Igor Bryskin; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Fatai, Hi! Good to see that you understand the construct now. This is not a corner case. The utility of the construct becomes quite signi= ficant if you have an application that does concurrent path computations on= an abstract topology. Regards, -Pavan _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp -- DIETER BELLER ALCATEL-LUCENT DEUTSCHLAND AG PROJECT MANAGER ASON/GMPLS CONTROL PLANE CORE NETWORKS BUSINESS DIVISION OPTICS BU, SWITCHING R&D Lorenzstrasse 10 70435 Stuttgart, Germany Phone: +49 711 821 43125 Mobil: +49 175 7266874 Dieter.Beller@alcatel-lucent.com Alcatel-Lucent Deutschland AG Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026 Chairman of the Supervisory Board: Michael Oppenhoff Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe --_000_D8D01B39D6B38C45AA37C06ECC1D65D53FCF022ASVEXDBPROD1infi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Igor,

 <= /p>

I am trying to summarize = the discussion we had so far. Pls see if my conclusion is in sync with the = idea of MELG you have

 <= /p>

MELG is useful when<= /o:p>

1. = ;      server layer VLs = are nailed down for the resources on the server layer links that are shared= among multiple VLs. These resources are typically wavelength on a fiber (can it be anything else??). In other words, if 2 VLs are pinne= d to use a particular wavelength on a particular fiber, then these 2 VLs wi= ll have MELG for the wavelength.

2. = ;      server layer do n= ot have centralized path computation entity which can be used by client lay= er to ask for concurrent diverse path computation within server layer.

3. = ;      Client layer has = a centralized path computation entity, which would compute paths for client= +server layer.

4. = ;      The need is to ce= ntralized concurrent computation of more than one client+server layer p= ath that meets some diversity and resource exclusivity requirements.

 <= /p>

Regds

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptical.com]
Sent: Monday, April 15, 2013 9:44 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

Please, see in-line.=

 <= /p>

Igor

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infinera.com]
Sent: Monday, April 15, 2013 12:05 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

I understand the SRLG and= MELG behavior you have penned .

 <= /p>

My concern was little dif= ferent.  With changing resource consumption (because of dynamicity the= network has) in the network links, potential paths a set of virtual link can take will change and hence its MELG, as it is tied to a r= esource it can take. So unless virtual links paths are nailed down, it woul= d be hard to compute MELGs in distributed way.

 <= /p>

IB>> I think you ar= e missing the point here. Virtual Link server layer paths are pinned as far= as fate sharing is concerned (that is, they are pinned on  server layer link level). It would make little sense to advertise VL SRLGs if the= SRLGs constantly change. The same is true for MELGs.  SRLGs/MELGs adv= ertised for VLs normally do not change: neither over time nor when VLs beco= me committed/uncommitted.

 <= /p>

Another point is, virtual= links can be viewed as oversubscription of resources (in MELG context). Ta= king an example (for OTN, I know it would work differently for a Wavelength in WDM), a link resources are worth 1 TB of BW, user has = provisioned 20 virtual links of 100G each going via that OTN link.  Ph= ysically, only 10 will get committed. But which 10? It will really depend o= n network dynamics at the time of demand to commit. MELGs are not that effective here. You need some different mech= anism.

 <= /p>

IB>> As I mentioned= before MELGs have nothing to do with bandwidth and were never intended to = solve the problems such as you describe (just like it would not make much sense to solve such problem with SRLGs :=3D)

Again,  MELG is an e= xtreme case SRLG designed exclusively for VLs (no more and no less).

 <= /p>

Regds

Khuzema=

 <= /p>

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 11:55 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

Think about MELG as an SR= LG that is shared between two or more links in its entirety. When two real = links have an SRLG in common, it means that two real links can co-exist concurrently, but there is something (e.g. common conduit, no= te that the conduit has room for more than for one link) that will bring bo= th these links down, if this something fails (e.g. conduit is cut ). Now co= nsider that this something must be taken in its entirety by one of the links to become operational . In th= is case SRLG becomes MELG. Note that MELG is only meaningful for virtual li= nks (unlike SRLG that makes sense for either real or virtual link). Why wou= ld you advertise two links that mutually exclude each other rather than advertising only one of them at a = time, unless the two are virtual links and hence both available for the cli= ent layer connections?

 <= /p>

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Friday, April 12, 2013 1:01 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

Do you mean, if virtual l= ink do not have any specific constraint, for example a link in the path (no= t talking about egress links/interfaces) must be traversed to realize the virtual link, there wont be any MELG for the virtual link?<= o:p>

 <= /p>

Regds

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 9:52 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

MELGs have nothing to do = with bandwidth. MELG is a concrete network resource in a server layer that = two or more Virtual Links in a client layer depend on in a mutually exclusive way. An example of MELG is a WDM layer transponder th= at can terminate either of respective WDM layer tunnels (but not both at th= e same time) for two OTN layer Virtual Links. If you advertise a Virtual Li= nk, say, for Ethernet layer that depends on the connection in OTN layer going through one of the mentioned = OTN links, the Ethernet VL must inherit the MELG similarly like it does SRL= Gs advertised for the OTN links.

 <= /p>

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Friday, April 12, 2013 12:06 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

For multi-layer (more tha= n 2) network, consider all the layers are meshy (that’s when virtual = links are useful anyway), MELGs of virtual link will change as and when BW/wavelength availability changes, because potential paths, a vi= rtual link can take will change. Mapping lower layer MELGs to higher layer = MELGs won’t be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all the risk and paths (a PCE?), which ca= n be utilized for layer specific path computation (as it is doing it anyway= ).

 <= /p>

This kind of architecture= has all the pieces that are required for Inter-PCE communication (across l= ayers), except the protocol that would actually make the 2 PCEs talk.

 <= /p>

You seem to be doing some= thing that you don’t like J

 <= /p>

Regards=

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 8:39 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

I am not a fan of inter-l= ayer path computations (nor I am a fan of inter-PCE computations). In my mi= nd path computation for a service or services in layer X is performed only in layer X, i.e. considers only X layer links (real or v= irtual). As Pavan mentioned SRLGs and MELGs that need to be inherited from = lower layers should be translated into X layer link SRLGs/MELGs and specifi= ed with X layer specific SRLG/MELG IDs.

 <= /p>

Cheers,=

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Friday, April 12, 2013 10:55 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

Ok. This would be useful = if network architecture is based on external PCE or mgmt entity as PCE in c= lient layer, but there is no counterpart in server layer, otherwise one could have inter-PCE communication to achieve diverse path i= n server layer without getting into virtual link and MELG stuff.

 <= /p>

Is that correct?

 <= /p>

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 6:36 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

2.       For cases of concurrent computation (case= #2-5), you are mainly talking about global optimization and diversity among= multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from th= e source end of those LSPs.  So there is no point in doing concurrent = computation at one network element for the services starting from multiple = network elements. At best it looks to me a problem to be solved by network management/planning software.&= nbsp;

Well, when an ingress nod= e is initiating a service, it is doing so on request from some management e= ntity. This management entity can compute paths for many services with some global criteria in mind, and then specify the resulting= paths as explicit EROs in provisioning requests sent to each of the servic= e ingresses. How else, for example,  you can set up several services o= riginated from different nodes that are disjoint from each other? Also, what is the point in your opinion of the s= tatefull PCE work?

 <= /p>

Cheers,=

Igor

 <= /p>

From: Vishnu P= avan Beeram [mailto:vishnupavan@gm= ail.com]
Sent: Friday, April 12, 2013 8:08 AM
To: Khuzema Pithewan
Cc: Igor Bryskin; Dieter Beller; c= camp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Khuzema, Hi!


Please see inline..

 

 

 1.       When Network has more than 2 layer i.e. P= acket-OTN-DWDM, the Packet (client) layer will be talking to its immediate = server layer i.e. OTN, which in turn is talking to DWDM layer. Using MELG, client layer path computation can take care of resource= exclusivity of virtual link for immediate server layer i.e. OTN layer.&nbs= p; However if there is resource exclusivity at DWDM layer, this mechanism d= oesn’t work. You need to do loose routing or use distributed PCE model

 

[VPB] The behavior is the same as what you would do = with SRLGs in a multi-layer architecture. There are architectures that allo= w the SRLGs in the lowest layer to be exported all the way up to the highes= t layer. The expectation is that MELGs would be treated in the same vein. 

2.       For cases of concurrent computation (case= #2-5), you are mainly talking about global optimization and diversity among= multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from th= e source end of those LSPs.  So there is no point in doing concurrent = computation at one network element for the services starting from multiple = network elements. At best it looks to me a problem to be solved by network management/planning software.&= nbsp;

[VPB]  I'm not sure why you think there is no p= oint in having a centralized computation function compute paths concurrentl= y for LSPs with different set of end-points. Even your NMS/planning-softwar= e can interact with such computation engine, retrieve all the paths and then go about initiating the path-setup from th= e ingress of each LSP. 

 

Regards,

-Pavan

 

 

 

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Tuesday, March 26, 2013 7:19 PM
To: Dieter Beller; Vishnu Pavan Beeram


Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Dieter,

 

You said:

>> I guess we are coming back to the essential point: "= and how often concurrent path computation will be >> used."

 

To be honest, this surprises me quite a bit, Let me give you some = of many reasons as to why concurrent path computations are needed and why t= his is better than computing one path at a time:

 

1.      = Computing several diverse paths for the same service in the context of serv= ice recovery. I hope you realize that computing one path at a time on many = configurations produces no or sub-optimal results. I also hope you realize the problem of selecting two paths with one of them  havi= ng a link with common MELG with a link from another path;

2.      = Computing paths for multiple services to be sufficiently disjoint from each= other;

3.      = Computing paths for multiple services to achieve a global optimization crit= eria (e.g. minimal summary total cost);

4.      = Computing paths for multiple services for the purpose of removing the bandw= idth fragmentations;

5.      = Computing paths for multiple services to plan shared mesh protection/restor= ation schemes

6.      = Etc.

 

Also think about this:

1.      = If concurrent path computation was not important, why PCEP includes the mac= hinery to do that?

2.      = My understanding of the statefull PCE is that it does pretty much nothing b= ut concurrent path computations

 

You also said:

>> I suppose that if a pce approach is used, i.e., path computatio= n is centralized including the
>> TE-DB, MELG routing extensions are not needed because the informat= ion about mutual
>>exclusive VLs can be kept in the central TE-DB when VLs are configu= red.

How this logic does not apply to other link attributes such as SRL= Gs?

What if path computation is not centralized?

 

Cheers,

Igor

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Hi Pavan,

On 25.03.2013 07:29, Fat= ai Zhang wrote:

Hi Pavan,

 

I am not sure how much VL (Virtual Link= ) will be used in the practical deployment and how often concurrent path computation will be used.

I guess we are coming back to the essential point: "and how often concurrent path computation will be used."

This means we are trying to figure out under which conditions MELG routing = extensions
could be beneficial.

IMHO, they would only make sense, if:

  • a path computation function supports the calculation of k shortest paths co= ncurrently
  • if there is only a single path computation function instance per domain (pc= e approach)
    If path computation is done in a distributed fashion the benefit goes away = because
    the instances calculate paths independently!

I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the
TE-DB, MELG routing extensions are not needed because the information about= mutual
exclusive VLs can be kept in the central TE-DB when VLs are configured.

Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their
applicability is broader.


Thanks,
Dieter

 

Do you think if it makes sense to add a flag (in= routing advertisement) to indicate a link is a VL or not?

 

 

 

Best Regards

 

Fatai

 

From: Vishnu Pavan Beeram [<= a href=3D"mailto:vishnupavan@gmail.com" target=3D"_blank">mailto:vishnupava= n@gmail.com]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Fatai, Hi!

 

Good to see that you understand the construct now.

 

This is not a corner case. The utility of the construct becomes qu= ite significant if you have an application that does concurrent path comput= ations on an abstract topology.

 

Regards,

-Pavan

 

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org=

https://www.ietf.org/mailman/listinfo/ccamp

 

--

DIETER BELLER

ALCATEL-LUCENT DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 = 711 821 43125
Mobil: +49 175 = 7266874

 

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe

 

--_000_D8D01B39D6B38C45AA37C06ECC1D65D53FCF022ASVEXDBPROD1infi_-- From vishnupavan@gmail.com Tue Apr 16 07:10:17 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315B721F96EE for ; Tue, 16 Apr 2013 07:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, NO_RELAYS=-0.001] 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 CxqBZ3mwl8lY for ; Tue, 16 Apr 2013 07:10:14 -0700 (PDT) Received: from mail-bk0-x22b.google.com (mail-bk0-x22b.google.com [IPv6:2a00:1450:4008:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id CF03A21F9552 for ; Tue, 16 Apr 2013 07:10:13 -0700 (PDT) Received: by mail-bk0-f43.google.com with SMTP id jm19so184933bkc.2 for ; Tue, 16 Apr 2013 07:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=cXWgHjsjamBSdoqm9RBMyLFOYE4RykSl84dLzyB7nGk=; b=x5C8qJc3DUxmj11Zgx2ngFgB/RJhHBmasiaQMIlbL+A+eXGU9T6Qo+4IfKUHmeJtOr BOpRu8gzWvNwwlLBBA4MmJV+MvlMY9PuJ5lz4gCyenzz8m6sRzHcWYmLI95GgWiPbi9/ LIl+nIz/voy5Y6nfgB4hNt5SmtHE0yqkuFS88o7SiKG5eB72hg2PZFKNre4R8C5MpvWb fm7LFGO66Wk2aE1FDQuYyxQZa1juGayop+x+WviOILkazeq2kH/5qUtXAi7UlLRWDznb blCWeoFQTKHdzHnJ6rcFckPbUN49SD1qp6dOljXSRoj4Ts0mSpjYDsHace9XS1frTuQ6 z9Fg== MIME-Version: 1.0 X-Received: by 10.204.61.132 with SMTP id t4mr822977bkh.20.1366121412875; Tue, 16 Apr 2013 07:10:12 -0700 (PDT) Received: by 10.205.127.137 with HTTP; Tue, 16 Apr 2013 07:10:12 -0700 (PDT) In-Reply-To: References: <5150C704.2040007@alcatel-lucent.com> Date: Tue, 16 Apr 2013 10:10:12 -0400 Message-ID: From: Vishnu Pavan Beeram To: Khuzema Pithewan Content-Type: multipart/alternative; boundary=001a11c395a689110d04da7aed66 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] MELGs - Q&A X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 14:10:17 -0000 --001a11c395a689110d04da7aed66 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Khuzema, Hi! MELGs are useful and come into play only when: (1) The server network domain is abstracted and the advertised Virtual TE-links possess some mutual exclusivity relationship. (2) There is a Centralized path computation entity in the client domain (computes paths in terms of Client TE-links/TE-nodes) that is capable of doing concurrent path computations. If either of the above 2 statements is NOT true, there is no utility for MELGs. At the risk of being pedantic: - Are MELGs needed when the server-network domain in not abstracted (no Virtual TE links)? The answer is NO. - Are MELGs needed when you have a distributed path-computation architecture (Client PCE interacting with Server PCE)? The answer is NO. - Are MELGs needed when the centralized path-computation engine doesn't (can't) do concurrent computations? The answer is NO. The actual procedures involved in abstracting the server network domain is beyond the scope of . The abstraction procedure itself is implementation-specific (maybe someday someone would put together a draft for discussing this). Though it is true that the primary use-case we had in mind when coming up with this new construct involves a lambda-layer server network domain, there is really no restriction (at a conceptual level) on using this construct when abstracting a packet-layer server network domain or a TDM-layer server network domain. It is up to the implementation on how to make best use of this construct. When you advertise a Virtual TE-link into a client network domain, you are doing this based on the existence of some potential underlying server-path. TE attributes like SRLGs, MELGs, delay etc that get advertised for the Virtual TE-link depend on the underlying server-path that is chosen for catering to this Client TE-link. If the underlying server-path keeps changing (based on network events), these TE attributes would also keep changing. The procedure for keeping the advertised information "current" is an implementation choice. If there exists such a thing as an abstraction manager (again, this is totally implementation specific), then the assumption is that it does one of the following - (a) computes new server-paths for the Virtual TE links whenever there is a change in the network (may not be very scalable in some architectures), (b) or does periodic path-computation for each Virtual TE link, (c) or uses a policy to pin down the Virtual TE-link to a specific underlying server-path, (d) or uses a combination of (a), (b), (c). doesn't make any recommendation as to what choice the abstraction manager would need to take. Hope this helps. -Pavan On Tue, Apr 16, 2013 at 7:08 AM, Khuzema Pithewan w= rote: > Hi Igor,**** > > ** ** > > I am trying to summarize the discussion we had so far. Pls see if my > conclusion is in sync with the idea of MELG you have **** > > ** ** > > MELG is useful when**** > > **1. **server layer VLs are nailed down for the resources on the > server layer links that are shared among multiple VLs. These resources ar= e > typically wavelength on a fiber (can it be anything else??). In other > words, if 2 VLs are pinned to use a particular wavelength on a particular > fiber, then these 2 VLs will have MELG for the wavelength.**** > > **2. **server layer do not have centralized path computation entity > which can be used by client layer to ask for concurrent diverse path > computation within server layer.**** > > **3. **Client layer has a centralized path computation entity, > which would compute paths for client+server layer.**** > > **4. **The need is to centralized concurrent computation of more > than one client+server layer path that meets some diversity and resource > exclusivity requirements.**** > > ** ** > > Regds**** > > Khuzema**** > > ** ** > > *From:* Igor Bryskin [mailto:IBryskin@advaoptical.com] > *Sent:* Monday, April 15, 2013 9:44 PM > > *To:* Khuzema Pithewan; Vishnu Pavan Beeram > *Cc:* Dieter Beller; ccamp@ietf.org > *Subject:* RE: [CCAMP] MELGs - Q&A**** > > ** ** > > Khuzema,**** > > Please, see in-line.**** > > ** ** > > Igor**** > > ** ** > > *From:* Khuzema Pithewan [mailto:kpithewan@infinera.com] > *Sent:* Monday, April 15, 2013 12:05 AM > *To:* Igor Bryskin; Vishnu Pavan Beeram > *Cc:* Dieter Beller; ccamp@ietf.org > *Subject:* RE: [CCAMP] MELGs - Q&A**** > > ** ** > > Hi Igor,**** > > ** ** > > I understand the SRLG and MELG behavior you have penned .**** > > ** ** > > My concern was little different. With changing resource consumption > (because of dynamicity the network has) in the network links, potential > paths a set of virtual link can take will change and hence its MELG, as i= t > is tied to a resource it can take. So unless virtual links paths are nail= ed > down, it would be hard to compute MELGs in distributed way.**** > > ** ** > > IB>> I think you are missing the point here. Virtual Link server layer > paths are pinned as far as fate sharing is concerned (that is, they are > pinned on server layer link level). It would make little sense to > advertise VL SRLGs if the SRLGs constantly change. The same is true for > MELGs. SRLGs/MELGs advertised for VLs normally do not change: neither ov= er > time nor when VLs become committed/uncommitted.**** > > ** ** > > Another point is, virtual links can be viewed as oversubscription of > resources (in MELG context). Taking an example (for OTN, I know it would > work differently for a Wavelength in WDM), a link resources are worth 1 T= B > of BW, user has provisioned 20 virtual links of 100G each going via that > OTN link. Physically, only 10 will get committed. But which 10? It will > really depend on network dynamics at the time of demand to commit. MELGs > are not that effective here. You need some different mechanism.**** > > ** ** > > IB>> As I mentioned before MELGs have nothing to do with bandwidth and > were never intended to solve the problems such as you describe (just like > it would not make much sense to solve such problem with SRLGs :=3D)**** > > Again, MELG is an extreme case SRLG designed exclusively for VLs (no mor= e > and no less).**** > > ** ** > > Regds**** > > Khuzema**** > > ** ** > > ** ** > > *From:* Igor Bryskin [mailto:IBryskin@advaoptical.com] > > *Sent:* Friday, April 12, 2013 11:55 PM > *To:* Khuzema Pithewan; Vishnu Pavan Beeram > *Cc:* Dieter Beller; ccamp@ietf.org > *Subject:* RE: [CCAMP] MELGs - Q&A**** > > ** ** > > Khuzema,**** > > ** ** > > Think about MELG as an SRLG that is shared between two or more links in > its entirety. When two real links have an SRLG in common, it means that t= wo > real links can co-exist concurrently, but there is something (e.g. common > conduit, note that the conduit has room for more than for one link) that > will bring both these links down, if this something fails (e.g. conduit i= s > cut ). Now consider that this something must be taken in its entirety by > one of the links to become operational . In this case SRLG becomes MELG. > Note that MELG is only meaningful for virtual links (unlike SRLG that mak= es > sense for either real or virtual link). Why would you advertise two links > that mutually exclude each other rather than advertising only one of them > at a time, unless the two are virtual links and hence both available for > the client layer connections?**** > > ** ** > > Igor **** > > ** ** > > ** ** > > *From:* Khuzema Pithewan [mailto:kpithewan@infinera.com] > > *Sent:* Friday, April 12, 2013 1:01 PM > *To:* Igor Bryskin; Vishnu Pavan Beeram > *Cc:* Dieter Beller; ccamp@ietf.org > *Subject:* RE: [CCAMP] MELGs - Q&A**** > > ** ** > > Hi Igor,**** > > ** ** > > Do you mean, if virtual link do not have any specific constraint, for > example a link in the path (not talking about egress links/interfaces) mu= st > be traversed to realize the virtual link, there wont be any MELG for the > virtual link?**** > > ** ** > > Regds**** > > Khuzema**** > > ** ** > > *From:* Igor Bryskin [mailto:IBryskin@advaoptical.com] > > *Sent:* Friday, April 12, 2013 9:52 PM > *To:* Khuzema Pithewan; Vishnu Pavan Beeram > *Cc:* Dieter Beller; ccamp@ietf.org > *Subject:* RE: [CCAMP] MELGs - Q&A**** > > ** ** > > Khuzema,**** > > **** > > MELGs have nothing to do with bandwidth. MELG is a concrete network > resource in a server layer that two or more Virtual Links in a client lay= er > depend on in a mutually exclusive way. An example of MELG is a WDM layer > transponder that can terminate either of respective WDM layer tunnels (bu= t > not both at the same time) for two OTN layer Virtual Links. If you > advertise a Virtual Link, say, for Ethernet layer that depends on the > connection in OTN layer going through one of the mentioned OTN links, the > Ethernet VL must inherit the MELG similarly like it does SRLGs advertised > for the OTN links.**** > > **** > > Igor**** > > **** > > **** > > *From:* Khuzema Pithewan [mailto:kpithewan@infinera.com] > > *Sent:* Friday, April 12, 2013 12:06 PM > *To:* Igor Bryskin; Vishnu Pavan Beeram > *Cc:* Dieter Beller; ccamp@ietf.org > *Subject:* RE: [CCAMP] MELGs - Q&A**** > > **** > > Hi Igor,**** > > **** > > For multi-layer (more than 2) network, consider all the layers are meshy > (that=92s when virtual links are useful anyway), MELGs of virtual link wi= ll > change as and when BW/wavelength availability changes, because potential > paths, a virtual link can take will change. Mapping lower layer MELGs to > higher layer MELGs won=92t be practical if done in distributed manner, so= it > has to be centralized. So you do have central element in each layer that > knows all the risk and paths (a PCE?), which can be utilized for layer > specific path computation (as it is doing it anyway). **** > > **** > > This kind of architecture has all the pieces that are required for > Inter-PCE communication (across layers), except the protocol that would > actually make the 2 PCEs talk.**** > > **** > > You seem to be doing something that you don=92t like J**** > > **** > > Regards**** > > Khuzema**** > > **** > > *From:* Igor Bryskin [mailto:IBryskin@advaoptical.com] > > *Sent:* Friday, April 12, 2013 8:39 PM > *To:* Khuzema Pithewan; Vishnu Pavan Beeram > *Cc:* Dieter Beller; ccamp@ietf.org > *Subject:* RE: [CCAMP] MELGs - Q&A**** > > **** > > Khuzema,**** > > **** > > I am not a fan of inter-layer path computations (nor I am a fan of > inter-PCE computations). In my mind path computation for a service or > services in layer X is performed only in layer X, i.e. considers only X > layer links (real or virtual). As Pavan mentioned SRLGs and MELGs that ne= ed > to be inherited from lower layers should be translated into X layer link > SRLGs/MELGs and specified with X layer specific SRLG/MELG IDs.**** > > **** > > Cheers,**** > > Igor**** > > **** > > **** > > *From:* Khuzema Pithewan [mailto:kpithewan@infinera.com] > > *Sent:* Friday, April 12, 2013 10:55 AM > *To:* Igor Bryskin; Vishnu Pavan Beeram > *Cc:* Dieter Beller; ccamp@ietf.org > *Subject:* RE: [CCAMP] MELGs - Q&A**** > > **** > > Hi Igor,**** > > **** > > Ok. This would be useful if network architecture is based on external PCE > or mgmt entity as PCE in client layer, but there is no counterpart in > server layer, otherwise one could have inter-PCE communication to achieve > diverse path in server layer without getting into virtual link and MELG > stuff.**** > > **** > > Is that correct?**** > > **** > > Khuzema**** > > **** > > *From:* Igor Bryskin [mailto:IBryskin@advaoptical.com] > > *Sent:* Friday, April 12, 2013 6:36 PM > *To:* Vishnu Pavan Beeram; Khuzema Pithewan > *Cc:* Dieter Beller; ccamp@ietf.org > *Subject:* RE: [CCAMP] MELGs - Q&A**** > > **** > > Khuzema,**** > > **** > > 2. For cases of concurrent computation (case#2-5), you are mainly > talking about global optimization and diversity among multiple services. > You can do the path computation, but to actually enact the computed path > the signaling needs to be done from the source end of those LSPs. So the= re > is no point in doing concurrent computation at one network element for th= e > services starting from multiple network elements. At best it looks to me = a > problem to be solved by network management/planning software. **** > > Well, when an ingress node is initiating a service, it is doing so on > request from some management entity. This management entity can compute > paths for many services with some global criteria in mind, and then speci= fy > the resulting paths as explicit EROs in provisioning requests sent to eac= h > of the service ingresses. How else, for example, you can set up several > services originated from different nodes that are disjoint from each othe= r? > Also, what is the point in your opinion of the statefull PCE work? **** > > **** > > Cheers,**** > > Igor**** > > **** > > *From:* Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] > > *Sent:* Friday, April 12, 2013 8:08 AM > *To:* Khuzema Pithewan > *Cc:* Igor Bryskin; Dieter Beller; ccamp@ietf.org > *Subject:* Re: [CCAMP] MELGs - Q&A**** > > **** > > Khuzema, Hi!**** > > > Please see inline..**** > > **** > > **** > > 1. When Network has more than 2 layer i.e. Packet-OTN-DWDM, the > Packet (client) layer will be talking to its immediate server layer i.e. > OTN, which in turn is talking to DWDM layer. Using MELG, client layer pat= h > computation can take care of resource exclusivity of virtual link for > immediate server layer i.e. OTN layer. However if there is resource > exclusivity at DWDM layer, this mechanism doesn=92t work. You need to do > loose routing or use distributed PCE model**** > > **** > > [VPB] The behavior is the same as what you would do with SRLGs in a > multi-layer architecture. There are architectures that allow the SRLGs in > the lowest layer to be exported all the way up to the highest layer. The > expectation is that MELGs would be treated in the same vein. **** > > 2. For cases of concurrent computation (case#2-5), you are mainly > talking about global optimization and diversity among multiple services. > You can do the path computation, but to actually enact the computed path > the signaling needs to be done from the source end of those LSPs. So the= re > is no point in doing concurrent computation at one network element for th= e > services starting from multiple network elements. At best it looks to me = a > problem to be solved by network management/planning software. **** > > [VPB] I'm not sure why you think there is no point in having a > centralized computation function compute paths concurrently for LSPs with > different set of end-points. Even your NMS/planning-software can interact > with such computation engine, retrieve all the paths and then go about > initiating the path-setup from the ingress of each LSP. **** > > **** > > Regards,**** > > -Pavan**** > > **** > > **** > > **** > > **** > > *From:* ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] *On Behalf > Of *Igor Bryskin > *Sent:* Tuesday, March 26, 2013 7:19 PM > *To:* Dieter Beller; Vishnu Pavan Beeram**** > > > *Cc:* ccamp@ietf.org > *Subject:* Re: [CCAMP] MELGs - Q&A**** > > **** > > Dieter,**** > > **** > > You said:**** > > >> I guess we are coming back to the essential point: "and how often > concurrent path computation will be >> used."**** > > **** > > To be honest, this surprises me quite a bit, Let me give you some of many > reasons as to why concurrent path computations are needed and why this is > better than computing one path at a time:**** > > **** > > 1. Computing several diverse paths for the same service in the > context of service recovery. I hope you realize that computing one path a= t > a time on many configurations produces no or sub-optimal results. I also > hope you realize the problem of selecting two paths with one of them > having a link with common MELG with a link from another path;**** > > 2. Computing paths for multiple services to be sufficiently disjoint > from each other;**** > > 3. Computing paths for multiple services to achieve a global > optimization criteria (e.g. minimal summary total cost);**** > > 4. Computing paths for multiple services for the purpose of removing > the bandwidth fragmentations;**** > > 5. Computing paths for multiple services to plan shared mesh > protection/restoration schemes**** > > 6. Etc.**** > > **** > > Also think about this:**** > > 1. If concurrent path computation was not important, why PCEP > includes the machinery to do that?**** > > 2. My understanding of the statefull PCE is that it does pretty much > nothing but concurrent path computations**** > > **** > > You also said:**** > > >> I suppose that if a pce approach is used, i.e., path computation is > centralized including the > >> TE-DB, MELG routing extensions are not needed because the information > about mutual > >>exclusive VLs can be kept in the central TE-DB when VLs are configured.= * > *** > > How this logic does not apply to other link attributes such as SRLGs?**** > > What if path computation is not centralized?**** > > **** > > Cheers,**** > > Igor**** > > **** > > *From:* ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] *On Behalf > Of *Dieter Beller > *Sent:* Monday, March 25, 2013 5:52 PM > *To:* Vishnu Pavan Beeram > *Cc:* ccamp@ietf.org > *Subject:* Re: [CCAMP] MELGs - Q&A**** > > **** > > Hi Pavan,**** > > On 25.03.2013 07:29, Fatai Zhang wrote:**** > > Hi Pavan,**** > > **** > > I am not sure how much VL (Virtual Link) will be used in the practical > deployment and how often concurrent path computation will be used.**** > > I guess we are coming back to the essential point: "and how often > concurrent path computation will be used." > > This means we are trying to figure out under which conditions MELG routin= g > extensions > could be beneficial. > > IMHO, they would only make sense, if:**** > > - a path computation function supports the calculation of k shortest > paths concurrently**** > - if there is only a single path computation function instance per > domain (pce approach) > If path computation is done in a distributed fashion the benefit goes > away because > the instances calculate paths independently!**** > > I suppose that if a pce approach is used, i.e., path computation is > centralized including the > TE-DB, MELG routing extensions are not needed because the information > about mutual > exclusive VLs can be kept in the central TE-DB when VLs are configured. > > Hence, it is quite doubtful whether MELG routing extensions are really > useful unless their > applicability is broader. > > > Thanks, > Dieter**** > > **** > > Do you think if it makes sense to add a flag (in routing advertisement) t= o > indicate a link is a VL or not?**** > > **** > > **** > > **** > > Best Regards**** > > **** > > Fatai**** > > **** > > *From:* Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] > > *Sent:* Friday, March 22, 2013 8:57 PM > *To:* Fatai Zhang > *Cc:* Igor Bryskin; ccamp@ietf.org > *Subject:* Re: [CCAMP] MELGs - Q&A**** > > **** > > Fatai, Hi!**** > > **** > > Good to see that you understand the construct now.**** > > **** > > This is not a corner case. The utility of the construct becomes quite > significant if you have an application that does concurrent path > computations on an abstract topology.**** > > **** > > Regards,**** > > -Pavan**** > > **** > > _______________________________________________**** > > CCAMP mailing list**** > > CCAMP@ietf.org**** > > https://www.ietf.org/mailman/listinfo/ccamp**** > > **** > > -- ** ** > > *DIETER BELLER ***** > > ALCATEL-LUCENT DEUTSCHLAND AG > PROJECT MANAGER ASON/GMPLS CONTROL PLANE > CORE NETWORKS BUSINESS DIVISION > OPTICS BU, SWITCHING R&D > > Lorenzstrasse 10 > 70435 Stuttgart, Germany > Phone: +49 711 821 43125 begin_of_the_skype_highlighting +49 711 821 4312= 5FREE > end_of_the_skype_highlighting <%2B49%20711%20821%2043125> > Mobil: +49 175 7266874 begin_of_the_skype_highlighting +49 175 7266874FRE= E > end_of_the_skype_highlighting <%2B49%20175%207266874> **** > > *Dieter.Beller@alcatel-lucent.com ***** > > **** > > Alcatel-Lucent Deutschland AG > Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026 > Chairman of the Supervisory Board: Michael Oppenhoff > Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. > Rainer Fechner =B7 Andreas Gehe **** > > **** > --001a11c395a689110d04da7aed66 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Khuzema, Hi!

MELGs are useful and come = into play only when:
(1) The server network domain is abstracted = and the advertised Virtual TE-links possess some mutual exclusivity relatio= nship.
(2) There is a Centralized path computation entity in the client domai= n (computes paths in terms of Client TE-links/TE-nodes) that is capable of = doing concurrent path computations.

If either of t= he above 2 statements is NOT true, there is no utility for MELGs.=A0
At the risk of being pedantic:=A0
- Are MELGs need= ed when the server-network domain in not abstracted (no Virtual TE links)? = The answer is NO.
- Are MELGs needed when you have a distributed = path-computation architecture (Client PCE interacting with Server PCE)? The= answer is NO.
- Are MELGs needed when the centralized path-computation engine = doesn't (can't) do concurrent computations? The answer is NO.
=

The actual procedures involved in abstracting the= server network domain is beyond the scope of <draft-melgs>. The abst= raction procedure itself is implementation-specific (maybe someday someone = would put together a draft for discussing this). Though it is true that the= primary use-case we had in mind when coming up with this new construct inv= olves a lambda-layer server network domain, there is really no restriction = (at a conceptual level) on using this construct when abstracting a packet-l= ayer server network domain or a TDM-layer server network domain. It is up t= o the implementation on how to make best use of this construct.=A0

When you advertise a Virtual TE-link into a client netw= ork domain, you are doing this based on the existence of some potential und= erlying server-path. TE attributes like SRLGs, MELGs, delay etc that get ad= vertised for the Virtual TE-link depend on the underlying server-path that = is chosen for catering to this Client TE-link. If the underlying server-pat= h keeps changing (based on network events), these TE attributes would also = keep changing. The procedure for keeping the advertised information "c= urrent" is an implementation choice.=A0

If there exists such a thing as an abstraction manager = (again, this is totally implementation specific), then the assumption is th= at it does one of the following -=A0
(a) computes new server-path= s for the Virtual TE links whenever there is a change in the network (may n= ot be very scalable in some architectures),=A0
(b) or does periodic path-computation for each Virtual TE link,=A0
(c) or uses a policy to pin down the Virtual TE-link to a specific u= nderlying server-path,=A0
(d) or uses a combination of (a), (b), = (c).

<draft-melgs> doesn't make any recommen= dation as to what choice the abstraction manager would need to take.
<= div style>
Hope this helps.
-Pavan


On Tue, = Apr 16, 2013 at 7:08 AM, Khuzema Pithewan <kpithewan@infinera.com= > wrote:

Hi Igor,

=A0<= /p>

I am trying to summarize = the discussion we had so far. Pls see if my conclusion is in sync with the = idea of MELG you have

=A0<= /p>

MELG is useful when

1.=A0=A0=A0=A0=A0=A0 server layer VLs are= nailed down for the resources on the server layer links that are shared am= ong multiple VLs. These resources are typically wavelength on a fiber (can it be anything else??). In other words, if 2 VLs are pinne= d to use a particular wavelength on a particular fiber, then these 2 VLs wi= ll have MELG for the wavelength.

2.=A0=A0=A0=A0=A0=A0 server layer do not = have centralized path computation entity which can be used by client layer = to ask for concurrent diverse path computation within server layer.

3.=A0=A0=A0=A0=A0=A0 Client layer has a c= entralized path computation entity, which would compute paths for client+se= rver layer.

4.=A0=A0=A0=A0=A0=A0 The need is to centr= alized concurrent computation of more than one client+server layer path tha= t meets some diversity and resource exclusivity requirements.=

=A0<= /p>

Regds

Khuzema

=A0<= /p>

From: Igor Bry= skin [mailto:= IBryskin@advaoptical.com]
Sent: Monday, April 15, 2013 9:44 PM


To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

=A0

Khuzema,

Please, see in-line.

=A0<= /p>

Igor=

=A0<= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infinera.com]
Sent: Monday, April 15, 2013 12:05 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

=A0

Hi Igor,

=A0<= /p>

I understand the SRLG and= MELG behavior you have penned .

=A0<= /p>

My concern was little dif= ferent.=A0 With changing resource consumption (because of dynamicity the ne= twork has) in the network links, potential paths a set of virtual link can take will change and hence its MELG, as it is tied to a r= esource it can take. So unless virtual links paths are nailed down, it woul= d be hard to compute MELGs in distributed way.

=A0<= /p>

IB>> I think you ar= e missing the point here. Virtual Link server layer paths are pinned as far= as fate sharing is concerned (that is, they are pinned on =A0server layer link level). It would make little sense to advertise VL SRLGs if the= SRLGs constantly change. The same is true for MELGs. =A0SRLGs/MELGs advert= ised for VLs normally do not change: neither over time nor when VLs become = committed/uncommitted.

=A0<= /p>

Another point is, virtual= links can be viewed as oversubscription of resources (in MELG context). Ta= king an example (for OTN, I know it would work differently for a Wavelength in WDM), a link resources are worth 1 TB of BW, user has = provisioned 20 virtual links of 100G each going via that OTN link. =A0Physi= cally, only 10 will get committed. But which 10? It will really depend on n= etwork dynamics at the time of demand to commit. MELGs are not that effective here. You need some different mech= anism.

=A0<= /p>

IB>> As I mentioned= before MELGs have nothing to do with bandwidth and were never intended to = solve the problems such as you describe (just like it would not make much sense to solve such problem with SRLGs :=3D)

Again, =A0MELG is an extr= eme case SRLG designed exclusively for VLs (no more and no less).=

=A0<= /p>

Regds

Khuzema

=A0<= /p>

=A0<= /p>

From: Igor Bry= skin [mailto:= IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 11:55 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

=A0

Khuzema,

=A0<= /p>

Think about MELG as an SR= LG that is shared between two or more links in its entirety. When two real = links have an SRLG in common, it means that two real links can co-exist concurrently, but there is something (e.g. common conduit, no= te that the conduit has room for more than for one link) that will bring bo= th these links down, if this something fails (e.g. conduit is cut ). Now co= nsider that this something must be taken in its entirety by one of the links to become operational . In th= is case SRLG becomes MELG. Note that MELG is only meaningful for virtual li= nks (unlike SRLG that makes sense for either real or virtual link). Why wou= ld you advertise two links that mutually exclude each other rather than advertising only one of them at a = time, unless the two are virtual links and hence both available for the cli= ent layer connections?

=A0<= /p>

Igor

=A0<= /p>

=A0<= /p>

From: Khuzema = Pithewan [mailt= o:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 1:01 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

=A0

Hi Igor,

=A0<= /p>

Do you mean, if virtual l= ink do not have any specific constraint, for example a link in the path (no= t talking about egress links/interfaces) must be traversed to realize the virtual link, there wont be any MELG for the virtual link?<= u>

=A0<= /p>

Regds

Khuzema

=A0<= /p>

From: Igor Bry= skin [mailto:= IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 9:52 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

=A0

Khuzema,=

=A0<= /p>

MELGs have nothing to do = with bandwidth. MELG is a concrete network resource in a server layer that = two or more Virtual Links in a client layer depend on in a mutually exclusive way. An example of MELG is a WDM layer transponder th= at can terminate either of respective WDM layer tunnels (but not both at th= e same time) for two OTN layer Virtual Links. If you advertise a Virtual Li= nk, say, for Ethernet layer that depends on the connection in OTN layer going through one of the mentioned = OTN links, the Ethernet VL must inherit the MELG similarly like it does SRL= Gs advertised for the OTN links.

=A0<= /p>

Igor=

=A0<= /p>

=A0<= /p>

From: Khuzema = Pithewan [mailt= o:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 12:06 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

=A0

Hi Igor,=

=A0<= /p>

For multi-layer (more tha= n 2) network, consider all the layers are meshy (that=92s when virtual link= s are useful anyway), MELGs of virtual link will change as and when BW/wavelength availability changes, because potential paths, a vi= rtual link can take will change. Mapping lower layer MELGs to higher layer = MELGs won=92t be practical if done in distributed manner, so it has to be c= entralized. So you do have central element in each layer that knows all the risk and paths (a PCE?), which ca= n be utilized for layer specific path computation (as it is doing it anyway= ).

=A0<= /p>

This kind of architecture= has all the pieces that are required for Inter-PCE communication (across l= ayers), except the protocol that would actually make the 2 PCEs talk.

=A0<= /p>

You seem to be doing some= thing that you don=92t like J

=A0<= /p>

Regards<= /u>

Khuzema<= /u>

=A0<= /p>

From: Igor Bry= skin [mailto:= IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 8:39 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

=A0

Khuzema,=

=A0<= /p>

I am not a fan of inter-l= ayer path computations (nor I am a fan of inter-PCE computations). In my mi= nd path computation for a service or services in layer X is performed only in layer X, i.e. considers only X layer links (real or v= irtual). As Pavan mentioned SRLGs and MELGs that need to be inherited from = lower layers should be translated into X layer link SRLGs/MELGs and specifi= ed with X layer specific SRLG/MELG IDs.

=A0<= /p>

Cheers,<= /u>

Igor=

=A0<= /p>

=A0<= /p>

From: Khuzema = Pithewan [mailt= o:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 10:55 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

=A0

Hi Igor,=

=A0<= /p>

Ok. This would be useful = if network architecture is based on external PCE or mgmt entity as PCE in c= lient layer, but there is no counterpart in server layer, otherwise one could have inter-PCE communication to achieve diverse path i= n server layer without getting into virtual link and MELG stuff.<= /u>

=A0<= /p>

Is that correct?

=A0<= /p>

Khuzema<= /u>

=A0<= /p>

From: Igor Bry= skin [mailto:= IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 6:36 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

=A0

Khuzema,=

=A0<= /p>

2.=A0=A0=A0=A0=A0=A0 For cases of concurrent computation (case= #2-5), you are mainly talking about global optimization and diversity among= multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from th= e source end of those LSPs.=A0 So there is no point in doing concurrent com= putation at one network element for the services starting from multiple net= work elements. At best it looks to me a problem to be solved by network management/planning software.= =A0

Well, when an ingress nod= e is initiating a service, it is doing so on request from some management e= ntity. This management entity can compute paths for many services with some global criteria in mind, and then specify the resulting= paths as explicit EROs in provisioning requests sent to each of the servic= e ingresses. How else, for example, =A0you can set up several services orig= inated from different nodes that are disjoint from each other? Also, what is the point in your opinion of the s= tatefull PCE work?

=A0<= /p>

Cheers,<= /u>

Igor=

=A0<= /p>

From: Vishnu P= avan Beeram [mai= lto:vishnupavan@gmail.com]
Sent: Friday, April 12, 2013 8:08 AM
To: Khuzema Pithewan
Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

=A0

Khuzema, Hi!


Please see inline..

=A0

=A0

=A01.=A0=A0=A0=A0=A0=A0 When Network has more than 2 layer i.e. P= acket-OTN-DWDM, the Packet (client) layer will be talking to its immediate = server layer i.e. OTN, which in turn is talking to DWDM layer. Using MELG, client layer path computation can take care of resource= exclusivity of virtual link for immediate server layer i.e. OTN layer.=A0 = However if there is resource exclusivity at DWDM layer, this mechanism does= n=92t work. You need to do loose routing or use distributed PCE model

=A0

[VPB] The behavior is the same as what you would do = with SRLGs in a multi-layer architecture. There are architectures that allo= w the SRLGs in the lowest layer to be exported all the way up to the highes= t layer. The expectation is that MELGs would be treated in the same vein.=A0

2.=A0=A0=A0=A0=A0=A0 For cases of concurrent computation (case= #2-5), you are mainly talking about global optimization and diversity among= multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from th= e source end of those LSPs.=A0 So there is no point in doing concurrent com= putation at one network element for the services starting from multiple net= work elements. At best it looks to me a problem to be solved by network management/planning software.= =A0

[VPB] =A0I'm not sure why you think there is no = point in having a centralized computation function compute paths concurrent= ly for LSPs with different set of end-points. Even your NMS/planning-softwa= re can interact with such computation engine, retrieve all the paths and then go about initiating the path-setup from th= e ingress of each LSP.=A0

=A0

Regards,

-Pavan

=A0

=A0

=A0<= /p>

=A0<= /p>

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Tuesday, March 26, 2013 7:19 PM
To: Dieter Beller; Vishnu Pavan Beeram


Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

=A0

Dieter,<= /u>

=A0<= /p>

You said:

>> I guess we are coming back to the essential= point: "and how often concurrent path comp= utation will be >> used."

=A0

To be honest, this surprises me quite a bit, Let me = give you some of many reasons as to why concurrent path computations are ne= eded and why this is better than computing one path at a time:

=A0

1.=A0=A0=A0=A0=A0 Computing sever= al diverse paths for the same service in the context of service recovery. I= hope you realize that computing one path at a time on many configurations = produces no or sub-optimal results. I also hope you realize the problem of selecting two paths with one of them =A0having = a link with common MELG with a link from another path;

2.=A0=A0=A0=A0=A0 Computing paths= for multiple services to be sufficiently disjoint from each other;<= u>

3.=A0=A0=A0=A0=A0 Computing paths= for multiple services to achieve a global optimization criteria (e.g. mini= mal summary total cost);

4.=A0=A0=A0=A0=A0 Computing paths= for multiple services for the purpose of removing the bandwidth fragmentat= ions;

5.=A0=A0=A0=A0=A0 Computing paths= for multiple services to plan shared mesh protection/restoration schemes

6.=A0=A0=A0=A0=A0 Etc.<= /u>

=A0

Also think about this:

1.=A0=A0=A0=A0=A0 If concurrent p= ath computation was not important, why PCEP includes the machinery to do th= at?

2.=A0=A0=A0=A0=A0 My understandin= g of the statefull PCE is that it does pretty much nothing but concurrent p= ath computations

=A0

You also said:

>> I suppose th= at if a pce approach is used, i.e., path computation is centralized includi= ng the
>> TE-DB, MELG routing extensions are not needed because the informat= ion about mutual
>>exclusive VLs can be kept in the central TE-DB when VLs are configu= red.

How this logic does not apply to other link attribut= es such as SRLGs?

What if path computation is not centralized?<= u>

=A0

Cheers,

Igor

=A0<= /p>

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

=A0

Hi Pavan,

On 25.03.2013 07:29, Fat= ai Zhang wrote:

Hi Pavan,

=A0<= /p>

I am not sure how much VL= (Virtual Link) will be used in the practical deployment and how often conc= urrent path computation will be used.

I guess we are coming back to the essential point: &= quot;and how often concurrent path computation w= ill be used."

This means we are trying to figure out under which conditions MELG routing = extensions
could be beneficial.

IMHO, they would only make sense, if:

  • a path computation function supports the calculation of k shortest paths co= ncurrently
  • if there is only a single path computation function instance per domain (pc= e approach)
    If path computation is done in a distributed fashion the benefit goes away = because
    the instances calculate paths independently!

I suppose that if a p= ce approach is used, i.e., path computation is centralized including the TE-DB, MELG routing extensions are not needed because the information about= mutual
exclusive VLs can be kept in the central TE-DB when VLs are configured.

Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their
applicability is broader.


Thanks,
Dieter

=A0<= /p>

Do you think if it makes sense to add a flag (in= routing advertisement) to indicate a link is a VL or not?=

=A0

=A0

=A0

Best Regards

=A0

Fatai

=A0<= /p>

From: Vishnu P= avan Beeram [mai= lto:vishnupavan@gmail.com]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

=A0

Fatai, Hi!

=A0

Good to see that you understand the construct now.

=A0

This is not a corner case. The utility of the constr= uct becomes quite significant if you have an application that does concurre= nt path computations on an abstract topology.

=A0

Regards,

-Pavan

=A0

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org=

https://www.ietf.org/mailman/listinfo/ccamp

=A0

--

DIETER BELLER

ALCATEL-LUCENT DEUTSCHLAND= AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 711 821 43125 begin_of_the_skype_highlighting=A0+49 711 821 43125 FREE=A0 end_of_t= he_skype_highlighting
Mobil: +49 175 7266874 begin_of_the_skype_highlighting=A0+49 175 7266874 = FREE=A0 end_of_the_skyp= e_highlighting

=A0

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe

=A0


--001a11c395a689110d04da7aed66-- From IBryskin@advaoptical.com Tue Apr 16 07:20:43 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11AB21F9739 for ; Tue, 16 Apr 2013 07:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=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 n7-xqkmlLlAD for ; Tue, 16 Apr 2013 07:20:32 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id D8A4021F96F5 for ; Tue, 16 Apr 2013 07:20:30 -0700 (PDT) Received: from MUC-SRV-MAIL10.advaoptical.com (muc-srv-mail10.advaoptical.com [172.20.1.59]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id r3GEJlgi029220 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Apr 2013 16:19:48 +0200 Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 16 Apr 2013 16:19:47 +0200 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0123.003; Tue, 16 Apr 2013 10:19:45 -0400 From: Igor Bryskin To: Khuzema Pithewan , Vishnu Pavan Beeram Thread-Topic: [CCAMP] MELGs - Q&A Thread-Index: AQHOIGPeoOQf0fNS1kG7ulofq5GmQJivzRoAgABxTHCAAPkpgIAAeAqAgABMBQCABErLAIABAdYAgAC6NQCAGt0OAIAAD52A///KWjCAAGRRgP//wCBQgABTlAD//73CwAAKM0gAAAY9GCAAdYY0gAAQgVwAADCVHoAAA3fQ8A== Date: Tue, 16 Apr 2013 14:19:45 +0000 Message-ID: References: <5150C704.2040007@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.1.111] Content-Type: multipart/alternative; boundary="_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A192392EEatlsrvmail10atl_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-04-16_05:2013-04-16, 2013-04-16, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] MELGs - Q&A X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 14:20:43 -0000 --_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A192392EEatlsrvmail10atl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Khuzema, Please, see in line. From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Tuesday, April 16, 2013 7:08 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, I am trying to summarize the discussion we had so far. Pls see if my conclu= sion is in sync with the idea of MELG you have MELG is useful when 1. server layer VLs are nailed down for the resources on the server la= yer links that are shared among multiple VLs. IB>> Correction: server layer link-level paths supporting *client layer* VL= s are nailed down. The resources of said paths are sharable between the pat= hs (and hence VLs) but not available for anything else. These resources are typically wavelength on a fiber (can it be anything els= e??). IB>> Server layer does not have to be WDM In other words, if 2 VLs are pinned to use a particular wavelength on a par= ticular fiber, then these 2 VLs will have MELG for the wavelength. IB>> Correction: Wavelength is not the only type of resource that is used i= n WDM layer. If two paths use the same transponder, converter, regenerator,= etc. then corresponding VLs have a MELG in common. If two paths have a WDM= link in common on which they *must* use the same wavelength (e.g. because = the paths are started on fixed transponders of the same frequency), then th= ey also have an MELG in common. If two paths have to use the same wavelengt= h on a common WDM link because this is the only wavelength available at the= moment, then the VLs *do not* have an MELG in common (just usual lack of = resources on the link) 2. server layer do not have centralized path computation entity which = can be used by client layer to ask for concurrent diverse path computation = within server layer. IB>> This approach has nothing to do with VLs. VLs (just like real links) a= re supposed to be pre-planned in a different time frame from when client la= yer connections are set up. When VLs are advertised, this means that the se= rver layer paths are successfully computed and pinned already (btw by serve= r layer path computer). Asking server layer path computation dynamically do= es not guarantee any success, so, if it fails, what to do next? You cannot= orchestrate any restoration schemes in the client layer this way. Instaed,= we suggest solid as_good_as_real Virtual Topology to use. 3. Client layer has a centralized path computation entity, which would= compute paths for client+server layer. IB>> Correction: only for client layer, based on client layer VLs 4. The need is to centralized concurrent computation of more than one = client+server layer path that meets some diversity and resource exclusivity= requirements. IB>> Correction: there is a need for concurrent path computation in the cli= ent layer and because the client layer topology is virtual, you need MELGs = to consider Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Monday, April 15, 2013 9:44 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Please, see in-line. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Monday, April 15, 2013 12:05 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, I understand the SRLG and MELG behavior you have penned . My concern was little different. With changing resource consumption (becau= se of dynamicity the network has) in the network links, potential paths a s= et of virtual link can take will change and hence its MELG, as it is tied t= o a resource it can take. So unless virtual links paths are nailed down, it= would be hard to compute MELGs in distributed way. IB>> I think you are missing the point here. Virtual Link server layer path= s are pinned as far as fate sharing is concerned (that is, they are pinned = on server layer link level). It would make little sense to advertise VL SR= LGs if the SRLGs constantly change. The same is true for MELGs. SRLGs/MELG= s advertised for VLs normally do not change: neither over time nor when VLs= become committed/uncommitted. Another point is, virtual links can be viewed as oversubscription of resour= ces (in MELG context). Taking an example (for OTN, I know it would work dif= ferently for a Wavelength in WDM), a link resources are worth 1 TB of BW, u= ser has provisioned 20 virtual links of 100G each going via that OTN link. = Physically, only 10 will get committed. But which 10? It will really depen= d on network dynamics at the time of demand to commit. MELGs are not that e= ffective here. You need some different mechanism. IB>> As I mentioned before MELGs have nothing to do with bandwidth and were= never intended to solve the problems such as you describe (just like it wo= uld not make much sense to solve such problem with SRLGs :=3D) Again, MELG is an extreme case SRLG designed exclusively for VLs (no more = and no less). Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 11:55 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Think about MELG as an SRLG that is shared between two or more links in its= entirety. When two real links have an SRLG in common, it means that two re= al links can co-exist concurrently, but there is something (e.g. common con= duit, note that the conduit has room for more than for one link) that will = bring both these links down, if this something fails (e.g. conduit is cut )= . Now consider that this something must be taken in its entirety by one of = the links to become operational . In this case SRLG becomes MELG. Note that= MELG is only meaningful for virtual links (unlike SRLG that makes sense fo= r either real or virtual link). Why would you advertise two links that mutu= ally exclude each other rather than advertising only one of them at a time,= unless the two are virtual links and hence both available for the client l= ayer connections? Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 1:01 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Do you mean, if virtual link do not have any specific constraint, for examp= le a link in the path (not talking about egress links/interfaces) must be t= raversed to realize the virtual link, there wont be any MELG for the virtua= l link? Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 9:52 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, MELGs have nothing to do with bandwidth. MELG is a concrete network resourc= e in a server layer that two or more Virtual Links in a client layer depend= on in a mutually exclusive way. An example of MELG is a WDM layer transpon= der that can terminate either of respective WDM layer tunnels (but not both= at the same time) for two OTN layer Virtual Links. If you advertise a Virt= ual Link, say, for Ethernet layer that depends on the connection in OTN lay= er going through one of the mentioned OTN links, the Ethernet VL must inher= it the MELG similarly like it does SRLGs advertised for the OTN links. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 12:06 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, For multi-layer (more than 2) network, consider all the layers are meshy (t= hat's when virtual links are useful anyway), MELGs of virtual link will cha= nge as and when BW/wavelength availability changes, because potential paths= , a virtual link can take will change. Mapping lower layer MELGs to higher = layer MELGs won't be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all= the risk and paths (a PCE?), which can be utilized for layer specific path= computation (as it is doing it anyway). This kind of architecture has all the pieces that are required for Inter-PC= E communication (across layers), except the protocol that would actually ma= ke the 2 PCEs talk. You seem to be doing something that you don't like :) Regards Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 8:39 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, I am not a fan of inter-layer path computations (nor I am a fan of inter-PC= E computations). In my mind path computation for a service or services in l= ayer X is performed only in layer X, i.e. considers only X layer links (rea= l or virtual). As Pavan mentioned SRLGs and MELGs that need to be inherited= from lower layers should be translated into X layer link SRLGs/MELGs and s= pecified with X layer specific SRLG/MELG IDs. Cheers, Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 10:55 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Ok. This would be useful if network architecture is based on external PCE o= r mgmt entity as PCE in client layer, but there is no counterpart in server= layer, otherwise one could have inter-PCE communication to achieve diverse= path in server layer without getting into virtual link and MELG stuff. Is that correct? Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 6:36 PM To: Vishnu Pavan Beeram; Khuzema Pithewan Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. Well, when an ingress node is initiating a service, it is doing so on reque= st from some management entity. This management entity can compute paths fo= r many services with some global criteria in mind, and then specify the res= ulting paths as explicit EROs in provisioning requests sent to each of the = service ingresses. How else, for example, you can set up several services = originated from different nodes that are disjoint from each other? Also, wh= at is the point in your opinion of the statefull PCE work? Cheers, Igor From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, April 12, 2013 8:08 AM To: Khuzema Pithewan Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Khuzema, Hi! Please see inline.. 1. When Network has more than 2 layer i.e. Packet-OTN-DWDM, the Pack= et (client) layer will be talking to its immediate server layer i.e. OTN, w= hich in turn is talking to DWDM layer. Using MELG, client layer path comput= ation can take care of resource exclusivity of virtual link for immediate s= erver layer i.e. OTN layer. However if there is resource exclusivity at DW= DM layer, this mechanism doesn't work. You need to do loose routing or use = distributed PCE model [VPB] The behavior is the same as what you would do with SRLGs in a multi-l= ayer architecture. There are architectures that allow the SRLGs in the lowe= st layer to be exported all the way up to the highest layer. The expectatio= n is that MELGs would be treated in the same vein. 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. [VPB] I'm not sure why you think there is no point in having a centralized= computation function compute paths concurrently for LSPs with different se= t of end-points. Even your NMS/planning-software can interact with such com= putation engine, retrieve all the paths and then go about initiating the pa= th-setup from the ingress of each LSP. Regards, -Pavan From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Igor Bryskin Sent: Tuesday, March 26, 2013 7:19 PM To: Dieter Beller; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Dieter, You said: >> I guess we are coming back to the essential point: "and how often concur= rent path computation will be >> used." To be honest, this surprises me quite a bit, Let me give you some of many r= easons as to why concurrent path computations are needed and why this is be= tter than computing one path at a time: 1. Computing several diverse paths for the same service in the context= of service recovery. I hope you realize that computing one path at a time = on many configurations produces no or sub-optimal results. I also hope you = realize the problem of selecting two paths with one of them having a link = with common MELG with a link from another path; 2. Computing paths for multiple services to be sufficiently disjoint f= rom each other; 3. Computing paths for multiple services to achieve a global optimizat= ion criteria (e.g. minimal summary total cost); 4. Computing paths for multiple services for the purpose of removing t= he bandwidth fragmentations; 5. Computing paths for multiple services to plan shared mesh protectio= n/restoration schemes 6. Etc. Also think about this: 1. If concurrent path computation was not important, why PCEP includes= the machinery to do that? 2. My understanding of the statefull PCE is that it does pretty much n= othing but concurrent path computations You also said: >> I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the >> TE-DB, MELG routing extensions are not needed because the information ab= out mutual >>exclusive VLs can be kept in the central TE-DB when VLs are configured. How this logic does not apply to other link attributes such as SRLGs? What if path computation is not centralized? Cheers, Igor From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Dieter Beller Sent: Monday, March 25, 2013 5:52 PM To: Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Hi Pavan, On 25.03.2013 07:29, Fatai Zhang wrote: Hi Pavan, I am not sure how much VL (Virtual Link) will be used in the practical depl= oyment and how often concurrent path computation will be used. I guess we are coming back to the essential point: "and how often concurren= t path computation will be used." This means we are trying to figure out under which conditions MELG routing = extensions could be beneficial. IMHO, they would only make sense, if: * a path computation function supports the calculation of k shortest pa= ths concurrently * if there is only a single path computation function instance per doma= in (pce approach) If path computation is done in a distributed fashion the benefit goes away = because the instances calculate paths independently! I suppose that if a pce approach is used, i.e., path computation is central= ized including the TE-DB, MELG routing extensions are not needed because the information about= mutual exclusive VLs can be kept in the central TE-DB when VLs are configured. Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their applicability is broader. Thanks, Dieter Do you think if it makes sense to add a flag (in routing advertisement) to = indicate a link is a VL or not? Best Regards Fatai From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, March 22, 2013 8:57 PM To: Fatai Zhang Cc: Igor Bryskin; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Fatai, Hi! Good to see that you understand the construct now. This is not a corner case. The utility of the construct becomes quite signi= ficant if you have an application that does concurrent path computations on= an abstract topology. Regards, -Pavan _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp -- DIETER BELLER ALCATEL-LUCENT DEUTSCHLAND AG PROJECT MANAGER ASON/GMPLS CONTROL PLANE CORE NETWORKS BUSINESS DIVISION OPTICS BU, SWITCHING R&D Lorenzstrasse 10 70435 Stuttgart, Germany Phone: +49 711 821 43125 Mobil: +49 175 7266874 Dieter.Beller@alcatel-lucent.com Alcatel-Lucent Deutschland AG Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026 Chairman of the Supervisory Board: Michael Oppenhoff Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe --_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A192392EEatlsrvmail10atl_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Khuzema,

Please, see in line.=

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infinera.com]
Sent: Tuesday, April 16, 2013 7:08 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

I am trying to summarize = the discussion we had so far. Pls see if my conclusion is in sync with the = idea of MELG you have

 <= /p>

MELG is useful when<= /o:p>

1. = ;     server layer VLs = are nailed down for the resources on the server layer links that are shared= among multiple VLs.

IB>> Correction: se= rver layer link-level paths supporting *client layer* VLs are nailed= down. The resources of said paths are sharable between the paths (and hence VLs) but not available for anything else.

 <= /p>

IB>> Server layer d= oes not have to be WDM

 <= /p>

IB>> Correction: Wa= velength is not the only type of resource that is used in WDM layer. If two= paths use the same transponder, converter, regenerator, etc. then corresponding VLs have a MELG in common. If two paths have a WDM link= in common on which they *must* use the same wavelength (e.g. becaus= e the paths are started on fixed transponders of the same frequency), then = they also have an MELG in common. If two paths have to use the same wavelength on a common WDM link because = this is the only wavelength available at the moment, then the VLs *do no= t* have an MELG in common (just  usual lack of resources on the li= nk)

 <= /p>

2. = ;     server layer do n= ot have centralized path computation entity which can be used by client lay= er to ask for concurrent diverse path computation within server layer.

IB>> This approach = has nothing to do with VLs. VLs (just like real links) are supposed to be p= re-planned in a different time frame from when client layer connections are set up. When VLs are advertised, this means that the server layer path= s are successfully computed and pinned already (btw by server layer path co= mputer). Asking server layer path computation dynamically does not guarante= e  any success, so, if it fails, what to do next? You cannot orchestrate any restoration schemes in the cli= ent layer this way. Instaed, we suggest solid as_good_as_real Virtual Topol= ogy to use.

 <= /p>

3. = ;     Client layer has = a centralized path computation entity, which would compute paths for client= +server layer.

IB>> Correction: on= ly for client layer, based on client layer VLs

4. = ;     The need is to ce= ntralized concurrent computation of more than one client+server layer p= ath that meets some diversity and resource exclusivity requirements.

IB>> Correction: th= ere is a need for concurrent path computation in the client layer and becau= se the client layer topology is virtual, you need MELGs to consider

 <= /p>

Regds

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Monday, April 15, 2013 9:44 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

Please, see in-line.=

 <= /p>

Igor

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Monday, April 15, 2013 12:05 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

I understand the SRLG and= MELG behavior you have penned .

 <= /p>

My concern was little dif= ferent.  With changing resource consumption (because of dynamicity the= network has) in the network links, potential paths a set of virtual link can take will change and hence its MELG, as it is tied to a r= esource it can take. So unless virtual links paths are nailed down, it woul= d be hard to compute MELGs in distributed way.

 <= /p>

IB>> I think you ar= e missing the point here. Virtual Link server layer paths are pinned as far= as fate sharing is concerned (that is, they are pinned on  server layer link level). It would make little sense to advertise VL SRLGs if the= SRLGs constantly change. The same is true for MELGs.  SRLGs/MELGs adv= ertised for VLs normally do not change: neither over time nor when VLs beco= me committed/uncommitted.

 <= /p>

Another point is, virtual= links can be viewed as oversubscription of resources (in MELG context). Ta= king an example (for OTN, I know it would work differently for a Wavelength in WDM), a link resources are worth 1 TB of BW, user has = provisioned 20 virtual links of 100G each going via that OTN link.  Ph= ysically, only 10 will get committed. But which 10? It will really depend o= n network dynamics at the time of demand to commit. MELGs are not that effective here. You need some different mech= anism.

 <= /p>

IB>> As I mentioned= before MELGs have nothing to do with bandwidth and were never intended to = solve the problems such as you describe (just like it would not make much sense to solve such problem with SRLGs :=3D)

Again,  MELG is an e= xtreme case SRLG designed exclusively for VLs (no more and no less).

 <= /p>

Regds

Khuzema=

 <= /p>

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 11:55 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

Think about MELG as an SR= LG that is shared between two or more links in its entirety. When two real = links have an SRLG in common, it means that two real links can co-exist concurrently, but there is something (e.g. common conduit, no= te that the conduit has room for more than for one link) that will bring bo= th these links down, if this something fails (e.g. conduit is cut ). Now co= nsider that this something must be taken in its entirety by one of the links to become operational . In th= is case SRLG becomes MELG. Note that MELG is only meaningful for virtual li= nks (unlike SRLG that makes sense for either real or virtual link). Why wou= ld you advertise two links that mutually exclude each other rather than advertising only one of them at a = time, unless the two are virtual links and hence both available for the cli= ent layer connections?

 <= /p>

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Friday, April 12, 2013 1:01 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

Do you mean, if virtual l= ink do not have any specific constraint, for example a link in the path (no= t talking about egress links/interfaces) must be traversed to realize the virtual link, there wont be any MELG for the virtual link?<= o:p>

 <= /p>

Regds

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 9:52 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

MELGs have nothing to do = with bandwidth. MELG is a concrete network resource in a server layer that = two or more Virtual Links in a client layer depend on in a mutually exclusive way. An example of MELG is a WDM layer transponder th= at can terminate either of respective WDM layer tunnels (but not both at th= e same time) for two OTN layer Virtual Links. If you advertise a Virtual Li= nk, say, for Ethernet layer that depends on the connection in OTN layer going through one of the mentioned = OTN links, the Ethernet VL must inherit the MELG similarly like it does SRL= Gs advertised for the OTN links.

 <= /p>

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Friday, April 12, 2013 12:06 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

For multi-layer (more tha= n 2) network, consider all the layers are meshy (that’s when virtual = links are useful anyway), MELGs of virtual link will change as and when BW/wavelength availability changes, because potential paths, a vi= rtual link can take will change. Mapping lower layer MELGs to higher layer = MELGs won’t be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all the risk and paths (a PCE?), which ca= n be utilized for layer specific path computation (as it is doing it anyway= ).

 <= /p>

This kind of architecture= has all the pieces that are required for Inter-PCE communication (across l= ayers), except the protocol that would actually make the 2 PCEs talk.

 <= /p>

You seem to be doing some= thing that you don’t like J

 <= /p>

Regards=

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 8:39 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

I am not a fan of inter-l= ayer path computations (nor I am a fan of inter-PCE computations). In my mi= nd path computation for a service or services in layer X is performed only in layer X, i.e. considers only X layer links (real or v= irtual). As Pavan mentioned SRLGs and MELGs that need to be inherited from = lower layers should be translated into X layer link SRLGs/MELGs and specifi= ed with X layer specific SRLG/MELG IDs.

 <= /p>

Cheers,=

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Friday, April 12, 2013 10:55 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

Ok. This would be useful = if network architecture is based on external PCE or mgmt entity as PCE in c= lient layer, but there is no counterpart in server layer, otherwise one could have inter-PCE communication to achieve diverse path i= n server layer without getting into virtual link and MELG stuff.

 <= /p>

Is that correct?

 <= /p>

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 6:36 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

2.       For cases of concurrent computation (case= #2-5), you are mainly talking about global optimization and diversity among= multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from th= e source end of those LSPs.  So there is no point in doing concurrent = computation at one network element for the services starting from multiple = network elements. At best it looks to me a problem to be solved by network management/planning software.&= nbsp;

Well, when an ingress nod= e is initiating a service, it is doing so on request from some management e= ntity. This management entity can compute paths for many services with some global criteria in mind, and then specify the resulting= paths as explicit EROs in provisioning requests sent to each of the servic= e ingresses. How else, for example,  you can set up several services o= riginated from different nodes that are disjoint from each other? Also, what is the point in your opinion of the s= tatefull PCE work?

 <= /p>

Cheers,=

Igor

 <= /p>

From: Vishnu P= avan Beeram [mailto:vishnupavan@gm= ail.com]
Sent: Friday, April 12, 2013 8:08 AM
To: Khuzema Pithewan
Cc: Igor Bryskin; Dieter Beller; c= camp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Khuzema, Hi!


Please see inline..

 

 

 1.       When Network has more than 2 layer i.e. P= acket-OTN-DWDM, the Packet (client) layer will be talking to its immediate = server layer i.e. OTN, which in turn is talking to DWDM layer. Using MELG, client layer path computation can take care of resource= exclusivity of virtual link for immediate server layer i.e. OTN layer.&nbs= p; However if there is resource exclusivity at DWDM layer, this mechanism d= oesn’t work. You need to do loose routing or use distributed PCE model

 

[VPB] The behavior is the same as what you would do = with SRLGs in a multi-layer architecture. There are architectures that allo= w the SRLGs in the lowest layer to be exported all the way up to the highes= t layer. The expectation is that MELGs would be treated in the same vein. 

2.       For cases of concurrent computation (case= #2-5), you are mainly talking about global optimization and diversity among= multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from th= e source end of those LSPs.  So there is no point in doing concurrent = computation at one network element for the services starting from multiple = network elements. At best it looks to me a problem to be solved by network management/planning software.&= nbsp;

[VPB]  I'm not sure why you think there is no p= oint in having a centralized computation function compute paths concurrentl= y for LSPs with different set of end-points. Even your NMS/planning-softwar= e can interact with such computation engine, retrieve all the paths and then go about initiating the path-setup from th= e ingress of each LSP. 

 

Regards,

-Pavan

 

 

 

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Tuesday, March 26, 2013 7:19 PM
To: Dieter Beller; Vishnu Pavan Beeram


Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Dieter,

 

You said:

>> I guess we are coming back to the essential point: "= and how often concurrent path computation will be >> used."

 

To be honest, this surprises me quite a bit, Let me give you some = of many reasons as to why concurrent path computations are needed and why t= his is better than computing one path at a time:

 

1.      = Computing several diverse paths for the same service in the context of serv= ice recovery. I hope you realize that computing one path at a time on many = configurations produces no or sub-optimal results. I also hope you realize the problem of selecting two paths with one of them  havi= ng a link with common MELG with a link from another path;

2.      = Computing paths for multiple services to be sufficiently disjoint from each= other;

3.      = Computing paths for multiple services to achieve a global optimization crit= eria (e.g. minimal summary total cost);

4.      = Computing paths for multiple services for the purpose of removing the bandw= idth fragmentations;

5.      = Computing paths for multiple services to plan shared mesh protection/restor= ation schemes

6.      = Etc.

 

Also think about this:

1.      = If concurrent path computation was not important, why PCEP includes the mac= hinery to do that?

2.      = My understanding of the statefull PCE is that it does pretty much nothing b= ut concurrent path computations

 

You also said:

>> I suppose that if a pce approach is used, i.e., path computatio= n is centralized including the
>> TE-DB, MELG routing extensions are not needed because the informat= ion about mutual
>>exclusive VLs can be kept in the central TE-DB when VLs are configu= red.

How this logic does not apply to other link attributes such as SRL= Gs?

What if path computation is not centralized?

 

Cheers,

Igor

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Hi Pavan,

On 25.03.2013 07:29, Fat= ai Zhang wrote:

Hi Pavan,

 

I am not sure how much VL (Virtual Link= ) will be used in the practical deployment and how often concurrent path computation will be used.

I guess we are coming back to the essential point: "and how often concurrent path computation will be used."

This means we are trying to figure out under which conditions MELG routing = extensions
could be beneficial.

IMHO, they would only make sense, if:

  • a path computation function supports the calculation of k shortest paths co= ncurrently
  • if there is only a single path computation function instance per domain (pc= e approach)
    If path computation is done in a distributed fashion the benefit goes away = because
    the instances calculate paths independently!

I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the
TE-DB, MELG routing extensions are not needed because the information about= mutual
exclusive VLs can be kept in the central TE-DB when VLs are configured.

Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their
applicability is broader.


Thanks,
Dieter

 

Do you think if it makes sense to add a flag (in= routing advertisement) to indicate a link is a VL or not?

 

 

 

Best Regards

 

Fatai

 

From: Vishnu Pavan Beeram [<= a href=3D"mailto:vishnupavan@gmail.com" target=3D"_blank">mailto:vishnupava= n@gmail.com]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Fatai, Hi!

 

Good to see that you understand the construct now.

 

This is not a corner case. The utility of the construct becomes qu= ite significant if you have an application that does concurrent path comput= ations on an abstract topology.

 

Regards,

-Pavan

 

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org=

https://www.ietf.org/mailman/listinfo/ccamp

 

--

DIETER BELLER

ALCATEL-LUCENT DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 = 711 821 43125
Mobil: +49 175 = 7266874

 

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe

 

--_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A192392EEatlsrvmail10atl_-- From daniele.ceccarelli@ericsson.com Tue Apr 16 17:51:35 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89BE21F9725 for ; Tue, 16 Apr 2013 17:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 8E-RV8WZ5UW5 for ; Tue, 16 Apr 2013 17:51:34 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 42A8321F97A5 for ; Tue, 16 Apr 2013 17:51:34 -0700 (PDT) X-AuditID: c1b4fb30-b7f266d000000cb5-78-516df215bad6 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 08.29.03253.512FD615; Wed, 17 Apr 2013 02:51:33 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.208]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0318.004; Wed, 17 Apr 2013 02:51:32 +0200 From: Daniele Ceccarelli To: "fred.gruman@us.fujitsu.com" Thread-Topic: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt Thread-Index: Ac47BbOWzTuuOSgCzkqIPxCgYq5HeQ== Date: Wed, 17 Apr 2013 00:51:31 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE480AEC6B@ESESSMB301.ericsson.se> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM+Jvra7op9xAg5ZT/BZP5txgsehvnc3q wOSxZMlPJo9pv9awBTBFcdmkpOZklqUW6dslcGU8PfqEpeCwdsWzqZ8ZGxhfKXUxcnJICJhI PDm+ihnCFpO4cG89WxcjF4eQwGFGiV/vF7JCOEsYJV7MfsnSxcjBwSZgJfHkkA9Ig4iArcSj ibNYQGxmgViJudt+M4OUCAsESPw4WgdREijx+u4EVghbT2Lf0elg5SwCqhJnWk+C2bwC3hJz muaB1TAKyEpM2L2IEWKkuMStJ/OZIG4TkFiy5zzUnaISLx//Y4WwFSU+vtoHVa8ncWPqFDYI W1ti2cLXzBDzBSVOznzCMoFRZBaSsbOQtMxC0jILScsCRpZVjOy5iZk56eXmmxiBAX9wy2+D HYyb7osdYpTmYFES5w13vRAgJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgZHjQ4hU2dr2Gb5N LGvv2V16+vbOrJXfc6bbh/udW6krJGVj314Xum7rc8sfHzz1pu+pcrHqfB/8/tDRDZyPLx3j Z1u6/9FivleC58VWaack7YtqvrUwRm554ZdpBoGLS27Nmfzn9B7zqgcWi+1XHeL+5Vgl9zZI 5q2qf4166JEVh7ZONzz3Y89iJZbijERDLeai4kQA4swIAkYCAAA= Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 00:51:35 -0000 Hi Fred,=0A= =0A= Thanks again for the suggestions. No worries, if this is a change that make= s sense we can fix it before the second last call.=0A= =0A= Just wanted a clarification (more loud thinking than a question): do you th= ink that an interface might support different TSGs at the same time? If the= answer is yes the bitmap makes sense, otherwise an enum would be more bits= -saving.=0A= I would say that until no LSP is configured it is possible to advertise/sup= port multiple of them (e.g. The newest one plus the ones it is possible to = rollback to for backward compatibility issues) and then, after the instanti= ation of the first LSP, a single one.=0A= =0A= Best regards=0A= Daniele=0A= =0A= *** E-mail via DME powered by mobile broadband ***=0A= =0A= --Original message---=0A= Sender: "Gruman, Fred" =0A= Sent time: 14/apr/2013 09:02=0A= To: daniele.ceccarelli@ericsson.com, ccamp@ietf.org=0A= Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-06.= txt=0A= =0A= Hi Daniele,=0A= =0A= Thanks for making the update to the TSG examples in Section 5.2=0A= =0A= I have a one additional comments regarding TSG:=0A= =0A= 1) during an OIF conference call, Stephen Shew indicated that ITU may be co= nsidering additional tributary slot granularity in the future (in addition = to 1.25 and 2.5G). There was a concern about handling more complex combina= tions in the future. =0A= =0A= It was suggested that perhaps instead of enumerating each combination, the = TSG be treated as bit flags where the first bit could indicate 1.25G, secon= d bit indicates 2.5G, third bit and beyond (perhaps into the reserve fields= in the future) could indicate future TSG rates. The encoding could then b= e:=0A= 00 - ignored=0A= 10 - 1.25G only=0A= 01 - 2.5G only=0A= 11 - Both 1.25G and 2.5G supported=0A= =0A= This may make it easier to understand the encoding if additional TSGs are a= dded later.=0A= =0A= I realize this comment may be coming in late so you might prefer to not mak= e any changes (this is ok with me as the current encodings are technically = correct).=0A= =0A= Best Regards,=0A= Fred=0A= =0A= =0A= -----Original Message-----=0A= From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of D= aniele Ceccarelli=0A= Sent: Thursday, April 04, 2013 10:46 AM=0A= To: ccamp@ietf.org=0A= Subject: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt= =0A= =0A= Dear OTNers,=0A= =0A= Info model and OSPF drafts have been updated accordingly to the discussion = in Orlando. The OSPF draft also includes some last call comments that had n= ot been addressed in v05 and suggestions received on the list.=0A= =0A= On the other side the framework draft doesn't need any change, while the si= gnaling will be updated soon.=0A= =0A= BR=0A= Daniele, Sergio, Fatai=0A= =0A= =0A= >-----Original Message-----=0A= >From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] =0A= >On Behalf Of internet-drafts@ietf.org=0A= >Sent: gioved=EC 4 aprile 2013 17.40=0A= >To: i-d-announce@ietf.org=0A= >Cc: ccamp@ietf.org=0A= >Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt=0A= >=0A= >=0A= >A New Internet-Draft is available from the on-line =0A= >Internet-Drafts directories.=0A= > This draft is a work item of the Common Control and =0A= >Measurement Plane Working Group of the IETF.=0A= >=0A= > Title : Traffic Engineering Extensions to =0A= >OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 =0A= >OTN Networks=0A= > Author(s) : Daniele Ceccarelli=0A= > Diego Caviglia=0A= > Fatai Zhang=0A= > Dan Li=0A= > Sergio Belotti=0A= > Pietro Vittorio Grandi=0A= > Rajan Rao=0A= > Khuzema Pithewan=0A= > John E Drake=0A= > Filename : draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt=0A= > Pages : 35=0A= > Date : 2013-04-04=0A= >=0A= >Abstract:=0A= > ITU-T Recommendation G.709 [G.709-2012] has introduced new fixed and=0A= > flexible Optical Data Unit (ODU) containers, enabling optimized=0A= > support for an increasingly abundant service mix.=0A= >=0A= > This document describes Open Shortest Path First - Traffic=0A= > Engineering (OSPF-TE) routing protocol extensions to support=0A= > Generalized MPLS (GMPLS) control of all currently defined ODU=0A= > containers, in support of both sub-lambda and lambda level routing=0A= > granularity.=0A= >=0A= >=0A= >The IETF datatracker status page for this draft is:=0A= >https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-ospf-g709v3=0A= >=0A= >There's also a htmlized version available at:=0A= >http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-06=0A= >=0A= >A diff from the previous version is available at:=0A= >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-gmpls-ospf-g709v3-06= =0A= >=0A= >=0A= >Internet-Drafts are also available by anonymous FTP at:=0A= >ftp://ftp.ietf.org/internet-drafts/=0A= >=0A= >_______________________________________________=0A= >CCAMP mailing list=0A= >CCAMP@ietf.org=0A= >https://www.ietf.org/mailman/listinfo/ccamp=0A= >=0A= _______________________________________________=0A= CCAMP mailing list=0A= CCAMP@ietf.org=0A= https://www.ietf.org/mailman/listinfo/ccamp= From kpithewan@infinera.com Wed Apr 17 04:18:43 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F5E21F890D for ; Wed, 17 Apr 2013 04:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=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 Vp-a6PknepQN for ; Wed, 17 Apr 2013 04:18:33 -0700 (PDT) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id E273F21F862A for ; Wed, 17 Apr 2013 04:18:32 -0700 (PDT) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.02.0342.003; Wed, 17 Apr 2013 04:18:32 -0700 From: Khuzema Pithewan To: Igor Bryskin , Vishnu Pavan Beeram Thread-Topic: [CCAMP] MELGs - Q&A Thread-Index: AQHOIGPek8R0zdnmbUizkEjN3z7415ivh4owgAA2TQCAATLDIIAAeV3g///IfQCABM8nkIABeO8AgAELY4CAGhSNwIAAhvCAgAAQMoD//6fVoIAAemEA//+PR9AAEKirAAANdD1g//+2wYD//LZZoIAH3AeA//9AGeCAAjI5gP//HdIQ Date: Wed, 17 Apr 2013 11:18:31 +0000 Message-ID: References: <5150C704.2040007@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: multipart/alternative; boundary="_000_D8D01B39D6B38C45AA37C06ECC1D65D53FCF0FC4SVEXDBPROD1infi_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] MELGs - Q&A X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 11:18:43 -0000 --_000_D8D01B39D6B38C45AA37C06ECC1D65D53FCF0FC4SVEXDBPROD1infi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Igor and Pavan, Thanks for the discussion. I understand MELG proposal is not really precluding non-WDM server layer. I= am trying to see, will it solve similar issues if they are there in more d= ynamic OTN (TDM) server layer. MELG seems to be made useful by quite a bit of mgmt provisioning w.r.t. VLs= and its path in server layer. It is one way, a client layer can make use = of server layer resource information (for path computation). However, is it= the typical way? I am not sure. Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Tuesday, April 16, 2013 7:50 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Please, see in line. From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Tuesday, April 16, 2013 7:08 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, I am trying to summarize the discussion we had so far. Pls see if my conclu= sion is in sync with the idea of MELG you have MELG is useful when 1. server layer VLs are nailed down for the resources on the server l= ayer links that are shared among multiple VLs. IB>> Correction: server layer link-level paths supporting *client layer* VL= s are nailed down. The resources of said paths are sharable between the pat= hs (and hence VLs) but not available for anything else. These resources are typically wavelength on a fiber (can it be anything els= e??). IB>> Server layer does not have to be WDM In other words, if 2 VLs are pinned to use a particular wavelength on a par= ticular fiber, then these 2 VLs will have MELG for the wavelength. IB>> Correction: Wavelength is not the only type of resource that is used i= n WDM layer. If two paths use the same transponder, converter, regenerator,= etc. then corresponding VLs have a MELG in common. If two paths have a WDM= link in common on which they *must* use the same wavelength (e.g. because = the paths are started on fixed transponders of the same frequency), then th= ey also have an MELG in common. If two paths have to use the same wavelengt= h on a common WDM link because this is the only wavelength available at the= moment, then the VLs *do not* have an MELG in common (just usual lack of = resources on the link) 2. server layer do not have centralized path computation entity which= can be used by client layer to ask for concurrent diverse path computation= within server layer. IB>> This approach has nothing to do with VLs. VLs (just like real links) a= re supposed to be pre-planned in a different time frame from when client la= yer connections are set up. When VLs are advertised, this means that the se= rver layer paths are successfully computed and pinned already (btw by serve= r layer path computer). Asking server layer path computation dynamically do= es not guarantee any success, so, if it fails, what to do next? You cannot= orchestrate any restoration schemes in the client layer this way. Instaed,= we suggest solid as_good_as_real Virtual Topology to use. 3. Client layer has a centralized path computation entity, which woul= d compute paths for client+server layer. IB>> Correction: only for client layer, based on client layer VLs 4. The need is to centralized concurrent computation of more than one= client+server layer path that meets some diversity and resource exclusivit= y requirements. IB>> Correction: there is a need for concurrent path computation in the cli= ent layer and because the client layer topology is virtual, you need MELGs = to consider Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Monday, April 15, 2013 9:44 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Please, see in-line. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Monday, April 15, 2013 12:05 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, I understand the SRLG and MELG behavior you have penned . My concern was little different. With changing resource consumption (becau= se of dynamicity the network has) in the network links, potential paths a s= et of virtual link can take will change and hence its MELG, as it is tied t= o a resource it can take. So unless virtual links paths are nailed down, it= would be hard to compute MELGs in distributed way. IB>> I think you are missing the point here. Virtual Link server layer path= s are pinned as far as fate sharing is concerned (that is, they are pinned = on server layer link level). It would make little sense to advertise VL SR= LGs if the SRLGs constantly change. The same is true for MELGs. SRLGs/MELG= s advertised for VLs normally do not change: neither over time nor when VLs= become committed/uncommitted. Another point is, virtual links can be viewed as oversubscription of resour= ces (in MELG context). Taking an example (for OTN, I know it would work dif= ferently for a Wavelength in WDM), a link resources are worth 1 TB of BW, u= ser has provisioned 20 virtual links of 100G each going via that OTN link. = Physically, only 10 will get committed. But which 10? It will really depen= d on network dynamics at the time of demand to commit. MELGs are not that e= ffective here. You need some different mechanism. IB>> As I mentioned before MELGs have nothing to do with bandwidth and were= never intended to solve the problems such as you describe (just like it wo= uld not make much sense to solve such problem with SRLGs :=3D) Again, MELG is an extreme case SRLG designed exclusively for VLs (no more = and no less). Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 11:55 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Think about MELG as an SRLG that is shared between two or more links in its= entirety. When two real links have an SRLG in common, it means that two re= al links can co-exist concurrently, but there is something (e.g. common con= duit, note that the conduit has room for more than for one link) that will = bring both these links down, if this something fails (e.g. conduit is cut )= . Now consider that this something must be taken in its entirety by one of = the links to become operational . In this case SRLG becomes MELG. Note that= MELG is only meaningful for virtual links (unlike SRLG that makes sense fo= r either real or virtual link). Why would you advertise two links that mutu= ally exclude each other rather than advertising only one of them at a time,= unless the two are virtual links and hence both available for the client l= ayer connections? Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 1:01 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Do you mean, if virtual link do not have any specific constraint, for examp= le a link in the path (not talking about egress links/interfaces) must be t= raversed to realize the virtual link, there wont be any MELG for the virtua= l link? Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 9:52 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, MELGs have nothing to do with bandwidth. MELG is a concrete network resourc= e in a server layer that two or more Virtual Links in a client layer depend= on in a mutually exclusive way. An example of MELG is a WDM layer transpon= der that can terminate either of respective WDM layer tunnels (but not both= at the same time) for two OTN layer Virtual Links. If you advertise a Virt= ual Link, say, for Ethernet layer that depends on the connection in OTN lay= er going through one of the mentioned OTN links, the Ethernet VL must inher= it the MELG similarly like it does SRLGs advertised for the OTN links. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 12:06 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, For multi-layer (more than 2) network, consider all the layers are meshy (t= hat's when virtual links are useful anyway), MELGs of virtual link will cha= nge as and when BW/wavelength availability changes, because potential paths= , a virtual link can take will change. Mapping lower layer MELGs to higher = layer MELGs won't be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all= the risk and paths (a PCE?), which can be utilized for layer specific path= computation (as it is doing it anyway). This kind of architecture has all the pieces that are required for Inter-PC= E communication (across layers), except the protocol that would actually ma= ke the 2 PCEs talk. You seem to be doing something that you don't like :) Regards Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 8:39 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, I am not a fan of inter-layer path computations (nor I am a fan of inter-PC= E computations). In my mind path computation for a service or services in l= ayer X is performed only in layer X, i.e. considers only X layer links (rea= l or virtual). As Pavan mentioned SRLGs and MELGs that need to be inherited= from lower layers should be translated into X layer link SRLGs/MELGs and s= pecified with X layer specific SRLG/MELG IDs. Cheers, Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 10:55 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Ok. This would be useful if network architecture is based on external PCE o= r mgmt entity as PCE in client layer, but there is no counterpart in server= layer, otherwise one could have inter-PCE communication to achieve diverse= path in server layer without getting into virtual link and MELG stuff. Is that correct? Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 6:36 PM To: Vishnu Pavan Beeram; Khuzema Pithewan Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. Well, when an ingress node is initiating a service, it is doing so on reque= st from some management entity. This management entity can compute paths fo= r many services with some global criteria in mind, and then specify the res= ulting paths as explicit EROs in provisioning requests sent to each of the = service ingresses. How else, for example, you can set up several services = originated from different nodes that are disjoint from each other? Also, wh= at is the point in your opinion of the statefull PCE work? Cheers, Igor From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, April 12, 2013 8:08 AM To: Khuzema Pithewan Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Khuzema, Hi! Please see inline.. 1. When Network has more than 2 layer i.e. Packet-OTN-DWDM, the Pack= et (client) layer will be talking to its immediate server layer i.e. OTN, w= hich in turn is talking to DWDM layer. Using MELG, client layer path comput= ation can take care of resource exclusivity of virtual link for immediate s= erver layer i.e. OTN layer. However if there is resource exclusivity at DW= DM layer, this mechanism doesn't work. You need to do loose routing or use = distributed PCE model [VPB] The behavior is the same as what you would do with SRLGs in a multi-l= ayer architecture. There are architectures that allow the SRLGs in the lowe= st layer to be exported all the way up to the highest layer. The expectatio= n is that MELGs would be treated in the same vein. 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. [VPB] I'm not sure why you think there is no point in having a centralized= computation function compute paths concurrently for LSPs with different se= t of end-points. Even your NMS/planning-software can interact with such com= putation engine, retrieve all the paths and then go about initiating the pa= th-setup from the ingress of each LSP. Regards, -Pavan From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Igor Bryskin Sent: Tuesday, March 26, 2013 7:19 PM To: Dieter Beller; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Dieter, You said: >> I guess we are coming back to the essential point: "and how often concur= rent path computation will be >> used." To be honest, this surprises me quite a bit, Let me give you some of many r= easons as to why concurrent path computations are needed and why this is be= tter than computing one path at a time: 1. Computing several diverse paths for the same service in the context= of service recovery. I hope you realize that computing one path at a time = on many configurations produces no or sub-optimal results. I also hope you = realize the problem of selecting two paths with one of them having a link = with common MELG with a link from another path; 2. Computing paths for multiple services to be sufficiently disjoint f= rom each other; 3. Computing paths for multiple services to achieve a global optimizat= ion criteria (e.g. minimal summary total cost); 4. Computing paths for multiple services for the purpose of removing t= he bandwidth fragmentations; 5. Computing paths for multiple services to plan shared mesh protectio= n/restoration schemes 6. Etc. Also think about this: 1. If concurrent path computation was not important, why PCEP includes= the machinery to do that? 2. My understanding of the statefull PCE is that it does pretty much n= othing but concurrent path computations You also said: >> I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the >> TE-DB, MELG routing extensions are not needed because the information ab= out mutual >>exclusive VLs can be kept in the central TE-DB when VLs are configured. How this logic does not apply to other link attributes such as SRLGs? What if path computation is not centralized? Cheers, Igor From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Dieter Beller Sent: Monday, March 25, 2013 5:52 PM To: Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Hi Pavan, On 25.03.2013 07:29, Fatai Zhang wrote: Hi Pavan, I am not sure how much VL (Virtual Link) will be used in the practical depl= oyment and how often concurrent path computation will be used. I guess we are coming back to the essential point: "and how often concurren= t path computation will be used." This means we are trying to figure out under which conditions MELG routing = extensions could be beneficial. IMHO, they would only make sense, if: * a path computation function supports the calculation of k shortest pa= ths concurrently * if there is only a single path computation function instance per doma= in (pce approach) If path computation is done in a distributed fashion the benefit goes away = because the instances calculate paths independently! I suppose that if a pce approach is used, i.e., path computation is central= ized including the TE-DB, MELG routing extensions are not needed because the information about= mutual exclusive VLs can be kept in the central TE-DB when VLs are configured. Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their applicability is broader. Thanks, Dieter Do you think if it makes sense to add a flag (in routing advertisement) to = indicate a link is a VL or not? Best Regards Fatai From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, March 22, 2013 8:57 PM To: Fatai Zhang Cc: Igor Bryskin; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Fatai, Hi! Good to see that you understand the construct now. This is not a corner case. The utility of the construct becomes quite signi= ficant if you have an application that does concurrent path computations on= an abstract topology. Regards, -Pavan _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp -- DIETER BELLER ALCATEL-LUCENT DEUTSCHLAND AG PROJECT MANAGER ASON/GMPLS CONTROL PLANE CORE NETWORKS BUSINESS DIVISION OPTICS BU, SWITCHING R&D Lorenzstrasse 10 70435 Stuttgart, Germany Phone: +49 711 821 43125 Mobil: +49 175 7266874 Dieter.Beller@alcatel-lucent.com Alcatel-Lucent Deutschland AG Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026 Chairman of the Supervisory Board: Michael Oppenhoff Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe --_000_D8D01B39D6B38C45AA37C06ECC1D65D53FCF0FC4SVEXDBPROD1infi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Igor and Pavan,

 <= /p>

Thanks for the discussion= .

 <= /p>

I understand MELG proposa= l is not really precluding non-WDM server layer. I am trying to see, will i= t solve similar issues if they are there in more dynamic OTN (TDM) server layer.

 <= /p>

MELG seems to be made use= ful by quite a bit of mgmt provisioning w.r.t. VLs and its path in server l= ayer.  It is one way, a client layer can make use of server layer resource information (for path computation). However, is it the typi= cal way?  I am not sure.

 <= /p>

Regds

Khuzema=

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptical.com]
Sent: Tuesday, April 16, 2013 7:50 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

Please, see in line.=

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infinera.com]
Sent: Tuesday, April 16, 2013 7:08 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

I am trying to summarize = the discussion we had so far. Pls see if my conclusion is in sync with the = idea of MELG you have

 <= /p>

MELG is useful when<= /o:p>

1. = ;      server layer VLs = are nailed down for the resources on the server layer links that are shared= among multiple VLs.

IB>> Correction: se= rver layer link-level paths supporting *client layer* VLs are nailed= down. The resources of said paths are sharable between the paths (and hence VLs) but not available for anything else.

 <= /p>

IB>> Server layer d= oes not have to be WDM

 <= /p>

IB>> Correction: Wa= velength is not the only type of resource that is used in WDM layer. If two= paths use the same transponder, converter, regenerator, etc. then corresponding VLs have a MELG in common. If two paths have a WDM link= in common on which they *must* use the same wavelength (e.g. becaus= e the paths are started on fixed transponders of the same frequency), then = they also have an MELG in common. If two paths have to use the same wavelength on a common WDM link because = this is the only wavelength available at the moment, then the VLs *do no= t* have an MELG in common (just  usual lack of resources on the li= nk)

 <= /p>

2. = ;      server layer do n= ot have centralized path computation entity which can be used by client lay= er to ask for concurrent diverse path computation within server layer.

IB>> This approach = has nothing to do with VLs. VLs (just like real links) are supposed to be p= re-planned in a different time frame from when client layer connections are set up. When VLs are advertised, this means that the server layer path= s are successfully computed and pinned already (btw by server layer path co= mputer). Asking server layer path computation dynamically does not guarante= e  any success, so, if it fails, what to do next? You cannot orchestrate any restoration schemes in the cli= ent layer this way. Instaed, we suggest solid as_good_as_real Virtual Topol= ogy to use.

 <= /p>

3. = ;      Client layer has = a centralized path computation entity, which would compute paths for client= +server layer.

IB>> Correction: on= ly for client layer, based on client layer VLs

4. = ;      The need is to ce= ntralized concurrent computation of more than one client+server layer p= ath that meets some diversity and resource exclusivity requirements.

IB>> Correction: th= ere is a need for concurrent path computation in the client layer and becau= se the client layer topology is virtual, you need MELGs to consider

 <= /p>

Regds

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Monday, April 15, 2013 9:44 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

Please, see in-line.=

 <= /p>

Igor

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Monday, April 15, 2013 12:05 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

I understand the SRLG and= MELG behavior you have penned .

 <= /p>

My concern was little dif= ferent.  With changing resource consumption (because of dynamicity the= network has) in the network links, potential paths a set of virtual link can take will change and hence its MELG, as it is tied to a r= esource it can take. So unless virtual links paths are nailed down, it woul= d be hard to compute MELGs in distributed way.

 <= /p>

IB>> I think you ar= e missing the point here. Virtual Link server layer paths are pinned as far= as fate sharing is concerned (that is, they are pinned on  server layer link level). It would make little sense to advertise VL SRLGs if the= SRLGs constantly change. The same is true for MELGs.  SRLGs/MELGs adv= ertised for VLs normally do not change: neither over time nor when VLs beco= me committed/uncommitted.

 <= /p>

Another point is, virtual= links can be viewed as oversubscription of resources (in MELG context). Ta= king an example (for OTN, I know it would work differently for a Wavelength in WDM), a link resources are worth 1 TB of BW, user has = provisioned 20 virtual links of 100G each going via that OTN link.  Ph= ysically, only 10 will get committed. But which 10? It will really depend o= n network dynamics at the time of demand to commit. MELGs are not that effective here. You need some different mech= anism.

 <= /p>

IB>> As I mentioned= before MELGs have nothing to do with bandwidth and were never intended to = solve the problems such as you describe (just like it would not make much sense to solve such problem with SRLGs :=3D)

Again,  MELG is an e= xtreme case SRLG designed exclusively for VLs (no more and no less).

 <= /p>

Regds

Khuzema=

 <= /p>

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 11:55 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

Think about MELG as an SR= LG that is shared between two or more links in its entirety. When two real = links have an SRLG in common, it means that two real links can co-exist concurrently, but there is something (e.g. common conduit, no= te that the conduit has room for more than for one link) that will bring bo= th these links down, if this something fails (e.g. conduit is cut ). Now co= nsider that this something must be taken in its entirety by one of the links to become operational . In th= is case SRLG becomes MELG. Note that MELG is only meaningful for virtual li= nks (unlike SRLG that makes sense for either real or virtual link). Why wou= ld you advertise two links that mutually exclude each other rather than advertising only one of them at a = time, unless the two are virtual links and hence both available for the cli= ent layer connections?

 <= /p>

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Friday, April 12, 2013 1:01 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

Do you mean, if virtual l= ink do not have any specific constraint, for example a link in the path (no= t talking about egress links/interfaces) must be traversed to realize the virtual link, there wont be any MELG for the virtual link?<= o:p>

 <= /p>

Regds

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 9:52 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

MELGs have nothing to do = with bandwidth. MELG is a concrete network resource in a server layer that = two or more Virtual Links in a client layer depend on in a mutually exclusive way. An example of MELG is a WDM layer transponder th= at can terminate either of respective WDM layer tunnels (but not both at th= e same time) for two OTN layer Virtual Links. If you advertise a Virtual Li= nk, say, for Ethernet layer that depends on the connection in OTN layer going through one of the mentioned = OTN links, the Ethernet VL must inherit the MELG similarly like it does SRL= Gs advertised for the OTN links.

 <= /p>

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Friday, April 12, 2013 12:06 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

For multi-layer (more tha= n 2) network, consider all the layers are meshy (that’s when virtual = links are useful anyway), MELGs of virtual link will change as and when BW/wavelength availability changes, because potential paths, a vi= rtual link can take will change. Mapping lower layer MELGs to higher layer = MELGs won’t be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all the risk and paths (a PCE?), which ca= n be utilized for layer specific path computation (as it is doing it anyway= ).

 <= /p>

This kind of architecture= has all the pieces that are required for Inter-PCE communication (across l= ayers), except the protocol that would actually make the 2 PCEs talk.

 <= /p>

You seem to be doing some= thing that you don’t like J

 <= /p>

Regards=

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 8:39 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

I am not a fan of inter-l= ayer path computations (nor I am a fan of inter-PCE computations). In my mi= nd path computation for a service or services in layer X is performed only in layer X, i.e. considers only X layer links (real or v= irtual). As Pavan mentioned SRLGs and MELGs that need to be inherited from = lower layers should be translated into X layer link SRLGs/MELGs and specifi= ed with X layer specific SRLG/MELG IDs.

 <= /p>

Cheers,=

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Friday, April 12, 2013 10:55 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

Ok. This would be useful = if network architecture is based on external PCE or mgmt entity as PCE in c= lient layer, but there is no counterpart in server layer, otherwise one could have inter-PCE communication to achieve diverse path i= n server layer without getting into virtual link and MELG stuff.

 <= /p>

Is that correct?

 <= /p>

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 6:36 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

2.       For cases of concurrent computation (case= #2-5), you are mainly talking about global optimization and diversity among= multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from th= e source end of those LSPs.  So there is no point in doing concurrent = computation at one network element for the services starting from multiple = network elements. At best it looks to me a problem to be solved by network management/planning software.&= nbsp;

Well, when an ingress nod= e is initiating a service, it is doing so on request from some management e= ntity. This management entity can compute paths for many services with some global criteria in mind, and then specify the resulting= paths as explicit EROs in provisioning requests sent to each of the servic= e ingresses. How else, for example,  you can set up several services o= riginated from different nodes that are disjoint from each other? Also, what is the point in your opinion of the s= tatefull PCE work?

 <= /p>

Cheers,=

Igor

 <= /p>

From: Vishnu P= avan Beeram [mailto:vishnupavan@gm= ail.com]
Sent: Friday, April 12, 2013 8:08 AM
To: Khuzema Pithewan
Cc: Igor Bryskin; Dieter Beller; c= camp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Khuzema, Hi!


Please see inline..

 

 

 1.       When Network has more than 2 layer i.e. P= acket-OTN-DWDM, the Packet (client) layer will be talking to its immediate = server layer i.e. OTN, which in turn is talking to DWDM layer. Using MELG, client layer path computation can take care of resource= exclusivity of virtual link for immediate server layer i.e. OTN layer.&nbs= p; However if there is resource exclusivity at DWDM layer, this mechanism d= oesn’t work. You need to do loose routing or use distributed PCE model

 

[VPB] The behavior is the same as what you would do = with SRLGs in a multi-layer architecture. There are architectures that allo= w the SRLGs in the lowest layer to be exported all the way up to the highes= t layer. The expectation is that MELGs would be treated in the same vein. 

2.       For cases of concurrent computation (case= #2-5), you are mainly talking about global optimization and diversity among= multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from th= e source end of those LSPs.  So there is no point in doing concurrent = computation at one network element for the services starting from multiple = network elements. At best it looks to me a problem to be solved by network management/planning software.&= nbsp;

[VPB]  I'm not sure why you think there is no p= oint in having a centralized computation function compute paths concurrentl= y for LSPs with different set of end-points. Even your NMS/planning-softwar= e can interact with such computation engine, retrieve all the paths and then go about initiating the path-setup from th= e ingress of each LSP. 

 

Regards,

-Pavan

 

 

 

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Tuesday, March 26, 2013 7:19 PM
To: Dieter Beller; Vishnu Pavan Beeram


Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Dieter,

 

You said:

>> I guess we are coming back to the essential point: "= and how often concurrent path computation will be >> used."

 

To be honest, this surprises me quite a bit, Let me give you some = of many reasons as to why concurrent path computations are needed and why t= his is better than computing one path at a time:

 

1.      = Computing several diverse paths for the same service in the context of serv= ice recovery. I hope you realize that computing one path at a time on many = configurations produces no or sub-optimal results. I also hope you realize the problem of selecting two paths with one of them  havi= ng a link with common MELG with a link from another path;

2.      = Computing paths for multiple services to be sufficiently disjoint from each= other;

3.      = Computing paths for multiple services to achieve a global optimization crit= eria (e.g. minimal summary total cost);

4.      = Computing paths for multiple services for the purpose of removing the bandw= idth fragmentations;

5.      = Computing paths for multiple services to plan shared mesh protection/restor= ation schemes

6.      = Etc.

 

Also think about this:

1.      = If concurrent path computation was not important, why PCEP includes the mac= hinery to do that?

2.      = My understanding of the statefull PCE is that it does pretty much nothing b= ut concurrent path computations

 

You also said:

>> I suppose that if a pce approach is used, i.e., path computatio= n is centralized including the
>> TE-DB, MELG routing extensions are not needed because the informat= ion about mutual
>>exclusive VLs can be kept in the central TE-DB when VLs are configu= red.

How this logic does not apply to other link attributes such as SRL= Gs?

What if path computation is not centralized?

 

Cheers,

Igor

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Hi Pavan,

On 25.03.2013 07:29, Fat= ai Zhang wrote:

Hi Pavan,

 

I am not sure how much VL (Virtual Link= ) will be used in the practical deployment and how often concurrent path computation will be used.

I guess we are coming back to the essential point: "and how often concurrent path computation will be used."

This means we are trying to figure out under which conditions MELG routing = extensions
could be beneficial.

IMHO, they would only make sense, if:

  • a path computation function supports the calculation of k shortest paths co= ncurrently
  • if there is only a single path computation function instance per domain (pc= e approach)
    If path computation is done in a distributed fashion the benefit goes away = because
    the instances calculate paths independently!

I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the
TE-DB, MELG routing extensions are not needed because the information about= mutual
exclusive VLs can be kept in the central TE-DB when VLs are configured.

Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their
applicability is broader.


Thanks,
Dieter

 

Do you think if it makes sense to add a flag (in= routing advertisement) to indicate a link is a VL or not?

 

 

 

Best Regards

 

Fatai

 

From: Vishnu Pavan Beeram [<= a href=3D"mailto:vishnupavan@gmail.com" target=3D"_blank">mailto:vishnupava= n@gmail.com]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Fatai, Hi!

 

Good to see that you understand the construct now.

 

This is not a corner case. The utility of the construct becomes qu= ite significant if you have an application that does concurrent path comput= ations on an abstract topology.

 

Regards,

-Pavan

 

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org=

https://www.ietf.org/mailman/listinfo/ccamp

 

--

DIETER BELLER

ALCATEL-LUCENT DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 = 711 821 43125
Mobil: +49 175 = 7266874

 

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe

 

--_000_D8D01B39D6B38C45AA37C06ECC1D65D53FCF0FC4SVEXDBPROD1infi_-- From jdrake@juniper.net Wed Apr 17 04:46:05 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00B721F8D6A for ; Wed, 17 Apr 2013 04:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 UVrfZRuz2tCm for ; Wed, 17 Apr 2013 04:46:03 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0A621F8CE8 for ; Wed, 17 Apr 2013 04:46:03 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUW6LepDpaFPWlsI1VBXhbNqt/Wg0w9rZ@postini.com; Wed, 17 Apr 2013 04:46:03 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 17 Apr 2013 04:44:49 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Wed, 17 Apr 2013 04:44:48 -0700 Received: from db9outboundpool.messaging.microsoft.com (213.199.154.246) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 17 Apr 2013 04:48:03 -0700 Received: from mail6-db9-R.bigfish.com (10.174.16.241) by DB9EHSOBE003.bigfish.com (10.174.14.66) with Microsoft SMTP Server id 14.1.225.23; Wed, 17 Apr 2013 11:44:46 +0000 Received: from mail6-db9 (localhost [127.0.0.1]) by mail6-db9-R.bigfish.com (Postfix) with ESMTP id A76A46000A4 for ; Wed, 17 Apr 2013 11:44:46 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -26 X-BigFish: PS-26(zz9371Ic89bh936eI148cI542I1432I111aIzz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h) Received: from mail6-db9 (localhost.localdomain [127.0.0.1]) by mail6-db9 (MessageSwitch) id 1366199085162397_25084; Wed, 17 Apr 2013 11:44:45 +0000 (UTC) Received: from DB9EHSMHS006.bigfish.com (unknown [10.174.16.241]) by mail6-db9.bigfish.com (Postfix) with ESMTP id 2403B1C0044; Wed, 17 Apr 2013 11:44:45 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS006.bigfish.com (10.174.14.16) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 17 Apr 2013 11:44:44 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.181]) by BL2PRD0510HT002.namprd05.prod.outlook.com ([10.255.100.37]) with mapi id 14.16.0293.003; Wed, 17 Apr 2013 11:44:36 +0000 From: John E Drake To: Daniele Ceccarelli , "fred.gruman@us.fujitsu.com" Thread-Topic: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt Thread-Index: Ac47BbOWqrw6KEYeXEevrzCZSajLdgAWuz+w Date: Wed, 17 Apr 2013 11:44:36 +0000 Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E1D4A5428@BL2PRD0510MB349.namprd05.prod.outlook.com> References: <4A1562797D64E44993C5CBF38CF1BE480AEC6B@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE480AEC6B@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.53] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ERICSSON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%US.FUJITSU.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 11:46:05 -0000 Fred, Other than to demonstrate it is always possible to add additional complexit= y to OTN, is there any reason to add additional TSG values? Irrespectively Yours, John > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Daniele Ceccarelli > Sent: Tuesday, April 16, 2013 5:52 PM > To: fred.gruman@us.fujitsu.com > Cc: ccamp@ietf.org > Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-ospf- > g709v3-06.txt >=20 > Hi Fred, >=20 > Thanks again for the suggestions. No worries, if this is a change that > makes sense we can fix it before the second last call. >=20 > Just wanted a clarification (more loud thinking than a question): do > you think that an interface might support different TSGs at the same > time? If the answer is yes the bitmap makes sense, otherwise an enum > would be more bits-saving. > I would say that until no LSP is configured it is possible to > advertise/support multiple of them (e.g. The newest one plus the ones > it is possible to rollback to for backward compatibility issues) and > then, after the instantiation of the first LSP, a single one. >=20 > Best regards > Daniele >=20 > *** E-mail via DME powered by mobile broadband *** >=20 > --Original message--- > Sender: "Gruman, Fred" Sent time: > 14/apr/2013 09:02 > To: daniele.ceccarelli@ericsson.com, ccamp@ietf.org > Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-ospf- > g709v3-06.txt >=20 > Hi Daniele, >=20 > Thanks for making the update to the TSG examples in Section 5.2 >=20 > I have a one additional comments regarding TSG: >=20 > 1) during an OIF conference call, Stephen Shew indicated that ITU may > be considering additional tributary slot granularity in the future (in > addition to 1.25 and 2.5G). There was a concern about handling more > complex combinations in the future. >=20 > It was suggested that perhaps instead of enumerating each combination, > the TSG be treated as bit flags where the first bit could indicate > 1.25G, second bit indicates 2.5G, third bit and beyond (perhaps into > the reserve fields in the future) could indicate future TSG rates. The > encoding could then be: > 00 - ignored > 10 - 1.25G only > 01 - 2.5G only > 11 - Both 1.25G and 2.5G supported >=20 > This may make it easier to understand the encoding if additional TSGs > are added later. >=20 > I realize this comment may be coming in late so you might prefer to not > make any changes (this is ok with me as the current encodings are > technically correct). >=20 > Best Regards, > Fred >=20 >=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Daniele Ceccarelli > Sent: Thursday, April 04, 2013 10:46 AM > To: ccamp@ietf.org > Subject: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3- > 06.txt >=20 > Dear OTNers, >=20 > Info model and OSPF drafts have been updated accordingly to the > discussion in Orlando. The OSPF draft also includes some last call > comments that had not been addressed in v05 and suggestions received on > the list. >=20 > On the other side the framework draft doesn't need any change, while > the signaling will be updated soon. >=20 > BR > Daniele, Sergio, Fatai >=20 >=20 > >-----Original Message----- > >From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > >Of internet-drafts@ietf.org > >Sent: gioved=EC 4 aprile 2013 17.40 > >To: i-d-announce@ietf.org > >Cc: ccamp@ietf.org > >Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-06.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 : Traffic Engineering Extensions to > >OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN > >Networks > > Author(s) : Daniele Ceccarelli > > Diego Caviglia > > Fatai Zhang > > Dan Li > > Sergio Belotti > > Pietro Vittorio Grandi > > Rajan Rao > > Khuzema Pithewan > > John E Drake > > Filename : draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt > > Pages : 35 > > Date : 2013-04-04 > > > >Abstract: > > ITU-T Recommendation G.709 [G.709-2012] has introduced new fixed > and > > flexible Optical Data Unit (ODU) containers, enabling optimized > > support for an increasingly abundant service mix. > > > > This document describes Open Shortest Path First - Traffic > > Engineering (OSPF-TE) routing protocol extensions to support > > Generalized MPLS (GMPLS) control of all currently defined ODU > > containers, in support of both sub-lambda and lambda level routing > > granularity. > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-ospf-g709v3 > > > >There's also a htmlized version available at: > >http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-06 > > > >A diff from the previous version is available at: > >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-gmpls-ospf-g709v3-06 > > > > > >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 From jdrake@juniper.net Wed Apr 17 05:44:45 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D02E21E8055 for ; Wed, 17 Apr 2013 05:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.121 X-Spam-Level: X-Spam-Status: No, score=-3.121 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 qviQE5SroZO7 for ; Wed, 17 Apr 2013 05:44:33 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id C482C21F8E49 for ; Wed, 17 Apr 2013 05:44:24 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUW6ZKNRnWpzWB4ZDJcm9d2Zi2WdBA6DD@postini.com; Wed, 17 Apr 2013 05:44:24 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 17 Apr 2013 05:43:06 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 17 Apr 2013 05:43:05 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.186) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 17 Apr 2013 05:52:58 -0700 Received: from mail10-co1-R.bigfish.com (10.243.78.241) by CO1EHSOBE013.bigfish.com (10.243.66.76) with Microsoft SMTP Server id 14.1.225.23; Wed, 17 Apr 2013 12:43:04 +0000 Received: from mail10-co1 (localhost [127.0.0.1]) by mail10-co1-R.bigfish.com (Postfix) with ESMTP id E48B6680548 for ; Wed, 17 Apr 2013 12:43:04 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -26 X-BigFish: PS-26(zz98dI9371Ic89bh1102Ic85dh1432I4015I1447Idb82hzz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz1033IL17326ah18c673h8275bh8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1155h) Received: from mail10-co1 (localhost.localdomain [127.0.0.1]) by mail10-co1 (MessageSwitch) id 1366202579784793_28458; Wed, 17 Apr 2013 12:42:59 +0000 (UTC) Received: from CO1EHSMHS025.bigfish.com (unknown [10.243.78.231]) by mail10-co1.bigfish.com (Postfix) with ESMTP id BC93B4A0048; Wed, 17 Apr 2013 12:42:59 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS025.bigfish.com (10.243.66.35) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 17 Apr 2013 12:42:59 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.181]) by BL2PRD0510HT004.namprd05.prod.outlook.com ([10.255.100.39]) with mapi id 14.16.0293.003; Wed, 17 Apr 2013 12:42:57 +0000 From: John E Drake To: Khuzema Pithewan , Igor Bryskin , Vishnu Pavan Beeram Thread-Topic: [CCAMP] MELGs - Q&A Thread-Index: AQHOIGPc5sNnbY0M9EO2ehkIVZ0e6ZivigwAgAC55wCAALCOgIAAeAqAgABMBQCABErLAIABAdYAgAELY4CAGovgAIAAD52AgAAQMoCAAB55gIAAA74AgAAP9gCAAASVAIAACscAgAAXnYCAA8Z9gIAAy+OAgAE80YCAADWBgIABX7KAgAAVUDA= Date: Wed, 17 Apr 2013 12:42:56 +0000 Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E1D4A5653@BL2PRD0510MB349.namprd05.prod.outlook.com> References: <5150C704.2040007@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.53] Content-Type: multipart/alternative; boundary="_000_0182DEA5604B3A44A2EE61F3EE3ED69E1D4A5653BL2PRD0510MB349_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%INFINERA.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ADVAOPTICAL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] MELGs - Q&A X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 12:44:45 -0000 --_000_0182DEA5604B3A44A2EE61F3EE3ED69E1D4A5653BL2PRD0510MB349_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Khuzema, Comments inline. Irrespectively Yours, John From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of K= huzema Pithewan Sent: Wednesday, April 17, 2013 4:19 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Hi Igor and Pavan, Thanks for the discussion. I understand MELG proposal is not really precluding non-WDM server layer. I= am trying to see, will it solve similar issues if they are there in more d= ynamic OTN (TDM) server layer. JD: This is a very good point. While MELGs can be used in higher layer se= rver networks, they may not have any utility in these networks because thes= e networks do not use physical resources directly. MELG seems to be made useful by quite a bit of mgmt provisioning w.r.t. VLs= and its path in server layer. It is one way, a client layer can make use = of server layer resource information (for path computation). However, is it= the typical way? I am not sure. JD: The draft should note that MELGs have utility only in client networks = that use centralized concurrent path computation. Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Tuesday, April 16, 2013 7:50 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Please, see in line. From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Tuesday, April 16, 2013 7:08 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, I am trying to summarize the discussion we had so far. Pls see if my conclu= sion is in sync with the idea of MELG you have MELG is useful when 1. server layer VLs are nailed down for the resources on the server l= ayer links that are shared among multiple VLs. IB>> Correction: server layer link-level paths supporting *client layer* VL= s are nailed down. The resources of said paths are sharable between the pat= hs (and hence VLs) but not available for anything else. These resources are typically wavelength on a fiber (can it be anything els= e??). IB>> Server layer does not have to be WDM In other words, if 2 VLs are pinned to use a particular wavelength on a par= ticular fiber, then these 2 VLs will have MELG for the wavelength. IB>> Correction: Wavelength is not the only type of resource that is used i= n WDM layer. If two paths use the same transponder, converter, regenerator,= etc. then corresponding VLs have a MELG in common. If two paths have a WDM= link in common on which they *must* use the same wavelength (e.g. because = the paths are started on fixed transponders of the same frequency), then th= ey also have an MELG in common. If two paths have to use the same wavelengt= h on a common WDM link because this is the only wavelength available at the= moment, then the VLs *do not* have an MELG in common (just usual lack of = resources on the link) 2. server layer do not have centralized path computation entity which= can be used by client layer to ask for concurrent diverse path computation= within server layer. IB>> This approach has nothing to do with VLs. VLs (just like real links) a= re supposed to be pre-planned in a different time frame from when client la= yer connections are set up. When VLs are advertised, this means that the se= rver layer paths are successfully computed and pinned already (btw by serve= r layer path computer). Asking server layer path computation dynamically do= es not guarantee any success, so, if it fails, what to do next? You cannot= orchestrate any restoration schemes in the client layer this way. Instaed,= we suggest solid as_good_as_real Virtual Topology to use. 3. Client layer has a centralized path computation entity, which woul= d compute paths for client+server layer. IB>> Correction: only for client layer, based on client layer VLs 4. The need is to centralized concurrent computation of more than one= client+server layer path that meets some diversity and resource exclusivit= y requirements. IB>> Correction: there is a need for concurrent path computation in the cli= ent layer and because the client layer topology is virtual, you need MELGs = to consider Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Monday, April 15, 2013 9:44 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Please, see in-line. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Monday, April 15, 2013 12:05 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, I understand the SRLG and MELG behavior you have penned . My concern was little different. With changing resource consumption (becau= se of dynamicity the network has) in the network links, potential paths a s= et of virtual link can take will change and hence its MELG, as it is tied t= o a resource it can take. So unless virtual links paths are nailed down, it= would be hard to compute MELGs in distributed way. IB>> I think you are missing the point here. Virtual Link server layer path= s are pinned as far as fate sharing is concerned (that is, they are pinned = on server layer link level). It would make little sense to advertise VL SR= LGs if the SRLGs constantly change. The same is true for MELGs. SRLGs/MELG= s advertised for VLs normally do not change: neither over time nor when VLs= become committed/uncommitted. Another point is, virtual links can be viewed as oversubscription of resour= ces (in MELG context). Taking an example (for OTN, I know it would work dif= ferently for a Wavelength in WDM), a link resources are worth 1 TB of BW, u= ser has provisioned 20 virtual links of 100G each going via that OTN link. = Physically, only 10 will get committed. But which 10? It will really depen= d on network dynamics at the time of demand to commit. MELGs are not that e= ffective here. You need some different mechanism. IB>> As I mentioned before MELGs have nothing to do with bandwidth and were= never intended to solve the problems such as you describe (just like it wo= uld not make much sense to solve such problem with SRLGs :=3D) Again, MELG is an extreme case SRLG designed exclusively for VLs (no more = and no less). Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 11:55 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Think about MELG as an SRLG that is shared between two or more links in its= entirety. When two real links have an SRLG in common, it means that two re= al links can co-exist concurrently, but there is something (e.g. common con= duit, note that the conduit has room for more than for one link) that will = bring both these links down, if this something fails (e.g. conduit is cut )= . Now consider that this something must be taken in its entirety by one of = the links to become operational . In this case SRLG becomes MELG. Note that= MELG is only meaningful for virtual links (unlike SRLG that makes sense fo= r either real or virtual link). Why would you advertise two links that mutu= ally exclude each other rather than advertising only one of them at a time,= unless the two are virtual links and hence both available for the client l= ayer connections? Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 1:01 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Do you mean, if virtual link do not have any specific constraint, for examp= le a link in the path (not talking about egress links/interfaces) must be t= raversed to realize the virtual link, there wont be any MELG for the virtua= l link? Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 9:52 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, MELGs have nothing to do with bandwidth. MELG is a concrete network resourc= e in a server layer that two or more Virtual Links in a client layer depend= on in a mutually exclusive way. An example of MELG is a WDM layer transpon= der that can terminate either of respective WDM layer tunnels (but not both= at the same time) for two OTN layer Virtual Links. If you advertise a Virt= ual Link, say, for Ethernet layer that depends on the connection in OTN lay= er going through one of the mentioned OTN links, the Ethernet VL must inher= it the MELG similarly like it does SRLGs advertised for the OTN links. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 12:06 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, For multi-layer (more than 2) network, consider all the layers are meshy (t= hat's when virtual links are useful anyway), MELGs of virtual link will cha= nge as and when BW/wavelength availability changes, because potential paths= , a virtual link can take will change. Mapping lower layer MELGs to higher = layer MELGs won't be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all= the risk and paths (a PCE?), which can be utilized for layer specific path= computation (as it is doing it anyway). This kind of architecture has all the pieces that are required for Inter-PC= E communication (across layers), except the protocol that would actually ma= ke the 2 PCEs talk. You seem to be doing something that you don't like :) Regards Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 8:39 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, I am not a fan of inter-layer path computations (nor I am a fan of inter-PC= E computations). In my mind path computation for a service or services in l= ayer X is performed only in layer X, i.e. considers only X layer links (rea= l or virtual). As Pavan mentioned SRLGs and MELGs that need to be inherited= from lower layers should be translated into X layer link SRLGs/MELGs and s= pecified with X layer specific SRLG/MELG IDs. Cheers, Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 10:55 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Ok. This would be useful if network architecture is based on external PCE o= r mgmt entity as PCE in client layer, but there is no counterpart in server= layer, otherwise one could have inter-PCE communication to achieve diverse= path in server layer without getting into virtual link and MELG stuff. Is that correct? Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 6:36 PM To: Vishnu Pavan Beeram; Khuzema Pithewan Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. Well, when an ingress node is initiating a service, it is doing so on reque= st from some management entity. This management entity can compute paths fo= r many services with some global criteria in mind, and then specify the res= ulting paths as explicit EROs in provisioning requests sent to each of the = service ingresses. How else, for example, you can set up several services = originated from different nodes that are disjoint from each other? Also, wh= at is the point in your opinion of the statefull PCE work? Cheers, Igor From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, April 12, 2013 8:08 AM To: Khuzema Pithewan Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Khuzema, Hi! Please see inline.. 1. When Network has more than 2 layer i.e. Packet-OTN-DWDM, the Pack= et (client) layer will be talking to its immediate server layer i.e. OTN, w= hich in turn is talking to DWDM layer. Using MELG, client layer path comput= ation can take care of resource exclusivity of virtual link for immediate s= erver layer i.e. OTN layer. However if there is resource exclusivity at DW= DM layer, this mechanism doesn't work. You need to do loose routing or use = distributed PCE model [VPB] The behavior is the same as what you would do with SRLGs in a multi-l= ayer architecture. There are architectures that allow the SRLGs in the lowe= st layer to be exported all the way up to the highest layer. The expectatio= n is that MELGs would be treated in the same vein. 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. [VPB] I'm not sure why you think there is no point in having a centralized= computation function compute paths concurrently for LSPs with different se= t of end-points. Even your NMS/planning-software can interact with such com= putation engine, retrieve all the paths and then go about initiating the pa= th-setup from the ingress of each LSP. Regards, -Pavan From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Igor Bryskin Sent: Tuesday, March 26, 2013 7:19 PM To: Dieter Beller; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Dieter, You said: >> I guess we are coming back to the essential point: "and how often concur= rent path computation will be >> used." To be honest, this surprises me quite a bit, Let me give you some of many r= easons as to why concurrent path computations are needed and why this is be= tter than computing one path at a time: 1. Computing several diverse paths for the same service in the context= of service recovery. I hope you realize that computing one path at a time = on many configurations produces no or sub-optimal results. I also hope you = realize the problem of selecting two paths with one of them having a link = with common MELG with a link from another path; 2. Computing paths for multiple services to be sufficiently disjoint f= rom each other; 3. Computing paths for multiple services to achieve a global optimizat= ion criteria (e.g. minimal summary total cost); 4. Computing paths for multiple services for the purpose of removing t= he bandwidth fragmentations; 5. Computing paths for multiple services to plan shared mesh protectio= n/restoration schemes 6. Etc. Also think about this: 1. If concurrent path computation was not important, why PCEP includes= the machinery to do that? 2. My understanding of the statefull PCE is that it does pretty much n= othing but concurrent path computations You also said: >> I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the >> TE-DB, MELG routing extensions are not needed because the information ab= out mutual >>exclusive VLs can be kept in the central TE-DB when VLs are configured. How this logic does not apply to other link attributes such as SRLGs? What if path computation is not centralized? Cheers, Igor From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Dieter Beller Sent: Monday, March 25, 2013 5:52 PM To: Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Hi Pavan, On 25.03.2013 07:29, Fatai Zhang wrote: Hi Pavan, I am not sure how much VL (Virtual Link) will be used in the practical depl= oyment and how often concurrent path computation will be used. I guess we are coming back to the essential point: "and how often concurren= t path computation will be used." This means we are trying to figure out under which conditions MELG routing = extensions could be beneficial. IMHO, they would only make sense, if: * a path computation function supports the calculation of k shortest pa= ths concurrently * if there is only a single path computation function instance per doma= in (pce approach) If path computation is done in a distributed fashion the benefit goes away = because the instances calculate paths independently! I suppose that if a pce approach is used, i.e., path computation is central= ized including the TE-DB, MELG routing extensions are not needed because the information about= mutual exclusive VLs can be kept in the central TE-DB when VLs are configured. Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their applicability is broader. Thanks, Dieter Do you think if it makes sense to add a flag (in routing advertisement) to = indicate a link is a VL or not? Best Regards Fatai From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, March 22, 2013 8:57 PM To: Fatai Zhang Cc: Igor Bryskin; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Fatai, Hi! Good to see that you understand the construct now. This is not a corner case. The utility of the construct becomes quite signi= ficant if you have an application that does concurrent path computations on= an abstract topology. Regards, -Pavan _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp -- DIETER BELLER ALCATEL-LUCENT DEUTSCHLAND AG PROJECT MANAGER ASON/GMPLS CONTROL PLANE CORE NETWORKS BUSINESS DIVISION OPTICS BU, SWITCHING R&D Lorenzstrasse 10 70435 Stuttgart, Germany Phone: +49 711 821 43125 Mobil: +49 175 7266874 Dieter.Beller@alcatel-lucent.com Alcatel-Lucent Deutschland AG Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026 Chairman of the Supervisory Board: Michael Oppenhoff Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe --_000_0182DEA5604B3A44A2EE61F3EE3ED69E1D4A5653BL2PRD0510MB349_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Khuzema,

 <= /p>

Comments inline.

 <= /p>

Irrespectively Yours,

 <= /p>

John

 <= /p>

From: ccamp-bo= unces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Khuzema Pithewan
Sent: Wednesday, April 17, 2013 4:19 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Hi Igor and Pavan,

 <= /p>

Thanks for the discussion= .

 <= /p>

I understand MELG proposa= l is not really precluding non-WDM server layer. I am trying to see, will i= t solve similar issues if they are there in more dynamic OTN (TDM) server layer.

 <= /p>

JD:  This is a very = good point.  While MELGs can be used in higher layer server networks, = they may not have any utility in these networks because these networks do not use physical resources directly.   

 <= /p>

MELG seems to be made use= ful by quite a bit of mgmt provisioning w.r.t. VLs and its path in server l= ayer.  It is one way, a client layer can make use of server layer resource information (for path computation). However, is it the typi= cal way?  I am not sure.

 <= /p>

JD:  The draft shoul= d note that MELGs have utility only in client networks that use centralized= concurrent path computation.

 <= /p>

Regds

Khuzema=

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Tuesday, April 16, 2013 7:50 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

Please, see in line.=

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Tuesday, April 16, 2013 7:08 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

I am trying to summarize = the discussion we had so far. Pls see if my conclusion is in sync with the = idea of MELG you have

 <= /p>

MELG is useful when<= /o:p>

1. = ;      server layer VLs = are nailed down for the resources on the server layer links that are shared= among multiple VLs.

IB>> Correction: se= rver layer link-level paths supporting *client layer* VLs are nailed= down. The resources of said paths are sharable between the paths (and hence VLs) but not available for anything else.

 <= /p>

IB>> Server layer d= oes not have to be WDM

 <= /p>

IB>> Correction: Wa= velength is not the only type of resource that is used in WDM layer. If two= paths use the same transponder, converter, regenerator, etc. then corresponding VLs have a MELG in common. If two paths have a WDM link= in common on which they *must* use the same wavelength (e.g. becaus= e the paths are started on fixed transponders of the same frequency), then = they also have an MELG in common. If two paths have to use the same wavelength on a common WDM link because = this is the only wavelength available at the moment, then the VLs *do no= t* have an MELG in common (just  usual lack of resources on the li= nk)

 <= /p>

2. = ;      server layer do n= ot have centralized path computation entity which can be used by client lay= er to ask for concurrent diverse path computation within server layer.

IB>> This approach = has nothing to do with VLs. VLs (just like real links) are supposed to be p= re-planned in a different time frame from when client layer connections are set up. When VLs are advertised, this means that the server layer path= s are successfully computed and pinned already (btw by server layer path co= mputer). Asking server layer path computation dynamically does not guarante= e  any success, so, if it fails, what to do next? You cannot orchestrate any restoration schemes in the cli= ent layer this way. Instaed, we suggest solid as_good_as_real Virtual Topol= ogy to use.

 <= /p>

3. = ;      Client layer has = a centralized path computation entity, which would compute paths for client= +server layer.

IB>> Correction: on= ly for client layer, based on client layer VLs

4. = ;      The need is to ce= ntralized concurrent computation of more than one client+server layer p= ath that meets some diversity and resource exclusivity requirements.

IB>> Correction: th= ere is a need for concurrent path computation in the client layer and becau= se the client layer topology is virtual, you need MELGs to consider

 <= /p>

Regds

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Monday, April 15, 2013 9:44 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

Please, see in-line.=

 <= /p>

Igor

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Monday, April 15, 2013 12:05 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

I understand the SRLG and= MELG behavior you have penned .

 <= /p>

My concern was little dif= ferent.  With changing resource consumption (because of dynamicity the= network has) in the network links, potential paths a set of virtual link can take will change and hence its MELG, as it is tied to a r= esource it can take. So unless virtual links paths are nailed down, it woul= d be hard to compute MELGs in distributed way.

 <= /p>

IB>> I think you ar= e missing the point here. Virtual Link server layer paths are pinned as far= as fate sharing is concerned (that is, they are pinned on  server layer link level). It would make little sense to advertise VL SRLGs if the= SRLGs constantly change. The same is true for MELGs.  SRLGs/MELGs adv= ertised for VLs normally do not change: neither over time nor when VLs beco= me committed/uncommitted.

 <= /p>

Another point is, virtual= links can be viewed as oversubscription of resources (in MELG context). Ta= king an example (for OTN, I know it would work differently for a Wavelength in WDM), a link resources are worth 1 TB of BW, user has = provisioned 20 virtual links of 100G each going via that OTN link.  Ph= ysically, only 10 will get committed. But which 10? It will really depend o= n network dynamics at the time of demand to commit. MELGs are not that effective here. You need some different mech= anism.

 <= /p>

IB>> As I mentioned= before MELGs have nothing to do with bandwidth and were never intended to = solve the problems such as you describe (just like it would not make much sense to solve such problem with SRLGs :=3D)

Again,  MELG is an e= xtreme case SRLG designed exclusively for VLs (no more and no less).

 <= /p>

Regds

Khuzema=

 <= /p>

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 11:55 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

Think about MELG as an SR= LG that is shared between two or more links in its entirety. When two real = links have an SRLG in common, it means that two real links can co-exist concurrently, but there is something (e.g. common conduit, no= te that the conduit has room for more than for one link) that will bring bo= th these links down, if this something fails (e.g. conduit is cut ). Now co= nsider that this something must be taken in its entirety by one of the links to become operational . In th= is case SRLG becomes MELG. Note that MELG is only meaningful for virtual li= nks (unlike SRLG that makes sense for either real or virtual link). Why wou= ld you advertise two links that mutually exclude each other rather than advertising only one of them at a = time, unless the two are virtual links and hence both available for the cli= ent layer connections?

 <= /p>

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Friday, April 12, 2013 1:01 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

Do you mean, if virtual l= ink do not have any specific constraint, for example a link in the path (no= t talking about egress links/interfaces) must be traversed to realize the virtual link, there wont be any MELG for the virtual link?<= o:p>

 <= /p>

Regds

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 9:52 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

MELGs have nothing to do = with bandwidth. MELG is a concrete network resource in a server layer that = two or more Virtual Links in a client layer depend on in a mutually exclusive way. An example of MELG is a WDM layer transponder th= at can terminate either of respective WDM layer tunnels (but not both at th= e same time) for two OTN layer Virtual Links. If you advertise a Virtual Li= nk, say, for Ethernet layer that depends on the connection in OTN layer going through one of the mentioned = OTN links, the Ethernet VL must inherit the MELG similarly like it does SRL= Gs advertised for the OTN links.

 <= /p>

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Friday, April 12, 2013 12:06 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

For multi-layer (more tha= n 2) network, consider all the layers are meshy (that’s when virtual = links are useful anyway), MELGs of virtual link will change as and when BW/wavelength availability changes, because potential paths, a vi= rtual link can take will change. Mapping lower layer MELGs to higher layer = MELGs won’t be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all the risk and paths (a PCE?), which ca= n be utilized for layer specific path computation (as it is doing it anyway= ).

 <= /p>

This kind of architecture= has all the pieces that are required for Inter-PCE communication (across l= ayers), except the protocol that would actually make the 2 PCEs talk.

 <= /p>

You seem to be doing some= thing that you don’t like J

 <= /p>

Regards=

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 8:39 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

I am not a fan of inter-l= ayer path computations (nor I am a fan of inter-PCE computations). In my mi= nd path computation for a service or services in layer X is performed only in layer X, i.e. considers only X layer links (real or v= irtual). As Pavan mentioned SRLGs and MELGs that need to be inherited from = lower layers should be translated into X layer link SRLGs/MELGs and specifi= ed with X layer specific SRLG/MELG IDs.

 <= /p>

Cheers,=

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Friday, April 12, 2013 10:55 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

Ok. This would be useful = if network architecture is based on external PCE or mgmt entity as PCE in c= lient layer, but there is no counterpart in server layer, otherwise one could have inter-PCE communication to achieve diverse path i= n server layer without getting into virtual link and MELG stuff.

 <= /p>

Is that correct?

 <= /p>

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 6:36 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

2.       For cases of concurrent computation (case= #2-5), you are mainly talking about global optimization and diversity among= multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from th= e source end of those LSPs.  So there is no point in doing concurrent = computation at one network element for the services starting from multiple = network elements. At best it looks to me a problem to be solved by network management/planning software.&= nbsp;

Well, when an ingress nod= e is initiating a service, it is doing so on request from some management e= ntity. This management entity can compute paths for many services with some global criteria in mind, and then specify the resulting= paths as explicit EROs in provisioning requests sent to each of the servic= e ingresses. How else, for example,  you can set up several services o= riginated from different nodes that are disjoint from each other? Also, what is the point in your opinion of the s= tatefull PCE work?

 <= /p>

Cheers,=

Igor

 <= /p>

From: Vishnu P= avan Beeram [mailto:vishnupavan@gm= ail.com]
Sent: Friday, April 12, 2013 8:08 AM
To: Khuzema Pithewan
Cc: Igor Bryskin; Dieter Beller; c= camp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Khuzema, Hi!


Please see inline..

 

 

 1.       When Network has more than 2 layer i.e. P= acket-OTN-DWDM, the Packet (client) layer will be talking to its immediate = server layer i.e. OTN, which in turn is talking to DWDM layer. Using MELG, client layer path computation can take care of resource= exclusivity of virtual link for immediate server layer i.e. OTN layer.&nbs= p; However if there is resource exclusivity at DWDM layer, this mechanism d= oesn’t work. You need to do loose routing or use distributed PCE model

 

[VPB] The behavior is the same as what you would do = with SRLGs in a multi-layer architecture. There are architectures that allo= w the SRLGs in the lowest layer to be exported all the way up to the highes= t layer. The expectation is that MELGs would be treated in the same vein. 

2.       For cases of concurrent computation (case= #2-5), you are mainly talking about global optimization and diversity among= multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from th= e source end of those LSPs.  So there is no point in doing concurrent = computation at one network element for the services starting from multiple = network elements. At best it looks to me a problem to be solved by network management/planning software.&= nbsp;

[VPB]  I'm not sure why you think there is no p= oint in having a centralized computation function compute paths concurrentl= y for LSPs with different set of end-points. Even your NMS/planning-softwar= e can interact with such computation engine, retrieve all the paths and then go about initiating the path-setup from th= e ingress of each LSP. 

 

Regards,

-Pavan

 

 

 

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Tuesday, March 26, 2013 7:19 PM
To: Dieter Beller; Vishnu Pavan Beeram


Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Dieter,

 

You said:

>> I guess we are coming back to the essential point: "= and how often concurrent path computation will be >> used."

 

To be honest, this surprises me quite a bit, Let me give you some = of many reasons as to why concurrent path computations are needed and why t= his is better than computing one path at a time:

 

1.      = Computing several diverse paths for the same service in the context of serv= ice recovery. I hope you realize that computing one path at a time on many = configurations produces no or sub-optimal results. I also hope you realize the problem of selecting two paths with one of them  havi= ng a link with common MELG with a link from another path;

2.      = Computing paths for multiple services to be sufficiently disjoint from each= other;

3.      = Computing paths for multiple services to achieve a global optimization crit= eria (e.g. minimal summary total cost);

4.      = Computing paths for multiple services for the purpose of removing the bandw= idth fragmentations;

5.      = Computing paths for multiple services to plan shared mesh protection/restor= ation schemes

6.      = Etc.

 

Also think about this:

1.      = If concurrent path computation was not important, why PCEP includes the mac= hinery to do that?

2.      = My understanding of the statefull PCE is that it does pretty much nothing b= ut concurrent path computations

 

You also said:

>> I suppose that if a pce approach is used, i.e., path computatio= n is centralized including the
>> TE-DB, MELG routing extensions are not needed because the informat= ion about mutual
>>exclusive VLs can be kept in the central TE-DB when VLs are configu= red.

How this logic does not apply to other link attributes such as SRL= Gs?

What if path computation is not centralized?

 

Cheers,

Igor

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Hi Pavan,

On 25.03.2013 07:29, Fat= ai Zhang wrote:

Hi Pavan,

 

I am not sure how much VL (Virtual Link= ) will be used in the practical deployment and how often concurrent path computation will be used.

I guess we are coming back to the essential point: "and how often concurrent path computation will be used."

This means we are trying to figure out under which conditions MELG routing = extensions
could be beneficial.

IMHO, they would only make sense, if:

  • a path computation function supports the calculation of k shortest paths co= ncurrently
  • if there is only a single path computation function instance per domain (pc= e approach)
    If path computation is done in a distributed fashion the benefit goes away = because
    the instances calculate paths independently!

I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the
TE-DB, MELG routing extensions are not needed because the information about= mutual
exclusive VLs can be kept in the central TE-DB when VLs are configured.

Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their
applicability is broader.


Thanks,
Dieter

 

Do you think if it makes sense to add a flag (in= routing advertisement) to indicate a link is a VL or not?

 

 

 

Best Regards

 

Fatai

 

From: Vishnu Pavan Beeram [<= a href=3D"mailto:vishnupavan@gmail.com" target=3D"_blank">mailto:vishnupava= n@gmail.com]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Fatai, Hi!

 

Good to see that you understand the construct now.

 

This is not a corner case. The utility of the construct becomes qu= ite significant if you have an application that does concurrent path comput= ations on an abstract topology.

 

Regards,

-Pavan

 

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org=

https://www.ietf.org/mailman/listinfo/ccamp

 

--

DIETER BELLER

ALCATEL-LUCENT DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 = 711 821 43125
Mobil: +49 175 = 7266874

 

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe

 

--_000_0182DEA5604B3A44A2EE61F3EE3ED69E1D4A5653BL2PRD0510MB349_-- From IBryskin@advaoptical.com Wed Apr 17 05:57:56 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A615E21F8782 for ; Wed, 17 Apr 2013 05:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.776 X-Spam-Level: X-Spam-Status: No, score=-1.776 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=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 i2h8KYhr6761 for ; Wed, 17 Apr 2013 05:57:45 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id 97F1421F8E5A for ; Wed, 17 Apr 2013 05:57:44 -0700 (PDT) Received: from MUC-SRV-MBX2.advaoptical.com ([172.20.1.96]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id r3HCvbnE010494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Apr 2013 14:57:37 +0200 Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MBX2.advaoptical.com (172.20.1.96) with Microsoft SMTP Server (TLS) id 15.0.620.29; Wed, 17 Apr 2013 14:57:36 +0200 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0123.003; Wed, 17 Apr 2013 08:57:35 -0400 From: Igor Bryskin To: John E Drake , Khuzema Pithewan , Vishnu Pavan Beeram Thread-Topic: [CCAMP] MELGs - Q&A Thread-Index: AQHOIGPeoOQf0fNS1kG7ulofq5GmQJivzRoAgABxTHCAAPkpgIAAeAqAgABMBQCABErLAIABAdYAgAC6NQCAGt0OAIAAD52A///KWjCAAGRRgP//wCBQgABTlAD//73CwAAKM0gAAAY9GCAAdYY0gAAQgVwAADCVHoAAA3fQ8AAvLpWAAALyvwAACBNGgA== Date: Wed, 17 Apr 2013 12:57:33 +0000 Message-ID: References: <5150C704.2040007@alcatel-lucent.com> <0182DEA5604B3A44A2EE61F3EE3ED69E1D4A5653@BL2PRD0510MB349.namprd05.prod.outlook.com> In-Reply-To: <0182DEA5604B3A44A2EE61F3EE3ED69E1D4A5653@BL2PRD0510MB349.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.1.111] Content-Type: multipart/alternative; boundary="_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923940Eatlsrvmail10atl_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-04-17_05:2013-04-17, 2013-04-17, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] MELGs - Q&A X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 12:57:56 -0000 --_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923940Eatlsrvmail10atl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable John, You said: JD: The draft should note that MELGs have utility only in client networks = that use centralized concurrent path computation. If a client device needs to compute two disjoint paths to a destination (e.= g. for recovery purposes), the computation will be concurrent (of more than= one paths), but not necessarily centralized. Note that MELGs need to be co= nsidered in this case to avoid selecting links belonging to different path= s with an MELG in common. Would you agree? Cheers, Igor From: John E Drake [mailto:jdrake@juniper.net] Sent: Wednesday, April 17, 2013 8:43 AM To: Khuzema Pithewan; Igor Bryskin; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Comments inline. Irrespectively Yours, John From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Khuzema Pithewan Sent: Wednesday, April 17, 2013 4:19 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Hi Igor and Pavan, Thanks for the discussion. I understand MELG proposal is not really precluding non-WDM server layer. I= am trying to see, will it solve similar issues if they are there in more d= ynamic OTN (TDM) server layer. JD: This is a very good point. While MELGs can be used in higher layer se= rver networks, they may not have any utility in these networks because thes= e networks do not use physical resources directly. MELG seems to be made useful by quite a bit of mgmt provisioning w.r.t. VLs= and its path in server layer. It is one way, a client layer can make use = of server layer resource information (for path computation). However, is it= the typical way? I am not sure. JD: The draft should note that MELGs have utility only in client networks = that use centralized concurrent path computation. Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Tuesday, April 16, 2013 7:50 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Please, see in line. From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Tuesday, April 16, 2013 7:08 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, I am trying to summarize the discussion we had so far. Pls see if my conclu= sion is in sync with the idea of MELG you have MELG is useful when 1. server layer VLs are nailed down for the resources on the server la= yer links that are shared among multiple VLs. IB>> Correction: server layer link-level paths supporting *client layer* VL= s are nailed down. The resources of said paths are sharable between the pat= hs (and hence VLs) but not available for anything else. These resources are typically wavelength on a fiber (can it be anything els= e??). IB>> Server layer does not have to be WDM In other words, if 2 VLs are pinned to use a particular wavelength on a par= ticular fiber, then these 2 VLs will have MELG for the wavelength. IB>> Correction: Wavelength is not the only type of resource that is used i= n WDM layer. If two paths use the same transponder, converter, regenerator,= etc. then corresponding VLs have a MELG in common. If two paths have a WDM= link in common on which they *must* use the same wavelength (e.g. because = the paths are started on fixed transponders of the same frequency), then th= ey also have an MELG in common. If two paths have to use the same wavelengt= h on a common WDM link because this is the only wavelength available at the= moment, then the VLs *do not* have an MELG in common (just usual lack of = resources on the link) 2. server layer do not have centralized path computation entity which = can be used by client layer to ask for concurrent diverse path computation = within server layer. IB>> This approach has nothing to do with VLs. VLs (just like real links) a= re supposed to be pre-planned in a different time frame from when client la= yer connections are set up. When VLs are advertised, this means that the se= rver layer paths are successfully computed and pinned already (btw by serve= r layer path computer). Asking server layer path computation dynamically do= es not guarantee any success, so, if it fails, what to do next? You cannot= orchestrate any restoration schemes in the client layer this way. Instaed,= we suggest solid as_good_as_real Virtual Topology to use. 3. Client layer has a centralized path computation entity, which would= compute paths for client+server layer. IB>> Correction: only for client layer, based on client layer VLs 4. The need is to centralized concurrent computation of more than one = client+server layer path that meets some diversity and resource exclusivity= requirements. IB>> Correction: there is a need for concurrent path computation in the cli= ent layer and because the client layer topology is virtual, you need MELGs = to consider Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Monday, April 15, 2013 9:44 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Please, see in-line. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Monday, April 15, 2013 12:05 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, I understand the SRLG and MELG behavior you have penned . My concern was little different. With changing resource consumption (becau= se of dynamicity the network has) in the network links, potential paths a s= et of virtual link can take will change and hence its MELG, as it is tied t= o a resource it can take. So unless virtual links paths are nailed down, it= would be hard to compute MELGs in distributed way. IB>> I think you are missing the point here. Virtual Link server layer path= s are pinned as far as fate sharing is concerned (that is, they are pinned = on server layer link level). It would make little sense to advertise VL SR= LGs if the SRLGs constantly change. The same is true for MELGs. SRLGs/MELG= s advertised for VLs normally do not change: neither over time nor when VLs= become committed/uncommitted. Another point is, virtual links can be viewed as oversubscription of resour= ces (in MELG context). Taking an example (for OTN, I know it would work dif= ferently for a Wavelength in WDM), a link resources are worth 1 TB of BW, u= ser has provisioned 20 virtual links of 100G each going via that OTN link. = Physically, only 10 will get committed. But which 10? It will really depen= d on network dynamics at the time of demand to commit. MELGs are not that e= ffective here. You need some different mechanism. IB>> As I mentioned before MELGs have nothing to do with bandwidth and were= never intended to solve the problems such as you describe (just like it wo= uld not make much sense to solve such problem with SRLGs :=3D) Again, MELG is an extreme case SRLG designed exclusively for VLs (no more = and no less). Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 11:55 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Think about MELG as an SRLG that is shared between two or more links in its= entirety. When two real links have an SRLG in common, it means that two re= al links can co-exist concurrently, but there is something (e.g. common con= duit, note that the conduit has room for more than for one link) that will = bring both these links down, if this something fails (e.g. conduit is cut )= . Now consider that this something must be taken in its entirety by one of = the links to become operational . In this case SRLG becomes MELG. Note that= MELG is only meaningful for virtual links (unlike SRLG that makes sense fo= r either real or virtual link). Why would you advertise two links that mutu= ally exclude each other rather than advertising only one of them at a time,= unless the two are virtual links and hence both available for the client l= ayer connections? Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 1:01 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Do you mean, if virtual link do not have any specific constraint, for examp= le a link in the path (not talking about egress links/interfaces) must be t= raversed to realize the virtual link, there wont be any MELG for the virtua= l link? Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 9:52 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, MELGs have nothing to do with bandwidth. MELG is a concrete network resourc= e in a server layer that two or more Virtual Links in a client layer depend= on in a mutually exclusive way. An example of MELG is a WDM layer transpon= der that can terminate either of respective WDM layer tunnels (but not both= at the same time) for two OTN layer Virtual Links. If you advertise a Virt= ual Link, say, for Ethernet layer that depends on the connection in OTN lay= er going through one of the mentioned OTN links, the Ethernet VL must inher= it the MELG similarly like it does SRLGs advertised for the OTN links. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 12:06 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, For multi-layer (more than 2) network, consider all the layers are meshy (t= hat's when virtual links are useful anyway), MELGs of virtual link will cha= nge as and when BW/wavelength availability changes, because potential paths= , a virtual link can take will change. Mapping lower layer MELGs to higher = layer MELGs won't be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all= the risk and paths (a PCE?), which can be utilized for layer specific path= computation (as it is doing it anyway). This kind of architecture has all the pieces that are required for Inter-PC= E communication (across layers), except the protocol that would actually ma= ke the 2 PCEs talk. You seem to be doing something that you don't like :) Regards Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 8:39 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, I am not a fan of inter-layer path computations (nor I am a fan of inter-PC= E computations). In my mind path computation for a service or services in l= ayer X is performed only in layer X, i.e. considers only X layer links (rea= l or virtual). As Pavan mentioned SRLGs and MELGs that need to be inherited= from lower layers should be translated into X layer link SRLGs/MELGs and s= pecified with X layer specific SRLG/MELG IDs. Cheers, Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 10:55 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Ok. This would be useful if network architecture is based on external PCE o= r mgmt entity as PCE in client layer, but there is no counterpart in server= layer, otherwise one could have inter-PCE communication to achieve diverse= path in server layer without getting into virtual link and MELG stuff. Is that correct? Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 6:36 PM To: Vishnu Pavan Beeram; Khuzema Pithewan Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. Well, when an ingress node is initiating a service, it is doing so on reque= st from some management entity. This management entity can compute paths fo= r many services with some global criteria in mind, and then specify the res= ulting paths as explicit EROs in provisioning requests sent to each of the = service ingresses. How else, for example, you can set up several services = originated from different nodes that are disjoint from each other? Also, wh= at is the point in your opinion of the statefull PCE work? Cheers, Igor From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, April 12, 2013 8:08 AM To: Khuzema Pithewan Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Khuzema, Hi! Please see inline.. 1. When Network has more than 2 layer i.e. Packet-OTN-DWDM, the Pack= et (client) layer will be talking to its immediate server layer i.e. OTN, w= hich in turn is talking to DWDM layer. Using MELG, client layer path comput= ation can take care of resource exclusivity of virtual link for immediate s= erver layer i.e. OTN layer. However if there is resource exclusivity at DW= DM layer, this mechanism doesn't work. You need to do loose routing or use = distributed PCE model [VPB] The behavior is the same as what you would do with SRLGs in a multi-l= ayer architecture. There are architectures that allow the SRLGs in the lowe= st layer to be exported all the way up to the highest layer. The expectatio= n is that MELGs would be treated in the same vein. 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. [VPB] I'm not sure why you think there is no point in having a centralized= computation function compute paths concurrently for LSPs with different se= t of end-points. Even your NMS/planning-software can interact with such com= putation engine, retrieve all the paths and then go about initiating the pa= th-setup from the ingress of each LSP. Regards, -Pavan From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Igor Bryskin Sent: Tuesday, March 26, 2013 7:19 PM To: Dieter Beller; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Dieter, You said: >> I guess we are coming back to the essential point: "and how often concur= rent path computation will be >> used." To be honest, this surprises me quite a bit, Let me give you some of many r= easons as to why concurrent path computations are needed and why this is be= tter than computing one path at a time: 1. Computing several diverse paths for the same service in the context= of service recovery. I hope you realize that computing one path at a time = on many configurations produces no or sub-optimal results. I also hope you = realize the problem of selecting two paths with one of them having a link = with common MELG with a link from another path; 2. Computing paths for multiple services to be sufficiently disjoint f= rom each other; 3. Computing paths for multiple services to achieve a global optimizat= ion criteria (e.g. minimal summary total cost); 4. Computing paths for multiple services for the purpose of removing t= he bandwidth fragmentations; 5. Computing paths for multiple services to plan shared mesh protectio= n/restoration schemes 6. Etc. Also think about this: 1. If concurrent path computation was not important, why PCEP includes= the machinery to do that? 2. My understanding of the statefull PCE is that it does pretty much n= othing but concurrent path computations You also said: >> I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the >> TE-DB, MELG routing extensions are not needed because the information ab= out mutual >>exclusive VLs can be kept in the central TE-DB when VLs are configured. How this logic does not apply to other link attributes such as SRLGs? What if path computation is not centralized? Cheers, Igor From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Dieter Beller Sent: Monday, March 25, 2013 5:52 PM To: Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Hi Pavan, On 25.03.2013 07:29, Fatai Zhang wrote: Hi Pavan, I am not sure how much VL (Virtual Link) will be used in the practical depl= oyment and how often concurrent path computation will be used. I guess we are coming back to the essential point: "and how often concurren= t path computation will be used." This means we are trying to figure out under which conditions MELG routing = extensions could be beneficial. IMHO, they would only make sense, if: * a path computation function supports the calculation of k shortest pa= ths concurrently * if there is only a single path computation function instance per doma= in (pce approach) If path computation is done in a distributed fashion the benefit goes away = because the instances calculate paths independently! I suppose that if a pce approach is used, i.e., path computation is central= ized including the TE-DB, MELG routing extensions are not needed because the information about= mutual exclusive VLs can be kept in the central TE-DB when VLs are configured. Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their applicability is broader. Thanks, Dieter Do you think if it makes sense to add a flag (in routing advertisement) to = indicate a link is a VL or not? Best Regards Fatai From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, March 22, 2013 8:57 PM To: Fatai Zhang Cc: Igor Bryskin; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Fatai, Hi! Good to see that you understand the construct now. This is not a corner case. The utility of the construct becomes quite signi= ficant if you have an application that does concurrent path computations on= an abstract topology. Regards, -Pavan _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp -- DIETER BELLER ALCATEL-LUCENT DEUTSCHLAND AG PROJECT MANAGER ASON/GMPLS CONTROL PLANE CORE NETWORKS BUSINESS DIVISION OPTICS BU, SWITCHING R&D Lorenzstrasse 10 70435 Stuttgart, Germany Phone: +49 711 821 43125 Mobil: +49 175 7266874 Dieter.Beller@alcatel-lucent.com Alcatel-Lucent Deutschland AG Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026 Chairman of the Supervisory Board: Michael Oppenhoff Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe --_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923940Eatlsrvmail10atl_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

John,

You said:

JD:  The draft shoul= d note that MELGs have utility only in client networks that use centralized= concurrent path computation.

 <= /p>

If a client device needs = to compute two disjoint paths to a destination (e.g. for recovery purposes)= , the computation will be concurrent (of more than one paths), but not necessarily centralized. Note that MELGs need to be considered in = this case to avoid selecting  links belonging to different paths with = an MELG in common. Would you agree?

 <= /p>

Cheers,=

Igor

 <= /p>

From: John E D= rake [mailto:jdrake@juniper.net]
Sent: Wednesday, April 17, 2013 8:43 AM
To: Khuzema Pithewan; Igor Bryskin; Vishnu Pavan Beeram
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

Comments inline.

 <= /p>

Irrespectively Yours,

 <= /p>

John

 <= /p>

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Khuzema Pithewan
Sent: Wednesday, April 17, 2013 4:19 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Hi Igor and Pavan,

 <= /p>

Thanks for the discussion= .

 <= /p>

I understand MELG proposa= l is not really precluding non-WDM server layer. I am trying to see, will i= t solve similar issues if they are there in more dynamic OTN (TDM) server layer.

 <= /p>

JD:  This is a very = good point.  While MELGs can be used in higher layer server networks, = they may not have any utility in these networks because these networks do not use physical resources directly.   

 <= /p>

MELG seems to be made use= ful by quite a bit of mgmt provisioning w.r.t. VLs and its path in server l= ayer.  It is one way, a client layer can make use of server layer resource information (for path computation). However, is it the typi= cal way?  I am not sure.

 <= /p>

JD:  The draft shoul= d note that MELGs have utility only in client networks that use centralized= concurrent path computation.

 <= /p>

Regds

Khuzema=

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Tuesday, April 16, 2013 7:50 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

Please, see in line.=

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Tuesday, April 16, 2013 7:08 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

I am trying to summarize = the discussion we had so far. Pls see if my conclusion is in sync with the = idea of MELG you have

 <= /p>

MELG is useful when<= /o:p>

1. = ;     server layer VLs = are nailed down for the resources on the server layer links that are shared= among multiple VLs.

IB>> Correction: se= rver layer link-level paths supporting *client layer* VLs are nailed= down. The resources of said paths are sharable between the paths (and hence VLs) but not available for anything else.

 <= /p>

IB>> Server layer d= oes not have to be WDM

 <= /p>

IB>> Correction: Wa= velength is not the only type of resource that is used in WDM layer. If two= paths use the same transponder, converter, regenerator, etc. then corresponding VLs have a MELG in common. If two paths have a WDM link= in common on which they *must* use the same wavelength (e.g. becaus= e the paths are started on fixed transponders of the same frequency), then = they also have an MELG in common. If two paths have to use the same wavelength on a common WDM link because = this is the only wavelength available at the moment, then the VLs *do no= t* have an MELG in common (just  usual lack of resources on the li= nk)

 <= /p>

2. = ;     server layer do n= ot have centralized path computation entity which can be used by client lay= er to ask for concurrent diverse path computation within server layer.

IB>> This approach = has nothing to do with VLs. VLs (just like real links) are supposed to be p= re-planned in a different time frame from when client layer connections are set up. When VLs are advertised, this means that the server layer path= s are successfully computed and pinned already (btw by server layer path co= mputer). Asking server layer path computation dynamically does not guarante= e  any success, so, if it fails, what to do next? You cannot orchestrate any restoration schemes in the cli= ent layer this way. Instaed, we suggest solid as_good_as_real Virtual Topol= ogy to use.

 <= /p>

3. = ;     Client layer has = a centralized path computation entity, which would compute paths for client= +server layer.

IB>> Correction: on= ly for client layer, based on client layer VLs

4. = ;     The need is to ce= ntralized concurrent computation of more than one client+server layer p= ath that meets some diversity and resource exclusivity requirements.

IB>> Correction: th= ere is a need for concurrent path computation in the client layer and becau= se the client layer topology is virtual, you need MELGs to consider

 <= /p>

Regds

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Monday, April 15, 2013 9:44 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

Please, see in-line.=

 <= /p>

Igor

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Monday, April 15, 2013 12:05 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

I understand the SRLG and= MELG behavior you have penned .

 <= /p>

My concern was little dif= ferent.  With changing resource consumption (because of dynamicity the= network has) in the network links, potential paths a set of virtual link can take will change and hence its MELG, as it is tied to a r= esource it can take. So unless virtual links paths are nailed down, it woul= d be hard to compute MELGs in distributed way.

 <= /p>

IB>> I think you ar= e missing the point here. Virtual Link server layer paths are pinned as far= as fate sharing is concerned (that is, they are pinned on  server layer link level). It would make little sense to advertise VL SRLGs if the= SRLGs constantly change. The same is true for MELGs.  SRLGs/MELGs adv= ertised for VLs normally do not change: neither over time nor when VLs beco= me committed/uncommitted.

 <= /p>

Another point is, virtual= links can be viewed as oversubscription of resources (in MELG context). Ta= king an example (for OTN, I know it would work differently for a Wavelength in WDM), a link resources are worth 1 TB of BW, user has = provisioned 20 virtual links of 100G each going via that OTN link.  Ph= ysically, only 10 will get committed. But which 10? It will really depend o= n network dynamics at the time of demand to commit. MELGs are not that effective here. You need some different mech= anism.

 <= /p>

IB>> As I mentioned= before MELGs have nothing to do with bandwidth and were never intended to = solve the problems such as you describe (just like it would not make much sense to solve such problem with SRLGs :=3D)

Again,  MELG is an e= xtreme case SRLG designed exclusively for VLs (no more and no less).

 <= /p>

Regds

Khuzema=

 <= /p>

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 11:55 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

Think about MELG as an SR= LG that is shared between two or more links in its entirety. When two real = links have an SRLG in common, it means that two real links can co-exist concurrently, but there is something (e.g. common conduit, no= te that the conduit has room for more than for one link) that will bring bo= th these links down, if this something fails (e.g. conduit is cut ). Now co= nsider that this something must be taken in its entirety by one of the links to become operational . In th= is case SRLG becomes MELG. Note that MELG is only meaningful for virtual li= nks (unlike SRLG that makes sense for either real or virtual link). Why wou= ld you advertise two links that mutually exclude each other rather than advertising only one of them at a = time, unless the two are virtual links and hence both available for the cli= ent layer connections?

 <= /p>

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Friday, April 12, 2013 1:01 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

Do you mean, if virtual l= ink do not have any specific constraint, for example a link in the path (no= t talking about egress links/interfaces) must be traversed to realize the virtual link, there wont be any MELG for the virtual link?<= o:p>

 <= /p>

Regds

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 9:52 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

MELGs have nothing to do = with bandwidth. MELG is a concrete network resource in a server layer that = two or more Virtual Links in a client layer depend on in a mutually exclusive way. An example of MELG is a WDM layer transponder th= at can terminate either of respective WDM layer tunnels (but not both at th= e same time) for two OTN layer Virtual Links. If you advertise a Virtual Li= nk, say, for Ethernet layer that depends on the connection in OTN layer going through one of the mentioned = OTN links, the Ethernet VL must inherit the MELG similarly like it does SRL= Gs advertised for the OTN links.

 <= /p>

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Friday, April 12, 2013 12:06 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

For multi-layer (more tha= n 2) network, consider all the layers are meshy (that’s when virtual = links are useful anyway), MELGs of virtual link will change as and when BW/wavelength availability changes, because potential paths, a vi= rtual link can take will change. Mapping lower layer MELGs to higher layer = MELGs won’t be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all the risk and paths (a PCE?), which ca= n be utilized for layer specific path computation (as it is doing it anyway= ).

 <= /p>

This kind of architecture= has all the pieces that are required for Inter-PCE communication (across l= ayers), except the protocol that would actually make the 2 PCEs talk.

 <= /p>

You seem to be doing some= thing that you don’t like J

 <= /p>

Regards=

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 8:39 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

I am not a fan of inter-l= ayer path computations (nor I am a fan of inter-PCE computations). In my mi= nd path computation for a service or services in layer X is performed only in layer X, i.e. considers only X layer links (real or v= irtual). As Pavan mentioned SRLGs and MELGs that need to be inherited from = lower layers should be translated into X layer link SRLGs/MELGs and specifi= ed with X layer specific SRLG/MELG IDs.

 <= /p>

Cheers,=

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Friday, April 12, 2013 10:55 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

Ok. This would be useful = if network architecture is based on external PCE or mgmt entity as PCE in c= lient layer, but there is no counterpart in server layer, otherwise one could have inter-PCE communication to achieve diverse path i= n server layer without getting into virtual link and MELG stuff.

 <= /p>

Is that correct?

 <= /p>

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 6:36 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

2.       For cases of concurrent computation (case= #2-5), you are mainly talking about global optimization and diversity among= multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from th= e source end of those LSPs.  So there is no point in doing concurrent = computation at one network element for the services starting from multiple = network elements. At best it looks to me a problem to be solved by network management/planning software.&= nbsp;

Well, when an ingress nod= e is initiating a service, it is doing so on request from some management e= ntity. This management entity can compute paths for many services with some global criteria in mind, and then specify the resulting= paths as explicit EROs in provisioning requests sent to each of the servic= e ingresses. How else, for example,  you can set up several services o= riginated from different nodes that are disjoint from each other? Also, what is the point in your opinion of the s= tatefull PCE work?

 <= /p>

Cheers,=

Igor

 <= /p>

From: Vishnu P= avan Beeram [mailto:vishnupavan@gm= ail.com]
Sent: Friday, April 12, 2013 8:08 AM
To: Khuzema Pithewan
Cc: Igor Bryskin; Dieter Beller; c= camp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Khuzema, Hi!


Please see inline..

 

 

 1.       When Network has more than 2 layer i.e. P= acket-OTN-DWDM, the Packet (client) layer will be talking to its immediate = server layer i.e. OTN, which in turn is talking to DWDM layer. Using MELG, client layer path computation can take care of resource= exclusivity of virtual link for immediate server layer i.e. OTN layer.&nbs= p; However if there is resource exclusivity at DWDM layer, this mechanism d= oesn’t work. You need to do loose routing or use distributed PCE model

 

[VPB] The behavior is the same as what you would do = with SRLGs in a multi-layer architecture. There are architectures that allo= w the SRLGs in the lowest layer to be exported all the way up to the highes= t layer. The expectation is that MELGs would be treated in the same vein. 

2.       For cases of concurrent computation (case= #2-5), you are mainly talking about global optimization and diversity among= multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from th= e source end of those LSPs.  So there is no point in doing concurrent = computation at one network element for the services starting from multiple = network elements. At best it looks to me a problem to be solved by network management/planning software.&= nbsp;

[VPB]  I'm not sure why you think there is no p= oint in having a centralized computation function compute paths concurrentl= y for LSPs with different set of end-points. Even your NMS/planning-softwar= e can interact with such computation engine, retrieve all the paths and then go about initiating the path-setup from th= e ingress of each LSP. 

 

Regards,

-Pavan

 

 

 

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Tuesday, March 26, 2013 7:19 PM
To: Dieter Beller; Vishnu Pavan Beeram


Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Dieter,

 

You said:

>> I guess we are coming back to the essential point: "= and how often concurrent path computation will be >> used."

 

To be honest, this surprises me quite a bit, Let me give you some = of many reasons as to why concurrent path computations are needed and why t= his is better than computing one path at a time:

 

1.      = Computing several diverse paths for the same service in the context of serv= ice recovery. I hope you realize that computing one path at a time on many = configurations produces no or sub-optimal results. I also hope you realize the problem of selecting two paths with one of them  havi= ng a link with common MELG with a link from another path;

2.      = Computing paths for multiple services to be sufficiently disjoint from each= other;

3.      = Computing paths for multiple services to achieve a global optimization crit= eria (e.g. minimal summary total cost);

4.      = Computing paths for multiple services for the purpose of removing the bandw= idth fragmentations;

5.      = Computing paths for multiple services to plan shared mesh protection/restor= ation schemes

6.      = Etc.

 

Also think about this:

1.      = If concurrent path computation was not important, why PCEP includes the mac= hinery to do that?

2.      = My understanding of the statefull PCE is that it does pretty much nothing b= ut concurrent path computations

 

You also said:

>> I suppose that if a pce approach is used, i.e., path computatio= n is centralized including the
>> TE-DB, MELG routing extensions are not needed because the informat= ion about mutual
>>exclusive VLs can be kept in the central TE-DB when VLs are configu= red.

How this logic does not apply to other link attributes such as SRL= Gs?

What if path computation is not centralized?

 

Cheers,

Igor

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Hi Pavan,

On 25.03.2013 07:29, Fat= ai Zhang wrote:

Hi Pavan,

 

I am not sure how much VL (Virtual Link= ) will be used in the practical deployment and how often concurrent path computation will be used.

I guess we are coming back to the essential point: "and how often concurrent path computation will be used."

This means we are trying to figure out under which conditions MELG routing = extensions
could be beneficial.

IMHO, they would only make sense, if:

  • a path computation function supports the calculation of k shortest paths co= ncurrently
  • if there is only a single path computation function instance per domain (pc= e approach)
    If path computation is done in a distributed fashion the benefit goes away = because
    the instances calculate paths independently!

I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the
TE-DB, MELG routing extensions are not needed because the information about= mutual
exclusive VLs can be kept in the central TE-DB when VLs are configured.

Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their
applicability is broader.


Thanks,
Dieter

 

Do you think if it makes sense to add a flag (in= routing advertisement) to indicate a link is a VL or not?

 

 

 

Best Regards

 

Fatai

 

From: Vishnu Pavan Beeram [<= a href=3D"mailto:vishnupavan@gmail.com" target=3D"_blank">mailto:vishnupava= n@gmail.com]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Fatai, Hi!

 

Good to see that you understand the construct now.

 

This is not a corner case. The utility of the construct becomes qu= ite significant if you have an application that does concurrent path comput= ations on an abstract topology.

 

Regards,

-Pavan

 

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org=

https://www.ietf.org/mailman/listinfo/ccamp

 

--

DIETER BELLER

ALCATEL-LUCENT DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 = 711 821 43125
Mobil: +49 175 = 7266874

 

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe

 

--_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923940Eatlsrvmail10atl_-- From jdrake@juniper.net Wed Apr 17 06:09:30 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E018D21F89A6 for ; Wed, 17 Apr 2013 06:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.079 X-Spam-Level: X-Spam-Status: No, score=-3.079 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 TBpXFPUeVUYu for ; Wed, 17 Apr 2013 06:09:19 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9FF21F8AF8 for ; Wed, 17 Apr 2013 06:09:18 -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 DSNKUW6e/mNX52D40enJcj6hZjcPFOf3/Trb@postini.com; Wed, 17 Apr 2013 06:09:18 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 17 Apr 2013 06:05:57 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 17 Apr 2013 06:05:57 -0700 Received: from DB8EHSOBE018.bigfish.com (213.199.154.189) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 17 Apr 2013 06:09:11 -0700 Received: from mail114-db8-R.bigfish.com (10.174.8.230) by DB8EHSOBE018.bigfish.com (10.174.4.81) with Microsoft SMTP Server id 14.1.225.23; Wed, 17 Apr 2013 13:05:54 +0000 Received: from mail114-db8 (localhost [127.0.0.1]) by mail114-db8-R.bigfish.com (Postfix) with ESMTP id C3B91C0164 for ; Wed, 17 Apr 2013 13:05:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -26 X-BigFish: PS-26(zz98dI9371Ic89bh1102Ic85dh1432I4015I1447Idb82hzz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz1033IL18c673h8275bh8275dh8275chz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1155h) Received: from mail114-db8 (localhost.localdomain [127.0.0.1]) by mail114-db8 (MessageSwitch) id 1366203950759520_12625; Wed, 17 Apr 2013 13:05:50 +0000 (UTC) Received: from DB8EHSMHS027.bigfish.com (unknown [10.174.8.241]) by mail114-db8.bigfish.com (Postfix) with ESMTP id 9E0234A0090; Wed, 17 Apr 2013 13:05:50 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS027.bigfish.com (10.174.4.37) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 17 Apr 2013 13:05:48 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.181]) by BL2PRD0510HT001.namprd05.prod.outlook.com ([10.255.100.36]) with mapi id 14.16.0293.003; Wed, 17 Apr 2013 13:05:39 +0000 From: John E Drake To: Igor Bryskin , Khuzema Pithewan , Vishnu Pavan Beeram Thread-Topic: [CCAMP] MELGs - Q&A Thread-Index: AQHOIGPc5sNnbY0M9EO2ehkIVZ0e6ZivigwAgAC55wCAALCOgIAAeAqAgABMBQCABErLAIABAdYAgAELY4CAGovgAIAAD52AgAAQMoCAAB55gIAAA74AgAAP9gCAAASVAIAACscAgAAXnYCAA8Z9gIAAy+OAgAE80YCAADWBgIABX7KAgAAVUDCAAAZbgIAAAiFQ Date: Wed, 17 Apr 2013 13:05:38 +0000 Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E1D4A56FA@BL2PRD0510MB349.namprd05.prod.outlook.com> References: <5150C704.2040007@alcatel-lucent.com> <0182DEA5604B3A44A2EE61F3EE3ED69E1D4A5653@BL2PRD0510MB349.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.53] Content-Type: multipart/alternative; boundary="_000_0182DEA5604B3A44A2EE61F3EE3ED69E1D4A56FABL2PRD0510MB349_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ADVAOPTICAL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%INFINERA.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] MELGs - Q&A X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 13:09:31 -0000 --_000_0182DEA5604B3A44A2EE61F3EE3ED69E1D4A56FABL2PRD0510MB349_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sure Irrespectively Yours, John From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Wednesday, April 17, 2013 5:58 AM To: John E Drake; Khuzema Pithewan; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A John, You said: JD: The draft should note that MELGs have utility only in client networks = that use centralized concurrent path computation. If a client device needs to compute two disjoint paths to a destination (e.= g. for recovery purposes), the computation will be concurrent (of more than= one paths), but not necessarily centralized. Note that MELGs need to be co= nsidered in this case to avoid selecting links belonging to different path= s with an MELG in common. Would you agree? Cheers, Igor From: John E Drake [mailto:jdrake@juniper.net] Sent: Wednesday, April 17, 2013 8:43 AM To: Khuzema Pithewan; Igor Bryskin; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Comments inline. Irrespectively Yours, John From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Khuzema Pithewan Sent: Wednesday, April 17, 2013 4:19 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Hi Igor and Pavan, Thanks for the discussion. I understand MELG proposal is not really precluding non-WDM server layer. I= am trying to see, will it solve similar issues if they are there in more d= ynamic OTN (TDM) server layer. JD: This is a very good point. While MELGs can be used in higher layer se= rver networks, they may not have any utility in these networks because thes= e networks do not use physical resources directly. MELG seems to be made useful by quite a bit of mgmt provisioning w.r.t. VLs= and its path in server layer. It is one way, a client layer can make use = of server layer resource information (for path computation). However, is it= the typical way? I am not sure. JD: The draft should note that MELGs have utility only in client networks = that use centralized concurrent path computation. Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Tuesday, April 16, 2013 7:50 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Please, see in line. From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Tuesday, April 16, 2013 7:08 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, I am trying to summarize the discussion we had so far. Pls see if my conclu= sion is in sync with the idea of MELG you have MELG is useful when 1. server layer VLs are nailed down for the resources on the server la= yer links that are shared among multiple VLs. IB>> Correction: server layer link-level paths supporting *client layer* VL= s are nailed down. The resources of said paths are sharable between the pat= hs (and hence VLs) but not available for anything else. These resources are typically wavelength on a fiber (can it be anything els= e??). IB>> Server layer does not have to be WDM In other words, if 2 VLs are pinned to use a particular wavelength on a par= ticular fiber, then these 2 VLs will have MELG for the wavelength. IB>> Correction: Wavelength is not the only type of resource that is used i= n WDM layer. If two paths use the same transponder, converter, regenerator,= etc. then corresponding VLs have a MELG in common. If two paths have a WDM= link in common on which they *must* use the same wavelength (e.g. because = the paths are started on fixed transponders of the same frequency), then th= ey also have an MELG in common. If two paths have to use the same wavelengt= h on a common WDM link because this is the only wavelength available at the= moment, then the VLs *do not* have an MELG in common (just usual lack of = resources on the link) 2. server layer do not have centralized path computation entity which = can be used by client layer to ask for concurrent diverse path computation = within server layer. IB>> This approach has nothing to do with VLs. VLs (just like real links) a= re supposed to be pre-planned in a different time frame from when client la= yer connections are set up. When VLs are advertised, this means that the se= rver layer paths are successfully computed and pinned already (btw by serve= r layer path computer). Asking server layer path computation dynamically do= es not guarantee any success, so, if it fails, what to do next? You cannot= orchestrate any restoration schemes in the client layer this way. Instaed,= we suggest solid as_good_as_real Virtual Topology to use. 3. Client layer has a centralized path computation entity, which would= compute paths for client+server layer. IB>> Correction: only for client layer, based on client layer VLs 4. The need is to centralized concurrent computation of more than one = client+server layer path that meets some diversity and resource exclusivity= requirements. IB>> Correction: there is a need for concurrent path computation in the cli= ent layer and because the client layer topology is virtual, you need MELGs = to consider Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Monday, April 15, 2013 9:44 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Please, see in-line. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Monday, April 15, 2013 12:05 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, I understand the SRLG and MELG behavior you have penned . My concern was little different. With changing resource consumption (becau= se of dynamicity the network has) in the network links, potential paths a s= et of virtual link can take will change and hence its MELG, as it is tied t= o a resource it can take. So unless virtual links paths are nailed down, it= would be hard to compute MELGs in distributed way. IB>> I think you are missing the point here. Virtual Link server layer path= s are pinned as far as fate sharing is concerned (that is, they are pinned = on server layer link level). It would make little sense to advertise VL SR= LGs if the SRLGs constantly change. The same is true for MELGs. SRLGs/MELG= s advertised for VLs normally do not change: neither over time nor when VLs= become committed/uncommitted. Another point is, virtual links can be viewed as oversubscription of resour= ces (in MELG context). Taking an example (for OTN, I know it would work dif= ferently for a Wavelength in WDM), a link resources are worth 1 TB of BW, u= ser has provisioned 20 virtual links of 100G each going via that OTN link. = Physically, only 10 will get committed. But which 10? It will really depen= d on network dynamics at the time of demand to commit. MELGs are not that e= ffective here. You need some different mechanism. IB>> As I mentioned before MELGs have nothing to do with bandwidth and were= never intended to solve the problems such as you describe (just like it wo= uld not make much sense to solve such problem with SRLGs :=3D) Again, MELG is an extreme case SRLG designed exclusively for VLs (no more = and no less). Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 11:55 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Think about MELG as an SRLG that is shared between two or more links in its= entirety. When two real links have an SRLG in common, it means that two re= al links can co-exist concurrently, but there is something (e.g. common con= duit, note that the conduit has room for more than for one link) that will = bring both these links down, if this something fails (e.g. conduit is cut )= . Now consider that this something must be taken in its entirety by one of = the links to become operational . In this case SRLG becomes MELG. Note that= MELG is only meaningful for virtual links (unlike SRLG that makes sense fo= r either real or virtual link). Why would you advertise two links that mutu= ally exclude each other rather than advertising only one of them at a time,= unless the two are virtual links and hence both available for the client l= ayer connections? Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 1:01 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Do you mean, if virtual link do not have any specific constraint, for examp= le a link in the path (not talking about egress links/interfaces) must be t= raversed to realize the virtual link, there wont be any MELG for the virtua= l link? Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 9:52 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, MELGs have nothing to do with bandwidth. MELG is a concrete network resourc= e in a server layer that two or more Virtual Links in a client layer depend= on in a mutually exclusive way. An example of MELG is a WDM layer transpon= der that can terminate either of respective WDM layer tunnels (but not both= at the same time) for two OTN layer Virtual Links. If you advertise a Virt= ual Link, say, for Ethernet layer that depends on the connection in OTN lay= er going through one of the mentioned OTN links, the Ethernet VL must inher= it the MELG similarly like it does SRLGs advertised for the OTN links. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 12:06 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, For multi-layer (more than 2) network, consider all the layers are meshy (t= hat's when virtual links are useful anyway), MELGs of virtual link will cha= nge as and when BW/wavelength availability changes, because potential paths= , a virtual link can take will change. Mapping lower layer MELGs to higher = layer MELGs won't be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all= the risk and paths (a PCE?), which can be utilized for layer specific path= computation (as it is doing it anyway). This kind of architecture has all the pieces that are required for Inter-PC= E communication (across layers), except the protocol that would actually ma= ke the 2 PCEs talk. You seem to be doing something that you don't like :) Regards Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 8:39 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, I am not a fan of inter-layer path computations (nor I am a fan of inter-PC= E computations). In my mind path computation for a service or services in l= ayer X is performed only in layer X, i.e. considers only X layer links (rea= l or virtual). As Pavan mentioned SRLGs and MELGs that need to be inherited= from lower layers should be translated into X layer link SRLGs/MELGs and s= pecified with X layer specific SRLG/MELG IDs. Cheers, Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 10:55 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Ok. This would be useful if network architecture is based on external PCE o= r mgmt entity as PCE in client layer, but there is no counterpart in server= layer, otherwise one could have inter-PCE communication to achieve diverse= path in server layer without getting into virtual link and MELG stuff. Is that correct? Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 6:36 PM To: Vishnu Pavan Beeram; Khuzema Pithewan Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. Well, when an ingress node is initiating a service, it is doing so on reque= st from some management entity. This management entity can compute paths fo= r many services with some global criteria in mind, and then specify the res= ulting paths as explicit EROs in provisioning requests sent to each of the = service ingresses. How else, for example, you can set up several services = originated from different nodes that are disjoint from each other? Also, wh= at is the point in your opinion of the statefull PCE work? Cheers, Igor From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, April 12, 2013 8:08 AM To: Khuzema Pithewan Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Khuzema, Hi! Please see inline.. 1. When Network has more than 2 layer i.e. Packet-OTN-DWDM, the Pack= et (client) layer will be talking to its immediate server layer i.e. OTN, w= hich in turn is talking to DWDM layer. Using MELG, client layer path comput= ation can take care of resource exclusivity of virtual link for immediate s= erver layer i.e. OTN layer. However if there is resource exclusivity at DW= DM layer, this mechanism doesn't work. You need to do loose routing or use = distributed PCE model [VPB] The behavior is the same as what you would do with SRLGs in a multi-l= ayer architecture. There are architectures that allow the SRLGs in the lowe= st layer to be exported all the way up to the highest layer. The expectatio= n is that MELGs would be treated in the same vein. 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. [VPB] I'm not sure why you think there is no point in having a centralized= computation function compute paths concurrently for LSPs with different se= t of end-points. Even your NMS/planning-software can interact with such com= putation engine, retrieve all the paths and then go about initiating the pa= th-setup from the ingress of each LSP. Regards, -Pavan From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Igor Bryskin Sent: Tuesday, March 26, 2013 7:19 PM To: Dieter Beller; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Dieter, You said: >> I guess we are coming back to the essential point: "and how often concur= rent path computation will be >> used." To be honest, this surprises me quite a bit, Let me give you some of many r= easons as to why concurrent path computations are needed and why this is be= tter than computing one path at a time: 1. Computing several diverse paths for the same service in the context= of service recovery. I hope you realize that computing one path at a time = on many configurations produces no or sub-optimal results. I also hope you = realize the problem of selecting two paths with one of them having a link = with common MELG with a link from another path; 2. Computing paths for multiple services to be sufficiently disjoint f= rom each other; 3. Computing paths for multiple services to achieve a global optimizat= ion criteria (e.g. minimal summary total cost); 4. Computing paths for multiple services for the purpose of removing t= he bandwidth fragmentations; 5. Computing paths for multiple services to plan shared mesh protectio= n/restoration schemes 6. Etc. Also think about this: 1. If concurrent path computation was not important, why PCEP includes= the machinery to do that? 2. My understanding of the statefull PCE is that it does pretty much n= othing but concurrent path computations You also said: >> I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the >> TE-DB, MELG routing extensions are not needed because the information ab= out mutual >>exclusive VLs can be kept in the central TE-DB when VLs are configured. How this logic does not apply to other link attributes such as SRLGs? What if path computation is not centralized? Cheers, Igor From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Dieter Beller Sent: Monday, March 25, 2013 5:52 PM To: Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Hi Pavan, On 25.03.2013 07:29, Fatai Zhang wrote: Hi Pavan, I am not sure how much VL (Virtual Link) will be used in the practical depl= oyment and how often concurrent path computation will be used. I guess we are coming back to the essential point: "and how often concurren= t path computation will be used." This means we are trying to figure out under which conditions MELG routing = extensions could be beneficial. IMHO, they would only make sense, if: * a path computation function supports the calculation of k shortest pa= ths concurrently * if there is only a single path computation function instance per doma= in (pce approach) If path computation is done in a distributed fashion the benefit goes away = because the instances calculate paths independently! I suppose that if a pce approach is used, i.e., path computation is central= ized including the TE-DB, MELG routing extensions are not needed because the information about= mutual exclusive VLs can be kept in the central TE-DB when VLs are configured. Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their applicability is broader. Thanks, Dieter Do you think if it makes sense to add a flag (in routing advertisement) to = indicate a link is a VL or not? Best Regards Fatai From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, March 22, 2013 8:57 PM To: Fatai Zhang Cc: Igor Bryskin; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Fatai, Hi! Good to see that you understand the construct now. This is not a corner case. The utility of the construct becomes quite signi= ficant if you have an application that does concurrent path computations on= an abstract topology. Regards, -Pavan _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp -- DIETER BELLER ALCATEL-LUCENT DEUTSCHLAND AG PROJECT MANAGER ASON/GMPLS CONTROL PLANE CORE NETWORKS BUSINESS DIVISION OPTICS BU, SWITCHING R&D Lorenzstrasse 10 70435 Stuttgart, Germany Phone: +49 711 821 43125 Mobil: +49 175 7266874 Dieter.Beller@alcatel-lucent.com Alcatel-Lucent Deutschland AG Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026 Chairman of the Supervisory Board: Michael Oppenhoff Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe --_000_0182DEA5604B3A44A2EE61F3EE3ED69E1D4A56FABL2PRD0510MB349_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Sure

 <= /p>

Irrespectively Yours,

 <= /p>

John

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptical.com]
Sent: Wednesday, April 17, 2013 5:58 AM
To: John E Drake; Khuzema Pithewan; Vishnu Pavan Beeram
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

John,

You said:

JD:  The draft shoul= d note that MELGs have utility only in client networks that use centralized= concurrent path computation.

 <= /p>

If a client device needs = to compute two disjoint paths to a destination (e.g. for recovery purposes)= , the computation will be concurrent (of more than one paths), but not necessarily centralized. Note that MELGs need to be considered in = this case to avoid selecting  links belonging to different paths with = an MELG in common. Would you agree?

 <= /p>

Cheers,=

Igor

 <= /p>

From: John E D= rake [mailto:jdrake@juniper.net]
Sent: Wednesday, April 17, 2013 8:43 AM
To: Khuzema Pithewan; Igor Bryskin; Vishnu Pavan Beeram
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

Comments inline.

 <= /p>

Irrespectively Yours,

 <= /p>

John

 <= /p>

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Khuzema Pithewan
Sent: Wednesday, April 17, 2013 4:19 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Hi Igor and Pavan,=

 <= /p>

Thanks for the discussion= .

 <= /p>

I understand MELG proposa= l is not really precluding non-WDM server layer. I am trying to see, will i= t solve similar issues if they are there in more dynamic OTN (TDM) server layer.

 <= /p>

JD:  This is a very = good point.  While MELGs can be used in higher layer server networks, = they may not have any utility in these networks because these networks do not use physical resources directly.   

 <= /p>

MELG seems to be made use= ful by quite a bit of mgmt provisioning w.r.t. VLs and its path in server l= ayer.  It is one way, a client layer can make use of server layer resource information (for path computation). However, is it the typi= cal way?  I am not sure.

 <= /p>

JD:  The draft shoul= d note that MELGs have utility only in client networks that use centralized= concurrent path computation.

 <= /p>

Regds

Khuzema=

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Tuesday, April 16, 2013 7:50 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

Please, see in line.

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Tuesday, April 16, 2013 7:08 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

I am trying to summarize = the discussion we had so far. Pls see if my conclusion is in sync with the = idea of MELG you have

 <= /p>

MELG is useful when

1.      server layer VLs are nai= led down for the resources on the server layer links that are shared among = multiple VLs.

IB>> Correction: se= rver layer link-level paths supporting *client layer* VLs are nailed= down. The resources of said paths are sharable between the paths (and hence VLs) but not available for anything else.

 <= /p>

IB>> Server layer d= oes not have to be WDM

 <= /p>

IB>> Correction: Wa= velength is not the only type of resource that is used in WDM layer. If two= paths use the same transponder, converter, regenerator, etc. then corresponding VLs have a MELG in common. If two paths have a WDM link= in common on which they *must* use the same wavelength (e.g. becaus= e the paths are started on fixed transponders of the same frequency), then = they also have an MELG in common. If two paths have to use the same wavelength on a common WDM link because = this is the only wavelength available at the moment, then the VLs *do no= t* have an MELG in common (just  usual lack of resources on the li= nk)

 <= /p>

2.      server layer do not have= centralized path computation entity which can be used by client layer to a= sk for concurrent diverse path computation within server layer.

IB>> This approach = has nothing to do with VLs. VLs (just like real links) are supposed to be p= re-planned in a different time frame from when client layer connections are set up. When VLs are advertised, this means that the server layer path= s are successfully computed and pinned already (btw by server layer path co= mputer). Asking server layer path computation dynamically does not guarante= e  any success, so, if it fails, what to do next? You cannot orchestrate any restoration schemes in the cli= ent layer this way. Instaed, we suggest solid as_good_as_real Virtual Topol= ogy to use.

 <= /p>

3.      Client layer has a centr= alized path computation entity, which would compute paths for client+se= rver layer.

IB>> Correction: on= ly for client layer, based on client layer VLs

4.      The need is to centraliz= ed concurrent computation of more than one client+server layer path tha= t meets some diversity and resource exclusivity requirements.

IB>> Correction: th= ere is a need for concurrent path computation in the client layer and becau= se the client layer topology is virtual, you need MELGs to consider<= o:p>

 <= /p>

Regds

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Monday, April 15, 2013 9:44 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

Please, see in-line.

 <= /p>

Igor

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Monday, April 15, 2013 12:05 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

I understand the SRLG and= MELG behavior you have penned .

 <= /p>

My concern was little dif= ferent.  With changing resource consumption (because of dynamicity the= network has) in the network links, potential paths a set of virtual link can take will change and hence its MELG, as it is tied to a r= esource it can take. So unless virtual links paths are nailed down, it woul= d be hard to compute MELGs in distributed way.

 <= /p>

IB>> I think you ar= e missing the point here. Virtual Link server layer paths are pinned as far= as fate sharing is concerned (that is, they are pinned on  server layer link level). It would make little sense to advertise VL SRLGs if the= SRLGs constantly change. The same is true for MELGs.  SRLGs/MELGs adv= ertised for VLs normally do not change: neither over time nor when VLs beco= me committed/uncommitted.

 <= /p>

Another point is, virtual= links can be viewed as oversubscription of resources (in MELG context). Ta= king an example (for OTN, I know it would work differently for a Wavelength in WDM), a link resources are worth 1 TB of BW, user has = provisioned 20 virtual links of 100G each going via that OTN link.  Ph= ysically, only 10 will get committed. But which 10? It will really depend o= n network dynamics at the time of demand to commit. MELGs are not that effective here. You need some different mech= anism.

 <= /p>

IB>> As I mentioned= before MELGs have nothing to do with bandwidth and were never intended to = solve the problems such as you describe (just like it would not make much sense to solve such problem with SRLGs :=3D)

Again,  MELG is an e= xtreme case SRLG designed exclusively for VLs (no more and no less).=

 <= /p>

Regds

Khuzema=

 <= /p>

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 11:55 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

Think about MELG as an SR= LG that is shared between two or more links in its entirety. When two real = links have an SRLG in common, it means that two real links can co-exist concurrently, but there is something (e.g. common conduit, no= te that the conduit has room for more than for one link) that will bring bo= th these links down, if this something fails (e.g. conduit is cut ). Now co= nsider that this something must be taken in its entirety by one of the links to become operational . In th= is case SRLG becomes MELG. Note that MELG is only meaningful for virtual li= nks (unlike SRLG that makes sense for either real or virtual link). Why wou= ld you advertise two links that mutually exclude each other rather than advertising only one of them at a = time, unless the two are virtual links and hence both available for the cli= ent layer connections?

 <= /p>

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Friday, April 12, 2013 1:01 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

Do you mean, if virtual l= ink do not have any specific constraint, for example a link in the path (no= t talking about egress links/interfaces) must be traversed to realize the virtual link, there wont be any MELG for the virtual link?<= /span>

 <= /p>

Regds

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 9:52 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

MELGs have nothing to do = with bandwidth. MELG is a concrete network resource in a server layer that = two or more Virtual Links in a client layer depend on in a mutually exclusive way. An example of MELG is a WDM layer transponder th= at can terminate either of respective WDM layer tunnels (but not both at th= e same time) for two OTN layer Virtual Links. If you advertise a Virtual Li= nk, say, for Ethernet layer that depends on the connection in OTN layer going through one of the mentioned = OTN links, the Ethernet VL must inherit the MELG similarly like it does SRL= Gs advertised for the OTN links.

 <= /p>

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Friday, April 12, 2013 12:06 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

For multi-layer (more tha= n 2) network, consider all the layers are meshy (that’s when virtual = links are useful anyway), MELGs of virtual link will change as and when BW/wavelength availability changes, because potential paths, a vi= rtual link can take will change. Mapping lower layer MELGs to higher layer = MELGs won’t be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all the risk and paths (a PCE?), which ca= n be utilized for layer specific path computation (as it is doing it anyway= ).

 <= /p>

This kind of architecture= has all the pieces that are required for Inter-PCE communication (across l= ayers), except the protocol that would actually make the 2 PCEs talk.

 <= /p>

You seem to be doing some= thing that you don’t like J

 <= /p>

Regards=

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 8:39 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

I am not a fan of inter-l= ayer path computations (nor I am a fan of inter-PCE computations). In my mi= nd path computation for a service or services in layer X is performed only in layer X, i.e. considers only X layer links (real or v= irtual). As Pavan mentioned SRLGs and MELGs that need to be inherited from = lower layers should be translated into X layer link SRLGs/MELGs and specifi= ed with X layer specific SRLG/MELG IDs.

 <= /p>

Cheers,=

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infine= ra.com]
Sent: Friday, April 12, 2013 10:55 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

Ok. This would be useful = if network architecture is based on external PCE or mgmt entity as PCE in c= lient layer, but there is no counterpart in server layer, otherwise one could have inter-PCE communication to achieve diverse path i= n server layer without getting into virtual link and MELG stuff.

 <= /p>

Is that correct?

 <= /p>

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, April 12, 2013 6:36 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 <= /p>

2.       For cases of concurrent computation (case= #2-5), you are mainly talking about global optimization and diversity among= multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from th= e source end of those LSPs.  So there is no point in doing concurrent = computation at one network element for the services starting from multiple = network elements. At best it looks to me a problem to be solved by network management/planning software.&= nbsp;

Well, when an ingress nod= e is initiating a service, it is doing so on request from some management e= ntity. This management entity can compute paths for many services with some global criteria in mind, and then specify the resulting= paths as explicit EROs in provisioning requests sent to each of the servic= e ingresses. How else, for example,  you can set up several services o= riginated from different nodes that are disjoint from each other? Also, what is the point in your opinion of the s= tatefull PCE work?

 <= /p>

Cheers,=

Igor

 <= /p>

From: Vishnu P= avan Beeram [mailto:vishnupavan@gm= ail.com]
Sent: Friday, April 12, 2013 8:08 AM
To: Khuzema Pithewan
Cc: Igor Bryskin; Dieter Beller; c= camp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Khuzema, Hi!


Please see inline..

 

 

 1.       When Network has more than 2 layer i.e. P= acket-OTN-DWDM, the Packet (client) layer will be talking to its immediate = server layer i.e. OTN, which in turn is talking to DWDM layer. Using MELG, client layer path computation can take care of resource= exclusivity of virtual link for immediate server layer i.e. OTN layer.&nbs= p; However if there is resource exclusivity at DWDM layer, this mechanism d= oesn’t work. You need to do loose routing or use distributed PCE model

 

[VPB] The behavior is the same as what you would do = with SRLGs in a multi-layer architecture. There are architectures that allo= w the SRLGs in the lowest layer to be exported all the way up to the highes= t layer. The expectation is that MELGs would be treated in the same vein. 

2.       For cases of concurrent computation (case= #2-5), you are mainly talking about global optimization and diversity among= multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from th= e source end of those LSPs.  So there is no point in doing concurrent = computation at one network element for the services starting from multiple = network elements. At best it looks to me a problem to be solved by network management/planning software.&= nbsp;

[VPB]  I'm not sure why you think there is no p= oint in having a centralized computation function compute paths concurrentl= y for LSPs with different set of end-points. Even your NMS/planning-softwar= e can interact with such computation engine, retrieve all the paths and then go about initiating the path-setup from th= e ingress of each LSP. 

 

Regards,

-Pavan

 

 

 

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Tuesday, March 26, 2013 7:19 PM
To: Dieter Beller; Vishnu Pavan Beeram


Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Dieter,

 

You said:

>> I guess we are coming back to the essential point: "= and how often concurrent path computation will be >> used."

 

To be honest, this surprises me quite a bit, Let me give you some = of many reasons as to why concurrent path computations are needed and why t= his is better than computing one path at a time:

 

1.      = Computing several diverse paths for the same service in the context of serv= ice recovery. I hope you realize that computing one path at a time on many = configurations produces no or sub-optimal results. I also hope you realize the problem of selecting two paths with one of them  havi= ng a link with common MELG with a link from another path;

2.      = Computing paths for multiple services to be sufficiently disjoint from each= other;

3.      = Computing paths for multiple services to achieve a global optimization crit= eria (e.g. minimal summary total cost);

4.      = Computing paths for multiple services for the purpose of removing the bandw= idth fragmentations;

5.      = Computing paths for multiple services to plan shared mesh protection/restor= ation schemes

6.      = Etc.

 

Also think about this:

1.      = If concurrent path computation was not important, why PCEP includes the mac= hinery to do that?

2.      = My understanding of the statefull PCE is that it does pretty much nothing b= ut concurrent path computations

 

You also said:

>> I suppose that if a pce approach is used, i.e., path computatio= n is centralized including the
>> TE-DB, MELG routing extensions are not needed because the informat= ion about mutual
>>exclusive VLs can be kept in the central TE-DB when VLs are configu= red.

How this logic does not apply to other link attributes such as SRL= Gs?

What if path computation is not centralized?

 

Cheers,

Igor

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Hi Pavan,

On 25.03.2013 07:29, Fat= ai Zhang wrote:

Hi Pavan,

 

I am not sure how much VL (Virtual Link= ) will be used in the practical deployment and how often concurrent path computation will be used.

I guess we are coming back to the essential point: "and how often concurrent path computation will be used."

This means we are trying to figure out under which conditions MELG routing = extensions
could be beneficial.

IMHO, they would only make sense, if:

  • a path computation function supports the calculation of k shortest paths co= ncurrently
  • if there is only a single path computation function instance per domain (pc= e approach)
    If path computation is done in a distributed fashion the benefit goes away = because
    the instances calculate paths independently!

I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the
TE-DB, MELG routing extensions are not needed because the information about= mutual
exclusive VLs can be kept in the central TE-DB when VLs are configured.

Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their
applicability is broader.


Thanks,
Dieter

 

Do you think if it makes sense to add a flag (in= routing advertisement) to indicate a link is a VL or not?

 

 

 

Best Regards

 

Fatai

 

From: Vishnu Pavan Beeram [<= a href=3D"mailto:vishnupavan@gmail.com" target=3D"_blank">mailto:vishnupava= n@gmail.com]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Fatai, Hi!

 

Good to see that you understand the construct now.

 

This is not a corner case. The utility of the construct becomes qu= ite significant if you have an application that does concurrent path comput= ations on an abstract topology.

 

Regards,

-Pavan

 

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org=

https://www.ietf.org/mailman/listinfo/ccamp

 

--

DIETER BELLER

ALCATEL-LUCENT DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 = 711 821 43125
Mobil: +49 175 = 7266874

 

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe

 

--_000_0182DEA5604B3A44A2EE61F3EE3ED69E1D4A56FABL2PRD0510MB349_-- From internet-drafts@ietf.org Wed Apr 17 14:24:26 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E274021E80E2; Wed, 17 Apr 2013 14:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.083, 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 Wir7sSIF3RWx; Wed, 17 Apr 2013 14:24:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFF621E8096; Wed, 17 Apr 2013 14:24:00 -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.43.p4 Message-ID: <20130417212359.13836.61338.idtracker@ietfa.amsl.com> Date: Wed, 17 Apr 2013 14:23:59 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-swcaps-update-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 21:24:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Revised Definition of The GMPLS Switching Capability and= Type Fields Author(s) : Lou Berger Julien Meuric Filename : draft-ietf-ccamp-swcaps-update-01.txt Pages : 9 Date : 2013-04-17 Abstract: GMPLS provides control for multiple switching technologies, and hierarchical switching within a technology. GMPLS routing and signaling use common values to indicate switching technology type. These values are carried in routing in the Switching Capability field, and in signaling in the Switching Type field. While the values used in these fields are the primary indicators of the technology and hierarchy level being controlled, the values are not consistently defined and used across the different technologies supported by GMPLS. This document is intended to resolve the inconsistent definition and use of the Switching Capability and Type fields by narrowly scoping the meaning and use of the fields. This document updates any document that uses the GMPLS Switching Capability and Types fields, in particular RFC 3471, RFC 4202, RFC 4203, and RFC 5307. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-swcaps-update There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-swcaps-update-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-swcaps-update-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From db3546@att.com Thu Apr 18 09:31:13 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7AA21F91AB for ; Thu, 18 Apr 2013 09:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 COEpO7TA2z-D for ; Thu, 18 Apr 2013 09:31:12 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id A9EB021F91A5 for ; Thu, 18 Apr 2013 09:31:11 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id fcf10715.0.188469.00-449.523319.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 18 Apr 2013 16:31:12 +0000 (UTC) X-MXL-Hash: 51701fd03669ccf8-9679ef4fa7e568042df16f7cbe43402b067eedd3 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3IGVAI0002091; Thu, 18 Apr 2013 12:31:11 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3IGUwnn001870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Apr 2013 12:31:05 -0400 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Thu, 18 Apr 2013 16:30:46 GMT Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.02.0342.003; Thu, 18 Apr 2013 12:30:46 -0400 From: "BRUNGARD, DEBORAH A" To: "draft-ietf-ccamp-swcaps-update@tools.ietf.org" Thread-Topic: Regarding IPR on draft-ietf-ccamp-swcaps-update Thread-Index: Ac48UhReLneZEDjyQLy4l7D+kCDxJQ== Date: Thu, 18 Apr 2013 16:30:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.170.183] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C82BA684MISOUT7MSGUSR9OIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=P+yNcF8u c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=bAQ5c2AgFIIA:10 a=idK9lrBCv2EA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=CzPfIXQ_c] X-AnalysisOut: [6IA:10 a=48vgC7mUAAAA:8 a=J45sLU1KrpcSb-sg0VMA:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=DwJU1rvFuxJ] X-AnalysisOut: [J-Sun:21] Cc: "ccamp@ietf.org" Subject: [CCAMP] Regarding IPR on draft-ietf-ccamp-swcaps-update X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 16:31:13 -0000 --_000_F64C10EAA68C8044B33656FA214632C82BA684MISOUT7MSGUSR9OIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors, Contributors, (CCAMP) In preparation of this document for Last Call: Are you aware of any IPR that applies to draft-ietf-ccamp-swcaps-update? 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 answer the ab= ove by responding to this email regardless of whether or not you are aware of a= ny relevant IPR. This document will not advance to the next stage until a resp= onse has been received from each author and listed contributor. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules whi= ch encourages you to notify the IETF if you are aware of IPR of others on an I= ETF contribution, or to refrain from participating in any contribution or discu= ssion related to your undisclosed IPR. For more information, please see the RFCs= listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualPrope= rty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your respons= e. --_000_F64C10EAA68C8044B33656FA214632C82BA684MISOUT7MSGUSR9OIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Authors, Contributors, (CCAMP)
 
In preparation of this document for Last Call:
 
Are you aware of any IPR that applies to draft-ietf-ccamp-swcaps-updat= e?
 
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 answer t= he above
by responding to this email regardless of whether or not you are aware= of any
relevant IPR. This document will not advance to the next stage until a= response
has been received from each author and listed contributor.
 
If you are on the CCAMP WG email list but are not listed as an author = or
contributor, we remind you of your obligations under the IETF IPR rule= s which
encourages you to notify the IETF if you are aware of IPR of others on= an IETF
contribution, or to refrain from participating in any contribution or = discussion
related to your undisclosed IPR.  For more information, please se= e the RFCs listed
 
Thank you,
CCAMP WG Chairs
 
PS Please include all listed in the headers of this message in your re= sponse.
 
 
 --_000_F64C10EAA68C8044B33656FA214632C82BA684MISOUT7MSGUSR9OIT_-- From lberger@labn.net Thu Apr 18 11:04:57 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEC121F9021 for ; Thu, 18 Apr 2013 11:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.305 X-Spam-Level: X-Spam-Status: No, score=-100.305 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 t3XEvfT7imvC for ; Thu, 18 Apr 2013 11:04:57 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 389A721F9022 for ; Thu, 18 Apr 2013 11:04:57 -0700 (PDT) Received: (qmail 12554 invoked by uid 0); 18 Apr 2013 18:04:35 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 18 Apr 2013 18:04:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=nZbASsMN5qWTbVQ3nlAQUshk2ITxjwJ+hCZpy8HEzqs=; b=B8mHhW1t9Sgu9nqFtgEC+KD0jkoxNBhQ7zPZdRgle1MmPVKJ0Nvh3TEsefshK6XNtU2n9ND8amgTmv9X944ucEal92Yo1ruMe5c+MSlUES8G3ZXkIgqLVRTRl/vY8S82; Received: from box313.bluehost.com ([69.89.31.113]:59008 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UStCF-0000bK-Hw for ccamp@ietf.org; Thu, 18 Apr 2013 12:04:35 -0600 Message-ID: <517035B1.4060201@labn.net> Date: Thu, 18 Apr 2013 14:04:33 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: CCAMP References: <20130417212359.13836.61338.idtracker@ietfa.amsl.com> In-Reply-To: <20130417212359.13836.61338.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <20130417212359.13836.61338.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [CCAMP] Fwd: I-D Action: draft-ietf-ccamp-swcaps-update-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 18:04:57 -0000 FYI - This rev has editorial changes that we identified in our "pre-LC" review. Lou (and Julien) -------- Original Message -------- Subject: [CCAMP] I-D Action: draft-ietf-ccamp-swcaps-update-01.txt Date: Wed, 17 Apr 2013 14:23:59 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: ccamp@ietf.org 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 : Revised Definition of The GMPLS Switching Capability and Type Fields Author(s) : Lou Berger Julien Meuric Filename : draft-ietf-ccamp-swcaps-update-01.txt Pages : 9 Date : 2013-04-17 Abstract: GMPLS provides control for multiple switching technologies, and hierarchical switching within a technology. GMPLS routing and signaling use common values to indicate switching technology type. These values are carried in routing in the Switching Capability field, and in signaling in the Switching Type field. While the values used in these fields are the primary indicators of the technology and hierarchy level being controlled, the values are not consistently defined and used across the different technologies supported by GMPLS. This document is intended to resolve the inconsistent definition and use of the Switching Capability and Type fields by narrowly scoping the meaning and use of the fields. This document updates any document that uses the GMPLS Switching Capability and Types fields, in particular RFC 3471, RFC 4202, RFC 4203, and RFC 5307. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-swcaps-update There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-swcaps-update-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-swcaps-update-01 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 From lberger@labn.net Thu Apr 18 11:51:23 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B4521F90C5 for ; Thu, 18 Apr 2013 11:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.285 X-Spam-Level: X-Spam-Status: No, score=-101.285 tagged_above=-999 required=5 tests=[AWL=0.980, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 rWECpgOw+CWf for ; Thu, 18 Apr 2013 11:51:22 -0700 (PDT) Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 30C5221F8FDB for ; Thu, 18 Apr 2013 11:51:21 -0700 (PDT) Received: (qmail 16418 invoked by uid 0); 18 Apr 2013 18:06:11 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy14.unifiedlayer.com with SMTP; 18 Apr 2013 18:06:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=hje/atc5YVMEH3JjPla3cgKOODoIq7dPjB5Yl+5gn+U=; b=P0Q5H0opsCU39pKKlVC3Zkbw67QOtdFmyHL1aBqHEfajKQxR5RgRNbL9B28dxqjoIkeSqvF4/crn+7T1aQMCg1VHnrTj9iFpQIbJzGjfgIC7rkU42XG5nr8kl/S+/A5D; Received: from box313.bluehost.com ([69.89.31.113]:59292 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UStDm-0001ep-Sd; Thu, 18 Apr 2013 12:06:10 -0600 Message-ID: <51703611.70308@labn.net> Date: Thu, 18 Apr 2013 14:06:09 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "BRUNGARD, DEBORAH A" References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-swcaps-update X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 18:51:23 -0000 No, I'm not aware of any IPR that applies to this draft. Lou On 4/18/2013 12:30 PM, BRUNGARD, DEBORAH A wrote: > Authors, Contributors, (CCAMP) > > In preparation of this document for Last Call: > > Are you aware of any IPR that applies to draft-ietf-ccamp-swcaps-update? > > 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 answer the > above > by responding to this email regardless of whether or not you are aware > of any > relevant IPR. This document will not advance to the next stage until a > response > has been received from each author and listed contributor. > > If you are on the CCAMP WG email list but are not listed as an author or > contributor, we remind you of your obligations under the IETF IPR rules > which > encourages you to notify the IETF if you are aware of IPR of others on > an IETF > contribution, or to refrain from participating in any contribution or > discussion > related to your undisclosed IPR. For more information, please see the > RFCs listed > above and > _http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty_. > > Thank you, > CCAMP WG Chairs > > PS Please include all listed in the headers of this message in your > response. > > From turners@ieca.com Thu Apr 18 13:43:14 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC3F21F91B7 for ; Thu, 18 Apr 2013 13:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.321 X-Spam-Level: X-Spam-Status: No, score=-102.321 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 fVuD4lIcLAqC for ; Thu, 18 Apr 2013 13:43:13 -0700 (PDT) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.56.185.3]) by ietfa.amsl.com (Postfix) with ESMTP id 57E9021F91A2 for ; Thu, 18 Apr 2013 13:43:13 -0700 (PDT) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id D69A5D3217505; Thu, 18 Apr 2013 15:42:48 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway16.websitewelcome.com (Postfix) with ESMTP id C6FC5D32174D5 for ; Thu, 18 Apr 2013 15:42:48 -0500 (CDT) Received: from [108.18.174.101] (port=61688 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1USvfk-0006uP-RZ; Thu, 18 Apr 2013 15:43:12 -0500 Message-ID: <51705AE0.1080809@ieca.com> Date: Thu, 18 Apr 2013 16:43:12 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: rsvp-dir@ietf.org, mpls@ietf.org, ccamp@ietf.org, tsvwg@ietf.org References: <20130418203231.18593.73338.idtracker@ietfa.amsl.com> In-Reply-To: <20130418203231.18593.73338.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130418203231.18593.73338.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.18.174.101]:61688 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [CCAMP] Fwd: I-D Action: draft-turner-rsvp-auth-update-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 20:43:15 -0000 Apologies for those who get this multiple times, but I wanted to cover all the bases proposed by the TSV AD and the RTG ADs. draft-turner-rsvp-auth-update is a first attempt at adding cryptographic agility to RSVP. It's primarily motivated as a response to: https://datatracker.ietf.org/doc/draft-mahesh-karp-rsvp-te-analysis/ which highlights the need to provide cryptographic agility. draft-turner-rsvp-auth-update does *not* address automated key management. Comments are welcome. Note that we're not yet asking any WG to adopt it as we're still in the stages of determining if there's interest. However, my expectation was that assuming there was interest we'd target the tsvwg WG. spt -------- Original Message -------- Subject: I-D Action: draft-turner-rsvp-auth-update-01.txt Date: Thu, 18 Apr 2013 13:32:31 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Cryptographic Agility for the RSVP INTEGRITY Object Author(s) : Sean Turner Lou Berger Mahesh Jethanandani Keyur Patel Dacheng Zhang Filename : draft-turner-rsvp-auth-update-01.txt Pages : 7 Date : 2013-04-18 Abstract: This document modifies the RSVP INTEGRITY object to support algorithm agility by explicitly indicating the algorithm used. It also provides rationale for the design choices. Finally, it updates the mandatory to implement algorithm. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-turner-rsvp-auth-update There's also a htmlized version available at: http://tools.ietf.org/html/draft-turner-rsvp-auth-update-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-turner-rsvp-auth-update-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 zhangfatai@huawei.com Thu Apr 18 20:08:22 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812A421E803C for ; Thu, 18 Apr 2013 20:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, J_CHICKENPOX_66=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 DmABmuW4WaOw for ; Thu, 18 Apr 2013 20:08:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DD11221F9375 for ; Thu, 18 Apr 2013 20:08:08 -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 ARZ24716; Fri, 19 Apr 2013 03:08:06 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Apr 2013 04:07:48 +0100 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Apr 2013 04:08:02 +0100 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.222]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.007; Fri, 19 Apr 2013 11:07:56 +0800 From: Fatai Zhang To: Igor Bryskin , John E Drake , Khuzema Pithewan , Vishnu Pavan Beeram Thread-Topic: [CCAMP] MELGs - Q&A Thread-Index: AQHOIGPek8R0zdnmbUizkEjN3z7415ivh4owgAA2TQCAATLDIIAAeV3g///IfQCABM8nkIAAfXoAgAELY4CAGovgAIAAD52AgAAQMoCAAB55gIAAA70AgAAP9wCAAASVAIAACsYAgAAXnYCAA8Z+gIAAy+KAgAE80oCAADWBgIABX7KAgAAXlgCAAAQVgIADBYlQ Date: Fri, 19 Apr 2013 03:07:55 +0000 Message-ID: References: <5150C704.2040007@alcatel-lucent.com> <0182DEA5604B3A44A2EE61F3EE3ED69E1D4A5653@BL2PRD0510MB349.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF843175C4BSZXEML552MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] MELGs - Q&A X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 03:08:22 -0000 --_000_F82A4B6D50F9464B8EBA55651F541CF843175C4BSZXEML552MBXchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Igor, This case can be still regarded as centralized path computation, ie., multi= ple disjoint paths are computed by one single node. =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=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 If a client device needs to compute two disjoint paths to a destination (e.= g. for recovery purposes), the computation will be concurrent (of more than= one paths), but not necessarily centralized. Note that MELGs need to be co= nsidered in this case to avoid selecting links belonging to different path= s with an MELG in common. Would you agree? Best Regards Fatai From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of I= gor Bryskin Sent: Wednesday, April 17, 2013 8:58 PM To: John E Drake; Khuzema Pithewan; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A John, You said: JD: The draft should note that MELGs have utility only in client networks = that use centralized concurrent path computation. If a client device needs to compute two disjoint paths to a destination (e.= g. for recovery purposes), the computation will be concurrent (of more than= one paths), but not necessarily centralized. Note that MELGs need to be co= nsidered in this case to avoid selecting links belonging to different path= s with an MELG in common. Would you agree? Cheers, Igor From: John E Drake [mailto:jdrake@juniper.net] Sent: Wednesday, April 17, 2013 8:43 AM To: Khuzema Pithewan; Igor Bryskin; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Comments inline. Irrespectively Yours, John From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Khuzema Pithewan Sent: Wednesday, April 17, 2013 4:19 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Hi Igor and Pavan, Thanks for the discussion. I understand MELG proposal is not really precluding non-WDM server layer. I= am trying to see, will it solve similar issues if they are there in more d= ynamic OTN (TDM) server layer. JD: This is a very good point. While MELGs can be used in higher layer se= rver networks, they may not have any utility in these networks because thes= e networks do not use physical resources directly. MELG seems to be made useful by quite a bit of mgmt provisioning w.r.t. VLs= and its path in server layer. It is one way, a client layer can make use = of server layer resource information (for path computation). However, is it= the typical way? I am not sure. JD: The draft should note that MELGs have utility only in client networks = that use centralized concurrent path computation. Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Tuesday, April 16, 2013 7:50 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Please, see in line. From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Tuesday, April 16, 2013 7:08 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, I am trying to summarize the discussion we had so far. Pls see if my conclu= sion is in sync with the idea of MELG you have MELG is useful when 1. server layer VLs are nailed down for the resources on the server lay= er links that are shared among multiple VLs. IB>> Correction: server layer link-level paths supporting *client layer* VL= s are nailed down. The resources of said paths are sharable between the pat= hs (and hence VLs) but not available for anything else. These resources are typically wavelength on a fiber (can it be anything els= e??). IB>> Server layer does not have to be WDM In other words, if 2 VLs are pinned to use a particular wavelength on a par= ticular fiber, then these 2 VLs will have MELG for the wavelength. IB>> Correction: Wavelength is not the only type of resource that is used i= n WDM layer. If two paths use the same transponder, converter, regenerator,= etc. then corresponding VLs have a MELG in common. If two paths have a WDM= link in common on which they *must* use the same wavelength (e.g. because = the paths are started on fixed transponders of the same frequency), then th= ey also have an MELG in common. If two paths have to use the same wavelengt= h on a common WDM link because this is the only wavelength available at the= moment, then the VLs *do not* have an MELG in common (just usual lack of = resources on the link) 2. server layer do not have centralized path computation entity which c= an be used by client layer to ask for concurrent diverse path computation w= ithin server layer. IB>> This approach has nothing to do with VLs. VLs (just like real links) a= re supposed to be pre-planned in a different time frame from when client la= yer connections are set up. When VLs are advertised, this means that the se= rver layer paths are successfully computed and pinned already (btw by serve= r layer path computer). Asking server layer path computation dynamically do= es not guarantee any success, so, if it fails, what to do next? You cannot= orchestrate any restoration schemes in the client layer this way. Instaed,= we suggest solid as_good_as_real Virtual Topology to use. 3. Client layer has a centralized path computation entity, which would = compute paths for client+server layer. IB>> Correction: only for client layer, based on client layer VLs 4. The need is to centralized concurrent computation of more than one c= lient+server layer path that meets some diversity and resource exclusivity = requirements. IB>> Correction: there is a need for concurrent path computation in the cli= ent layer and because the client layer topology is virtual, you need MELGs = to consider Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Monday, April 15, 2013 9:44 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Please, see in-line. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Monday, April 15, 2013 12:05 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, I understand the SRLG and MELG behavior you have penned . My concern was little different. With changing resource consumption (becau= se of dynamicity the network has) in the network links, potential paths a s= et of virtual link can take will change and hence its MELG, as it is tied t= o a resource it can take. So unless virtual links paths are nailed down, it= would be hard to compute MELGs in distributed way. IB>> I think you are missing the point here. Virtual Link server layer path= s are pinned as far as fate sharing is concerned (that is, they are pinned = on server layer link level). It would make little sense to advertise VL SR= LGs if the SRLGs constantly change. The same is true for MELGs. SRLGs/MELG= s advertised for VLs normally do not change: neither over time nor when VLs= become committed/uncommitted. Another point is, virtual links can be viewed as oversubscription of resour= ces (in MELG context). Taking an example (for OTN, I know it would work dif= ferently for a Wavelength in WDM), a link resources are worth 1 TB of BW, u= ser has provisioned 20 virtual links of 100G each going via that OTN link. = Physically, only 10 will get committed. But which 10? It will really depen= d on network dynamics at the time of demand to commit. MELGs are not that e= ffective here. You need some different mechanism. IB>> As I mentioned before MELGs have nothing to do with bandwidth and were= never intended to solve the problems such as you describe (just like it wo= uld not make much sense to solve such problem with SRLGs :=3D) Again, MELG is an extreme case SRLG designed exclusively for VLs (no more = and no less). Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 11:55 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Think about MELG as an SRLG that is shared between two or more links in its= entirety. When two real links have an SRLG in common, it means that two re= al links can co-exist concurrently, but there is something (e.g. common con= duit, note that the conduit has room for more than for one link) that will = bring both these links down, if this something fails (e.g. conduit is cut )= . Now consider that this something must be taken in its entirety by one of = the links to become operational . In this case SRLG becomes MELG. Note that= MELG is only meaningful for virtual links (unlike SRLG that makes sense fo= r either real or virtual link). Why would you advertise two links that mutu= ally exclude each other rather than advertising only one of them at a time,= unless the two are virtual links and hence both available for the client l= ayer connections? Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 1:01 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Do you mean, if virtual link do not have any specific constraint, for examp= le a link in the path (not talking about egress links/interfaces) must be t= raversed to realize the virtual link, there wont be any MELG for the virtua= l link? Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 9:52 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, MELGs have nothing to do with bandwidth. MELG is a concrete network resourc= e in a server layer that two or more Virtual Links in a client layer depend= on in a mutually exclusive way. An example of MELG is a WDM layer transpon= der that can terminate either of respective WDM layer tunnels (but not both= at the same time) for two OTN layer Virtual Links. If you advertise a Virt= ual Link, say, for Ethernet layer that depends on the connection in OTN lay= er going through one of the mentioned OTN links, the Ethernet VL must inher= it the MELG similarly like it does SRLGs advertised for the OTN links. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 12:06 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, For multi-layer (more than 2) network, consider all the layers are meshy (t= hat's when virtual links are useful anyway), MELGs of virtual link will cha= nge as and when BW/wavelength availability changes, because potential paths= , a virtual link can take will change. Mapping lower layer MELGs to higher = layer MELGs won't be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all= the risk and paths (a PCE?), which can be utilized for layer specific path= computation (as it is doing it anyway). This kind of architecture has all the pieces that are required for Inter-PC= E communication (across layers), except the protocol that would actually ma= ke the 2 PCEs talk. You seem to be doing something that you don't like :) Regards Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 8:39 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, I am not a fan of inter-layer path computations (nor I am a fan of inter-PC= E computations). In my mind path computation for a service or services in l= ayer X is performed only in layer X, i.e. considers only X layer links (rea= l or virtual). As Pavan mentioned SRLGs and MELGs that need to be inherited= from lower layers should be translated into X layer link SRLGs/MELGs and s= pecified with X layer specific SRLG/MELG IDs. Cheers, Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 10:55 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Ok. This would be useful if network architecture is based on external PCE o= r mgmt entity as PCE in client layer, but there is no counterpart in server= layer, otherwise one could have inter-PCE communication to achieve diverse= path in server layer without getting into virtual link and MELG stuff. Is that correct? Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 6:36 PM To: Vishnu Pavan Beeram; Khuzema Pithewan Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. Well, when an ingress node is initiating a service, it is doing so on reque= st from some management entity. This management entity can compute paths fo= r many services with some global criteria in mind, and then specify the res= ulting paths as explicit EROs in provisioning requests sent to each of the = service ingresses. How else, for example, you can set up several services = originated from different nodes that are disjoint from each other? Also, wh= at is the point in your opinion of the statefull PCE work? Cheers, Igor From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, April 12, 2013 8:08 AM To: Khuzema Pithewan Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Khuzema, Hi! Please see inline.. 1. When Network has more than 2 layer i.e. Packet-OTN-DWDM, the Pack= et (client) layer will be talking to its immediate server layer i.e. OTN, w= hich in turn is talking to DWDM layer. Using MELG, client layer path comput= ation can take care of resource exclusivity of virtual link for immediate s= erver layer i.e. OTN layer. However if there is resource exclusivity at DW= DM layer, this mechanism doesn't work. You need to do loose routing or use = distributed PCE model [VPB] The behavior is the same as what you would do with SRLGs in a multi-l= ayer architecture. There are architectures that allow the SRLGs in the lowe= st layer to be exported all the way up to the highest layer. The expectatio= n is that MELGs would be treated in the same vein. 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. [VPB] I'm not sure why you think there is no point in having a centralized= computation function compute paths concurrently for LSPs with different se= t of end-points. Even your NMS/planning-software can interact with such com= putation engine, retrieve all the paths and then go about initiating the pa= th-setup from the ingress of each LSP. Regards, -Pavan From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Igor Bryskin Sent: Tuesday, March 26, 2013 7:19 PM To: Dieter Beller; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Dieter, You said: >> I guess we are coming back to the essential point: "and how often concur= rent path computation will be >> used." To be honest, this surprises me quite a bit, Let me give you some of many r= easons as to why concurrent path computations are needed and why this is be= tter than computing one path at a time: 1. Computing several diverse paths for the same service in the context= of service recovery. I hope you realize that computing one path at a time = on many configurations produces no or sub-optimal results. I also hope you = realize the problem of selecting two paths with one of them having a link = with common MELG with a link from another path; 2. Computing paths for multiple services to be sufficiently disjoint f= rom each other; 3. Computing paths for multiple services to achieve a global optimizat= ion criteria (e.g. minimal summary total cost); 4. Computing paths for multiple services for the purpose of removing t= he bandwidth fragmentations; 5. Computing paths for multiple services to plan shared mesh protectio= n/restoration schemes 6. Etc. Also think about this: 1. If concurrent path computation was not important, why PCEP includes= the machinery to do that? 2. My understanding of the statefull PCE is that it does pretty much n= othing but concurrent path computations You also said: >> I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the >> TE-DB, MELG routing extensions are not needed because the information ab= out mutual >>exclusive VLs can be kept in the central TE-DB when VLs are configured. How this logic does not apply to other link attributes such as SRLGs? What if path computation is not centralized? Cheers, Igor From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Dieter Beller Sent: Monday, March 25, 2013 5:52 PM To: Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Hi Pavan, On 25.03.2013 07:29, Fatai Zhang wrote: Hi Pavan, I am not sure how much VL (Virtual Link) will be used in the practical depl= oyment and how often concurrent path computation will be used. I guess we are coming back to the essential point: "and how often concurren= t path computation will be used." This means we are trying to figure out under which conditions MELG routing = extensions could be beneficial. IMHO, they would only make sense, if: * a path computation function supports the calculation of k shortest pa= ths concurrently * if there is only a single path computation function instance per doma= in (pce approach) If path computation is done in a distributed fashion the benefit goes away = because the instances calculate paths independently! I suppose that if a pce approach is used, i.e., path computation is central= ized including the TE-DB, MELG routing extensions are not needed because the information about= mutual exclusive VLs can be kept in the central TE-DB when VLs are configured. Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their applicability is broader. Thanks, Dieter Do you think if it makes sense to add a flag (in routing advertisement) to = indicate a link is a VL or not? Best Regards Fatai From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, March 22, 2013 8:57 PM To: Fatai Zhang Cc: Igor Bryskin; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Fatai, Hi! Good to see that you understand the construct now. This is not a corner case. The utility of the construct becomes quite signi= ficant if you have an application that does concurrent path computations on= an abstract topology. Regards, -Pavan _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp -- DIETER BELLER ALCATEL-LUCENT DEUTSCHLAND AG PROJECT MANAGER ASON/GMPLS CONTROL PLANE CORE NETWORKS BUSINESS DIVISION OPTICS BU, SWITCHING R&D Lorenzstrasse 10 70435 Stuttgart, Germany Phone: +49 711 821 43125 Mobil: +49 175 7266874 Dieter.Beller@alcatel-lucent.com Alcatel-Lucent Deutschland AG Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026 Chairman of the Supervisory Board: Michael Oppenhoff Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe --_000_F82A4B6D50F9464B8EBA55651F541CF843175C4BSZXEML552MBXchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Igor,

 = ;

This case = can be still regarded as centralized path computation, ie., multiple disjoi= nt paths are computed by one single node.

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

If a clien= t device needs to compute two disjoint paths to a destination (e.g. for rec= overy purposes), the computation will be concurrent (of more than one paths), but not necessarily centralized. Note that MELGs need to = be considered in this case to avoid selecting  links belonging to diff= erent paths with an MELG in common. Would you agree?

 

 

 

 

Best Regards

 

Fatai

 = ;

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org= ] On Behalf Of Igor Bryskin
Sent: Wednesday, April 17, 2013 8:58 PM
To: John E Drake; Khuzema Pithewan; Vishnu Pavan Beeram
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

John,

You said:<= /span>

JD:  = The draft should note that MELGs have utility only in client networks that = use centralized concurrent path computation.

 

If a clien= t device needs to compute two disjoint paths to a destination (e.g. for rec= overy purposes), the computation will be concurrent (of more than one paths), but not necessarily centralized. Note that MELGs need to = be considered in this case to avoid selecting  links belonging to diff= erent paths with an MELG in common. Would you agree?

 

Cheers,

Igor

 

From: John E Drake [mailto:jdrake@juniper.net]
Sent: Wednesday, April 17, 2013 8:43 AM
To: Khuzema Pithewan; Igor Bryskin; Vishnu Pavan Beeram
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

Comments i= nline.

 

Irrespecti= vely Yours,

 

John

 

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Khuzema Pithewan
Sent: Wednesday, April 17, 2013 4:19 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Hi Igor an= d Pavan,

 

Thanks for= the discussion.

 

I understa= nd MELG proposal is not really precluding non-WDM server layer. I am trying= to see, will it solve similar issues if they are there in more dynamic OTN (TDM) server layer.

 

JD:  = This is a very good point.  While MELGs can be used in higher layer se= rver networks, they may not have any utility in these networks because these networks do not use physical resources directly.   =

 

MELG seems= to be made useful by quite a bit of mgmt provisioning w.r.t. VLs and its p= ath in server layer.  It is one way, a client layer can make use of server layer resource information (for path computation). However, = is it the typical way?  I am not sure.

 

JD:  = The draft should note that MELGs have utility only in client networks that = use centralized concurrent path computation.

 

Regds

Khuzema

 

 

 

 

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Tuesday, April 16, 2013 7:50 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

Please, se= e in line.

 

From: Khuzema Pithewan [mailto:kpithewan@infinera.com]
Sent: Tuesday, April 16, 2013 7:08 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

I am tryin= g to summarize the discussion we had so far. Pls see if my conclusion is in= sync with the idea of MELG you have

 

MELG is us= eful when

1. &nbs= p;   se= rver layer VLs are nailed down for the resources on the server layer links = that are shared among multiple VLs.

IB>>= Correction: server layer link-level paths supporting *client layer*= VLs are nailed down. The resources of said paths are sharable between the paths (and hence VLs) but not available for anything else.

 

These resources are typically wavelength on a fiber (can= it be anything else??).

IB>>= Server layer does not have to be WDM

 

In other words, if 2 VLs are pinned to use a particular = wavelength on a particular fiber, then these 2 VLs will have MELG for the wavelength.

IB>>= Correction: Wavelength is not the only type of resource that is used in WD= M layer. If two paths use the same transponder, converter, regenerator, etc. then corresponding VLs have a MELG in common. If two paths have a WDM= link in common on which they *must* use the same wavelength (e.g. b= ecause the paths are started on fixed transponders of the same frequency), = then they also have an MELG in common. If two paths have to use the same wavelength on a common WDM link because = this is the only wavelength available at the moment, then the VLs *do no= t* have an MELG in common (just  usual lack of resources on the li= nk)

 

2. &nbs= p;   se= rver layer do not have centralized path computation entity which can be use= d by client layer to ask for concurrent diverse path computation within server layer.

IB>>= This approach has nothing to do with VLs. VLs (just like real links) are s= upposed to be pre-planned in a different time frame from when client layer connections are set up. When VLs are advertised, this means that the= server layer paths are successfully computed and pinned already (btw by se= rver layer path computer). Asking server layer path computation dynamically= does not guarantee  any success, so, if it fails, what to do next? You cannot orchestrate any restoration s= chemes in the client layer this way. Instaed, we suggest solid as_good_as_r= eal Virtual Topology to use.

 

3. &nbs= p;   Cl= ient layer has a centralized path computation entity, which would compute p= aths for client+server layer.

IB>>= Correction: only for client layer, based on client layer VLs

4. &nbs= p;   Th= e need is to centralized concurrent computation of more than one client+= ;server layer path that meets some diversity and resource exclusivity requirements.

IB>>= Correction: there is a need for concurrent path computation in the client = layer and because the client layer topology is virtual, you need MELGs to consider

 

Regds

Khuzema

 

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Monday, April 15, 2013 9:44 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

Please, se= e in-line.

 

Igor

 

From: Khuzema Pithewan [mailto:kpithewan@infinera.com]
Sent: Monday, April 15, 2013 12:05 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

I understa= nd the SRLG and MELG behavior you have penned .=

 

My concern= was little different.  With changing resource consumption (because of= dynamicity the network has) in the network links, potential paths a set of virtual link can take will change and hence its MELG, as it is ti= ed to a resource it can take. So unless virtual links paths are nailed down= , it would be hard to compute MELGs in distributed way.

 

IB>>= I think you are missing the point here. Virtual Link server layer paths ar= e pinned as far as fate sharing is concerned (that is, they are pinned on  server layer link level). It would make little sense to ad= vertise VL SRLGs if the SRLGs constantly change. The same is true for MELGs= .  SRLGs/MELGs advertised for VLs normally do not change: neither over= time nor when VLs become committed/uncommitted.

 

Another po= int is, virtual links can be viewed as oversubscription of resources (in ME= LG context). Taking an example (for OTN, I know it would work differently for a Wavelength in WDM), a link resources are worth 1 TB of B= W, user has provisioned 20 virtual links of 100G each going via that OTN li= nk.  Physically, only 10 will get committed. But which 10? It will rea= lly depend on network dynamics at the time of demand to commit. MELGs are not that effective here. You need some= different mechanism.

 

IB>>= As I mentioned before MELGs have nothing to do with bandwidth and were nev= er intended to solve the problems such as you describe (just like it would not make much sense to solve such problem with SRLGs :=3D)=

Again, &nb= sp;MELG is an extreme case SRLG designed exclusively for VLs (no more and n= o less).

 

Regds

Khuzema

 

 

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 11:55 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

Think abou= t MELG as an SRLG that is shared between two or more links in its entirety.= When two real links have an SRLG in common, it means that two real links can co-exist concurrently, but there is something (e.g. com= mon conduit, note that the conduit has room for more than for one link) tha= t will bring both these links down, if this something fails (e.g. conduit i= s cut ). Now consider that this something must be taken in its entirety by one of the links to become oper= ational . In this case SRLG becomes MELG. Note that MELG is only meaningful= for virtual links (unlike SRLG that makes sense for either real or virtual= link). Why would you advertise two links that mutually exclude each other rather than advertising only on= e of them at a time, unless the two are virtual links and hence both availa= ble for the client layer connections?

 

Igor

 

 

From: Khuzema Pithewan [mailto:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 1:01 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

Do you mea= n, if virtual link do not have any specific constraint, for example a link = in the path (not talking about egress links/interfaces) must be traversed to realize the virtual link, there wont be any MELG for the v= irtual link?

 

Regds

Khuzema

 

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 9:52 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

MELGs have= nothing to do with bandwidth. MELG is a concrete network resource in a ser= ver layer that two or more Virtual Links in a client layer depend on in a mutually exclusive way. An example of MELG is a WDM layer t= ransponder that can terminate either of respective WDM layer tunnels (but n= ot both at the same time) for two OTN layer Virtual Links. If you advertise= a Virtual Link, say, for Ethernet layer that depends on the connection in OTN layer going through one of the= mentioned OTN links, the Ethernet VL must inherit the MELG similarly like = it does SRLGs advertised for the OTN links.

 

Igor

 

 

From: Khuzema Pithewan [mailto:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 12:06 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

For multi-= layer (more than 2) network, consider all the layers are meshy (that’= s when virtual links are useful anyway), MELGs of virtual link will change as and when BW/wavelength availability changes, because potential p= aths, a virtual link can take will change. Mapping lower layer MELGs to hig= her layer MELGs won’t be practical if done in distributed manner, so = it has to be centralized. So you do have central element in each layer that knows all the risk and paths (a PCE?), = which can be utilized for layer specific path computation (as it is doing i= t anyway).

 

This kind = of architecture has all the pieces that are required for Inter-PCE communic= ation (across layers), except the protocol that would actually make the 2 PCEs talk.

 

You seem t= o be doing something that you don’t like J

 

Regards

Khuzema

 

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 8:39 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

I am not a= fan of inter-layer path computations (nor I am a fan of inter-PCE computat= ions). In my mind path computation for a service or services in layer X is performed only in layer X, i.e. considers only X layer links= (real or virtual). As Pavan mentioned SRLGs and MELGs that need to be inhe= rited from lower layers should be translated into X layer link SRLGs/MELGs = and specified with X layer specific SRLG/MELG IDs.

 

Cheers,

Igor

 

 

From: Khuzema Pithewan [mailto:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 10:55 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

Ok. This w= ould be useful if network architecture is based on external PCE or mgmt ent= ity as PCE in client layer, but there is no counterpart in server layer, otherwise one could have inter-PCE communication to achieve = diverse path in server layer without getting into virtual link and MELG stu= ff.

 

Is that co= rrect?

 

Khuzema

 

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 6:36 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

2= . =       For cases of concurrent co= mputation (case#2-5), you are mainly talking about global optimization and = diversity among multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done fro= m the source end of those LSPs.  So there is no point in doing concurr= ent computation at one network element for the services starting from multi= ple network elements. At best it looks to me a problem to be solved by network management/planning software. 

Well, when= an ingress node is initiating a service, it is doing so on request from so= me management entity. This management entity can compute paths for many services with some global criteria in mind, and then specify the = resulting paths as explicit EROs in provisioning requests sent to each of t= he service ingresses. How else, for example,  you can set up several s= ervices originated from different nodes that are disjoint from each other? Also, what is the point in your opinion= of the statefull PCE work?

 

Cheers,

Igor

 

From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com]
Sent: Friday, April 12, 2013 8:08 AM
To: Khuzema Pithewan
Cc: Igor Bryskin; Dieter Beller; c= camp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Khuzema, Hi!<= /p>


Please see inline..

 

 

 1.    = ;   When Network has more than= 2 layer i.e. Packet-OTN-DWDM, the Packet (client) layer will be talking to= its immediate server layer i.e. OTN, which in turn is talking to DWDM layer. Using MELG, client layer path computation can take care of = resource exclusivity of virtual link for immediate server layer i.e. OTN la= yer.  However if there is resource exclusivity at DWDM layer, this mec= hanism doesn’t work. You need to do loose routing or use distributed PCE model

 

[VPB] The behavior is the same = as what you would do with SRLGs in a multi-layer architecture. There are ar= chitectures that allow the SRLGs in the lowest layer to be exported all the= way up to the highest layer. The expectation is that MELGs would be treated in the same vein. 

2= . =       For cases of concurrent co= mputation (case#2-5), you are mainly talking about global optimization and = diversity among multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done fro= m the source end of those LSPs.  So there is no point in doing concurr= ent computation at one network element for the services starting from multi= ple network elements. At best it looks to me a problem to be solved by network management/planning software. 

[VPB]  I'm not sure why yo= u think there is no point in having a centralized computation function comp= ute paths concurrently for LSPs with different set of end-points. Even your= NMS/planning-software can interact with such computation engine, retrieve all the paths and then go about initiati= ng the path-setup from the ingress of each LSP. 

 

Regards,

-Pavan

 

 

 

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Tuesday, March 26, 2013 7:19 PM
To: Dieter Beller; Vishnu Pavan Beeram


Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Dieter,

 

You said:

>> I guess we are coming back to the es= sential point: "and how often concurrent path computation will be >> used."

 

To be honest, this surprises me quite a bit, = Let me give you some of many reasons as to why concurrent path computations= are needed and why this is better than computing one path at a time:

 

1.      Computing several diverse paths for the same service i= n the context of service recovery. I hope you realize that computing one pa= th at a time on many configurations produces no or sub-optimal results. I a= lso hope you realize the problem of selecting two paths with one of them  having a link with common MELG = with a link from another path;

2.      Computing paths for multiple services to be sufficient= ly disjoint from each other;

3.      Computing paths for multiple services to achieve a glo= bal optimization criteria (e.g. minimal summary total cost);

4.      Computing paths for multiple services for the purpose = of removing the bandwidth fragmentations;

5.      Computing paths for multiple services to plan shared m= esh protection/restoration schemes

6.      Etc.

 

Also think about this:

1.      If concurrent path computation was not important, why = PCEP includes the machinery to do that?

2.      My understanding of the statefull PCE is that it does = pretty much nothing but concurrent path computations

 

You also said:

>> I suppose that if a pce approach is used, = i.e., path computation is centralized including the
>> TE-DB, MELG routing extensions are not needed because the informat= ion about mutual
>>exclusive VLs can be kept in the central TE-DB when VLs are configu= red.

How this logic does not apply to other link a= ttributes such as SRLGs?

What if path computation is not centralized?<= o:p>

 

Cheers,

Igor

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Hi Pavan,

On 25.03.2013 07:29, Fat= ai Zhang wrote:

Hi Pavan,

 

I am not sure how much V= L (Virtual Link) will be used in the practical deployment and how often concurrent path computation will be used.

I guess we are coming back to the essential p= oint: "and how often concurrent path computation will be used."

This means we are trying to figure out under which conditions MELG routing = extensions
could be beneficial.

IMHO, they would only make sense, if:

  • a path computation function supports the calculation o= f k shortest paths concurrently
  • if there is only a single path computation function in= stance per domain (pce approach)
    If path computation is done in a distributed fashion the benefit goes away = because
    the instances calculate paths independently!

I suppose that if a pce approach is used, i.e., pat= h computation is centralized including the
TE-DB, MELG routing extensions are not needed because the information about= mutual
exclusive VLs can be kept in the central TE-DB when VLs are configured.

Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their
applicability is broader.


Thanks,
Dieter

 

Do you think if it makes sense to= add a flag (in routing advertisement) to indicate a link is a VL or not?

 

 

 

Best Regards

 

Fatai=

 

From: Vishnu Pavan Beeram [m= ailto:vishnupavan@gmail.com]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Fatai, Hi!

 

Good to see that you understand the construct= now.

 

This is not a corner case. The utility of the= construct becomes quite significant if you have an application that does c= oncurrent path computations on an abstract topology.

 

Regards,

-Pavan

 

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

 

--

DIETER BELLE= R

ALCATEL-LUCENT DEUTSCHLAN= D AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 = 711 821 43125
Mobil: +49 175 = 7266874

 

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe

 

--_000_F82A4B6D50F9464B8EBA55651F541CF843175C4BSZXEML552MBXchi_-- From zhangfatai@huawei.com Thu Apr 18 20:26:04 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7251621F93A3 for ; Thu, 18 Apr 2013 20:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=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 vzKmomMnKG+w for ; Thu, 18 Apr 2013 20:25:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 19D8421F9375 for ; Thu, 18 Apr 2013 20:25:48 -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 ARZ25660; Fri, 19 Apr 2013 03:25:48 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Apr 2013 04:25:32 +0100 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Apr 2013 11:25:45 +0800 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.222]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.007; Fri, 19 Apr 2013 11:25:42 +0800 From: Fatai Zhang To: Vishnu Pavan Beeram , Khuzema Pithewan , Igor Bryskin , Dieter Beller Thread-Topic: [CCAMP] MELGs - Q&A Thread-Index: AQHOIGPek8R0zdnmbUizkEjN3z7415ivh4owgAA2TQCAATLDIIAAeV3g///IfQCABM8nkIAAfXoAgAELY4CAGovgAIAAD52AgAAQMoCAAB55gIAAA70AgAAP9wCAAASVAIAACsYAgAAXnYCAA8Z+gIAAy+KAgAE80oCAADLWAIAEhDjA Date: Fri, 19 Apr 2013 03:25:42 +0000 Message-ID: References: <5150C704.2040007@alcatel-lucent.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF843175C60SZXEML552MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] MELGs - Q&A X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 03:26:04 -0000 --_000_F82A4B6D50F9464B8EBA55651F541CF843175C60SZXEML552MBXchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Pavan, Igor I think there are some concerns about the applicability of MELGs and I have= the same feeling as Khuzema and Dieter. I still think that MELGS can only handle a very small corner case as you pu= t many cases below where MELGs are not needed. What is Virtual Link? As described in RFC6001, it says as below. So my ques= tion is: when there are two VLs created through Call approach as defined in= RFC6001, one has 3 potential paths in the server layer to setup FA-LSP, an= d another has 2 potential paths in the server layer, and only one of the 3 = &2 has the same resource shared in the server layer. How MELGs can help in this case? =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=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 A virtual TE link is defined as a TE link between two upper-layer nodes tha= t is not associated with a fully provisioned FA-LSP in a lower layer [RFC52= 12]. A virtual TE link is advertised a= s any TE link, following the rules in [RFC4206] defined for fully provisioned TE links. A virtual TE link represe= nts thus the potentiality to set up an FA-LSP in the lower layer to support= the TE link that has been advertised. =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=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 Best Regards Fatai From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of V= ishnu Pavan Beeram Sent: Tuesday, April 16, 2013 10:10 PM To: Khuzema Pithewan Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Khuzema, Hi! MELGs are useful and come into play only when: (1) The server network domain is abstracted and the advertised Virtual TE-l= inks possess some mutual exclusivity relationship. (2) There is a Centralized path computation entity in the client domain (co= mputes paths in terms of Client TE-links/TE-nodes) that is capable of doing= concurrent path computations. If either of the above 2 statements is NOT true, there is no utility for ME= LGs. At the risk of being pedantic: - Are MELGs needed when the server-network domain in not abstracted (no Vir= tual TE links)? The answer is NO. - Are MELGs needed when you have a distributed path-computation architectur= e (Client PCE interacting with Server PCE)? The answer is NO. - Are MELGs needed when the centralized path-computation engine doesn't (ca= n't) do concurrent computations? The answer is NO. The actual procedures involved in abstracting the server network domain is = beyond the scope of . The abstraction procedure itself is impl= ementation-specific (maybe someday someone would put together a draft for d= iscussing this). Though it is true that the primary use-case we had in mind= when coming up with this new construct involves a lambda-layer server netw= ork domain, there is really no restriction (at a conceptual level) on using= this construct when abstracting a packet-layer server network domain or a = TDM-layer server network domain. It is up to the implementation on how to m= ake best use of this construct. When you advertise a Virtual TE-link into a client network domain, you are = doing this based on the existence of some potential underlying server-path.= TE attributes like SRLGs, MELGs, delay etc that get advertised for the Vir= tual TE-link depend on the underlying server-path that is chosen for cateri= ng to this Client TE-link. If the underlying server-path keeps changing (ba= sed on network events), these TE attributes would also keep changing. The p= rocedure for keeping the advertised information "current" is an implementat= ion choice. If there exists such a thing as an abstraction manager (again, this is tota= lly implementation specific), then the assumption is that it does one of th= e following - (a) computes new server-paths for the Virtual TE links whenever there is a = change in the network (may not be very scalable in some architectures), (b) or does periodic path-computation for each Virtual TE link, (c) or uses a policy to pin down the Virtual TE-link to a specific underlyi= ng server-path, (d) or uses a combination of (a), (b), (c). doesn't make any recommendation as to what choice the abstrac= tion manager would need to take. Hope this helps. -Pavan On Tue, Apr 16, 2013 at 7:08 AM, Khuzema Pithewan > wrote: Hi Igor, I am trying to summarize the discussion we had so far. Pls see if my conclu= sion is in sync with the idea of MELG you have MELG is useful when 1. server layer VLs are nailed down for the resources on the server l= ayer links that are shared among multiple VLs. These resources are typicall= y wavelength on a fiber (can it be anything else??). In other words, if 2 V= Ls are pinned to use a particular wavelength on a particular fiber, then th= ese 2 VLs will have MELG for the wavelength. 2. server layer do not have centralized path computation entity which= can be used by client layer to ask for concurrent diverse path computation= within server layer. 3. Client layer has a centralized path computation entity, which woul= d compute paths for client+server layer. 4. The need is to centralized concurrent computation of more than one= client+server layer path that meets some diversity and resource exclusivit= y requirements. Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Monday, April 15, 2013 9:44 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Please, see in-line. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Monday, April 15, 2013 12:05 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, I understand the SRLG and MELG behavior you have penned . My concern was little different. With changing resource consumption (becau= se of dynamicity the network has) in the network links, potential paths a s= et of virtual link can take will change and hence its MELG, as it is tied t= o a resource it can take. So unless virtual links paths are nailed down, it= would be hard to compute MELGs in distributed way. IB>> I think you are missing the point here. Virtual Link server layer path= s are pinned as far as fate sharing is concerned (that is, they are pinned = on server layer link level). It would make little sense to advertise VL SR= LGs if the SRLGs constantly change. The same is true for MELGs. SRLGs/MELG= s advertised for VLs normally do not change: neither over time nor when VLs= become committed/uncommitted. Another point is, virtual links can be viewed as oversubscription of resour= ces (in MELG context). Taking an example (for OTN, I know it would work dif= ferently for a Wavelength in WDM), a link resources are worth 1 TB of BW, u= ser has provisioned 20 virtual links of 100G each going via that OTN link. = Physically, only 10 will get committed. But which 10? It will really depen= d on network dynamics at the time of demand to commit. MELGs are not that e= ffective here. You need some different mechanism. IB>> As I mentioned before MELGs have nothing to do with bandwidth and were= never intended to solve the problems such as you describe (just like it wo= uld not make much sense to solve such problem with SRLGs :=3D) Again, MELG is an extreme case SRLG designed exclusively for VLs (no more = and no less). Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 11:55 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Think about MELG as an SRLG that is shared between two or more links in its= entirety. When two real links have an SRLG in common, it means that two re= al links can co-exist concurrently, but there is something (e.g. common con= duit, note that the conduit has room for more than for one link) that will = bring both these links down, if this something fails (e.g. conduit is cut )= . Now consider that this something must be taken in its entirety by one of = the links to become operational . In this case SRLG becomes MELG. Note that= MELG is only meaningful for virtual links (unlike SRLG that makes sense fo= r either real or virtual link). Why would you advertise two links that mutu= ally exclude each other rather than advertising only one of them at a time,= unless the two are virtual links and hence both available for the client l= ayer connections? Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 1:01 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Do you mean, if virtual link do not have any specific constraint, for examp= le a link in the path (not talking about egress links/interfaces) must be t= raversed to realize the virtual link, there wont be any MELG for the virtua= l link? Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 9:52 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, MELGs have nothing to do with bandwidth. MELG is a concrete network resourc= e in a server layer that two or more Virtual Links in a client layer depend= on in a mutually exclusive way. An example of MELG is a WDM layer transpon= der that can terminate either of respective WDM layer tunnels (but not both= at the same time) for two OTN layer Virtual Links. If you advertise a Virt= ual Link, say, for Ethernet layer that depends on the connection in OTN lay= er going through one of the mentioned OTN links, the Ethernet VL must inher= it the MELG similarly like it does SRLGs advertised for the OTN links. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 12:06 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, For multi-layer (more than 2) network, consider all the layers are meshy (t= hat's when virtual links are useful anyway), MELGs of virtual link will cha= nge as and when BW/wavelength availability changes, because potential paths= , a virtual link can take will change. Mapping lower layer MELGs to higher = layer MELGs won't be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all= the risk and paths (a PCE?), which can be utilized for layer specific path= computation (as it is doing it anyway). This kind of architecture has all the pieces that are required for Inter-PC= E communication (across layers), except the protocol that would actually ma= ke the 2 PCEs talk. You seem to be doing something that you don't like :) Regards Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 8:39 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, I am not a fan of inter-layer path computations (nor I am a fan of inter-PC= E computations). In my mind path computation for a service or services in l= ayer X is performed only in layer X, i.e. considers only X layer links (rea= l or virtual). As Pavan mentioned SRLGs and MELGs that need to be inherited= from lower layers should be translated into X layer link SRLGs/MELGs and s= pecified with X layer specific SRLG/MELG IDs. Cheers, Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 10:55 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Ok. This would be useful if network architecture is based on external PCE o= r mgmt entity as PCE in client layer, but there is no counterpart in server= layer, otherwise one could have inter-PCE communication to achieve diverse= path in server layer without getting into virtual link and MELG stuff. Is that correct? Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 6:36 PM To: Vishnu Pavan Beeram; Khuzema Pithewan Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. Well, when an ingress node is initiating a service, it is doing so on reque= st from some management entity. This management entity can compute paths fo= r many services with some global criteria in mind, and then specify the res= ulting paths as explicit EROs in provisioning requests sent to each of the = service ingresses. How else, for example, you can set up several services = originated from different nodes that are disjoint from each other? Also, wh= at is the point in your opinion of the statefull PCE work? Cheers, Igor From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, April 12, 2013 8:08 AM To: Khuzema Pithewan Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Khuzema, Hi! Please see inline.. 1. When Network has more than 2 layer i.e. Packet-OTN-DWDM, the Pack= et (client) layer will be talking to its immediate server layer i.e. OTN, w= hich in turn is talking to DWDM layer. Using MELG, client layer path comput= ation can take care of resource exclusivity of virtual link for immediate s= erver layer i.e. OTN layer. However if there is resource exclusivity at DW= DM layer, this mechanism doesn't work. You need to do loose routing or use = distributed PCE model [VPB] The behavior is the same as what you would do with SRLGs in a multi-l= ayer architecture. There are architectures that allow the SRLGs in the lowe= st layer to be exported all the way up to the highest layer. The expectatio= n is that MELGs would be treated in the same vein. 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. [VPB] I'm not sure why you think there is no point in having a centralized= computation function compute paths concurrently for LSPs with different se= t of end-points. Even your NMS/planning-software can interact with such com= putation engine, retrieve all the paths and then go about initiating the pa= th-setup from the ingress of each LSP. Regards, -Pavan From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Igor Bryskin Sent: Tuesday, March 26, 2013 7:19 PM To: Dieter Beller; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Dieter, You said: >> I guess we are coming back to the essential point: "and how often concur= rent path computation will be >> used." To be honest, this surprises me quite a bit, Let me give you some of many r= easons as to why concurrent path computations are needed and why this is be= tter than computing one path at a time: 1. Computing several diverse paths for the same service in the context= of service recovery. I hope you realize that computing one path at a time = on many configurations produces no or sub-optimal results. I also hope you = realize the problem of selecting two paths with one of them having a link = with common MELG with a link from another path; 2. Computing paths for multiple services to be sufficiently disjoint f= rom each other; 3. Computing paths for multiple services to achieve a global optimizat= ion criteria (e.g. minimal summary total cost); 4. Computing paths for multiple services for the purpose of removing t= he bandwidth fragmentations; 5. Computing paths for multiple services to plan shared mesh protectio= n/restoration schemes 6. Etc. Also think about this: 1. If concurrent path computation was not important, why PCEP includes= the machinery to do that? 2. My understanding of the statefull PCE is that it does pretty much n= othing but concurrent path computations You also said: >> I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the >> TE-DB, MELG routing extensions are not needed because the information ab= out mutual >>exclusive VLs can be kept in the central TE-DB when VLs are configured. How this logic does not apply to other link attributes such as SRLGs? What if path computation is not centralized? Cheers, Igor From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Dieter Beller Sent: Monday, March 25, 2013 5:52 PM To: Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Hi Pavan, On 25.03.2013 07:29, Fatai Zhang wrote: Hi Pavan, I am not sure how much VL (Virtual Link) will be used in the practical depl= oyment and how often concurrent path computation will be used. I guess we are coming back to the essential point: "and how often concurren= t path computation will be used." This means we are trying to figure out under which conditions MELG routing = extensions could be beneficial. IMHO, they would only make sense, if: * a path computation function supports the calculation of k shortest pa= ths concurrently * if there is only a single path computation function instance per doma= in (pce approach) If path computation is done in a distributed fashion the benefit goes away = because the instances calculate paths independently! I suppose that if a pce approach is used, i.e., path computation is central= ized including the TE-DB, MELG routing extensions are not needed because the information about= mutual exclusive VLs can be kept in the central TE-DB when VLs are configured. Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their applicability is broader. Thanks, Dieter Do you think if it makes sense to add a flag (in routing advertisement) to = indicate a link is a VL or not? Best Regards Fatai From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, March 22, 2013 8:57 PM To: Fatai Zhang Cc: Igor Bryskin; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Fatai, Hi! Good to see that you understand the construct now. This is not a corner case. The utility of the construct becomes quite signi= ficant if you have an application that does concurrent path computations on= an abstract topology. Regards, -Pavan _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp -- DIETER BELLER ALCATEL-LUCENT DEUTSCHLAND AG PROJECT MANAGER ASON/GMPLS CONTROL PLANE CORE NETWORKS BUSINESS DIVISION OPTICS BU, SWITCHING R&D Lorenzstrasse 10 70435 Stuttgart, Germany Phone: +49 711 821 43125 begin_of_the_skype_highlighting [X] +49 711 821 43= 125 FREE end_of_the_skype_highlighting Mobil: +49 175 7266874 begin_of_the_skype_highlighting [X] +49 175 7266874 = FREE end_of_the_skype_highlighting Dieter.Beller@alcatel-lucent.com Alcatel-Lucent Deutschland AG Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026 Chairman of the Supervisory Board: Michael Oppenhoff Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe --_000_F82A4B6D50F9464B8EBA55651F541CF843175C60SZXEML552MBXchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Pavan, = Igor

 = ;

I think th= ere are some concerns about the applicability of MELGs and I have the same = feeling as Khuzema and Dieter.

 = ;

I still th= ink that MELGS can only handle a very small corner case as you put many cas= es below where MELGs are not needed.

 = ;

What is Vi= rtual Link? As described in RFC6001, it says as below. So my question is: w= hen there are two VLs created through Call approach as defined in RFC6001, one has 3 potential paths in the server layer to setup FA-LSP,= and another has 2 potential paths in the server layer, and only one of the= 3 &2 has the same resource shared in the server layer.

 = ;

How MELGs = can help in this case?

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

A virtual TE link is defined as a TE link between = two upper-layer nodes that is not associated with a fully provisioned FA-LSP in a lower layer [R= FC5212].  A virtual TE link is advertised as any TE link, following the rules in [RFC4206] defined for fully provisioned TE links.  A virtual TE link represents thus the potentiality to set up an FA-LSP in the lower layer to support the TE link that has been advertised.

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

 = ;

 

 

 

 

Best Regards

 

Fatai

 = ;

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org= ] On Behalf Of Vishnu Pavan Beeram
Sent: Tuesday, April 16, 2013 10:10 PM
To: Khuzema Pithewan
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Khuzema, Hi!<= /p>

 

MELGs are useful and come into = play only when:

(1) The server network domain i= s abstracted and the advertised Virtual TE-links possess some mutual exclus= ivity relationship.

(2) There is a Centralized path= computation entity in the client domain (computes paths in terms of Client= TE-links/TE-nodes) that is capable of doing concurrent path computations.<= o:p>

 

If either of the above 2 statem= ents is NOT true, there is no utility for MELGs. 

At the risk of being pedantic:&= nbsp;

- Are MELGs needed when the ser= ver-network domain in not abstracted (no Virtual TE links)? The answer is N= O.

- Are MELGs needed when you hav= e a distributed path-computation architecture (Client PCE interacting with = Server PCE)? The answer is NO.

- Are MELGs needed when the cen= tralized path-computation engine doesn't (can't) do concurrent computations= ? The answer is NO.

 

The actual procedures involved = in abstracting the server network domain is beyond the scope of <draft-m= elgs>. The abstraction procedure itself is implementation-specific (mayb= e someday someone would put together a draft for discussing this). Though it is true that the primary use-case we had i= n mind when coming up with this new construct involves a lambda-layer serve= r network domain, there is really no restriction (at a conceptual level) on= using this construct when abstracting a packet-layer server network domain or a TDM-layer server network domain.= It is up to the implementation on how to make best use of this construct.&= nbsp;

 

When you advertise a Virtual TE= -link into a client network domain, you are doing this based on the existen= ce of some potential underlying server-path. TE attributes like SRLGs, MELG= s, delay etc that get advertised for the Virtual TE-link depend on the underlying server-path that is chosen fo= r catering to this Client TE-link. If the underlying server-path keeps chan= ging (based on network events), these TE attributes would also keep changin= g. The procedure for keeping the advertised information "current" is an implementation choice.&nb= sp;

 

If there exists such a thing as= an abstraction manager (again, this is totally implementation specific), t= hen the assumption is that it does one of the following - <= /span>

(a) computes new server-paths f= or the Virtual TE links whenever there is a change in the network (may not = be very scalable in some architectures), 

(b) or does periodic path-compu= tation for each Virtual TE link, 

(c) or uses a policy to pin dow= n the Virtual TE-link to a specific underlying server-path, 

(d) or uses a combination of (a= ), (b), (c).

 

<draft-melgs> doesn't mak= e any recommendation as to what choice the abstraction manager would need t= o take.

 

Hope this helps.

-Pavan

=  

On Tue, Apr 16, 2013 at 7:08 AM= , Khuzema Pithewan <kpithewan@infinera.com> wrote:

Hi Igor,

 

I am trying to summarize= the discussion we had so far. Pls see if my conclusion is in sync with the idea of MELG you have

 

MELG is useful when

1.      = ; server layer VLs are naile= d down for the resources on the server layer links that are shared among mu= ltiple VLs. These resources are typically wavelength on a fiber (can it be anything else??). In other words, if 2 VLs are pinned t= o use a particular wavelength on a particular fiber, then these 2 VLs will = have MELG for the wavelength.=

2.      = ; server layer do not have c= entralized path computation entity which can be used by client layer to ask= for concurrent diverse path computation within server layer.

3.      = ; Client layer has a central= ized path computation entity, which would compute paths for client+serv= er layer.

4.      = ; The need is to centralized= concurrent computation of more than one client+server layer path that = meets some diversity and resource exclusivity requirements.

 

Regds

Khuzema

 

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Monday, April 15, 2013 9:44 PM


To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

Please, see in-line.

 

Igor

 

From: Khuzema Pithewan [mailto:kpithewan@infinera.com]
Sent: Monday, April 15, 2013 12:05 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

I understand the SRLG an= d MELG behavior you have penned .

 

My concern was little di= fferent.  With changing resource consumption (because of dynamicity the network has) in the network links, potential paths a set of virtual li= nk can take will change and hence its MELG, as it is tied to a resource it = can take. So unless virtual links paths are nailed down, it would be hard t= o compute MELGs in distributed way.<= /span>

 

IB>> I think you a= re missing the point here. Virtual Link server layer paths are pinned as far as fate sharing is concerned (that is, they are pinned on  ser= ver layer link level). It would make little sense to advertise VL SRLGs if = the SRLGs constantly change. The same is true for MELGs.  SRLGs/MELGs = advertised for VLs normally do not change: neither over time nor when VLs become committed/uncommitted.

 

Another point is, virtua= l links can be viewed as oversubscription of resources (in MELG context). Taking an example (for OTN, I know it would work differently for= a Wavelength in WDM), a link resources are worth 1 TB of BW, user has prov= isioned 20 virtual links of 100G each going via that OTN link.  Physic= ally, only 10 will get committed. But which 10? It will really depend on network dynamics at the time of demand = to commit. MELGs are not that effective here. You need some different mecha= nism.

 

IB>> As I mentione= d before MELGs have nothing to do with bandwidth and were never intended to solve the problems such as you describe (just like it would not make mu= ch sense to solve such problem with SRLGs :=3D)=

Again,  MELG is an = extreme case SRLG designed exclusively for VLs (no more and no less).

 

Regds

Khuzema

 

 

From: Igor Bryskin [mai= lto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 11:55 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

Think about MELG as an S= RLG that is shared between two or more links in its entirety. When two real links have an SRLG in common, it means that two real links c= an co-exist concurrently, but there is something (e.g. common conduit, note= that the conduit has room for more than for one link) that will bring both= these links down, if this something fails (e.g. conduit is cut ). Now consider that this something must be tak= en in its entirety by one of the links to become operational . In this case= SRLG becomes MELG. Note that MELG is only meaningful for virtual links (un= like SRLG that makes sense for either real or virtual link). Why would you advertise two links that mutually exc= lude each other rather than advertising only one of them at a time, unless = the two are virtual links and hence both available for the client layer con= nections?

 

Igor

 

 

From: Khuzema Pithewan [mail= to:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 1:01 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

Do you mean, if virtual = link do not have any specific constraint, for example a link in the path (not talking about egress links/interfaces) must be traversed = to realize the virtual link, there wont be any MELG for the virtual link?

 

Regds

Khuzema

 

From: Igor Bryskin [mai= lto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 9:52 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

MELGs have nothing to do= with bandwidth. MELG is a concrete network resource in a server layer that two or more Virtual Links in a client layer depend on in a mutu= ally exclusive way. An example of MELG is a WDM layer transponder that can = terminate either of respective WDM layer tunnels (but not both at the same = time) for two OTN layer Virtual Links. If you advertise a Virtual Link, say, for Ethernet layer that depen= ds on the connection in OTN layer going through one of the mentioned OTN li= nks, the Ethernet VL must inherit the MELG similarly like it does SRLGs adv= ertised for the OTN links.

 

Igor

 

 

From: Khuzema Pithewan [mail= to:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 12:06 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

For multi-layer (more th= an 2) network, consider all the layers are meshy (that’s when virtual links are useful anyway), MELGs of virtual link will change as and= when BW/wavelength availability changes, because potential paths, a virtua= l link can take will change. Mapping lower layer MELGs to higher layer MELG= s won’t be practical if done in distributed manner, so it has to be centralized. So you do have central el= ement in each layer that knows all the risk and paths (a PCE?), which can b= e utilized for layer specific path computation (as it is doing it anyway).

 

This kind of architectur= e has all the pieces that are required for Inter-PCE communication (across layers), except the protocol that would actually make the 2 PCEs t= alk.

 

You seem to be doing som= ething that you don’t like J

 

Regards

Khuzema

 

From: Igor Bryskin [mai= lto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 8:39 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

I am not a fan of inter-= layer path computations (nor I am a fan of inter-PCE computations). In my mind path computation for a service or services in layer X is perfor= med only in layer X, i.e. considers only X layer links (real or virtual). A= s Pavan mentioned SRLGs and MELGs that need to be inherited from lower laye= rs should be translated into X layer link SRLGs/MELGs and specified with X layer specific SRLG/MELG IDs.=

 

Cheers,

Igor

 

 

From: Khuzema Pithewan [mail= to:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 10:55 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

Ok. This would be useful= if network architecture is based on external PCE or mgmt entity as PCE in client layer, but there is no counterpart in server layer, other= wise one could have inter-PCE communication to achieve diverse path in serv= er layer without getting into virtual link and MELG stuff.

 

Is that correct?<= span lang=3D"EN-US">

 

Khuzema

 

From: Igor Bryskin [mai= lto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 6:36 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

2= . =       For cases of concurrent co= mputation (case#2-5), you are mainly talking about global optimization and = diversity among multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done fro= m the source end of those LSPs.  So there is no point in doing concurr= ent computation at one network element for the services starting from multi= ple network elements. At best it looks to me a problem to be solved by network management/planning software. 

Well, when an ingress no= de is initiating a service, it is doing so on request from some management entity. This management entity can compute paths for many servi= ces with some global criteria in mind, and then specify the resulting paths= as explicit EROs in provisioning requests sent to each of the service ingr= esses. How else, for example,  you can set up several services originated from different nodes that are disjo= int from each other? Also, what is the point in your opinion of the statefu= ll PCE work?

 

Cheers,

Igor

 

From: Vishnu Pavan Beeram [m= ailto:vishnupavan@gmail.com]
Sent: Friday, April 12, 2013 8:08 AM
To: Khuzema Pithewan
Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Khuzema, Hi!


Please see inline..

 

 

 1.    = ;   When Network has more than= 2 layer i.e. Packet-OTN-DWDM, the Packet (client) layer will be talking to= its immediate server layer i.e. OTN, which in turn is talking to DWDM layer. Using MELG, client layer path computation can take care of = resource exclusivity of virtual link for immediate server layer i.e. OTN la= yer.  However if there is resource exclusivity at DWDM layer, this mec= hanism doesn’t work. You need to do loose routing or use distributed PCE model

 

[VPB] The behavior is the same as what you wo= uld do with SRLGs in a multi-layer architecture. There are architectures th= at allow the SRLGs in the lowest layer to be exported all the way up to the highest layer. The expectation is tha= t MELGs would be treated in the same vein. 

2= . =       For cases of concurrent co= mputation (case#2-5), you are mainly talking about global optimization and = diversity among multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done fro= m the source end of those LSPs.  So there is no point in doing concurr= ent computation at one network element for the services starting from multi= ple network elements. At best it looks to me a problem to be solved by network management/planning software. 

[VPB]  I'm not sure why you think there = is no point in having a centralized computation function compute paths conc= urrently for LSPs with different set of end-points. Even your NMS/planning-software can interact with such computation engine,= retrieve all the paths and then go about initiating the path-setup from th= e ingress of each LSP. 

 

Regards,

-Pavan

 

 

 

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Tuesday, March 26, 2013 7:19 PM
To: Dieter Beller; Vishnu Pavan Beeram


Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Dieter,

 

You said:

>> I guess we are coming back to the es= sential point: "and how often concurrent path computation will be >> used."

 

To be honest, this surprises me quite a bit, = Let me give you some of many reasons as to why concurrent path computations= are needed and why this is better than computing one path at a time:

 

1.      Computing several diverse paths for the same service i= n the context of service recovery. I hope you realize that computing one pa= th at a time on many configurations produces no or sub-optimal results. I a= lso hope you realize the problem of selecting two paths with one of them  having a link with common MELG = with a link from another path;

2.      Computing paths for multiple services to be sufficient= ly disjoint from each other;

3.      Computing paths for multiple services to achieve a glo= bal optimization criteria (e.g. minimal summary total cost);

4.      Computing paths for multiple services for the purpose = of removing the bandwidth fragmentations;

5.      Computing paths for multiple services to plan shared m= esh protection/restoration schemes

6.      Etc.

 

Also think about this:

1.      If concurrent path computation was not important, why = PCEP includes the machinery to do that?

2.      My understanding of the statefull PCE is that it does = pretty much nothing but concurrent path computations

 

You also said:

>> I suppose that if a pce approach is used, = i.e., path computation is centralized including the
>> TE-DB, MELG routing extensions are not needed because the informat= ion about mutual
>>exclusive VLs can be kept in the central TE-DB when VLs are configu= red.

How this logic does not apply to other link a= ttributes such as SRLGs?

What if path computation is not centralized?<= o:p>

 

Cheers,

Igor

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Hi Pavan,

On 25.03.2013 07:29, Fat= ai Zhang wrote:

Hi Pavan,

 

I am not sure how much V= L (Virtual Link) will be used in the practical deployment and how often concurrent path computation will be used.

I guess we are coming back to the essential p= oint: "and how often concurrent path computation will be used."

This means we are trying to figure out under which conditions MELG routing = extensions
could be beneficial.

IMHO, they would only make sense, if:

  • a path computation function supports the calculation o= f k shortest paths concurrently
  • if there is only a single path computation function in= stance per domain (pce approach)
    If path computation is done in a distributed fashion the benefit goes away = because
    the instances calculate paths independently!

I suppose that if a pce approach is used, i.e., pat= h computation is centralized including the
TE-DB, MELG routing extensions are not needed because the information about= mutual
exclusive VLs can be kept in the central TE-DB when VLs are configured.

Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their
applicability is broader.


Thanks,
Dieter

 

Do you think if it makes sense to= add a flag (in routing advertisement) to indicate a link is a VL or not?

 

 

 

Best Regards

 

Fatai=

 

From: Vishnu Pavan Beeram [m= ailto:vishnupavan@gmail.com]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Fatai, Hi!

 

Good to see that you understand the construct= now.

 

This is not a corner case. The utility of the= construct becomes quite significant if you have an application that does c= oncurrent path computations on an abstract topology.

 

Regards,

-Pavan

 

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

 

--

DIETER BELLE= R

ALCATEL-LUCENT DEUTSCHLAN= D AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 711 821 43125 begin_of_the_skype_highlighting +49 711 821 43125 FREE  end_of_the_skype_highlighting
Mobil: +49 175 7266874 begin_of_the_skype_highlighting +49 175 7266874 FREE  = end_of_the_skype_highlighting

 

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe

 

 

--_000_F82A4B6D50F9464B8EBA55651F541CF843175C60SZXEML552MBXchi_-- From IBryskin@advaoptical.com Fri Apr 19 05:14:45 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CACBE21F9488 for ; Fri, 19 Apr 2013 05:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=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 hy-OLng+3+5I for ; Fri, 19 Apr 2013 05:14:34 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id C5DB921F940E for ; Fri, 19 Apr 2013 05:14:32 -0700 (PDT) Received: from MUC-SRV-MBX1.advaoptical.com ([172.20.1.95]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id r3JCDqT7028409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Apr 2013 14:13:52 +0200 Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MBX1.advaoptical.com (172.20.1.95) with Microsoft SMTP Server (TLS) id 15.0.620.29; Fri, 19 Apr 2013 14:13:51 +0200 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0123.003; Fri, 19 Apr 2013 08:13:50 -0400 From: Igor Bryskin To: Fatai Zhang , John E Drake , Khuzema Pithewan , Vishnu Pavan Beeram Thread-Topic: [CCAMP] MELGs - Q&A Thread-Index: AQHOIGPeoOQf0fNS1kG7ulofq5GmQJivzRoAgABxTHCAAPkpgIAAeAqAgABMBQCABErLAIABAdYAgAC6NQCAGt0OAIAAD52A///KWjCAAGRRgP//wCBQgABTlAD//73CwAAKM0gAAAY9GCAAdYY0gAAQgVwAADCVHoAAA3fQ8AAvLpWAAALyvwAACBNGgABIbOKAAAp2XbA= Date: Fri, 19 Apr 2013 12:13:49 +0000 Message-ID: References: <5150C704.2040007@alcatel-lucent.com> <0182DEA5604B3A44A2EE61F3EE3ED69E1D4A5653@BL2PRD0510MB349.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [174.46.146.58] Content-Type: multipart/alternative; boundary="_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923A6DCatlsrvmail10atl_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-04-19_05:2013-04-19, 2013-04-19, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] MELGs - Q&A X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 12:14:45 -0000 --_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923A6DCatlsrvmail10atl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Fatai, What I said was that this is not necessarily the case of centralized path c= omputation: a given NE, being an ingress of a service, is capable to comput= e disjoint paths to the service destination on its own (i.e. without asking= a network PCE to do so). The point is that MELGs need to be considered in = this case just as in the case of centralized concurrent path computation fo= r multiple services. Cheers, Igor From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Thursday, April 18, 2013 11:08 PM To: Igor Bryskin; John E Drake; Khuzema Pithewan; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, This case can be still regarded as centralized path computation, ie., multi= ple disjoint paths are computed by one single node. =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=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 If a client device needs to compute two disjoint paths to a destination (e.= g. for recovery purposes), the computation will be concurrent (of more than= one paths), but not necessarily centralized. Note that MELGs need to be co= nsidered in this case to avoid selecting links belonging to different path= s with an MELG in common. Would you agree? Best Regards Fatai From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Igor Bryskin Sent: Wednesday, April 17, 2013 8:58 PM To: John E Drake; Khuzema Pithewan; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A John, You said: JD: The draft should note that MELGs have utility only in client networks = that use centralized concurrent path computation. If a client device needs to compute two disjoint paths to a destination (e.= g. for recovery purposes), the computation will be concurrent (of more than= one paths), but not necessarily centralized. Note that MELGs need to be co= nsidered in this case to avoid selecting links belonging to different path= s with an MELG in common. Would you agree? Cheers, Igor From: John E Drake [mailto:jdrake@juniper.net] Sent: Wednesday, April 17, 2013 8:43 AM To: Khuzema Pithewan; Igor Bryskin; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Comments inline. Irrespectively Yours, John From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Khuzema Pithewan Sent: Wednesday, April 17, 2013 4:19 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Hi Igor and Pavan, Thanks for the discussion. I understand MELG proposal is not really precluding non-WDM server layer. I= am trying to see, will it solve similar issues if they are there in more d= ynamic OTN (TDM) server layer. JD: This is a very good point. While MELGs can be used in higher layer se= rver networks, they may not have any utility in these networks because thes= e networks do not use physical resources directly. MELG seems to be made useful by quite a bit of mgmt provisioning w.r.t. VLs= and its path in server layer. It is one way, a client layer can make use = of server layer resource information (for path computation). However, is it= the typical way? I am not sure. JD: The draft should note that MELGs have utility only in client networks = that use centralized concurrent path computation. Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Tuesday, April 16, 2013 7:50 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Please, see in line. From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Tuesday, April 16, 2013 7:08 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, I am trying to summarize the discussion we had so far. Pls see if my conclu= sion is in sync with the idea of MELG you have MELG is useful when 1. server layer VLs are nailed down for the resources on the server lay= er links that are shared among multiple VLs. IB>> Correction: server layer link-level paths supporting *client layer* VL= s are nailed down. The resources of said paths are sharable between the pat= hs (and hence VLs) but not available for anything else. These resources are typically wavelength on a fiber (can it be anything els= e??). IB>> Server layer does not have to be WDM In other words, if 2 VLs are pinned to use a particular wavelength on a par= ticular fiber, then these 2 VLs will have MELG for the wavelength. IB>> Correction: Wavelength is not the only type of resource that is used i= n WDM layer. If two paths use the same transponder, converter, regenerator,= etc. then corresponding VLs have a MELG in common. If two paths have a WDM= link in common on which they *must* use the same wavelength (e.g. because = the paths are started on fixed transponders of the same frequency), then th= ey also have an MELG in common. If two paths have to use the same wavelengt= h on a common WDM link because this is the only wavelength available at the= moment, then the VLs *do not* have an MELG in common (just usual lack of = resources on the link) 2. server layer do not have centralized path computation entity which c= an be used by client layer to ask for concurrent diverse path computation w= ithin server layer. IB>> This approach has nothing to do with VLs. VLs (just like real links) a= re supposed to be pre-planned in a different time frame from when client la= yer connections are set up. When VLs are advertised, this means that the se= rver layer paths are successfully computed and pinned already (btw by serve= r layer path computer). Asking server layer path computation dynamically do= es not guarantee any success, so, if it fails, what to do next? You cannot= orchestrate any restoration schemes in the client layer this way. Instaed,= we suggest solid as_good_as_real Virtual Topology to use. 3. Client layer has a centralized path computation entity, which would = compute paths for client+server layer. IB>> Correction: only for client layer, based on client layer VLs 4. The need is to centralized concurrent computation of more than one c= lient+server layer path that meets some diversity and resource exclusivity = requirements. IB>> Correction: there is a need for concurrent path computation in the cli= ent layer and because the client layer topology is virtual, you need MELGs = to consider Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Monday, April 15, 2013 9:44 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Please, see in-line. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Monday, April 15, 2013 12:05 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, I understand the SRLG and MELG behavior you have penned . My concern was little different. With changing resource consumption (becau= se of dynamicity the network has) in the network links, potential paths a s= et of virtual link can take will change and hence its MELG, as it is tied t= o a resource it can take. So unless virtual links paths are nailed down, it= would be hard to compute MELGs in distributed way. IB>> I think you are missing the point here. Virtual Link server layer path= s are pinned as far as fate sharing is concerned (that is, they are pinned = on server layer link level). It would make little sense to advertise VL SR= LGs if the SRLGs constantly change. The same is true for MELGs. SRLGs/MELG= s advertised for VLs normally do not change: neither over time nor when VLs= become committed/uncommitted. Another point is, virtual links can be viewed as oversubscription of resour= ces (in MELG context). Taking an example (for OTN, I know it would work dif= ferently for a Wavelength in WDM), a link resources are worth 1 TB of BW, u= ser has provisioned 20 virtual links of 100G each going via that OTN link. = Physically, only 10 will get committed. But which 10? It will really depen= d on network dynamics at the time of demand to commit. MELGs are not that e= ffective here. You need some different mechanism. IB>> As I mentioned before MELGs have nothing to do with bandwidth and were= never intended to solve the problems such as you describe (just like it wo= uld not make much sense to solve such problem with SRLGs :=3D) Again, MELG is an extreme case SRLG designed exclusively for VLs (no more = and no less). Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 11:55 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Think about MELG as an SRLG that is shared between two or more links in its= entirety. When two real links have an SRLG in common, it means that two re= al links can co-exist concurrently, but there is something (e.g. common con= duit, note that the conduit has room for more than for one link) that will = bring both these links down, if this something fails (e.g. conduit is cut )= . Now consider that this something must be taken in its entirety by one of = the links to become operational . In this case SRLG becomes MELG. Note that= MELG is only meaningful for virtual links (unlike SRLG that makes sense fo= r either real or virtual link). Why would you advertise two links that mutu= ally exclude each other rather than advertising only one of them at a time,= unless the two are virtual links and hence both available for the client l= ayer connections? Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 1:01 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Do you mean, if virtual link do not have any specific constraint, for examp= le a link in the path (not talking about egress links/interfaces) must be t= raversed to realize the virtual link, there wont be any MELG for the virtua= l link? Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 9:52 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, MELGs have nothing to do with bandwidth. MELG is a concrete network resourc= e in a server layer that two or more Virtual Links in a client layer depend= on in a mutually exclusive way. An example of MELG is a WDM layer transpon= der that can terminate either of respective WDM layer tunnels (but not both= at the same time) for two OTN layer Virtual Links. If you advertise a Virt= ual Link, say, for Ethernet layer that depends on the connection in OTN lay= er going through one of the mentioned OTN links, the Ethernet VL must inher= it the MELG similarly like it does SRLGs advertised for the OTN links. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 12:06 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, For multi-layer (more than 2) network, consider all the layers are meshy (t= hat's when virtual links are useful anyway), MELGs of virtual link will cha= nge as and when BW/wavelength availability changes, because potential paths= , a virtual link can take will change. Mapping lower layer MELGs to higher = layer MELGs won't be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all= the risk and paths (a PCE?), which can be utilized for layer specific path= computation (as it is doing it anyway). This kind of architecture has all the pieces that are required for Inter-PC= E communication (across layers), except the protocol that would actually ma= ke the 2 PCEs talk. You seem to be doing something that you don't like :) Regards Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 8:39 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, I am not a fan of inter-layer path computations (nor I am a fan of inter-PC= E computations). In my mind path computation for a service or services in l= ayer X is performed only in layer X, i.e. considers only X layer links (rea= l or virtual). As Pavan mentioned SRLGs and MELGs that need to be inherited= from lower layers should be translated into X layer link SRLGs/MELGs and s= pecified with X layer specific SRLG/MELG IDs. Cheers, Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 10:55 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Ok. This would be useful if network architecture is based on external PCE o= r mgmt entity as PCE in client layer, but there is no counterpart in server= layer, otherwise one could have inter-PCE communication to achieve diverse= path in server layer without getting into virtual link and MELG stuff. Is that correct? Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 6:36 PM To: Vishnu Pavan Beeram; Khuzema Pithewan Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. Well, when an ingress node is initiating a service, it is doing so on reque= st from some management entity. This management entity can compute paths fo= r many services with some global criteria in mind, and then specify the res= ulting paths as explicit EROs in provisioning requests sent to each of the = service ingresses. How else, for example, you can set up several services = originated from different nodes that are disjoint from each other? Also, wh= at is the point in your opinion of the statefull PCE work? Cheers, Igor From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, April 12, 2013 8:08 AM To: Khuzema Pithewan Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Khuzema, Hi! Please see inline.. 1. When Network has more than 2 layer i.e. Packet-OTN-DWDM, the Pack= et (client) layer will be talking to its immediate server layer i.e. OTN, w= hich in turn is talking to DWDM layer. Using MELG, client layer path comput= ation can take care of resource exclusivity of virtual link for immediate s= erver layer i.e. OTN layer. However if there is resource exclusivity at DW= DM layer, this mechanism doesn't work. You need to do loose routing or use = distributed PCE model [VPB] The behavior is the same as what you would do with SRLGs in a multi-l= ayer architecture. There are architectures that allow the SRLGs in the lowe= st layer to be exported all the way up to the highest layer. The expectatio= n is that MELGs would be treated in the same vein. 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. [VPB] I'm not sure why you think there is no point in having a centralized= computation function compute paths concurrently for LSPs with different se= t of end-points. Even your NMS/planning-software can interact with such com= putation engine, retrieve all the paths and then go about initiating the pa= th-setup from the ingress of each LSP. Regards, -Pavan From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Igor Bryskin Sent: Tuesday, March 26, 2013 7:19 PM To: Dieter Beller; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Dieter, You said: >> I guess we are coming back to the essential point: "and how often concur= rent path computation will be >> used." To be honest, this surprises me quite a bit, Let me give you some of many r= easons as to why concurrent path computations are needed and why this is be= tter than computing one path at a time: 1. Computing several diverse paths for the same service in the context= of service recovery. I hope you realize that computing one path at a time = on many configurations produces no or sub-optimal results. I also hope you = realize the problem of selecting two paths with one of them having a link = with common MELG with a link from another path; 2. Computing paths for multiple services to be sufficiently disjoint f= rom each other; 3. Computing paths for multiple services to achieve a global optimizat= ion criteria (e.g. minimal summary total cost); 4. Computing paths for multiple services for the purpose of removing t= he bandwidth fragmentations; 5. Computing paths for multiple services to plan shared mesh protectio= n/restoration schemes 6. Etc. Also think about this: 1. If concurrent path computation was not important, why PCEP includes= the machinery to do that? 2. My understanding of the statefull PCE is that it does pretty much n= othing but concurrent path computations You also said: >> I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the >> TE-DB, MELG routing extensions are not needed because the information ab= out mutual >>exclusive VLs can be kept in the central TE-DB when VLs are configured. How this logic does not apply to other link attributes such as SRLGs? What if path computation is not centralized? Cheers, Igor From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Dieter Beller Sent: Monday, March 25, 2013 5:52 PM To: Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Hi Pavan, On 25.03.2013 07:29, Fatai Zhang wrote: Hi Pavan, I am not sure how much VL (Virtual Link) will be used in the practical depl= oyment and how often concurrent path computation will be used. I guess we are coming back to the essential point: "and how often concurren= t path computation will be used." This means we are trying to figure out under which conditions MELG routing = extensions could be beneficial. IMHO, they would only make sense, if: * a path computation function supports the calculation of k shortest pa= ths concurrently * if there is only a single path computation function instance per doma= in (pce approach) If path computation is done in a distributed fashion the benefit goes away = because the instances calculate paths independently! I suppose that if a pce approach is used, i.e., path computation is central= ized including the TE-DB, MELG routing extensions are not needed because the information about= mutual exclusive VLs can be kept in the central TE-DB when VLs are configured. Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their applicability is broader. Thanks, Dieter Do you think if it makes sense to add a flag (in routing advertisement) to = indicate a link is a VL or not? Best Regards Fatai From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, March 22, 2013 8:57 PM To: Fatai Zhang Cc: Igor Bryskin; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Fatai, Hi! Good to see that you understand the construct now. This is not a corner case. The utility of the construct becomes quite signi= ficant if you have an application that does concurrent path computations on= an abstract topology. Regards, -Pavan _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp -- DIETER BELLER ALCATEL-LUCENT DEUTSCHLAND AG PROJECT MANAGER ASON/GMPLS CONTROL PLANE CORE NETWORKS BUSINESS DIVISION OPTICS BU, SWITCHING R&D Lorenzstrasse 10 70435 Stuttgart, Germany Phone: +49 711 821 43125 Mobil: +49 175 7266874 Dieter.Beller@alcatel-lucent.com Alcatel-Lucent Deutschland AG Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026 Chairman of the Supervisory Board: Michael Oppenhoff Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe --_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923A6DCatlsrvmail10atl_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Fatai,<= /p>

 <= /p>

What I said was that this= is not necessarily the case of centralized path computation: a given NE, b= eing an ingress of a service, is capable to compute disjoint paths to the service destination on its own (i.e. without asking a network= PCE to do so). The point is that MELGs need to be considered in this case = just as in the case of centralized concurrent path computation for multiple= services.

 <= /p>

Cheers,=

Igor

 <= /p>

 <= /p>

From: Fatai Zh= ang [mailto:zhangfatai@huawei.com]
Sent: Thursday, April 18, 2013 11:08 PM
To: Igor Bryskin; John E Drake; Khuzema Pithewan; Vishnu Pavan Beera= m
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

 

 

 

 

Best Regards

 

Fatai

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Wednesday, April 17, 2013 8:58 PM
To: John E Drake; Khuzema Pithewan; Vishnu Pavan Beeram
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

=

<= /p>

From: John E Drake [mailto:jdrake@juniper.net]
Sent: Wednesday, April 17, 2013 8:43 AM
To: Khuzema Pithewan; Igor Bryskin; Vishnu Pavan Beeram
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

<= /p>

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Khuzema Pithewan
Sent: Wednesday, April 17, 2013 4:19 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

=

=

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Tuesday, April 16, 2013 7:50 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

From: Khuzema Pithewan [mailto:kpithewan@infinera.com]
Sent: Tuesday, April 16, 2013 7:08 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

1.     server layer VLs are nailed down for the resources on the server = layer links that are shared among multiple VLs.

These resources are typically wavelength on a = fiber (can it be anything else??).

In other words, if 2 VLs are pinned to use a p= articular wavelength on a particular fiber, then these 2 VLs will have MELG for the wavelength.

2.     server layer do not have centralized path computation entity whic= h can be used by client layer to ask for concurrent diverse path computation within server layer.

3.     Client layer has a centralized path computation entity, which wou= ld compute paths for client+server layer.

4.     The need is to centralized concurrent computation of more than on= e client+server layer path that meets some diversity and resource exclusivity requirements.

=

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Monday, April 15, 2013 9:44 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

<= /p>

From: Khuzema Pithewan [mailto:kpithewan@infinera.com]
Sent: Monday, April 15, 2013 12:05 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

=

=

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 11:55 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

From: Khuzema Pithewan [mailto:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 1:01 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

=

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 9:52 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

<= /p>

From: Khuzema Pithewan [mailto:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 12:06 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

J

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 8:39 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

<= /p>

From: Khuzema Pithewan [mailto:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 10:55 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 6:36 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan
Cc: Dieter Beller; ccamp@ietf.org<= /a>
Subject: RE: [CCAMP] MELGs - Q&A

 

2.       For cases of c= oncurrent computation (case#2-5), you are mainly talking about global optim= ization and diversity among multiple services. You can do the path computation, but to actually enact the computed path the signa= ling needs to be done from the source end of those LSPs.  So there is = no point in doing concurrent computation at one network element for the ser= vices starting from multiple network elements. At best it looks to me a problem to be solved by network managem= ent/planning software.&nb= sp;

<= /p>

From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com]
Sent: Friday, April 12, 2013 8:08 AM
To: Khuzema Pithewan
Cc: Igor Bryskin; Dieter Beller; c= camp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Khuzema, = Hi!


Please see inline..

 

 

 1.       When Network h= as more than 2 layer i.e. Packet-OTN-DWDM, the Packet (client) layer will b= e talking to its immediate server layer i.e. OTN, which in turn is talking to DWDM layer. Using MELG, client layer path computatio= n can take care of resource exclusivity of virtual link for immediate serve= r layer i.e. OTN layer.  However if there is resource exclusivity at D= WDM layer, this mechanism doesn’t work. You need to do loose routing or use distributed PCE model

 

[VPB] The= behavior is the same as what you would do with SRLGs in a multi-layer arch= itecture. There are architectures that allow the SRLGs in the lowest layer = to be exported all the way up to the highest layer. The expectation is that MELGs would be treated in the same = vein. 

2.       For cases of c= oncurrent computation (case#2-5), you are mainly talking about global optim= ization and diversity among multiple services. You can do the path computation, but to actually enact the computed path the signa= ling needs to be done from the source end of those LSPs.  So there is = no point in doing concurrent computation at one network element for the ser= vices starting from multiple network elements. At best it looks to me a problem to be solved by network managem= ent/planning software.&nb= sp;

[VPB] &nb= sp;I'm not sure why you think there is no point in having a centralized com= putation function compute paths concurrently for LSPs with different set of= end-points. Even your NMS/planning-software can interact with such computation engine, retrieve all the paths and then= go about initiating the path-setup from the ingress of each LSP. 

 

Regards,<= o:p>

-Pavan

 

 

 

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Tuesday, March 26, 2013 7:19 PM
To: Dieter Beller; Vishnu Pavan Beeram


Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Dieter,

 

You said:

>> I guess we are= coming back to the essential point: "and how often concurrent path computation will be >> used."

 

To be honest, this surp= rises me quite a bit, Let me give you some of many reasons as to why concur= rent path computations are needed and why this is better than computing one path at a time:

 

1.      Computing several diverse= paths for the same service in the context of service recovery. I hope you = realize that computing one path at a time on many configurations produces n= o or sub-optimal results. I also hope you realize the problem of selecting two paths with one of them  havi= ng a link with common MELG with a link from another path;=

2.      Computing paths for multi= ple services to be sufficiently disjoint from each other;=

3.      Computing paths for multi= ple services to achieve a global optimization criteria (e.g. minimal summar= y total cost);

4.      Computing paths for multi= ple services for the purpose of removing the bandwidth fragmentations;=

5.      Computing paths for multi= ple services to plan shared mesh protection/restoration schemes<= /span>

6.      Etc.

 

Also think about this:<= o:p>

1.      If concurrent path comput= ation was not important, why PCEP includes the machinery to do that?

2.      My understanding of the s= tatefull PCE is that it does pretty much nothing but concurrent path comput= ations

 

You also said:

>> I suppose that if a = pce approach is used, i.e., path computation is centralized including the >> TE-DB, MELG routing extensions are not needed because the informat= ion about mutual
>>exclusive VLs can be kept in the central TE-DB when VLs are configu= red.

How this logic does not= apply to other link attributes such as SRLGs?

What if path computatio= n is not centralized?

 

Cheers,

Igor

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Hi Pavan,<= /p>

On 25.03.2013 07:29, Fat= ai Zhang wrote:

Hi Pavan,

 

I am not sur= e how much VL (Virtual Link) will be used in the practical deployment and how often concurrent path computation will be used.<= span style=3D"mso-fareast-language:ZH-CN">

I guess we are coming b= ack to the essential point: "and how often concurrent path computation will be used."

This means we are trying to figure out under which conditions MELG routing = extensions
could be beneficial.

IMHO, they would only make sense, if:

  • a path computation function supp= orts the calculation of k shortest paths concurrently
  • if there is only a single path c= omputation function instance per domain (pce approach)
    If path computation is done in a distributed fashion the benefit goes away = because
    the instances calculate paths independently!

I suppose that if a pce appro= ach is used, i.e., path computation is centralized including the
TE-DB, MELG routing extensions are not needed because the information about= mutual
exclusive VLs can be kept in the central TE-DB when VLs are configured.

Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their
applicability is broader.


Thanks,
Dieter

 

Do you think if it ma= kes sense to add a flag (in routing advertisement) to indicate a link is a = VL or not?

 

 

 

Best Regards

 

Fatai

 

From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Fatai, Hi!

 

Good to see that you un= derstand the construct now.

 

This is not a corner ca= se. The utility of the construct becomes quite significant if you have an a= pplication that does concurrent path computations on an abstract topology.

 

Regards,

-Pavan

 

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

 

--

= DIETER BELLER

ALCATEL-LUCEN= T DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 = 711 821 43125
Mobil: +49 175 = 7266874

 

Alcatel-Lucent Deutschland A= G
Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe

 

--_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923A6DCatlsrvmail10atl_-- From IBryskin@advaoptical.com Fri Apr 19 05:22:57 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF7D21F9593 for ; Fri, 19 Apr 2013 05:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_66=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 WykDjltMoDfA for ; Fri, 19 Apr 2013 05:22:45 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEDD21F9488 for ; Fri, 19 Apr 2013 05:22:44 -0700 (PDT) Received: from MUC-SRV-MAIL10B.advaoptical.com ([172.20.1.60]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id r3JCMVoi013814 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Apr 2013 14:22:31 +0200 Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MAIL10B.advaoptical.com (172.20.1.60) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 19 Apr 2013 14:22:31 +0200 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0123.003; Fri, 19 Apr 2013 08:22:29 -0400 From: Igor Bryskin To: Fatai Zhang , Vishnu Pavan Beeram , Khuzema Pithewan , "Dieter Beller" Thread-Topic: [CCAMP] MELGs - Q&A Thread-Index: AQHOIGPeoOQf0fNS1kG7ulofq5GmQJivzRoAgABxTHCAAPkpgIAAeAqAgABMBQCABErLAIABAdYAgAC6NQCAGt0OAIAAD52A///KWjCAAGRRgP//wCBQgABTlAD//73CwAAKM0gAAAY9GCAAdYY0gAAQgVwAADCVHoAABlrDAACAXYgAAAonNRA= Date: Fri, 19 Apr 2013 12:22:28 +0000 Message-ID: References: <5150C704.2040007@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [174.46.146.58] Content-Type: multipart/related; boundary="_004_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923A6F2atlsrvmail10atl_"; type="multipart/alternative" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-04-19_05:2013-04-19, 2013-04-19, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] MELGs - Q&A X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 12:22:57 -0000 --_004_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923A6F2atlsrvmail10atl_ Content-Type: multipart/alternative; boundary="_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923A6F2atlsrvmail10atl_" --_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923A6F2atlsrvmail10atl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Fatai, What is Virtual Link? As described in RFC6001, it says as below. So my ques= tion is: when there are two VLs created through Call approach as defined in= RFC6001, one has 3 potential paths in the server layer to setup FA-LSP, an= d another has 2 potential paths in the server layer, and only one of the 3 = &2 has the same resource shared in the server layer. How MELGs can help in this case? IB>> Simple: with MELGs the path computer will know in advance that selecti= ng two paths with a virtual link belonging to path #1 and a virtual link be= longing to path #2 having an MELG in common will be a bad idea, because an = attempt to provision such path combination is guaranteed to fail. Without M= ELGs the path computer won't have such knowledge. Cheers, Igor From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Thursday, April 18, 2013 11:26 PM To: Vishnu Pavan Beeram; Khuzema Pithewan; Igor Bryskin; Dieter Beller Cc: ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Pavan, Igor I think there are some concerns about the applicability of MELGs and I have= the same feeling as Khuzema and Dieter. I still think that MELGS can only handle a very small corner case as you pu= t many cases below where MELGs are not needed. What is Virtual Link? As described in RFC6001, it says as below. So my ques= tion is: when there are two VLs created through Call approach as defined in= RFC6001, one has 3 potential paths in the server layer to setup FA-LSP, an= d another has 2 potential paths in the server layer, and only one of the 3 = &2 has the same resource shared in the server layer. How MELGs can help in this case? =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=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 A virtual TE link is defined as a TE link between two upper-layer nodes tha= t is not associated with a fully provisioned FA-LSP in a lower layer [RFC52= 12]. A virtual TE link is advertised a= s any TE link, following the rules in [RFC4206] defined for fully provisioned TE links. A virtual TE link represe= nts thus the potentiality to set up an FA-LSP in the lower layer to support= the TE link that has been advertised. =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=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 Best Regards Fatai From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of V= ishnu Pavan Beeram Sent: Tuesday, April 16, 2013 10:10 PM To: Khuzema Pithewan Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Khuzema, Hi! MELGs are useful and come into play only when: (1) The server network domain is abstracted and the advertised Virtual TE-l= inks possess some mutual exclusivity relationship. (2) There is a Centralized path computation entity in the client domain (co= mputes paths in terms of Client TE-links/TE-nodes) that is capable of doing= concurrent path computations. If either of the above 2 statements is NOT true, there is no utility for ME= LGs. At the risk of being pedantic: - Are MELGs needed when the server-network domain in not abstracted (no Vir= tual TE links)? The answer is NO. - Are MELGs needed when you have a distributed path-computation architectur= e (Client PCE interacting with Server PCE)? The answer is NO. - Are MELGs needed when the centralized path-computation engine doesn't (ca= n't) do concurrent computations? The answer is NO. The actual procedures involved in abstracting the server network domain is = beyond the scope of . The abstraction procedure itself is impl= ementation-specific (maybe someday someone would put together a draft for d= iscussing this). Though it is true that the primary use-case we had in mind= when coming up with this new construct involves a lambda-layer server netw= ork domain, there is really no restriction (at a conceptual level) on using= this construct when abstracting a packet-layer server network domain or a = TDM-layer server network domain. It is up to the implementation on how to m= ake best use of this construct. When you advertise a Virtual TE-link into a client network domain, you are = doing this based on the existence of some potential underlying server-path.= TE attributes like SRLGs, MELGs, delay etc that get advertised for the Vir= tual TE-link depend on the underlying server-path that is chosen for cateri= ng to this Client TE-link. If the underlying server-path keeps changing (ba= sed on network events), these TE attributes would also keep changing. The p= rocedure for keeping the advertised information "current" is an implementat= ion choice. If there exists such a thing as an abstraction manager (again, this is tota= lly implementation specific), then the assumption is that it does one of th= e following - (a) computes new server-paths for the Virtual TE links whenever there is a = change in the network (may not be very scalable in some architectures), (b) or does periodic path-computation for each Virtual TE link, (c) or uses a policy to pin down the Virtual TE-link to a specific underlyi= ng server-path, (d) or uses a combination of (a), (b), (c). doesn't make any recommendation as to what choice the abstrac= tion manager would need to take. Hope this helps. -Pavan On Tue, Apr 16, 2013 at 7:08 AM, Khuzema Pithewan > wrote: Hi Igor, I am trying to summarize the discussion we had so far. Pls see if my conclu= sion is in sync with the idea of MELG you have MELG is useful when 1. server layer VLs are nailed down for the resources on the server l= ayer links that are shared among multiple VLs. These resources are typicall= y wavelength on a fiber (can it be anything else??). In other words, if 2 V= Ls are pinned to use a particular wavelength on a particular fiber, then th= ese 2 VLs will have MELG for the wavelength. 2. server layer do not have centralized path computation entity which= can be used by client layer to ask for concurrent diverse path computation= within server layer. 3. Client layer has a centralized path computation entity, which woul= d compute paths for client+server layer. 4. The need is to centralized concurrent computation of more than one= client+server layer path that meets some diversity and resource exclusivit= y requirements. Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Monday, April 15, 2013 9:44 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Please, see in-line. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Monday, April 15, 2013 12:05 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, I understand the SRLG and MELG behavior you have penned . My concern was little different. With changing resource consumption (becau= se of dynamicity the network has) in the network links, potential paths a s= et of virtual link can take will change and hence its MELG, as it is tied t= o a resource it can take. So unless virtual links paths are nailed down, it= would be hard to compute MELGs in distributed way. IB>> I think you are missing the point here. Virtual Link server layer path= s are pinned as far as fate sharing is concerned (that is, they are pinned = on server layer link level). It would make little sense to advertise VL SR= LGs if the SRLGs constantly change. The same is true for MELGs. SRLGs/MELG= s advertised for VLs normally do not change: neither over time nor when VLs= become committed/uncommitted. Another point is, virtual links can be viewed as oversubscription of resour= ces (in MELG context). Taking an example (for OTN, I know it would work dif= ferently for a Wavelength in WDM), a link resources are worth 1 TB of BW, u= ser has provisioned 20 virtual links of 100G each going via that OTN link. = Physically, only 10 will get committed. But which 10? It will really depen= d on network dynamics at the time of demand to commit. MELGs are not that e= ffective here. You need some different mechanism. IB>> As I mentioned before MELGs have nothing to do with bandwidth and were= never intended to solve the problems such as you describe (just like it wo= uld not make much sense to solve such problem with SRLGs :=3D) Again, MELG is an extreme case SRLG designed exclusively for VLs (no more = and no less). Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 11:55 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Think about MELG as an SRLG that is shared between two or more links in its= entirety. When two real links have an SRLG in common, it means that two re= al links can co-exist concurrently, but there is something (e.g. common con= duit, note that the conduit has room for more than for one link) that will = bring both these links down, if this something fails (e.g. conduit is cut )= . Now consider that this something must be taken in its entirety by one of = the links to become operational . In this case SRLG becomes MELG. Note that= MELG is only meaningful for virtual links (unlike SRLG that makes sense fo= r either real or virtual link). Why would you advertise two links that mutu= ally exclude each other rather than advertising only one of them at a time,= unless the two are virtual links and hence both available for the client l= ayer connections? Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 1:01 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Do you mean, if virtual link do not have any specific constraint, for examp= le a link in the path (not talking about egress links/interfaces) must be t= raversed to realize the virtual link, there wont be any MELG for the virtua= l link? Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 9:52 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, MELGs have nothing to do with bandwidth. MELG is a concrete network resourc= e in a server layer that two or more Virtual Links in a client layer depend= on in a mutually exclusive way. An example of MELG is a WDM layer transpon= der that can terminate either of respective WDM layer tunnels (but not both= at the same time) for two OTN layer Virtual Links. If you advertise a Virt= ual Link, say, for Ethernet layer that depends on the connection in OTN lay= er going through one of the mentioned OTN links, the Ethernet VL must inher= it the MELG similarly like it does SRLGs advertised for the OTN links. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 12:06 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, For multi-layer (more than 2) network, consider all the layers are meshy (t= hat's when virtual links are useful anyway), MELGs of virtual link will cha= nge as and when BW/wavelength availability changes, because potential paths= , a virtual link can take will change. Mapping lower layer MELGs to higher = layer MELGs won't be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all= the risk and paths (a PCE?), which can be utilized for layer specific path= computation (as it is doing it anyway). This kind of architecture has all the pieces that are required for Inter-PC= E communication (across layers), except the protocol that would actually ma= ke the 2 PCEs talk. You seem to be doing something that you don't like :) Regards Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 8:39 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, I am not a fan of inter-layer path computations (nor I am a fan of inter-PC= E computations). In my mind path computation for a service or services in l= ayer X is performed only in layer X, i.e. considers only X layer links (rea= l or virtual). As Pavan mentioned SRLGs and MELGs that need to be inherited= from lower layers should be translated into X layer link SRLGs/MELGs and s= pecified with X layer specific SRLG/MELG IDs. Cheers, Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 10:55 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Ok. This would be useful if network architecture is based on external PCE o= r mgmt entity as PCE in client layer, but there is no counterpart in server= layer, otherwise one could have inter-PCE communication to achieve diverse= path in server layer without getting into virtual link and MELG stuff. Is that correct? Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 6:36 PM To: Vishnu Pavan Beeram; Khuzema Pithewan Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. Well, when an ingress node is initiating a service, it is doing so on reque= st from some management entity. This management entity can compute paths fo= r many services with some global criteria in mind, and then specify the res= ulting paths as explicit EROs in provisioning requests sent to each of the = service ingresses. How else, for example, you can set up several services = originated from different nodes that are disjoint from each other? Also, wh= at is the point in your opinion of the statefull PCE work? Cheers, Igor From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, April 12, 2013 8:08 AM To: Khuzema Pithewan Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Khuzema, Hi! Please see inline.. 1. When Network has more than 2 layer i.e. Packet-OTN-DWDM, the Pack= et (client) layer will be talking to its immediate server layer i.e. OTN, w= hich in turn is talking to DWDM layer. Using MELG, client layer path comput= ation can take care of resource exclusivity of virtual link for immediate s= erver layer i.e. OTN layer. However if there is resource exclusivity at DW= DM layer, this mechanism doesn't work. You need to do loose routing or use = distributed PCE model [VPB] The behavior is the same as what you would do with SRLGs in a multi-l= ayer architecture. There are architectures that allow the SRLGs in the lowe= st layer to be exported all the way up to the highest layer. The expectatio= n is that MELGs would be treated in the same vein. 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. [VPB] I'm not sure why you think there is no point in having a centralized= computation function compute paths concurrently for LSPs with different se= t of end-points. Even your NMS/planning-software can interact with such com= putation engine, retrieve all the paths and then go about initiating the pa= th-setup from the ingress of each LSP. Regards, -Pavan From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Igor Bryskin Sent: Tuesday, March 26, 2013 7:19 PM To: Dieter Beller; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Dieter, You said: >> I guess we are coming back to the essential point: "and how often concur= rent path computation will be >> used." To be honest, this surprises me quite a bit, Let me give you some of many r= easons as to why concurrent path computations are needed and why this is be= tter than computing one path at a time: 1. Computing several diverse paths for the same service in the context= of service recovery. I hope you realize that computing one path at a time = on many configurations produces no or sub-optimal results. I also hope you = realize the problem of selecting two paths with one of them having a link = with common MELG with a link from another path; 2. Computing paths for multiple services to be sufficiently disjoint f= rom each other; 3. Computing paths for multiple services to achieve a global optimizat= ion criteria (e.g. minimal summary total cost); 4. Computing paths for multiple services for the purpose of removing t= he bandwidth fragmentations; 5. Computing paths for multiple services to plan shared mesh protectio= n/restoration schemes 6. Etc. Also think about this: 1. If concurrent path computation was not important, why PCEP includes= the machinery to do that? 2. My understanding of the statefull PCE is that it does pretty much n= othing but concurrent path computations You also said: >> I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the >> TE-DB, MELG routing extensions are not needed because the information ab= out mutual >>exclusive VLs can be kept in the central TE-DB when VLs are configured. How this logic does not apply to other link attributes such as SRLGs? What if path computation is not centralized? Cheers, Igor From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Dieter Beller Sent: Monday, March 25, 2013 5:52 PM To: Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Hi Pavan, On 25.03.2013 07:29, Fatai Zhang wrote: Hi Pavan, I am not sure how much VL (Virtual Link) will be used in the practical depl= oyment and how often concurrent path computation will be used. I guess we are coming back to the essential point: "and how often concurren= t path computation will be used." This means we are trying to figure out under which conditions MELG routing = extensions could be beneficial. IMHO, they would only make sense, if: * a path computation function supports the calculation of k shortest pa= ths concurrently * if there is only a single path computation function instance per doma= in (pce approach) If path computation is done in a distributed fashion the benefit goes away = because the instances calculate paths independently! I suppose that if a pce approach is used, i.e., path computation is central= ized including the TE-DB, MELG routing extensions are not needed because the information about= mutual exclusive VLs can be kept in the central TE-DB when VLs are configured. Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their applicability is broader. Thanks, Dieter Do you think if it makes sense to add a flag (in routing advertisement) to = indicate a link is a VL or not? Best Regards Fatai From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, March 22, 2013 8:57 PM To: Fatai Zhang Cc: Igor Bryskin; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Fatai, Hi! Good to see that you understand the construct now. This is not a corner case. The utility of the construct becomes quite signi= ficant if you have an application that does concurrent path computations on= an abstract topology. Regards, -Pavan _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp -- DIETER BELLER ALCATEL-LUCENT DEUTSCHLAND AG PROJECT MANAGER ASON/GMPLS CONTROL PLANE CORE NETWORKS BUSINESS DIVISION OPTICS BU, SWITCHING R&D Lorenzstrasse 10 70435 Stuttgart, Germany Phone: +49 711 821 43125 begin_of_the_skype_highlighting [Image removed by = sender.] +49 711 821 43125 FREE end_of_the_skype_highlighting Mobil: +49 175 7266874 begin_of_the_skype_highlighting [Image removed by se= nder.] +49 175 7266874 FREE end_of_the_skype_highlighting Dieter.Beller@alcatel-lucent.com Alcatel-Lucent Deutschland AG Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026 Chairman of the Supervisory Board: Michael Oppenhoff Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe --_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923A6F2atlsrvmail10atl_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Fatai,<= /p>

 <= /p>

What is Virtual Link? As described in RFC6001,= it says as below. So my question is: when there are two VLs created through Call approach as defined in RFC6001, one has 3 potential p= aths in the server layer to setup FA-LSP, and another has 2 potential paths= in the server layer, and only one of the 3 &2 has the same resource sh= ared in the server layer.

 

How MELGs can help in this case?

 

IB>> Simple: with MELGs the path compute= r will know in advance that selecting two paths with a virtual link belonging to path #1 and a virtual link belonging to path #2 having an MEL= G in common will be a bad idea, because an attempt to provision such path c= ombination is guaranteed to fail. Without MELGs the path computer won’= ;t have such knowledge.

 

Cheers,

Igor

 <= /p>

 <= /p>

From: Fatai Zh= ang [mailto:zhangfatai@huawei.com]
Sent: Thursday, April 18, 2013 11:26 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan; Igor Bryskin; Dieter Bell= er
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

A virtual TE link is defined as a TE l= ink between two upper-layer nodes that is not associated with a fully provisioned FA-LSP in a lower layer [RFC5212].  A virtual TE link is advertised as any TE link, following the rules in [RFC4206] defined for fully provisioned TE links.  A virtual TE link represents thus the potentiality to set up an FA-LSP= in the lower layer to support the TE link that has been advertised.

=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=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<= /span>

 

 

 

 

Best Regards

 

Fatai

From: ccamp-bounces@ietf.org [mailt= o:ccamp-bounces@ietf.org] On Behalf Of Vishnu Pavan Beeram
Sent: Tuesday, April 16, 2013 10:10 PM
To: Khuzema Pithewan
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

&nbs= p;

Khuzema, = Hi!

&nbs= p;

MELGs are= useful and come into play only when:

(1) The s= erver network domain is abstracted and the advertised Virtual TE-links poss= ess some mutual exclusivity relationship.

(2) There= is a Centralized path computation entity in the client domain (computes pa= ths in terms of Client TE-links/TE-nodes) that is capable of doing concurre= nt path computations.

&nbs= p;

If either= of the above 2 statements is NOT true, there is no utility for MELGs. = ;

At the ri= sk of being pedantic: 

- Are MEL= Gs needed when the server-network domain in not abstracted (no Virtual TE l= inks)? The answer is NO.

- Are MEL= Gs needed when you have a distributed path-computation architecture (Client= PCE interacting with Server PCE)? The answer is NO.

- Are MEL= Gs needed when the centralized path-computation engine doesn't (can't) do c= oncurrent computations? The answer is NO.

&nbs= p;

The actua= l procedures involved in abstracting the server network domain is beyond th= e scope of <draft-melgs>. The abstraction procedure itself is impleme= ntation-specific (maybe someday someone would put together a draft for discussing this). Though it is true that the prim= ary use-case we had in mind when coming up with this new construct involves= a lambda-layer server network domain, there is really no restriction (at a= conceptual level) on using this construct when abstracting a packet-layer server network domain or a TDM-l= ayer server network domain. It is up to the implementation on how to make b= est use of this construct. 

&nbs= p;

When you = advertise a Virtual TE-link into a client network domain, you are doing thi= s based on the existence of some potential underlying server-path. TE attri= butes like SRLGs, MELGs, delay etc that get advertised for the Virtual TE-link depend on the underlying server-pat= h that is chosen for catering to this Client TE-link. If the underlying ser= ver-path keeps changing (based on network events), these TE attributes woul= d also keep changing. The procedure for keeping the advertised information "current" is an implement= ation choice. 

&nbs= p;

If there = exists such a thing as an abstraction manager (again, this is totally imple= mentation specific), then the assumption is that it does one of the followi= ng - 

(a) compu= tes new server-paths for the Virtual TE links whenever there is a change in= the network (may not be very scalable in some architectures), 

(b) or do= es periodic path-computation for each Virtual TE link, 

(c) or us= es a policy to pin down the Virtual TE-link to a specific underlying server= -path, 

(d) or us= es a combination of (a), (b), (c).

&nbs= p;

<draft= -melgs> doesn't make any recommendation as to what choice the abstractio= n manager would need to take.

&nbs= p;

Hope this= helps.

-Pavan

 

On Tue, A= pr 16, 2013 at 7:08 AM, Khuzema Pithewan <kpithewan@infinera.com> wrote:

Hi Igor,

 

I am trying = to summarize the discussion we had so far. Pls see if my conclusion is in sync with the idea of MELG you have

 

MELG is usef= ul when=

1.  = ;     server layer V= Ls are nailed down for the resources on the server layer links that are sha= red among multiple VLs. These resources are typically wavelength on a fiber (can it be anything else??). In other words, if 2 VL= s are pinned to use a particular wavelength on a particular fiber, then the= se 2 VLs will have MELG for the wavelength.

2.  = ;     server layer d= o not have centralized path computation entity which can be used by client = layer to ask for concurrent diverse path computation within server layer.=

3.  = ;     Client layer h= as a centralized path computation entity, which would compute paths for cli= ent+server layer.

4.  = ;     The need is to= centralized concurrent computation of more than one client+server laye= r path that meets some diversity and resource exclusivity requirements.=

 

Regds=

Khuzema

 

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Monday, April 15, 2013 9:44 PM


To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

Please, see = in-line.

 

Igor<= span style=3D"mso-fareast-language:ZH-CN">

 

From: Khuzema Pithewan [mailto:kpithewan@infinera.com]
Sent: Monday, April 15, 2013 12:05 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

I understand= the SRLG and MELG behavior you have penned .

 

My concern w= as little different.  With changing resource consumption (because of dynamicity the network has) in the network links, potential paths a set= of virtual link can take will change and hence its MELG, as it is tied to = a resource it can take. So unless virtual links paths are nailed down, it w= ould be hard to compute MELGs in distributed way.

 

IB>> I= think you are missing the point here. Virtual Link server layer paths are pinned as far as fate sharing is concerned (that is, they are pi= nned on  server layer link level). It would make little sense to adver= tise VL SRLGs if the SRLGs constantly change. The same is true for MELGs. &= nbsp;SRLGs/MELGs advertised for VLs normally do not change: neither over time nor when VLs become committed/uncommitted= .

 

Another poin= t is, virtual links can be viewed as oversubscription of resources (in MELG context). Taking an example (for OTN, I know it would work differ= ently for a Wavelength in WDM), a link resources are worth 1 TB of BW, user= has provisioned 20 virtual links of 100G each going via that OTN link. &nb= sp;Physically, only 10 will get committed. But which 10? It will really depend on network dynamics at the time of dem= and to commit. MELGs are not that effective here. You need some different m= echanism.

 

IB>> A= s I mentioned before MELGs have nothing to do with bandwidth and were never intended to solve the problems such as you describe (just like = it would not make much sense to solve such problem with SRLGs :=3D)<= span style=3D"mso-fareast-language:ZH-CN">

Again,  = ;MELG is an extreme case SRLG designed exclusively for VLs (no more and no less).<= /o:p>

 

Regds=

Khuzema

 

 

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 11:55 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

Think about = MELG as an SRLG that is shared between two or more links in its entirety. When two real links have an SRLG in common, it means that tw= o real links can co-exist concurrently, but there is something (e.g. common= conduit, note that the conduit has room for more than for one link) that w= ill bring both these links down, if this something fails (e.g. conduit is cut ). Now consider that this som= ething must be taken in its entirety by one of the links to become operatio= nal . In this case SRLG becomes MELG. Note that MELG is only meaningful for= virtual links (unlike SRLG that makes sense for either real or virtual link). Why would you advertise two = links that mutually exclude each other rather than advertising only one of = them at a time, unless the two are virtual links and hence both available f= or the client layer connections?

 

Igor

 

 

From: Khuzema Pithewan [mailto:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 1:01 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

Do you mean,= if virtual link do not have any specific constraint, for example a link in the path (not talking about egress links/interfaces) mus= t be traversed to realize the virtual link, there wont be any MELG for the = virtual link?<= /span>

 

Regds=

Khuzema

 

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 9:52 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

MELGs have n= othing to do with bandwidth. MELG is a concrete network resource in a server layer that two or more Virtual Links in a client layer depend = on in a mutually exclusive way. An example of MELG is a WDM layer transpond= er that can terminate either of respective WDM layer tunnels (but not both = at the same time) for two OTN layer Virtual Links. If you advertise a Virtual Link, say, for Ethernet layer th= at depends on the connection in OTN layer going through one of the mentione= d OTN links, the Ethernet VL must inherit the MELG similarly like it does S= RLGs advertised for the OTN links.

 

Igor<= span style=3D"mso-fareast-language:ZH-CN">

 

 

From: Khuzema Pithewan [mailto:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 12:06 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

For multi-la= yer (more than 2) network, consider all the layers are meshy (that’s when virtual links are useful anyway), MELGs of virtual link= will change as and when BW/wavelength availability changes, because potent= ial paths, a virtual link can take will change. Mapping lower layer MELGs t= o higher layer MELGs won’t be practical if done in distributed manner, so it has to be centralized. So you do have= central element in each layer that knows all the risk and paths (a PCE?), = which can be utilized for layer specific path computation (as it is doing i= t anyway).

 

This kind of= architecture has all the pieces that are required for Inter-PCE communication (across layers), except the protocol that would actually mak= e the 2 PCEs talk.

 

You seem to = be doing something that you don’t like J

 

Regards

Khuzema

 

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 8:39 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

I am not a f= an of inter-layer path computations (nor I am a fan of inter-PCE computations). In my mind path computation for a service or services in la= yer X is performed only in layer X, i.e. considers only X layer links (real= or virtual). As Pavan mentioned SRLGs and MELGs that need to be inherited = from lower layers should be translated into X layer link SRLGs/MELGs and specified with X layer specific SRLG/MEL= G IDs.<= /p>

 

Cheers,

Igor<= span style=3D"mso-fareast-language:ZH-CN">

 

 

From: Khuzema Pithewan [mailto:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 10:55 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

Ok. This wou= ld be useful if network architecture is based on external PCE or mgmt entity as PCE in client layer, but there is no counterpart in = server layer, otherwise one could have inter-PCE communication to achieve d= iverse path in server layer without getting into virtual link and MELG stuf= f.

 

Is that corr= ect?

 

Khuzema

 

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 6:36 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

2.       For cases of c= oncurrent computation (case#2-5), you are mainly talking about global optim= ization and diversity among multiple services. You can do the path computation, but to actually enact the computed path the signa= ling needs to be done from the source end of those LSPs.  So there is = no point in doing concurrent computation at one network element for the ser= vices starting from multiple network elements. At best it looks to me a problem to be solved by network managem= ent/planning software.&nb= sp;

Well, when a= n ingress node is initiating a service, it is doing so on request from some management entity. This management entity can compute pa= ths for many services with some global criteria in mind, and then specify t= he resulting paths as explicit EROs in provisioning requests sent to each o= f the service ingresses. How else, for example,  you can set up several services originated from differe= nt nodes that are disjoint from each other? Also, what is the point in your= opinion of the statefull PCE work?

 

Cheers,

Igor<= span style=3D"mso-fareast-language:ZH-CN">

 

From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com]
Sent: Friday, April 12, 2013 8:08 AM
To: Khuzema Pithewan
Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Khuzema, Hi!=


Please see inline..

 

 

 1.       When Network h= as more than 2 layer i.e. Packet-OTN-DWDM, the Packet (client) layer will b= e talking to its immediate server layer i.e. OTN, which in turn is talking to DWDM layer. Using MELG, client layer path computatio= n can take care of resource exclusivity of virtual link for immediate serve= r layer i.e. OTN layer.  However if there is resource exclusivity at D= WDM layer, this mechanism doesn’t work. You need to do loose routing or use distributed PCE model

 

[VPB] The behavior is t= he same as what you would do with SRLGs in a multi-layer architecture. Ther= e are architectures that allow the SRLGs in the lowest layer to be exported all the way up to the highest layer. Th= e expectation is that MELGs would be treated in the same vein. 

2.       For cases of c= oncurrent computation (case#2-5), you are mainly talking about global optim= ization and diversity among multiple services. You can do the path computation, but to actually enact the computed path the signa= ling needs to be done from the source end of those LSPs.  So there is = no point in doing concurrent computation at one network element for the ser= vices starting from multiple network elements. At best it looks to me a problem to be solved by network managem= ent/planning software.&nb= sp;

[VPB]  I'm not sur= e why you think there is no point in having a centralized computation funct= ion compute paths concurrently for LSPs with different set of end-points. Even your NMS/planning-software can interact = with such computation engine, retrieve all the paths and then go about init= iating the path-setup from the ingress of each LSP. =

 

Regards,

-Pavan

 

 

 

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Tuesday, March 26, 2013 7:19 PM
To: Dieter Beller; Vishnu Pavan Beeram


Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Dieter,

 

You said:

>> I guess we are= coming back to the essential point: "and how often concurrent path computation will be >> used."

 

To be honest, this surp= rises me quite a bit, Let me give you some of many reasons as to why concur= rent path computations are needed and why this is better than computing one path at a time:

 

1.      Computing several diverse= paths for the same service in the context of service recovery. I hope you = realize that computing one path at a time on many configurations produces n= o or sub-optimal results. I also hope you realize the problem of selecting two paths with one of them  havi= ng a link with common MELG with a link from another path;=

2.      Computing paths for multi= ple services to be sufficiently disjoint from each other;=

3.      Computing paths for multi= ple services to achieve a global optimization criteria (e.g. minimal summar= y total cost);

4.      Computing paths for multi= ple services for the purpose of removing the bandwidth fragmentations;=

5.      Computing paths for multi= ple services to plan shared mesh protection/restoration schemes<= /span>

6.      Etc.

 

Also think about this:<= o:p>

1.      If concurrent path comput= ation was not important, why PCEP includes the machinery to do that?

2.      My understanding of the s= tatefull PCE is that it does pretty much nothing but concurrent path comput= ations

 

You also said:

>> I suppose that if a = pce approach is used, i.e., path computation is centralized including the >> TE-DB, MELG routing extensions are not needed because the informat= ion about mutual
>>exclusive VLs can be kept in the central TE-DB when VLs are configu= red.

How this logic does not= apply to other link attributes such as SRLGs?

What if path computatio= n is not centralized?

 

Cheers,

Igor

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Hi Pavan,<= /p>

On 25.03.2013 07:29, Fat= ai Zhang wrote:

Hi Pavan,

 

I am not sur= e how much VL (Virtual Link) will be used in the practical deployment and how often concurrent path computation will be used.<= span style=3D"mso-fareast-language:ZH-CN">

I guess we are coming b= ack to the essential point: "and how often concurrent path computation will be used."

This means we are trying to figure out under which conditions MELG routing = extensions
could be beneficial.

IMHO, they would only make sense, if:

  • a path computation function supp= orts the calculation of k shortest paths concurrently
  • if there is only a single path c= omputation function instance per domain (pce approach)
    If path computation is done in a distributed fashion the benefit goes away = because
    the instances calculate paths independently!

I suppose that if a pce appro= ach is used, i.e., path computation is centralized including the
TE-DB, MELG routing extensions are not needed because the information about= mutual
exclusive VLs can be kept in the central TE-DB when VLs are configured.

Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their
applicability is broader.


Thanks,
Dieter

 

Do you think if it ma= kes sense to add a flag (in routing advertisement) to indicate a link is a = VL or not?

 

 

 

Best Regards

 

Fatai

 

From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Fatai, Hi!

 

Good to see that you un= derstand the construct now.

 

This is not a corner ca= se. The utility of the construct becomes quite significant if you have an a= pplication that does concurrent path computations on an abstract topology.

 

Regards,

-Pavan

 

___________________________=
____________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman=
/listinfo/ccamp

 

--

= DIETER BELLER

ALCATEL-LUCEN= T DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 711 821 43125 begin_of_the_skype_highlighting 3D"Image+49 711 821 43125 FREE  end_of_the_skype_highlighting
Mobil: +49 175 7266874 begin_of_the_skype_highlighting 3D"Image+49 175 7266874 FREE  = end_of_the_skype_highlighting

 

Alcatel-Lucent Deutschland A= G
Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe

 

&nbs= p;

--_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923A6F2atlsrvmail10atl_-- --_004_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923A6F2atlsrvmail10atl_ Content-Type: image/jpeg; name="~WRD000.jpg" Content-Description: ~WRD000.jpg Content-Disposition: inline; filename="~WRD000.jpg"; size=823; creation-date="Fri, 19 Apr 2013 12:16:28 GMT"; modification-date="Fri, 19 Apr 2013 12:16:28 GMT" Content-ID: <~WRD000.jpg> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABkAGQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigD//2Q== --_004_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923A6F2atlsrvmail10atl_-- From vishnupavan@gmail.com Fri Apr 19 07:28:48 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477E021F94DC for ; Fri, 19 Apr 2013 07:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, NO_RELAYS=-0.001] 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 HPTpV1vW-p-E for ; Fri, 19 Apr 2013 07:28:45 -0700 (PDT) Received: from mail-bk0-x22c.google.com (mail-bk0-x22c.google.com [IPv6:2a00:1450:4008:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 34A4321F94FF for ; Fri, 19 Apr 2013 07:28:44 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jk13so1745959bkc.17 for ; Fri, 19 Apr 2013 07:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=TyDaOuOAtwHAzeYi/KRjoToRoTzHXUJBy/jFI4ZoC18=; b=EYI6153RFhs3GSQGcnDhDkZrHdugHOP97xw9c9KANV+atoacgo4Z0yvgTehTCWYhll jE3kr7+lee8k+nhjx0UBkV4pp3W2GsP/DtjdI7MVEjFQYTYzcxMwZeDkZ1ig0aEgtWre eyu/8YRh2DfsMlozsu4J7DrKwpJb3gHd781aXO5WVK/3Nu8OKkdHNDrV/JCUxfHc+/g1 hODZcyEUdACFBMtuSsSprsAW9Qqxo0yVDOec5n475yCoVbTIHrMzO981N7F0EVlQ8CBQ LXmSvXNEA7VNijiK2oL2LxcvUYeDg2DrIG1AUx6h/Gjd4/zG1zmT+iOZAUXDY7McW0w6 ZOgg== MIME-Version: 1.0 X-Received: by 10.204.233.81 with SMTP id jx17mr4845218bkb.52.1366381723075; Fri, 19 Apr 2013 07:28:43 -0700 (PDT) Received: by 10.205.127.137 with HTTP; Fri, 19 Apr 2013 07:28:42 -0700 (PDT) In-Reply-To: References: <5150C704.2040007@alcatel-lucent.com> Date: Fri, 19 Apr 2013 10:28:42 -0400 Message-ID: From: Vishnu Pavan Beeram To: Fatai Zhang Content-Type: multipart/alternative; boundary=485b3979d9283d0d4f04dab78910 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] MELGs - Q&A X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 14:28:48 -0000 --485b3979d9283d0d4f04dab78910 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Fatai, Hi! See inline: ** ** > > I still think that MELGS can only handle a very small corner case as you > put many cases below where MELGs are not needed. > [VPB] MELGs come into play when there are Virtual TE Links and there is a client computation function capable of doing concurrent computations. If the client computation function cannot do concurrent computations, then the MELGs have NO utility. If you are not using Virtual TE Links and are relying on a hierarchical PCE framework to co-ordinate between the client and server domains for the selection of paths, then you don't need MELGs. Let me try an analogy - If I'm riding a bike, I need a helmet. If I'm driving a car (not NASCAR), the helmet has no utility. That doesn't mean the helmet serves a small corner case :) > **** > > ** ** > > What is Virtual Link? As described in RFC6001, it says as below. So my > question is: when there are two VLs created through Call approach as > defined in RFC6001, one has 3 potential paths in the server layer to setu= p > FA-LSP, and another has 2 potential paths in the server layer, and only o= ne > of the 3 &2 has the same resource shared in the server layer. **** > > ** ** > > How MELGs can help in this case? > [VPB] I think the disconnect between us has got to do with how the Virtual TE (VTE) Link gets advertised. Say, that there are 3 potential paths in the server layer that can cater to a given VTE link. In our notion of the "Virtual TE Link", at the time of advertising there already exists an association between the VTE link and one of these 3 paths. Without associating your VTE link with a specific server-path, you wouldn't be able to accurately advertise attributes like diversity, delay, mutual-exclusivity etc. If I understood your question correctly, your notion of how the Virtual TE Link gets advertised seems to be different - you don't associate the VTE link to a specific potential path at the time of advertisement. Continuing with your example - If the path that gets associated with VTE-Link-1 and the path that gets associated with VTE-Link-2 depend on the same resource, "MELGs" would make sure that the client computation function is aware of the existence of such "mutual exclusivity" relationship. BR, -Pavan > **** > > > =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=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 > **** > > A virtual TE link is defined as a TE link between two upper-layer nodes > that is not associated with a fully provisioned FA-LSP in a lower layer [ > RFC5212 ]. A virtual TE link is > advertised as any TE link, following the rules in [RFC4206] > defined for fully provisioned TE links. A virtual TE link represents > thus the potentiality to set up an FA-LSP in the lower layer to support > the TE link that has been advertised.**** > > > =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=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 > **** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > Best Regards**** > > ** ** > > Fatai**** > > ** ** > > *From:* ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] *On Behalf > Of *Vishnu Pavan Beeram > *Sent:* Tuesday, April 16, 2013 10:10 PM > *To:* Khuzema Pithewan > > *Cc:* ccamp@ietf.org > *Subject:* Re: [CCAMP] MELGs - Q&A**** > > ** ** > > Khuzema, Hi!**** > > ** ** > > MELGs are useful and come into play only when:**** > > (1) The server network domain is abstracted and the advertised Virtual > TE-links possess some mutual exclusivity relationship.**** > > (2) There is a Centralized path computation entity in the client domain > (computes paths in terms of Client TE-links/TE-nodes) that is capable of > doing concurrent path computations.**** > > ** ** > > If either of the above 2 statements is NOT true, there is no utility for > MELGs. **** > > At the risk of being pedantic: **** > > - Are MELGs needed when the server-network domain in not abstracted (no > Virtual TE links)? The answer is NO.**** > > - Are MELGs needed when you have a distributed path-computation > architecture (Client PCE interacting with Server PCE)? The answer is NO.*= * > ** > > - Are MELGs needed when the centralized path-computation engine doesn't > (can't) do concurrent computations? The answer is NO.**** > > ** ** > > The actual procedures involved in abstracting the server network domain i= s > beyond the scope of . The abstraction procedure itself is > implementation-specific (maybe someday someone would put together a draft > for discussing this). Though it is true that the primary use-case we had = in > mind when coming up with this new construct involves a lambda-layer serve= r > network domain, there is really no restriction (at a conceptual level) on > using this construct when abstracting a packet-layer server network domai= n > or a TDM-layer server network domain. It is up to the implementation on h= ow > to make best use of this construct. **** > > ** ** > > When you advertise a Virtual TE-link into a client network domain, you ar= e > doing this based on the existence of some potential underlying server-pat= h. > TE attributes like SRLGs, MELGs, delay etc that get advertised for the > Virtual TE-link depend on the underlying server-path that is chosen for > catering to this Client TE-link. If the underlying server-path keeps > changing (based on network events), these TE attributes would also keep > changing. The procedure for keeping the advertised information "current" = is > an implementation choice. **** > > ** ** > > If there exists such a thing as an abstraction manager (again, this is > totally implementation specific), then the assumption is that it does one > of the following - **** > > (a) computes new server-paths for the Virtual TE links whenever there is = a > change in the network (may not be very scalable in some architectures), *= * > ** > > (b) or does periodic path-computation for each Virtual TE link, **** > > (c) or uses a policy to pin down the Virtual TE-link to a specific > underlying server-path, **** > > (d) or uses a combination of (a), (b), (c).**** > > ** ** > > doesn't make any recommendation as to what choice the > abstraction manager would need to take.**** > > ** ** > > Hope this helps.**** > > -Pavan**** > > ** ** > > On Tue, Apr 16, 2013 at 7:08 AM, Khuzema Pithewan > wrote:**** > > Hi Igor,**** > > **** > > I am trying to summarize the discussion we had so far. Pls see if my > conclusion is in sync with the idea of MELG you have **** > > **** > > MELG is useful when**** > > 1. server layer VLs are nailed down for the resources on the server > layer links that are shared among multiple VLs. These resources are > typically wavelength on a fiber (can it be anything else??). In other > words, if 2 VLs are pinned to use a particular wavelength on a particular > fiber, then these 2 VLs will have MELG for the wavelength.**** > > 2. server layer do not have centralized path computation entity > which can be used by client layer to ask for concurrent diverse path > computation within server layer.**** > > 3. Client layer has a centralized path computation entity, which > would compute paths for client+server layer.**** > > 4. The need is to centralized concurrent computation of more than > one client+server layer path that meets some diversity and resource > exclusivity requirements.**** > > **** > > Regds**** > > Khuzema**** > > **** > > *From:* Igor Bryskin [mailto:IBryskin@advaoptical.com] > *Sent:* Monday, April 15, 2013 9:44 PM**** > > > *To:* Khuzema Pithewan; Vishnu Pavan Beeram > *Cc:* Dieter Beller; ccamp@ietf.org > *Subject:* RE: [CCAMP] MELGs - Q&A**** > > **** > > Khuzema,**** > > Please, see in-line.**** > > **** > > Igor**** > > **** > > *From:* Khuzema Pithewan [mailto:kpithewan@infinera.com] > *Sent:* Monday, April 15, 2013 12:05 AM > *To:* Igor Bryskin; Vishnu Pavan Beeram > *Cc:* Dieter Beller; ccamp@ietf.org > *Subject:* RE: [CCAMP] MELGs - Q&A**** > > **** > > Hi Igor,**** > > **** > > I understand the SRLG and MELG behavior you have penned .**** > > **** > > My concern was little different. With changing resource consumption > (because of dynamicity the network has) in the network links, potential > paths a set of virtual link can take will change and hence its MELG, as i= t > is tied to a resource it can take. So unless virtual links paths are nail= ed > down, it would be hard to compute MELGs in distributed way.**** > > **** > > IB>> I think you are missing the point here. Virtual Link server layer > paths are pinned as far as fate sharing is concerned (that is, they are > pinned on server layer link level). It would make little sense to > advertise VL SRLGs if the SRLGs constantly change. The same is true for > MELGs. SRLGs/MELGs advertised for VLs normally do not change: neither ov= er > time nor when VLs become committed/uncommitted.**** > > **** > > Another point is, virtual links can be viewed as oversubscription of > resources (in MELG context). Taking an example (for OTN, I know it would > work differently for a Wavelength in WDM), a link resources are worth 1 T= B > of BW, user has provisioned 20 virtual links of 100G each going via that > OTN link. Physically, only 10 will get committed. But which 10? It will > really depend on network dynamics at the time of demand to commit. MELGs > are not that effective here. You need some different mechanism.**** > > **** > > IB>> As I mentioned before MELGs have nothing to do with bandwidth and > were never intended to solve the problems such as you describe (just like > it would not make much sense to solve such problem with SRLGs :=3D)**** > > Again, MELG is an extreme case SRLG designed exclusively for VLs (no mor= e > and no less).**** > > **** > > Regds**** > > Khuzema**** > > **** > > **** > > *From:* Igor Bryskin [mailto:IBryskin@advaoptical.com] > > *Sent:* Friday, April 12, 2013 11:55 PM > *To:* Khuzema Pithewan; Vishnu Pavan Beeram > *Cc:* Dieter Beller; ccamp@ietf.org > *Subject:* RE: [CCAMP] MELGs - Q&A**** > > **** > > Khuzema,**** > > **** > > Think about MELG as an SRLG that is shared between two or more links in > its entirety. When two real links have an SRLG in common, it means that t= wo > real links can co-exist concurrently, but there is something (e.g. common > conduit, note that the conduit has room for more than for one link) that > will bring both these links down, if this something fails (e.g. conduit i= s > cut ). Now consider that this something must be taken in its entirety by > one of the links to become operational . In this case SRLG becomes MELG. > Note that MELG is only meaningful for virtual links (unlike SRLG that mak= es > sense for either real or virtual link). Why would you advertise two links > that mutually exclude each other rather than advertising only one of them > at a time, unless the two are virtual links and hence both available for > the client layer connections?**** > > **** > > Igor **** > > **** > > **** > > *From:* Khuzema Pithewan [mailto:kpithewan@infinera.com] > > *Sent:* Friday, April 12, 2013 1:01 PM > *To:* Igor Bryskin; Vishnu Pavan Beeram > *Cc:* Dieter Beller; ccamp@ietf.org > *Subject:* RE: [CCAMP] MELGs - Q&A**** > > **** > > Hi Igor,**** > > **** > > Do you mean, if virtual link do not have any specific constraint, for > example a link in the path (not talking about egress links/interfaces) mu= st > be traversed to realize the virtual link, there wont be any MELG for the > virtual link?**** > > **** > > Regds**** > > Khuzema**** > > **** > > *From:* Igor Bryskin [mailto:IBryskin@advaoptical.com] > > *Sent:* Friday, April 12, 2013 9:52 PM > *To:* Khuzema Pithewan; Vishnu Pavan Beeram > *Cc:* Dieter Beller; ccamp@ietf.org > *Subject:* RE: [CCAMP] MELGs - Q&A**** > > **** > > Khuzema,**** > > **** > > MELGs have nothing to do with bandwidth. MELG is a concrete network > resource in a server layer that two or more Virtual Links in a client lay= er > depend on in a mutually exclusive way. An example of MELG is a WDM layer > transponder that can terminate either of respective WDM layer tunnels (bu= t > not both at the same time) for two OTN layer Virtual Links. If you > advertise a Virtual Link, say, for Ethernet layer that depends on the > connection in OTN layer going through one of the mentioned OTN links, the > Ethernet VL must inherit the MELG similarly like it does SRLGs advertised > for the OTN links.**** > > **** > > Igor**** > > **** > > **** > > *From:* Khuzema Pithewan [mailto:kpithewan@infinera.com] > > *Sent:* Friday, April 12, 2013 12:06 PM > *To:* Igor Bryskin; Vishnu Pavan Beeram > *Cc:* Dieter Beller; ccamp@ietf.org > *Subject:* RE: [CCAMP] MELGs - Q&A**** > > **** > > Hi Igor,**** > > **** > > For multi-layer (more than 2) network, consider all the layers are meshy > (that=92s when virtual links are useful anyway), MELGs of virtual link wi= ll > change as and when BW/wavelength availability changes, because potential > paths, a virtual link can take will change. Mapping lower layer MELGs to > higher layer MELGs won=92t be practical if done in distributed manner, so= it > has to be centralized. So you do have central element in each layer that > knows all the risk and paths (a PCE?), which can be utilized for layer > specific path computation (as it is doing it anyway). **** > > **** > > This kind of architecture has all the pieces that are required for > Inter-PCE communication (across layers), except the protocol that would > actually make the 2 PCEs talk.**** > > **** > > You seem to be doing something that you don=92t like J**** > > **** > > Regards**** > > Khuzema**** > > **** > > *From:* Igor Bryskin [mailto:IBryskin@advaoptical.com] > > *Sent:* Friday, April 12, 2013 8:39 PM > *To:* Khuzema Pithewan; Vishnu Pavan Beeram > *Cc:* Dieter Beller; ccamp@ietf.org > *Subject:* RE: [CCAMP] MELGs - Q&A**** > > **** > > Khuzema,**** > > **** > > I am not a fan of inter-layer path computations (nor I am a fan of > inter-PCE computations). In my mind path computation for a service or > services in layer X is performed only in layer X, i.e. considers only X > layer links (real or virtual). As Pavan mentioned SRLGs and MELGs that ne= ed > to be inherited from lower layers should be translated into X layer link > SRLGs/MELGs and specified with X layer specific SRLG/MELG IDs.**** > > **** > > Cheers,**** > > Igor**** > > **** > > **** > > *From:* Khuzema Pithewan [mailto:kpithewan@infinera.com] > > *Sent:* Friday, April 12, 2013 10:55 AM > *To:* Igor Bryskin; Vishnu Pavan Beeram > *Cc:* Dieter Beller; ccamp@ietf.org > *Subject:* RE: [CCAMP] MELGs - Q&A**** > > **** > > Hi Igor,**** > > **** > > Ok. This would be useful if network architecture is based on external PCE > or mgmt entity as PCE in client layer, but there is no counterpart in > server layer, otherwise one could have inter-PCE communication to achieve > diverse path in server layer without getting into virtual link and MELG > stuff.**** > > **** > > Is that correct?**** > > **** > > Khuzema**** > > **** > > *From:* Igor Bryskin [mailto:IBryskin@advaoptical.com] > > *Sent:* Friday, April 12, 2013 6:36 PM > *To:* Vishnu Pavan Beeram; Khuzema Pithewan > *Cc:* Dieter Beller; ccamp@ietf.org > *Subject:* RE: [CCAMP] MELGs - Q&A**** > > **** > > Khuzema,**** > > **** > > 2. For cases of concurrent computation (case#2-5), you are mainly > talking about global optimization and diversity among multiple services. > You can do the path computation, but to actually enact the computed path > the signaling needs to be done from the source end of those LSPs. So the= re > is no point in doing concurrent computation at one network element for th= e > services starting from multiple network elements. At best it looks to me = a > problem to be solved by network management/planning software. **** > > Well, when an ingress node is initiating a service, it is doing so on > request from some management entity. This management entity can compute > paths for many services with some global criteria in mind, and then speci= fy > the resulting paths as explicit EROs in provisioning requests sent to eac= h > of the service ingresses. How else, for example, you can set up several > services originated from different nodes that are disjoint from each othe= r? > Also, what is the point in your opinion of the statefull PCE work? **** > > **** > > Cheers,**** > > Igor**** > > **** > > *From:* Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] > > *Sent:* Friday, April 12, 2013 8:08 AM > *To:* Khuzema Pithewan > *Cc:* Igor Bryskin; Dieter Beller; ccamp@ietf.org > *Subject:* Re: [CCAMP] MELGs - Q&A**** > > **** > > Khuzema, Hi!**** > > > Please see inline..**** > > **** > > **** > > 1. When Network has more than 2 layer i.e. Packet-OTN-DWDM, the > Packet (client) layer will be talking to its immediate server layer i.e. > OTN, which in turn is talking to DWDM layer. Using MELG, client layer pat= h > computation can take care of resource exclusivity of virtual link for > immediate server layer i.e. OTN layer. However if there is resource > exclusivity at DWDM layer, this mechanism doesn=92t work. You need to do > loose routing or use distributed PCE model**** > > **** > > [VPB] The behavior is the same as what you would do with SRLGs in a > multi-layer architecture. There are architectures that allow the SRLGs in > the lowest layer to be exported all the way up to the highest layer. The > expectation is that MELGs would be treated in the same vein. **** > > 2. For cases of concurrent computation (case#2-5), you are mainly > talking about global optimization and diversity among multiple services. > You can do the path computation, but to actually enact the computed path > the signaling needs to be done from the source end of those LSPs. So the= re > is no point in doing concurrent computation at one network element for th= e > services starting from multiple network elements. At best it looks to me = a > problem to be solved by network management/planning software. **** > > [VPB] I'm not sure why you think there is no point in having a > centralized computation function compute paths concurrently for LSPs with > different set of end-points. Even your NMS/planning-software can interact > with such computation engine, retrieve all the paths and then go about > initiating the path-setup from the ingress of each LSP. **** > > **** > > Regards,**** > > -Pavan**** > > **** > > **** > > **** > > **** > > *From:* ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] *On Behalf > Of *Igor Bryskin > *Sent:* Tuesday, March 26, 2013 7:19 PM > *To:* Dieter Beller; Vishnu Pavan Beeram**** > > > *Cc:* ccamp@ietf.org > *Subject:* Re: [CCAMP] MELGs - Q&A**** > > **** > > Dieter,**** > > **** > > You said:**** > > >> I guess we are coming back to the essential point: "and how often > concurrent path computation will be >> used."**** > > **** > > To be honest, this surprises me quite a bit, Let me give you some of many > reasons as to why concurrent path computations are needed and why this is > better than computing one path at a time:**** > > **** > > 1. Computing several diverse paths for the same service in the > context of service recovery. I hope you realize that computing one path a= t > a time on many configurations produces no or sub-optimal results. I also > hope you realize the problem of selecting two paths with one of them > having a link with common MELG with a link from another path;**** > > 2. Computing paths for multiple services to be sufficiently disjoint > from each other;**** > > 3. Computing paths for multiple services to achieve a global > optimization criteria (e.g. minimal summary total cost);**** > > 4. Computing paths for multiple services for the purpose of removing > the bandwidth fragmentations;**** > > 5. Computing paths for multiple services to plan shared mesh > protection/restoration schemes**** > > 6. Etc.**** > > **** > > Also think about this:**** > > 1. If concurrent path computation was not important, why PCEP > includes the machinery to do that?**** > > 2. My understanding of the statefull PCE is that it does pretty much > nothing but concurrent path computations**** > > **** > > You also said:**** > > >> I suppose that if a pce approach is used, i.e., path computation is > centralized including the > >> TE-DB, MELG routing extensions are not needed because the information > about mutual > >>exclusive VLs can be kept in the central TE-DB when VLs are configured.= * > *** > > How this logic does not apply to other link attributes such as SRLGs?**** > > What if path computation is not centralized?**** > > **** > > Cheers,**** > > Igor**** > > **** > > *From:* ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] *On Behalf > Of *Dieter Beller > *Sent:* Monday, March 25, 2013 5:52 PM > *To:* Vishnu Pavan Beeram > *Cc:* ccamp@ietf.org > *Subject:* Re: [CCAMP] MELGs - Q&A**** > > **** > > Hi Pavan,**** > > On 25.03.2013 07:29, Fatai Zhang wrote:**** > > Hi Pavan,**** > > **** > > I am not sure how much VL (Virtual Link) will be used in the practical > deployment and how often concurrent path computation will be used.**** > > I guess we are coming back to the essential point: "and how often > concurrent path computation will be used." > > This means we are trying to figure out under which conditions MELG routin= g > extensions > could be beneficial. > > IMHO, they would only make sense, if:**** > > - a path computation function supports the calculation of k shortest > paths concurrently**** > - if there is only a single path computation function instance per > domain (pce approach) > If path computation is done in a distributed fashion the benefit goes > away because > the instances calculate paths independently!**** > > I suppose that if a pce approach is used, i.e., path computation is > centralized including the > TE-DB, MELG routing extensions are not needed because the information > about mutual > exclusive VLs can be kept in the central TE-DB when VLs are configured. > > Hence, it is quite doubtful whether MELG routing extensions are really > useful unless their > applicability is broader. > > > Thanks, > Dieter**** > > **** > > Do you think if it makes sense to add a flag (in routing advertisement) t= o > indicate a link is a VL or not?**** > > **** > > **** > > **** > > Best Regards**** > > **** > > Fatai**** > > **** > > *From:* Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] > > *Sent:* Friday, March 22, 2013 8:57 PM > *To:* Fatai Zhang > *Cc:* Igor Bryskin; ccamp@ietf.org > *Subject:* Re: [CCAMP] MELGs - Q&A**** > > **** > > Fatai, Hi!**** > > **** > > Good to see that you understand the construct now.**** > > **** > > This is not a corner case. The utility of the construct becomes quite > significant if you have an application that does concurrent path > computations on an abstract topology.**** > > **** > > Regards,**** > > -Pavan**** > > **** > > _______________________________________________**** > > CCAMP mailing list**** > > CCAMP@ietf.org**** > > https://www.ietf.org/mailman/listinfo/ccamp**** > > **** > > -- **** > > *DIETER BELLER ***** > > ALCATEL-LUCENT DEUTSCHLAND AG > PROJECT MANAGER ASON/GMPLS CONTROL PLANE > CORE NETWORKS BUSINESS DIVISION > OPTICS BU, SWITCHING R&D > > Lorenzstrasse 10 > 70435 Stuttgart, Germany > Phone: +49 711 821 43125 begin_of_the_skype_highlighting +49 711 821 4312= 5FREE > end_of_the_skype_highlighting begin_of_the_skype_highlighting +49 711 821 > 43125 begin_of_the_skype_highlighting +49 711 821 43125 FREE > end_of_the_skype_highlighting FREE begin_of_the_skype_highlighting +49 > 711 821 43125 FREE <%2B49%20711%20821%2043125> > Mobil: +49 175 7266874 begin_of_the_skype_highlighting +49 175 7266874FRE= E > end_of_the_skype_highlighting begin_of_the_skype_highlighting +49 175 > 7266874 begin_of_the_skype_highlighting +49 175 7266874 FREE > end_of_the_skype_highlighting FREE begin_of_the_skype_highlighting +49 > 175 7266874 FREE <%2B49%20175%207266874> **** > > *Dieter.Beller@alcatel-lucent.com ***** > > **** > > Alcatel-Lucent Deutschland AG > Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026 > Chairman of the Supervisory Board: Michael Oppenhoff > Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. > Rainer Fechner =B7 Andreas Gehe **** > > **** > > ** ** > --485b3979d9283d0d4f04dab78910 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Fatai, Hi!

See inline:
=

=A0=

I still th= ink that MELGS can only handle a very small corner case as you put many cas= es below where MELGs are not needed.


[VPB] MELGs come into pl= ay when there are Virtual TE Links and =A0there is a client computation fun= ction capable of doing concurrent computations. If the client computation f= unction cannot do concurrent computations, then the MELGs have NO utility. = =A0If you are not using Virtual TE Links and are relying on a hierarchical = PCE framework to co-ordinate between the client and server domains for the = selection of paths, then you don't need MELGs.

Let me try an analogy - If I'm riding a= bike, I need a helmet. If I'm driving a car (not NASCAR), the helmet h= as no utility. That doesn't mean the helmet serves a small corner case = :) =A0
=A0

=A0=

What is Vi= rtual Link? As described in RFC6001, it says as below. So my question is: w= hen there are two VLs created through Call approach as defined in RFC6001, one has 3 potential paths in the server layer to setup FA-LSP,= and another has 2 potential paths in the server layer, and only one of the= 3 &2 has the same resource shared in the server layer.

=A0=

How MELGs = can help in this case?


[VPB] I think the disconnect between us has got to do with how the Virtual = TE (VTE) Link gets advertised. Say, that there are 3 potential paths in the= server layer that can cater to a given VTE link. In our notion of the &quo= t;Virtual TE Link", at the time of advertising there already exists an= association between the VTE link and one of these 3 paths. Without associa= ting your VTE link with a specific server-path, you wouldn't be able to= accurately advertise attributes like diversity, delay, mutual-exclusivity = etc. If I understood your question correctly, your notion of how the Virtua= l TE Link gets advertised seems to be different - you don't associate t= he VTE link to a specific potential path at the time of advertisement.=A0

Continuing with your example - If the path that g= ets associated with VTE-Link-1 and the path that gets associated with VTE-L= ink-2 depend on the same resource, "MELGs" would make sure that t= he client computation function is aware of the existence of such "mutu= al exclusivity" relationship.=A0

BR,
-Pavan
=A0

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

A virtual = TE link is defined as a TE link between two upper-layer nodes that is not a= ssociated with a fully provisioned FA-LSP in a lower layer [RFC5212].=A0 A virtual TE link is advertised as any TE link, following the rules in [RFC= 4206] defined for fully provisioned TE links.=A0 A virtual TE link represents thus the potentiality to set up an FA-LSP in the lower layer to support the TE link that has been advertised.=

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

=A0=

=A0

=A0

=A0

=A0

Best Regards<= /span>

=A0

Fatai<= /p>

=A0=

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Vishnu Pavan Beeram
Sent: Tuesday, April 16, 2013 10:10 PM
To: Khuzema Pithewan


Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

=A0

Khuzema, Hi!

=A0

MELGs are useful and come into = play only when:

(1) The server network domain i= s abstracted and the advertised Virtual TE-links possess some mutual exclus= ivity relationship.

(2) There is a Centralized path= computation entity in the client domain (computes paths in terms of Client= TE-links/TE-nodes) that is capable of doing concurrent path computations.<= u>

=A0

If either of the above 2 statem= ents is NOT true, there is no utility for MELGs.=A0

At the risk of being pedantic:= =A0

- Are MELGs needed when the ser= ver-network domain in not abstracted (no Virtual TE links)? The answer is N= O.

- Are MELGs needed when you hav= e a distributed path-computation architecture (Client PCE interacting with = Server PCE)? The answer is NO.

- Are MELGs needed when the cen= tralized path-computation engine doesn't (can't) do concurrent comp= utations? The answer is NO.

=A0

The actual procedures involved = in abstracting the server network domain is beyond the scope of <draft-m= elgs>. The abstraction procedure itself is implementation-specific (mayb= e someday someone would put together a draft for discussing this). Though it is true that the primary use-case we had i= n mind when coming up with this new construct involves a lambda-layer serve= r network domain, there is really no restriction (at a conceptual level) on= using this construct when abstracting a packet-layer server network domain or a TDM-layer server network domain.= It is up to the implementation on how to make best use of this construct.= =A0

=A0

When you advertise a Virtual TE= -link into a client network domain, you are doing this based on the existen= ce of some potential underlying server-path. TE attributes like SRLGs, MELG= s, delay etc that get advertised for the Virtual TE-link depend on the underlying server-path that is chosen fo= r catering to this Client TE-link. If the underlying server-path keeps chan= ging (based on network events), these TE attributes would also keep changin= g. The procedure for keeping the advertised information "current" is an implementation choice.=A0=

=A0

If there exists such a thing as= an abstraction manager (again, this is totally implementation specific), t= hen the assumption is that it does one of the following -=A0<= /span>

(a) computes new server-paths f= or the Virtual TE links whenever there is a change in the network (may not = be very scalable in some architectures),=A0

(b) or does periodic path-compu= tation for each Virtual TE link,=A0

(c) or uses a policy to pin dow= n the Virtual TE-link to a specific underlying server-path,=A0

(d) or uses a combination of (a= ), (b), (c).

=A0

<draft-melgs> doesn't= make any recommendation as to what choice the abstraction manager would ne= ed to take.

=A0

Hope this helps.<= /span>

-Pavan

= =A0

On Tue, Apr 16, 2013 at 7:08 AM= , Khuzema Pithewan <kpithewan@infinera.com> wrote:

Hi Igor,

=A0=

I am tryin= g to summarize the discussion we had so far. Pls see if my conclusion is in sync with the idea of MELG you have =

=A0=

MELG is us= eful when

1.=A0=A0=A0=A0=A0=A0 server layer VLs are naile= d down for the resources on the server layer links that are shared among mu= ltiple VLs. These resources are typically wavelength on a fiber (can it be anything else??). In other words, if 2 VLs are pinned t= o use a particular wavelength on a particular fiber, then these 2 VLs will = have MELG for the wavelength.

2.=A0=A0=A0=A0=A0=A0 server layer do not have c= entralized path computation entity which can be used by client layer to ask= for concurrent diverse path computation within server layer.

3.=A0=A0=A0=A0=A0=A0 Client layer has a central= ized path computation entity, which would compute paths for client+server l= ayer.

4.=A0=A0=A0=A0=A0=A0 The need is to centralized= concurrent computation of more than one client+server layer path that meet= s some diversity and resource exclusivity requirements.

=A0=

Regds

Khuzema

=A0=

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Monday, April 15, 2013 9:44 PM<= /u>


To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

=A0

Khuzema,

Please, se= e in-line.

=A0=

Igor

=A0=

From: Khuzema Pithewan [mailto:kpithewan@infinera.com]
Sent: Monday, April 15, 2013 12:05 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A<= /u>

=A0

Hi Igor,

=A0=

I understa= nd the SRLG and MELG behavior you have penned .=

=A0=

My concern= was little different.=A0 With changing resource consumption (because of dy= namicity the network has) in the network links, potential paths a set of virtual li= nk can take will change and hence its MELG, as it is tied to a resource it = can take. So unless virtual links paths are nailed down, it would be hard t= o compute MELGs in distributed way.

=A0=

IB>>= I think you are missing the point here. Virtual Link server layer paths ar= e pinned as far as fate sharing is concerned (that is, they are pinned on =A0server= layer link level). It would make little sense to advertise VL SRLGs if the= SRLGs constantly change. The same is true for MELGs. =A0SRLGs/MELGs advert= ised for VLs normally do not change: neither over time nor when VLs become committed/uncommitted.

=A0=

Another po= int is, virtual links can be viewed as oversubscription of resources (in ME= LG context). Taking an example (for OTN, I know it would work differently for= a Wavelength in WDM), a link resources are worth 1 TB of BW, user has prov= isioned 20 virtual links of 100G each going via that OTN link. =A0Physicall= y, only 10 will get committed. But which 10? It will really depend on network dynamics at the time of demand = to commit. MELGs are not that effective here. You need some different mecha= nism.

=A0=

IB>>= As I mentioned before MELGs have nothing to do with bandwidth and were nev= er intended to solve the problems such as you describe (just like it would not make mu= ch sense to solve such problem with SRLGs :=3D)=

Again, =A0= MELG is an extreme case SRLG designed exclusively for VLs (no more and no l= ess).

=A0=

Regds

Khuzema

=A0=

=A0=

From: Igor Bryskin [mai= lto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 11:55 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A<= /u>

=A0

Khuzema,

=A0=

Think abou= t MELG as an SRLG that is shared between two or more links in its entirety. When two real links have an SRLG in common, it means that two real links c= an co-exist concurrently, but there is something (e.g. common conduit, note= that the conduit has room for more than for one link) that will bring both= these links down, if this something fails (e.g. conduit is cut ). Now consider that this something must be tak= en in its entirety by one of the links to become operational . In this case= SRLG becomes MELG. Note that MELG is only meaningful for virtual links (un= like SRLG that makes sense for either real or virtual link). Why would you advertise two links that mutually exc= lude each other rather than advertising only one of them at a time, unless = the two are virtual links and hence both available for the client layer con= nections?

=A0=

Igor

=A0=

=A0=

From: Khuzema Pithewan [mail= to:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 1:01 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A<= /u>

=A0

Hi Igor,

=A0=

Do you mea= n, if virtual link do not have any specific constraint, for example a link in the path (not talking about egress links/interfaces) must be traversed = to realize the virtual link, there wont be any MELG for the virtual link?

=A0=

Regds

Khuzema

=A0=

From: Igor Bryskin [mai= lto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 9:52 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A<= /u>

=A0

Khuzema,

=A0=

MELGs have= nothing to do with bandwidth. MELG is a concrete network resource in a ser= ver layer that two or more Virtual Links in a client layer depend on in a mutu= ally exclusive way. An example of MELG is a WDM layer transponder that can = terminate either of respective WDM layer tunnels (but not both at the same = time) for two OTN layer Virtual Links. If you advertise a Virtual Link, say, for Ethernet layer that depen= ds on the connection in OTN layer going through one of the mentioned OTN li= nks, the Ethernet VL must inherit the MELG similarly like it does SRLGs adv= ertised for the OTN links.=

=A0=

Igor

=A0=

=A0=

From: Khuzema Pithewan [mail= to:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 12:06 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A<= /u>

=A0

Hi Igor,

=A0=

For multi-= layer (more than 2) network, consider all the layers are meshy (that=92s wh= en virtual links are useful anyway), MELGs of virtual link will change as and= when BW/wavelength availability changes, because potential paths, a virtua= l link can take will change. Mapping lower layer MELGs to higher layer MELG= s won=92t be practical if done in distributed manner, so it has to be centralized. So you do have central el= ement in each layer that knows all the risk and paths (a PCE?), which can b= e utilized for layer specific path computation (as it is doing it anyway).

=A0=

This kind = of architecture has all the pieces that are required for Inter-PCE communic= ation (across layers), except the protocol that would actually make the 2 PCEs t= alk.

=A0=

You seem t= o be doing something that you don=92t like J

=A0=

Regards

Khuzema

=A0=

From: Igor Bryskin [mai= lto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 8:39 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A<= /u>

=A0

Khuzema,

=A0=

I am not a= fan of inter-layer path computations (nor I am a fan of inter-PCE computat= ions). In my mind path computation for a service or services in layer X is perfor= med only in layer X, i.e. considers only X layer links (real or virtual). A= s Pavan mentioned SRLGs and MELGs that need to be inherited from lower laye= rs should be translated into X layer link SRLGs/MELGs and specified with X layer specific SRLG/MELG IDs.=

=A0=

Cheers,

Igor

=A0=

=A0=

From: Khuzema Pithewan [mail= to:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 10:55 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A<= /u>

=A0

Hi Igor,

=A0=

Ok. This w= ould be useful if network architecture is based on external PCE or mgmt ent= ity as PCE in client layer, but there is no counterpart in server layer, other= wise one could have inter-PCE communication to achieve diverse path in serv= er layer without getting into virtual link and MELG stuff.

=A0=

Is that co= rrect?

=A0=

Khuzema

=A0=

From: Igor Bryskin [mai= lto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 6:36 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A<= /u>

=A0

Khuzema,

=A0=

2= .=A0=A0= =A0=A0=A0=A0 For cases of concurrent co= mputation (case#2-5), you are mainly talking about global optimization and = diversity among multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done fro= m the source end of those LSPs.=A0 So there is no point in doing concurrent= computation at one network element for the services starting from multiple= network elements. At best it looks to me a problem to be solved by network management/planning software.=A0

Well, when= an ingress node is initiating a service, it is doing so on request from so= me management entity. This management entity can compute paths for many servi= ces with some global criteria in mind, and then specify the resulting paths= as explicit EROs in provisioning requests sent to each of the service ingr= esses. How else, for example, =A0you can set up several services originated from different nodes that are disjo= int from each other? Also, what is the point in your opinion of the statefu= ll PCE work?

=A0=

Cheers,

Igor

=A0=

From: Vishnu Pavan Beeram [m= ailto:vishnupavan@gmail.com]
Sent: Friday, April 12, 2013 8:08 AM
To: Khuzema Pithewan
Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A<= /u>

=A0

Khuzema, Hi!


Please see inline..

=A0

=A0

=A01.=A0=A0=A0=A0= =A0=A0 When Network has more than= 2 layer i.e. Packet-OTN-DWDM, the Packet (client) layer will be talking to= its immediate server layer i.e. OTN, which in turn is talking to DWDM layer. Using MELG, client layer path computation can take care of = resource exclusivity of virtual link for immediate server layer i.e. OTN la= yer.=A0 However if there is resource exclusivity at DWDM layer, this mechan= ism doesn=92t work. You need to do loose routing or use distributed PCE model=

=A0

[VPB] The behavior is the same = as what you would do with SRLGs in a multi-layer architecture. There are ar= chitectures that allow the SRLGs in the lowest layer to be exported all the way up to the highest layer. The expectation is tha= t MELGs would be treated in the same vein.=A0

2= .=A0=A0= =A0=A0=A0=A0 For cases of concurrent co= mputation (case#2-5), you are mainly talking about global optimization and = diversity among multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done fro= m the source end of those LSPs.=A0 So there is no point in doing concurrent= computation at one network element for the services starting from multiple= network elements. At best it looks to me a problem to be solved by network management/planning software.=A0

[VPB] =A0I'm not sure why y= ou think there is no point in having a centralized computation function com= pute paths concurrently for LSPs with different set of end-points. Even your NMS/planning-software can interact with such computation engine,= retrieve all the paths and then go about initiating the path-setup from th= e ingress of each LSP.=A0

=A0

Regards,

-Pavan

=A0

=A0

=A0=

=A0=

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Tuesday, March 26, 2013 7:19 PM
To: Dieter Beller; Vishnu Pavan Beeram


Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

=A0

Dieter,

=A0=

You said:<= /span>

>> I guess we are coming = back to the essential point: "and how often concurrent path computation will be >> used."

=A0

To be honest, this surprises me= quite a bit, Let me give you some of many reasons as to why concurrent pat= h computations are needed and why this is better than computing one path at a time:

=A0

1.=A0=A0=A0=A0=A0 Computing several diverse paths for the same service i= n the context of service recovery. I hope you realize that computing one pa= th at a time on many configurations produces no or sub-optimal results. I a= lso hope you realize the problem of selecting two paths with one of them =A0having a link with common MELG wit= h a link from another path;

2.=A0=A0=A0=A0=A0 Computing paths for multiple services to be sufficient= ly disjoint from each other;

3.=A0=A0=A0=A0=A0 Computing paths for multiple services to achieve a glo= bal optimization criteria (e.g. minimal summary total cost);<= /span>

4.=A0=A0=A0=A0=A0 Computing paths for multiple services for the purpose = of removing the bandwidth fragmentations;

5.=A0=A0=A0=A0=A0 Computing paths for multiple services to plan shared m= esh protection/restoration schemes

6.=A0=A0=A0=A0=A0 Etc.

=A0

Also think about this:

1.=A0=A0=A0=A0=A0 If concurrent path computation was not important, why = PCEP includes the machinery to do that?

2.=A0=A0=A0=A0=A0 My understanding of the statefull PCE is that it does = pretty much nothing but concurrent path computations

=A0

You also said:

= >> I suppose that if a pce approach is used, i.e., path computation i= s centralized including the
>> TE-DB, MELG routing extensions are not needed because the informat= ion about mutual
>>exclusive VLs can be kept in the central TE-DB when VLs are configu= red.

How this logic does not apply t= o other link attributes such as SRLGs?

What if path computation is not= centralized?

=A0

Cheers,

= Igor

=A0=

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A<= /u>

=A0

Hi Pavan,

On 25.03.2013 07:29, Fat= ai Zhang wrote:

Hi Pavan,<= /span>

=A0=

I am not s= ure how much VL (Virtual Link) will be used in the practical deployment and how often concurrent path computation will be used.

I guess we are coming back to t= he essential point: "= and how often concurrent path computation will be used."

This means we are trying to figure out under which conditions MELG routing = extensions
could be beneficial.

IMHO, they would only make sense, if:

  • a path computation function supports the calculation o= f k shortest paths concurrently
  • if there is only a single path computation function in= stance per domain (pce approach)
    If path computation is done in a distributed fashion the benefit goes away = because
    the instances calculate paths independently!

= I suppose that if a pce approach is used, i.e., path computation is central= ized including the
TE-DB, MELG routing extensions are not needed because the information about= mutual
exclusive VLs can be kept in the central TE-DB when VLs are configured.

Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their
applicability is broader.


Thanks,
Dieter

=A0=

Do you think if it makes sense to= add a flag (in routing advertisement) to indicate a link is a VL or not?

=A0

=A0

=A0

Best Regards

=A0

Fatai=

=A0=

From: Vishnu Pavan Beeram [m= ailto:vishnupavan@gmail.com]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A<= /u>

=A0

Fatai, Hi!=

=A0

Good to see that you understand= the construct now.

=A0

This is not a corner case. The = utility of the construct becomes quite significant if you have an applicati= on that does concurrent path computations on an abstract topology.

=A0

Regards,

-Pavan

= =A0

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

=A0

= --

ALCATEL-LUC= ENT DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 711 821 43125<= /span> begin_of_the_skype_highlighting=A0+49 711 821 43125 FREE=A0 end_of_the_skype_highlighting= begin_of_the_skype_highlighting=A0+49 711 821 43= 125 begin_of_the_skype_highlighting=A0+49 711 821 43125 FREE=A0 end_of_the_skype_highlighting FREE=A0 begin_of_the_skype_hig= hlighting=A0+49 711 821 43125 FREE=A0
Mobil: = +49 175 7266874= begin_of_the_skype_highlighting=A0+49 175 7266874 FREE=A0 e= nd_of_the_skype_highlighting b= egin_of_the_skype_highlighting=A0= +49 175 7266874= begin_of_the_skype_highlighting=A0+49 175 7266874 FREE=A0 e= nd_of_the_skype_highlighting FREE=A0 begin_of_the_skype_highlighting= =A0+49 175 7266874 FREE=A0

=A0

Alcatel-Lucent Deutschland= AG
Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe

=A0

=A0


--485b3979d9283d0d4f04dab78910-- From zhangfatai@huawei.com Fri Apr 19 18:10:24 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA09921F93EA for ; Fri, 19 Apr 2013 18:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.348 X-Spam-Level: X-Spam-Status: No, score=-5.348 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=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 RmpTHEVwoAtu for ; Fri, 19 Apr 2013 18:10:21 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4BE21F9399 for ; Fri, 19 Apr 2013 18:10:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AQQ01893; Sat, 20 Apr 2013 01:10:18 +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.7; Sat, 20 Apr 2013 02:09:58 +0100 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 20 Apr 2013 02:10:14 +0100 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.222]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Sat, 20 Apr 2013 09:10:10 +0800 From: Fatai Zhang To: Vishnu Pavan Beeram Thread-Topic: [CCAMP] MELGs - Q&A Thread-Index: AQHOIGPek8R0zdnmbUizkEjN3z7415ivh4owgAA2TQCAATLDIIAAeV3g///IfQCABM8nkIAAfXoAgAELY4CAGovgAIAAD52AgAAQMoCAAB55gIAAA70AgAAP9wCAAASVAIAACsYAgAAXnYCAA8Z+gIAAy+KAgAE80oCAADLWAIAEhDjAgAA38QCAATdTEA== Date: Sat, 20 Apr 2013 01:10:09 +0000 Message-ID: References: <5150C704.2040007@alcatel-lucent.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF843175FD1SZXEML552MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] MELGs - Q&A X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 01:10:24 -0000 --_000_F82A4B6D50F9464B8EBA55651F541CF843175FD1SZXEML552MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGF2YW4sDQoNCkluIG15IGV4bXBsZSwgSSBqdXN0IHdhbnQgdG8gc2hvdyB5b3UgdGhhdCB0 aGUgbW9yZSBnZW5lcmljIGNhc2UgZm9yIHRoZSBWVEUgbGluayAodG8gaW1wcm92ZSByZXNvdXJj ZSB1c2FnZSBlZmZpY2llbmN5KSwgd2hpY2ggZG9lcyBub3QgYXNzb2NpYXRlIGEgc3BlY2lmaWMg cG90ZW50aWFsIHBhdGggYXQgdGhlIHRpbWUgb2YgYWR2ZXJ0aXNlbWVudC4gSW4gdGhpcyBnZW5l cmljIGNhc2UsIE1FTEdzIGRvbuKAmXQgaGVscC4NCg0KUGxlYXNlIHNlZSBtb3JlIGluLWxpbmUg YmVsb3cuDQoNCg0KV2hhdCBpcyBWaXJ0dWFsIExpbms/IEFzIGRlc2NyaWJlZCBpbiBSRkM2MDAx LCBpdCBzYXlzIGFzIGJlbG93LiBTbyBteSBxdWVzdGlvbiBpczogd2hlbiB0aGVyZSBhcmUgdHdv IFZMcyBjcmVhdGVkIHRocm91Z2ggQ2FsbCBhcHByb2FjaCBhcyBkZWZpbmVkIGluIFJGQzYwMDEs IG9uZSBoYXMgMyBwb3RlbnRpYWwgcGF0aHMgaW4gdGhlIHNlcnZlciBsYXllciB0byBzZXR1cCBG QS1MU1AsIGFuZCBhbm90aGVyIGhhcyAyIHBvdGVudGlhbCBwYXRocyBpbiB0aGUgc2VydmVyIGxh eWVyLCBhbmQgb25seSBvbmUgb2YgdGhlIDMgJjIgaGFzIHRoZSBzYW1lIHJlc291cmNlIHNoYXJl ZCBpbiB0aGUgc2VydmVyIGxheWVyLg0KDQpIb3cgTUVMR3MgY2FuIGhlbHAgaW4gdGhpcyBjYXNl Pw0KDQpbVlBCXSBJIHRoaW5rIHRoZSBkaXNjb25uZWN0IGJldHdlZW4gdXMgaGFzIGdvdCB0byBk byB3aXRoIGhvdyB0aGUgVmlydHVhbCBURSAoVlRFKSBMaW5rIGdldHMgYWR2ZXJ0aXNlZC4gU2F5 LCB0aGF0IHRoZXJlIGFyZSAzIHBvdGVudGlhbCBwYXRocyBpbiB0aGUgc2VydmVyIGxheWVyIHRo YXQgY2FuIGNhdGVyIHRvIGEgZ2l2ZW4gVlRFIGxpbmsuIEluIG91ciBub3Rpb24gb2YgdGhlICJW aXJ0dWFsIFRFIExpbmsiLCBhdCB0aGUgdGltZSBvZiBhZHZlcnRpc2luZyB0aGVyZSBhbHJlYWR5 IGV4aXN0cyBhbiBhc3NvY2lhdGlvbiBiZXR3ZWVuIHRoZSBWVEUgbGluayBhbmQgb25lIG9mIHRo ZXNlIDMgcGF0aHMuIFdpdGhvdXQgYXNzb2NpYXRpbmcgeW91ciBWVEUgbGluayB3aXRoIGEgc3Bl Y2lmaWMgc2VydmVyLXBhdGgsIHlvdSB3b3VsZG4ndCBiZSBhYmxlIHRvIGFjY3VyYXRlbHkgYWR2 ZXJ0aXNlIGF0dHJpYnV0ZXMgbGlrZSBkaXZlcnNpdHksIGRlbGF5LCBtdXR1YWwtZXhjbHVzaXZp dHkgZXRjLiBJZiBJIHVuZGVyc3Rvb2QgeW91ciBxdWVzdGlvbiBjb3JyZWN0bHksIHlvdXIgbm90 aW9uIG9mIGhvdyB0aGUgVmlydHVhbCBURSBMaW5rIGdldHMgYWR2ZXJ0aXNlZCBzZWVtcyB0byBi ZSBkaWZmZXJlbnQgLSB5b3UgZG9uJ3QgYXNzb2NpYXRlIHRoZSBWVEUgbGluayB0byBhIHNwZWNp ZmljIHBvdGVudGlhbCBwYXRoIGF0IHRoZSB0aW1lIG9mIGFkdmVydGlzZW1lbnQuDQoNCltGYXRh aV0gUmlnaHQuIFRoZSBWVEUgbGluayBkb2VzIG5vdCBhc3NvY2lhdGUgYSBzcGVjaWZpYyBwb3Rl bnRpYWwgcGF0aCBhdCB0aGUgdGltZSBvZiBhZHZlcnRpc2VtZW50LCBpdCBpcyBhIGtpbmQgb2Yg cG90ZW50aWFsaXR5IGZvciB0aGUgVlRFIGFkdmVydGlzZWQgYXMgZGVmaW5lZCBpbiBSRkM2MDAx LiBJbiB0aGlzIGNhc2UsIHBhdGggY29tcHV0YXRpb24gZWxlbWVudCAoZS5nLCBjZW50cmFsaXpl ZCBQQ0UgZm9yIGludGVyLWxheWVyKSBjYW4gYmUgYXdhcmUgb2YgdGhlIGxpbmsgaW5mb3JtYXRp b24sIGluY2x1ZGluZyBsaW5rIGJhbmR3aWR0aCwgU1JMR+KApi4uDQoNCg0KQ29udGludWluZyB3 aXRoIHlvdXIgZXhhbXBsZSAtIElmIHRoZSBwYXRoIHRoYXQgZ2V0cyBhc3NvY2lhdGVkIHdpdGgg VlRFLUxpbmstMSBhbmQgdGhlIHBhdGggdGhhdCBnZXRzIGFzc29jaWF0ZWQgd2l0aCBWVEUtTGlu ay0yIGRlcGVuZCBvbiB0aGUgc2FtZSByZXNvdXJjZSwgIk1FTEdzIiB3b3VsZCBtYWtlIHN1cmUg dGhhdCB0aGUgY2xpZW50IGNvbXB1dGF0aW9uIGZ1bmN0aW9uIGlzIGF3YXJlIG9mIHRoZSBleGlz dGVuY2Ugb2Ygc3VjaCAibXV0dWFsIGV4Y2x1c2l2aXR5IiByZWxhdGlvbnNoaXAuDQoNCltGYXRh aV0gVGhlIHBhdGggY29tcHV0YXRpb24gZWxlbWVudCAoY2VudHJhbGl6ZWQgUENFIGZvciBpbnRl ci1sYXllciBvciBtdWx0aXBsZSBQQ0VzIHRocm91Z2ggY29tbXVuaWNhdGlvbikgY2FuIHRha2Ug Y2FyZSBvZiB0aGlzIGlzc3VlIHRvIGF2b2lkIHRoaXMgaGFwcGVuIHdpdGhvdXQgTUVMRyBpbnRy b2R1Y2VkLg0KDQpCUiwNCi1QYXZhbg0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQ0KQSB2aXJ0dWFsIFRFIGxpbmsgaXMgZGVmaW5lZCBhcyBh IFRFIGxpbmsgYmV0d2VlbiB0d28gdXBwZXItbGF5ZXIgbm9kZXMgdGhhdCBpcyBub3QgYXNzb2Np YXRlZCB3aXRoIGEgZnVsbHkgcHJvdmlzaW9uZWQgRkEtTFNQIGluIGEgbG93ZXIgbGF5ZXIgW1JG QzUyMTI8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTIxMj5dLiAgQSB2aXJ0dWFsIFRF IGxpbmsgaXMgYWR2ZXJ0aXNlZCBhcyBhbnkgVEUgbGluaywgZm9sbG93aW5nIHRoZSBydWxlcyBp biBbUkZDNDIwNjxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0MjA2Pl0gZGVmaW5lZCBm b3IgZnVsbHkgcHJvdmlzaW9uZWQgVEUgbGlua3MuICBBIHZpcnR1YWwgVEUgbGluayByZXByZXNl bnRzIHRodXMgdGhlIHBvdGVudGlhbGl0eSB0byBzZXQgdXAgYW4gRkEtTFNQIGluIHRoZSBsb3dl ciBsYXllciB0byBzdXBwb3J0IHRoZSBURSBsaW5rIHRoYXQgaGFzIGJlZW4gYWR2ZXJ0aXNlZC4N Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQpC ZXN0IFJlZ2FyZHMNCg0KRmF0YWkNCg0KRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZzxtYWls dG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFZpc2hudSBQYXZh biBCZWVyYW0NClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDE2LCAyMDEzIDEwOjEwIFBNDQpUbzogS2h1 emVtYSBQaXRoZXdhbg0KDQpDYzogY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFtDQ0FNUF0gTUVMR3MgLSBRJkENCg0KS2h1emVtYSwgSGkhDQoNCk1F TEdzIGFyZSB1c2VmdWwgYW5kIGNvbWUgaW50byBwbGF5IG9ubHkgd2hlbjoNCigxKSBUaGUgc2Vy dmVyIG5ldHdvcmsgZG9tYWluIGlzIGFic3RyYWN0ZWQgYW5kIHRoZSBhZHZlcnRpc2VkIFZpcnR1 YWwgVEUtbGlua3MgcG9zc2VzcyBzb21lIG11dHVhbCBleGNsdXNpdml0eSByZWxhdGlvbnNoaXAu DQooMikgVGhlcmUgaXMgYSBDZW50cmFsaXplZCBwYXRoIGNvbXB1dGF0aW9uIGVudGl0eSBpbiB0 aGUgY2xpZW50IGRvbWFpbiAoY29tcHV0ZXMgcGF0aHMgaW4gdGVybXMgb2YgQ2xpZW50IFRFLWxp bmtzL1RFLW5vZGVzKSB0aGF0IGlzIGNhcGFibGUgb2YgZG9pbmcgY29uY3VycmVudCBwYXRoIGNv bXB1dGF0aW9ucy4NCg0KSWYgZWl0aGVyIG9mIHRoZSBhYm92ZSAyIHN0YXRlbWVudHMgaXMgTk9U IHRydWUsIHRoZXJlIGlzIG5vIHV0aWxpdHkgZm9yIE1FTEdzLg0KQXQgdGhlIHJpc2sgb2YgYmVp bmcgcGVkYW50aWM6DQotIEFyZSBNRUxHcyBuZWVkZWQgd2hlbiB0aGUgc2VydmVyLW5ldHdvcmsg ZG9tYWluIGluIG5vdCBhYnN0cmFjdGVkIChubyBWaXJ0dWFsIFRFIGxpbmtzKT8gVGhlIGFuc3dl ciBpcyBOTy4NCi0gQXJlIE1FTEdzIG5lZWRlZCB3aGVuIHlvdSBoYXZlIGEgZGlzdHJpYnV0ZWQg cGF0aC1jb21wdXRhdGlvbiBhcmNoaXRlY3R1cmUgKENsaWVudCBQQ0UgaW50ZXJhY3Rpbmcgd2l0 aCBTZXJ2ZXIgUENFKT8gVGhlIGFuc3dlciBpcyBOTy4NCi0gQXJlIE1FTEdzIG5lZWRlZCB3aGVu IHRoZSBjZW50cmFsaXplZCBwYXRoLWNvbXB1dGF0aW9uIGVuZ2luZSBkb2Vzbid0IChjYW4ndCkg ZG8gY29uY3VycmVudCBjb21wdXRhdGlvbnM/IFRoZSBhbnN3ZXIgaXMgTk8uDQoNClRoZSBhY3R1 YWwgcHJvY2VkdXJlcyBpbnZvbHZlZCBpbiBhYnN0cmFjdGluZyB0aGUgc2VydmVyIG5ldHdvcmsg ZG9tYWluIGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgPGRyYWZ0LW1lbGdzPi4gVGhlIGFic3RyYWN0 aW9uIHByb2NlZHVyZSBpdHNlbGYgaXMgaW1wbGVtZW50YXRpb24tc3BlY2lmaWMgKG1heWJlIHNv bWVkYXkgc29tZW9uZSB3b3VsZCBwdXQgdG9nZXRoZXIgYSBkcmFmdCBmb3IgZGlzY3Vzc2luZyB0 aGlzKS4gVGhvdWdoIGl0IGlzIHRydWUgdGhhdCB0aGUgcHJpbWFyeSB1c2UtY2FzZSB3ZSBoYWQg aW4gbWluZCB3aGVuIGNvbWluZyB1cCB3aXRoIHRoaXMgbmV3IGNvbnN0cnVjdCBpbnZvbHZlcyBh IGxhbWJkYS1sYXllciBzZXJ2ZXIgbmV0d29yayBkb21haW4sIHRoZXJlIGlzIHJlYWxseSBubyBy ZXN0cmljdGlvbiAoYXQgYSBjb25jZXB0dWFsIGxldmVsKSBvbiB1c2luZyB0aGlzIGNvbnN0cnVj dCB3aGVuIGFic3RyYWN0aW5nIGEgcGFja2V0LWxheWVyIHNlcnZlciBuZXR3b3JrIGRvbWFpbiBv ciBhIFRETS1sYXllciBzZXJ2ZXIgbmV0d29yayBkb21haW4uIEl0IGlzIHVwIHRvIHRoZSBpbXBs ZW1lbnRhdGlvbiBvbiBob3cgdG8gbWFrZSBiZXN0IHVzZSBvZiB0aGlzIGNvbnN0cnVjdC4NCg0K V2hlbiB5b3UgYWR2ZXJ0aXNlIGEgVmlydHVhbCBURS1saW5rIGludG8gYSBjbGllbnQgbmV0d29y ayBkb21haW4sIHlvdSBhcmUgZG9pbmcgdGhpcyBiYXNlZCBvbiB0aGUgZXhpc3RlbmNlIG9mIHNv bWUgcG90ZW50aWFsIHVuZGVybHlpbmcgc2VydmVyLXBhdGguIFRFIGF0dHJpYnV0ZXMgbGlrZSBT UkxHcywgTUVMR3MsIGRlbGF5IGV0YyB0aGF0IGdldCBhZHZlcnRpc2VkIGZvciB0aGUgVmlydHVh bCBURS1saW5rIGRlcGVuZCBvbiB0aGUgdW5kZXJseWluZyBzZXJ2ZXItcGF0aCB0aGF0IGlzIGNo b3NlbiBmb3IgY2F0ZXJpbmcgdG8gdGhpcyBDbGllbnQgVEUtbGluay4gSWYgdGhlIHVuZGVybHlp bmcgc2VydmVyLXBhdGgga2VlcHMgY2hhbmdpbmcgKGJhc2VkIG9uIG5ldHdvcmsgZXZlbnRzKSwg dGhlc2UgVEUgYXR0cmlidXRlcyB3b3VsZCBhbHNvIGtlZXAgY2hhbmdpbmcuIFRoZSBwcm9jZWR1 cmUgZm9yIGtlZXBpbmcgdGhlIGFkdmVydGlzZWQgaW5mb3JtYXRpb24gImN1cnJlbnQiIGlzIGFu IGltcGxlbWVudGF0aW9uIGNob2ljZS4NCg0KSWYgdGhlcmUgZXhpc3RzIHN1Y2ggYSB0aGluZyBh cyBhbiBhYnN0cmFjdGlvbiBtYW5hZ2VyIChhZ2FpbiwgdGhpcyBpcyB0b3RhbGx5IGltcGxlbWVu dGF0aW9uIHNwZWNpZmljKSwgdGhlbiB0aGUgYXNzdW1wdGlvbiBpcyB0aGF0IGl0IGRvZXMgb25l IG9mIHRoZSBmb2xsb3dpbmcgLQ0KKGEpIGNvbXB1dGVzIG5ldyBzZXJ2ZXItcGF0aHMgZm9yIHRo ZSBWaXJ0dWFsIFRFIGxpbmtzIHdoZW5ldmVyIHRoZXJlIGlzIGEgY2hhbmdlIGluIHRoZSBuZXR3 b3JrIChtYXkgbm90IGJlIHZlcnkgc2NhbGFibGUgaW4gc29tZSBhcmNoaXRlY3R1cmVzKSwNCihi KSBvciBkb2VzIHBlcmlvZGljIHBhdGgtY29tcHV0YXRpb24gZm9yIGVhY2ggVmlydHVhbCBURSBs aW5rLA0KKGMpIG9yIHVzZXMgYSBwb2xpY3kgdG8gcGluIGRvd24gdGhlIFZpcnR1YWwgVEUtbGlu ayB0byBhIHNwZWNpZmljIHVuZGVybHlpbmcgc2VydmVyLXBhdGgsDQooZCkgb3IgdXNlcyBhIGNv bWJpbmF0aW9uIG9mIChhKSwgKGIpLCAoYykuDQoNCjxkcmFmdC1tZWxncz4gZG9lc24ndCBtYWtl IGFueSByZWNvbW1lbmRhdGlvbiBhcyB0byB3aGF0IGNob2ljZSB0aGUgYWJzdHJhY3Rpb24gbWFu YWdlciB3b3VsZCBuZWVkIHRvIHRha2UuDQoNCkhvcGUgdGhpcyBoZWxwcy4NCi1QYXZhbg0KDQpP biBUdWUsIEFwciAxNiwgMjAxMyBhdCA3OjA4IEFNLCBLaHV6ZW1hIFBpdGhld2FuIDxrcGl0aGV3 YW5AaW5maW5lcmEuY29tPG1haWx0bzprcGl0aGV3YW5AaW5maW5lcmEuY29tPj4gd3JvdGU6DQpI aSBJZ29yLA0KDQpJIGFtIHRyeWluZyB0byBzdW1tYXJpemUgdGhlIGRpc2N1c3Npb24gd2UgaGFk IHNvIGZhci4gUGxzIHNlZSBpZiBteSBjb25jbHVzaW9uIGlzIGluIHN5bmMgd2l0aCB0aGUgaWRl YSBvZiBNRUxHIHlvdSBoYXZlDQoNCk1FTEcgaXMgdXNlZnVsIHdoZW4NCg0KMS4gICAgICAgc2Vy dmVyIGxheWVyIFZMcyBhcmUgbmFpbGVkIGRvd24gZm9yIHRoZSByZXNvdXJjZXMgb24gdGhlIHNl cnZlciBsYXllciBsaW5rcyB0aGF0IGFyZSBzaGFyZWQgYW1vbmcgbXVsdGlwbGUgVkxzLiBUaGVz ZSByZXNvdXJjZXMgYXJlIHR5cGljYWxseSB3YXZlbGVuZ3RoIG9uIGEgZmliZXIgKGNhbiBpdCBi ZSBhbnl0aGluZyBlbHNlPz8pLiBJbiBvdGhlciB3b3JkcywgaWYgMiBWTHMgYXJlIHBpbm5lZCB0 byB1c2UgYSBwYXJ0aWN1bGFyIHdhdmVsZW5ndGggb24gYSBwYXJ0aWN1bGFyIGZpYmVyLCB0aGVu IHRoZXNlIDIgVkxzIHdpbGwgaGF2ZSBNRUxHIGZvciB0aGUgd2F2ZWxlbmd0aC4NCg0KMi4gICAg ICAgc2VydmVyIGxheWVyIGRvIG5vdCBoYXZlIGNlbnRyYWxpemVkIHBhdGggY29tcHV0YXRpb24g ZW50aXR5IHdoaWNoIGNhbiBiZSB1c2VkIGJ5IGNsaWVudCBsYXllciB0byBhc2sgZm9yIGNvbmN1 cnJlbnQgZGl2ZXJzZSBwYXRoIGNvbXB1dGF0aW9uIHdpdGhpbiBzZXJ2ZXIgbGF5ZXIuDQoNCjMu ICAgICAgIENsaWVudCBsYXllciBoYXMgYSBjZW50cmFsaXplZCBwYXRoIGNvbXB1dGF0aW9uIGVu dGl0eSwgd2hpY2ggd291bGQgY29tcHV0ZSBwYXRocyBmb3IgY2xpZW50K3NlcnZlciBsYXllci4N Cg0KNC4gICAgICAgVGhlIG5lZWQgaXMgdG8gY2VudHJhbGl6ZWQgY29uY3VycmVudCBjb21wdXRh dGlvbiBvZiBtb3JlIHRoYW4gb25lIGNsaWVudCtzZXJ2ZXIgbGF5ZXIgcGF0aCB0aGF0IG1lZXRz IHNvbWUgZGl2ZXJzaXR5IGFuZCByZXNvdXJjZSBleGNsdXNpdml0eSByZXF1aXJlbWVudHMuDQoN ClJlZ2RzDQpLaHV6ZW1hDQoNCkZyb206IElnb3IgQnJ5c2tpbiBbbWFpbHRvOklCcnlza2luQGFk dmFvcHRpY2FsLmNvbTxtYWlsdG86SUJyeXNraW5AYWR2YW9wdGljYWwuY29tPl0NClNlbnQ6IE1v bmRheSwgQXByaWwgMTUsIDIwMTMgOTo0NCBQTQ0KDQpUbzogS2h1emVtYSBQaXRoZXdhbjsgVmlz aG51IFBhdmFuIEJlZXJhbQ0KQ2M6IERpZXRlciBCZWxsZXI7IGNjYW1wQGlldGYub3JnPG1haWx0 bzpjY2FtcEBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbQ0NBTVBdIE1FTEdzIC0gUSZBDQoNCkto dXplbWEsDQpQbGVhc2UsIHNlZSBpbi1saW5lLg0KDQpJZ29yDQoNCkZyb206IEtodXplbWEgUGl0 aGV3YW4gW21haWx0bzprcGl0aGV3YW5AaW5maW5lcmEuY29tPG1haWx0bzprcGl0aGV3YW5AaW5m aW5lcmEuY29tPl0NClNlbnQ6IE1vbmRheSwgQXByaWwgMTUsIDIwMTMgMTI6MDUgQU0NClRvOiBJ Z29yIEJyeXNraW47IFZpc2hudSBQYXZhbiBCZWVyYW0NCkNjOiBEaWV0ZXIgQmVsbGVyOyBjY2Ft cEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW0NDQU1QXSBN RUxHcyAtIFEmQQ0KDQpIaSBJZ29yLA0KDQpJIHVuZGVyc3RhbmQgdGhlIFNSTEcgYW5kIE1FTEcg YmVoYXZpb3IgeW91IGhhdmUgcGVubmVkIC4NCg0KTXkgY29uY2VybiB3YXMgbGl0dGxlIGRpZmZl cmVudC4gIFdpdGggY2hhbmdpbmcgcmVzb3VyY2UgY29uc3VtcHRpb24gKGJlY2F1c2Ugb2YgZHlu YW1pY2l0eSB0aGUgbmV0d29yayBoYXMpIGluIHRoZSBuZXR3b3JrIGxpbmtzLCBwb3RlbnRpYWwg cGF0aHMgYSBzZXQgb2YgdmlydHVhbCBsaW5rIGNhbiB0YWtlIHdpbGwgY2hhbmdlIGFuZCBoZW5j ZSBpdHMgTUVMRywgYXMgaXQgaXMgdGllZCB0byBhIHJlc291cmNlIGl0IGNhbiB0YWtlLiBTbyB1 bmxlc3MgdmlydHVhbCBsaW5rcyBwYXRocyBhcmUgbmFpbGVkIGRvd24sIGl0IHdvdWxkIGJlIGhh cmQgdG8gY29tcHV0ZSBNRUxHcyBpbiBkaXN0cmlidXRlZCB3YXkuDQoNCklCPj4gSSB0aGluayB5 b3UgYXJlIG1pc3NpbmcgdGhlIHBvaW50IGhlcmUuIFZpcnR1YWwgTGluayBzZXJ2ZXIgbGF5ZXIg cGF0aHMgYXJlIHBpbm5lZCBhcyBmYXIgYXMgZmF0ZSBzaGFyaW5nIGlzIGNvbmNlcm5lZCAodGhh dCBpcywgdGhleSBhcmUgcGlubmVkIG9uICBzZXJ2ZXIgbGF5ZXIgbGluayBsZXZlbCkuIEl0IHdv dWxkIG1ha2UgbGl0dGxlIHNlbnNlIHRvIGFkdmVydGlzZSBWTCBTUkxHcyBpZiB0aGUgU1JMR3Mg Y29uc3RhbnRseSBjaGFuZ2UuIFRoZSBzYW1lIGlzIHRydWUgZm9yIE1FTEdzLiAgU1JMR3MvTUVM R3MgYWR2ZXJ0aXNlZCBmb3IgVkxzIG5vcm1hbGx5IGRvIG5vdCBjaGFuZ2U6IG5laXRoZXIgb3Zl ciB0aW1lIG5vciB3aGVuIFZMcyBiZWNvbWUgY29tbWl0dGVkL3VuY29tbWl0dGVkLg0KDQpBbm90 aGVyIHBvaW50IGlzLCB2aXJ0dWFsIGxpbmtzIGNhbiBiZSB2aWV3ZWQgYXMgb3ZlcnN1YnNjcmlw dGlvbiBvZiByZXNvdXJjZXMgKGluIE1FTEcgY29udGV4dCkuIFRha2luZyBhbiBleGFtcGxlIChm b3IgT1ROLCBJIGtub3cgaXQgd291bGQgd29yayBkaWZmZXJlbnRseSBmb3IgYSBXYXZlbGVuZ3Ro IGluIFdETSksIGEgbGluayByZXNvdXJjZXMgYXJlIHdvcnRoIDEgVEIgb2YgQlcsIHVzZXIgaGFz IHByb3Zpc2lvbmVkIDIwIHZpcnR1YWwgbGlua3Mgb2YgMTAwRyBlYWNoIGdvaW5nIHZpYSB0aGF0 IE9UTiBsaW5rLiAgUGh5c2ljYWxseSwgb25seSAxMCB3aWxsIGdldCBjb21taXR0ZWQuIEJ1dCB3 aGljaCAxMD8gSXQgd2lsbCByZWFsbHkgZGVwZW5kIG9uIG5ldHdvcmsgZHluYW1pY3MgYXQgdGhl IHRpbWUgb2YgZGVtYW5kIHRvIGNvbW1pdC4gTUVMR3MgYXJlIG5vdCB0aGF0IGVmZmVjdGl2ZSBo ZXJlLiBZb3UgbmVlZCBzb21lIGRpZmZlcmVudCBtZWNoYW5pc20uDQoNCklCPj4gQXMgSSBtZW50 aW9uZWQgYmVmb3JlIE1FTEdzIGhhdmUgbm90aGluZyB0byBkbyB3aXRoIGJhbmR3aWR0aCBhbmQg d2VyZSBuZXZlciBpbnRlbmRlZCB0byBzb2x2ZSB0aGUgcHJvYmxlbXMgc3VjaCBhcyB5b3UgZGVz Y3JpYmUgKGp1c3QgbGlrZSBpdCB3b3VsZCBub3QgbWFrZSBtdWNoIHNlbnNlIHRvIHNvbHZlIHN1 Y2ggcHJvYmxlbSB3aXRoIFNSTEdzIDo9KQ0KQWdhaW4sICBNRUxHIGlzIGFuIGV4dHJlbWUgY2Fz ZSBTUkxHIGRlc2lnbmVkIGV4Y2x1c2l2ZWx5IGZvciBWTHMgKG5vIG1vcmUgYW5kIG5vIGxlc3Mp Lg0KDQpSZWdkcw0KS2h1emVtYQ0KDQoNCkZyb206IElnb3IgQnJ5c2tpbiBbbWFpbHRvOklCcnlz a2luQGFkdmFvcHRpY2FsLmNvbV0NClNlbnQ6IEZyaWRheSwgQXByaWwgMTIsIDIwMTMgMTE6NTUg UE0NClRvOiBLaHV6ZW1hIFBpdGhld2FuOyBWaXNobnUgUGF2YW4gQmVlcmFtDQpDYzogRGlldGVy IEJlbGxlcjsgY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPg0KU3ViamVjdDog UkU6IFtDQ0FNUF0gTUVMR3MgLSBRJkENCg0KS2h1emVtYSwNCg0KVGhpbmsgYWJvdXQgTUVMRyBh cyBhbiBTUkxHIHRoYXQgaXMgc2hhcmVkIGJldHdlZW4gdHdvIG9yIG1vcmUgbGlua3MgaW4gaXRz IGVudGlyZXR5LiBXaGVuIHR3byByZWFsIGxpbmtzIGhhdmUgYW4gU1JMRyBpbiBjb21tb24sIGl0 IG1lYW5zIHRoYXQgdHdvIHJlYWwgbGlua3MgY2FuIGNvLWV4aXN0IGNvbmN1cnJlbnRseSwgYnV0 IHRoZXJlIGlzIHNvbWV0aGluZyAoZS5nLiBjb21tb24gY29uZHVpdCwgbm90ZSB0aGF0IHRoZSBj b25kdWl0IGhhcyByb29tIGZvciBtb3JlIHRoYW4gZm9yIG9uZSBsaW5rKSB0aGF0IHdpbGwgYnJp bmcgYm90aCB0aGVzZSBsaW5rcyBkb3duLCBpZiB0aGlzIHNvbWV0aGluZyBmYWlscyAoZS5nLiBj b25kdWl0IGlzIGN1dCApLiBOb3cgY29uc2lkZXIgdGhhdCB0aGlzIHNvbWV0aGluZyBtdXN0IGJl IHRha2VuIGluIGl0cyBlbnRpcmV0eSBieSBvbmUgb2YgdGhlIGxpbmtzIHRvIGJlY29tZSBvcGVy YXRpb25hbCAuIEluIHRoaXMgY2FzZSBTUkxHIGJlY29tZXMgTUVMRy4gTm90ZSB0aGF0IE1FTEcg aXMgb25seSBtZWFuaW5nZnVsIGZvciB2aXJ0dWFsIGxpbmtzICh1bmxpa2UgU1JMRyB0aGF0IG1h a2VzIHNlbnNlIGZvciBlaXRoZXIgcmVhbCBvciB2aXJ0dWFsIGxpbmspLiBXaHkgd291bGQgeW91 IGFkdmVydGlzZSB0d28gbGlua3MgdGhhdCBtdXR1YWxseSBleGNsdWRlIGVhY2ggb3RoZXIgcmF0 aGVyIHRoYW4gYWR2ZXJ0aXNpbmcgb25seSBvbmUgb2YgdGhlbSBhdCBhIHRpbWUsIHVubGVzcyB0 aGUgdHdvIGFyZSB2aXJ0dWFsIGxpbmtzIGFuZCBoZW5jZSBib3RoIGF2YWlsYWJsZSBmb3IgdGhl IGNsaWVudCBsYXllciBjb25uZWN0aW9ucz8NCg0KSWdvcg0KDQoNCkZyb206IEtodXplbWEgUGl0 aGV3YW4gW21haWx0bzprcGl0aGV3YW5AaW5maW5lcmEuY29tXQ0KU2VudDogRnJpZGF5LCBBcHJp bCAxMiwgMjAxMyAxOjAxIFBNDQpUbzogSWdvciBCcnlza2luOyBWaXNobnUgUGF2YW4gQmVlcmFt DQpDYzogRGlldGVyIEJlbGxlcjsgY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3Jn Pg0KU3ViamVjdDogUkU6IFtDQ0FNUF0gTUVMR3MgLSBRJkENCg0KSGkgSWdvciwNCg0KRG8geW91 IG1lYW4sIGlmIHZpcnR1YWwgbGluayBkbyBub3QgaGF2ZSBhbnkgc3BlY2lmaWMgY29uc3RyYWlu dCwgZm9yIGV4YW1wbGUgYSBsaW5rIGluIHRoZSBwYXRoIChub3QgdGFsa2luZyBhYm91dCBlZ3Jl c3MgbGlua3MvaW50ZXJmYWNlcykgbXVzdCBiZSB0cmF2ZXJzZWQgdG8gcmVhbGl6ZSB0aGUgdmly dHVhbCBsaW5rLCB0aGVyZSB3b250IGJlIGFueSBNRUxHIGZvciB0aGUgdmlydHVhbCBsaW5rPw0K DQpSZWdkcw0KS2h1emVtYQ0KDQpGcm9tOiBJZ29yIEJyeXNraW4gW21haWx0bzpJQnJ5c2tpbkBh ZHZhb3B0aWNhbC5jb21dDQpTZW50OiBGcmlkYXksIEFwcmlsIDEyLCAyMDEzIDk6NTIgUE0NClRv OiBLaHV6ZW1hIFBpdGhld2FuOyBWaXNobnUgUGF2YW4gQmVlcmFtDQpDYzogRGlldGVyIEJlbGxl cjsgY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtD Q0FNUF0gTUVMR3MgLSBRJkENCg0KS2h1emVtYSwNCg0KTUVMR3MgaGF2ZSBub3RoaW5nIHRvIGRv IHdpdGggYmFuZHdpZHRoLiBNRUxHIGlzIGEgY29uY3JldGUgbmV0d29yayByZXNvdXJjZSBpbiBh IHNlcnZlciBsYXllciB0aGF0IHR3byBvciBtb3JlIFZpcnR1YWwgTGlua3MgaW4gYSBjbGllbnQg bGF5ZXIgZGVwZW5kIG9uIGluIGEgbXV0dWFsbHkgZXhjbHVzaXZlIHdheS4gQW4gZXhhbXBsZSBv ZiBNRUxHIGlzIGEgV0RNIGxheWVyIHRyYW5zcG9uZGVyIHRoYXQgY2FuIHRlcm1pbmF0ZSBlaXRo ZXIgb2YgcmVzcGVjdGl2ZSBXRE0gbGF5ZXIgdHVubmVscyAoYnV0IG5vdCBib3RoIGF0IHRoZSBz YW1lIHRpbWUpIGZvciB0d28gT1ROIGxheWVyIFZpcnR1YWwgTGlua3MuIElmIHlvdSBhZHZlcnRp c2UgYSBWaXJ0dWFsIExpbmssIHNheSwgZm9yIEV0aGVybmV0IGxheWVyIHRoYXQgZGVwZW5kcyBv biB0aGUgY29ubmVjdGlvbiBpbiBPVE4gbGF5ZXIgZ29pbmcgdGhyb3VnaCBvbmUgb2YgdGhlIG1l bnRpb25lZCBPVE4gbGlua3MsIHRoZSBFdGhlcm5ldCBWTCBtdXN0IGluaGVyaXQgdGhlIE1FTEcg c2ltaWxhcmx5IGxpa2UgaXQgZG9lcyBTUkxHcyBhZHZlcnRpc2VkIGZvciB0aGUgT1ROIGxpbmtz Lg0KDQpJZ29yDQoNCg0KRnJvbTogS2h1emVtYSBQaXRoZXdhbiBbbWFpbHRvOmtwaXRoZXdhbkBp bmZpbmVyYS5jb21dDQpTZW50OiBGcmlkYXksIEFwcmlsIDEyLCAyMDEzIDEyOjA2IFBNDQpUbzog SWdvciBCcnlza2luOyBWaXNobnUgUGF2YW4gQmVlcmFtDQpDYzogRGlldGVyIEJlbGxlcjsgY2Nh bXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtDQ0FNUF0g TUVMR3MgLSBRJkENCg0KSGkgSWdvciwNCg0KRm9yIG11bHRpLWxheWVyIChtb3JlIHRoYW4gMikg bmV0d29yaywgY29uc2lkZXIgYWxsIHRoZSBsYXllcnMgYXJlIG1lc2h5ICh0aGF04oCZcyB3aGVu IHZpcnR1YWwgbGlua3MgYXJlIHVzZWZ1bCBhbnl3YXkpLCBNRUxHcyBvZiB2aXJ0dWFsIGxpbmsg d2lsbCBjaGFuZ2UgYXMgYW5kIHdoZW4gQlcvd2F2ZWxlbmd0aCBhdmFpbGFiaWxpdHkgY2hhbmdl cywgYmVjYXVzZSBwb3RlbnRpYWwgcGF0aHMsIGEgdmlydHVhbCBsaW5rIGNhbiB0YWtlIHdpbGwg Y2hhbmdlLiBNYXBwaW5nIGxvd2VyIGxheWVyIE1FTEdzIHRvIGhpZ2hlciBsYXllciBNRUxHcyB3 b27igJl0IGJlIHByYWN0aWNhbCBpZiBkb25lIGluIGRpc3RyaWJ1dGVkIG1hbm5lciwgc28gaXQg aGFzIHRvIGJlIGNlbnRyYWxpemVkLiBTbyB5b3UgZG8gaGF2ZSBjZW50cmFsIGVsZW1lbnQgaW4g ZWFjaCBsYXllciB0aGF0IGtub3dzIGFsbCB0aGUgcmlzayBhbmQgcGF0aHMgKGEgUENFPyksIHdo aWNoIGNhbiBiZSB1dGlsaXplZCBmb3IgbGF5ZXIgc3BlY2lmaWMgcGF0aCBjb21wdXRhdGlvbiAo YXMgaXQgaXMgZG9pbmcgaXQgYW55d2F5KS4NCg0KVGhpcyBraW5kIG9mIGFyY2hpdGVjdHVyZSBo YXMgYWxsIHRoZSBwaWVjZXMgdGhhdCBhcmUgcmVxdWlyZWQgZm9yIEludGVyLVBDRSBjb21tdW5p Y2F0aW9uIChhY3Jvc3MgbGF5ZXJzKSwgZXhjZXB0IHRoZSBwcm90b2NvbCB0aGF0IHdvdWxkIGFj dHVhbGx5IG1ha2UgdGhlIDIgUENFcyB0YWxrLg0KDQpZb3Ugc2VlbSB0byBiZSBkb2luZyBzb21l dGhpbmcgdGhhdCB5b3UgZG9u4oCZdCBsaWtlIOKYug0KDQpSZWdhcmRzDQpLaHV6ZW1hDQoNCkZy b206IElnb3IgQnJ5c2tpbiBbbWFpbHRvOklCcnlza2luQGFkdmFvcHRpY2FsLmNvbV0NClNlbnQ6 IEZyaWRheSwgQXByaWwgMTIsIDIwMTMgODozOSBQTQ0KVG86IEtodXplbWEgUGl0aGV3YW47IFZp c2hudSBQYXZhbiBCZWVyYW0NCkNjOiBEaWV0ZXIgQmVsbGVyOyBjY2FtcEBpZXRmLm9yZzxtYWls dG86Y2NhbXBAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW0NDQU1QXSBNRUxHcyAtIFEmQQ0KDQpL aHV6ZW1hLA0KDQpJIGFtIG5vdCBhIGZhbiBvZiBpbnRlci1sYXllciBwYXRoIGNvbXB1dGF0aW9u cyAobm9yIEkgYW0gYSBmYW4gb2YgaW50ZXItUENFIGNvbXB1dGF0aW9ucykuIEluIG15IG1pbmQg cGF0aCBjb21wdXRhdGlvbiBmb3IgYSBzZXJ2aWNlIG9yIHNlcnZpY2VzIGluIGxheWVyIFggaXMg cGVyZm9ybWVkIG9ubHkgaW4gbGF5ZXIgWCwgaS5lLiBjb25zaWRlcnMgb25seSBYIGxheWVyIGxp bmtzIChyZWFsIG9yIHZpcnR1YWwpLiBBcyBQYXZhbiBtZW50aW9uZWQgU1JMR3MgYW5kIE1FTEdz IHRoYXQgbmVlZCB0byBiZSBpbmhlcml0ZWQgZnJvbSBsb3dlciBsYXllcnMgc2hvdWxkIGJlIHRy YW5zbGF0ZWQgaW50byBYIGxheWVyIGxpbmsgU1JMR3MvTUVMR3MgYW5kIHNwZWNpZmllZCB3aXRo IFggbGF5ZXIgc3BlY2lmaWMgU1JMRy9NRUxHIElEcy4NCg0KQ2hlZXJzLA0KSWdvcg0KDQoNCkZy b206IEtodXplbWEgUGl0aGV3YW4gW21haWx0bzprcGl0aGV3YW5AaW5maW5lcmEuY29tXQ0KU2Vu dDogRnJpZGF5LCBBcHJpbCAxMiwgMjAxMyAxMDo1NSBBTQ0KVG86IElnb3IgQnJ5c2tpbjsgVmlz aG51IFBhdmFuIEJlZXJhbQ0KQ2M6IERpZXRlciBCZWxsZXI7IGNjYW1wQGlldGYub3JnPG1haWx0 bzpjY2FtcEBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbQ0NBTVBdIE1FTEdzIC0gUSZBDQoNCkhp IElnb3IsDQoNCk9rLiBUaGlzIHdvdWxkIGJlIHVzZWZ1bCBpZiBuZXR3b3JrIGFyY2hpdGVjdHVy ZSBpcyBiYXNlZCBvbiBleHRlcm5hbCBQQ0Ugb3IgbWdtdCBlbnRpdHkgYXMgUENFIGluIGNsaWVu dCBsYXllciwgYnV0IHRoZXJlIGlzIG5vIGNvdW50ZXJwYXJ0IGluIHNlcnZlciBsYXllciwgb3Ro ZXJ3aXNlIG9uZSBjb3VsZCBoYXZlIGludGVyLVBDRSBjb21tdW5pY2F0aW9uIHRvIGFjaGlldmUg ZGl2ZXJzZSBwYXRoIGluIHNlcnZlciBsYXllciB3aXRob3V0IGdldHRpbmcgaW50byB2aXJ0dWFs IGxpbmsgYW5kIE1FTEcgc3R1ZmYuDQoNCklzIHRoYXQgY29ycmVjdD8NCg0KS2h1emVtYQ0KDQpG cm9tOiBJZ29yIEJyeXNraW4gW21haWx0bzpJQnJ5c2tpbkBhZHZhb3B0aWNhbC5jb21dDQpTZW50 OiBGcmlkYXksIEFwcmlsIDEyLCAyMDEzIDY6MzYgUE0NClRvOiBWaXNobnUgUGF2YW4gQmVlcmFt OyBLaHV6ZW1hIFBpdGhld2FuDQpDYzogRGlldGVyIEJlbGxlcjsgY2NhbXBAaWV0Zi5vcmc8bWFp bHRvOmNjYW1wQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtDQ0FNUF0gTUVMR3MgLSBRJkENCg0K S2h1emVtYSwNCg0KDQoyLiAgICAgICBGb3IgY2FzZXMgb2YgY29uY3VycmVudCBjb21wdXRhdGlv biAoY2FzZSMyLTUpLCB5b3UgYXJlIG1haW5seSB0YWxraW5nIGFib3V0IGdsb2JhbCBvcHRpbWl6 YXRpb24gYW5kIGRpdmVyc2l0eSBhbW9uZyBtdWx0aXBsZSBzZXJ2aWNlcy4gWW91IGNhbiBkbyB0 aGUgcGF0aCBjb21wdXRhdGlvbiwgYnV0IHRvIGFjdHVhbGx5IGVuYWN0IHRoZSBjb21wdXRlZCBw YXRoIHRoZSBzaWduYWxpbmcgbmVlZHMgdG8gYmUgZG9uZSBmcm9tIHRoZSBzb3VyY2UgZW5kIG9m IHRob3NlIExTUHMuICBTbyB0aGVyZSBpcyBubyBwb2ludCBpbiBkb2luZyBjb25jdXJyZW50IGNv bXB1dGF0aW9uIGF0IG9uZSBuZXR3b3JrIGVsZW1lbnQgZm9yIHRoZSBzZXJ2aWNlcyBzdGFydGlu ZyBmcm9tIG11bHRpcGxlIG5ldHdvcmsgZWxlbWVudHMuIEF0IGJlc3QgaXQgbG9va3MgdG8gbWUg YSBwcm9ibGVtIHRvIGJlIHNvbHZlZCBieSBuZXR3b3JrIG1hbmFnZW1lbnQvcGxhbm5pbmcgc29m dHdhcmUuDQpXZWxsLCB3aGVuIGFuIGluZ3Jlc3Mgbm9kZSBpcyBpbml0aWF0aW5nIGEgc2Vydmlj ZSwgaXQgaXMgZG9pbmcgc28gb24gcmVxdWVzdCBmcm9tIHNvbWUgbWFuYWdlbWVudCBlbnRpdHku IFRoaXMgbWFuYWdlbWVudCBlbnRpdHkgY2FuIGNvbXB1dGUgcGF0aHMgZm9yIG1hbnkgc2Vydmlj ZXMgd2l0aCBzb21lIGdsb2JhbCBjcml0ZXJpYSBpbiBtaW5kLCBhbmQgdGhlbiBzcGVjaWZ5IHRo ZSByZXN1bHRpbmcgcGF0aHMgYXMgZXhwbGljaXQgRVJPcyBpbiBwcm92aXNpb25pbmcgcmVxdWVz dHMgc2VudCB0byBlYWNoIG9mIHRoZSBzZXJ2aWNlIGluZ3Jlc3Nlcy4gSG93IGVsc2UsIGZvciBl eGFtcGxlLCAgeW91IGNhbiBzZXQgdXAgc2V2ZXJhbCBzZXJ2aWNlcyBvcmlnaW5hdGVkIGZyb20g ZGlmZmVyZW50IG5vZGVzIHRoYXQgYXJlIGRpc2pvaW50IGZyb20gZWFjaCBvdGhlcj8gQWxzbywg d2hhdCBpcyB0aGUgcG9pbnQgaW4geW91ciBvcGluaW9uIG9mIHRoZSBzdGF0ZWZ1bGwgUENFIHdv cms/DQoNCkNoZWVycywNCklnb3INCg0KRnJvbTogVmlzaG51IFBhdmFuIEJlZXJhbSBbbWFpbHRv OnZpc2hudXBhdmFuQGdtYWlsLmNvbV0NClNlbnQ6IEZyaWRheSwgQXByaWwgMTIsIDIwMTMgODow OCBBTQ0KVG86IEtodXplbWEgUGl0aGV3YW4NCkNjOiBJZ29yIEJyeXNraW47IERpZXRlciBCZWxs ZXI7IGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb Q0NBTVBdIE1FTEdzIC0gUSZBDQoNCktodXplbWEsIEhpIQ0KDQpQbGVhc2Ugc2VlIGlubGluZS4u DQoNCg0KIDEuICAgICAgIFdoZW4gTmV0d29yayBoYXMgbW9yZSB0aGFuIDIgbGF5ZXIgaS5lLiBQ YWNrZXQtT1ROLURXRE0sIHRoZSBQYWNrZXQgKGNsaWVudCkgbGF5ZXIgd2lsbCBiZSB0YWxraW5n IHRvIGl0cyBpbW1lZGlhdGUgc2VydmVyIGxheWVyIGkuZS4gT1ROLCB3aGljaCBpbiB0dXJuIGlz IHRhbGtpbmcgdG8gRFdETSBsYXllci4gVXNpbmcgTUVMRywgY2xpZW50IGxheWVyIHBhdGggY29t cHV0YXRpb24gY2FuIHRha2UgY2FyZSBvZiByZXNvdXJjZSBleGNsdXNpdml0eSBvZiB2aXJ0dWFs IGxpbmsgZm9yIGltbWVkaWF0ZSBzZXJ2ZXIgbGF5ZXIgaS5lLiBPVE4gbGF5ZXIuICBIb3dldmVy IGlmIHRoZXJlIGlzIHJlc291cmNlIGV4Y2x1c2l2aXR5IGF0IERXRE0gbGF5ZXIsIHRoaXMgbWVj aGFuaXNtIGRvZXNu4oCZdCB3b3JrLiBZb3UgbmVlZCB0byBkbyBsb29zZSByb3V0aW5nIG9yIHVz ZSBkaXN0cmlidXRlZCBQQ0UgbW9kZWwNCg0KW1ZQQl0gVGhlIGJlaGF2aW9yIGlzIHRoZSBzYW1l IGFzIHdoYXQgeW91IHdvdWxkIGRvIHdpdGggU1JMR3MgaW4gYSBtdWx0aS1sYXllciBhcmNoaXRl Y3R1cmUuIFRoZXJlIGFyZSBhcmNoaXRlY3R1cmVzIHRoYXQgYWxsb3cgdGhlIFNSTEdzIGluIHRo ZSBsb3dlc3QgbGF5ZXIgdG8gYmUgZXhwb3J0ZWQgYWxsIHRoZSB3YXkgdXAgdG8gdGhlIGhpZ2hl c3QgbGF5ZXIuIFRoZSBleHBlY3RhdGlvbiBpcyB0aGF0IE1FTEdzIHdvdWxkIGJlIHRyZWF0ZWQg aW4gdGhlIHNhbWUgdmVpbi4NCg0KMi4gICAgICAgRm9yIGNhc2VzIG9mIGNvbmN1cnJlbnQgY29t cHV0YXRpb24gKGNhc2UjMi01KSwgeW91IGFyZSBtYWlubHkgdGFsa2luZyBhYm91dCBnbG9iYWwg b3B0aW1pemF0aW9uIGFuZCBkaXZlcnNpdHkgYW1vbmcgbXVsdGlwbGUgc2VydmljZXMuIFlvdSBj YW4gZG8gdGhlIHBhdGggY29tcHV0YXRpb24sIGJ1dCB0byBhY3R1YWxseSBlbmFjdCB0aGUgY29t cHV0ZWQgcGF0aCB0aGUgc2lnbmFsaW5nIG5lZWRzIHRvIGJlIGRvbmUgZnJvbSB0aGUgc291cmNl IGVuZCBvZiB0aG9zZSBMU1BzLiAgU28gdGhlcmUgaXMgbm8gcG9pbnQgaW4gZG9pbmcgY29uY3Vy cmVudCBjb21wdXRhdGlvbiBhdCBvbmUgbmV0d29yayBlbGVtZW50IGZvciB0aGUgc2VydmljZXMg c3RhcnRpbmcgZnJvbSBtdWx0aXBsZSBuZXR3b3JrIGVsZW1lbnRzLiBBdCBiZXN0IGl0IGxvb2tz IHRvIG1lIGEgcHJvYmxlbSB0byBiZSBzb2x2ZWQgYnkgbmV0d29yayBtYW5hZ2VtZW50L3BsYW5u aW5nIHNvZnR3YXJlLg0KW1ZQQl0gIEknbSBub3Qgc3VyZSB3aHkgeW91IHRoaW5rIHRoZXJlIGlz IG5vIHBvaW50IGluIGhhdmluZyBhIGNlbnRyYWxpemVkIGNvbXB1dGF0aW9uIGZ1bmN0aW9uIGNv bXB1dGUgcGF0aHMgY29uY3VycmVudGx5IGZvciBMU1BzIHdpdGggZGlmZmVyZW50IHNldCBvZiBl bmQtcG9pbnRzLiBFdmVuIHlvdXIgTk1TL3BsYW5uaW5nLXNvZnR3YXJlIGNhbiBpbnRlcmFjdCB3 aXRoIHN1Y2ggY29tcHV0YXRpb24gZW5naW5lLCByZXRyaWV2ZSBhbGwgdGhlIHBhdGhzIGFuZCB0 aGVuIGdvIGFib3V0IGluaXRpYXRpbmcgdGhlIHBhdGgtc2V0dXAgZnJvbSB0aGUgaW5ncmVzcyBv ZiBlYWNoIExTUC4NCg0KUmVnYXJkcywNCi1QYXZhbg0KDQoNCg0KDQpGcm9tOiBjY2FtcC1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmNjYW1w LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhh bGYgT2YgSWdvciBCcnlza2luDQpTZW50OiBUdWVzZGF5LCBNYXJjaCAyNiwgMjAxMyA3OjE5IFBN DQpUbzogRGlldGVyIEJlbGxlcjsgVmlzaG51IFBhdmFuIEJlZXJhbQ0KDQpDYzogY2NhbXBAaWV0 Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtDQ0FNUF0gTUVMR3Mg LSBRJkENCg0KRGlldGVyLA0KDQpZb3Ugc2FpZDoNCj4+IEkgZ3Vlc3Mgd2UgYXJlIGNvbWluZyBi YWNrIHRvIHRoZSBlc3NlbnRpYWwgcG9pbnQ6ICJhbmQgaG93IG9mdGVuIGNvbmN1cnJlbnQgcGF0 aCBjb21wdXRhdGlvbiB3aWxsIGJlID4+IHVzZWQuIg0KDQpUbyBiZSBob25lc3QsIHRoaXMgc3Vy cHJpc2VzIG1lIHF1aXRlIGEgYml0LCBMZXQgbWUgZ2l2ZSB5b3Ugc29tZSBvZiBtYW55IHJlYXNv bnMgYXMgdG8gd2h5IGNvbmN1cnJlbnQgcGF0aCBjb21wdXRhdGlvbnMgYXJlIG5lZWRlZCBhbmQg d2h5IHRoaXMgaXMgYmV0dGVyIHRoYW4gY29tcHV0aW5nIG9uZSBwYXRoIGF0IGEgdGltZToNCg0K DQoxLiAgICAgIENvbXB1dGluZyBzZXZlcmFsIGRpdmVyc2UgcGF0aHMgZm9yIHRoZSBzYW1lIHNl cnZpY2UgaW4gdGhlIGNvbnRleHQgb2Ygc2VydmljZSByZWNvdmVyeS4gSSBob3BlIHlvdSByZWFs aXplIHRoYXQgY29tcHV0aW5nIG9uZSBwYXRoIGF0IGEgdGltZSBvbiBtYW55IGNvbmZpZ3VyYXRp b25zIHByb2R1Y2VzIG5vIG9yIHN1Yi1vcHRpbWFsIHJlc3VsdHMuIEkgYWxzbyBob3BlIHlvdSBy ZWFsaXplIHRoZSBwcm9ibGVtIG9mIHNlbGVjdGluZyB0d28gcGF0aHMgd2l0aCBvbmUgb2YgdGhl bSAgaGF2aW5nIGEgbGluayB3aXRoIGNvbW1vbiBNRUxHIHdpdGggYSBsaW5rIGZyb20gYW5vdGhl ciBwYXRoOw0KDQoyLiAgICAgIENvbXB1dGluZyBwYXRocyBmb3IgbXVsdGlwbGUgc2VydmljZXMg dG8gYmUgc3VmZmljaWVudGx5IGRpc2pvaW50IGZyb20gZWFjaCBvdGhlcjsNCg0KMy4gICAgICBD b21wdXRpbmcgcGF0aHMgZm9yIG11bHRpcGxlIHNlcnZpY2VzIHRvIGFjaGlldmUgYSBnbG9iYWwg b3B0aW1pemF0aW9uIGNyaXRlcmlhIChlLmcuIG1pbmltYWwgc3VtbWFyeSB0b3RhbCBjb3N0KTsN Cg0KNC4gICAgICBDb21wdXRpbmcgcGF0aHMgZm9yIG11bHRpcGxlIHNlcnZpY2VzIGZvciB0aGUg cHVycG9zZSBvZiByZW1vdmluZyB0aGUgYmFuZHdpZHRoIGZyYWdtZW50YXRpb25zOw0KDQo1LiAg ICAgIENvbXB1dGluZyBwYXRocyBmb3IgbXVsdGlwbGUgc2VydmljZXMgdG8gcGxhbiBzaGFyZWQg bWVzaCBwcm90ZWN0aW9uL3Jlc3RvcmF0aW9uIHNjaGVtZXMNCg0KNi4gICAgICBFdGMuDQoNCkFs c28gdGhpbmsgYWJvdXQgdGhpczoNCg0KMS4gICAgICBJZiBjb25jdXJyZW50IHBhdGggY29tcHV0 YXRpb24gd2FzIG5vdCBpbXBvcnRhbnQsIHdoeSBQQ0VQIGluY2x1ZGVzIHRoZSBtYWNoaW5lcnkg dG8gZG8gdGhhdD8NCg0KMi4gICAgICBNeSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBzdGF0ZWZ1bGwg UENFIGlzIHRoYXQgaXQgZG9lcyBwcmV0dHkgbXVjaCBub3RoaW5nIGJ1dCBjb25jdXJyZW50IHBh dGggY29tcHV0YXRpb25zDQoNCllvdSBhbHNvIHNhaWQ6DQo+PiBJIHN1cHBvc2UgdGhhdCBpZiBh IHBjZSBhcHByb2FjaCBpcyB1c2VkLCBpLmUuLCBwYXRoIGNvbXB1dGF0aW9uIGlzIGNlbnRyYWxp emVkIGluY2x1ZGluZyB0aGUNCj4+IFRFLURCLCBNRUxHIHJvdXRpbmcgZXh0ZW5zaW9ucyBhcmUg bm90IG5lZWRlZCBiZWNhdXNlIHRoZSBpbmZvcm1hdGlvbiBhYm91dCBtdXR1YWwNCj4+ZXhjbHVz aXZlIFZMcyBjYW4gYmUga2VwdCBpbiB0aGUgY2VudHJhbCBURS1EQiB3aGVuIFZMcyBhcmUgY29u ZmlndXJlZC4NCkhvdyB0aGlzIGxvZ2ljIGRvZXMgbm90IGFwcGx5IHRvIG90aGVyIGxpbmsgYXR0 cmlidXRlcyBzdWNoIGFzIFNSTEdzPw0KV2hhdCBpZiBwYXRoIGNvbXB1dGF0aW9uIGlzIG5vdCBj ZW50cmFsaXplZD8NCg0KQ2hlZXJzLA0KSWdvcg0KDQpGcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmNjYW1wLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgRGll dGVyIEJlbGxlcg0KU2VudDogTW9uZGF5LCBNYXJjaCAyNSwgMjAxMyA1OjUyIFBNDQpUbzogVmlz aG51IFBhdmFuIEJlZXJhbQ0KQ2M6IGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBbQ0NBTVBdIE1FTEdzIC0gUSZBDQoNCkhpIFBhdmFuLA0KT24gMjUu MDMuMjAxMyAwNzx0ZWw6MjUuMDMuMjAxMyUyMDA3PjoyOSwgRmF0YWkgWmhhbmcgd3JvdGU6DQpI aSBQYXZhbiwNCg0KSSBhbSBub3Qgc3VyZSBob3cgbXVjaCBWTCAoVmlydHVhbCBMaW5rKSB3aWxs IGJlIHVzZWQgaW4gdGhlIHByYWN0aWNhbCBkZXBsb3ltZW50IGFuZCBob3cgb2Z0ZW4gY29uY3Vy cmVudCBwYXRoIGNvbXB1dGF0aW9uIHdpbGwgYmUgdXNlZC4NCkkgZ3Vlc3Mgd2UgYXJlIGNvbWlu ZyBiYWNrIHRvIHRoZSBlc3NlbnRpYWwgcG9pbnQ6ICJhbmQgaG93IG9mdGVuIGNvbmN1cnJlbnQg cGF0aCBjb21wdXRhdGlvbiB3aWxsIGJlIHVzZWQuIg0KDQpUaGlzIG1lYW5zIHdlIGFyZSB0cnlp bmcgdG8gZmlndXJlIG91dCB1bmRlciB3aGljaCBjb25kaXRpb25zIE1FTEcgcm91dGluZyBleHRl bnNpb25zDQpjb3VsZCBiZSBiZW5lZmljaWFsLg0KDQpJTUhPLCB0aGV5IHdvdWxkIG9ubHkgbWFr ZSBzZW5zZSwgaWY6DQoNCiAgKiAgIGEgcGF0aCBjb21wdXRhdGlvbiBmdW5jdGlvbiBzdXBwb3J0 cyB0aGUgY2FsY3VsYXRpb24gb2YgayBzaG9ydGVzdCBwYXRocyBjb25jdXJyZW50bHkNCiAgKiAg IGlmIHRoZXJlIGlzIG9ubHkgYSBzaW5nbGUgcGF0aCBjb21wdXRhdGlvbiBmdW5jdGlvbiBpbnN0 YW5jZSBwZXIgZG9tYWluIChwY2UgYXBwcm9hY2gpDQpJZiBwYXRoIGNvbXB1dGF0aW9uIGlzIGRv bmUgaW4gYSBkaXN0cmlidXRlZCBmYXNoaW9uIHRoZSBiZW5lZml0IGdvZXMgYXdheSBiZWNhdXNl DQp0aGUgaW5zdGFuY2VzIGNhbGN1bGF0ZSBwYXRocyBpbmRlcGVuZGVudGx5IQ0KSSBzdXBwb3Nl IHRoYXQgaWYgYSBwY2UgYXBwcm9hY2ggaXMgdXNlZCwgaS5lLiwgcGF0aCBjb21wdXRhdGlvbiBp cyBjZW50cmFsaXplZCBpbmNsdWRpbmcgdGhlDQpURS1EQiwgTUVMRyByb3V0aW5nIGV4dGVuc2lv bnMgYXJlIG5vdCBuZWVkZWQgYmVjYXVzZSB0aGUgaW5mb3JtYXRpb24gYWJvdXQgbXV0dWFsDQpl eGNsdXNpdmUgVkxzIGNhbiBiZSBrZXB0IGluIHRoZSBjZW50cmFsIFRFLURCIHdoZW4gVkxzIGFy ZSBjb25maWd1cmVkLg0KDQpIZW5jZSwgaXQgaXMgcXVpdGUgZG91YnRmdWwgd2hldGhlciBNRUxH IHJvdXRpbmcgZXh0ZW5zaW9ucyBhcmUgcmVhbGx5IHVzZWZ1bCB1bmxlc3MgdGhlaXINCmFwcGxp Y2FiaWxpdHkgaXMgYnJvYWRlci4NCg0KDQpUaGFua3MsDQpEaWV0ZXINCg0KRG8geW91IHRoaW5r IGlmIGl0IG1ha2VzIHNlbnNlIHRvIGFkZCBhIGZsYWcgKGluIHJvdXRpbmcgYWR2ZXJ0aXNlbWVu dCkgdG8gaW5kaWNhdGUgYSBsaW5rIGlzIGEgVkwgb3Igbm90Pw0KDQoNCg0KQmVzdCBSZWdhcmRz DQoNCkZhdGFpDQoNCkZyb206IFZpc2hudSBQYXZhbiBCZWVyYW0gW21haWx0bzp2aXNobnVwYXZh bkBnbWFpbC5jb21dDQpTZW50OiBGcmlkYXksIE1hcmNoIDIyLCAyMDEzIDg6NTcgUE0NClRvOiBG YXRhaSBaaGFuZw0KQ2M6IElnb3IgQnJ5c2tpbjsgY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1w QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtDQ0FNUF0gTUVMR3MgLSBRJkENCg0KRmF0YWksIEhp IQ0KDQpHb29kIHRvIHNlZSB0aGF0IHlvdSB1bmRlcnN0YW5kIHRoZSBjb25zdHJ1Y3Qgbm93Lg0K DQpUaGlzIGlzIG5vdCBhIGNvcm5lciBjYXNlLiBUaGUgdXRpbGl0eSBvZiB0aGUgY29uc3RydWN0 IGJlY29tZXMgcXVpdGUgc2lnbmlmaWNhbnQgaWYgeW91IGhhdmUgYW4gYXBwbGljYXRpb24gdGhh dCBkb2VzIGNvbmN1cnJlbnQgcGF0aCBjb21wdXRhdGlvbnMgb24gYW4gYWJzdHJhY3QgdG9wb2xv Z3kuDQoNClJlZ2FyZHMsDQotUGF2YW4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KDQpDQ0FNUCBtYWlsaW5nIGxpc3QNCg0KQ0NBTVBAaWV0Zi5v cmc8bWFpbHRvOkNDQU1QQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2NjYW1wDQoNCi0tDQpESUVURVIgQkVMTEVSDQpBTENBVEVMLUxVQ0VOVCBERVVU U0NITEFORCBBRw0KUFJPSkVDVCBNQU5BR0VSIEFTT04vR01QTFMgQ09OVFJPTCBQTEFORQ0KQ09S RSBORVRXT1JLUyBCVVNJTkVTUyBESVZJU0lPTg0KT1BUSUNTIEJVLCBTV0lUQ0hJTkcgUiZEDQoN CkxvcmVuenN0cmFzc2UgMTANCjcwNDM1IFN0dXR0Z2FydCwgR2VybWFueQ0KUGhvbmU6ICs0OSA3 MTEgODIxIDQzMTI1IGJlZ2luX29mX3RoZV9za3lwZV9oaWdobGlnaHRpbmcgW1hdICs0OSA3MTEg ODIxIDQzMTI1IEZSRUUgIGVuZF9vZl90aGVfc2t5cGVfaGlnaGxpZ2h0aW5nIGJlZ2luX29mX3Ro ZV9za3lwZV9oaWdobGlnaHRpbmcg6ZSZ6K+v77yB5pyq5oyH5a6a5paH5Lu25ZCN44CCKzQ5IDcx MSA4MjEgNDMxMjUgYmVnaW5fb2ZfdGhlX3NreXBlX2hpZ2hsaWdodGluZyBbWF0gKzQ5IDcxMSA4 MjEgNDMxMjUgRlJFRSAgZW5kX29mX3RoZV9za3lwZV9oaWdobGlnaHRpbmcgRlJFRSAgYmVnaW5f b2ZfdGhlX3NreXBlX2hpZ2hsaWdodGluZyDplJnor6/vvIHmnKrmjIflrprmlofku7blkI3jgIIr NDkgNzExIDgyMSA0MzEyNSBGUkVFICA8dGVsOiUyQjQ5JTIwNzExJTIwODIxJTIwNDMxMjU+DQpN b2JpbDogKzQ5IDE3NSA3MjY2ODc0IGJlZ2luX29mX3RoZV9za3lwZV9oaWdobGlnaHRpbmcgW1hd ICs0OSAxNzUgNzI2Njg3NCBGUkVFICBlbmRfb2ZfdGhlX3NreXBlX2hpZ2hsaWdodGluZyBiZWdp bl9vZl90aGVfc2t5cGVfaGlnaGxpZ2h0aW5nIOmUmeivr++8geacquaMh+WumuaWh+S7tuWQjeOA gis0OSAxNzUgNzI2Njg3NCBiZWdpbl9vZl90aGVfc2t5cGVfaGlnaGxpZ2h0aW5nIFtYXSArNDkg MTc1IDcyNjY4NzQgRlJFRSAgZW5kX29mX3RoZV9za3lwZV9oaWdobGlnaHRpbmcgRlJFRSAgYmVn aW5fb2ZfdGhlX3NreXBlX2hpZ2hsaWdodGluZyDplJnor6/vvIHmnKrmjIflrprmlofku7blkI3j gIIrNDkgMTc1IDcyNjY4NzQgRlJFRSAgPHRlbDolMkI0OSUyMDE3NSUyMDcyNjY4NzQ+DQpEaWV0 ZXIuQmVsbGVyQGFsY2F0ZWwtbHVjZW50LmNvbTxtYWlsdG86RGlldGVyLkJlbGxlckBhbGNhdGVs LWx1Y2VudC5jb20+DQoNCkFsY2F0ZWwtTHVjZW50IERldXRzY2hsYW5kIEFHDQpEb21pY2lsZSBv ZiB0aGUgQ29tcGFueTogU3R1dHRnYXJ0IMK3IExvY2FsIENvdXJ0IFN0dXR0Z2FydCBIUkIgNDAy Ng0KQ2hhaXJtYW4gb2YgdGhlIFN1cGVydmlzb3J5IEJvYXJkOiBNaWNoYWVsIE9wcGVuaG9mZg0K Qm9hcmQgb2YgTWFuYWdlbWVudDogV2lsaGVsbSBEcmVzc2VsaGF1cyAoQ2hhaXJtYW4pIMK3IEhh bnMtSsO2cmcgRGF1YiDCtyBEci4gUmFpbmVyIEZlY2huZXIgwrcgQW5kcmVhcyBHZWhlDQoNCg0K DQo= --_000_F82A4B6D50F9464B8EBA55651F541CF843175FD1SZXEML552MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0i R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+ DQo8IS0tW2lmICFtc29dPjxzdHlsZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9 DQpvXDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwo I2RlZmF1bHQjVk1MKTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwv c3R5bGU+PCFbZW5kaWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAw IDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6 MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0 IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2Ut MToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCnNwYW4uSFRNTENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC8 5byPIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCDpooTorr7moLzlvI8iOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5za3lw ZXBuaHByaW50Y29udGFpbmVyMTM2NjM3NTU5MQ0KCXttc28tc3R5bGUtbmFtZTpza3lwZV9wbmhf cHJpbnRfY29udGFpbmVyXzEzNjYzNzU1OTE7fQ0Kc3Bhbi5za3lwZXBuaGNvbnRhaW5lcg0KCXtt c28tc3R5bGUtbmFtZTpza3lwZV9wbmhfY29udGFpbmVyO30NCnNwYW4uc2t5cGVwbmhtYXJrDQoJ e21zby1zdHlsZS1uYW1lOnNreXBlX3BuaF9tYXJrO30NCnNwYW4uc2t5cGVwbmhoaWdobGlnaHRp bmdpbmFjdGl2ZWNvbW1vbg0KCXttc28tc3R5bGUtbmFtZTpza3lwZV9wbmhfaGlnaGxpZ2h0aW5n X2luYWN0aXZlX2NvbW1vbjt9DQpzcGFuLnNreXBlcG5odGV4dGFyZWFzcGFuDQoJe21zby1zdHls ZS1uYW1lOnNreXBlX3BuaF90ZXh0YXJlYV9zcGFuO30NCnNwYW4uc2t5cGVwbmh0ZXh0c3Bhbg0K CXttc28tc3R5bGUtbmFtZTpza3lwZV9wbmhfdGV4dF9zcGFuO30NCnNwYW4uc2t5cGVwbmhmcmVl dGV4dHNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6c2t5cGVfcG5oX2ZyZWVfdGV4dF9zcGFuO30NCnNw YW4uRW1haWxTdHlsZTI3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0 IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExp c3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE3NDM3OTg0Mzc7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE2NDY1NjYwODY7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJn aW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5IaSBQYXZhbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J biBteSBleG1wbGUsIEkganVzdCB3YW50IHRvIHNob3cgeW91IHRoYXQgdGhlIG1vcmUgZ2VuZXJp YyBjYXNlIGZvciB0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+aGUNCiBWVEUgbGluayAodG8gaW1wcm92ZSByZXNvdXJjZSB1c2Fn ZSBlZmZpY2llbmN5KSwgd2hpY2ggZG9lcyBub3QgYXNzb2NpYXRlIGEgc3BlY2lmaWMgcG90ZW50 aWFsIHBhdGggYXQgdGhlIHRpbWUgb2YgYWR2ZXJ0aXNlbWVudC4gSW4gdGhpcyBnZW5lcmljIGNh c2UsIE1FTEdzIGRvbuKAmXQgaGVscC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1p ZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBo Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlBsZWFzZSBzZWUgbW9yZSBpbi1saW5lIGJlbG93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5 OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldoYXQgaXMgVmlydHVhbCBMaW5rPyBBcyBk ZXNjcmliZWQgaW4gUkZDNjAwMSwgaXQgc2F5cyBhcyBiZWxvdy4gU28gbXkgcXVlc3Rpb24gaXM6 DQogd2hlbiB0aGVyZSBhcmUgdHdvIFZMcyBjcmVhdGVkIHRocm91Z2ggQ2FsbCBhcHByb2FjaCBh cyBkZWZpbmVkIGluIFJGQzYwMDEsIG9uZSBoYXMgMyBwb3RlbnRpYWwgcGF0aHMgaW4gdGhlIHNl cnZlciBsYXllciB0byBzZXR1cCBGQS1MU1AsIGFuZCBhbm90aGVyIGhhcyAyIHBvdGVudGlhbCBw YXRocyBpbiB0aGUgc2VydmVyIGxheWVyLCBhbmQgb25seSBvbmUgb2YgdGhlIDMgJmFtcDsyIGhh cyB0aGUgc2FtZSByZXNvdXJjZSBzaGFyZWQgaW4gdGhlIHNlcnZlcg0KIGxheWVyLiA8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ib3cgTUVMR3MgY2FuIGhlbHAgaW4gdGhpcyBj YXNlPzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPltWUEJdIEkgdGhp bmsgdGhlIGRpc2Nvbm5lY3QgYmV0d2VlbiB1cyBoYXMgZ290IHRvIGRvIHdpdGggaG93IHRoZSBW aXJ0dWFsIFRFIChWVEUpIExpbmsgZ2V0cyBhZHZlcnRpc2VkLiBTYXksIHRoYXQgdGhlcmUgYXJl IDMgcG90ZW50aWFsIHBhdGhzIGluIHRoZSBzZXJ2ZXIgbGF5ZXIgdGhhdCBjYW4gY2F0ZXIgdG8g YSBnaXZlbiBWVEUgbGluay4gSW4gb3VyIG5vdGlvbiBvZg0KIHRoZSAmcXVvdDtWaXJ0dWFsIFRF IExpbmsmcXVvdDssIGF0IHRoZSB0aW1lIG9mIGFkdmVydGlzaW5nIHRoZXJlIGFscmVhZHkgZXhp c3RzIGFuIGFzc29jaWF0aW9uIGJldHdlZW4gdGhlIFZURSBsaW5rIGFuZCBvbmUgb2YgdGhlc2Ug MyBwYXRocy4gV2l0aG91dCBhc3NvY2lhdGluZyB5b3VyIFZURSBsaW5rIHdpdGggYSBzcGVjaWZp YyBzZXJ2ZXItcGF0aCwgeW91IHdvdWxkbid0IGJlIGFibGUgdG8gYWNjdXJhdGVseSBhZHZlcnRp c2UgYXR0cmlidXRlcyBsaWtlDQogZGl2ZXJzaXR5LCBkZWxheSwgbXV0dWFsLWV4Y2x1c2l2aXR5 IGV0Yy4gSWYgSSB1bmRlcnN0b29kIHlvdXIgcXVlc3Rpb24gY29ycmVjdGx5LCB5b3VyIG5vdGlv biBvZiBob3cgdGhlIFZpcnR1YWwgVEUgTGluayBnZXRzIGFkdmVydGlzZWQgc2VlbXMgdG8gYmUg ZGlmZmVyZW50IC0geW91IGRvbid0IGFzc29jaWF0ZSB0aGUgVlRFIGxpbmsgdG8gYSBzcGVjaWZp YyBwb3RlbnRpYWwgcGF0aCBhdCB0aGUgdGltZSBvZiBhZHZlcnRpc2VtZW50LiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bRmF0YWldIFJpZ2h0LiBUaGUgVlRFIGxp bmsgZG9lcyBub3QgYXNzb2NpYXRlIGEgc3BlY2lmaWMgcG90ZW50aWFsIHBhdGggYXQgdGhlIHRp bWUgb2YgYWR2ZXJ0aXNlbWVudCwgaXQgaXMgYSBraW5kIG9mIHBvdGVudGlhbGl0eSBmb3IgdGhl IFZURQ0KIGFkdmVydGlzZWQgYXMgZGVmaW5lZCBpbiBSRkM2MDAxLiBJbiB0aGlzIGNhc2UsIHBh dGggY29tcHV0YXRpb24gZWxlbWVudCAoZS5nLCBjZW50cmFsaXplZCBQQ0UgZm9yIGludGVyLWxh eWVyKSBjYW4gYmUgYXdhcmUgb2YgdGhlIGxpbmsgaW5mb3JtYXRpb24sIGluY2x1ZGluZyBsaW5r IGJhbmR3aWR0aCwgU1JMR+KApi4uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNvbnRpbnVpbmcgd2l0aCB5b3VyIGV4YW1w bGUgLSBJZiB0aGUgcGF0aCB0aGF0IGdldHMgYXNzb2NpYXRlZCB3aXRoIFZURS1MaW5rLTEgYW5k IHRoZSBwYXRoIHRoYXQgZ2V0cyBhc3NvY2lhdGVkIHdpdGggVlRFLUxpbmstMiBkZXBlbmQgb24g dGhlIHNhbWUgcmVzb3VyY2UsICZxdW90O01FTEdzJnF1b3Q7IHdvdWxkIG1ha2Ugc3VyZSB0aGF0 IHRoZSBjbGllbnQgY29tcHV0YXRpb24gZnVuY3Rpb24NCiBpcyBhd2FyZSBvZiB0aGUgZXhpc3Rl bmNlIG9mIHN1Y2ggJnF1b3Q7bXV0dWFsIGV4Y2x1c2l2aXR5JnF1b3Q7IHJlbGF0aW9uc2hpcC4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0ZhdGFpXSBUaGUgcGF0 aCBjb21wdXRhdGlvbiBlbGVtZW50IChjZW50cmFsaXplZCBQQ0UgZm9yIGludGVyLWxheWVyIG9y IG11bHRpcGxlIFBDRXMgdGhyb3VnaCBjb21tdW5pY2F0aW9uKSBjYW4gdGFrZSBjYXJlIG9mIHRo aXMgaXNzdWUgdG8gYXZvaWQNCiB0aGlzIGhhcHBlbiB3aXRob3V0IE1FTEcgaW50cm9kdWNlZC4g PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5CUiw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+LVBhdmFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QSB2aXJ0dWFsIFRFIGxpbmsgaXMgZGVmaW5l ZCBhcyBhIFRFIGxpbmsgYmV0d2VlbiB0d28gdXBwZXItbGF5ZXIgbm9kZXMgdGhhdCBpcyBub3QN CiBhc3NvY2lhdGVkIHdpdGggYSBmdWxseSBwcm92aXNpb25lZCBGQS1MU1AgaW4gYSBsb3dlciBs YXllciBbPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTIxMiIgdGFyZ2V0 PSJfYmxhbmsiIHRpdGxlPSImcXVvdDtSZXF1aXJlbWVudHMgZm9yIEdNUExTLUJhc2VkIE11bHRp LSBSZWdpb24gYW5kIE11bHRpLUxheWVyIE5ldHdvcmtzIChNUk4vTUxOKSZxdW90OyI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0Q7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPlJGQzUyMTI8L3NwYW4+ PC9hPl0uJm5ic3A7DQogQSB2aXJ0dWFsIFRFIGxpbmsgaXMgYWR2ZXJ0aXNlZCBhcyBhbnkgVEUg bGluaywgZm9sbG93aW5nIHRoZSBydWxlcyBpbiBbPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjNDIwNiIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSImcXVvdDtMYWJlbCBTd2l0 Y2hlZCBQYXRocyAoTFNQKSBIaWVyYXJjaHkgd2l0aCBHZW5lcmFsaXplZCBNdWx0aS1Qcm90b2Nv bCBMYWJlbCBTd2l0Y2hpbmcgKEdNUExTKSBUcmFmZmljIEVuZ2luZWVyaW5nIChURSkmcXVvdDsi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO3RleHQtZGVjb3JhdGlvbjpub25lIj5SRkM0MjA2 PC9zcGFuPjwvYT5dDQogZGVmaW5lZCBmb3IgZnVsbHkgcHJvdmlzaW9uZWQgVEUgbGlua3MuJm5i c3A7IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMwMDcwQzAiPkEgdmlydHVhbCBURSBsaW5rIHJlcHJlc2VudHMgdGh1cyB0aGUNCjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+cG90ZW50 aWFsaXR5PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzAwNzBDMCI+IHRvIHNldCB1cCBhbiBGQS1MU1A8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4NCiBpbiB0aGUgbG93ZXIgbGF5 ZXIgdG8gc3VwcG9ydCB0aGUgVEUgbGluayB0aGF0IGhhcyBiZWVuIGFkdmVydGlzZWQuPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpq dXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPg0KPHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZXN0IFJlZ2FyZHM8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzt0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+ DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50 ZXItaWRlb2dyYXBoIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+RmF0YWk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4NCjxhIGhyZWY9Im1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+Y2NhbXAtYm91bmNlc0BpZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVm PSJtYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNjYW1wLWJv dW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5WaXNobnUgUGF2YW4gQmVl cmFtPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEFwcmlsIDE2LCAyMDEzIDEwOjEwIFBNPGJy Pg0KPGI+VG86PC9iPiBLaHV6ZW1hIFBpdGhld2FuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpjY2Ft cEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNjYW1wQGlldGYub3JnPC9hPjxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW0NDQU1QXSBNRUxHcyAtIFEmYW1wO0E8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5LaHV6ZW1h LCBIaSE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+TUVMR3Mg YXJlIHVzZWZ1bCBhbmQgY29tZSBpbnRvIHBsYXkgb25seSB3aGVuOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiPigxKSBUaGUgc2VydmVyIG5ldHdvcmsgZG9tYWluIGlzIGFic3RyYWN0ZWQgYW5kIHRo ZSBhZHZlcnRpc2VkIFZpcnR1YWwgVEUtbGlua3MgcG9zc2VzcyBzb21lIG11dHVhbCBleGNsdXNp dml0eSByZWxhdGlvbnNoaXAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+KDIpIFRoZXJlIGlzIGEg Q2VudHJhbGl6ZWQgcGF0aCBjb21wdXRhdGlvbiBlbnRpdHkgaW4gdGhlIGNsaWVudCBkb21haW4g KGNvbXB1dGVzIHBhdGhzIGluIHRlcm1zIG9mIENsaWVudCBURS1saW5rcy9URS1ub2RlcykgdGhh dCBpcyBjYXBhYmxlIG9mIGRvaW5nIGNvbmN1cnJlbnQNCiBwYXRoIGNvbXB1dGF0aW9ucy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5JZiBlaXRo ZXIgb2YgdGhlIGFib3ZlIDIgc3RhdGVtZW50cyBpcyBOT1QgdHJ1ZSwgdGhlcmUgaXMgbm8gdXRp bGl0eSBmb3IgTUVMR3MuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+QXQgdGhlIHJpc2sg b2YgYmVpbmcgcGVkYW50aWM6Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+LSBBcmUgTUVM R3MgbmVlZGVkIHdoZW4gdGhlIHNlcnZlci1uZXR3b3JrIGRvbWFpbiBpbiBub3QgYWJzdHJhY3Rl ZCAobm8gVmlydHVhbCBURSBsaW5rcyk/IFRoZSBhbnN3ZXIgaXMgTk8uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+LSBBcmUgTUVMR3MgbmVlZGVkIHdoZW4geW91IGhhdmUgYSBkaXN0cmlidXRlZCBw YXRoLWNvbXB1dGF0aW9uIGFyY2hpdGVjdHVyZSAoQ2xpZW50IFBDRSBpbnRlcmFjdGluZyB3aXRo IFNlcnZlciBQQ0UpPyBUaGUgYW5zd2VyIGlzIE5PLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPi0g QXJlIE1FTEdzIG5lZWRlZCB3aGVuIHRoZSBjZW50cmFsaXplZCBwYXRoLWNvbXB1dGF0aW9uIGVu Z2luZSBkb2Vzbid0IChjYW4ndCkgZG8gY29uY3VycmVudCBjb21wdXRhdGlvbnM/IFRoZSBhbnN3 ZXIgaXMgTk8uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+VGhlIGFjdHVhbCBwcm9jZWR1cmVzIGludm9sdmVkIGluIGFic3RyYWN0aW5nIHRoZSBz ZXJ2ZXIgbmV0d29yayBkb21haW4gaXMgYmV5b25kIHRoZSBzY29wZSBvZiAmbHQ7ZHJhZnQtbWVs Z3MmZ3Q7LiBUaGUgYWJzdHJhY3Rpb24gcHJvY2VkdXJlIGl0c2VsZiBpcyBpbXBsZW1lbnRhdGlv bi1zcGVjaWZpYw0KIChtYXliZSBzb21lZGF5IHNvbWVvbmUgd291bGQgcHV0IHRvZ2V0aGVyIGEg ZHJhZnQgZm9yIGRpc2N1c3NpbmcgdGhpcykuIFRob3VnaCBpdCBpcyB0cnVlIHRoYXQgdGhlIHBy aW1hcnkgdXNlLWNhc2Ugd2UgaGFkIGluIG1pbmQgd2hlbiBjb21pbmcgdXAgd2l0aCB0aGlzIG5l dyBjb25zdHJ1Y3QgaW52b2x2ZXMgYSBsYW1iZGEtbGF5ZXIgc2VydmVyIG5ldHdvcmsgZG9tYWlu LCB0aGVyZSBpcyByZWFsbHkgbm8gcmVzdHJpY3Rpb24gKGF0IGEgY29uY2VwdHVhbA0KIGxldmVs KSBvbiB1c2luZyB0aGlzIGNvbnN0cnVjdCB3aGVuIGFic3RyYWN0aW5nIGEgcGFja2V0LWxheWVy IHNlcnZlciBuZXR3b3JrIGRvbWFpbiBvciBhIFRETS1sYXllciBzZXJ2ZXIgbmV0d29yayBkb21h aW4uIEl0IGlzIHVwIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvbiBob3cgdG8gbWFrZSBiZXN0IHVz ZSBvZiB0aGlzIGNvbnN0cnVjdC4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5XaGVuIHlvdSBhZHZlcnRpc2UgYSBWaXJ0dWFsIFRFLWxp bmsgaW50byBhIGNsaWVudCBuZXR3b3JrIGRvbWFpbiwgeW91IGFyZSBkb2luZyB0aGlzIGJhc2Vk IG9uIHRoZSBleGlzdGVuY2Ugb2Ygc29tZSBwb3RlbnRpYWwgdW5kZXJseWluZyBzZXJ2ZXItcGF0 aC4gVEUgYXR0cmlidXRlcw0KIGxpa2UgU1JMR3MsIE1FTEdzLCBkZWxheSBldGMgdGhhdCBnZXQg YWR2ZXJ0aXNlZCBmb3IgdGhlIFZpcnR1YWwgVEUtbGluayBkZXBlbmQgb24gdGhlIHVuZGVybHlp bmcgc2VydmVyLXBhdGggdGhhdCBpcyBjaG9zZW4gZm9yIGNhdGVyaW5nIHRvIHRoaXMgQ2xpZW50 IFRFLWxpbmsuIElmIHRoZSB1bmRlcmx5aW5nIHNlcnZlci1wYXRoIGtlZXBzIGNoYW5naW5nIChi YXNlZCBvbiBuZXR3b3JrIGV2ZW50cyksIHRoZXNlIFRFIGF0dHJpYnV0ZXMgd291bGQNCiBhbHNv IGtlZXAgY2hhbmdpbmcuIFRoZSBwcm9jZWR1cmUgZm9yIGtlZXBpbmcgdGhlIGFkdmVydGlzZWQg aW5mb3JtYXRpb24gJnF1b3Q7Y3VycmVudCZxdW90OyBpcyBhbiBpbXBsZW1lbnRhdGlvbiBjaG9p Y2UuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+SWYgdGhlcmUgZXhpc3RzIHN1Y2ggYSB0aGluZyBhcyBhbiBhYnN0cmFjdGlvbiBtYW5h Z2VyIChhZ2FpbiwgdGhpcyBpcyB0b3RhbGx5IGltcGxlbWVudGF0aW9uIHNwZWNpZmljKSwgdGhl biB0aGUgYXNzdW1wdGlvbiBpcyB0aGF0IGl0IGRvZXMgb25lIG9mIHRoZSBmb2xsb3dpbmcNCiAt Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+KGEpIGNvbXB1dGVzIG5ldyBzZXJ2ZXItcGF0 aHMgZm9yIHRoZSBWaXJ0dWFsIFRFIGxpbmtzIHdoZW5ldmVyIHRoZXJlIGlzIGEgY2hhbmdlIGlu IHRoZSBuZXR3b3JrIChtYXkgbm90IGJlIHZlcnkgc2NhbGFibGUgaW4gc29tZSBhcmNoaXRlY3R1 cmVzKSwmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4oYikgb3IgZG9lcyBwZXJpb2RpYyBw YXRoLWNvbXB1dGF0aW9uIGZvciBlYWNoIFZpcnR1YWwgVEUgbGluaywmbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIj4oYykgb3IgdXNlcyBhIHBvbGljeSB0byBwaW4gZG93biB0aGUgVmlydHVh bCBURS1saW5rIHRvIGEgc3BlY2lmaWMgdW5kZXJseWluZyBzZXJ2ZXItcGF0aCwmbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIj4oZCkgb3IgdXNlcyBhIGNvbWJpbmF0aW9uIG9mIChhKSwgKGIp LCAoYykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyI+Jmx0O2RyYWZ0LW1lbGdzJmd0OyBkb2Vzbid0IG1ha2UgYW55IHJlY29tbWVuZGF0aW9uIGFz IHRvIHdoYXQgY2hvaWNlIHRoZSBhYnN0cmFjdGlvbiBtYW5hZ2VyIHdvdWxkIG5lZWQgdG8gdGFr ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5I b3BlIHRoaXMgaGVscHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+LVBhdmFuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBUdWUsIEFwciAxNiwgMjAxMyBh dCA3OjA4IEFNLCBLaHV6ZW1hIFBpdGhld2FuICZsdDs8YSBocmVmPSJtYWlsdG86a3BpdGhld2Fu QGluZmluZXJhLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmtwaXRoZXdhbkBpbmZpbmVyYS5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5IaSBJZ29yLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkkgYW0gdHJ5aW5nIHRvIHN1bW1hcml6ZSB0aGUgZGlzY3Vzc2lvbiB3ZSBoYWQgc28gZmFyLiBQ bHMgc2VlIGlmIG15IGNvbmNsdXNpb24gaXMgaW4NCiBzeW5jIHdpdGggdGhlIGlkZWEgb2YgTUVM RyB5b3UgaGF2ZSA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NRUxHIGlzIHVz ZWZ1bCB3aGVuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjEuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ c2VydmVyIGxheWVyIFZMcyBhcmUgbmFpbGVkIGRvd24gZm9yIHRoZSByZXNvdXJjZXMgb24gdGhl IHNlcnZlciBsYXllciBsaW5rcyB0aGF0IGFyZSBzaGFyZWQgYW1vbmcgbXVsdGlwbGUgVkxzLiBU aGVzZSByZXNvdXJjZXMgYXJlIHR5cGljYWxseSB3YXZlbGVuZ3RoIG9uDQogYSBmaWJlciAoY2Fu IGl0IGJlIGFueXRoaW5nIGVsc2U/PykuIEluIG90aGVyIHdvcmRzLCBpZiAyIFZMcyBhcmUgcGlu bmVkIHRvIHVzZSBhIHBhcnRpY3VsYXIgd2F2ZWxlbmd0aCBvbiBhIHBhcnRpY3VsYXIgZmliZXIs IHRoZW4gdGhlc2UgMiBWTHMgd2lsbCBoYXZlIE1FTEcgZm9yIHRoZSB3YXZlbGVuZ3RoLjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4yLjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPnNlcnZlciBsYXllciBk byBub3QgaGF2ZSBjZW50cmFsaXplZCBwYXRoIGNvbXB1dGF0aW9uIGVudGl0eSB3aGljaCBjYW4g YmUgdXNlZCBieSBjbGllbnQgbGF5ZXIgdG8gYXNrIGZvciBjb25jdXJyZW50IGRpdmVyc2UgcGF0 aCBjb21wdXRhdGlvbiB3aXRoaW4gc2VydmVyIGxheWVyLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4zLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNsaWVudCBsYXllciBoYXMgYSBjZW50cmFsaXplZCBw YXRoIGNvbXB1dGF0aW9uIGVudGl0eSwgd2hpY2ggd291bGQgY29tcHV0ZSBwYXRocyBmb3IgY2xp ZW50JiM0MztzZXJ2ZXIgbGF5ZXIuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+VGhlIG5lZWQgaXMgdG8gY2VudHJhbGl6ZWQgY29uY3VycmVudCBjb21wdXRh dGlvbiBvZiBtb3JlIHRoYW4gb25lIGNsaWVudCYjNDM7c2VydmVyIGxheWVyIHBhdGggdGhhdCBt ZWV0cyBzb21lIGRpdmVyc2l0eSBhbmQgcmVzb3VyY2UgZXhjbHVzaXZpdHkgcmVxdWlyZW1lbnRz Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2RzPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ S2h1emVtYTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gSWdvcg0KIEJyeXNraW4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86SUJyeXNraW5A YWR2YW9wdGljYWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+SUJyeXNraW5AYWR2YW9wdGljYWwuY29t PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEFwcmlsIDE1LCAyMDEzIDk6NDQgUE08 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGI+ VG86PC9iPiBLaHV6ZW1hIFBpdGhld2FuOyBWaXNobnUgUGF2YW4gQmVlcmFtPGJyPg0KPGI+Q2M6 PC9iPiBEaWV0ZXIgQmVsbGVyOyA8YSBocmVmPSJtYWlsdG86Y2NhbXBAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5jY2FtcEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtD Q0FNUF0gTUVMR3MgLSBRJmFtcDtBPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5LaHV6ZW1hLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBsZWFzZSwgc2VlIGluLWxpbmUu PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWdvcjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gS2h1emVtYQ0KIFBpdGhl d2FuIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmtwaXRoZXdhbkBpbmZpbmVyYS5jb20iIHRhcmdl dD0iX2JsYW5rIj5rcGl0aGV3YW5AaW5maW5lcmEuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9i PiBNb25kYXksIEFwcmlsIDE1LCAyMDEzIDEyOjA1IEFNPGJyPg0KPGI+VG86PC9iPiBJZ29yIEJy eXNraW47IFZpc2hudSBQYXZhbiBCZWVyYW08YnI+DQo8Yj5DYzo8L2I+IERpZXRlciBCZWxsZXI7 IDxhIGhyZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNjYW1wQGll dGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0NDQU1QXSBNRUxHcyAtIFEmYW1w O0E8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgSWdvciw8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHVuZGVyc3RhbmQgdGhlIFNSTEcg YW5kIE1FTEcgYmVoYXZpb3IgeW91IGhhdmUgcGVubmVkIC48L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5NeSBjb25jZXJuIHdhcyBsaXR0bGUgZGlmZmVyZW50LiZuYnNwOyBXaXRo IGNoYW5naW5nIHJlc291cmNlIGNvbnN1bXB0aW9uIChiZWNhdXNlIG9mIGR5bmFtaWNpdHkNCiB0 aGUgbmV0d29yayBoYXMpIGluIHRoZSBuZXR3b3JrIGxpbmtzLCBwb3RlbnRpYWwgcGF0aHMgYSBz ZXQgb2YgdmlydHVhbCBsaW5rIGNhbiB0YWtlIHdpbGwgY2hhbmdlIGFuZCBoZW5jZSBpdHMgTUVM RywgYXMgaXQgaXMgdGllZCB0byBhIHJlc291cmNlIGl0IGNhbiB0YWtlLiBTbyB1bmxlc3Mgdmly dHVhbCBsaW5rcyBwYXRocyBhcmUgbmFpbGVkIGRvd24sIGl0IHdvdWxkIGJlIGhhcmQgdG8gY29t cHV0ZSBNRUxHcyBpbiBkaXN0cmlidXRlZCB3YXkuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SUImZ3Q7Jmd0OyBJIHRoaW5rIHlvdSBhcmUgbWlzc2luZyB0aGUgcG9pbnQgaGVy ZS4gVmlydHVhbCBMaW5rIHNlcnZlciBsYXllciBwYXRocyBhcmUgcGlubmVkDQogYXMgZmFyIGFz IGZhdGUgc2hhcmluZyBpcyBjb25jZXJuZWQgKHRoYXQgaXMsIHRoZXkgYXJlIHBpbm5lZCBvbiAm bmJzcDtzZXJ2ZXIgbGF5ZXIgbGluayBsZXZlbCkuIEl0IHdvdWxkIG1ha2UgbGl0dGxlIHNlbnNl IHRvIGFkdmVydGlzZSBWTCBTUkxHcyBpZiB0aGUgU1JMR3MgY29uc3RhbnRseSBjaGFuZ2UuIFRo ZSBzYW1lIGlzIHRydWUgZm9yIE1FTEdzLiAmbmJzcDtTUkxHcy9NRUxHcyBhZHZlcnRpc2VkIGZv ciBWTHMgbm9ybWFsbHkgZG8gbm90IGNoYW5nZToNCiBuZWl0aGVyIG92ZXIgdGltZSBub3Igd2hl biBWTHMgYmVjb21lIGNvbW1pdHRlZC91bmNvbW1pdHRlZC48L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5Bbm90aGVyIHBvaW50IGlzLCB2aXJ0dWFsIGxpbmtzIGNhbiBiZSB2aWV3 ZWQgYXMgb3ZlcnN1YnNjcmlwdGlvbiBvZiByZXNvdXJjZXMgKGluIE1FTEcNCiBjb250ZXh0KS4g VGFraW5nIGFuIGV4YW1wbGUgKGZvciBPVE4sIEkga25vdyBpdCB3b3VsZCB3b3JrIGRpZmZlcmVu dGx5IGZvciBhIFdhdmVsZW5ndGggaW4gV0RNKSwgYSBsaW5rIHJlc291cmNlcyBhcmUgd29ydGgg MSBUQiBvZiBCVywgdXNlciBoYXMgcHJvdmlzaW9uZWQgMjAgdmlydHVhbCBsaW5rcyBvZiAxMDBH IGVhY2ggZ29pbmcgdmlhIHRoYXQgT1ROIGxpbmsuICZuYnNwO1BoeXNpY2FsbHksIG9ubHkgMTAg d2lsbCBnZXQgY29tbWl0dGVkLiBCdXQNCiB3aGljaCAxMD8gSXQgd2lsbCByZWFsbHkgZGVwZW5k IG9uIG5ldHdvcmsgZHluYW1pY3MgYXQgdGhlIHRpbWUgb2YgZGVtYW5kIHRvIGNvbW1pdC4gTUVM R3MgYXJlIG5vdCB0aGF0IGVmZmVjdGl2ZSBoZXJlLiBZb3UgbmVlZCBzb21lIGRpZmZlcmVudCBt ZWNoYW5pc20uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SUImZ3Q7Jmd0OyBB cyBJIG1lbnRpb25lZCBiZWZvcmUgTUVMR3MgaGF2ZSBub3RoaW5nIHRvIGRvIHdpdGggYmFuZHdp ZHRoIGFuZCB3ZXJlIG5ldmVyIGludGVuZGVkDQogdG8gc29sdmUgdGhlIHByb2JsZW1zIHN1Y2gg YXMgeW91IGRlc2NyaWJlIChqdXN0IGxpa2UgaXQgd291bGQgbm90IG1ha2UgbXVjaCBzZW5zZSB0 byBzb2x2ZSBzdWNoIHByb2JsZW0gd2l0aCBTUkxHcyA6PSk8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BZ2Fpbiwg Jm5ic3A7TUVMRyBpcyBhbiBleHRyZW1lIGNhc2UgU1JMRyBkZXNpZ25lZCBleGNsdXNpdmVseSBm b3IgVkxzIChubyBtb3JlIGFuZCBubyBsZXNzKS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5SZWdkczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPktodXplbWE8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IElnb3INCiBCcnlza2luIFs8YSBocmVmPSJtYWlsdG86SUJyeXNraW5AYWR2YW9wdGljYWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOklCcnlza2luQGFkdmFvcHRpY2FsLmNvbTwvYT5dDQo8 YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBBcHJpbCAxMiwgMjAxMyAxMTo1NSBQTTxicj4NCjxi PlRvOjwvYj4gS2h1emVtYSBQaXRoZXdhbjsgVmlzaG51IFBhdmFuIEJlZXJhbTxicj4NCjxiPkNj OjwvYj4gRGlldGVyIEJlbGxlcjsgPGEgaHJlZj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+Y2NhbXBAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBb Q0NBTVBdIE1FTEdzIC0gUSZhbXA7QTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5LaHV6ZW1hLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRo aW5rIGFib3V0IE1FTEcgYXMgYW4gU1JMRyB0aGF0IGlzIHNoYXJlZCBiZXR3ZWVuIHR3byBvciBt b3JlIGxpbmtzIGluIGl0cyBlbnRpcmV0eS4NCiBXaGVuIHR3byByZWFsIGxpbmtzIGhhdmUgYW4g U1JMRyBpbiBjb21tb24sIGl0IG1lYW5zIHRoYXQgdHdvIHJlYWwgbGlua3MgY2FuIGNvLWV4aXN0 IGNvbmN1cnJlbnRseSwgYnV0IHRoZXJlIGlzIHNvbWV0aGluZyAoZS5nLiBjb21tb24gY29uZHVp dCwgbm90ZSB0aGF0IHRoZSBjb25kdWl0IGhhcyByb29tIGZvciBtb3JlIHRoYW4gZm9yIG9uZSBs aW5rKSB0aGF0IHdpbGwgYnJpbmcgYm90aCB0aGVzZSBsaW5rcyBkb3duLCBpZiB0aGlzIHNvbWV0 aGluZw0KIGZhaWxzIChlLmcuIGNvbmR1aXQgaXMgY3V0ICkuIE5vdyBjb25zaWRlciB0aGF0IHRo aXMgc29tZXRoaW5nIG11c3QgYmUgdGFrZW4gaW4gaXRzIGVudGlyZXR5IGJ5IG9uZSBvZiB0aGUg bGlua3MgdG8gYmVjb21lIG9wZXJhdGlvbmFsIC4gSW4gdGhpcyBjYXNlIFNSTEcgYmVjb21lcyBN RUxHLiBOb3RlIHRoYXQgTUVMRyBpcyBvbmx5IG1lYW5pbmdmdWwgZm9yIHZpcnR1YWwgbGlua3Mg KHVubGlrZSBTUkxHIHRoYXQgbWFrZXMgc2Vuc2UgZm9yIGVpdGhlcg0KIHJlYWwgb3IgdmlydHVh bCBsaW5rKS4gV2h5IHdvdWxkIHlvdSBhZHZlcnRpc2UgdHdvIGxpbmtzIHRoYXQgbXV0dWFsbHkg ZXhjbHVkZSBlYWNoIG90aGVyIHJhdGhlciB0aGFuIGFkdmVydGlzaW5nIG9ubHkgb25lIG9mIHRo ZW0gYXQgYSB0aW1lLCB1bmxlc3MgdGhlIHR3byBhcmUgdmlydHVhbCBsaW5rcyBhbmQgaGVuY2Ug Ym90aCBhdmFpbGFibGUgZm9yIHRoZSBjbGllbnQgbGF5ZXIgY29ubmVjdGlvbnM/PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWdvcg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBL aHV6ZW1hDQogUGl0aGV3YW4gWzxhIGhyZWY9Im1haWx0bzprcGl0aGV3YW5AaW5maW5lcmEuY29t IiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOmtwaXRoZXdhbkBpbmZpbmVyYS5jb208L2E+XQ0KPGJy Pg0KPGI+U2VudDo8L2I+IEZyaWRheSwgQXByaWwgMTIsIDIwMTMgMTowMSBQTTxicj4NCjxiPlRv OjwvYj4gSWdvciBCcnlza2luOyBWaXNobnUgUGF2YW4gQmVlcmFtPGJyPg0KPGI+Q2M6PC9iPiBE aWV0ZXIgQmVsbGVyOyA8YSBocmVmPSJtYWlsdG86Y2NhbXBAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5jY2FtcEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtDQ0FNUF0g TUVMR3MgLSBRJmFtcDtBPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkhpIElnb3IsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RG8geW91IG1l YW4sIGlmIHZpcnR1YWwgbGluayBkbyBub3QgaGF2ZSBhbnkgc3BlY2lmaWMgY29uc3RyYWludCwg Zm9yIGV4YW1wbGUgYSBsaW5rDQogaW4gdGhlIHBhdGggKG5vdCB0YWxraW5nIGFib3V0IGVncmVz cyBsaW5rcy9pbnRlcmZhY2VzKSBtdXN0IGJlIHRyYXZlcnNlZCB0byByZWFsaXplIHRoZSB2aXJ0 dWFsIGxpbmssIHRoZXJlIHdvbnQgYmUgYW55IE1FTEcgZm9yIHRoZSB2aXJ0dWFsIGxpbms/PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnZHM8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5LaHV6 ZW1hPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiBJZ29yDQogQnJ5c2tpbiBbPGEgaHJlZj0ibWFpbHRvOklCcnlza2luQGFkdmFvcHRpY2Fs LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpJQnJ5c2tpbkBhZHZhb3B0aWNhbC5jb208L2E+ XQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgQXByaWwgMTIsIDIwMTMgOTo1MiBQTTxicj4N CjxiPlRvOjwvYj4gS2h1emVtYSBQaXRoZXdhbjsgVmlzaG51IFBhdmFuIEJlZXJhbTxicj4NCjxi PkNjOjwvYj4gRGlldGVyIEJlbGxlcjsgPGEgaHJlZj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+Y2NhbXBAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJF OiBbQ0NBTVBdIE1FTEdzIC0gUSZhbXA7QTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5LaHV6ZW1hLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi Pk1FTEdzIGhhdmUgbm90aGluZyB0byBkbyB3aXRoIGJhbmR3aWR0aC4gTUVMRyBpcyBhIGNvbmNy ZXRlIG5ldHdvcmsgcmVzb3VyY2UgaW4gYSBzZXJ2ZXINCiBsYXllciB0aGF0IHR3byBvciBtb3Jl IFZpcnR1YWwgTGlua3MgaW4gYSBjbGllbnQgbGF5ZXIgZGVwZW5kIG9uIGluIGEgbXV0dWFsbHkg ZXhjbHVzaXZlIHdheS4gQW4gZXhhbXBsZSBvZiBNRUxHIGlzIGEgV0RNIGxheWVyIHRyYW5zcG9u ZGVyIHRoYXQgY2FuIHRlcm1pbmF0ZSBlaXRoZXIgb2YgcmVzcGVjdGl2ZSBXRE0gbGF5ZXIgdHVu bmVscyAoYnV0IG5vdCBib3RoIGF0IHRoZSBzYW1lIHRpbWUpIGZvciB0d28gT1ROIGxheWVyIFZp cnR1YWwNCiBMaW5rcy4gSWYgeW91IGFkdmVydGlzZSBhIFZpcnR1YWwgTGluaywgc2F5LCBmb3Ig RXRoZXJuZXQgbGF5ZXIgdGhhdCBkZXBlbmRzIG9uIHRoZSBjb25uZWN0aW9uIGluIE9UTiBsYXll ciBnb2luZyB0aHJvdWdoIG9uZSBvZiB0aGUgbWVudGlvbmVkIE9UTiBsaW5rcywgdGhlIEV0aGVy bmV0IFZMIG11c3QgaW5oZXJpdCB0aGUgTUVMRyBzaW1pbGFybHkgbGlrZSBpdCBkb2VzIFNSTEdz IGFkdmVydGlzZWQgZm9yIHRoZSBPVE4gbGlua3MuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SWdvcjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gS2h1emVtYQ0KIFBpdGhld2FuIFs8 YSBocmVmPSJtYWlsdG86a3BpdGhld2FuQGluZmluZXJhLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1h aWx0bzprcGl0aGV3YW5AaW5maW5lcmEuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlk YXksIEFwcmlsIDEyLCAyMDEzIDEyOjA2IFBNPGJyPg0KPGI+VG86PC9iPiBJZ29yIEJyeXNraW47 IFZpc2hudSBQYXZhbiBCZWVyYW08YnI+DQo8Yj5DYzo8L2I+IERpZXRlciBCZWxsZXI7IDxhIGhy ZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNjYW1wQGlldGYub3Jn PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0NDQU1QXSBNRUxHcyAtIFEmYW1wO0E8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgSWdvciw8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Gb3IgbXVsdGktbGF5ZXIgKG1vcmUgdGhhbiAy KSBuZXR3b3JrLCBjb25zaWRlciBhbGwgdGhlIGxheWVycyBhcmUgbWVzaHkgKHRoYXTigJlzIHdo ZW4NCiB2aXJ0dWFsIGxpbmtzIGFyZSB1c2VmdWwgYW55d2F5KSwgTUVMR3Mgb2YgdmlydHVhbCBs aW5rIHdpbGwgY2hhbmdlIGFzIGFuZCB3aGVuIEJXL3dhdmVsZW5ndGggYXZhaWxhYmlsaXR5IGNo YW5nZXMsIGJlY2F1c2UgcG90ZW50aWFsIHBhdGhzLCBhIHZpcnR1YWwgbGluayBjYW4gdGFrZSB3 aWxsIGNoYW5nZS4gTWFwcGluZyBsb3dlciBsYXllciBNRUxHcyB0byBoaWdoZXIgbGF5ZXIgTUVM R3Mgd29u4oCZdCBiZSBwcmFjdGljYWwgaWYgZG9uZSBpbg0KIGRpc3RyaWJ1dGVkIG1hbm5lciwg c28gaXQgaGFzIHRvIGJlIGNlbnRyYWxpemVkLiBTbyB5b3UgZG8gaGF2ZSBjZW50cmFsIGVsZW1l bnQgaW4gZWFjaCBsYXllciB0aGF0IGtub3dzIGFsbCB0aGUgcmlzayBhbmQgcGF0aHMgKGEgUENF PyksIHdoaWNoIGNhbiBiZSB1dGlsaXplZCBmb3IgbGF5ZXIgc3BlY2lmaWMgcGF0aCBjb21wdXRh dGlvbiAoYXMgaXQgaXMgZG9pbmcgaXQgYW55d2F5KS4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlRoaXMga2luZCBvZiBhcmNoaXRlY3R1cmUgaGFzIGFsbCB0aGUgcGllY2Vz IHRoYXQgYXJlIHJlcXVpcmVkIGZvciBJbnRlci1QQ0UgY29tbXVuaWNhdGlvbg0KIChhY3Jvc3Mg bGF5ZXJzKSwgZXhjZXB0IHRoZSBwcm90b2NvbCB0aGF0IHdvdWxkIGFjdHVhbGx5IG1ha2UgdGhl IDIgUENFcyB0YWxrLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPllvdSBzZWVt IHRvIGJlIGRvaW5nIHNvbWV0aGluZyB0aGF0IHlvdSBkb27igJl0IGxpa2UNCjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2Rp bmdzO2NvbG9yOiMxRjQ5N0QiPko8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5S ZWdhcmRzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+S2h1emVtYTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSWdvcg0KIEJyeXNraW4gWzxhIGhyZWY9Im1h aWx0bzpJQnJ5c2tpbkBhZHZhb3B0aWNhbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86SUJy eXNraW5AYWR2YW9wdGljYWwuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEFw cmlsIDEyLCAyMDEzIDg6MzkgUE08YnI+DQo8Yj5Ubzo8L2I+IEtodXplbWEgUGl0aGV3YW47IFZp c2hudSBQYXZhbiBCZWVyYW08YnI+DQo8Yj5DYzo8L2I+IERpZXRlciBCZWxsZXI7IDxhIGhyZWY9 Im1haWx0bzpjY2FtcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNjYW1wQGlldGYub3JnPC9h Pjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0NDQU1QXSBNRUxHcyAtIFEmYW1wO0E8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+S2h1emVtYSw8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFtIG5vdCBhIGZhbiBvZiBpbnRlci1sYXllciBw YXRoIGNvbXB1dGF0aW9ucyAobm9yIEkgYW0gYSBmYW4gb2YgaW50ZXItUENFIGNvbXB1dGF0aW9u cykuDQogSW4gbXkgbWluZCBwYXRoIGNvbXB1dGF0aW9uIGZvciBhIHNlcnZpY2Ugb3Igc2Vydmlj ZXMgaW4gbGF5ZXIgWCBpcyBwZXJmb3JtZWQgb25seSBpbiBsYXllciBYLCBpLmUuIGNvbnNpZGVy cyBvbmx5IFggbGF5ZXIgbGlua3MgKHJlYWwgb3IgdmlydHVhbCkuIEFzIFBhdmFuIG1lbnRpb25l ZCBTUkxHcyBhbmQgTUVMR3MgdGhhdCBuZWVkIHRvIGJlIGluaGVyaXRlZCBmcm9tIGxvd2VyIGxh eWVycyBzaG91bGQgYmUgdHJhbnNsYXRlZCBpbnRvIFggbGF5ZXINCiBsaW5rIFNSTEdzL01FTEdz IGFuZCBzcGVjaWZpZWQgd2l0aCBYIGxheWVyIHNwZWNpZmljIFNSTEcvTUVMRyBJRHMuPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hlZXJzLDwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklnb3I8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEtodXplbWENCiBQaXRoZXdhbiBbPGEgaHJlZj0ibWFpbHRv OmtwaXRoZXdhbkBpbmZpbmVyYS5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86a3BpdGhld2Fu QGluZmluZXJhLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBBcHJpbCAxMiwg MjAxMyAxMDo1NSBBTTxicj4NCjxiPlRvOjwvYj4gSWdvciBCcnlza2luOyBWaXNobnUgUGF2YW4g QmVlcmFtPGJyPg0KPGI+Q2M6PC9iPiBEaWV0ZXIgQmVsbGVyOyA8YSBocmVmPSJtYWlsdG86Y2Nh bXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5jY2FtcEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUkU6IFtDQ0FNUF0gTUVMR3MgLSBRJmFtcDtBPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIElnb3IsPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+T2suIFRoaXMgd291bGQgYmUgdXNlZnVsIGlmIG5ldHdvcmsgYXJjaGl0 ZWN0dXJlIGlzIGJhc2VkIG9uIGV4dGVybmFsIFBDRSBvciBtZ210IGVudGl0eQ0KIGFzIFBDRSBp biBjbGllbnQgbGF5ZXIsIGJ1dCB0aGVyZSBpcyBubyBjb3VudGVycGFydCBpbiBzZXJ2ZXIgbGF5 ZXIsIG90aGVyd2lzZSBvbmUgY291bGQgaGF2ZSBpbnRlci1QQ0UgY29tbXVuaWNhdGlvbiB0byBh Y2hpZXZlIGRpdmVyc2UgcGF0aCBpbiBzZXJ2ZXIgbGF5ZXIgd2l0aG91dCBnZXR0aW5nIGludG8g dmlydHVhbCBsaW5rIGFuZCBNRUxHIHN0dWZmLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPklzIHRoYXQgY29ycmVjdD88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5LaHV6ZW1hPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiBJZ29yDQogQnJ5c2tpbiBbPGEgaHJlZj0ibWFpbHRvOklCcnlza2luQGFkdmFv cHRpY2FsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpJQnJ5c2tpbkBhZHZhb3B0aWNhbC5j b208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgQXByaWwgMTIsIDIwMTMgNjozNiBQ TTxicj4NCjxiPlRvOjwvYj4gVmlzaG51IFBhdmFuIEJlZXJhbTsgS2h1emVtYSBQaXRoZXdhbjxi cj4NCjxiPkNjOjwvYj4gRGlldGVyIEJlbGxlcjsgPGEgaHJlZj0ibWFpbHRvOmNjYW1wQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+Y2NhbXBAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJFOiBbQ0NBTVBdIE1FTEdzIC0gUSZhbXA7QTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5LaHV6ZW1hLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bi1sZWZ0OjcyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4yLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkZvciBjYXNlcyBvZiBjb25jdXJyZW50IGNvbXB1dGF0aW9uIChjYXNlIzItNSks IHlvdSBhcmUgbWFpbmx5IHRhbGtpbmcgYWJvdXQgZ2xvYmFsIG9wdGltaXphdGlvbiBhbmQgZGl2 ZXJzaXR5IGFtb25nIG11bHRpcGxlIHNlcnZpY2VzLiBZb3UgY2FuIGRvIHRoZSBwYXRoIGNvbXB1 dGF0aW9uLA0KIGJ1dCB0byBhY3R1YWxseSBlbmFjdCB0aGUgY29tcHV0ZWQgcGF0aCB0aGUgc2ln bmFsaW5nIG5lZWRzIHRvIGJlIGRvbmUgZnJvbSB0aGUgc291cmNlIGVuZCBvZiB0aG9zZSBMU1Bz LiZuYnNwOyBTbyB0aGVyZSBpcyBubyBwb2ludCBpbiBkb2luZyBjb25jdXJyZW50IGNvbXB1dGF0 aW9uIGF0IG9uZSBuZXR3b3JrIGVsZW1lbnQgZm9yIHRoZSBzZXJ2aWNlcyBzdGFydGluZyBmcm9t IG11bHRpcGxlIG5ldHdvcmsgZWxlbWVudHMuIEF0IGJlc3QgaXQgbG9va3MNCiB0byBtZSBhIHBy b2JsZW0gdG8gYmUgc29sdmVkIGJ5IG5ldHdvcmsgbWFuYWdlbWVudC9wbGFubmluZyBzb2Z0d2Fy ZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XZWxsLCB3aGVuIGFuIGluZ3Jlc3Mgbm9kZSBpcyBpbml0 aWF0aW5nIGEgc2VydmljZSwgaXQgaXMgZG9pbmcgc28gb24gcmVxdWVzdCBmcm9tIHNvbWUNCiBt YW5hZ2VtZW50IGVudGl0eS4gVGhpcyBtYW5hZ2VtZW50IGVudGl0eSBjYW4gY29tcHV0ZSBwYXRo cyBmb3IgbWFueSBzZXJ2aWNlcyB3aXRoIHNvbWUgZ2xvYmFsIGNyaXRlcmlhIGluIG1pbmQsIGFu ZCB0aGVuIHNwZWNpZnkgdGhlIHJlc3VsdGluZyBwYXRocyBhcyBleHBsaWNpdCBFUk9zIGluIHBy b3Zpc2lvbmluZyByZXF1ZXN0cyBzZW50IHRvIGVhY2ggb2YgdGhlIHNlcnZpY2UgaW5ncmVzc2Vz LiBIb3cgZWxzZSwgZm9yIGV4YW1wbGUsICZuYnNwO3lvdQ0KIGNhbiBzZXQgdXAgc2V2ZXJhbCBz ZXJ2aWNlcyBvcmlnaW5hdGVkIGZyb20gZGlmZmVyZW50IG5vZGVzIHRoYXQgYXJlIGRpc2pvaW50 IGZyb20gZWFjaCBvdGhlcj8gQWxzbywgd2hhdCBpcyB0aGUgcG9pbnQgaW4geW91ciBvcGluaW9u IG9mIHRoZSBzdGF0ZWZ1bGwgUENFIHdvcms/DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5DaGVlcnMsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWdvcjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBWaXNobnUNCiBQYXZhbiBCZWVyYW0gWzxhIGhyZWY9Im1haWx0bzp2aXNobnVwYXZhbkBnbWFp bC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86dmlzaG51cGF2YW5AZ21haWwuY29tPC9hPl0N Cjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEFwcmlsIDEyLCAyMDEzIDg6MDggQU08YnI+DQo8 Yj5Ubzo8L2I+IEtodXplbWEgUGl0aGV3YW48YnI+DQo8Yj5DYzo8L2I+IElnb3IgQnJ5c2tpbjsg RGlldGVyIEJlbGxlcjsgPGEgaHJlZj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+DQpjY2FtcEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtDQ0FN UF0gTUVMR3MgLSBRJmFtcDtBPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+S2h1emVtYSwgSGkhPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NClBsZWFz ZSBzZWUgaW5saW5lLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzEuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ V2hlbiBOZXR3b3JrIGhhcyBtb3JlIHRoYW4gMiBsYXllciBpLmUuIFBhY2tldC1PVE4tRFdETSwg dGhlIFBhY2tldCAoY2xpZW50KSBsYXllciB3aWxsIGJlIHRhbGtpbmcgdG8gaXRzIGltbWVkaWF0 ZSBzZXJ2ZXIgbGF5ZXIgaS5lLiBPVE4sIHdoaWNoIGluIHR1cm4gaXMgdGFsa2luZw0KIHRvIERX RE0gbGF5ZXIuIFVzaW5nIE1FTEcsIGNsaWVudCBsYXllciBwYXRoIGNvbXB1dGF0aW9uIGNhbiB0 YWtlIGNhcmUgb2YgcmVzb3VyY2UgZXhjbHVzaXZpdHkgb2YgdmlydHVhbCBsaW5rIGZvciBpbW1l ZGlhdGUgc2VydmVyIGxheWVyIGkuZS4gT1ROIGxheWVyLiZuYnNwOyBIb3dldmVyIGlmIHRoZXJl IGlzIHJlc291cmNlIGV4Y2x1c2l2aXR5IGF0IERXRE0gbGF5ZXIsIHRoaXMgbWVjaGFuaXNtIGRv ZXNu4oCZdCB3b3JrLiBZb3UgbmVlZCB0byBkbyBsb29zZQ0KIHJvdXRpbmcgb3IgdXNlIGRpc3Ry aWJ1dGVkIFBDRSBtb2RlbDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+W1ZQ Ql0gVGhlIGJlaGF2aW9yIGlzIHRoZSBzYW1lIGFzIHdoYXQgeW91IHdvdWxkIGRvIHdpdGggU1JM R3MgaW4gYSBtdWx0aS1sYXllciBhcmNoaXRlY3R1cmUuIFRoZXJlIGFyZSBhcmNoaXRlY3R1cmVz IHRoYXQgYWxsb3cgdGhlIFNSTEdzIGluIHRoZSBsb3dlc3QgbGF5ZXINCiB0byBiZSBleHBvcnRl ZCBhbGwgdGhlIHdheSB1cCB0byB0aGUgaGlnaGVzdCBsYXllci4gVGhlIGV4cGVjdGF0aW9uIGlz IHRoYXQgTUVMR3Mgd291bGQgYmUgdHJlYXRlZCBpbiB0aGUgc2FtZSB2ZWluLiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4y Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjoj MUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZvciBj YXNlcyBvZiBjb25jdXJyZW50IGNvbXB1dGF0aW9uIChjYXNlIzItNSksIHlvdSBhcmUgbWFpbmx5 IHRhbGtpbmcgYWJvdXQgZ2xvYmFsIG9wdGltaXphdGlvbiBhbmQgZGl2ZXJzaXR5IGFtb25nIG11 bHRpcGxlIHNlcnZpY2VzLiBZb3UgY2FuIGRvIHRoZSBwYXRoIGNvbXB1dGF0aW9uLA0KIGJ1dCB0 byBhY3R1YWxseSBlbmFjdCB0aGUgY29tcHV0ZWQgcGF0aCB0aGUgc2lnbmFsaW5nIG5lZWRzIHRv IGJlIGRvbmUgZnJvbSB0aGUgc291cmNlIGVuZCBvZiB0aG9zZSBMU1BzLiZuYnNwOyBTbyB0aGVy ZSBpcyBubyBwb2ludCBpbiBkb2luZyBjb25jdXJyZW50IGNvbXB1dGF0aW9uIGF0IG9uZSBuZXR3 b3JrIGVsZW1lbnQgZm9yIHRoZSBzZXJ2aWNlcyBzdGFydGluZyBmcm9tIG11bHRpcGxlIG5ldHdv cmsgZWxlbWVudHMuIEF0IGJlc3QgaXQgbG9va3MNCiB0byBtZSBhIHByb2JsZW0gdG8gYmUgc29s dmVkIGJ5IG5ldHdvcmsgbWFuYWdlbWVudC9wbGFubmluZyBzb2Z0d2FyZS48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi PltWUEJdICZuYnNwO0knbSBub3Qgc3VyZSB3aHkgeW91IHRoaW5rIHRoZXJlIGlzIG5vIHBvaW50 IGluIGhhdmluZyBhIGNlbnRyYWxpemVkIGNvbXB1dGF0aW9uIGZ1bmN0aW9uIGNvbXB1dGUgcGF0 aHMgY29uY3VycmVudGx5IGZvciBMU1BzIHdpdGggZGlmZmVyZW50IHNldCBvZiBlbmQtcG9pbnRz Lg0KIEV2ZW4geW91ciBOTVMvcGxhbm5pbmctc29mdHdhcmUgY2FuIGludGVyYWN0IHdpdGggc3Vj aCBjb21wdXRhdGlvbiBlbmdpbmUsIHJldHJpZXZlIGFsbCB0aGUgcGF0aHMgYW5kIHRoZW4gZ28g YWJvdXQgaW5pdGlhdGluZyB0aGUgcGF0aC1zZXR1cCBmcm9tIHRoZSBpbmdyZXNzIG9mIGVhY2gg TFNQLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+LVBhdmFuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxhIGhyZWY9Im1h aWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Y2NhbXAtYm91bmNl c0BpZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5JZ29yIEJyeXNraW48YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTWFy Y2ggMjYsIDIwMTMgNzoxOSBQTTxicj4NCjxiPlRvOjwvYj4gRGlldGVyIEJlbGxlcjsgVmlzaG51 IFBhdmFuIEJlZXJhbTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj48YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPmNjYW1wQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W0NDQU1QXSBNRUxHcyAtIFEmYW1wO0E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkRpZXRlciw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5Zb3Ugc2FpZDo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsmZ3Q7IEkg Z3Vlc3Mgd2UgYXJlIGNvbWluZyBiYWNrIHRvIHRoZSBlc3NlbnRpYWwgcG9pbnQ6ICZxdW90Ozwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPmFuZA0KIGhvdyBvZnRlbiBjb25jdXJyZW50IHBhdGggY29tcHV0YXRpb24gd2lsbCBiZSAm Z3Q7Jmd0OyB1c2VkLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+JnF1b3Q7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+VG8gYmUgaG9uZXN0LCB0aGlzIHN1cnByaXNlcyBtZSBxdWl0ZSBhIGJpdCwg TGV0IG1lIGdpdmUgeW91IHNvbWUgb2YgbWFueSByZWFzb25zIGFzIHRvIHdoeSBjb25jdXJyZW50 IHBhdGggY29tcHV0YXRpb25zIGFyZSBuZWVkZWQgYW5kIHdoeSB0aGlzIGlzIGJldHRlciB0aGFu DQogY29tcHV0aW5nIG9uZSBwYXRoIGF0IGEgdGltZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+MS48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8L3NwYW4+DQo8c3BhbiBsYW5nPSJFTi1VUyI+Q29tcHV0aW5nIHNldmVyYWwgZGl2ZXJz ZSBwYXRocyBmb3IgdGhlIHNhbWUgc2VydmljZSBpbiB0aGUgY29udGV4dCBvZiBzZXJ2aWNlIHJl Y292ZXJ5LiBJIGhvcGUgeW91IHJlYWxpemUgdGhhdCBjb21wdXRpbmcgb25lIHBhdGggYXQgYSB0 aW1lIG9uIG1hbnkgY29uZmlndXJhdGlvbnMgcHJvZHVjZXMgbm8gb3Igc3ViLW9wdGltYWwgcmVz dWx0cy4gSSBhbHNvIGhvcGUgeW91IHJlYWxpemUgdGhlIHByb2JsZW0gb2YNCiBzZWxlY3Rpbmcg dHdvIHBhdGhzIHdpdGggb25lIG9mIHRoZW0gJm5ic3A7aGF2aW5nIGEgbGluayB3aXRoIGNvbW1v biBNRUxHIHdpdGggYSBsaW5rIGZyb20gYW5vdGhlciBwYXRoOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj4yLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bh bj4NCjxzcGFuIGxhbmc9IkVOLVVTIj5Db21wdXRpbmcgcGF0aHMgZm9yIG11bHRpcGxlIHNlcnZp Y2VzIHRvIGJlIHN1ZmZpY2llbnRseSBkaXNqb2ludCBmcm9tIGVhY2ggb3RoZXI7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPjMuPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgPC9zcGFuPg0KPHNwYW4gbGFuZz0iRU4tVVMiPkNvbXB1dGluZyBwYXRocyBmb3IgbXVs dGlwbGUgc2VydmljZXMgdG8gYWNoaWV2ZSBhIGdsb2JhbCBvcHRpbWl6YXRpb24gY3JpdGVyaWEg KGUuZy4gbWluaW1hbCBzdW1tYXJ5IHRvdGFsIGNvc3QpOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwPjxzcGFuIGxhbmc9IkVOLVVTIj40Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4N CjxzcGFuIGxhbmc9IkVOLVVTIj5Db21wdXRpbmcgcGF0aHMgZm9yIG11bHRpcGxlIHNlcnZpY2Vz IGZvciB0aGUgcHVycG9zZSBvZiByZW1vdmluZyB0aGUgYmFuZHdpZHRoIGZyYWdtZW50YXRpb25z OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj41Ljwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4NCjxzcGFuIGxhbmc9IkVOLVVTIj5Db21wdXRpbmcgcGF0 aHMgZm9yIG11bHRpcGxlIHNlcnZpY2VzIHRvIHBsYW4gc2hhcmVkIG1lc2ggcHJvdGVjdGlvbi9y ZXN0b3JhdGlvbiBzY2hlbWVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0i RU4tVVMiPjYuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPg0KPHNwYW4gbGFuZz0iRU4t VVMiPkV0Yy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5BbHNvIHRoaW5rIGFib3V0IHRoaXM6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPjEuPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPC9zcGFuPg0KPHNwYW4gbGFuZz0iRU4tVVMiPklmIGNvbmN1cnJlbnQgcGF0 aCBjb21wdXRhdGlvbiB3YXMgbm90IGltcG9ydGFudCwgd2h5IFBDRVAgaW5jbHVkZXMgdGhlIG1h Y2hpbmVyeSB0byBkbyB0aGF0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9 IkVOLVVTIj4yLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBw dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4NCjxzcGFuIGxhbmc9IkVO LVVTIj5NeSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBzdGF0ZWZ1bGwgUENFIGlzIHRoYXQgaXQgZG9l cyBwcmV0dHkgbXVjaCBub3RoaW5nIGJ1dCBjb25jdXJyZW50IHBhdGggY29tcHV0YXRpb25zPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyI+WW91IGFsc28gc2FpZDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFy Z2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7Jmd0OyBJIHN1cHBvc2Ug dGhhdCBpZiBhIHBjZSBhcHByb2FjaCBpcyB1c2VkLCBpLmUuLCBwYXRoIGNvbXB1dGF0aW9uIGlz IGNlbnRyYWxpemVkIGluY2x1ZGluZyB0aGU8YnI+DQomZ3Q7Jmd0OyBURS1EQiwgTUVMRyByb3V0 aW5nIGV4dGVuc2lvbnMgYXJlIG5vdCBuZWVkZWQgYmVjYXVzZSB0aGUgaW5mb3JtYXRpb24gYWJv dXQgbXV0dWFsPGJyPg0KJmd0OyZndDtleGNsdXNpdmUgVkxzIGNhbiBiZSBrZXB0IGluIHRoZSBj ZW50cmFsIFRFLURCIHdoZW4gVkxzIGFyZSBjb25maWd1cmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkhvdyB0aGlzIGxv Z2ljIGRvZXMgbm90IGFwcGx5IHRvIG90aGVyIGxpbmsgYXR0cmlidXRlcyBzdWNoIGFzIFNSTEdz PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiPldoYXQgaWYgcGF0aCBjb21wdXRhdGlvbiBpcyBub3QgY2VudHJhbGl6ZWQ/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90 dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPklnb3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPg0KPGEgaHJlZj0ibWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5jY2FtcC1ib3VuY2VzQGlldGYub3JnPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1h aWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Y2NhbXAtYm91bmNl c0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkRpZXRlciBCZWxsZXI8YnI+DQo8 Yj5TZW50OjwvYj4gTW9uZGF5LCBNYXJjaCAyNSwgMjAxMyA1OjUyIFBNPGJyPg0KPGI+VG86PC9i PiBWaXNobnUgUGF2YW4gQmVlcmFtPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86Y2Nh bXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5jY2FtcEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtDQ0FNUF0gTUVMR3MgLSBRJmFtcDtBPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaQ0KPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj5QYXZhbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+T24NCjxhIGhyZWY9InRl bDoyNS4wMy4yMDEzJTIwMDciIHRhcmdldD0iX2JsYW5rIj4yNS4wMy4yMDEzIDA3PC9hPjoyOSwg RmF0YWkgWmhhbmcgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5IaSBQYXZhbiw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5JIGFtIG5vdCBzdXJlIGhvdyBtdWNoIFZMIChWaXJ0dWFsIExpbmspIHdpbGwgYmUgdXNl ZCBpbiB0aGUgcHJhY3RpY2FsIGRlcGxveW1lbnQgYW5kDQogaG93IG9mdGVuIGNvbmN1cnJlbnQg cGF0aCBjb21wdXRhdGlvbiB3aWxsIGJlIHVzZWQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGd1ZXNzIHdlIGFyZSBjb21pbmcgYmFjayB0byB0aGUg ZXNzZW50aWFsIHBvaW50OiAmcXVvdDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5hbmQgaG93DQogb2Z0ZW4gY29uY3VycmVudCBw YXRoIGNvbXB1dGF0aW9uIHdpbGwgYmUgdXNlZC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiZx dW90Ozxicj4NCjxicj4NClRoaXMgbWVhbnMgd2UgYXJlIHRyeWluZyB0byBmaWd1cmUgb3V0IHVu ZGVyIHdoaWNoIGNvbmRpdGlvbnMgTUVMRyByb3V0aW5nIGV4dGVuc2lvbnM8YnI+DQpjb3VsZCBi ZSBiZW5lZmljaWFsLjxicj4NCjxicj4NCklNSE8sIHRoZXkgd291bGQgb25seSBtYWtlIHNlbnNl LCBpZjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIGxhbmc9IkVOLVVT Ij5hIHBhdGggY29tcHV0YXRpb24gZnVuY3Rpb24gc3VwcG9ydHMgdGhlIGNhbGN1bGF0aW9uIG9m IGsgc2hvcnRlc3QgcGF0aHMgY29uY3VycmVudGx5PG86cD48L286cD48L3NwYW4+PC9saT48bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIGxhbmc9 IkVOLVVTIj5pZiB0aGVyZSBpcyBvbmx5IGEgc2luZ2xlIHBhdGggY29tcHV0YXRpb24gZnVuY3Rp b24gaW5zdGFuY2UgcGVyIGRvbWFpbiAocGNlIGFwcHJvYWNoKTxicj4NCklmIHBhdGggY29tcHV0 YXRpb24gaXMgZG9uZSBpbiBhIGRpc3RyaWJ1dGVkIGZhc2hpb24gdGhlIGJlbmVmaXQgZ29lcyBh d2F5IGJlY2F1c2U8YnI+DQp0aGUgaW5zdGFuY2VzIGNhbGN1bGF0ZSBwYXRocyBpbmRlcGVuZGVu dGx5ITxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g bGFuZz0iRU4tVVMiPkkgc3VwcG9zZSB0aGF0IGlmIGEgcGNlIGFwcHJvYWNoIGlzIHVzZWQsIGku ZS4sIHBhdGggY29tcHV0YXRpb24gaXMgY2VudHJhbGl6ZWQgaW5jbHVkaW5nIHRoZTxicj4NClRF LURCLCBNRUxHIHJvdXRpbmcgZXh0ZW5zaW9ucyBhcmUgbm90IG5lZWRlZCBiZWNhdXNlIHRoZSBp bmZvcm1hdGlvbiBhYm91dCBtdXR1YWw8YnI+DQpleGNsdXNpdmUgVkxzIGNhbiBiZSBrZXB0IGlu IHRoZSBjZW50cmFsIFRFLURCIHdoZW4gVkxzIGFyZSBjb25maWd1cmVkLjxicj4NCjxicj4NCkhl bmNlLCBpdCBpcyBxdWl0ZSBkb3VidGZ1bCB3aGV0aGVyIE1FTEcgcm91dGluZyBleHRlbnNpb25z IGFyZSByZWFsbHkgdXNlZnVsIHVubGVzcyB0aGVpcjxicj4NCmFwcGxpY2FiaWxpdHkgaXMgYnJv YWRlci48YnI+DQo8YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KRGlldGVyPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQt YWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoIj4NCjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RG8geW91IHRoaW5r IGlmIGl0IG1ha2VzIHNlbnNlIHRvIGFkZCBhIGZsYWcgKGluIHJvdXRpbmcgYWR2ZXJ0aXNlbWVu dCkgdG8gaW5kaWNhdGUgYSBsaW5rIGlzIGEgVkwgb3Igbm90Pzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQt YWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoIj4NCjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87dGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgi Pg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5Omlu dGVyLWlkZW9ncmFwaCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246anVzdGlmeTt0 ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCBSZWdhcmRzPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 dGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPg0KPHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9n cmFwaCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkZhdGFpPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IFZpc2hudQ0KIFBhdmFuIEJlZXJhbSBbPGEgaHJlZj0ibWFpbHRvOnZpc2hudXBhdmFu QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzp2aXNobnVwYXZhbkBnbWFpbC5jb208 L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgTWFyY2ggMjIsIDIwMTMgODo1NyBQTTxi cj4NCjxiPlRvOjwvYj4gRmF0YWkgWmhhbmc8YnI+DQo8Yj5DYzo8L2I+IElnb3IgQnJ5c2tpbjsg PGEgaHJlZj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Y2NhbXBAaWV0 Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQ0NBTVBdIE1FTEdzIC0gUSZhbXA7 QTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+RmF0YWksIEhpITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIj5Hb29kIHRvIHNlZSB0aGF0IHlvdSB1bmRlcnN0YW5kIHRoZSBjb25zdHJ1Y3Qgbm93 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlRo aXMgaXMgbm90IGEgY29ybmVyIGNhc2UuIFRoZSB1dGlsaXR5IG9mIHRoZSBjb25zdHJ1Y3QgYmVj b21lcyBxdWl0ZSBzaWduaWZpY2FudCBpZiB5b3UgaGF2ZSBhbiBhcHBsaWNhdGlvbiB0aGF0IGRv ZXMgY29uY3VycmVudCBwYXRoIGNvbXB1dGF0aW9ucyBvbiBhbiBhYnN0cmFjdA0KIHRvcG9sb2d5 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlJl Z2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+LVBhdmFuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5DQ0FNUCBtYWlsaW5nIGxpc3Q8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Im1h aWx0bzpDQ0FNUEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPkNDQU1QQGlldGYub3JnPC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXA8L2E+PG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+LS0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztmb250LXZhcmlhbnQ6c21hbGwtY2FwcyI+RElFVEVSIEJFTExFUg0KPC9zcGFuPjwv Yj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzY2MzlCNyI+QUxDQVRFTC1MVUNFTlQgREVVVFNDSExBTkQgQUcNCjxi cj4NClBST0pFQ1QgTUFOQUdFUiBBU09OL0dNUExTIENPTlRST0wgUExBTkUgPGJyPg0KQ09SRSBO RVRXT1JLUyBCVVNJTkVTUyBESVZJU0lPTiA8YnI+DQpPUFRJQ1MgQlUsIFNXSVRDSElORyBSJmFt cDtEIDxicj4NCjxicj4NCkxvcmVuenN0cmFzc2UgMTAgPGJyPg0KNzA0MzUgU3R1dHRnYXJ0LCBH ZXJtYW55IDxicj4NClBob25lOiA8YSBocmVmPSJ0ZWw6JTJCNDklMjA3MTElMjA4MjElMjA0MzEy NSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGNsYXNzPSJza3lwZXBuaHByaW50Y29udGFpbmVyMTM2 NjM3NTU5MSI+JiM0Mzs0OSA3MTEgODIxIDQzMTI1PC9zcGFuPjxzcGFuIGNsYXNzPSJza3lwZXBu aG1hcmsiPiBiZWdpbl9vZl90aGVfc2t5cGVfaGlnaGxpZ2h0aW5nPC9zcGFuPjxzcGFuIGNsYXNz PSJza3lwZXBuaGNvbnRhaW5lciI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29y YXRpb246bm9uZSI+PGltZyBib3JkZXI9IjAiIGlkPSJfeDAwMDBfaTEwMjUiIHNyYz0iY2hyb21l LWV4dGVuc2lvbjovL2xpZmJjaWJsbGhrZGhvYWZwamZubGhmcGZnbnBsZGZsL251bWJlcnNfYnV0 dG9uX3NreXBlX2xvZ28ucG5nIj48L3NwYW4+PHNwYW4gY2xhc3M9InNreXBlcG5odGV4dHNwYW4i PiYjNDM7NDkNCiA3MTEgODIxIDQzMTI1PC9zcGFuPjxzcGFuIGNsYXNzPSJza3lwZXBuaGZyZWV0 ZXh0c3BhbiI+IEZSRUUmbmJzcDsgPC9zcGFuPjxzcGFuIGNsYXNzPSJza3lwZXBuaG1hcmsiPmVu ZF9vZl90aGVfc2t5cGVfaGlnaGxpZ2h0aW5nPC9zcGFuPiBiZWdpbl9vZl90aGVfc2t5cGVfaGln aGxpZ2h0aW5nJm5ic3A7PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTrl rovkvZM7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxzcGFuIGxhbmc9IkVOLVVTIj7plJnor6/vvIHm nKrmjIflrprmlofku7blkI3jgII8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0ic2t5cGVw bmhwcmludGNvbnRhaW5lcjEzNjYzNzU1OTEiPiYjNDM7NDkNCiA3MTEgODIxIDQzMTI1PC9zcGFu PjxzcGFuIGNsYXNzPSJza3lwZXBuaG1hcmsiPiBiZWdpbl9vZl90aGVfc2t5cGVfaGlnaGxpZ2h0 aW5nPC9zcGFuPjxzcGFuIGNsYXNzPSJza3lwZXBuaGNvbnRhaW5lciI+Jm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZSI+PGltZyBib3JkZXI9IjAiIGlkPSJfeDAw MDBfaTEwMjYiIHNyYz0iY2hyb21lLWV4dGVuc2lvbjovL2xpZmJjaWJsbGhrZGhvYWZwamZubGhm cGZnbnBsZGZsL251bWJlcnNfYnV0dG9uX3NreXBlX2xvZ28ucG5nIj48L3NwYW4+PHNwYW4gY2xh c3M9InNreXBlcG5odGV4dHNwYW4iPiYjNDM7NDkNCiA3MTEgODIxIDQzMTI1PC9zcGFuPjxzcGFu IGNsYXNzPSJza3lwZXBuaGZyZWV0ZXh0c3BhbiI+IEZSRUUmbmJzcDsgPC9zcGFuPjxzcGFuIGNs YXNzPSJza3lwZXBuaG1hcmsiPmVuZF9vZl90aGVfc2t5cGVfaGlnaGxpZ2h0aW5nPC9zcGFuPiBG UkVFJm5ic3A7IGJlZ2luX29mX3RoZV9za3lwZV9oaWdobGlnaHRpbmcmbmJzcDs8Yj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OuWui+S9kzt0ZXh0LWRlY29yYXRpb246bm9u ZSI+PHNwYW4gbGFuZz0iRU4tVVMiPumUmeivr++8geacquaMh+WumuaWh+S7tuWQjeOAgjwvc3Bh bj48L3NwYW4+PC9iPiYjNDM7NDkNCiA3MTEgODIxIDQzMTI1IEZSRUUmbmJzcDsgPC9hPjxicj4N Ck1vYmlsOiA8YSBocmVmPSJ0ZWw6JTJCNDklMjAxNzUlMjA3MjY2ODc0IiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gY2xhc3M9InNreXBlcG5ocHJpbnRjb250YWluZXIxMzY2Mzc1NTkxIj4mIzQzOzQ5 IDE3NSA3MjY2ODc0PC9zcGFuPjxzcGFuIGNsYXNzPSJza3lwZXBuaG1hcmsiPiBiZWdpbl9vZl90 aGVfc2t5cGVfaGlnaGxpZ2h0aW5nPC9zcGFuPjxzcGFuIGNsYXNzPSJza3lwZXBuaGNvbnRhaW5l ciI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZSI+PGltZyBi b3JkZXI9IjAiIGlkPSJfeDAwMDBfaTEwMjciIHNyYz0iY2hyb21lLWV4dGVuc2lvbjovL2xpZmJj aWJsbGhrZGhvYWZwamZubGhmcGZnbnBsZGZsL251bWJlcnNfYnV0dG9uX3NreXBlX2xvZ28ucG5n Ij48L3NwYW4+PHNwYW4gY2xhc3M9InNreXBlcG5odGV4dHNwYW4iPiYjNDM7NDkNCiAxNzUgNzI2 Njg3NDwvc3Bhbj48c3BhbiBjbGFzcz0ic2t5cGVwbmhmcmVldGV4dHNwYW4iPiBGUkVFJm5ic3A7 IDwvc3Bhbj48c3BhbiBjbGFzcz0ic2t5cGVwbmhtYXJrIj5lbmRfb2ZfdGhlX3NreXBlX2hpZ2hs aWdodGluZzwvc3Bhbj4gYmVnaW5fb2ZfdGhlX3NreXBlX2hpZ2hsaWdodGluZyZuYnNwOzxiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk65a6L5L2TO3RleHQtZGVjb3JhdGlv bjpub25lIj48c3BhbiBsYW5nPSJFTi1VUyI+6ZSZ6K+v77yB5pyq5oyH5a6a5paH5Lu25ZCN44CC PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9InNreXBlcG5ocHJpbnRjb250YWluZXIxMzY2 Mzc1NTkxIj4mIzQzOzQ5DQogMTc1IDcyNjY4NzQ8L3NwYW4+PHNwYW4gY2xhc3M9InNreXBlcG5o bWFyayI+IGJlZ2luX29mX3RoZV9za3lwZV9oaWdobGlnaHRpbmc8L3NwYW4+PHNwYW4gY2xhc3M9 InNreXBlcG5oY29udGFpbmVyIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9InRleHQtZGVjb3Jh dGlvbjpub25lIj48aW1nIGJvcmRlcj0iMCIgaWQ9Il94MDAwMF9pMTAyOCIgc3JjPSJjaHJvbWUt ZXh0ZW5zaW9uOi8vbGlmYmNpYmxsaGtkaG9hZnBqZm5saGZwZmducGxkZmwvbnVtYmVyc19idXR0 b25fc2t5cGVfbG9nby5wbmciPjwvc3Bhbj48c3BhbiBjbGFzcz0ic2t5cGVwbmh0ZXh0c3BhbiI+ JiM0Mzs0OQ0KIDE3NSA3MjY2ODc0PC9zcGFuPjxzcGFuIGNsYXNzPSJza3lwZXBuaGZyZWV0ZXh0 c3BhbiI+IEZSRUUmbmJzcDsgPC9zcGFuPjxzcGFuIGNsYXNzPSJza3lwZXBuaG1hcmsiPmVuZF9v Zl90aGVfc2t5cGVfaGlnaGxpZ2h0aW5nPC9zcGFuPiBGUkVFJm5ic3A7IGJlZ2luX29mX3RoZV9z a3lwZV9oaWdobGlnaHRpbmcmbmJzcDs8Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OuWui+S9kzt0ZXh0LWRlY29yYXRpb246bm9uZSI+PHNwYW4gbGFuZz0iRU4tVVMiPumU meivr++8geacquaMh+WumuaWh+S7tuWQjeOAgjwvc3Bhbj48L3NwYW4+PC9iPiYjNDM7NDkNCiAx NzUgNzI2Njg3NCBGUkVFJm5ic3A7IDwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM2NjM5Qjci PjxhIGhyZWY9Im1haWx0bzpEaWV0ZXIuQmVsbGVyQGFsY2F0ZWwtbHVjZW50LmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPkRpZXRlci5CZWxsZXJAYWxjYXRlbC1sdWNlbnQuY29tPC9hPg0KPC9zcGFuPjwv Yj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QWxjYXRlbC1MdWNlbnQgRGV1dHNjaGxhbmQgQUcNCjxi cj4NCkRvbWljaWxlIG9mIHRoZSBDb21wYW55OiBTdHV0dGdhcnQgwrcgTG9jYWwgQ291cnQgU3R1 dHRnYXJ0IEhSQiA0MDI2IDxicj4NCkNoYWlybWFuIG9mIHRoZSBTdXBlcnZpc29yeSBCb2FyZDog TWljaGFlbCBPcHBlbmhvZmYgPGJyPg0KQm9hcmQgb2YgTWFuYWdlbWVudDogV2lsaGVsbSBEcmVz c2VsaGF1cyAoQ2hhaXJtYW4pIMK3IEhhbnMtSsO2cmcgRGF1YiDCtyBEci4gUmFpbmVyIEZlY2hu ZXIgwrcgQW5kcmVhcyBHZWhlDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F82A4B6D50F9464B8EBA55651F541CF843175FD1SZXEML552MBXchi_-- From zhangfatai@huawei.com Fri Apr 19 18:15:04 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D031621F961B for ; Fri, 19 Apr 2013 18:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.065 X-Spam-Level: X-Spam-Status: No, score=-5.065 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_66=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 W+U6JuadtgRg for ; Fri, 19 Apr 2013 18:14:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2109321F892B for ; Fri, 19 Apr 2013 18:14:42 -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 ASA00433; Sat, 20 Apr 2013 01:14:42 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 20 Apr 2013 02:14:23 +0100 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 20 Apr 2013 02:14:24 +0100 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.222]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.007; Sat, 20 Apr 2013 09:14:21 +0800 From: Fatai Zhang To: Igor Bryskin , Vishnu Pavan Beeram , Khuzema Pithewan , Dieter Beller Thread-Topic: [CCAMP] MELGs - Q&A Thread-Index: AQHOIGPek8R0zdnmbUizkEjN3z7415ivh4owgAA2TQCAATLDIIAAeV3g///IfQCABM8nkIAAfXoAgAELY4CAGovgAIAAD52AgAAQMoCAAB55gIAAA70AgAAP9wCAAASVAIAACsYAgAAXnYCAA8Z+gIAAy+KAgAE80oCAADLWAIAEhDjAgAAUrACAAVyggA== Date: Sat, 20 Apr 2013 01:14:20 +0000 Message-ID: References: <5150C704.2040007@alcatel-lucent.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: multipart/related; boundary="_004_F82A4B6D50F9464B8EBA55651F541CF843175FDFSZXEML552MBXchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] MELGs - Q&A X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 01:15:04 -0000 --_004_F82A4B6D50F9464B8EBA55651F541CF843175FDFSZXEML552MBXchi_ Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF843175FDFSZXEML552MBXchi_" --_000_F82A4B6D50F9464B8EBA55651F541CF843175FDFSZXEML552MBXchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Igor, I have explained to Pavan. The path computation element (centralized PCE for inter-layer or multiple P= CEs through communication) can take care of this issue. In addition, in this case, how you advertise MELGS for this two VT links? = Will you advertise that VL 1 must be exclusive with VL2? That is wrong, bec= ause VL1 and VL2 can be used for the disjoint paths in the client layer. Best Regards Fatai From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 19, 2013 8:22 PM To: Fatai Zhang; Vishnu Pavan Beeram; Khuzema Pithewan; Dieter Beller Cc: ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Fatai, What is Virtual Link? As described in RFC6001, it says as below. So my ques= tion is: when there are two VLs created through Call approach as defined in= RFC6001, one has 3 potential paths in the server layer to setup FA-LSP, an= d another has 2 potential paths in the server layer, and only one of the 3 = &2 has the same resource shared in the server layer. How MELGs can help in this case? IB>> Simple: with MELGs the path computer will know in advance that selecti= ng two paths with a virtual link belonging to path #1 and a virtual link be= longing to path #2 having an MELG in common will be a bad idea, because an = attempt to provision such path combination is guaranteed to fail. Without M= ELGs the path computer won't have such knowledge. Cheers, Igor From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Thursday, April 18, 2013 11:26 PM To: Vishnu Pavan Beeram; Khuzema Pithewan; Igor Bryskin; Dieter Beller Cc: ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Pavan, Igor I think there are some concerns about the applicability of MELGs and I have= the same feeling as Khuzema and Dieter. I still think that MELGS can only handle a very small corner case as you pu= t many cases below where MELGs are not needed. What is Virtual Link? As described in RFC6001, it says as below. So my ques= tion is: when there are two VLs created through Call approach as defined in= RFC6001, one has 3 potential paths in the server layer to setup FA-LSP, an= d another has 2 potential paths in the server layer, and only one of the 3 = &2 has the same resource shared in the server layer. How MELGs can help in this case? =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=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 A virtual TE link is defined as a TE link between two upper-layer nodes tha= t is not associated with a fully provisioned FA-LSP in a lower layer [RFC52= 12]. A virtual TE link is advertised a= s any TE link, following the rules in [RFC4206] defined for fully provisioned TE links. A virtual TE link represe= nts thus the potentiality to set up an FA-LSP in the lower layer to support= the TE link that has been advertised. =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=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 Best Regards Fatai From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of V= ishnu Pavan Beeram Sent: Tuesday, April 16, 2013 10:10 PM To: Khuzema Pithewan Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Khuzema, Hi! MELGs are useful and come into play only when: (1) The server network domain is abstracted and the advertised Virtual TE-l= inks possess some mutual exclusivity relationship. (2) There is a Centralized path computation entity in the client domain (co= mputes paths in terms of Client TE-links/TE-nodes) that is capable of doing= concurrent path computations. If either of the above 2 statements is NOT true, there is no utility for ME= LGs. At the risk of being pedantic: - Are MELGs needed when the server-network domain in not abstracted (no Vir= tual TE links)? The answer is NO. - Are MELGs needed when you have a distributed path-computation architectur= e (Client PCE interacting with Server PCE)? The answer is NO. - Are MELGs needed when the centralized path-computation engine doesn't (ca= n't) do concurrent computations? The answer is NO. The actual procedures involved in abstracting the server network domain is = beyond the scope of . The abstraction procedure itself is impl= ementation-specific (maybe someday someone would put together a draft for d= iscussing this). Though it is true that the primary use-case we had in mind= when coming up with this new construct involves a lambda-layer server netw= ork domain, there is really no restriction (at a conceptual level) on using= this construct when abstracting a packet-layer server network domain or a = TDM-layer server network domain. It is up to the implementation on how to m= ake best use of this construct. When you advertise a Virtual TE-link into a client network domain, you are = doing this based on the existence of some potential underlying server-path.= TE attributes like SRLGs, MELGs, delay etc that get advertised for the Vir= tual TE-link depend on the underlying server-path that is chosen for cateri= ng to this Client TE-link. If the underlying server-path keeps changing (ba= sed on network events), these TE attributes would also keep changing. The p= rocedure for keeping the advertised information "current" is an implementat= ion choice. If there exists such a thing as an abstraction manager (again, this is tota= lly implementation specific), then the assumption is that it does one of th= e following - (a) computes new server-paths for the Virtual TE links whenever there is a = change in the network (may not be very scalable in some architectures), (b) or does periodic path-computation for each Virtual TE link, (c) or uses a policy to pin down the Virtual TE-link to a specific underlyi= ng server-path, (d) or uses a combination of (a), (b), (c). doesn't make any recommendation as to what choice the abstrac= tion manager would need to take. Hope this helps. -Pavan On Tue, Apr 16, 2013 at 7:08 AM, Khuzema Pithewan > wrote: Hi Igor, I am trying to summarize the discussion we had so far. Pls see if my conclu= sion is in sync with the idea of MELG you have MELG is useful when 1. server layer VLs are nailed down for the resources on the server l= ayer links that are shared among multiple VLs. These resources are typicall= y wavelength on a fiber (can it be anything else??). In other words, if 2 V= Ls are pinned to use a particular wavelength on a particular fiber, then th= ese 2 VLs will have MELG for the wavelength. 2. server layer do not have centralized path computation entity which= can be used by client layer to ask for concurrent diverse path computation= within server layer. 3. Client layer has a centralized path computation entity, which woul= d compute paths for client+server layer. 4. The need is to centralized concurrent computation of more than one= client+server layer path that meets some diversity and resource exclusivit= y requirements. Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Monday, April 15, 2013 9:44 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Please, see in-line. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Monday, April 15, 2013 12:05 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, I understand the SRLG and MELG behavior you have penned . My concern was little different. With changing resource consumption (becau= se of dynamicity the network has) in the network links, potential paths a s= et of virtual link can take will change and hence its MELG, as it is tied t= o a resource it can take. So unless virtual links paths are nailed down, it= would be hard to compute MELGs in distributed way. IB>> I think you are missing the point here. Virtual Link server layer path= s are pinned as far as fate sharing is concerned (that is, they are pinned = on server layer link level). It would make little sense to advertise VL SR= LGs if the SRLGs constantly change. The same is true for MELGs. SRLGs/MELG= s advertised for VLs normally do not change: neither over time nor when VLs= become committed/uncommitted. Another point is, virtual links can be viewed as oversubscription of resour= ces (in MELG context). Taking an example (for OTN, I know it would work dif= ferently for a Wavelength in WDM), a link resources are worth 1 TB of BW, u= ser has provisioned 20 virtual links of 100G each going via that OTN link. = Physically, only 10 will get committed. But which 10? It will really depen= d on network dynamics at the time of demand to commit. MELGs are not that e= ffective here. You need some different mechanism. IB>> As I mentioned before MELGs have nothing to do with bandwidth and were= never intended to solve the problems such as you describe (just like it wo= uld not make much sense to solve such problem with SRLGs :=3D) Again, MELG is an extreme case SRLG designed exclusively for VLs (no more = and no less). Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 11:55 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Think about MELG as an SRLG that is shared between two or more links in its= entirety. When two real links have an SRLG in common, it means that two re= al links can co-exist concurrently, but there is something (e.g. common con= duit, note that the conduit has room for more than for one link) that will = bring both these links down, if this something fails (e.g. conduit is cut )= . Now consider that this something must be taken in its entirety by one of = the links to become operational . In this case SRLG becomes MELG. Note that= MELG is only meaningful for virtual links (unlike SRLG that makes sense fo= r either real or virtual link). Why would you advertise two links that mutu= ally exclude each other rather than advertising only one of them at a time,= unless the two are virtual links and hence both available for the client l= ayer connections? Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 1:01 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Do you mean, if virtual link do not have any specific constraint, for examp= le a link in the path (not talking about egress links/interfaces) must be t= raversed to realize the virtual link, there wont be any MELG for the virtua= l link? Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 9:52 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, MELGs have nothing to do with bandwidth. MELG is a concrete network resourc= e in a server layer that two or more Virtual Links in a client layer depend= on in a mutually exclusive way. An example of MELG is a WDM layer transpon= der that can terminate either of respective WDM layer tunnels (but not both= at the same time) for two OTN layer Virtual Links. If you advertise a Virt= ual Link, say, for Ethernet layer that depends on the connection in OTN lay= er going through one of the mentioned OTN links, the Ethernet VL must inher= it the MELG similarly like it does SRLGs advertised for the OTN links. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 12:06 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, For multi-layer (more than 2) network, consider all the layers are meshy (t= hat's when virtual links are useful anyway), MELGs of virtual link will cha= nge as and when BW/wavelength availability changes, because potential paths= , a virtual link can take will change. Mapping lower layer MELGs to higher = layer MELGs won't be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all= the risk and paths (a PCE?), which can be utilized for layer specific path= computation (as it is doing it anyway). This kind of architecture has all the pieces that are required for Inter-PC= E communication (across layers), except the protocol that would actually ma= ke the 2 PCEs talk. You seem to be doing something that you don't like :) Regards Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 8:39 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, I am not a fan of inter-layer path computations (nor I am a fan of inter-PC= E computations). In my mind path computation for a service or services in l= ayer X is performed only in layer X, i.e. considers only X layer links (rea= l or virtual). As Pavan mentioned SRLGs and MELGs that need to be inherited= from lower layers should be translated into X layer link SRLGs/MELGs and s= pecified with X layer specific SRLG/MELG IDs. Cheers, Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 10:55 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Ok. This would be useful if network architecture is based on external PCE o= r mgmt entity as PCE in client layer, but there is no counterpart in server= layer, otherwise one could have inter-PCE communication to achieve diverse= path in server layer without getting into virtual link and MELG stuff. Is that correct? Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 6:36 PM To: Vishnu Pavan Beeram; Khuzema Pithewan Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. Well, when an ingress node is initiating a service, it is doing so on reque= st from some management entity. This management entity can compute paths fo= r many services with some global criteria in mind, and then specify the res= ulting paths as explicit EROs in provisioning requests sent to each of the = service ingresses. How else, for example, you can set up several services = originated from different nodes that are disjoint from each other? Also, wh= at is the point in your opinion of the statefull PCE work? Cheers, Igor From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, April 12, 2013 8:08 AM To: Khuzema Pithewan Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Khuzema, Hi! Please see inline.. 1. When Network has more than 2 layer i.e. Packet-OTN-DWDM, the Pack= et (client) layer will be talking to its immediate server layer i.e. OTN, w= hich in turn is talking to DWDM layer. Using MELG, client layer path comput= ation can take care of resource exclusivity of virtual link for immediate s= erver layer i.e. OTN layer. However if there is resource exclusivity at DW= DM layer, this mechanism doesn't work. You need to do loose routing or use = distributed PCE model [VPB] The behavior is the same as what you would do with SRLGs in a multi-l= ayer architecture. There are architectures that allow the SRLGs in the lowe= st layer to be exported all the way up to the highest layer. The expectatio= n is that MELGs would be treated in the same vein. 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. [VPB] I'm not sure why you think there is no point in having a centralized= computation function compute paths concurrently for LSPs with different se= t of end-points. Even your NMS/planning-software can interact with such com= putation engine, retrieve all the paths and then go about initiating the pa= th-setup from the ingress of each LSP. Regards, -Pavan From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Igor Bryskin Sent: Tuesday, March 26, 2013 7:19 PM To: Dieter Beller; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Dieter, You said: >> I guess we are coming back to the essential point: "and how often concur= rent path computation will be >> used." To be honest, this surprises me quite a bit, Let me give you some of many r= easons as to why concurrent path computations are needed and why this is be= tter than computing one path at a time: 1. Computing several diverse paths for the same service in the context= of service recovery. I hope you realize that computing one path at a time = on many configurations produces no or sub-optimal results. I also hope you = realize the problem of selecting two paths with one of them having a link = with common MELG with a link from another path; 2. Computing paths for multiple services to be sufficiently disjoint f= rom each other; 3. Computing paths for multiple services to achieve a global optimizat= ion criteria (e.g. minimal summary total cost); 4. Computing paths for multiple services for the purpose of removing t= he bandwidth fragmentations; 5. Computing paths for multiple services to plan shared mesh protectio= n/restoration schemes 6. Etc. Also think about this: 1. If concurrent path computation was not important, why PCEP includes= the machinery to do that? 2. My understanding of the statefull PCE is that it does pretty much n= othing but concurrent path computations You also said: >> I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the >> TE-DB, MELG routing extensions are not needed because the information ab= out mutual >>exclusive VLs can be kept in the central TE-DB when VLs are configured. How this logic does not apply to other link attributes such as SRLGs? What if path computation is not centralized? Cheers, Igor From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Dieter Beller Sent: Monday, March 25, 2013 5:52 PM To: Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Hi Pavan, On 25.03.2013 07:29, Fatai Zhang wrote: Hi Pavan, I am not sure how much VL (Virtual Link) will be used in the practical depl= oyment and how often concurrent path computation will be used. I guess we are coming back to the essential point: "and how often concurren= t path computation will be used." This means we are trying to figure out under which conditions MELG routing = extensions could be beneficial. IMHO, they would only make sense, if: * a path computation function supports the calculation of k shortest pa= ths concurrently * if there is only a single path computation function instance per doma= in (pce approach) If path computation is done in a distributed fashion the benefit goes away = because the instances calculate paths independently! I suppose that if a pce approach is used, i.e., path computation is central= ized including the TE-DB, MELG routing extensions are not needed because the information about= mutual exclusive VLs can be kept in the central TE-DB when VLs are configured. Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their applicability is broader. Thanks, Dieter Do you think if it makes sense to add a flag (in routing advertisement) to = indicate a link is a VL or not? Best Regards Fatai From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, March 22, 2013 8:57 PM To: Fatai Zhang Cc: Igor Bryskin; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Fatai, Hi! Good to see that you understand the construct now. This is not a corner case. The utility of the construct becomes quite signi= ficant if you have an application that does concurrent path computations on= an abstract topology. Regards, -Pavan _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp -- DIETER BELLER ALCATEL-LUCENT DEUTSCHLAND AG PROJECT MANAGER ASON/GMPLS CONTROL PLANE CORE NETWORKS BUSINESS DIVISION OPTICS BU, SWITCHING R&D Lorenzstrasse 10 70435 Stuttgart, Germany Phone: +49 711 821 43125 begin_of_the_skype_highlighting [Image removed by = sender.] +49 711 821 43125 FREE end_of_the_skype_highlighting Mobil: +49 175 7266874 begin_of_the_skype_highlighting [Image removed by se= nder.] +49 175 7266874 FREE end_of_the_skype_highlighting Dieter.Beller@alcatel-lucent.com Alcatel-Lucent Deutschland AG Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026 Chairman of the Supervisory Board: Michael Oppenhoff Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe --_000_F82A4B6D50F9464B8EBA55651F541CF843175FDFSZXEML552MBXchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Igor,

 = ;

I have exp= lained to Pavan.

 = ;

The path c= omputation element (centralized PCE for inter-layer or multiple PCEs throug= h communication) can take care of this issue.

 = ;

In additio= n, in this case, how you advertise MELGS for this two VT links?  Will = you advertise that VL 1 must be exclusive with VL2? That is wrong, because VL1 and VL2 can be used for the disjoint paths in the client layer= .

 = ;

 

 

 

 

Best Regards

 

Fatai

 = ;

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 19, 2013 8:22 PM
To: Fatai Zhang; Vishnu Pavan Beeram; Khuzema Pithewan; Dieter Belle= r
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Fatai,

 

What is Virtual Link? As described in RFC6001, it says a= s below. So my question is: when there are two VLs created through Call approach as defined in RFC6001, one has 3 potential paths in the serv= er layer to setup FA-LSP, and another has 2 potential paths in the server l= ayer, and only one of the 3 &2 has the same resource shared in the serv= er layer.

 

How MELGs can help in this case?

 

IB>> Simple: with MELGs the path computer will kno= w in advance that selecting two paths with a virtual link belonging to path #1 and a virtual link belonging to path #2 having an MELG in commo= n will be a bad idea, because an attempt to provision such path combination= is guaranteed to fail. Without MELGs the path computer won’t have su= ch knowledge.

 

Cheers,

Igor

 

 

From: Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Thursday, April 18, 2013 11:26 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan; Igor Bryskin; Dieter Bell= er
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Pavan, = Igor

 

I think th= ere are some concerns about the applicability of MELGs and I have the same = feeling as Khuzema and Dieter.

 

I still th= ink that MELGS can only handle a very small corner case as you put many cas= es below where MELGs are not needed.=

 

What is Vi= rtual Link? As described in RFC6001, it says as below. So my question is: w= hen there are two VLs created through Call approach as defined in RFC6001, one has 3 potential paths in the server layer to setup FA-LSP,= and another has 2 potential paths in the server layer, and only one of the= 3 &2 has the same resource shared in the server layer.

 

How MELGs = can help in this case?

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

A virtual TE link is defined as a TE link between = two upper-layer nodes that is not associated with a fully provisioned FA-LSP in a lower layer [R= FC5212].  A virtual TE link is advertised as any TE link, following the rules in [RFC4206] defined for fully provisioned TE links.  A virtual TE link represents thus the potentiality to set up an FA-LSP in the lower layer to support the TE link that has been advertised.=

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

 

 

 

 

 

Best Regards

 

Fatai

 

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org= ] On Behalf Of Vishnu Pavan Beeram
Sent: Tuesday, April 16, 2013 10:10 PM
To: Khuzema Pithewan
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Khuzema, Hi!<= /p>

 

MELGs are useful and come into = play only when:

(1) The server network domain i= s abstracted and the advertised Virtual TE-links possess some mutual exclus= ivity relationship.

(2) There is a Centralized path= computation entity in the client domain (computes paths in terms of Client= TE-links/TE-nodes) that is capable of doing concurrent path computations.<= o:p>

 

If either of the above 2 statem= ents is NOT true, there is no utility for MELGs. 

At the risk of being pedantic:&= nbsp;

- Are MELGs needed when the ser= ver-network domain in not abstracted (no Virtual TE links)? The answer is N= O.

- Are MELGs needed when you hav= e a distributed path-computation architecture (Client PCE interacting with = Server PCE)? The answer is NO.

- Are MELGs needed when the cen= tralized path-computation engine doesn't (can't) do concurrent computations= ? The answer is NO.

 

The actual procedures involved = in abstracting the server network domain is beyond the scope of <draft-m= elgs>. The abstraction procedure itself is implementation-specific (mayb= e someday someone would put together a draft for discussing this). Though it is true that the primary use-case we had i= n mind when coming up with this new construct involves a lambda-layer serve= r network domain, there is really no restriction (at a conceptual level) on= using this construct when abstracting a packet-layer server network domain or a TDM-layer server network domain.= It is up to the implementation on how to make best use of this construct.&= nbsp;

 

When you advertise a Virtual TE= -link into a client network domain, you are doing this based on the existen= ce of some potential underlying server-path. TE attributes like SRLGs, MELG= s, delay etc that get advertised for the Virtual TE-link depend on the underlying server-path that is chosen fo= r catering to this Client TE-link. If the underlying server-path keeps chan= ging (based on network events), these TE attributes would also keep changin= g. The procedure for keeping the advertised information "current" is an implementation choice.&nb= sp;

 

If there exists such a thing as= an abstraction manager (again, this is totally implementation specific), t= hen the assumption is that it does one of the following - <= /span>

(a) computes new server-paths f= or the Virtual TE links whenever there is a change in the network (may not = be very scalable in some architectures), 

(b) or does periodic path-compu= tation for each Virtual TE link, 

(c) or uses a policy to pin dow= n the Virtual TE-link to a specific underlying server-path, 

(d) or uses a combination of (a= ), (b), (c).

 

<draft-melgs> doesn't mak= e any recommendation as to what choice the abstraction manager would need t= o take.

 

Hope this helps.

-Pavan

=  

On Tue, Apr 16, 2013 at 7:08 AM= , Khuzema Pithewan <kpithewan@infinera.com> wrote:

Hi Igor,

 

I am trying to summarize= the discussion we had so far. Pls see if my conclusion is in sync with the idea of MELG you have

 

MELG is useful when

1.      = ; server layer VLs are naile= d down for the resources on the server layer links that are shared among mu= ltiple VLs. These resources are typically wavelength on a fiber (can it be anything else??). In other words, if 2 VLs are pinned t= o use a particular wavelength on a particular fiber, then these 2 VLs will = have MELG for the wavelength.=

2.      = ; server layer do not have c= entralized path computation entity which can be used by client layer to ask= for concurrent diverse path computation within server layer.

3.      = ; Client layer has a central= ized path computation entity, which would compute paths for client+serv= er layer.

4.      = ; The need is to centralized= concurrent computation of more than one client+server layer path that = meets some diversity and resource exclusivity requirements.

 

Regds

Khuzema

 

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Monday, April 15, 2013 9:44 PM


To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

Please, see in-line.

 

Igor

 

From: Khuzema Pithewan [mailto:kpithewan@infinera.com]
Sent: Monday, April 15, 2013 12:05 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

I understand the SRLG an= d MELG behavior you have penned .

 

My concern was little di= fferent.  With changing resource consumption (because of dynamicity the network has) in the network links, potential paths a set of virtual li= nk can take will change and hence its MELG, as it is tied to a resource it = can take. So unless virtual links paths are nailed down, it would be hard t= o compute MELGs in distributed way.<= /span>

 

IB>> I think you a= re missing the point here. Virtual Link server layer paths are pinned as far as fate sharing is concerned (that is, they are pinned on  ser= ver layer link level). It would make little sense to advertise VL SRLGs if = the SRLGs constantly change. The same is true for MELGs.  SRLGs/MELGs = advertised for VLs normally do not change: neither over time nor when VLs become committed/uncommitted.

 

Another point is, virtua= l links can be viewed as oversubscription of resources (in MELG context). Taking an example (for OTN, I know it would work differently for= a Wavelength in WDM), a link resources are worth 1 TB of BW, user has prov= isioned 20 virtual links of 100G each going via that OTN link.  Physic= ally, only 10 will get committed. But which 10? It will really depend on network dynamics at the time of demand = to commit. MELGs are not that effective here. You need some different mecha= nism.

 

IB>> As I mentione= d before MELGs have nothing to do with bandwidth and were never intended to solve the problems such as you describe (just like it would not make mu= ch sense to solve such problem with SRLGs :=3D)=

Again,  MELG is an = extreme case SRLG designed exclusively for VLs (no more and no less).

 

Regds

Khuzema

 

 

From: Igor Bryskin [mai= lto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 11:55 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

Think about MELG as an S= RLG that is shared between two or more links in its entirety. When two real links have an SRLG in common, it means that two real links c= an co-exist concurrently, but there is something (e.g. common conduit, note= that the conduit has room for more than for one link) that will bring both= these links down, if this something fails (e.g. conduit is cut ). Now consider that this something must be tak= en in its entirety by one of the links to become operational . In this case= SRLG becomes MELG. Note that MELG is only meaningful for virtual links (un= like SRLG that makes sense for either real or virtual link). Why would you advertise two links that mutually exc= lude each other rather than advertising only one of them at a time, unless = the two are virtual links and hence both available for the client layer con= nections?

 

Igor

 

 

From: Khuzema Pithewan [mail= to:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 1:01 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

Do you mean, if virtual = link do not have any specific constraint, for example a link in the path (not talking about egress links/interfaces) must be traversed = to realize the virtual link, there wont be any MELG for the virtual link?

 

Regds

Khuzema

 

From: Igor Bryskin [mai= lto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 9:52 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

MELGs have nothing to do= with bandwidth. MELG is a concrete network resource in a server layer that two or more Virtual Links in a client layer depend on in a mutu= ally exclusive way. An example of MELG is a WDM layer transponder that can = terminate either of respective WDM layer tunnels (but not both at the same = time) for two OTN layer Virtual Links. If you advertise a Virtual Link, say, for Ethernet layer that depen= ds on the connection in OTN layer going through one of the mentioned OTN li= nks, the Ethernet VL must inherit the MELG similarly like it does SRLGs adv= ertised for the OTN links.

 

Igor

 

 

From: Khuzema Pithewan [mail= to:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 12:06 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

For multi-layer (more th= an 2) network, consider all the layers are meshy (that’s when virtual links are useful anyway), MELGs of virtual link will change as and= when BW/wavelength availability changes, because potential paths, a virtua= l link can take will change. Mapping lower layer MELGs to higher layer MELG= s won’t be practical if done in distributed manner, so it has to be centralized. So you do have central el= ement in each layer that knows all the risk and paths (a PCE?), which can b= e utilized for layer specific path computation (as it is doing it anyway).

 

This kind of architectur= e has all the pieces that are required for Inter-PCE communication (across layers), except the protocol that would actually make the 2 PCEs t= alk.

 

You seem to be doing som= ething that you don’t like J

 

Regards

Khuzema

 

From: Igor Bryskin [mai= lto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 8:39 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

I am not a fan of inter-= layer path computations (nor I am a fan of inter-PCE computations). In my mind path computation for a service or services in layer X is perfor= med only in layer X, i.e. considers only X layer links (real or virtual). A= s Pavan mentioned SRLGs and MELGs that need to be inherited from lower laye= rs should be translated into X layer link SRLGs/MELGs and specified with X layer specific SRLG/MELG IDs.=

 

Cheers,

Igor

 

 

From: Khuzema Pithewan [mail= to:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 10:55 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

Ok. This would be useful= if network architecture is based on external PCE or mgmt entity as PCE in client layer, but there is no counterpart in server layer, other= wise one could have inter-PCE communication to achieve diverse path in serv= er layer without getting into virtual link and MELG stuff.

 

Is that correct?<= span lang=3D"EN-US">

 

Khuzema

 

From: Igor Bryskin [mai= lto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 6:36 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

2= . =       For cases of concurrent co= mputation (case#2-5), you are mainly talking about global optimization and = diversity among multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done fro= m the source end of those LSPs.  So there is no point in doing concurr= ent computation at one network element for the services starting from multi= ple network elements. At best it looks to me a problem to be solved by network management/planning software. 

Well, when an ingress no= de is initiating a service, it is doing so on request from some management entity. This management entity can compute paths for many servi= ces with some global criteria in mind, and then specify the resulting paths= as explicit EROs in provisioning requests sent to each of the service ingr= esses. How else, for example,  you can set up several services originated from different nodes that are disjo= int from each other? Also, what is the point in your opinion of the statefu= ll PCE work?

 

Cheers,

Igor

 

From: Vishnu Pavan Beeram [m= ailto:vishnupavan@gmail.com]
Sent: Friday, April 12, 2013 8:08 AM
To: Khuzema Pithewan
Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Khuzema, Hi!


Please see inline..

 

 

 1.    = ;   When Network has more than= 2 layer i.e. Packet-OTN-DWDM, the Packet (client) layer will be talking to= its immediate server layer i.e. OTN, which in turn is talking to DWDM layer. Using MELG, client layer path computation can take care of = resource exclusivity of virtual link for immediate server layer i.e. OTN la= yer.  However if there is resource exclusivity at DWDM layer, this mec= hanism doesn’t work. You need to do loose routing or use distributed PCE model

 

[VPB] The behavior is the same as what you wo= uld do with SRLGs in a multi-layer architecture. There are architectures th= at allow the SRLGs in the lowest layer to be exported all the way up to the highest layer. The expectation is tha= t MELGs would be treated in the same vein. 

2= . =       For cases of concurrent co= mputation (case#2-5), you are mainly talking about global optimization and = diversity among multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done fro= m the source end of those LSPs.  So there is no point in doing concurr= ent computation at one network element for the services starting from multi= ple network elements. At best it looks to me a problem to be solved by network management/planning software. 

[VPB]  I'm not sure why you think there = is no point in having a centralized computation function compute paths conc= urrently for LSPs with different set of end-points. Even your NMS/planning-software can interact with such computation engine,= retrieve all the paths and then go about initiating the path-setup from th= e ingress of each LSP. 

 

Regards,

-Pavan

 

 

 

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Tuesday, March 26, 2013 7:19 PM
To: Dieter Beller; Vishnu Pavan Beeram


Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Dieter,

 

You said:

>> I guess we are coming back to the es= sential point: "and how often concurrent path computation will be >> used."

 

To be honest, this surprises me quite a bit, = Let me give you some of many reasons as to why concurrent path computations= are needed and why this is better than computing one path at a time:

 

1.      Computing several diverse paths for the same service i= n the context of service recovery. I hope you realize that computing one pa= th at a time on many configurations produces no or sub-optimal results. I a= lso hope you realize the problem of selecting two paths with one of them  having a link with common MELG = with a link from another path;

2.      Computing paths for multiple services to be sufficient= ly disjoint from each other;

3.      Computing paths for multiple services to achieve a glo= bal optimization criteria (e.g. minimal summary total cost);

4.      Computing paths for multiple services for the purpose = of removing the bandwidth fragmentations;

5.      Computing paths for multiple services to plan shared m= esh protection/restoration schemes

6.      Etc.

 

Also think about this:

1.      If concurrent path computation was not important, why = PCEP includes the machinery to do that?

2.      My understanding of the statefull PCE is that it does = pretty much nothing but concurrent path computations

 

You also said:

>> I suppose that if a pce approach is used, = i.e., path computation is centralized including the
>> TE-DB, MELG routing extensions are not needed because the informat= ion about mutual
>>exclusive VLs can be kept in the central TE-DB when VLs are configu= red.

How this logic does not apply to other link a= ttributes such as SRLGs?

What if path computation is not centralized?<= o:p>

 

Cheers,

Igor

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Hi Pavan,

On 25.03.2013 07:29, Fat= ai Zhang wrote:

Hi Pavan,

 

I am not sure how much V= L (Virtual Link) will be used in the practical deployment and how often concurrent path computation will be used.

I guess we are coming back to the essential p= oint: "and how often concurrent path computation will be used."

This means we are trying to figure out under which conditions MELG routing = extensions
could be beneficial.

IMHO, they would only make sense, if:

  • a path computation function supports the calculation o= f k shortest paths concurrently
  • if there is only a single path computation function in= stance per domain (pce approach)
    If path computation is done in a distributed fashion the benefit goes away = because
    the instances calculate paths independently!

I suppose that if a pce approach is used, i.e., pat= h computation is centralized including the
TE-DB, MELG routing extensions are not needed because the information about= mutual
exclusive VLs can be kept in the central TE-DB when VLs are configured.

Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their
applicability is broader.


Thanks,
Dieter

 

Do you think if it makes sense to= add a flag (in routing advertisement) to indicate a link is a VL or not?

 

 

 

Best Regards

 

Fatai=

 

From: Vishnu Pavan Beeram [m= ailto:vishnupavan@gmail.com]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Fatai, Hi!

 

Good to see that you understand the construct= now.

 

This is not a corner case. The utility of the= construct becomes quite significant if you have an application that does c= oncurrent path computations on an abstract topology.

 

Regards,

-Pavan

 

_______________________________________________
CCAMP mailing list
CCAMP@iet=
f.org
https://www.ietf.org/mailman/listinfo/ccamp

 

--

DIETER BELLE= R

ALCATEL-LUCENT DEUTSCHLAN= D AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 711 821 43125 begin_of_the_skype_highlighting 3D"Image&#= 43;49 711 821 43125 FREE  end_of_the_skype_highlighting
Mobil: +49 175 7266874 begin_of_the_skype_highlighting 3D"=+49 175 7266874 FREE  = end_of_the_skype_highlighting

 

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe

 

 

--_000_F82A4B6D50F9464B8EBA55651F541CF843175FDFSZXEML552MBXchi_-- --_004_F82A4B6D50F9464B8EBA55651F541CF843175FDFSZXEML552MBXchi_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=823; creation-date="Sat, 20 Apr 2013 01:14:20 GMT"; modification-date="Sat, 20 Apr 2013 01:14:20 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABkAGQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigD//2Q== --_004_F82A4B6D50F9464B8EBA55651F541CF843175FDFSZXEML552MBXchi_-- From Annapoorni.Neelankantan@ecitele.com Mon Apr 22 05:49:53 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08CFA21F8F03 for ; Mon, 22 Apr 2013 05:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] 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 diz9Xu8sC52r for ; Mon, 22 Apr 2013 05:49:49 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.165]) by ietfa.amsl.com (Postfix) with ESMTP id D85B921F8EF7 for ; Mon, 22 Apr 2013 05:49:48 -0700 (PDT) Received: from [85.158.137.99:61336] by server-5.bemta-3.messagelabs.com id 78/B6-30636-AE135715; Mon, 22 Apr 2013 12:49:46 +0000 X-Env-Sender: Annapoorni.Neelankantan@ecitele.com X-Msg-Ref: server-6.tower-217.messagelabs.com!1366634983!13445405!2 X-Originating-IP: [147.234.242.234] X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7083 invoked from network); 22 Apr 2013 12:49:45 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Apr 2013 12:49:45 -0000 X-AuditID: 93eaf2e7-b7f9e6d000007e4b-16-517531c2d6b0 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 1E.A7.32331.2C135715; Mon, 22 Apr 2013 15:49:06 +0300 (IDT) Received: from ILPTWPVEXCA01.ecitele.com (172.31.244.224) by ilptexch01.ecitele.com (172.31.244.40) with Microsoft SMTP Server (TLS) id 8.3.264.0; Mon, 22 Apr 2013 15:49:06 +0300 Received: from ILPTWPVEXMB02.ecitele.com ([fe80::5979:ca8d:419f:56df]) by ILPTWPVEXCA01.ecitele.com ([fe80::ac15:43ab:d541:dfa7%12]) with mapi id 14.02.0328.009; Mon, 22 Apr 2013 15:49:05 +0300 From: Annapoorni Neelankantan To: "hanjianrui@huawei.com" , "imajuku.wataru@lab.ntt.co.jp" , "gregb@grotto-networking.com" , "ylee@huawei.com" , "danli@huawei.com" Thread-Topic: questions regarding [gen-encode] draft Thread-Index: Ac4/V6wl4M41VQ8NQ/id5pkR+WcLiA== Date: Mon, 22 Apr 2013 12:49:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.133.42] Content-Type: multipart/alternative; boundary="_000_D605E34D2A329843B785AC78BDD18EFB1A32613FILPTWPVEXMB02ec_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA41TWUwTURT1zUzbARkzjECfRKWMW1xaW8FQoyVGTcQPAyiJW6IO7aMz2k5L ZzBg/KiJxt1gFI1EY4koCgioaDSuRSWpcU0golETEUWo/rjG3ZkOIIk/vq/z7j3v3HNf7iVx 5qQhlRREGQVEzsPq44m9ve8/mrttJfnW7tH2rkMdhH3rm424/eu1XfhsPKcyGtblbLr5TpdT Xf0Vy8OXB8EsThR9MicjkwtJTgebFxDWcc4y1iS4HKyNNfk9nBN5kSg7WM7vR6KLzY43/XNm KTRBNCHR6XMJotvBLlica7bbp88w29js8WNsGTPjC3hBMiGzlxM8Ji+SJM6NTEpkdTPOX374 lPB3PsJKP4cv6IOguRHbDuJISGfC4OlqoOEU+OB5o347iCcZ+gqAd+qPG7TLeQCbj14kVBZD 3wLwUd1CFevpuXD/ztYYKYneiMGf7eGYFE4XwY6aVlzFw+mp8P7nep2Kk5RyoX07CQ1bYOR6 e8wGQY+Dl96GYpii8+C9u5EYHyiWvtyuxzRNI3zSdaTPNg2rL9/HNZwMe17+0mk4HTZ9eKzX +D54+MY1QtNMhJGDXX0NWOHdc519/BEwfKKDKAcplYNKVA56XjnouRafAkOX3us1PBker4ri /fjO9ZfY4HgIGGpBsuDxy4Vet9VmQU5BRh5kcfq8Z4A2SN0XwLcjY1sATQI2gSrfIeczOm6d VOZtASNIjE2mXk0qyWeGFfpcZTwn8asCJR4ktQBI4mwS9Syq0CkXV7YeBXz9qUXKb+7BU4c6 fcrIivKqDKv1Py+skaoJLsllaLcyqmsR8qNAv+hIkmQhxSgzzyQGkBuVFgke+W8aI+NUTwmK J7PKoSQ/55UEt5a/DTLIK5tfRQF54mxPFDCE6BNRqpH6YlWotErlS8QBtf4N6wVG5U+GU0ZV MEHZvwG9XqUUppQSVqvtS8piDaRSg6DD9nbDfLrYcqyg4WrT79GNu+jHrTVdrLx85fnSA+4U DI/0pJ18U0FvWdPZkN7rzxr1qcqZvy2reIhjQ/qcop7MYsryuqnu3dnCohVZ3/ktE+um187Z ajl9o+1HW8VS/dBpLyakZR67ag4ZeNQeqdq9IDeb13P2ZR+H3Spvizv1ax5LSDxnm4QHJO4P 6cwHiDwEAAA= Cc: Annapoorni Neelankantan , "ccamp@ietf.org" Subject: [CCAMP] questions regarding [gen-encode] draft X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 12:49:53 -0000 --_000_D605E34D2A329843B785AC78BDD18EFB1A32613FILPTWPVEXMB02ec_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Hello Authors, I have few questions regarding the [gen-encode draft] - "draft-ietf-ccamp-ge= neral-constraint-encode-10.txt The mentioned draft has expired on 28 march 2013. But all the WSON specific= documents refer to this document for reference. Is the "draft-ietf-ccamp-general-constraint-encode-10.txt still valid?? Questions pertaining to "draft-ietf-ccamp-general-constraint-encode-10.txt" 1) In Section 2.3.Available Labels Sub-TLV defines priority as 8 bits. However in the example A.5. Priority Flags in Available/Shared Backup Labels sub-TLV Priority is defined as 3 bits. Since there is a mismatch, How many bits should be used to represent priorit= y? 2) In the same example A.5 Priority Flags in Available/Shared Backup La= bels sub-TLV, 7 mentioned as the highest priority. In ASON/Packet world, "= 0" is the highest priority and "7" the lowest. Could you please comment as to whether 0 or 7 constitutes hi= ghest priority ? 3) In section 2.3. Available Labels Sub-TLV The Available Labels sub-TLV link consists of an availability flag, priority flags, and a single variable length label set field as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PRI | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Set Field | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where PRI (Priority Flags, 8 bits): Indicates priority level applied to Label Set Field. Bit 8 corresponds to priority level 0 and bit 15 corresponds to priority level 7. a) What is the use/definition of availability flag ? b) Where should priority be encoded, in the first byte(0-7bits) or (8= -15bits)? Diagram show the first byte whereas the explanation says it as the second byte. 4) In "Available Labels Sub-TLV", assuming Priority is defined by 8 Bit= s - If two bits are set to indicate that available labels for 2 priorities, shou= ld the available labels at each priority be encoded as below? 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 01000001 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Set Field for priority =3D 1 | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Set Field for priority =3D 7 | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5) In the "Label Set" field of Available Label set TLV, what does "Low= est Frequency" signify? Is it the lowest frequency supported by the port for a particular grid and c= hannel spacing ? OR Is it the lowest available frequency i.e the lowest frequency which is not i= n use, at that point in time? In Example A.2 in the draft, For the following frequencies which are available (and not i= n use) Frequency (THz) n Value bit map position -------------------------------------------------- 192.0 -11 0 192.5 -6 5 193.1 0 11 193.9 8 19 194.0 9 20 195.2 21 32 195.8 27 38 Encoding is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | Num Wavelengths =3D 40 | Length =3D 16 bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Grid | C.S. | Reserved | n for lowest frequency =3D -11 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0 0 0 0 1 0| Not used in 40 Channel system (all zeros) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If the available frequencies are: Frequency (THz) n Value bit map position -------------------------------------------------- 193.9 8 19 194.0 9 20 195.2 21 32 195.8 27 38 Will the value of "n" change in the encoding change to "8", OR will it= still remain "-11" ? Will the Encoding change as below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | Num Wavelengths =3D 40 | Length =3D 16 bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Grid | C.S. | Reserved | n for lowest frequency =3D 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0 0 0 0 1 0| Not used in 40 Channel system (all zeros) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thanks Annapoorni 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_D605E34D2A329843B785AC78BDD18EFB1A32613FILPTWPVEXMB02ec_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Hello Authors,

 

I have few questions re= garding the [gen-encode draft] - “draft-ietf-ccamp-general-constraint-= encode-10.txt

 

The mentioned draft has= expired on 28 march 2013. But all the WSON specific documents refer to this= document for reference.

 

Is the “draft-iet= f-ccamp-general-constraint-encode-10.txt still valid??

 

 

Questions pertaining= to “draft-ietf-ccamp-general-constraint-encode-10.txt”

 

1) = ;     In Section 2.3.Available Labels Sub-TLV defines priority as 8 bits.

However in the example

=       A.5. Priority Flags in Available/Shared= Backup Labels sub-TLV

         = ;       Priority is defined as 3 bits.

Since there is a mismatch,= How many bits should be used to represent prio= rity?

 

2) = ;     In the same example A.5 Priority Flags in Available/Shared Backup Labels sub-TLV,

         &nbs= p;      7 mentioned as the highest priority. In ASO= N/Packet world, “0” is the highest priority and “7”= the lowest.

    =             Coul= d you please comment as to whether 0 or 7 constitutes highest priority ?

 

3) = ;     In section 2.3. Available Labels Sub-TLV

 

 
   The Available Labels sub-TLV link consists of an availability flag,<=
o:p>
   priority flags, and a single variable length label set=
 field as
   follows:
 
      0      =
;             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
     +-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+=
;-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;
     |     PRI  &=
nbsp;    |        &nb=
sp;     Reserved      &nbs=
p;            &n=
bsp;     |
     +-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+=
;-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;
     |       =
;            &nb=
sp; Label Set Field         &nb=
sp;            &=
nbsp;    |
     :       =
;            &nb=
sp;            &=
nbsp;            =
;             &n=
bsp;    :
     +-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+=
;-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;
 
 
   Where
 
   PRI (Priority Flags, 8 bits): Indicates priority level=
 applied to
   Label Set Field. Bit 8 corresponds to priority level 0 and bit 15
   corresponds to=
 priority level 7.<=
/o:p>
 

     a)  What is the use/definition of availability flag ?

    =  b) Where should  priority be  encoded, in the first byte(0-7= bits) or (8-15bits)? Diagram show the first byte whereas the

    =    explanation says it as the second byte.

 

4) = ;     In “Available Labels Sub-TLV”, as= suming Priority is defined by 8 Bits –

If two bits are set to indicate that available= labels for 2 priorities, should the available labels at each priority be en= coded as below?

 

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

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

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

  =    | 01000001 = |            &n= bsp; Reserved          &nb= sp;            &= nbsp; |

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

  =    |          &n= bsp;          Label Set Field for p= riority =3D 1          |=

  =    :          &n= bsp;            =             &nbs= p;            &n= bsp;            =   :

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

  =    |          &n= bsp;          Label Set Field for p= riority =3D 7          |=

  =    :          &n= bsp;            =             &nbs= p;            &n= bsp;            =   :

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

 <= /o:p>

 

5) = ;     In the &= #8220;Label Set” field of Available Label set TLV,  what does “Lowest Frequency” signify?

Is it the lowest frequency supported by the po= rt for a particular grid and channel spacing ?

OR

Is it the lowest available frequency i.e the l= owest frequency which is not in use, at that point in time?

 

         = ;       In Example A.2 in the draft,

         = ;       For the following frequencies which ar= e available (and not in use)

     = Frequency (THz)       n Value  &nbs= p;   bit map position

     ------= --------------------------------------------

      192.0  &nbs= p;          -11  &nbs= p;            &n= bsp;  0

     = 192.5           &nbs= p;  -6           = ;       5

     = 193.1           &nbs= p;   0          =        11

     = 193.9           &nbs= p;   8          =        19

     = 194.0           &nbs= p;   9          =        20

     = 195.2           &nbs= p;  21           &nbs= p;     32

     = 195.8           &nbs= p;  27           = ;      38

      Encoding is:

     = 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<= /span>

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

     | = ; 4    | Num Wavelengths =3D 40  |    Len= gth =3D 16 bytes          |

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

     |Grid= |  C.S. |      Reserved   | n  for lowest= frequency =3D -11 |

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

     |1 0 0= 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0|

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

     |1 0 0= 0 0 0 1 0|   Not used in 40 Channel system (all zeros)  = ; |

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

 

    = ;            If the a= vailable frequencies are:

     = Frequency (THz)       n Value  &nbs= p;   bit map position

     ------= --------------------------------------------

     = 193.9           &nbs= p;   8          =        19

     = 194.0           &nbs= p;   9          =        20

     = 195.2           &nbs= p;  21           &nbs= p;     32

     = 195.8           &nbs= p;  27           = ;      38

 

      Will the value of “n” ch= ange in the encoding change to “8”, OR will it still remain R= 20;-11” ?

  &n= bsp;   Will the Encoding change as below:

     = 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<= /span>

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

     | = ; 4    | Num Wavelengths =3D 40  |    Len= gth =3D 16 bytes          |

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

     |Grid= |  C.S. |      Reserved   | n  for lowest= frequency =3D 8 |

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

     |1 0 0= 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0|

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

     |1 0 0= 0 0 0 1 0|   Not used in 40 Channel system (all zeros)  = ; |

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

 

Thanks

Annapoorni

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_D605E34D2A329843B785AC78BDD18EFB1A32613FILPTWPVEXMB02ec_-- From IBryskin@advaoptical.com Mon Apr 22 06:34:50 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF0741F0D1B for ; Mon, 22 Apr 2013 06:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_66=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 0SfIBhZ6tcms for ; Mon, 22 Apr 2013 06:34:47 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id 06CF71F0D1A for ; Mon, 22 Apr 2013 06:34:45 -0700 (PDT) Received: from MUC-SRV-MBX2.advaoptical.com ([172.20.1.96]) by muc-vsrv-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id r3MDYQkf012122 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Apr 2013 15:34:26 +0200 Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MBX2.advaoptical.com (172.20.1.96) with Microsoft SMTP Server (TLS) id 15.0.620.29; Mon, 22 Apr 2013 15:34:25 +0200 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0123.003; Mon, 22 Apr 2013 09:34:23 -0400 From: Igor Bryskin To: Fatai Zhang , Vishnu Pavan Beeram Thread-Topic: [CCAMP] MELGs - Q&A Thread-Index: AQHOIGPeoOQf0fNS1kG7ulofq5GmQJivzRoAgABxTHCAAPkpgIAAeAqAgABMBQCABErLAIABAdYAgAC6NQCAGt0OAIAAD52A///KWjCAAGRRgP//wCBQgABTlAD//73CwAAKM0gAAAY9GCAAdYY0gAAQgVwAADCVHoAABlrDAACAXYgAABcnrgAAFmcDgAB0bnfQ Date: Mon, 22 Apr 2013 13:34:22 +0000 Message-ID: References: <5150C704.2040007@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.21.1.81] Content-Type: multipart/related; boundary="_004_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923A939atlsrvmail10atl_"; type="multipart/alternative" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-04-22_03:2013-04-22, 2013-04-22, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] MELGs - Q&A X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 13:34:51 -0000 --_004_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923A939atlsrvmail10atl_ Content-Type: multipart/alternative; boundary="_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923A939atlsrvmail10atl_" --_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923A939atlsrvmail10atl_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRmF0YWksDQpQbGVhc2UsIHNlZSBteSBjb21tZW50cyBpbiBsaW5lLg0KDQpDaGVlcnMsDQpJ Z29yDQoNCg0KRnJvbTogRmF0YWkgWmhhbmcgW21haWx0bzp6aGFuZ2ZhdGFpQGh1YXdlaS5jb21d DQpTZW50OiBGcmlkYXksIEFwcmlsIDE5LCAyMDEzIDk6MTAgUE0NClRvOiBWaXNobnUgUGF2YW4g QmVlcmFtDQpDYzogS2h1emVtYSBQaXRoZXdhbjsgSWdvciBCcnlza2luOyBEaWV0ZXIgQmVsbGVy OyBjY2FtcEBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtDQ0FNUF0gTUVMR3MgLSBRJkENCg0KSGkg UGF2YW4sDQoNCkluIG15IGV4bXBsZSwgSSBqdXN0IHdhbnQgdG8gc2hvdyB5b3UgdGhhdCB0aGUg bW9yZSBnZW5lcmljIGNhc2UgZm9yIHRoZSBWVEUgbGluayAodG8gaW1wcm92ZSByZXNvdXJjZSB1 c2FnZSBlZmZpY2llbmN5KSwgd2hpY2ggZG9lcyBub3QgYXNzb2NpYXRlIGEgc3BlY2lmaWMgcG90 ZW50aWFsIHBhdGggYXQgdGhlIHRpbWUgb2YgYWR2ZXJ0aXNlbWVudC4gSW4gdGhpcyBnZW5lcmlj IGNhc2UsIE1FTEdzIGRvbuKAmXQgaGVscC4NCg0KUGxlYXNlIHNlZSBtb3JlIGluLWxpbmUgYmVs b3cuDQoNCg0KV2hhdCBpcyBWaXJ0dWFsIExpbms/IEFzIGRlc2NyaWJlZCBpbiBSRkM2MDAxLCBp dCBzYXlzIGFzIGJlbG93LiBTbyBteSBxdWVzdGlvbiBpczogd2hlbiB0aGVyZSBhcmUgdHdvIFZM cyBjcmVhdGVkIHRocm91Z2ggQ2FsbCBhcHByb2FjaCBhcyBkZWZpbmVkIGluIFJGQzYwMDEsIG9u ZSBoYXMgMyBwb3RlbnRpYWwgcGF0aHMgaW4gdGhlIHNlcnZlciBsYXllciB0byBzZXR1cCBGQS1M U1AsIGFuZCBhbm90aGVyIGhhcyAyIHBvdGVudGlhbCBwYXRocyBpbiB0aGUgc2VydmVyIGxheWVy LCBhbmQgb25seSBvbmUgb2YgdGhlIDMgJjIgaGFzIHRoZSBzYW1lIHJlc291cmNlIHNoYXJlZCBp biB0aGUgc2VydmVyIGxheWVyLg0KDQpIb3cgTUVMR3MgY2FuIGhlbHAgaW4gdGhpcyBjYXNlPw0K DQpbVlBCXSBJIHRoaW5rIHRoZSBkaXNjb25uZWN0IGJldHdlZW4gdXMgaGFzIGdvdCB0byBkbyB3 aXRoIGhvdyB0aGUgVmlydHVhbCBURSAoVlRFKSBMaW5rIGdldHMgYWR2ZXJ0aXNlZC4gU2F5LCB0 aGF0IHRoZXJlIGFyZSAzIHBvdGVudGlhbCBwYXRocyBpbiB0aGUgc2VydmVyIGxheWVyIHRoYXQg Y2FuIGNhdGVyIHRvIGEgZ2l2ZW4gVlRFIGxpbmsuIEluIG91ciBub3Rpb24gb2YgdGhlICJWaXJ0 dWFsIFRFIExpbmsiLCBhdCB0aGUgdGltZSBvZiBhZHZlcnRpc2luZyB0aGVyZSBhbHJlYWR5IGV4 aXN0cyBhbiBhc3NvY2lhdGlvbiBiZXR3ZWVuIHRoZSBWVEUgbGluayBhbmQgb25lIG9mIHRoZXNl IDMgcGF0aHMuIFdpdGhvdXQgYXNzb2NpYXRpbmcgeW91ciBWVEUgbGluayB3aXRoIGEgc3BlY2lm aWMgc2VydmVyLXBhdGgsIHlvdSB3b3VsZG4ndCBiZSBhYmxlIHRvIGFjY3VyYXRlbHkgYWR2ZXJ0 aXNlIGF0dHJpYnV0ZXMgbGlrZSBkaXZlcnNpdHksIGRlbGF5LCBtdXR1YWwtZXhjbHVzaXZpdHkg ZXRjLiBJZiBJIHVuZGVyc3Rvb2QgeW91ciBxdWVzdGlvbiBjb3JyZWN0bHksIHlvdXIgbm90aW9u IG9mIGhvdyB0aGUgVmlydHVhbCBURSBMaW5rIGdldHMgYWR2ZXJ0aXNlZCBzZWVtcyB0byBiZSBk aWZmZXJlbnQgLSB5b3UgZG9uJ3QgYXNzb2NpYXRlIHRoZSBWVEUgbGluayB0byBhIHNwZWNpZmlj IHBvdGVudGlhbCBwYXRoIGF0IHRoZSB0aW1lIG9mIGFkdmVydGlzZW1lbnQuDQoNCltGYXRhaV0g UmlnaHQuIFRoZSBWVEUgbGluayBkb2VzIG5vdCBhc3NvY2lhdGUgYSBzcGVjaWZpYyBwb3RlbnRp YWwgcGF0aCBhdCB0aGUgdGltZSBvZiBhZHZlcnRpc2VtZW50LCBpdCBpcyBhIGtpbmQgb2YgcG90 ZW50aWFsaXR5IGZvciB0aGUgVlRFIGFkdmVydGlzZWQgYXMgZGVmaW5lZCBpbiBSRkM2MDAxLiBJ biB0aGlzIGNhc2UsIHBhdGggY29tcHV0YXRpb24gZWxlbWVudCAoZS5nLCBjZW50cmFsaXplZCBQ Q0UgZm9yIGludGVyLWxheWVyKSBjYW4gYmUgYXdhcmUgb2YgdGhlIGxpbmsgaW5mb3JtYXRpb24s IGluY2x1ZGluZyBsaW5rIGJhbmR3aWR0aCwgU1JMR+KApi4uDQoNCklCPj4gV2XigJl2ZSBuZXZl ciBzYWlkIHRoYXQgb3VyIHdvcmsgaXMgbGltaXRlZCB0byB3aGF0IGlzIGRlZmluZWQgb3IgcHJl c2NyaWJlZCBieSBSRkM2MDAxLiBJbiBwYXJ0aWN1bGFyLCBhY2NvcmRpbmcgdG8gb3VyIFZMIHN0 b3J5LCB3aGVuIGEgVkwgaXMgYWR2ZXJ0aXNlZCwgdGhpcyBpcyBhYm91dCBtdWNoIG1vcmUgdGhh biBhZHZlcnRpc2luZyDigJxhIGtpbmQgb2YgcG90ZW50aWFsaXR54oCdLiBOb3Qgb25seSBhIHBv dGVudGlhbCBwYXRoIGluIHRoZSBzZXJ2ZXIgbGF5ZXIgaXMgc2VsZWN0ZWQgYW5kIHBpbm5lZCAo YXQgbGVhc3QgYXMgZmFyIGFzIHRoZSBsaW5rIGZhdGUgc2hhcmluZyBpcyBjb25jZXJuZWQpLCBh IHN0YXRlIGlzIGNyZWF0ZWQgYXQgZXZlcnkgc2VydmVyIGxheWVyIGxpbmsgdGhlIHNlbGVjdGVk IHBhdGggaXMgZ29pbmcgdGhyb3VnaC4gVGhlIHNhaWQgc3RhdGUgYWxsb3dzIGZvciBzaGFyaW5n IHRoZSBsaW5rIHJlc291cmNlIGFtb25nIFZMcywgYnV0IG1ha2VzIHJlc291cmNlIHVuYXZhaWxh YmxlIGZvciBhbnl0aGluZyBlbHNlIGFuZCBwcmV2ZW50cyB0aGUgcmVzb3VyY2UgZnJvbSBiZWlu ZyBkZS1wcm92aXNpb25lZC4gSW4gb3VyIG9waW5pb24sIHRoaXMgaXMgdGhlIG9ubHkgd2F5IHRv IHByZXZlbnQgdGhlIGZvbGxvd2luZyBzaXR1YXRpb25zIHRvIGhhcHBlbiBhZnRlciB0aGUgVkwg aXMgYWR2ZXJ0aXNlZDoNCg0KYSkgICAgICBTb21lIExTUCwgdW5yZWxhdGVkIHRvIFZMLCBhbGxv Y2F0ZXMgYW5kIHN0YXJ0cyB1c2luZyB0aGUgcmVzb3VyY2UgdGhlIFZMIGRlcGVuZHMgdXBvbjsN Cg0KYikgICAgICBUaGUgb3BlcmF0b3IgKGNvbnNjaW91c2x5IG9yIG90aGVyd2lzZSkgZGUtcHJv dmlzaW9ucyB0aGUgcmVzb3VyY2UuDQpCZXNpZGVzLCBob3cgZWxzZSBvbmUgY2FuIGFkdmVydGlz ZSB0aGUgVkzigJlzIFNSTEdzLCBpZiBvbmUgaGFzIG5vIGNsdWUgYXMgdG8gd2hhdCBzZXJ2ZXIg bGF5ZXIgcGF0aCB0aGUgVkwgd2lsbCBlbmQgdXAgdGFraW5nIHdoZW4gaXMgY29tbWl0dGVkPw0K DQoNCkNvbnRpbnVpbmcgd2l0aCB5b3VyIGV4YW1wbGUgLSBJZiB0aGUgcGF0aCB0aGF0IGdldHMg YXNzb2NpYXRlZCB3aXRoIFZURS1MaW5rLTEgYW5kIHRoZSBwYXRoIHRoYXQgZ2V0cyBhc3NvY2lh dGVkIHdpdGggVlRFLUxpbmstMiBkZXBlbmQgb24gdGhlIHNhbWUgcmVzb3VyY2UsICJNRUxHcyIg d291bGQgbWFrZSBzdXJlIHRoYXQgdGhlIGNsaWVudCBjb21wdXRhdGlvbiBmdW5jdGlvbiBpcyBh d2FyZSBvZiB0aGUgZXhpc3RlbmNlIG9mIHN1Y2ggIm11dHVhbCBleGNsdXNpdml0eSIgcmVsYXRp b25zaGlwLg0KDQpbRmF0YWldIFRoZSBwYXRoIGNvbXB1dGF0aW9uIGVsZW1lbnQgKGNlbnRyYWxp emVkIFBDRSBmb3IgaW50ZXItbGF5ZXIgb3IgbXVsdGlwbGUgUENFcyB0aHJvdWdoIGNvbW11bmlj YXRpb24pIGNhbiB0YWtlIGNhcmUgb2YgdGhpcyBpc3N1ZSB0byBhdm9pZCB0aGlzIGhhcHBlbiB3 aXRob3V0IE1FTEcgaW50cm9kdWNlZC4NCg0KSUI+PiBJTU8gaW50ZXItbGF5ZXIgcGF0aCBjb21w dXRhdGlvbiBpcyBvbmUgb2YgdGhvc2UgdGhpbmdzIHBlb3BsZSB0YWxrIGZvciBtYW55IHllYXJz ICg3KyA/KSwgYnV0IHdoaWNoIG5ldmVyIHNlZXMgYW55IHByb2R1Y3Rpb24gbmV0d29yayBkZXBs b3ltZW50IGZvciBhIHNpbXBsZSByZWFzb246IGl0IGlzIG9ubHkgZ29vZCBmb3IgYSBjYXJlZnVs bHkgb3JjaGVzdHJhdGVkIGRlbW8sIGJ1dCBpcyBub3QgZ29vZCBlbm91Z2ggdG8gc29sdmUgYW55 IHJlYWwgbmV0d29yayBwcm9ibGVtLiBPbmUgYmlnIHByb2JsZW0gd2l0aCB0aGUgaW50ZXItbGF5 ZXIgcGF0aCBjb21wdXRhdGlvbiBpcyB0aGF0IGl0IGltcGxpZXMgKnJlLWRlZmluaW5nIGNsaWVu dCBsYXllciB0b3BvbG9neSBkdXJpbmcgYSBjbGllbnQgbGF5ZXIgcGF0aCBjb21wdXRhdGlvbiwg aS5lLiBiYXNlZCBvbiBhIHNpbmdsZSBwYXRoIGNvbXB1dGF0aW9uIHJlcXVlc3QqLiBBIHJlYWwg bGlmZSBhbmFsb2d5IG9mIHRoaXMgcGFyYWRpZ20gd291bGQgYmUgc29tZXRoaW5nIGxpa2UgdGhp cy4gSW1hZ2luZSwgRmF0YWksIHlvdSBhcnJpdmUgdG8gdGhlIEJlaWppbmcgYWlycG9ydCBhbmQg c2F5OiDigJxJIG5lZWQgdG8gZmx5IHRvIFdhc2hpbmd0b24gREPigJ0sIGFuZCB5b3UgaGVhciBi YWNrOiDigJxNci4gWmhhbmcsIEFsbCBmbGlnaHRzIHRvIFdhc2hpbmd0b24gYXJlIGJvb2tlZCwg aG93ZXZlciwgSSBjYW4gc2VlIHRoYXQgd2UgaGF2ZSBhIHNwYXJlIHBsYW5lIGF2YWlsYWJsZSwg c28gSeKAmXZlIGp1c3QgY3JlYXRlZCBmb3IgeW91IGEgZmxpZ2h0IEFpckNoaW5hIFhZWiB3aGlj aCB3aWxsIGdvIG5vbi1zdG9wIHRvIFdhc2hpbmd0b24uIFdlIHdpbGwgc3RhcnQgYm9hcmRpbmcg c2hvcnRseS4gSG9wZWZ1bGx5IG90aGVyIHNldmVyYWwgaHVuZHJlZCBwYXNzZW5nZXJzICB3aWxs ICBzaG93IHVwLiBJZiBub3QsIGRvbuKAmXQgd29ycnksIHdlIHdpbGwgZmx5IHlvdSBhbG9uZS4g VGhhbmsgeW91IGZvciBjaG9vc2luZyBBaXIgQ2hpbmHigJ0uIEFzIHlvdSBrbm93LCB0aGluZ3Mg ZG8gbm90IHdvcmsgdGhpcyB3YXk6IEFpciBDaGluYSBwcmUtcGxhbnMgaXRzIGZsaWdodHMgdmVy eSBjYXJlZnVsbHksIGJhc2VkIG9uIGZhciBtb3JlIGRhdGEgdGhhbiBNci5aaGFuZ+KAmXMgcmVx dWVzdCBhbmQgaW4gYSBkaWZmZXJlbnQgdGltZSBmcmFtZSAobG9uZyBiZWZvcmUgaXQgc3RhcnRz IGZseWluZyBwZW9wbGUpLiBUaGlzIHByZS1wbGFubmluZyBtYXkgcHJvdmUsIGZvciBleGFtcGxl LCB0aGF0IGluc3RlYWQgb2YgY3JlYXRpbmcgYSBub24tc3RvcCBmbGlnaHQgdG8gV2FzaGluZ3Rv biwgaXQgaXMgYmV0dGVyIGVjb25vbWljcy13aXNlIHRvIGNyZWF0ZSB0d28gZmxpZ2h0czogQmVp amluZy1Mb25kb24gYW5kIExvbmRvbi1XYXNoaW5ndG9uLiBJbiB0aGUgY29udGV4dCBvZiB0aGlz IGFuYWxvZ3ksIFZMcyBhcmUgZmxpZ2h0cyB0aGF0IGRvIG5vdCBoYXZlIGNvbW1pdHRlZCBwbGFu ZXMsIGluc3RlYWQsIHRoZXJlIGlzIGEgcG9vbCBvZiBwbGFuZXMgdGhhdCBpcyBzaGFyZWQgYmV0 d2VlbiBhIGdyb3VwIG9mIGZsaWdodHMuIEluIGFsbCBvdGhlciByZXNwZWN0cyB0aGUg4oCcdmly dHVhbOKAnSBmbGlnaHRzIGFyZSBubyBkaWZmZXJlbnQgZnJvbSB0aGUg4oCccmVhbOKAnSBmbGln aHRzLCBpbiBwYXJ0aWN1bGFyLCB0aGV5IGFyZSBzdWJqZWN0IGZvciB0aGUgc2FtZSB0ZWRpb3Vz IHBsYW5uaW5nIHByb2Nlc3MsIGhlbmNlIGl0IGlzIGJldHRlciB0byB1c2UgdGhlc2UgdmlydHVh bCBmbGlnaHRzIHRoYW4gdG8gY3JlYXRlIGZsaWdodHMgb24gdGhlIGZseSA6PSkNCg0KSWdvcg0K DQoNCg0KDQpCUiwNCi1QYXZhbg0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KQSB2aXJ0dWFsIFRFIGxpbmsgaXMgZGVmaW5lZCBhcyBhIFRF IGxpbmsgYmV0d2VlbiB0d28gdXBwZXItbGF5ZXIgbm9kZXMgdGhhdCBpcyBub3QgYXNzb2NpYXRl ZCB3aXRoIGEgZnVsbHkgcHJvdmlzaW9uZWQgRkEtTFNQIGluIGEgbG93ZXIgbGF5ZXIgW1JGQzUy MTI8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTIxMj5dLiAgQSB2aXJ0dWFsIFRFIGxp bmsgaXMgYWR2ZXJ0aXNlZCBhcyBhbnkgVEUgbGluaywgZm9sbG93aW5nIHRoZSBydWxlcyBpbiBb UkZDNDIwNjxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0MjA2Pl0gZGVmaW5lZCBmb3Ig ZnVsbHkgcHJvdmlzaW9uZWQgVEUgbGlua3MuICBBIHZpcnR1YWwgVEUgbGluayByZXByZXNlbnRz IHRodXMgdGhlIHBvdGVudGlhbGl0eSB0byBzZXQgdXAgYW4gRkEtTFNQIGluIHRoZSBsb3dlciBs YXllciB0byBzdXBwb3J0IHRoZSBURSBsaW5rIHRoYXQgaGFzIGJlZW4gYWR2ZXJ0aXNlZC4NCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQpCZXN0 IFJlZ2FyZHMNCg0KRmF0YWkNCg0KRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 Y2NhbXAtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFZpc2hudSBQYXZhbiBC ZWVyYW0NClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDE2LCAyMDEzIDEwOjEwIFBNDQpUbzogS2h1emVt YSBQaXRoZXdhbg0KDQpDYzogY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPg0K U3ViamVjdDogUmU6IFtDQ0FNUF0gTUVMR3MgLSBRJkENCg0KS2h1emVtYSwgSGkhDQoNCk1FTEdz IGFyZSB1c2VmdWwgYW5kIGNvbWUgaW50byBwbGF5IG9ubHkgd2hlbjoNCigxKSBUaGUgc2VydmVy IG5ldHdvcmsgZG9tYWluIGlzIGFic3RyYWN0ZWQgYW5kIHRoZSBhZHZlcnRpc2VkIFZpcnR1YWwg VEUtbGlua3MgcG9zc2VzcyBzb21lIG11dHVhbCBleGNsdXNpdml0eSByZWxhdGlvbnNoaXAuDQoo MikgVGhlcmUgaXMgYSBDZW50cmFsaXplZCBwYXRoIGNvbXB1dGF0aW9uIGVudGl0eSBpbiB0aGUg Y2xpZW50IGRvbWFpbiAoY29tcHV0ZXMgcGF0aHMgaW4gdGVybXMgb2YgQ2xpZW50IFRFLWxpbmtz L1RFLW5vZGVzKSB0aGF0IGlzIGNhcGFibGUgb2YgZG9pbmcgY29uY3VycmVudCBwYXRoIGNvbXB1 dGF0aW9ucy4NCg0KSWYgZWl0aGVyIG9mIHRoZSBhYm92ZSAyIHN0YXRlbWVudHMgaXMgTk9UIHRy dWUsIHRoZXJlIGlzIG5vIHV0aWxpdHkgZm9yIE1FTEdzLg0KQXQgdGhlIHJpc2sgb2YgYmVpbmcg cGVkYW50aWM6DQotIEFyZSBNRUxHcyBuZWVkZWQgd2hlbiB0aGUgc2VydmVyLW5ldHdvcmsgZG9t YWluIGluIG5vdCBhYnN0cmFjdGVkIChubyBWaXJ0dWFsIFRFIGxpbmtzKT8gVGhlIGFuc3dlciBp cyBOTy4NCi0gQXJlIE1FTEdzIG5lZWRlZCB3aGVuIHlvdSBoYXZlIGEgZGlzdHJpYnV0ZWQgcGF0 aC1jb21wdXRhdGlvbiBhcmNoaXRlY3R1cmUgKENsaWVudCBQQ0UgaW50ZXJhY3Rpbmcgd2l0aCBT ZXJ2ZXIgUENFKT8gVGhlIGFuc3dlciBpcyBOTy4NCi0gQXJlIE1FTEdzIG5lZWRlZCB3aGVuIHRo ZSBjZW50cmFsaXplZCBwYXRoLWNvbXB1dGF0aW9uIGVuZ2luZSBkb2Vzbid0IChjYW4ndCkgZG8g Y29uY3VycmVudCBjb21wdXRhdGlvbnM/IFRoZSBhbnN3ZXIgaXMgTk8uDQoNClRoZSBhY3R1YWwg cHJvY2VkdXJlcyBpbnZvbHZlZCBpbiBhYnN0cmFjdGluZyB0aGUgc2VydmVyIG5ldHdvcmsgZG9t YWluIGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgPGRyYWZ0LW1lbGdzPi4gVGhlIGFic3RyYWN0aW9u IHByb2NlZHVyZSBpdHNlbGYgaXMgaW1wbGVtZW50YXRpb24tc3BlY2lmaWMgKG1heWJlIHNvbWVk YXkgc29tZW9uZSB3b3VsZCBwdXQgdG9nZXRoZXIgYSBkcmFmdCBmb3IgZGlzY3Vzc2luZyB0aGlz KS4gVGhvdWdoIGl0IGlzIHRydWUgdGhhdCB0aGUgcHJpbWFyeSB1c2UtY2FzZSB3ZSBoYWQgaW4g bWluZCB3aGVuIGNvbWluZyB1cCB3aXRoIHRoaXMgbmV3IGNvbnN0cnVjdCBpbnZvbHZlcyBhIGxh bWJkYS1sYXllciBzZXJ2ZXIgbmV0d29yayBkb21haW4sIHRoZXJlIGlzIHJlYWxseSBubyByZXN0 cmljdGlvbiAoYXQgYSBjb25jZXB0dWFsIGxldmVsKSBvbiB1c2luZyB0aGlzIGNvbnN0cnVjdCB3 aGVuIGFic3RyYWN0aW5nIGEgcGFja2V0LWxheWVyIHNlcnZlciBuZXR3b3JrIGRvbWFpbiBvciBh IFRETS1sYXllciBzZXJ2ZXIgbmV0d29yayBkb21haW4uIEl0IGlzIHVwIHRvIHRoZSBpbXBsZW1l bnRhdGlvbiBvbiBob3cgdG8gbWFrZSBiZXN0IHVzZSBvZiB0aGlzIGNvbnN0cnVjdC4NCg0KV2hl biB5b3UgYWR2ZXJ0aXNlIGEgVmlydHVhbCBURS1saW5rIGludG8gYSBjbGllbnQgbmV0d29yayBk b21haW4sIHlvdSBhcmUgZG9pbmcgdGhpcyBiYXNlZCBvbiB0aGUgZXhpc3RlbmNlIG9mIHNvbWUg cG90ZW50aWFsIHVuZGVybHlpbmcgc2VydmVyLXBhdGguIFRFIGF0dHJpYnV0ZXMgbGlrZSBTUkxH cywgTUVMR3MsIGRlbGF5IGV0YyB0aGF0IGdldCBhZHZlcnRpc2VkIGZvciB0aGUgVmlydHVhbCBU RS1saW5rIGRlcGVuZCBvbiB0aGUgdW5kZXJseWluZyBzZXJ2ZXItcGF0aCB0aGF0IGlzIGNob3Nl biBmb3IgY2F0ZXJpbmcgdG8gdGhpcyBDbGllbnQgVEUtbGluay4gSWYgdGhlIHVuZGVybHlpbmcg c2VydmVyLXBhdGgga2VlcHMgY2hhbmdpbmcgKGJhc2VkIG9uIG5ldHdvcmsgZXZlbnRzKSwgdGhl c2UgVEUgYXR0cmlidXRlcyB3b3VsZCBhbHNvIGtlZXAgY2hhbmdpbmcuIFRoZSBwcm9jZWR1cmUg Zm9yIGtlZXBpbmcgdGhlIGFkdmVydGlzZWQgaW5mb3JtYXRpb24gImN1cnJlbnQiIGlzIGFuIGlt cGxlbWVudGF0aW9uIGNob2ljZS4NCg0KSWYgdGhlcmUgZXhpc3RzIHN1Y2ggYSB0aGluZyBhcyBh biBhYnN0cmFjdGlvbiBtYW5hZ2VyIChhZ2FpbiwgdGhpcyBpcyB0b3RhbGx5IGltcGxlbWVudGF0 aW9uIHNwZWNpZmljKSwgdGhlbiB0aGUgYXNzdW1wdGlvbiBpcyB0aGF0IGl0IGRvZXMgb25lIG9m IHRoZSBmb2xsb3dpbmcgLQ0KKGEpIGNvbXB1dGVzIG5ldyBzZXJ2ZXItcGF0aHMgZm9yIHRoZSBW aXJ0dWFsIFRFIGxpbmtzIHdoZW5ldmVyIHRoZXJlIGlzIGEgY2hhbmdlIGluIHRoZSBuZXR3b3Jr IChtYXkgbm90IGJlIHZlcnkgc2NhbGFibGUgaW4gc29tZSBhcmNoaXRlY3R1cmVzKSwNCihiKSBv ciBkb2VzIHBlcmlvZGljIHBhdGgtY29tcHV0YXRpb24gZm9yIGVhY2ggVmlydHVhbCBURSBsaW5r LA0KKGMpIG9yIHVzZXMgYSBwb2xpY3kgdG8gcGluIGRvd24gdGhlIFZpcnR1YWwgVEUtbGluayB0 byBhIHNwZWNpZmljIHVuZGVybHlpbmcgc2VydmVyLXBhdGgsDQooZCkgb3IgdXNlcyBhIGNvbWJp bmF0aW9uIG9mIChhKSwgKGIpLCAoYykuDQoNCjxkcmFmdC1tZWxncz4gZG9lc24ndCBtYWtlIGFu eSByZWNvbW1lbmRhdGlvbiBhcyB0byB3aGF0IGNob2ljZSB0aGUgYWJzdHJhY3Rpb24gbWFuYWdl ciB3b3VsZCBuZWVkIHRvIHRha2UuDQoNCkhvcGUgdGhpcyBoZWxwcy4NCi1QYXZhbg0KDQpPbiBU dWUsIEFwciAxNiwgMjAxMyBhdCA3OjA4IEFNLCBLaHV6ZW1hIFBpdGhld2FuIDxrcGl0aGV3YW5A aW5maW5lcmEuY29tPG1haWx0bzprcGl0aGV3YW5AaW5maW5lcmEuY29tPj4gd3JvdGU6DQpIaSBJ Z29yLA0KDQpJIGFtIHRyeWluZyB0byBzdW1tYXJpemUgdGhlIGRpc2N1c3Npb24gd2UgaGFkIHNv IGZhci4gUGxzIHNlZSBpZiBteSBjb25jbHVzaW9uIGlzIGluIHN5bmMgd2l0aCB0aGUgaWRlYSBv ZiBNRUxHIHlvdSBoYXZlDQoNCk1FTEcgaXMgdXNlZnVsIHdoZW4NCg0KMS4gICAgICAgc2VydmVy IGxheWVyIFZMcyBhcmUgbmFpbGVkIGRvd24gZm9yIHRoZSByZXNvdXJjZXMgb24gdGhlIHNlcnZl ciBsYXllciBsaW5rcyB0aGF0IGFyZSBzaGFyZWQgYW1vbmcgbXVsdGlwbGUgVkxzLiBUaGVzZSBy ZXNvdXJjZXMgYXJlIHR5cGljYWxseSB3YXZlbGVuZ3RoIG9uIGEgZmliZXIgKGNhbiBpdCBiZSBh bnl0aGluZyBlbHNlPz8pLiBJbiBvdGhlciB3b3JkcywgaWYgMiBWTHMgYXJlIHBpbm5lZCB0byB1 c2UgYSBwYXJ0aWN1bGFyIHdhdmVsZW5ndGggb24gYSBwYXJ0aWN1bGFyIGZpYmVyLCB0aGVuIHRo ZXNlIDIgVkxzIHdpbGwgaGF2ZSBNRUxHIGZvciB0aGUgd2F2ZWxlbmd0aC4NCg0KMi4gICAgICAg c2VydmVyIGxheWVyIGRvIG5vdCBoYXZlIGNlbnRyYWxpemVkIHBhdGggY29tcHV0YXRpb24gZW50 aXR5IHdoaWNoIGNhbiBiZSB1c2VkIGJ5IGNsaWVudCBsYXllciB0byBhc2sgZm9yIGNvbmN1cnJl bnQgZGl2ZXJzZSBwYXRoIGNvbXB1dGF0aW9uIHdpdGhpbiBzZXJ2ZXIgbGF5ZXIuDQoNCjMuICAg ICAgIENsaWVudCBsYXllciBoYXMgYSBjZW50cmFsaXplZCBwYXRoIGNvbXB1dGF0aW9uIGVudGl0 eSwgd2hpY2ggd291bGQgY29tcHV0ZSBwYXRocyBmb3IgY2xpZW50K3NlcnZlciBsYXllci4NCg0K NC4gICAgICAgVGhlIG5lZWQgaXMgdG8gY2VudHJhbGl6ZWQgY29uY3VycmVudCBjb21wdXRhdGlv biBvZiBtb3JlIHRoYW4gb25lIGNsaWVudCtzZXJ2ZXIgbGF5ZXIgcGF0aCB0aGF0IG1lZXRzIHNv bWUgZGl2ZXJzaXR5IGFuZCByZXNvdXJjZSBleGNsdXNpdml0eSByZXF1aXJlbWVudHMuDQoNClJl Z2RzDQpLaHV6ZW1hDQoNCkZyb206IElnb3IgQnJ5c2tpbiBbbWFpbHRvOklCcnlza2luQGFkdmFv cHRpY2FsLmNvbTxtYWlsdG86SUJyeXNraW5AYWR2YW9wdGljYWwuY29tPl0NClNlbnQ6IE1vbmRh eSwgQXByaWwgMTUsIDIwMTMgOTo0NCBQTQ0KDQpUbzogS2h1emVtYSBQaXRoZXdhbjsgVmlzaG51 IFBhdmFuIEJlZXJhbQ0KQ2M6IERpZXRlciBCZWxsZXI7IGNjYW1wQGlldGYub3JnPG1haWx0bzpj Y2FtcEBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbQ0NBTVBdIE1FTEdzIC0gUSZBDQoNCktodXpl bWEsDQpQbGVhc2UsIHNlZSBpbi1saW5lLg0KDQpJZ29yDQoNCkZyb206IEtodXplbWEgUGl0aGV3 YW4gW21haWx0bzprcGl0aGV3YW5AaW5maW5lcmEuY29tPG1haWx0bzprcGl0aGV3YW5AaW5maW5l cmEuY29tPl0NClNlbnQ6IE1vbmRheSwgQXByaWwgMTUsIDIwMTMgMTI6MDUgQU0NClRvOiBJZ29y IEJyeXNraW47IFZpc2hudSBQYXZhbiBCZWVyYW0NCkNjOiBEaWV0ZXIgQmVsbGVyOyBjY2FtcEBp ZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW0NDQU1QXSBNRUxH cyAtIFEmQQ0KDQpIaSBJZ29yLA0KDQpJIHVuZGVyc3RhbmQgdGhlIFNSTEcgYW5kIE1FTEcgYmVo YXZpb3IgeW91IGhhdmUgcGVubmVkIC4NCg0KTXkgY29uY2VybiB3YXMgbGl0dGxlIGRpZmZlcmVu dC4gIFdpdGggY2hhbmdpbmcgcmVzb3VyY2UgY29uc3VtcHRpb24gKGJlY2F1c2Ugb2YgZHluYW1p Y2l0eSB0aGUgbmV0d29yayBoYXMpIGluIHRoZSBuZXR3b3JrIGxpbmtzLCBwb3RlbnRpYWwgcGF0 aHMgYSBzZXQgb2YgdmlydHVhbCBsaW5rIGNhbiB0YWtlIHdpbGwgY2hhbmdlIGFuZCBoZW5jZSBp dHMgTUVMRywgYXMgaXQgaXMgdGllZCB0byBhIHJlc291cmNlIGl0IGNhbiB0YWtlLiBTbyB1bmxl c3MgdmlydHVhbCBsaW5rcyBwYXRocyBhcmUgbmFpbGVkIGRvd24sIGl0IHdvdWxkIGJlIGhhcmQg dG8gY29tcHV0ZSBNRUxHcyBpbiBkaXN0cmlidXRlZCB3YXkuDQoNCklCPj4gSSB0aGluayB5b3Ug YXJlIG1pc3NpbmcgdGhlIHBvaW50IGhlcmUuIFZpcnR1YWwgTGluayBzZXJ2ZXIgbGF5ZXIgcGF0 aHMgYXJlIHBpbm5lZCBhcyBmYXIgYXMgZmF0ZSBzaGFyaW5nIGlzIGNvbmNlcm5lZCAodGhhdCBp cywgdGhleSBhcmUgcGlubmVkIG9uICBzZXJ2ZXIgbGF5ZXIgbGluayBsZXZlbCkuIEl0IHdvdWxk IG1ha2UgbGl0dGxlIHNlbnNlIHRvIGFkdmVydGlzZSBWTCBTUkxHcyBpZiB0aGUgU1JMR3MgY29u c3RhbnRseSBjaGFuZ2UuIFRoZSBzYW1lIGlzIHRydWUgZm9yIE1FTEdzLiAgU1JMR3MvTUVMR3Mg YWR2ZXJ0aXNlZCBmb3IgVkxzIG5vcm1hbGx5IGRvIG5vdCBjaGFuZ2U6IG5laXRoZXIgb3ZlciB0 aW1lIG5vciB3aGVuIFZMcyBiZWNvbWUgY29tbWl0dGVkL3VuY29tbWl0dGVkLg0KDQpBbm90aGVy IHBvaW50IGlzLCB2aXJ0dWFsIGxpbmtzIGNhbiBiZSB2aWV3ZWQgYXMgb3ZlcnN1YnNjcmlwdGlv biBvZiByZXNvdXJjZXMgKGluIE1FTEcgY29udGV4dCkuIFRha2luZyBhbiBleGFtcGxlIChmb3Ig T1ROLCBJIGtub3cgaXQgd291bGQgd29yayBkaWZmZXJlbnRseSBmb3IgYSBXYXZlbGVuZ3RoIGlu IFdETSksIGEgbGluayByZXNvdXJjZXMgYXJlIHdvcnRoIDEgVEIgb2YgQlcsIHVzZXIgaGFzIHBy b3Zpc2lvbmVkIDIwIHZpcnR1YWwgbGlua3Mgb2YgMTAwRyBlYWNoIGdvaW5nIHZpYSB0aGF0IE9U TiBsaW5rLiAgUGh5c2ljYWxseSwgb25seSAxMCB3aWxsIGdldCBjb21taXR0ZWQuIEJ1dCB3aGlj aCAxMD8gSXQgd2lsbCByZWFsbHkgZGVwZW5kIG9uIG5ldHdvcmsgZHluYW1pY3MgYXQgdGhlIHRp bWUgb2YgZGVtYW5kIHRvIGNvbW1pdC4gTUVMR3MgYXJlIG5vdCB0aGF0IGVmZmVjdGl2ZSBoZXJl LiBZb3UgbmVlZCBzb21lIGRpZmZlcmVudCBtZWNoYW5pc20uDQoNCklCPj4gQXMgSSBtZW50aW9u ZWQgYmVmb3JlIE1FTEdzIGhhdmUgbm90aGluZyB0byBkbyB3aXRoIGJhbmR3aWR0aCBhbmQgd2Vy ZSBuZXZlciBpbnRlbmRlZCB0byBzb2x2ZSB0aGUgcHJvYmxlbXMgc3VjaCBhcyB5b3UgZGVzY3Jp YmUgKGp1c3QgbGlrZSBpdCB3b3VsZCBub3QgbWFrZSBtdWNoIHNlbnNlIHRvIHNvbHZlIHN1Y2gg cHJvYmxlbSB3aXRoIFNSTEdzIDo9KQ0KQWdhaW4sICBNRUxHIGlzIGFuIGV4dHJlbWUgY2FzZSBT UkxHIGRlc2lnbmVkIGV4Y2x1c2l2ZWx5IGZvciBWTHMgKG5vIG1vcmUgYW5kIG5vIGxlc3MpLg0K DQpSZWdkcw0KS2h1emVtYQ0KDQoNCkZyb206IElnb3IgQnJ5c2tpbiBbbWFpbHRvOklCcnlza2lu QGFkdmFvcHRpY2FsLmNvbV0NClNlbnQ6IEZyaWRheSwgQXByaWwgMTIsIDIwMTMgMTE6NTUgUE0N ClRvOiBLaHV6ZW1hIFBpdGhld2FuOyBWaXNobnUgUGF2YW4gQmVlcmFtDQpDYzogRGlldGVyIEJl bGxlcjsgY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPg0KU3ViamVjdDogUkU6 IFtDQ0FNUF0gTUVMR3MgLSBRJkENCg0KS2h1emVtYSwNCg0KVGhpbmsgYWJvdXQgTUVMRyBhcyBh biBTUkxHIHRoYXQgaXMgc2hhcmVkIGJldHdlZW4gdHdvIG9yIG1vcmUgbGlua3MgaW4gaXRzIGVu dGlyZXR5LiBXaGVuIHR3byByZWFsIGxpbmtzIGhhdmUgYW4gU1JMRyBpbiBjb21tb24sIGl0IG1l YW5zIHRoYXQgdHdvIHJlYWwgbGlua3MgY2FuIGNvLWV4aXN0IGNvbmN1cnJlbnRseSwgYnV0IHRo ZXJlIGlzIHNvbWV0aGluZyAoZS5nLiBjb21tb24gY29uZHVpdCwgbm90ZSB0aGF0IHRoZSBjb25k dWl0IGhhcyByb29tIGZvciBtb3JlIHRoYW4gZm9yIG9uZSBsaW5rKSB0aGF0IHdpbGwgYnJpbmcg Ym90aCB0aGVzZSBsaW5rcyBkb3duLCBpZiB0aGlzIHNvbWV0aGluZyBmYWlscyAoZS5nLiBjb25k dWl0IGlzIGN1dCApLiBOb3cgY29uc2lkZXIgdGhhdCB0aGlzIHNvbWV0aGluZyBtdXN0IGJlIHRh a2VuIGluIGl0cyBlbnRpcmV0eSBieSBvbmUgb2YgdGhlIGxpbmtzIHRvIGJlY29tZSBvcGVyYXRp b25hbCAuIEluIHRoaXMgY2FzZSBTUkxHIGJlY29tZXMgTUVMRy4gTm90ZSB0aGF0IE1FTEcgaXMg b25seSBtZWFuaW5nZnVsIGZvciB2aXJ0dWFsIGxpbmtzICh1bmxpa2UgU1JMRyB0aGF0IG1ha2Vz IHNlbnNlIGZvciBlaXRoZXIgcmVhbCBvciB2aXJ0dWFsIGxpbmspLiBXaHkgd291bGQgeW91IGFk dmVydGlzZSB0d28gbGlua3MgdGhhdCBtdXR1YWxseSBleGNsdWRlIGVhY2ggb3RoZXIgcmF0aGVy IHRoYW4gYWR2ZXJ0aXNpbmcgb25seSBvbmUgb2YgdGhlbSBhdCBhIHRpbWUsIHVubGVzcyB0aGUg dHdvIGFyZSB2aXJ0dWFsIGxpbmtzIGFuZCBoZW5jZSBib3RoIGF2YWlsYWJsZSBmb3IgdGhlIGNs aWVudCBsYXllciBjb25uZWN0aW9ucz8NCg0KSWdvcg0KDQoNCkZyb206IEtodXplbWEgUGl0aGV3 YW4gW21haWx0bzprcGl0aGV3YW5AaW5maW5lcmEuY29tXQ0KU2VudDogRnJpZGF5LCBBcHJpbCAx MiwgMjAxMyAxOjAxIFBNDQpUbzogSWdvciBCcnlza2luOyBWaXNobnUgUGF2YW4gQmVlcmFtDQpD YzogRGlldGVyIEJlbGxlcjsgY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPg0K U3ViamVjdDogUkU6IFtDQ0FNUF0gTUVMR3MgLSBRJkENCg0KSGkgSWdvciwNCg0KRG8geW91IG1l YW4sIGlmIHZpcnR1YWwgbGluayBkbyBub3QgaGF2ZSBhbnkgc3BlY2lmaWMgY29uc3RyYWludCwg Zm9yIGV4YW1wbGUgYSBsaW5rIGluIHRoZSBwYXRoIChub3QgdGFsa2luZyBhYm91dCBlZ3Jlc3Mg bGlua3MvaW50ZXJmYWNlcykgbXVzdCBiZSB0cmF2ZXJzZWQgdG8gcmVhbGl6ZSB0aGUgdmlydHVh bCBsaW5rLCB0aGVyZSB3b250IGJlIGFueSBNRUxHIGZvciB0aGUgdmlydHVhbCBsaW5rPw0KDQpS ZWdkcw0KS2h1emVtYQ0KDQpGcm9tOiBJZ29yIEJyeXNraW4gW21haWx0bzpJQnJ5c2tpbkBhZHZh b3B0aWNhbC5jb21dDQpTZW50OiBGcmlkYXksIEFwcmlsIDEyLCAyMDEzIDk6NTIgUE0NClRvOiBL aHV6ZW1hIFBpdGhld2FuOyBWaXNobnUgUGF2YW4gQmVlcmFtDQpDYzogRGlldGVyIEJlbGxlcjsg Y2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtDQ0FN UF0gTUVMR3MgLSBRJkENCg0KS2h1emVtYSwNCg0KTUVMR3MgaGF2ZSBub3RoaW5nIHRvIGRvIHdp dGggYmFuZHdpZHRoLiBNRUxHIGlzIGEgY29uY3JldGUgbmV0d29yayByZXNvdXJjZSBpbiBhIHNl cnZlciBsYXllciB0aGF0IHR3byBvciBtb3JlIFZpcnR1YWwgTGlua3MgaW4gYSBjbGllbnQgbGF5 ZXIgZGVwZW5kIG9uIGluIGEgbXV0dWFsbHkgZXhjbHVzaXZlIHdheS4gQW4gZXhhbXBsZSBvZiBN RUxHIGlzIGEgV0RNIGxheWVyIHRyYW5zcG9uZGVyIHRoYXQgY2FuIHRlcm1pbmF0ZSBlaXRoZXIg b2YgcmVzcGVjdGl2ZSBXRE0gbGF5ZXIgdHVubmVscyAoYnV0IG5vdCBib3RoIGF0IHRoZSBzYW1l IHRpbWUpIGZvciB0d28gT1ROIGxheWVyIFZpcnR1YWwgTGlua3MuIElmIHlvdSBhZHZlcnRpc2Ug YSBWaXJ0dWFsIExpbmssIHNheSwgZm9yIEV0aGVybmV0IGxheWVyIHRoYXQgZGVwZW5kcyBvbiB0 aGUgY29ubmVjdGlvbiBpbiBPVE4gbGF5ZXIgZ29pbmcgdGhyb3VnaCBvbmUgb2YgdGhlIG1lbnRp b25lZCBPVE4gbGlua3MsIHRoZSBFdGhlcm5ldCBWTCBtdXN0IGluaGVyaXQgdGhlIE1FTEcgc2lt aWxhcmx5IGxpa2UgaXQgZG9lcyBTUkxHcyBhZHZlcnRpc2VkIGZvciB0aGUgT1ROIGxpbmtzLg0K DQpJZ29yDQoNCg0KRnJvbTogS2h1emVtYSBQaXRoZXdhbiBbbWFpbHRvOmtwaXRoZXdhbkBpbmZp bmVyYS5jb21dDQpTZW50OiBGcmlkYXksIEFwcmlsIDEyLCAyMDEzIDEyOjA2IFBNDQpUbzogSWdv ciBCcnlza2luOyBWaXNobnUgUGF2YW4gQmVlcmFtDQpDYzogRGlldGVyIEJlbGxlcjsgY2NhbXBA aWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtDQ0FNUF0gTUVM R3MgLSBRJkENCg0KSGkgSWdvciwNCg0KRm9yIG11bHRpLWxheWVyIChtb3JlIHRoYW4gMikgbmV0 d29yaywgY29uc2lkZXIgYWxsIHRoZSBsYXllcnMgYXJlIG1lc2h5ICh0aGF04oCZcyB3aGVuIHZp cnR1YWwgbGlua3MgYXJlIHVzZWZ1bCBhbnl3YXkpLCBNRUxHcyBvZiB2aXJ0dWFsIGxpbmsgd2ls bCBjaGFuZ2UgYXMgYW5kIHdoZW4gQlcvd2F2ZWxlbmd0aCBhdmFpbGFiaWxpdHkgY2hhbmdlcywg YmVjYXVzZSBwb3RlbnRpYWwgcGF0aHMsIGEgdmlydHVhbCBsaW5rIGNhbiB0YWtlIHdpbGwgY2hh bmdlLiBNYXBwaW5nIGxvd2VyIGxheWVyIE1FTEdzIHRvIGhpZ2hlciBsYXllciBNRUxHcyB3b27i gJl0IGJlIHByYWN0aWNhbCBpZiBkb25lIGluIGRpc3RyaWJ1dGVkIG1hbm5lciwgc28gaXQgaGFz IHRvIGJlIGNlbnRyYWxpemVkLiBTbyB5b3UgZG8gaGF2ZSBjZW50cmFsIGVsZW1lbnQgaW4gZWFj aCBsYXllciB0aGF0IGtub3dzIGFsbCB0aGUgcmlzayBhbmQgcGF0aHMgKGEgUENFPyksIHdoaWNo IGNhbiBiZSB1dGlsaXplZCBmb3IgbGF5ZXIgc3BlY2lmaWMgcGF0aCBjb21wdXRhdGlvbiAoYXMg aXQgaXMgZG9pbmcgaXQgYW55d2F5KS4NCg0KVGhpcyBraW5kIG9mIGFyY2hpdGVjdHVyZSBoYXMg YWxsIHRoZSBwaWVjZXMgdGhhdCBhcmUgcmVxdWlyZWQgZm9yIEludGVyLVBDRSBjb21tdW5pY2F0 aW9uIChhY3Jvc3MgbGF5ZXJzKSwgZXhjZXB0IHRoZSBwcm90b2NvbCB0aGF0IHdvdWxkIGFjdHVh bGx5IG1ha2UgdGhlIDIgUENFcyB0YWxrLg0KDQpZb3Ugc2VlbSB0byBiZSBkb2luZyBzb21ldGhp bmcgdGhhdCB5b3UgZG9u4oCZdCBsaWtlIOKYug0KDQpSZWdhcmRzDQpLaHV6ZW1hDQoNCkZyb206 IElnb3IgQnJ5c2tpbiBbbWFpbHRvOklCcnlza2luQGFkdmFvcHRpY2FsLmNvbV0NClNlbnQ6IEZy aWRheSwgQXByaWwgMTIsIDIwMTMgODozOSBQTQ0KVG86IEtodXplbWEgUGl0aGV3YW47IFZpc2hu dSBQYXZhbiBCZWVyYW0NCkNjOiBEaWV0ZXIgQmVsbGVyOyBjY2FtcEBpZXRmLm9yZzxtYWlsdG86 Y2NhbXBAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW0NDQU1QXSBNRUxHcyAtIFEmQQ0KDQpLaHV6 ZW1hLA0KDQpJIGFtIG5vdCBhIGZhbiBvZiBpbnRlci1sYXllciBwYXRoIGNvbXB1dGF0aW9ucyAo bm9yIEkgYW0gYSBmYW4gb2YgaW50ZXItUENFIGNvbXB1dGF0aW9ucykuIEluIG15IG1pbmQgcGF0 aCBjb21wdXRhdGlvbiBmb3IgYSBzZXJ2aWNlIG9yIHNlcnZpY2VzIGluIGxheWVyIFggaXMgcGVy Zm9ybWVkIG9ubHkgaW4gbGF5ZXIgWCwgaS5lLiBjb25zaWRlcnMgb25seSBYIGxheWVyIGxpbmtz IChyZWFsIG9yIHZpcnR1YWwpLiBBcyBQYXZhbiBtZW50aW9uZWQgU1JMR3MgYW5kIE1FTEdzIHRo YXQgbmVlZCB0byBiZSBpbmhlcml0ZWQgZnJvbSBsb3dlciBsYXllcnMgc2hvdWxkIGJlIHRyYW5z bGF0ZWQgaW50byBYIGxheWVyIGxpbmsgU1JMR3MvTUVMR3MgYW5kIHNwZWNpZmllZCB3aXRoIFgg bGF5ZXIgc3BlY2lmaWMgU1JMRy9NRUxHIElEcy4NCg0KQ2hlZXJzLA0KSWdvcg0KDQoNCkZyb206 IEtodXplbWEgUGl0aGV3YW4gW21haWx0bzprcGl0aGV3YW5AaW5maW5lcmEuY29tXQ0KU2VudDog RnJpZGF5LCBBcHJpbCAxMiwgMjAxMyAxMDo1NSBBTQ0KVG86IElnb3IgQnJ5c2tpbjsgVmlzaG51 IFBhdmFuIEJlZXJhbQ0KQ2M6IERpZXRlciBCZWxsZXI7IGNjYW1wQGlldGYub3JnPG1haWx0bzpj Y2FtcEBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbQ0NBTVBdIE1FTEdzIC0gUSZBDQoNCkhpIEln b3IsDQoNCk9rLiBUaGlzIHdvdWxkIGJlIHVzZWZ1bCBpZiBuZXR3b3JrIGFyY2hpdGVjdHVyZSBp cyBiYXNlZCBvbiBleHRlcm5hbCBQQ0Ugb3IgbWdtdCBlbnRpdHkgYXMgUENFIGluIGNsaWVudCBs YXllciwgYnV0IHRoZXJlIGlzIG5vIGNvdW50ZXJwYXJ0IGluIHNlcnZlciBsYXllciwgb3RoZXJ3 aXNlIG9uZSBjb3VsZCBoYXZlIGludGVyLVBDRSBjb21tdW5pY2F0aW9uIHRvIGFjaGlldmUgZGl2 ZXJzZSBwYXRoIGluIHNlcnZlciBsYXllciB3aXRob3V0IGdldHRpbmcgaW50byB2aXJ0dWFsIGxp bmsgYW5kIE1FTEcgc3R1ZmYuDQoNCklzIHRoYXQgY29ycmVjdD8NCg0KS2h1emVtYQ0KDQpGcm9t OiBJZ29yIEJyeXNraW4gW21haWx0bzpJQnJ5c2tpbkBhZHZhb3B0aWNhbC5jb21dDQpTZW50OiBG cmlkYXksIEFwcmlsIDEyLCAyMDEzIDY6MzYgUE0NClRvOiBWaXNobnUgUGF2YW4gQmVlcmFtOyBL aHV6ZW1hIFBpdGhld2FuDQpDYzogRGlldGVyIEJlbGxlcjsgY2NhbXBAaWV0Zi5vcmc8bWFpbHRv OmNjYW1wQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtDQ0FNUF0gTUVMR3MgLSBRJkENCg0KS2h1 emVtYSwNCg0KDQoyLiAgICAgICBGb3IgY2FzZXMgb2YgY29uY3VycmVudCBjb21wdXRhdGlvbiAo Y2FzZSMyLTUpLCB5b3UgYXJlIG1haW5seSB0YWxraW5nIGFib3V0IGdsb2JhbCBvcHRpbWl6YXRp b24gYW5kIGRpdmVyc2l0eSBhbW9uZyBtdWx0aXBsZSBzZXJ2aWNlcy4gWW91IGNhbiBkbyB0aGUg cGF0aCBjb21wdXRhdGlvbiwgYnV0IHRvIGFjdHVhbGx5IGVuYWN0IHRoZSBjb21wdXRlZCBwYXRo IHRoZSBzaWduYWxpbmcgbmVlZHMgdG8gYmUgZG9uZSBmcm9tIHRoZSBzb3VyY2UgZW5kIG9mIHRo b3NlIExTUHMuICBTbyB0aGVyZSBpcyBubyBwb2ludCBpbiBkb2luZyBjb25jdXJyZW50IGNvbXB1 dGF0aW9uIGF0IG9uZSBuZXR3b3JrIGVsZW1lbnQgZm9yIHRoZSBzZXJ2aWNlcyBzdGFydGluZyBm cm9tIG11bHRpcGxlIG5ldHdvcmsgZWxlbWVudHMuIEF0IGJlc3QgaXQgbG9va3MgdG8gbWUgYSBw cm9ibGVtIHRvIGJlIHNvbHZlZCBieSBuZXR3b3JrIG1hbmFnZW1lbnQvcGxhbm5pbmcgc29mdHdh cmUuDQpXZWxsLCB3aGVuIGFuIGluZ3Jlc3Mgbm9kZSBpcyBpbml0aWF0aW5nIGEgc2VydmljZSwg aXQgaXMgZG9pbmcgc28gb24gcmVxdWVzdCBmcm9tIHNvbWUgbWFuYWdlbWVudCBlbnRpdHkuIFRo aXMgbWFuYWdlbWVudCBlbnRpdHkgY2FuIGNvbXB1dGUgcGF0aHMgZm9yIG1hbnkgc2VydmljZXMg d2l0aCBzb21lIGdsb2JhbCBjcml0ZXJpYSBpbiBtaW5kLCBhbmQgdGhlbiBzcGVjaWZ5IHRoZSBy ZXN1bHRpbmcgcGF0aHMgYXMgZXhwbGljaXQgRVJPcyBpbiBwcm92aXNpb25pbmcgcmVxdWVzdHMg c2VudCB0byBlYWNoIG9mIHRoZSBzZXJ2aWNlIGluZ3Jlc3Nlcy4gSG93IGVsc2UsIGZvciBleGFt cGxlLCAgeW91IGNhbiBzZXQgdXAgc2V2ZXJhbCBzZXJ2aWNlcyBvcmlnaW5hdGVkIGZyb20gZGlm ZmVyZW50IG5vZGVzIHRoYXQgYXJlIGRpc2pvaW50IGZyb20gZWFjaCBvdGhlcj8gQWxzbywgd2hh dCBpcyB0aGUgcG9pbnQgaW4geW91ciBvcGluaW9uIG9mIHRoZSBzdGF0ZWZ1bGwgUENFIHdvcms/ DQoNCkNoZWVycywNCklnb3INCg0KRnJvbTogVmlzaG51IFBhdmFuIEJlZXJhbSBbbWFpbHRvOnZp c2hudXBhdmFuQGdtYWlsLmNvbV0NClNlbnQ6IEZyaWRheSwgQXByaWwgMTIsIDIwMTMgODowOCBB TQ0KVG86IEtodXplbWEgUGl0aGV3YW4NCkNjOiBJZ29yIEJyeXNraW47IERpZXRlciBCZWxsZXI7 IGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQ0NB TVBdIE1FTEdzIC0gUSZBDQoNCktodXplbWEsIEhpIQ0KDQpQbGVhc2Ugc2VlIGlubGluZS4uDQoN Cg0KIDEuICAgICAgIFdoZW4gTmV0d29yayBoYXMgbW9yZSB0aGFuIDIgbGF5ZXIgaS5lLiBQYWNr ZXQtT1ROLURXRE0sIHRoZSBQYWNrZXQgKGNsaWVudCkgbGF5ZXIgd2lsbCBiZSB0YWxraW5nIHRv IGl0cyBpbW1lZGlhdGUgc2VydmVyIGxheWVyIGkuZS4gT1ROLCB3aGljaCBpbiB0dXJuIGlzIHRh bGtpbmcgdG8gRFdETSBsYXllci4gVXNpbmcgTUVMRywgY2xpZW50IGxheWVyIHBhdGggY29tcHV0 YXRpb24gY2FuIHRha2UgY2FyZSBvZiByZXNvdXJjZSBleGNsdXNpdml0eSBvZiB2aXJ0dWFsIGxp bmsgZm9yIGltbWVkaWF0ZSBzZXJ2ZXIgbGF5ZXIgaS5lLiBPVE4gbGF5ZXIuICBIb3dldmVyIGlm IHRoZXJlIGlzIHJlc291cmNlIGV4Y2x1c2l2aXR5IGF0IERXRE0gbGF5ZXIsIHRoaXMgbWVjaGFu aXNtIGRvZXNu4oCZdCB3b3JrLiBZb3UgbmVlZCB0byBkbyBsb29zZSByb3V0aW5nIG9yIHVzZSBk aXN0cmlidXRlZCBQQ0UgbW9kZWwNCg0KW1ZQQl0gVGhlIGJlaGF2aW9yIGlzIHRoZSBzYW1lIGFz IHdoYXQgeW91IHdvdWxkIGRvIHdpdGggU1JMR3MgaW4gYSBtdWx0aS1sYXllciBhcmNoaXRlY3R1 cmUuIFRoZXJlIGFyZSBhcmNoaXRlY3R1cmVzIHRoYXQgYWxsb3cgdGhlIFNSTEdzIGluIHRoZSBs b3dlc3QgbGF5ZXIgdG8gYmUgZXhwb3J0ZWQgYWxsIHRoZSB3YXkgdXAgdG8gdGhlIGhpZ2hlc3Qg bGF5ZXIuIFRoZSBleHBlY3RhdGlvbiBpcyB0aGF0IE1FTEdzIHdvdWxkIGJlIHRyZWF0ZWQgaW4g dGhlIHNhbWUgdmVpbi4NCg0KMi4gICAgICAgRm9yIGNhc2VzIG9mIGNvbmN1cnJlbnQgY29tcHV0 YXRpb24gKGNhc2UjMi01KSwgeW91IGFyZSBtYWlubHkgdGFsa2luZyBhYm91dCBnbG9iYWwgb3B0 aW1pemF0aW9uIGFuZCBkaXZlcnNpdHkgYW1vbmcgbXVsdGlwbGUgc2VydmljZXMuIFlvdSBjYW4g ZG8gdGhlIHBhdGggY29tcHV0YXRpb24sIGJ1dCB0byBhY3R1YWxseSBlbmFjdCB0aGUgY29tcHV0 ZWQgcGF0aCB0aGUgc2lnbmFsaW5nIG5lZWRzIHRvIGJlIGRvbmUgZnJvbSB0aGUgc291cmNlIGVu ZCBvZiB0aG9zZSBMU1BzLiAgU28gdGhlcmUgaXMgbm8gcG9pbnQgaW4gZG9pbmcgY29uY3VycmVu dCBjb21wdXRhdGlvbiBhdCBvbmUgbmV0d29yayBlbGVtZW50IGZvciB0aGUgc2VydmljZXMgc3Rh cnRpbmcgZnJvbSBtdWx0aXBsZSBuZXR3b3JrIGVsZW1lbnRzLiBBdCBiZXN0IGl0IGxvb2tzIHRv IG1lIGEgcHJvYmxlbSB0byBiZSBzb2x2ZWQgYnkgbmV0d29yayBtYW5hZ2VtZW50L3BsYW5uaW5n IHNvZnR3YXJlLg0KW1ZQQl0gIEknbSBub3Qgc3VyZSB3aHkgeW91IHRoaW5rIHRoZXJlIGlzIG5v IHBvaW50IGluIGhhdmluZyBhIGNlbnRyYWxpemVkIGNvbXB1dGF0aW9uIGZ1bmN0aW9uIGNvbXB1 dGUgcGF0aHMgY29uY3VycmVudGx5IGZvciBMU1BzIHdpdGggZGlmZmVyZW50IHNldCBvZiBlbmQt cG9pbnRzLiBFdmVuIHlvdXIgTk1TL3BsYW5uaW5nLXNvZnR3YXJlIGNhbiBpbnRlcmFjdCB3aXRo IHN1Y2ggY29tcHV0YXRpb24gZW5naW5lLCByZXRyaWV2ZSBhbGwgdGhlIHBhdGhzIGFuZCB0aGVu IGdvIGFib3V0IGluaXRpYXRpbmcgdGhlIHBhdGgtc2V0dXAgZnJvbSB0aGUgaW5ncmVzcyBvZiBl YWNoIExTUC4NCg0KUmVnYXJkcywNCi1QYXZhbg0KDQoNCg0KDQpGcm9tOiBjY2FtcC1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmNjYW1wLWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYg T2YgSWdvciBCcnlza2luDQpTZW50OiBUdWVzZGF5LCBNYXJjaCAyNiwgMjAxMyA3OjE5IFBNDQpU bzogRGlldGVyIEJlbGxlcjsgVmlzaG51IFBhdmFuIEJlZXJhbQ0KDQpDYzogY2NhbXBAaWV0Zi5v cmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtDQ0FNUF0gTUVMR3MgLSBR JkENCg0KRGlldGVyLA0KDQpZb3Ugc2FpZDoNCj4+IEkgZ3Vlc3Mgd2UgYXJlIGNvbWluZyBiYWNr IHRvIHRoZSBlc3NlbnRpYWwgcG9pbnQ6ICJhbmQgaG93IG9mdGVuIGNvbmN1cnJlbnQgcGF0aCBj b21wdXRhdGlvbiB3aWxsIGJlID4+IHVzZWQuIg0KDQpUbyBiZSBob25lc3QsIHRoaXMgc3VycHJp c2VzIG1lIHF1aXRlIGEgYml0LCBMZXQgbWUgZ2l2ZSB5b3Ugc29tZSBvZiBtYW55IHJlYXNvbnMg YXMgdG8gd2h5IGNvbmN1cnJlbnQgcGF0aCBjb21wdXRhdGlvbnMgYXJlIG5lZWRlZCBhbmQgd2h5 IHRoaXMgaXMgYmV0dGVyIHRoYW4gY29tcHV0aW5nIG9uZSBwYXRoIGF0IGEgdGltZToNCg0KDQox LiAgICAgIENvbXB1dGluZyBzZXZlcmFsIGRpdmVyc2UgcGF0aHMgZm9yIHRoZSBzYW1lIHNlcnZp Y2UgaW4gdGhlIGNvbnRleHQgb2Ygc2VydmljZSByZWNvdmVyeS4gSSBob3BlIHlvdSByZWFsaXpl IHRoYXQgY29tcHV0aW5nIG9uZSBwYXRoIGF0IGEgdGltZSBvbiBtYW55IGNvbmZpZ3VyYXRpb25z IHByb2R1Y2VzIG5vIG9yIHN1Yi1vcHRpbWFsIHJlc3VsdHMuIEkgYWxzbyBob3BlIHlvdSByZWFs aXplIHRoZSBwcm9ibGVtIG9mIHNlbGVjdGluZyB0d28gcGF0aHMgd2l0aCBvbmUgb2YgdGhlbSAg aGF2aW5nIGEgbGluayB3aXRoIGNvbW1vbiBNRUxHIHdpdGggYSBsaW5rIGZyb20gYW5vdGhlciBw YXRoOw0KDQoyLiAgICAgIENvbXB1dGluZyBwYXRocyBmb3IgbXVsdGlwbGUgc2VydmljZXMgdG8g YmUgc3VmZmljaWVudGx5IGRpc2pvaW50IGZyb20gZWFjaCBvdGhlcjsNCg0KMy4gICAgICBDb21w dXRpbmcgcGF0aHMgZm9yIG11bHRpcGxlIHNlcnZpY2VzIHRvIGFjaGlldmUgYSBnbG9iYWwgb3B0 aW1pemF0aW9uIGNyaXRlcmlhIChlLmcuIG1pbmltYWwgc3VtbWFyeSB0b3RhbCBjb3N0KTsNCg0K NC4gICAgICBDb21wdXRpbmcgcGF0aHMgZm9yIG11bHRpcGxlIHNlcnZpY2VzIGZvciB0aGUgcHVy cG9zZSBvZiByZW1vdmluZyB0aGUgYmFuZHdpZHRoIGZyYWdtZW50YXRpb25zOw0KDQo1LiAgICAg IENvbXB1dGluZyBwYXRocyBmb3IgbXVsdGlwbGUgc2VydmljZXMgdG8gcGxhbiBzaGFyZWQgbWVz aCBwcm90ZWN0aW9uL3Jlc3RvcmF0aW9uIHNjaGVtZXMNCg0KNi4gICAgICBFdGMuDQoNCkFsc28g dGhpbmsgYWJvdXQgdGhpczoNCg0KMS4gICAgICBJZiBjb25jdXJyZW50IHBhdGggY29tcHV0YXRp b24gd2FzIG5vdCBpbXBvcnRhbnQsIHdoeSBQQ0VQIGluY2x1ZGVzIHRoZSBtYWNoaW5lcnkgdG8g ZG8gdGhhdD8NCg0KMi4gICAgICBNeSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBzdGF0ZWZ1bGwgUENF IGlzIHRoYXQgaXQgZG9lcyBwcmV0dHkgbXVjaCBub3RoaW5nIGJ1dCBjb25jdXJyZW50IHBhdGgg Y29tcHV0YXRpb25zDQoNCllvdSBhbHNvIHNhaWQ6DQo+PiBJIHN1cHBvc2UgdGhhdCBpZiBhIHBj ZSBhcHByb2FjaCBpcyB1c2VkLCBpLmUuLCBwYXRoIGNvbXB1dGF0aW9uIGlzIGNlbnRyYWxpemVk IGluY2x1ZGluZyB0aGUNCj4+IFRFLURCLCBNRUxHIHJvdXRpbmcgZXh0ZW5zaW9ucyBhcmUgbm90 IG5lZWRlZCBiZWNhdXNlIHRoZSBpbmZvcm1hdGlvbiBhYm91dCBtdXR1YWwNCj4+ZXhjbHVzaXZl IFZMcyBjYW4gYmUga2VwdCBpbiB0aGUgY2VudHJhbCBURS1EQiB3aGVuIFZMcyBhcmUgY29uZmln dXJlZC4NCkhvdyB0aGlzIGxvZ2ljIGRvZXMgbm90IGFwcGx5IHRvIG90aGVyIGxpbmsgYXR0cmli dXRlcyBzdWNoIGFzIFNSTEdzPw0KV2hhdCBpZiBwYXRoIGNvbXB1dGF0aW9uIGlzIG5vdCBjZW50 cmFsaXplZD8NCg0KQ2hlZXJzLA0KSWdvcg0KDQpGcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgRGlldGVy IEJlbGxlcg0KU2VudDogTW9uZGF5LCBNYXJjaCAyNSwgMjAxMyA1OjUyIFBNDQpUbzogVmlzaG51 IFBhdmFuIEJlZXJhbQ0KQ2M6IGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4N ClN1YmplY3Q6IFJlOiBbQ0NBTVBdIE1FTEdzIC0gUSZBDQoNCkhpIFBhdmFuLA0KT24gMjUuMDMu MjAxMyAwNzx0ZWw6MjUuMDMuMjAxMyUyMDA3PjoyOSwgRmF0YWkgWmhhbmcgd3JvdGU6DQpIaSBQ YXZhbiwNCg0KSSBhbSBub3Qgc3VyZSBob3cgbXVjaCBWTCAoVmlydHVhbCBMaW5rKSB3aWxsIGJl IHVzZWQgaW4gdGhlIHByYWN0aWNhbCBkZXBsb3ltZW50IGFuZCBob3cgb2Z0ZW4gY29uY3VycmVu dCBwYXRoIGNvbXB1dGF0aW9uIHdpbGwgYmUgdXNlZC4NCkkgZ3Vlc3Mgd2UgYXJlIGNvbWluZyBi YWNrIHRvIHRoZSBlc3NlbnRpYWwgcG9pbnQ6ICJhbmQgaG93IG9mdGVuIGNvbmN1cnJlbnQgcGF0 aCBjb21wdXRhdGlvbiB3aWxsIGJlIHVzZWQuIg0KDQpUaGlzIG1lYW5zIHdlIGFyZSB0cnlpbmcg dG8gZmlndXJlIG91dCB1bmRlciB3aGljaCBjb25kaXRpb25zIE1FTEcgcm91dGluZyBleHRlbnNp b25zDQpjb3VsZCBiZSBiZW5lZmljaWFsLg0KDQpJTUhPLCB0aGV5IHdvdWxkIG9ubHkgbWFrZSBz ZW5zZSwgaWY6DQoNCiAgKiAgIGEgcGF0aCBjb21wdXRhdGlvbiBmdW5jdGlvbiBzdXBwb3J0cyB0 aGUgY2FsY3VsYXRpb24gb2YgayBzaG9ydGVzdCBwYXRocyBjb25jdXJyZW50bHkNCiAgKiAgIGlm IHRoZXJlIGlzIG9ubHkgYSBzaW5nbGUgcGF0aCBjb21wdXRhdGlvbiBmdW5jdGlvbiBpbnN0YW5j ZSBwZXIgZG9tYWluIChwY2UgYXBwcm9hY2gpDQpJZiBwYXRoIGNvbXB1dGF0aW9uIGlzIGRvbmUg aW4gYSBkaXN0cmlidXRlZCBmYXNoaW9uIHRoZSBiZW5lZml0IGdvZXMgYXdheSBiZWNhdXNlDQp0 aGUgaW5zdGFuY2VzIGNhbGN1bGF0ZSBwYXRocyBpbmRlcGVuZGVudGx5IQ0KSSBzdXBwb3NlIHRo YXQgaWYgYSBwY2UgYXBwcm9hY2ggaXMgdXNlZCwgaS5lLiwgcGF0aCBjb21wdXRhdGlvbiBpcyBj ZW50cmFsaXplZCBpbmNsdWRpbmcgdGhlDQpURS1EQiwgTUVMRyByb3V0aW5nIGV4dGVuc2lvbnMg YXJlIG5vdCBuZWVkZWQgYmVjYXVzZSB0aGUgaW5mb3JtYXRpb24gYWJvdXQgbXV0dWFsDQpleGNs dXNpdmUgVkxzIGNhbiBiZSBrZXB0IGluIHRoZSBjZW50cmFsIFRFLURCIHdoZW4gVkxzIGFyZSBj b25maWd1cmVkLg0KDQpIZW5jZSwgaXQgaXMgcXVpdGUgZG91YnRmdWwgd2hldGhlciBNRUxHIHJv dXRpbmcgZXh0ZW5zaW9ucyBhcmUgcmVhbGx5IHVzZWZ1bCB1bmxlc3MgdGhlaXINCmFwcGxpY2Fi aWxpdHkgaXMgYnJvYWRlci4NCg0KDQpUaGFua3MsDQpEaWV0ZXINCg0KRG8geW91IHRoaW5rIGlm IGl0IG1ha2VzIHNlbnNlIHRvIGFkZCBhIGZsYWcgKGluIHJvdXRpbmcgYWR2ZXJ0aXNlbWVudCkg dG8gaW5kaWNhdGUgYSBsaW5rIGlzIGEgVkwgb3Igbm90Pw0KDQoNCg0KQmVzdCBSZWdhcmRzDQoN CkZhdGFpDQoNCkZyb206IFZpc2hudSBQYXZhbiBCZWVyYW0gW21haWx0bzp2aXNobnVwYXZhbkBn bWFpbC5jb21dDQpTZW50OiBGcmlkYXksIE1hcmNoIDIyLCAyMDEzIDg6NTcgUE0NClRvOiBGYXRh aSBaaGFuZw0KQ2M6IElnb3IgQnJ5c2tpbjsgY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFtDQ0FNUF0gTUVMR3MgLSBRJkENCg0KRmF0YWksIEhpIQ0K DQpHb29kIHRvIHNlZSB0aGF0IHlvdSB1bmRlcnN0YW5kIHRoZSBjb25zdHJ1Y3Qgbm93Lg0KDQpU aGlzIGlzIG5vdCBhIGNvcm5lciBjYXNlLiBUaGUgdXRpbGl0eSBvZiB0aGUgY29uc3RydWN0IGJl Y29tZXMgcXVpdGUgc2lnbmlmaWNhbnQgaWYgeW91IGhhdmUgYW4gYXBwbGljYXRpb24gdGhhdCBk b2VzIGNvbmN1cnJlbnQgcGF0aCBjb21wdXRhdGlvbnMgb24gYW4gYWJzdHJhY3QgdG9wb2xvZ3ku DQoNClJlZ2FyZHMsDQotUGF2YW4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQpDQ0FNUCBtYWlsaW5nIGxpc3QNCg0KQ0NBTVBAaWV0Zi5vcmc8 bWFpbHRvOkNDQU1QQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2NjYW1wDQoNCi0tDQpESUVURVIgQkVMTEVSDQpBTENBVEVMLUxVQ0VOVCBERVVUU0NI TEFORCBBRw0KUFJPSkVDVCBNQU5BR0VSIEFTT04vR01QTFMgQ09OVFJPTCBQTEFORQ0KQ09SRSBO RVRXT1JLUyBCVVNJTkVTUyBESVZJU0lPTg0KT1BUSUNTIEJVLCBTV0lUQ0hJTkcgUiZEDQoNCkxv cmVuenN0cmFzc2UgMTANCjcwNDM1IFN0dXR0Z2FydCwgR2VybWFueQ0KUGhvbmU6ICs0OSA3MTEg ODIxIDQzMTI1IGJlZ2luX29mX3RoZV9za3lwZV9oaWdobGlnaHRpbmcgW0ltYWdlIHJlbW92ZWQg Ynkgc2VuZGVyLl0gKzQ5IDcxMSA4MjEgNDMxMjUgRlJFRSAgZW5kX29mX3RoZV9za3lwZV9oaWdo bGlnaHRpbmcgYmVnaW5fb2ZfdGhlX3NreXBlX2hpZ2hsaWdodGluZyDplJnor6/vvIHmnKrmjIfl rprmlofku7blkI3jgIIrNDkgNzExIDgyMSA0MzEyNSBiZWdpbl9vZl90aGVfc2t5cGVfaGlnaGxp Z2h0aW5nIFtJbWFnZSByZW1vdmVkIGJ5IHNlbmRlci5dICs0OSA3MTEgODIxIDQzMTI1IEZSRUUg IGVuZF9vZl90aGVfc2t5cGVfaGlnaGxpZ2h0aW5nIEZSRUUgIGJlZ2luX29mX3RoZV9za3lwZV9o aWdobGlnaHRpbmcg6ZSZ6K+v77yB5pyq5oyH5a6a5paH5Lu25ZCN44CCKzQ5IDcxMSA4MjEgNDMx MjUgRlJFRSAgPHRlbDolMkI0OSUyMDcxMSUyMDgyMSUyMDQzMTI1Pg0KTW9iaWw6ICs0OSAxNzUg NzI2Njg3NCBiZWdpbl9vZl90aGVfc2t5cGVfaGlnaGxpZ2h0aW5nIFtJbWFnZSByZW1vdmVkIGJ5 IHNlbmRlci5dICs0OSAxNzUgNzI2Njg3NCBGUkVFICBlbmRfb2ZfdGhlX3NreXBlX2hpZ2hsaWdo dGluZyBiZWdpbl9vZl90aGVfc2t5cGVfaGlnaGxpZ2h0aW5nIOmUmeivr++8geacquaMh+WumuaW h+S7tuWQjeOAgis0OSAxNzUgNzI2Njg3NCBiZWdpbl9vZl90aGVfc2t5cGVfaGlnaGxpZ2h0aW5n IFtJbWFnZSByZW1vdmVkIGJ5IHNlbmRlci5dICs0OSAxNzUgNzI2Njg3NCBGUkVFICBlbmRfb2Zf dGhlX3NreXBlX2hpZ2hsaWdodGluZyBGUkVFICBiZWdpbl9vZl90aGVfc2t5cGVfaGlnaGxpZ2h0 aW5nIOmUmeivr++8geacquaMh+WumuaWh+S7tuWQjeOAgis0OSAxNzUgNzI2Njg3NCBGUkVFICA8 dGVsOiUyQjQ5JTIwMTc1JTIwNzI2Njg3ND4NCkRpZXRlci5CZWxsZXJAYWxjYXRlbC1sdWNlbnQu Y29tPG1haWx0bzpEaWV0ZXIuQmVsbGVyQGFsY2F0ZWwtbHVjZW50LmNvbT4NCg0KQWxjYXRlbC1M dWNlbnQgRGV1dHNjaGxhbmQgQUcNCkRvbWljaWxlIG9mIHRoZSBDb21wYW55OiBTdHV0dGdhcnQg wrcgTG9jYWwgQ291cnQgU3R1dHRnYXJ0IEhSQiA0MDI2DQpDaGFpcm1hbiBvZiB0aGUgU3VwZXJ2 aXNvcnkgQm9hcmQ6IE1pY2hhZWwgT3BwZW5ob2ZmDQpCb2FyZCBvZiBNYW5hZ2VtZW50OiBXaWxo ZWxtIERyZXNzZWxoYXVzIChDaGFpcm1hbikgwrcgSGFucy1Kw7ZyZyBEYXViIMK3IERyLiBSYWlu ZXIgRmVjaG5lciDCtyBBbmRyZWFzIEdlaGUNCg0KDQoNCg== --_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923A939atlsrvmail10atl_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0i R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+ DQo8IS0tW2lmICFtc29dPjxzdHlsZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9 DQpvXDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwo I2RlZmF1bHQjVk1MKTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwv c3R5bGU+PCFbZW5kaWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAw IDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6 MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5 IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsNCglw YW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpw Lk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwg ZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10 b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2lu LWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uSFRNTFByZWZv cm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0 ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnAuSFRNTCwgbGkuSFRNTCwgZGl2LkhUTUwN Cgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC85byPIjsNCgltc28tc3R5bGUtbGluazoi SFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCnNwYW4uSFRNTENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+ 5qC85byPIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCDpooTorr7moLzlvI8iOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5z a3lwZXBuaHByaW50Y29udGFpbmVyMTM2NjM3NTU5MQ0KCXttc28tc3R5bGUtbmFtZTpza3lwZV9w bmhfcHJpbnRfY29udGFpbmVyXzEzNjYzNzU1OTE7fQ0Kc3Bhbi5za3lwZXBuaGNvbnRhaW5lcg0K CXttc28tc3R5bGUtbmFtZTpza3lwZV9wbmhfY29udGFpbmVyO30NCnNwYW4uc2t5cGVwbmhtYXJr DQoJe21zby1zdHlsZS1uYW1lOnNreXBlX3BuaF9tYXJrO30NCnNwYW4uc2t5cGVwbmhoaWdobGln aHRpbmdpbmFjdGl2ZWNvbW1vbg0KCXttc28tc3R5bGUtbmFtZTpza3lwZV9wbmhfaGlnaGxpZ2h0 aW5nX2luYWN0aXZlX2NvbW1vbjt9DQpzcGFuLnNreXBlcG5odGV4dGFyZWFzcGFuDQoJe21zby1z dHlsZS1uYW1lOnNreXBlX3BuaF90ZXh0YXJlYV9zcGFuO30NCnNwYW4uc2t5cGVwbmh0ZXh0c3Bh bg0KCXttc28tc3R5bGUtbmFtZTpza3lwZV9wbmhfdGV4dF9zcGFuO30NCnNwYW4uc2t5cGVwbmhm cmVldGV4dHNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6c2t5cGVfcG5oX2ZyZWVfdGV4dF9zcGFuO30N CnNwYW4uRW1haWxTdHlsZTI5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWls U3R5bGUzMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMjVp biAxLjBpbiAxLjI1aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMDE3NDY0 NDIyOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNzQxNDY4OTI2O30NCkBsaXN0IGwwOmxldmVs MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6 bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDENCgl7bXNvLWxpc3QtaWQ6MTQ5NjIxNjgyNDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6LTMyMzE4NjQzOCAtMTcxNTQxMjcxOCA2NzY5ODcxMyA2NzY5 ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcx NTt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93 ZXI7DQoJbXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFs cGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6 LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlz dCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDgN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9t YW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDINCgl7bXNvLWxp c3QtaWQ6MTc0Mzc5ODQzNzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTY0NjU2NjA4Njt9DQpA bGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMg0KCXtt c28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLXRh Yi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs MjpsZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJ e21zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwt dGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBGYXRhaSw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGxlYXNlLCBzZWUgbXkgY29tbWVudHMgaW4gbGluZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWdvcjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBGYXRh aSBaaGFuZyBbbWFpbHRvOnpoYW5nZmF0YWlAaHVhd2VpLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9i PiBGcmlkYXksIEFwcmlsIDE5LCAyMDEzIDk6MTAgUE08YnI+DQo8Yj5Ubzo8L2I+IFZpc2hudSBQ YXZhbiBCZWVyYW08YnI+DQo8Yj5DYzo8L2I+IEtodXplbWEgUGl0aGV3YW47IElnb3IgQnJ5c2tp bjsgRGlldGVyIEJlbGxlcjsgY2NhbXBAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6 IFtDQ0FNUF0gTUVMR3MgLSBRJmFtcDtBPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkhpIFBhdmFuLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+SW4gbXkgZXhtcGxlLCBJIGp1c3Qgd2FudCB0byBzaG93IHlvdSB0aGF0 IHRoZSBtb3JlIGdlbmVyaWMgY2FzZSBmb3IgdGhlIFZURSBsaW5rICh0byBpbXByb3ZlIHJlc291 cmNlDQogdXNhZ2UgZWZmaWNpZW5jeSksIHdoaWNoIGRvZXMgbm90IGFzc29jaWF0ZSBhIHNwZWNp ZmljIHBvdGVudGlhbCBwYXRoIGF0IHRoZSB0aW1lIG9mIGFkdmVydGlzZW1lbnQuIEluIHRoaXMg Z2VuZXJpYyBjYXNlLCBNRUxHcyBkb27igJl0IGhlbHAuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5QbGVhc2Ugc2VlIG1vcmUgaW4t bGluZSBiZWxvdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t cmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5XaGF0IGlzIFZpcnR1YWwgTGluaz8gQXMgZGVzY3Jp YmVkIGluIFJGQzYwMDEsIGl0IHNheXMgYXMgYmVsb3cuIFNvIG15DQogcXVlc3Rpb24gaXM6IHdo ZW4gdGhlcmUgYXJlIHR3byBWTHMgY3JlYXRlZCB0aHJvdWdoIENhbGwgYXBwcm9hY2ggYXMgZGVm aW5lZCBpbiBSRkM2MDAxLCBvbmUgaGFzIDMgcG90ZW50aWFsIHBhdGhzIGluIHRoZSBzZXJ2ZXIg bGF5ZXIgdG8gc2V0dXAgRkEtTFNQLCBhbmQgYW5vdGhlciBoYXMgMiBwb3RlbnRpYWwgcGF0aHMg aW4gdGhlIHNlcnZlciBsYXllciwgYW5kIG9ubHkgb25lIG9mIHRoZSAzICZhbXA7MiBoYXMgdGhl IHNhbWUgcmVzb3VyY2Ugc2hhcmVkDQogaW4gdGhlIHNlcnZlciBsYXllci4gPC9zcGFuPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+SG93IE1FTEdzIGNhbiBoZWxw IGluIHRoaXMgY2FzZT88L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj5bVlBCXSBJIHRoaW5rIHRoZSBkaXNjb25uZWN0IGJldHdlZW4gdXMgaGFzIGdvdCB0 byBkbyB3aXRoIGhvdyB0aGUgVmlydHVhbCBURSAoVlRFKSBMaW5rIGdldHMgYWR2ZXJ0aXNlZC4g U2F5LCB0aGF0IHRoZXJlIGFyZSAzIHBvdGVudGlhbCBwYXRocyBpbiB0aGUgc2VydmVyIGxheWVy IHRoYXQgY2FuIGNhdGVyIHRvIGEgZ2l2ZW4gVlRFIGxpbmsuDQogSW4gb3VyIG5vdGlvbiBvZiB0 aGUgJnF1b3Q7VmlydHVhbCBURSBMaW5rJnF1b3Q7LCBhdCB0aGUgdGltZSBvZiBhZHZlcnRpc2lu ZyB0aGVyZSBhbHJlYWR5IGV4aXN0cyBhbiBhc3NvY2lhdGlvbiBiZXR3ZWVuIHRoZSBWVEUgbGlu ayBhbmQgb25lIG9mIHRoZXNlIDMgcGF0aHMuIFdpdGhvdXQgYXNzb2NpYXRpbmcgeW91ciBWVEUg bGluayB3aXRoIGEgc3BlY2lmaWMgc2VydmVyLXBhdGgsIHlvdSB3b3VsZG4ndCBiZSBhYmxlIHRv IGFjY3VyYXRlbHkgYWR2ZXJ0aXNlDQogYXR0cmlidXRlcyBsaWtlIGRpdmVyc2l0eSwgZGVsYXks IG11dHVhbC1leGNsdXNpdml0eSBldGMuIElmIEkgdW5kZXJzdG9vZCB5b3VyIHF1ZXN0aW9uIGNv cnJlY3RseSwgeW91ciBub3Rpb24gb2YgaG93IHRoZSBWaXJ0dWFsIFRFIExpbmsgZ2V0cyBhZHZl cnRpc2VkIHNlZW1zIHRvIGJlIGRpZmZlcmVudCAtIHlvdSBkb24ndCBhc3NvY2lhdGUgdGhlIFZU RSBsaW5rIHRvIGEgc3BlY2lmaWMgcG90ZW50aWFsIHBhdGggYXQgdGhlIHRpbWUgb2YgYWR2ZXJ0 aXNlbWVudC4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPltGYXRhaV0gUmlnaHQuIFRoZSBWVEUgbGluayBkb2VzIG5v dCBhc3NvY2lhdGUgYSBzcGVjaWZpYyBwb3RlbnRpYWwgcGF0aCBhdCB0aGUgdGltZSBvZiBhZHZl cnRpc2VtZW50LCBpdCBpcyBhIGtpbmQgb2YgcG90ZW50aWFsaXR5DQogZm9yIHRoZSBWVEUgYWR2 ZXJ0aXNlZCBhcyBkZWZpbmVkIGluIFJGQzYwMDEuIEluIHRoaXMgY2FzZSwgcGF0aCBjb21wdXRh dGlvbiBlbGVtZW50IChlLmcsIGNlbnRyYWxpemVkIFBDRSBmb3IgaW50ZXItbGF5ZXIpIGNhbiBi ZSBhd2FyZSBvZiB0aGUgbGluayBpbmZvcm1hdGlvbiwgaW5jbHVkaW5nIGxpbmsgYmFuZHdpZHRo LCBTUkxH4oCmLi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+SUImZ3Q7Jmd0OyBXZeKAmXZlIG5ldmVyIHNhaWQgdGhhdCBv dXIgd29yayBpcyBsaW1pdGVkIHRvIHdoYXQgaXMgZGVmaW5lZCBvciBwcmVzY3JpYmVkIGJ5IFJG QzYwMDEuIEluIHBhcnRpY3VsYXIsIGFjY29yZGluZyB0byBvdXIgVkwgc3RvcnksDQogd2hlbiBh IFZMIGlzIGFkdmVydGlzZWQsIHRoaXMgaXMgYWJvdXQgbXVjaCBtb3JlIHRoYW4gYWR2ZXJ0aXNp bmcg4oCcPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5hIGtpbmQgb2YgcG90ZW50aWFsaXR54oCdLiBOb3Qg b25seSBhIHBvdGVudGlhbCBwYXRoIGluIHRoZSBzZXJ2ZXIgbGF5ZXIgaXMgc2VsZWN0ZWQNCiBh bmQgcGlubmVkIChhdCBsZWFzdCBhcyBmYXIgYXMgdGhlIGxpbmsgZmF0ZSBzaGFyaW5nIGlzIGNv bmNlcm5lZCksIGEgc3RhdGUgaXMgY3JlYXRlZCBhdCBldmVyeSBzZXJ2ZXIgbGF5ZXIgbGluayB0 aGUgc2VsZWN0ZWQgcGF0aCBpcyBnb2luZyB0aHJvdWdoLiBUaGUgc2FpZCBzdGF0ZSBhbGxvd3Mg Zm9yIHNoYXJpbmcgdGhlIGxpbmsgcmVzb3VyY2UgYW1vbmcgVkxzLCBidXQgbWFrZXMgcmVzb3Vy Y2UgdW5hdmFpbGFibGUgZm9yIGFueXRoaW5nDQogZWxzZSBhbmQgcHJldmVudHMgdGhlIHJlc291 cmNlIGZyb20gYmVpbmcgZGUtcHJvdmlzaW9uZWQuIEluIG91ciBvcGluaW9uLCB0aGlzIGlzIHRo ZSBvbmx5IHdheSB0byBwcmV2ZW50IHRoZSBmb2xsb3dpbmcgc2l0dWF0aW9ucyB0byBoYXBwZW4g YWZ0ZXIgdGhlIFZMIGlzIGFkdmVydGlzZWQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6 bDEgbGV2ZWwxIGxmbzQiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5hKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlNvbWUgTFNQLCB1bnJlbGF0 ZWQgdG8gVkwsIGFsbG9jYXRlcyBhbmQgc3RhcnRzIHVzaW5nIHRoZSByZXNvdXJjZSB0aGUgVkwg ZGVwZW5kcyB1cG9uOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm80 Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+Yik8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5UaGUgb3BlcmF0b3IgKGNvbnNjaW91c2x5IG9yIG90 aGVyd2lzZSkgZGUtcHJvdmlzaW9ucyB0aGUgcmVzb3VyY2UuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkJlc2lkZXMsIGhvdyBlbHNlIG9u ZSBjYW4gYWR2ZXJ0aXNlIHRoZSBWTOKAmXMgU1JMR3MsIGlmIG9uZSBoYXMgbm8gY2x1ZSBhcyB0 byB3aGF0IHNlcnZlciBsYXllciBwYXRoIHRoZSBWTCB3aWxsIGVuZCB1cCB0YWtpbmcgd2hlbg0K IGlzIGNvbW1pdHRlZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+Q29udGludWluZyB3aXRoIHlvdXIgZXhhbXBsZSAtIElmIHRoZSBwYXRo IHRoYXQgZ2V0cyBhc3NvY2lhdGVkIHdpdGggVlRFLUxpbmstMSBhbmQgdGhlIHBhdGggdGhhdCBn ZXRzIGFzc29jaWF0ZWQgd2l0aCBWVEUtTGluay0yIGRlcGVuZCBvbiB0aGUgc2FtZSByZXNvdXJj ZSwgJnF1b3Q7TUVMR3MmcXVvdDsgd291bGQgbWFrZSBzdXJlIHRoYXQgdGhlIGNsaWVudA0KIGNv bXB1dGF0aW9uIGZ1bmN0aW9uIGlzIGF3YXJlIG9mIHRoZSBleGlzdGVuY2Ugb2Ygc3VjaCAmcXVv dDttdXR1YWwgZXhjbHVzaXZpdHkmcXVvdDsgcmVsYXRpb25zaGlwLiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+W0Zh dGFpXSBUaGUgcGF0aCBjb21wdXRhdGlvbiBlbGVtZW50IChjZW50cmFsaXplZCBQQ0UgZm9yIGlu dGVyLWxheWVyIG9yIG11bHRpcGxlIFBDRXMgdGhyb3VnaCBjb21tdW5pY2F0aW9uKSBjYW4gdGFr ZSBjYXJlIG9mIHRoaXMNCiBpc3N1ZSB0byBhdm9pZCB0aGlzIGhhcHBlbiB3aXRob3V0IE1FTEcg aW50cm9kdWNlZC4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj5JQiZndDsmZ3Q7IElNTyBpbnRlci1sYXllciBwYXRoIGNvbXB1 dGF0aW9uIGlzIG9uZSBvZiB0aG9zZSB0aGluZ3MgcGVvcGxlIHRhbGsgZm9yIG1hbnkgeWVhcnMg KDcmIzQzOyA/KSwgYnV0IHdoaWNoIG5ldmVyIHNlZXMgYW55IHByb2R1Y3Rpb24NCiBuZXR3b3Jr IGRlcGxveW1lbnQgZm9yIGEgc2ltcGxlIHJlYXNvbjogaXQgaXMgb25seSBnb29kIGZvciBhIGNh cmVmdWxseSBvcmNoZXN0cmF0ZWQgZGVtbywgYnV0IGlzIG5vdCBnb29kIGVub3VnaCB0byBzb2x2 ZSBhbnkgcmVhbCBuZXR3b3JrIHByb2JsZW0uIE9uZSBiaWcgcHJvYmxlbSB3aXRoIHRoZSBpbnRl ci1sYXllciBwYXRoIGNvbXB1dGF0aW9uIGlzIHRoYXQgaXQgaW1wbGllcyAqPGI+cmUtZGVmaW5p bmcgY2xpZW50IGxheWVyIHRvcG9sb2d5DQogZHVyaW5nIGEgY2xpZW50IGxheWVyIHBhdGggY29t cHV0YXRpb24sIGkuZS4gYmFzZWQgb24gYSBzaW5nbGUgcGF0aCBjb21wdXRhdGlvbiByZXF1ZXN0 PC9iPiouIEEgcmVhbCBsaWZlIGFuYWxvZ3kgb2YgdGhpcyBwYXJhZGlnbSB3b3VsZCBiZSBzb21l dGhpbmcgbGlrZSB0aGlzLiBJbWFnaW5lLCBGYXRhaSwgeW91IGFycml2ZSB0byB0aGUgQmVpamlu ZyBhaXJwb3J0IGFuZCBzYXk6IOKAnEkgbmVlZCB0byBmbHkgdG8gV2FzaGluZ3RvbiBEQ+KAnSwg YW5kDQogeW91IGhlYXIgYmFjazog4oCcTXIuIFpoYW5nLCBBbGwgZmxpZ2h0cyB0byBXYXNoaW5n dG9uIGFyZSBib29rZWQsIGhvd2V2ZXIsIEkgY2FuIHNlZSB0aGF0IHdlIGhhdmUgYSBzcGFyZSBw bGFuZSBhdmFpbGFibGUsIHNvIEnigJl2ZSBqdXN0IGNyZWF0ZWQgZm9yIHlvdSBhIGZsaWdodCBB aXJDaGluYSBYWVogd2hpY2ggd2lsbCBnbyBub24tc3RvcCB0byBXYXNoaW5ndG9uLiBXZSB3aWxs IHN0YXJ0IGJvYXJkaW5nIHNob3J0bHkuIEhvcGVmdWxseSBvdGhlcg0KIHNldmVyYWwgaHVuZHJl ZCBwYXNzZW5nZXJzICZuYnNwO3dpbGwgJm5ic3A7c2hvdyB1cC4gSWYgbm90LCBkb27igJl0IHdv cnJ5LCB3ZSB3aWxsIGZseSB5b3UgYWxvbmUuIFRoYW5rIHlvdSBmb3IgY2hvb3NpbmcgQWlyIENo aW5h4oCdLiBBcyB5b3Uga25vdywgdGhpbmdzIGRvIG5vdCB3b3JrIHRoaXMgd2F5OiBBaXIgQ2hp bmEgcHJlLXBsYW5zIGl0cyBmbGlnaHRzIHZlcnkgY2FyZWZ1bGx5LCBiYXNlZCBvbiBmYXIgbW9y ZSBkYXRhIHRoYW4gTXIuWmhhbmfigJlzIHJlcXVlc3QNCiBhbmQgaW4gYSBkaWZmZXJlbnQgdGlt ZSBmcmFtZSAobG9uZyBiZWZvcmUgaXQgc3RhcnRzIGZseWluZyBwZW9wbGUpLiBUaGlzIHByZS1w bGFubmluZyBtYXkgcHJvdmUsIGZvciBleGFtcGxlLCB0aGF0IGluc3RlYWQgb2YgY3JlYXRpbmcg YSBub24tc3RvcCBmbGlnaHQgdG8gV2FzaGluZ3RvbiwgaXQgaXMgYmV0dGVyIGVjb25vbWljcy13 aXNlIHRvIGNyZWF0ZSB0d28gZmxpZ2h0czogQmVpamluZy1Mb25kb24gYW5kIExvbmRvbi1XYXNo aW5ndG9uLg0KIEluIHRoZSBjb250ZXh0IG9mIHRoaXMgYW5hbG9neSwgVkxzIGFyZSBmbGlnaHRz IHRoYXQgZG8gbm90IGhhdmUgY29tbWl0dGVkIHBsYW5lcywgaW5zdGVhZCwgdGhlcmUgaXMgYSBw b29sIG9mIHBsYW5lcyB0aGF0IGlzIHNoYXJlZCBiZXR3ZWVuIGEgZ3JvdXAgb2YgZmxpZ2h0cy4g SW4gYWxsIG90aGVyIHJlc3BlY3RzIHRoZSDigJx2aXJ0dWFs4oCdIGZsaWdodHMgYXJlIG5vIGRp ZmZlcmVudCBmcm9tIHRoZSDigJxyZWFs4oCdIGZsaWdodHMsIGluIHBhcnRpY3VsYXIsDQogdGhl eSBhcmUgc3ViamVjdCBmb3IgdGhlIHNhbWUgdGVkaW91cyBwbGFubmluZyBwcm9jZXNzLCBoZW5j ZSBpdCBpcyBiZXR0ZXIgdG8gdXNlIHRoZXNlIHZpcnR1YWwgZmxpZ2h0cyB0aGFuIHRvIGNyZWF0 ZSBmbGlnaHRzIG9uIHRoZSBmbHkgOj0pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5JZ29yPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkJSLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+LVBhdmFuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj49PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvc3Bhbj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkEgdmlydHVhbCBURSBsaW5rIGlzIGRl ZmluZWQgYXMgYSBURSBsaW5rIGJldHdlZW4gdHdvIHVwcGVyLWxheWVyIG5vZGVzDQogdGhhdCBp cyBub3QgYXNzb2NpYXRlZCB3aXRoIGEgZnVsbHkgcHJvdmlzaW9uZWQgRkEtTFNQIGluIGEgbG93 ZXIgbGF5ZXIgWzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUyMTIiIHRh cmdldD0iX2JsYW5rIiB0aXRsZT0iJnF1b3Q7UmVxdWlyZW1lbnRzIGZvciBHTVBMUy1CYXNlZCBN dWx0aS0gUmVnaW9uIGFuZCBNdWx0aS1MYXllciBOZXR3b3JrcyAoTVJOL01MTikmcXVvdDsiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO3RleHQtZGVjb3JhdGlvbjpub25lIj5SRkM1MjEyPC9z cGFuPjwvYT5dLiZuYnNwOw0KIEEgdmlydHVhbCBURSBsaW5rIGlzIGFkdmVydGlzZWQgYXMgYW55 IFRFIGxpbmssIGZvbGxvd2luZyB0aGUgcnVsZXMgaW4gWzxhIGhyZWY9Imh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzQyMDYiIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iJnF1b3Q7TGFiZWwg U3dpdGNoZWQgUGF0aHMgKExTUCkgSGllcmFyY2h5IHdpdGggR2VuZXJhbGl6ZWQgTXVsdGktUHJv dG9jb2wgTGFiZWwgU3dpdGNoaW5nIChHTVBMUykgVHJhZmZpYyBFbmdpbmVlcmluZyAoVEUpJnF1 b3Q7Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDt0ZXh0LWRlY29yYXRpb246bm9uZSI+UkZD NDIwNjwvc3Bhbj48L2E+XQ0KIGRlZmluZWQgZm9yIGZ1bGx5IHByb3Zpc2lvbmVkIFRFIGxpbmtz LiZuYnNwOyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDcwQzA7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkEgdmlydHVhbCBURSBsaW5rIHJlcHJlc2VudHMg dGh1cyB0aGUNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkO21z by1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5wb3RlbnRpYWxpdHk8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDcwQzA7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PiB0byBzZXQgdXAgYW4gRkEtTFNQPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4NCiBpbiB0aGUgbG93ZXIg bGF5ZXIgdG8gc3VwcG9ydCB0aGUgVEUgbGluayB0aGF0IGhhcyBiZWVuIGFkdmVydGlzZWQuPC9z cGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9zcGFuPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7Jm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246anVzdGlmeSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+QmVzdCBSZWdhcmRzPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3Rl eHQtYWxpZ246anVzdGlmeSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246anVzdGlmeSI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+RmF0 YWk8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPg0KPGEgaHJlZj0ibWFpbHRvOmNjYW1wLWJvdW5jZXNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5jY2FtcC1ib3VuY2VzQGlldGYub3JnPC9hPiBbbWFp bHRvOjxhIGhyZWY9Im1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+Y2NhbXAtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlZpc2hu dSBQYXZhbiBCZWVyYW08YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgQXByaWwgMTYsIDIwMTMg MTA6MTAgUE08YnI+DQo8Yj5Ubzo8L2I+IEtodXplbWEgUGl0aGV3YW48L3NwYW4+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86Y2NhbXBA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5jY2FtcEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtDQ0FNUF0gTUVMR3MgLSBRJmFtcDtBPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5LaHV6ZW1hLCBIaSE8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj5NRUxHcyBhcmUgdXNlZnVsIGFuZCBjb21lIGludG8gcGxh eSBvbmx5IHdoZW46PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PigxKSBUaGUgc2VydmVyIG5ldHdvcmsgZG9tYWluIGlzIGFic3RyYWN0ZWQgYW5kIHRoZSBhZHZl cnRpc2VkIFZpcnR1YWwgVEUtbGlua3MgcG9zc2VzcyBzb21lIG11dHVhbCBleGNsdXNpdml0eSBy ZWxhdGlvbnNoaXAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PigyKSBUaGVyZSBpcyBhIENlbnRyYWxpemVkIHBhdGggY29tcHV0YXRpb24gZW50aXR5IGluIHRo ZSBjbGllbnQgZG9tYWluIChjb21wdXRlcyBwYXRocyBpbiB0ZXJtcyBvZiBDbGllbnQgVEUtbGlu a3MvVEUtbm9kZXMpIHRoYXQgaXMgY2FwYWJsZQ0KIG9mIGRvaW5nIGNvbmN1cnJlbnQgcGF0aCBj b21wdXRhdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5JZiBl aXRoZXIgb2YgdGhlIGFib3ZlIDIgc3RhdGVtZW50cyBpcyBOT1QgdHJ1ZSwgdGhlcmUgaXMgbm8g dXRpbGl0eSBmb3IgTUVMR3MuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPkF0IHRoZSByaXNrIG9mIGJlaW5nIHBlZGFudGljOiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4tIEFyZSBNRUxHcyBuZWVkZWQg d2hlbiB0aGUgc2VydmVyLW5ldHdvcmsgZG9tYWluIGluIG5vdCBhYnN0cmFjdGVkIChubyBWaXJ0 dWFsIFRFIGxpbmtzKT8gVGhlIGFuc3dlciBpcyBOTy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+LSBBcmUgTUVMR3MgbmVlZGVkIHdoZW4geW91IGhhdmUgYSBk aXN0cmlidXRlZCBwYXRoLWNvbXB1dGF0aW9uIGFyY2hpdGVjdHVyZSAoQ2xpZW50IFBDRSBpbnRl cmFjdGluZyB3aXRoIFNlcnZlciBQQ0UpPyBUaGUgYW5zd2VyIGlzIE5PLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4tIEFyZSBNRUxHcyBuZWVkZWQgd2hlbiB0 aGUgY2VudHJhbGl6ZWQgcGF0aC1jb21wdXRhdGlvbiBlbmdpbmUgZG9lc24ndCAoY2FuJ3QpIGRv IGNvbmN1cnJlbnQgY29tcHV0YXRpb25zPyBUaGUgYW5zd2VyIGlzIE5PLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+VGhlIGFjdHVhbCBwcm9jZWR1cmVzIGludm9sdmVk IGluIGFic3RyYWN0aW5nIHRoZSBzZXJ2ZXIgbmV0d29yayBkb21haW4gaXMgYmV5b25kIHRoZSBz Y29wZSBvZiAmbHQ7ZHJhZnQtbWVsZ3MmZ3Q7LiBUaGUgYWJzdHJhY3Rpb24gcHJvY2VkdXJlDQog aXRzZWxmIGlzIGltcGxlbWVudGF0aW9uLXNwZWNpZmljIChtYXliZSBzb21lZGF5IHNvbWVvbmUg d291bGQgcHV0IHRvZ2V0aGVyIGEgZHJhZnQgZm9yIGRpc2N1c3NpbmcgdGhpcykuIFRob3VnaCBp dCBpcyB0cnVlIHRoYXQgdGhlIHByaW1hcnkgdXNlLWNhc2Ugd2UgaGFkIGluIG1pbmQgd2hlbiBj b21pbmcgdXAgd2l0aCB0aGlzIG5ldyBjb25zdHJ1Y3QgaW52b2x2ZXMgYSBsYW1iZGEtbGF5ZXIg c2VydmVyIG5ldHdvcmsgZG9tYWluLCB0aGVyZQ0KIGlzIHJlYWxseSBubyByZXN0cmljdGlvbiAo YXQgYSBjb25jZXB0dWFsIGxldmVsKSBvbiB1c2luZyB0aGlzIGNvbnN0cnVjdCB3aGVuIGFic3Ry YWN0aW5nIGEgcGFja2V0LWxheWVyIHNlcnZlciBuZXR3b3JrIGRvbWFpbiBvciBhIFRETS1sYXll ciBzZXJ2ZXIgbmV0d29yayBkb21haW4uIEl0IGlzIHVwIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBv biBob3cgdG8gbWFrZSBiZXN0IHVzZSBvZiB0aGlzIGNvbnN0cnVjdC4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPldoZW4geW91IGFkdmVydGlzZSBhIFZpcnR1 YWwgVEUtbGluayBpbnRvIGEgY2xpZW50IG5ldHdvcmsgZG9tYWluLCB5b3UgYXJlIGRvaW5nIHRo aXMgYmFzZWQgb24gdGhlIGV4aXN0ZW5jZSBvZiBzb21lIHBvdGVudGlhbCB1bmRlcmx5aW5nDQog c2VydmVyLXBhdGguIFRFIGF0dHJpYnV0ZXMgbGlrZSBTUkxHcywgTUVMR3MsIGRlbGF5IGV0YyB0 aGF0IGdldCBhZHZlcnRpc2VkIGZvciB0aGUgVmlydHVhbCBURS1saW5rIGRlcGVuZCBvbiB0aGUg dW5kZXJseWluZyBzZXJ2ZXItcGF0aCB0aGF0IGlzIGNob3NlbiBmb3IgY2F0ZXJpbmcgdG8gdGhp cyBDbGllbnQgVEUtbGluay4gSWYgdGhlIHVuZGVybHlpbmcgc2VydmVyLXBhdGgga2VlcHMgY2hh bmdpbmcgKGJhc2VkIG9uIG5ldHdvcmsgZXZlbnRzKSwNCiB0aGVzZSBURSBhdHRyaWJ1dGVzIHdv dWxkIGFsc28ga2VlcCBjaGFuZ2luZy4gVGhlIHByb2NlZHVyZSBmb3Iga2VlcGluZyB0aGUgYWR2 ZXJ0aXNlZCBpbmZvcm1hdGlvbiAmcXVvdDtjdXJyZW50JnF1b3Q7IGlzIGFuIGltcGxlbWVudGF0 aW9uIGNob2ljZS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PklmIHRoZXJlIGV4aXN0cyBzdWNoIGEgdGhpbmcgYXMgYW4gYWJzdHJhY3Rpb24gbWFuYWdlciAo YWdhaW4sIHRoaXMgaXMgdG90YWxseSBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYyksIHRoZW4gdGhl IGFzc3VtcHRpb24gaXMgdGhhdCBpdA0KIGRvZXMgb25lIG9mIHRoZSBmb2xsb3dpbmcgLSZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4oYSkgY29tcHV0 ZXMgbmV3IHNlcnZlci1wYXRocyBmb3IgdGhlIFZpcnR1YWwgVEUgbGlua3Mgd2hlbmV2ZXIgdGhl cmUgaXMgYSBjaGFuZ2UgaW4gdGhlIG5ldHdvcmsgKG1heSBub3QgYmUgdmVyeSBzY2FsYWJsZSBp biBzb21lIGFyY2hpdGVjdHVyZXMpLCZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj4oYikgb3IgZG9lcyBwZXJpb2RpYyBwYXRoLWNvbXB1dGF0aW9uIGZv ciBlYWNoIFZpcnR1YWwgVEUgbGluaywmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+KGMpIG9yIHVzZXMgYSBwb2xpY3kgdG8gcGluIGRvd24gdGhlIFZp cnR1YWwgVEUtbGluayB0byBhIHNwZWNpZmljIHVuZGVybHlpbmcgc2VydmVyLXBhdGgsJm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPihkKSBvciB1c2Vz IGEgY29tYmluYXRpb24gb2YgKGEpLCAoYiksIChjKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPiZsdDtkcmFmdC1tZWxncyZndDsgZG9lc24ndCBtYWtlIGFueSByZWNv bW1lbmRhdGlvbiBhcyB0byB3aGF0IGNob2ljZSB0aGUgYWJzdHJhY3Rpb24gbWFuYWdlciB3b3Vs ZCBuZWVkIHRvIHRha2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5I b3BlIHRoaXMgaGVscHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPi1QYXZhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5PbiBUdWUsIEFwciAx NiwgMjAxMyBhdCA3OjA4IEFNLCBLaHV6ZW1hIFBpdGhld2FuICZsdDs8YSBocmVmPSJtYWlsdG86 a3BpdGhld2FuQGluZmluZXJhLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmtwaXRoZXdhbkBpbmZpbmVy YS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkhpIElnb3IsPC9zcGFuPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+SSBhbSB0cnlpbmcgdG8gc3Vt bWFyaXplIHRoZSBkaXNjdXNzaW9uIHdlIGhhZCBzbyBmYXIuIFBscyBzZWUgaWYgbXkgY29uY2x1 c2lvbg0KIGlzIGluIHN5bmMgd2l0aCB0aGUgaWRlYSBvZiBNRUxHIHlvdSBoYXZlIDwvc3Bhbj48 c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPk1FTEcgaXMgdXNlZnVs IHdoZW48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+MS48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+c2VydmVyIGxheWVyIFZMcyBhcmUgbmFpbGVkIGRvd24gZm9yIHRoZSByZXNvdXJjZXMgb24g dGhlIHNlcnZlciBsYXllciBsaW5rcyB0aGF0IGFyZSBzaGFyZWQgYW1vbmcgbXVsdGlwbGUgVkxz LiBUaGVzZSByZXNvdXJjZXMgYXJlIHR5cGljYWxseQ0KIHdhdmVsZW5ndGggb24gYSBmaWJlciAo Y2FuIGl0IGJlIGFueXRoaW5nIGVsc2U/PykuIEluIG90aGVyIHdvcmRzLCBpZiAyIFZMcyBhcmUg cGlubmVkIHRvIHVzZSBhIHBhcnRpY3VsYXIgd2F2ZWxlbmd0aCBvbiBhIHBhcnRpY3VsYXIgZmli ZXIsIHRoZW4gdGhlc2UgMiBWTHMgd2lsbCBoYXZlIE1FTEcgZm9yIHRoZSB3YXZlbGVuZ3RoLjwv c3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4yLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuMHB0O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5zZXJ2 ZXIgbGF5ZXIgZG8gbm90IGhhdmUgY2VudHJhbGl6ZWQgcGF0aCBjb21wdXRhdGlvbiBlbnRpdHkg d2hpY2ggY2FuIGJlIHVzZWQgYnkgY2xpZW50IGxheWVyIHRvIGFzayBmb3IgY29uY3VycmVudCBk aXZlcnNlIHBhdGggY29tcHV0YXRpb24gd2l0aGluDQogc2VydmVyIGxheWVyLjwvc3Bhbj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj4zLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0 O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5DbGllbnQgbGF5ZXIg aGFzIGEgY2VudHJhbGl6ZWQgcGF0aCBjb21wdXRhdGlvbiBlbnRpdHksIHdoaWNoIHdvdWxkIGNv bXB1dGUgcGF0aHMgZm9yIGNsaWVudCYjNDM7c2VydmVyIGxheWVyLjwvc3Bhbj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj40Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5UaGUgbmVlZCBpcyB0byBjZW50 cmFsaXplZCBjb25jdXJyZW50IGNvbXB1dGF0aW9uIG9mIG1vcmUgdGhhbiBvbmUgY2xpZW50JiM0 MztzZXJ2ZXIgbGF5ZXIgcGF0aCB0aGF0IG1lZXRzIHNvbWUgZGl2ZXJzaXR5IGFuZCByZXNvdXJj ZSBleGNsdXNpdml0eQ0KIHJlcXVpcmVtZW50cy48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj5SZWdkczwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPktodXplbWE8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij4NCiBJZ29yIEJyeXNraW4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86SUJyeXNraW5AYWR2YW9w dGljYWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+SUJyeXNraW5AYWR2YW9wdGljYWwuY29tPC9hPl0N Cjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEFwcmlsIDE1LCAyMDEzIDk6NDQgUE08L3NwYW4+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48YnI+DQo8Yj5Ubzo8L2I+IEtodXplbWEgUGl0 aGV3YW47IFZpc2hudSBQYXZhbiBCZWVyYW08YnI+DQo8Yj5DYzo8L2I+IERpZXRlciBCZWxsZXI7 IDxhIGhyZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNjYW1wQGll dGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0NDQU1QXSBNRUxHcyAtIFEmYW1w O0E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPktodXplbWEsPC9zcGFuPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+UGxlYXNlLCBzZWUgaW4tbGluZS48L3Nw YW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5JZ29yPC9zcGFu PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+DQogS2h1emVtYSBQaXRoZXdhbiBbbWFpbHRvOjxhIGhy ZWY9Im1haWx0bzprcGl0aGV3YW5AaW5maW5lcmEuY29tIiB0YXJnZXQ9Il9ibGFuayI+a3BpdGhl d2FuQGluZmluZXJhLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBcHJpbCAx NSwgMjAxMyAxMjowNSBBTTxicj4NCjxiPlRvOjwvYj4gSWdvciBCcnlza2luOyBWaXNobnUgUGF2 YW4gQmVlcmFtPGJyPg0KPGI+Q2M6PC9iPiBEaWV0ZXIgQmVsbGVyOyA8YSBocmVmPSJtYWlsdG86 Y2NhbXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5jY2FtcEBpZXRmLm9yZzwvYT48YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUkU6IFtDQ0FNUF0gTUVMR3MgLSBRJmFtcDtBPC9zcGFuPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5IaSBJZ29yLDwvc3Bhbj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkkgdW5kZXJzdGFuZCB0aGUgU1JMRyBh bmQgTUVMRyBiZWhhdmlvciB5b3UgaGF2ZSBwZW5uZWQgLjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPk15IGNvbmNlcm4gd2FzIGxpdHRsZSBkaWZmZXJl bnQuJm5ic3A7IFdpdGggY2hhbmdpbmcgcmVzb3VyY2UgY29uc3VtcHRpb24gKGJlY2F1c2UNCiBv ZiBkeW5hbWljaXR5IHRoZSBuZXR3b3JrIGhhcykgaW4gdGhlIG5ldHdvcmsgbGlua3MsIHBvdGVu dGlhbCBwYXRocyBhIHNldCBvZiB2aXJ0dWFsIGxpbmsgY2FuIHRha2Ugd2lsbCBjaGFuZ2UgYW5k IGhlbmNlIGl0cyBNRUxHLCBhcyBpdCBpcyB0aWVkIHRvIGEgcmVzb3VyY2UgaXQgY2FuIHRha2Uu IFNvIHVubGVzcyB2aXJ0dWFsIGxpbmtzIHBhdGhzIGFyZSBuYWlsZWQgZG93biwgaXQgd291bGQg YmUgaGFyZCB0byBjb21wdXRlIE1FTEdzIGluDQogZGlzdHJpYnV0ZWQgd2F5Ljwvc3Bhbj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPklCJmd0OyZndDsgSSB0aGlu ayB5b3UgYXJlIG1pc3NpbmcgdGhlIHBvaW50IGhlcmUuIFZpcnR1YWwgTGluayBzZXJ2ZXIgbGF5 ZXINCiBwYXRocyBhcmUgcGlubmVkIGFzIGZhciBhcyBmYXRlIHNoYXJpbmcgaXMgY29uY2VybmVk ICh0aGF0IGlzLCB0aGV5IGFyZSBwaW5uZWQgb24gJm5ic3A7c2VydmVyIGxheWVyIGxpbmsgbGV2 ZWwpLiBJdCB3b3VsZCBtYWtlIGxpdHRsZSBzZW5zZSB0byBhZHZlcnRpc2UgVkwgU1JMR3MgaWYg dGhlIFNSTEdzIGNvbnN0YW50bHkgY2hhbmdlLiBUaGUgc2FtZSBpcyB0cnVlIGZvciBNRUxHcy4g Jm5ic3A7U1JMR3MvTUVMR3MgYWR2ZXJ0aXNlZCBmb3IgVkxzIG5vcm1hbGx5DQogZG8gbm90IGNo YW5nZTogbmVpdGhlciBvdmVyIHRpbWUgbm9yIHdoZW4gVkxzIGJlY29tZSBjb21taXR0ZWQvdW5j b21taXR0ZWQuPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+QW5vdGhlciBwb2ludCBpcywgdmlydHVhbCBsaW5rcyBjYW4gYmUgdmlld2VkIGFzIG92ZXJz dWJzY3JpcHRpb24gb2YgcmVzb3VyY2VzDQogKGluIE1FTEcgY29udGV4dCkuIFRha2luZyBhbiBl eGFtcGxlIChmb3IgT1ROLCBJIGtub3cgaXQgd291bGQgd29yayBkaWZmZXJlbnRseSBmb3IgYSBX YXZlbGVuZ3RoIGluIFdETSksIGEgbGluayByZXNvdXJjZXMgYXJlIHdvcnRoIDEgVEIgb2YgQlcs IHVzZXIgaGFzIHByb3Zpc2lvbmVkIDIwIHZpcnR1YWwgbGlua3Mgb2YgMTAwRyBlYWNoIGdvaW5n IHZpYSB0aGF0IE9UTiBsaW5rLiAmbmJzcDtQaHlzaWNhbGx5LCBvbmx5IDEwIHdpbGwgZ2V0IGNv bW1pdHRlZC4NCiBCdXQgd2hpY2ggMTA/IEl0IHdpbGwgcmVhbGx5IGRlcGVuZCBvbiBuZXR3b3Jr IGR5bmFtaWNzIGF0IHRoZSB0aW1lIG9mIGRlbWFuZCB0byBjb21taXQuIE1FTEdzIGFyZSBub3Qg dGhhdCBlZmZlY3RpdmUgaGVyZS4gWW91IG5lZWQgc29tZSBkaWZmZXJlbnQgbWVjaGFuaXNtLjwv c3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwv c3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPklCJmd0OyZn dDsgQXMgSSBtZW50aW9uZWQgYmVmb3JlIE1FTEdzIGhhdmUgbm90aGluZyB0byBkbyB3aXRoIGJh bmR3aWR0aCBhbmQNCiB3ZXJlIG5ldmVyIGludGVuZGVkIHRvIHNvbHZlIHRoZSBwcm9ibGVtcyBz dWNoIGFzIHlvdSBkZXNjcmliZSAoanVzdCBsaWtlIGl0IHdvdWxkIG5vdCBtYWtlIG11Y2ggc2Vu c2UgdG8gc29sdmUgc3VjaCBwcm9ibGVtIHdpdGggU1JMR3MgOj0pPC9zcGFuPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+QWdhaW4sICZuYnNwO01FTEcgaXMgYW4g ZXh0cmVtZSBjYXNlIFNSTEcgZGVzaWduZWQgZXhjbHVzaXZlbHkgZm9yIFZMcyAobm8NCiBtb3Jl IGFuZCBubyBsZXNzKS48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj5SZWdkczwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPktodXplbWE8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4NCiBJZ29yIEJyeXNr aW4gWzxhIGhyZWY9Im1haWx0bzpJQnJ5c2tpbkBhZHZhb3B0aWNhbC5jb20iIHRhcmdldD0iX2Js YW5rIj5tYWlsdG86SUJyeXNraW5AYWR2YW9wdGljYWwuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBGcmlkYXksIEFwcmlsIDEyLCAyMDEzIDExOjU1IFBNPGJyPg0KPGI+VG86PC9iPiBLaHV6 ZW1hIFBpdGhld2FuOyBWaXNobnUgUGF2YW4gQmVlcmFtPGJyPg0KPGI+Q2M6PC9iPiBEaWV0ZXIg QmVsbGVyOyA8YSBocmVmPSJtYWlsdG86Y2NhbXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5j Y2FtcEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtDQ0FNUF0gTUVMR3Mg LSBRJmFtcDtBPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5L aHV6ZW1hLDwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PlRoaW5rIGFib3V0IE1FTEcgYXMgYW4gU1JMRyB0aGF0IGlzIHNoYXJlZCBiZXR3ZWVuIHR3byBv ciBtb3JlIGxpbmtzIGluDQogaXRzIGVudGlyZXR5LiBXaGVuIHR3byByZWFsIGxpbmtzIGhhdmUg YW4gU1JMRyBpbiBjb21tb24sIGl0IG1lYW5zIHRoYXQgdHdvIHJlYWwgbGlua3MgY2FuIGNvLWV4 aXN0IGNvbmN1cnJlbnRseSwgYnV0IHRoZXJlIGlzIHNvbWV0aGluZyAoZS5nLiBjb21tb24gY29u ZHVpdCwgbm90ZSB0aGF0IHRoZSBjb25kdWl0IGhhcyByb29tIGZvciBtb3JlIHRoYW4gZm9yIG9u ZSBsaW5rKSB0aGF0IHdpbGwgYnJpbmcgYm90aCB0aGVzZSBsaW5rcyBkb3duLA0KIGlmIHRoaXMg c29tZXRoaW5nIGZhaWxzIChlLmcuIGNvbmR1aXQgaXMgY3V0ICkuIE5vdyBjb25zaWRlciB0aGF0 IHRoaXMgc29tZXRoaW5nIG11c3QgYmUgdGFrZW4gaW4gaXRzIGVudGlyZXR5IGJ5IG9uZSBvZiB0 aGUgbGlua3MgdG8gYmVjb21lIG9wZXJhdGlvbmFsIC4gSW4gdGhpcyBjYXNlIFNSTEcgYmVjb21l cyBNRUxHLiBOb3RlIHRoYXQgTUVMRyBpcyBvbmx5IG1lYW5pbmdmdWwgZm9yIHZpcnR1YWwgbGlu a3MgKHVubGlrZSBTUkxHIHRoYXQNCiBtYWtlcyBzZW5zZSBmb3IgZWl0aGVyIHJlYWwgb3Igdmly dHVhbCBsaW5rKS4gV2h5IHdvdWxkIHlvdSBhZHZlcnRpc2UgdHdvIGxpbmtzIHRoYXQgbXV0dWFs bHkgZXhjbHVkZSBlYWNoIG90aGVyIHJhdGhlciB0aGFuIGFkdmVydGlzaW5nIG9ubHkgb25lIG9m IHRoZW0gYXQgYSB0aW1lLCB1bmxlc3MgdGhlIHR3byBhcmUgdmlydHVhbCBsaW5rcyBhbmQgaGVu Y2UgYm90aCBhdmFpbGFibGUgZm9yIHRoZSBjbGllbnQgbGF5ZXIgY29ubmVjdGlvbnM/PC9zcGFu PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+SWdvcg0KPC9zcGFu PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+DQogS2h1emVtYSBQaXRoZXdhbiBbPGEgaHJlZj0ibWFp bHRvOmtwaXRoZXdhbkBpbmZpbmVyYS5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86a3BpdGhl d2FuQGluZmluZXJhLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBBcHJpbCAx MiwgMjAxMyAxOjAxIFBNPGJyPg0KPGI+VG86PC9iPiBJZ29yIEJyeXNraW47IFZpc2hudSBQYXZh biBCZWVyYW08YnI+DQo8Yj5DYzo8L2I+IERpZXRlciBCZWxsZXI7IDxhIGhyZWY9Im1haWx0bzpj Y2FtcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNjYW1wQGlldGYub3JnPC9hPjxicj4NCjxi PlN1YmplY3Q6PC9iPiBSRTogW0NDQU1QXSBNRUxHcyAtIFEmYW1wO0E8L3NwYW4+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkhpIElnb3IsPC9zcGFuPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+RG8geW91IG1lYW4sIGlmIHZpcnR1YWwg bGluayBkbyBub3QgaGF2ZSBhbnkgc3BlY2lmaWMgY29uc3RyYWludCwgZm9yDQogZXhhbXBsZSBh IGxpbmsgaW4gdGhlIHBhdGggKG5vdCB0YWxraW5nIGFib3V0IGVncmVzcyBsaW5rcy9pbnRlcmZh Y2VzKSBtdXN0IGJlIHRyYXZlcnNlZCB0byByZWFsaXplIHRoZSB2aXJ0dWFsIGxpbmssIHRoZXJl IHdvbnQgYmUgYW55IE1FTEcgZm9yIHRoZSB2aXJ0dWFsIGxpbms/PC9zcGFuPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+UmVnZHM8L3NwYW4+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5LaHV6ZW1hPC9zcGFuPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+DQogSWdvciBCcnlza2luIFs8YSBocmVmPSJtYWlsdG86SUJyeXNraW5AYWR2 YW9wdGljYWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOklCcnlza2luQGFkdmFvcHRpY2Fs LmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBBcHJpbCAxMiwgMjAxMyA5OjUy IFBNPGJyPg0KPGI+VG86PC9iPiBLaHV6ZW1hIFBpdGhld2FuOyBWaXNobnUgUGF2YW4gQmVlcmFt PGJyPg0KPGI+Q2M6PC9iPiBEaWV0ZXIgQmVsbGVyOyA8YSBocmVmPSJtYWlsdG86Y2NhbXBAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5jY2FtcEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUkU6IFtDQ0FNUF0gTUVMR3MgLSBRJmFtcDtBPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj5LaHV6ZW1hLDwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPk1FTEdzIGhhdmUgbm90aGluZyB0byBkbyB3aXRoIGJh bmR3aWR0aC4gTUVMRyBpcyBhIGNvbmNyZXRlIG5ldHdvcmsgcmVzb3VyY2UNCiBpbiBhIHNlcnZl ciBsYXllciB0aGF0IHR3byBvciBtb3JlIFZpcnR1YWwgTGlua3MgaW4gYSBjbGllbnQgbGF5ZXIg ZGVwZW5kIG9uIGluIGEgbXV0dWFsbHkgZXhjbHVzaXZlIHdheS4gQW4gZXhhbXBsZSBvZiBNRUxH IGlzIGEgV0RNIGxheWVyIHRyYW5zcG9uZGVyIHRoYXQgY2FuIHRlcm1pbmF0ZSBlaXRoZXIgb2Yg cmVzcGVjdGl2ZSBXRE0gbGF5ZXIgdHVubmVscyAoYnV0IG5vdCBib3RoIGF0IHRoZSBzYW1lIHRp bWUpIGZvciB0d28gT1ROIGxheWVyDQogVmlydHVhbCBMaW5rcy4gSWYgeW91IGFkdmVydGlzZSBh IFZpcnR1YWwgTGluaywgc2F5LCBmb3IgRXRoZXJuZXQgbGF5ZXIgdGhhdCBkZXBlbmRzIG9uIHRo ZSBjb25uZWN0aW9uIGluIE9UTiBsYXllciBnb2luZyB0aHJvdWdoIG9uZSBvZiB0aGUgbWVudGlv bmVkIE9UTiBsaW5rcywgdGhlIEV0aGVybmV0IFZMIG11c3QgaW5oZXJpdCB0aGUgTUVMRyBzaW1p bGFybHkgbGlrZSBpdCBkb2VzIFNSTEdzIGFkdmVydGlzZWQgZm9yIHRoZSBPVE4gbGlua3MuPC9z cGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+SWdvcjwvc3Bh bj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPg0KIEtodXplbWEgUGl0aGV3YW4gWzxhIGhyZWY9Im1h aWx0bzprcGl0aGV3YW5AaW5maW5lcmEuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOmtwaXRo ZXdhbkBpbmZpbmVyYS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgQXByaWwg MTIsIDIwMTMgMTI6MDYgUE08YnI+DQo8Yj5Ubzo8L2I+IElnb3IgQnJ5c2tpbjsgVmlzaG51IFBh dmFuIEJlZXJhbTxicj4NCjxiPkNjOjwvYj4gRGlldGVyIEJlbGxlcjsgPGEgaHJlZj0ibWFpbHRv OmNjYW1wQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Y2NhbXBAaWV0Zi5vcmc8L2E+PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJFOiBbQ0NBTVBdIE1FTEdzIC0gUSZhbXA7QTwvc3Bhbj48c3BhbiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+SGkgSWdvciw8L3NwYW4+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Gb3IgbXVsdGktbGF5ZXIgKG1vcmUg dGhhbiAyKSBuZXR3b3JrLCBjb25zaWRlciBhbGwgdGhlIGxheWVycyBhcmUgbWVzaHkNCiAodGhh dOKAmXMgd2hlbiB2aXJ0dWFsIGxpbmtzIGFyZSB1c2VmdWwgYW55d2F5KSwgTUVMR3Mgb2Ygdmly dHVhbCBsaW5rIHdpbGwgY2hhbmdlIGFzIGFuZCB3aGVuIEJXL3dhdmVsZW5ndGggYXZhaWxhYmls aXR5IGNoYW5nZXMsIGJlY2F1c2UgcG90ZW50aWFsIHBhdGhzLCBhIHZpcnR1YWwgbGluayBjYW4g dGFrZSB3aWxsIGNoYW5nZS4gTWFwcGluZyBsb3dlciBsYXllciBNRUxHcyB0byBoaWdoZXIgbGF5 ZXIgTUVMR3Mgd29u4oCZdCBiZSBwcmFjdGljYWwNCiBpZiBkb25lIGluIGRpc3RyaWJ1dGVkIG1h bm5lciwgc28gaXQgaGFzIHRvIGJlIGNlbnRyYWxpemVkLiBTbyB5b3UgZG8gaGF2ZSBjZW50cmFs IGVsZW1lbnQgaW4gZWFjaCBsYXllciB0aGF0IGtub3dzIGFsbCB0aGUgcmlzayBhbmQgcGF0aHMg KGEgUENFPyksIHdoaWNoIGNhbiBiZSB1dGlsaXplZCBmb3IgbGF5ZXIgc3BlY2lmaWMgcGF0aCBj b21wdXRhdGlvbiAoYXMgaXQgaXMgZG9pbmcgaXQgYW55d2F5KS4NCjwvc3Bhbj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlRoaXMga2luZCBvZiBhcmNoaXRlY3R1 cmUgaGFzIGFsbCB0aGUgcGllY2VzIHRoYXQgYXJlIHJlcXVpcmVkIGZvciBJbnRlci1QQ0UNCiBj b21tdW5pY2F0aW9uIChhY3Jvc3MgbGF5ZXJzKSwgZXhjZXB0IHRoZSBwcm90b2NvbCB0aGF0IHdv dWxkIGFjdHVhbGx5IG1ha2UgdGhlIDIgUENFcyB0YWxrLjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPllvdSBzZWVtIHRvIGJlIGRvaW5nIHNvbWV0aGlu ZyB0aGF0IHlvdSBkb27igJl0IGxpa2UNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+Sjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPlJlZ2FyZHM8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj5LaHV6ZW1hPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+DQogSWdvciBCcnlz a2luIFs8YSBocmVmPSJtYWlsdG86SUJyeXNraW5AYWR2YW9wdGljYWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+bWFpbHRvOklCcnlza2luQGFkdmFvcHRpY2FsLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50 OjwvYj4gRnJpZGF5LCBBcHJpbCAxMiwgMjAxMyA4OjM5IFBNPGJyPg0KPGI+VG86PC9iPiBLaHV6 ZW1hIFBpdGhld2FuOyBWaXNobnUgUGF2YW4gQmVlcmFtPGJyPg0KPGI+Q2M6PC9iPiBEaWV0ZXIg QmVsbGVyOyA8YSBocmVmPSJtYWlsdG86Y2NhbXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5j Y2FtcEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtDQ0FNUF0gTUVMR3Mg LSBRJmFtcDtBPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5L aHV6ZW1hLDwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PkkgYW0gbm90IGEgZmFuIG9mIGludGVyLWxheWVyIHBhdGggY29tcHV0YXRpb25zIChub3IgSSBh bSBhIGZhbiBvZiBpbnRlci1QQ0UNCiBjb21wdXRhdGlvbnMpLiBJbiBteSBtaW5kIHBhdGggY29t cHV0YXRpb24gZm9yIGEgc2VydmljZSBvciBzZXJ2aWNlcyBpbiBsYXllciBYIGlzIHBlcmZvcm1l ZCBvbmx5IGluIGxheWVyIFgsIGkuZS4gY29uc2lkZXJzIG9ubHkgWCBsYXllciBsaW5rcyAocmVh bCBvciB2aXJ0dWFsKS4gQXMgUGF2YW4gbWVudGlvbmVkIFNSTEdzIGFuZCBNRUxHcyB0aGF0IG5l ZWQgdG8gYmUgaW5oZXJpdGVkIGZyb20gbG93ZXIgbGF5ZXJzIHNob3VsZCBiZSB0cmFuc2xhdGVk DQogaW50byBYIGxheWVyIGxpbmsgU1JMR3MvTUVMR3MgYW5kIHNwZWNpZmllZCB3aXRoIFggbGF5 ZXIgc3BlY2lmaWMgU1JMRy9NRUxHIElEcy48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj5DaGVlcnMsPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+SWdvcjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPg0K IEtodXplbWEgUGl0aGV3YW4gWzxhIGhyZWY9Im1haWx0bzprcGl0aGV3YW5AaW5maW5lcmEuY29t IiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOmtwaXRoZXdhbkBpbmZpbmVyYS5jb208L2E+XQ0KPGJy Pg0KPGI+U2VudDo8L2I+IEZyaWRheSwgQXByaWwgMTIsIDIwMTMgMTA6NTUgQU08YnI+DQo8Yj5U bzo8L2I+IElnb3IgQnJ5c2tpbjsgVmlzaG51IFBhdmFuIEJlZXJhbTxicj4NCjxiPkNjOjwvYj4g RGlldGVyIEJlbGxlcjsgPGEgaHJlZj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+Y2NhbXBAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbQ0NBTVBd IE1FTEdzIC0gUSZhbXA7QTwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+SGkgSWdvciw8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj5Pay4gVGhpcyB3b3VsZCBiZSB1c2VmdWwgaWYgbmV0d29yayBhcmNoaXRlY3R1cmUg aXMgYmFzZWQgb24gZXh0ZXJuYWwNCiBQQ0Ugb3IgbWdtdCBlbnRpdHkgYXMgUENFIGluIGNsaWVu dCBsYXllciwgYnV0IHRoZXJlIGlzIG5vIGNvdW50ZXJwYXJ0IGluIHNlcnZlciBsYXllciwgb3Ro ZXJ3aXNlIG9uZSBjb3VsZCBoYXZlIGludGVyLVBDRSBjb21tdW5pY2F0aW9uIHRvIGFjaGlldmUg ZGl2ZXJzZSBwYXRoIGluIHNlcnZlciBsYXllciB3aXRob3V0IGdldHRpbmcgaW50byB2aXJ0dWFs IGxpbmsgYW5kIE1FTEcgc3R1ZmYuPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+SXMgdGhhdCBjb3JyZWN0Pzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPktodXplbWE8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj4NCiBJZ29yIEJyeXNraW4gWzxhIGhyZWY9Im1haWx0bzpJQnJ5c2tpbkBhZHZhb3B0aWNh bC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86SUJyeXNraW5AYWR2YW9wdGljYWwuY29tPC9h Pl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEFwcmlsIDEyLCAyMDEzIDY6MzYgUE08YnI+ DQo8Yj5Ubzo8L2I+IFZpc2hudSBQYXZhbiBCZWVyYW07IEtodXplbWEgUGl0aGV3YW48YnI+DQo8 Yj5DYzo8L2I+IERpZXRlciBCZWxsZXI7IDxhIGhyZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPmNjYW1wQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBS RTogW0NDQU1QXSBNRUxHcyAtIFEmYW1wO0E8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPktodXplbWEsPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1s ZWZ0OjEuMGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Mi48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3 LjBwdDtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Rm9yIGNhc2Vz IG9mIGNvbmN1cnJlbnQgY29tcHV0YXRpb24gKGNhc2UjMi01KSwgeW91IGFyZSBtYWlubHkgdGFs a2luZyBhYm91dCBnbG9iYWwgb3B0aW1pemF0aW9uIGFuZCBkaXZlcnNpdHkgYW1vbmcgbXVsdGlw bGUgc2VydmljZXMuIFlvdSBjYW4NCiBkbyB0aGUgcGF0aCBjb21wdXRhdGlvbiwgYnV0IHRvIGFj dHVhbGx5IGVuYWN0IHRoZSBjb21wdXRlZCBwYXRoIHRoZSBzaWduYWxpbmcgbmVlZHMgdG8gYmUg ZG9uZSBmcm9tIHRoZSBzb3VyY2UgZW5kIG9mIHRob3NlIExTUHMuJm5ic3A7IFNvIHRoZXJlIGlz IG5vIHBvaW50IGluIGRvaW5nIGNvbmN1cnJlbnQgY29tcHV0YXRpb24gYXQgb25lIG5ldHdvcmsg ZWxlbWVudCBmb3IgdGhlIHNlcnZpY2VzIHN0YXJ0aW5nIGZyb20gbXVsdGlwbGUgbmV0d29yaw0K IGVsZW1lbnRzLiBBdCBiZXN0IGl0IGxvb2tzIHRvIG1lIGEgcHJvYmxlbSB0byBiZSBzb2x2ZWQg YnkgbmV0d29yayBtYW5hZ2VtZW50L3BsYW5uaW5nIHNvZnR3YXJlLjwvc3Bhbj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPldlbGwsIHdoZW4gYW4gaW5n cmVzcyBub2RlIGlzIGluaXRpYXRpbmcgYSBzZXJ2aWNlLCBpdCBpcyBkb2luZyBzbyBvbg0KIHJl cXVlc3QgZnJvbSBzb21lIG1hbmFnZW1lbnQgZW50aXR5LiBUaGlzIG1hbmFnZW1lbnQgZW50aXR5 IGNhbiBjb21wdXRlIHBhdGhzIGZvciBtYW55IHNlcnZpY2VzIHdpdGggc29tZSBnbG9iYWwgY3Jp dGVyaWEgaW4gbWluZCwgYW5kIHRoZW4gc3BlY2lmeSB0aGUgcmVzdWx0aW5nIHBhdGhzIGFzIGV4 cGxpY2l0IEVST3MgaW4gcHJvdmlzaW9uaW5nIHJlcXVlc3RzIHNlbnQgdG8gZWFjaCBvZiB0aGUg c2VydmljZSBpbmdyZXNzZXMuIEhvdyBlbHNlLA0KIGZvciBleGFtcGxlLCAmbmJzcDt5b3UgY2Fu IHNldCB1cCBzZXZlcmFsIHNlcnZpY2VzIG9yaWdpbmF0ZWQgZnJvbSBkaWZmZXJlbnQgbm9kZXMg dGhhdCBhcmUgZGlzam9pbnQgZnJvbSBlYWNoIG90aGVyPyBBbHNvLCB3aGF0IGlzIHRoZSBwb2lu dCBpbiB5b3VyIG9waW5pb24gb2YgdGhlIHN0YXRlZnVsbCBQQ0Ugd29yaz8NCjwvc3Bhbj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkNoZWVycyw8L3NwYW4+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5JZ29yPC9zcGFuPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4NCiBWaXNobnUgUGF2YW4g QmVlcmFtIFs8YSBocmVmPSJtYWlsdG86dmlzaG51cGF2YW5AZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+bWFpbHRvOnZpc2hudXBhdmFuQGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gRnJpZGF5LCBBcHJpbCAxMiwgMjAxMyA4OjA4IEFNPGJyPg0KPGI+VG86PC9iPiBLaHV6ZW1h IFBpdGhld2FuPGJyPg0KPGI+Q2M6PC9iPiBJZ29yIEJyeXNraW47IERpZXRlciBCZWxsZXI7IDxh IGhyZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KY2NhbXBAaWV0 Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQ0NBTVBdIE1FTEdzIC0gUSZhbXA7 QTwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPktodXplbWEsIEhpITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+PGJyPg0KUGxlYXNlIHNlZSBpbmxpbmUuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPiZuYnNwOzEuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPldoZW4gTmV0d29yayBo YXMgbW9yZSB0aGFuIDIgbGF5ZXIgaS5lLiBQYWNrZXQtT1ROLURXRE0sIHRoZSBQYWNrZXQgKGNs aWVudCkgbGF5ZXIgd2lsbCBiZSB0YWxraW5nIHRvIGl0cyBpbW1lZGlhdGUgc2VydmVyIGxheWVy IGkuZS4gT1ROLCB3aGljaA0KIGluIHR1cm4gaXMgdGFsa2luZyB0byBEV0RNIGxheWVyLiBVc2lu ZyBNRUxHLCBjbGllbnQgbGF5ZXIgcGF0aCBjb21wdXRhdGlvbiBjYW4gdGFrZSBjYXJlIG9mIHJl c291cmNlIGV4Y2x1c2l2aXR5IG9mIHZpcnR1YWwgbGluayBmb3IgaW1tZWRpYXRlIHNlcnZlciBs YXllciBpLmUuIE9UTiBsYXllci4mbmJzcDsgSG93ZXZlciBpZiB0aGVyZSBpcyByZXNvdXJjZSBl eGNsdXNpdml0eSBhdCBEV0RNIGxheWVyLCB0aGlzIG1lY2hhbmlzbSBkb2VzbuKAmXQgd29yay4N CiBZb3UgbmVlZCB0byBkbyBsb29zZSByb3V0aW5nIG9yIHVzZSBkaXN0cmlidXRlZCBQQ0UgbW9k ZWw8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPltWUEJdIFRo ZSBiZWhhdmlvciBpcyB0aGUgc2FtZSBhcyB3aGF0IHlvdSB3b3VsZCBkbyB3aXRoIFNSTEdzIGlu IGEgbXVsdGktbGF5ZXIgYXJjaGl0ZWN0dXJlLiBUaGVyZSBhcmUgYXJjaGl0ZWN0dXJlcyB0aGF0 IGFsbG93IHRoZSBTUkxHcw0KIGluIHRoZSBsb3dlc3QgbGF5ZXIgdG8gYmUgZXhwb3J0ZWQgYWxs IHRoZSB3YXkgdXAgdG8gdGhlIGhpZ2hlc3QgbGF5ZXIuIFRoZSBleHBlY3RhdGlvbiBpcyB0aGF0 IE1FTEdzIHdvdWxkIGJlIHRyZWF0ZWQgaW4gdGhlIHNhbWUgdmVpbi4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPjIuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkZvciBjYXNlcyBvZiBjb25jdXJyZW50IGNv bXB1dGF0aW9uIChjYXNlIzItNSksIHlvdSBhcmUgbWFpbmx5IHRhbGtpbmcgYWJvdXQgZ2xvYmFs IG9wdGltaXphdGlvbiBhbmQgZGl2ZXJzaXR5IGFtb25nIG11bHRpcGxlIHNlcnZpY2VzLiBZb3Ug Y2FuDQogZG8gdGhlIHBhdGggY29tcHV0YXRpb24sIGJ1dCB0byBhY3R1YWxseSBlbmFjdCB0aGUg Y29tcHV0ZWQgcGF0aCB0aGUgc2lnbmFsaW5nIG5lZWRzIHRvIGJlIGRvbmUgZnJvbSB0aGUgc291 cmNlIGVuZCBvZiB0aG9zZSBMU1BzLiZuYnNwOyBTbyB0aGVyZSBpcyBubyBwb2ludCBpbiBkb2lu ZyBjb25jdXJyZW50IGNvbXB1dGF0aW9uIGF0IG9uZSBuZXR3b3JrIGVsZW1lbnQgZm9yIHRoZSBz ZXJ2aWNlcyBzdGFydGluZyBmcm9tIG11bHRpcGxlIG5ldHdvcmsNCiBlbGVtZW50cy4gQXQgYmVz dCBpdCBsb29rcyB0byBtZSBhIHByb2JsZW0gdG8gYmUgc29sdmVkIGJ5IG5ldHdvcmsgbWFuYWdl bWVudC9wbGFubmluZyBzb2Z0d2FyZS48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+W1ZQQl0gJm5ic3A7SSdtIG5vdCBzdXJlIHdoeSB5b3Ug dGhpbmsgdGhlcmUgaXMgbm8gcG9pbnQgaW4gaGF2aW5nIGEgY2VudHJhbGl6ZWQgY29tcHV0YXRp b24gZnVuY3Rpb24gY29tcHV0ZSBwYXRocyBjb25jdXJyZW50bHkgZm9yIExTUHMgd2l0aA0KIGRp ZmZlcmVudCBzZXQgb2YgZW5kLXBvaW50cy4gRXZlbiB5b3VyIE5NUy9wbGFubmluZy1zb2Z0d2Fy ZSBjYW4gaW50ZXJhY3Qgd2l0aCBzdWNoIGNvbXB1dGF0aW9uIGVuZ2luZSwgcmV0cmlldmUgYWxs IHRoZSBwYXRocyBhbmQgdGhlbiBnbyBhYm91dCBpbml0aWF0aW5nIHRoZSBwYXRoLXNldHVwIGZy b20gdGhlIGluZ3Jlc3Mgb2YgZWFjaCBMU1AuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj4tUGF2YW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPg0KPGEgaHJl Zj0ibWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5jY2FtcC1i b3VuY2VzQGlldGYub3JnPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpjY2FtcC1ib3VuY2Vz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Y2NhbXAtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPklnb3IgQnJ5c2tpbjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5 LCBNYXJjaCAyNiwgMjAxMyA3OjE5IFBNPGJyPg0KPGI+VG86PC9iPiBEaWV0ZXIgQmVsbGVyOyBW aXNobnUgUGF2YW4gQmVlcmFtPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PGJy Pg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86Y2NhbXBAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5jY2FtcEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtDQ0FNUF0g TUVMR3MgLSBRJmFtcDtBPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5EaWV0ZXIsPC9zcGFu PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+WW91IHNhaWQ6PC9z cGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6WkgtQ04iPiZndDsmZ3Q7IEkgZ3Vlc3Mgd2UgYXJlIGNvbWluZyBiYWNrIHRv IHRoZSBlc3NlbnRpYWwgcG9pbnQ6ICZxdW90Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+YW5kDQogaG93 IG9mdGVuIGNvbmN1cnJlbnQgcGF0aCBjb21wdXRhdGlvbiB3aWxsIGJlICZndDsmZ3Q7IHVzZWQu PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+JnF1b3Q7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj5UbyBiZSBob25lc3QsIHRoaXMgc3VycHJpc2VzIG1lIHF1aXRlIGEgYml0LCBMZXQg bWUgZ2l2ZSB5b3Ugc29tZSBvZiBtYW55IHJlYXNvbnMgYXMgdG8gd2h5IGNvbmN1cnJlbnQgcGF0 aCBjb21wdXRhdGlvbnMgYXJlIG5lZWRlZCBhbmQNCiB3aHkgdGhpcyBpcyBiZXR0ZXIgdGhhbiBj b21wdXRpbmcgb25lIHBhdGggYXQgYSB0aW1lOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6WkgtQ04iPjEuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Q29tcHV0 aW5nIHNldmVyYWwgZGl2ZXJzZSBwYXRocyBmb3IgdGhlIHNhbWUgc2VydmljZSBpbiB0aGUgY29u dGV4dCBvZiBzZXJ2aWNlIHJlY292ZXJ5LiBJIGhvcGUgeW91IHJlYWxpemUgdGhhdCBjb21wdXRp bmcgb25lIHBhdGggYXQgYSB0aW1lIG9uIG1hbnkgY29uZmlndXJhdGlvbnMgcHJvZHVjZXMgbm8g b3Igc3ViLW9wdGltYWwgcmVzdWx0cy4gSSBhbHNvIGhvcGUNCiB5b3UgcmVhbGl6ZSB0aGUgcHJv YmxlbSBvZiBzZWxlY3RpbmcgdHdvIHBhdGhzIHdpdGggb25lIG9mIHRoZW0gJm5ic3A7aGF2aW5n IGEgbGluayB3aXRoIGNvbW1vbiBNRUxHIHdpdGggYSBsaW5rIGZyb20gYW5vdGhlciBwYXRoOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+Mi48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDttc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Db21wdXRpbmcgcGF0aHMg Zm9yIG11bHRpcGxlIHNlcnZpY2VzIHRvIGJlIHN1ZmZpY2llbnRseSBkaXNqb2ludCBmcm9tIGVh Y2ggb3RoZXI7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj4zLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0 O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkNvbXB1 dGluZyBwYXRocyBmb3IgbXVsdGlwbGUgc2VydmljZXMgdG8gYWNoaWV2ZSBhIGdsb2JhbCBvcHRp bWl6YXRpb24gY3JpdGVyaWEgKGUuZy4gbWluaW1hbCBzdW1tYXJ5IHRvdGFsIGNvc3QpOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+NC48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDttc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Db21wdXRpbmcgcGF0aHMgZm9y IG11bHRpcGxlIHNlcnZpY2VzIGZvciB0aGUgcHVycG9zZSBvZiByZW1vdmluZyB0aGUgYmFuZHdp ZHRoIGZyYWdtZW50YXRpb25zOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+NS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj5Db21wdXRpbmcgcGF0aHMgZm9yIG11bHRpcGxlIHNlcnZpY2VzIHRvIHBsYW4gc2hhcmVk IG1lc2ggcHJvdGVjdGlvbi9yZXN0b3JhdGlvbiBzY2hlbWVzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHA+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj42Ljwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkV0Yy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkFsc28gdGhpbmsgYWJvdXQgdGhp czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPjEuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+SWYgY29uY3VycmVu dCBwYXRoIGNvbXB1dGF0aW9uIHdhcyBub3QgaW1wb3J0YW50LCB3aHkgUENFUCBpbmNsdWRlcyB0 aGUgbWFjaGluZXJ5IHRvIGRvIHRoYXQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4g c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4yLjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjcuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPk15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIHN0YXRlZnVsbCBQQ0UgaXMgdGhhdCBp dCBkb2VzIHByZXR0eSBtdWNoIG5vdGhpbmcgYnV0IGNvbmN1cnJlbnQgcGF0aCBjb21wdXRhdGlv bnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPllvdSBhbHNvIHNhaWQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZndDsm Z3Q7IEkgc3VwcG9zZSB0aGF0IGlmIGEgcGNlIGFwcHJvYWNoIGlzIHVzZWQsIGkuZS4sIHBhdGgg Y29tcHV0YXRpb24gaXMgY2VudHJhbGl6ZWQgaW5jbHVkaW5nIHRoZTxicj4NCiZndDsmZ3Q7IFRF LURCLCBNRUxHIHJvdXRpbmcgZXh0ZW5zaW9ucyBhcmUgbm90IG5lZWRlZCBiZWNhdXNlIHRoZSBp bmZvcm1hdGlvbiBhYm91dCBtdXR1YWw8YnI+DQomZ3Q7Jmd0O2V4Y2x1c2l2ZSBWTHMgY2FuIGJl IGtlcHQgaW4gdGhlIGNlbnRyYWwgVEUtREIgd2hlbiBWTHMgYXJlIGNvbmZpZ3VyZWQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkhvdyB0aGlzIGxvZ2ljIGRvZXMgbm90IGFwcGx5IHRv IG90aGVyIGxpbmsgYXR0cmlidXRlcyBzdWNoIGFzIFNSTEdzPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj5XaGF0IGlmIHBhdGggY29tcHV0YXRpb24gaXMgbm90IGNlbnRyYWxpemVkPzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5JZ29yPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+DQo8YSBocmVmPSJtYWlsdG86Y2NhbXAtYm91bmNl c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5jY2FtcC1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RGll dGVyIEJlbGxlcjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE1hcmNoIDI1LCAyMDEzIDU6NTIg UE08YnI+DQo8Yj5Ubzo8L2I+IFZpc2hudSBQYXZhbiBCZWVyYW08YnI+DQo8Yj5DYzo8L2I+IDxh IGhyZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNjYW1wQGlldGYu b3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0NDQU1QXSBNRUxHcyAtIFEmYW1wO0E8 L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj5IaQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+UGF2YW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Pbg0KPGEgaHJl Zj0idGVsOjI1LjAzLjIwMTMlMjAwNyIgdGFyZ2V0PSJfYmxhbmsiPjI1LjAzLjIwMTMgMDc8L2E+ OjI5LCBGYXRhaSBaaGFuZyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+SGkgUGF2YW4sPC9zcGFuPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+SSBhbSBub3Qgc3VyZSBob3cg bXVjaCBWTCAoVmlydHVhbCBMaW5rKSB3aWxsIGJlIHVzZWQgaW4gdGhlIHByYWN0aWNhbA0KIGRl cGxveW1lbnQgYW5kIGhvdyBvZnRlbiBjb25jdXJyZW50IHBhdGggY29tcHV0YXRpb24gd2lsbCBi ZSB1c2VkLjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5JIGd1ZXNzIHdlIGFy ZSBjb21pbmcgYmFjayB0byB0aGUgZXNzZW50aWFsIHBvaW50OiAmcXVvdDs8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPmFuZA0KIGhvdyBvZnRlbiBjb25jdXJyZW50IHBhdGggY29tcHV0YXRpb24gd2lsbCBi ZSB1c2VkLjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZx dW90Ozxicj4NCjxicj4NClRoaXMgbWVhbnMgd2UgYXJlIHRyeWluZyB0byBmaWd1cmUgb3V0IHVu ZGVyIHdoaWNoIGNvbmRpdGlvbnMgTUVMRyByb3V0aW5nIGV4dGVuc2lvbnM8YnI+DQpjb3VsZCBi ZSBiZW5lZmljaWFsLjxicj4NCjxicj4NCklNSE8sIHRoZXkgd291bGQgb25seSBtYWtlIHNlbnNl LCBpZjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxldmVsMSBsZm8zIj4NCjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+YSBwYXRoIGNvbXB1dGF0aW9uIGZ1bmN0aW9uIHN1cHBv cnRzIHRoZSBjYWxjdWxhdGlvbiBvZiBrIHNob3J0ZXN0IHBhdGhzIGNvbmN1cnJlbnRseTxvOnA+ PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZl bDEgbGZvMyI+DQo8c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPmlmIHRo ZXJlIGlzIG9ubHkgYSBzaW5nbGUgcGF0aCBjb21wdXRhdGlvbiBmdW5jdGlvbiBpbnN0YW5jZSBw ZXIgZG9tYWluIChwY2UgYXBwcm9hY2gpPGJyPg0KSWYgcGF0aCBjb21wdXRhdGlvbiBpcyBkb25l IGluIGEgZGlzdHJpYnV0ZWQgZmFzaGlvbiB0aGUgYmVuZWZpdCBnb2VzIGF3YXkgYmVjYXVzZTxi cj4NCnRoZSBpbnN0YW5jZXMgY2FsY3VsYXRlIHBhdGhzIGluZGVwZW5kZW50bHkhPG86cD48L286 cD48L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkkgc3VwcG9zZSB0aGF0IGlmIGEgcGNlIGFwcHJvYWNoIGlz IHVzZWQsIGkuZS4sIHBhdGggY29tcHV0YXRpb24gaXMgY2VudHJhbGl6ZWQgaW5jbHVkaW5nIHRo ZTxicj4NClRFLURCLCBNRUxHIHJvdXRpbmcgZXh0ZW5zaW9ucyBhcmUgbm90IG5lZWRlZCBiZWNh dXNlIHRoZSBpbmZvcm1hdGlvbiBhYm91dCBtdXR1YWw8YnI+DQpleGNsdXNpdmUgVkxzIGNhbiBi ZSBrZXB0IGluIHRoZSBjZW50cmFsIFRFLURCIHdoZW4gVkxzIGFyZSBjb25maWd1cmVkLjxicj4N Cjxicj4NCkhlbmNlLCBpdCBpcyBxdWl0ZSBkb3VidGZ1bCB3aGV0aGVyIE1FTEcgcm91dGluZyBl eHRlbnNpb25zIGFyZSByZWFsbHkgdXNlZnVsIHVubGVzcyB0aGVpcjxicj4NCmFwcGxpY2FiaWxp dHkgaXMgYnJvYWRlci48YnI+DQo8YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KRGlldGVyPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246anVzdGlm eSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+RG8geW91IHRoaW5rIGlmIGl0IG1ha2VzIHNlbnNlIHRvIGFkZCBh IGZsYWcgKGluIHJvdXRpbmcgYWR2ZXJ0aXNlbWVudCkgdG8gaW5kaWNhdGUgYSBsaW5rIGlzIGEg Vkwgb3Igbm90Pzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWdu Omp1c3RpZnkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmp1c3RpZnkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmp1c3RpZnkiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0 LWFsaWduOmp1c3RpZnkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkJlc3QgUmVnYXJkczwvc3Bhbj48c3BhbiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmp1c3RpZnkiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmp1 c3RpZnkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkZhdGFpPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4NCiBWaXNo bnUgUGF2YW4gQmVlcmFtIFs8YSBocmVmPSJtYWlsdG86dmlzaG51cGF2YW5AZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnZpc2hudXBhdmFuQGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXJjaCAyMiwgMjAxMyA4OjU3IFBNPGJyPg0KPGI+VG86PC9i PiBGYXRhaSBaaGFuZzxicj4NCjxiPkNjOjwvYj4gSWdvciBCcnlza2luOyA8YSBocmVmPSJtYWls dG86Y2NhbXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5jY2FtcEBpZXRmLm9yZzwvYT48YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtDQ0FNUF0gTUVMR3MgLSBRJmFtcDtBPC9zcGFuPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj5GYXRhaSwgSGkhPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+R29vZCB0byBz ZWUgdGhhdCB5b3UgdW5kZXJzdGFuZCB0aGUgY29uc3RydWN0IG5vdy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlRoaXMgaXMgbm90IGEgY29ybmVyIGNhc2UuIFRoZSB1 dGlsaXR5IG9mIHRoZSBjb25zdHJ1Y3QgYmVjb21lcyBxdWl0ZSBzaWduaWZpY2FudCBpZiB5b3Ug aGF2ZSBhbiBhcHBsaWNhdGlvbiB0aGF0IGRvZXMgY29uY3VycmVudCBwYXRoIGNvbXB1dGF0aW9u cw0KIG9uIGFuIGFic3RyYWN0IHRvcG9sb2d5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+LVBhdmFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4t Ym90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj5DQ0FNUCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48 YSBocmVmPSJtYWlsdG86Q0NBTVBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5DQ0FNUEBpZXRm Lm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NjYW1wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jY2FtcDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48 c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPi0tDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztmb250LXZhcmlhbnQ6c21hbGwtY2Fwczttc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+RElFVEVSIEJFTExFUg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzY2MzlCNzttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+QUxDQVRFTC1MVUNFTlQgREVVVFND SExBTkQgQUcNCjxicj4NClBST0pFQ1QgTUFOQUdFUiBBU09OL0dNUExTIENPTlRST0wgUExBTkUg PGJyPg0KQ09SRSBORVRXT1JLUyBCVVNJTkVTUyBESVZJU0lPTiA8YnI+DQpPUFRJQ1MgQlUsIFNX SVRDSElORyBSJmFtcDtEIDxicj4NCjxicj4NCkxvcmVuenN0cmFzc2UgMTAgPGJyPg0KNzA0MzUg U3R1dHRnYXJ0LCBHZXJtYW55IDxicj4NClBob25lOiA8YSBocmVmPSJ0ZWw6JTJCNDklMjA3MTEl MjA4MjElMjA0MzEyNSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGNsYXNzPSJza3lwZXBuaHByaW50 Y29udGFpbmVyMTM2NjM3NTU5MSI+JiM0Mzs0OSA3MTEgODIxIDQzMTI1PC9zcGFuPjxzcGFuIGNs YXNzPSJza3lwZXBuaG1hcmsiPiBiZWdpbl9vZl90aGVfc2t5cGVfaGlnaGxpZ2h0aW5nPC9zcGFu PjxzcGFuIGNsYXNzPSJza3lwZXBuaGNvbnRhaW5lciI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbjt0ZXh0LWRlY29yYXRp b246bm9uZSI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIxMDAiIGhlaWdodD0iMTAwIiBpZD0iX3gw MDAwX2kxMDI1IiBzcmM9ImNpZDp+V1JEMDAwLmpwZyIgYWx0PSJJbWFnZSByZW1vdmVkIGJ5IHNl bmRlci4iPjwvc3Bhbj48c3BhbiBjbGFzcz0ic2t5cGVwbmh0ZXh0c3BhbiI+JiM0Mzs0OQ0KIDcx MSA4MjEgNDMxMjU8L3NwYW4+PHNwYW4gY2xhc3M9InNreXBlcG5oZnJlZXRleHRzcGFuIj4gRlJF RSZuYnNwOyA8L3NwYW4+PHNwYW4gY2xhc3M9InNreXBlcG5obWFyayI+ZW5kX29mX3RoZV9za3lw ZV9oaWdobGlnaHRpbmc8L3NwYW4+IGJlZ2luX29mX3RoZV9za3lwZV9oaWdobGlnaHRpbmcmbmJz cDs8Yj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1bjt0ZXh0LWRl Y29yYXRpb246bm9uZSI+6ZSZ6K+v77yB5pyq5oyH5a6a5paH5Lu25ZCN44CCPC9zcGFuPjwvYj48 c3BhbiBjbGFzcz0ic2t5cGVwbmhwcmludGNvbnRhaW5lcjEzNjYzNzU1OTEiPiYjNDM7NDkNCiA3 MTEgODIxIDQzMTI1PC9zcGFuPjxzcGFuIGNsYXNzPSJza3lwZXBuaG1hcmsiPiBiZWdpbl9vZl90 aGVfc2t5cGVfaGlnaGxpZ2h0aW5nPC9zcGFuPjxzcGFuIGNsYXNzPSJza3lwZXBuaGNvbnRhaW5l ciI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBw dDtwYWRkaW5nOjBpbjt0ZXh0LWRlY29yYXRpb246bm9uZSI+PGltZyBib3JkZXI9IjAiIHdpZHRo PSIxMDAiIGhlaWdodD0iMTAwIiBpZD0iX3gwMDAwX2kxMDI2IiBzcmM9ImNpZDp+V1JEMDAwLmpw ZyIgYWx0PSJJbWFnZSByZW1vdmVkIGJ5IHNlbmRlci4iPjwvc3Bhbj48c3BhbiBjbGFzcz0ic2t5 cGVwbmh0ZXh0c3BhbiI+JiM0Mzs0OQ0KIDcxMSA4MjEgNDMxMjU8L3NwYW4+PHNwYW4gY2xhc3M9 InNreXBlcG5oZnJlZXRleHRzcGFuIj4gRlJFRSZuYnNwOyA8L3NwYW4+PHNwYW4gY2xhc3M9InNr eXBlcG5obWFyayI+ZW5kX29mX3RoZV9za3lwZV9oaWdobGlnaHRpbmc8L3NwYW4+IEZSRUUmbmJz cDsgYmVnaW5fb2ZfdGhlX3NreXBlX2hpZ2hsaWdodGluZyZuYnNwOzxiPjxzcGFuIGxhbmc9IlpI LUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuO3RleHQtZGVjb3JhdGlvbjpub25lIj7plJno r6/vvIHmnKrmjIflrprmlofku7blkI3jgII8L3NwYW4+PC9iPiYjNDM7NDkNCiA3MTEgODIxIDQz MTI1IEZSRUUmbmJzcDsgPC9hPjxicj4NCk1vYmlsOiA8YSBocmVmPSJ0ZWw6JTJCNDklMjAxNzUl MjA3MjY2ODc0IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gY2xhc3M9InNreXBlcG5ocHJpbnRjb250 YWluZXIxMzY2Mzc1NTkxIj4mIzQzOzQ5IDE3NSA3MjY2ODc0PC9zcGFuPjxzcGFuIGNsYXNzPSJz a3lwZXBuaG1hcmsiPiBiZWdpbl9vZl90aGVfc2t5cGVfaGlnaGxpZ2h0aW5nPC9zcGFuPjxzcGFu IGNsYXNzPSJza3lwZXBuaGNvbnRhaW5lciI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJib3Jk ZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbjt0ZXh0LWRlY29yYXRpb246bm9u ZSI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIxMDAiIGhlaWdodD0iMTAwIiBpZD0iX3gwMDAwX2kx MDI3IiBzcmM9ImNpZDp+V1JEMDAwLmpwZyIgYWx0PSJJbWFnZSByZW1vdmVkIGJ5IHNlbmRlci4i Pjwvc3Bhbj48c3BhbiBjbGFzcz0ic2t5cGVwbmh0ZXh0c3BhbiI+JiM0Mzs0OQ0KIDE3NSA3MjY2 ODc0PC9zcGFuPjxzcGFuIGNsYXNzPSJza3lwZXBuaGZyZWV0ZXh0c3BhbiI+IEZSRUUmbmJzcDsg PC9zcGFuPjxzcGFuIGNsYXNzPSJza3lwZXBuaG1hcmsiPmVuZF9vZl90aGVfc2t5cGVfaGlnaGxp Z2h0aW5nPC9zcGFuPiBiZWdpbl9vZl90aGVfc2t5cGVfaGlnaGxpZ2h0aW5nJm5ic3A7PGI+PHNw YW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW47dGV4dC1kZWNvcmF0aW9u Om5vbmUiPumUmeivr++8geacquaMh+WumuaWh+S7tuWQjeOAgjwvc3Bhbj48L2I+PHNwYW4gY2xh c3M9InNreXBlcG5ocHJpbnRjb250YWluZXIxMzY2Mzc1NTkxIj4mIzQzOzQ5DQogMTc1IDcyNjY4 NzQ8L3NwYW4+PHNwYW4gY2xhc3M9InNreXBlcG5obWFyayI+IGJlZ2luX29mX3RoZV9za3lwZV9o aWdobGlnaHRpbmc8L3NwYW4+PHNwYW4gY2xhc3M9InNreXBlcG5oY29udGFpbmVyIj4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImJvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6 MGluO3RleHQtZGVjb3JhdGlvbjpub25lIj48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjEwMCIgaGVp Z2h0PSIxMDAiIGlkPSJfeDAwMDBfaTEwMjgiIHNyYz0iY2lkOn5XUkQwMDAuanBnIiBhbHQ9Iklt YWdlIHJlbW92ZWQgYnkgc2VuZGVyLiI+PC9zcGFuPjxzcGFuIGNsYXNzPSJza3lwZXBuaHRleHRz cGFuIj4mIzQzOzQ5DQogMTc1IDcyNjY4NzQ8L3NwYW4+PHNwYW4gY2xhc3M9InNreXBlcG5oZnJl ZXRleHRzcGFuIj4gRlJFRSZuYnNwOyA8L3NwYW4+PHNwYW4gY2xhc3M9InNreXBlcG5obWFyayI+ ZW5kX29mX3RoZV9za3lwZV9oaWdobGlnaHRpbmc8L3NwYW4+IEZSRUUmbmJzcDsgYmVnaW5fb2Zf dGhlX3NreXBlX2hpZ2hsaWdodGluZyZuYnNwOzxiPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0i Zm9udC1mYW1pbHk6U2ltU3VuO3RleHQtZGVjb3JhdGlvbjpub25lIj7plJnor6/vvIHmnKrmjIfl rprmlofku7blkI3jgII8L3NwYW4+PC9iPiYjNDM7NDkNCiAxNzUgNzI2Njg3NCBGUkVFJm5ic3A7 IDwvYT48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM2NjM5Qjc7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPjxhIGhyZWY9Im1haWx0bzpEaWV0ZXIuQmVsbGVyQGFsY2F0ZWwtbHVj ZW50LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkRpZXRlci5CZWxsZXJAYWxjYXRlbC1sdWNlbnQuY29t PC9hPg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkFsY2F0ZWwtTHVjZW50IERl dXRzY2hsYW5kIEFHDQo8YnI+DQpEb21pY2lsZSBvZiB0aGUgQ29tcGFueTogU3R1dHRnYXJ0IMK3 IExvY2FsIENvdXJ0IFN0dXR0Z2FydCBIUkIgNDAyNiA8YnI+DQpDaGFpcm1hbiBvZiB0aGUgU3Vw ZXJ2aXNvcnkgQm9hcmQ6IE1pY2hhZWwgT3BwZW5ob2ZmIDxicj4NCkJvYXJkIG9mIE1hbmFnZW1l bnQ6IFdpbGhlbG0gRHJlc3NlbGhhdXMgKENoYWlybWFuKSDCtyBIYW5zLUrDtnJnIERhdWIgwrcg RHIuIFJhaW5lciBGZWNobmVyIMK3IEFuZHJlYXMgR2VoZQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923A939atlsrvmail10atl_-- --_004_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923A939atlsrvmail10atl_ Content-Type: image/jpeg; name="~WRD000.jpg" Content-Description: ~WRD000.jpg Content-Disposition: inline; filename="~WRD000.jpg"; size=823; creation-date="Mon, 22 Apr 2013 12:44:07 GMT"; modification-date="Mon, 22 Apr 2013 12:44:07 GMT" Content-ID: <~WRD000.jpg> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABkAGQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigD//2Q== --_004_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923A939atlsrvmail10atl_-- From IBryskin@advaoptical.com Mon Apr 22 06:58:56 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E5221F9110 for ; Mon, 22 Apr 2013 06:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_66=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 HqNyU6CG-2ui for ; Mon, 22 Apr 2013 06:58:43 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id A6F5A21F905B for ; Mon, 22 Apr 2013 06:58:41 -0700 (PDT) Received: from MUC-SRV-MAIL10B.advaoptical.com ([172.20.1.60]) by muc-vsrv-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id r3MDwWdL014309 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Apr 2013 15:58:32 +0200 Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MAIL10B.advaoptical.com (172.20.1.60) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 22 Apr 2013 15:58:32 +0200 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0123.003; Mon, 22 Apr 2013 09:58:29 -0400 From: Igor Bryskin To: Fatai Zhang , Vishnu Pavan Beeram , Khuzema Pithewan , "Dieter Beller" Thread-Topic: [CCAMP] MELGs - Q&A Thread-Index: AQHOIGPeoOQf0fNS1kG7ulofq5GmQJivzRoAgABxTHCAAPkpgIAAeAqAgABMBQCABErLAIABAdYAgAC6NQCAGt0OAIAAD52A///KWjCAAGRRgP//wCBQgABTlAD//73CwAAKM0gAAAY9GCAAdYY0gAAQgVwAADCVHoAABlrDAACAXYgAAAonNRAAI4zjAAB2Qw1A Date: Mon, 22 Apr 2013 13:58:29 +0000 Message-ID: References: <5150C704.2040007@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.21.1.81] Content-Type: multipart/related; boundary="_004_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923A963atlsrvmail10atl_"; type="multipart/alternative" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-04-22_03:2013-04-22, 2013-04-22, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] MELGs - Q&A X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 13:58:56 -0000 --_004_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923A963atlsrvmail10atl_ Content-Type: multipart/alternative; boundary="_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923A963atlsrvmail10atl_" --_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923A963atlsrvmail10atl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Fatai and Khuzema, In my opinion you confuse two cases: Case 1. Two virtual links are served by WDM layer. The potential paths supp= orting each VL are terminated on the same transponder, hence the two VLs ar= e mutually exclusive. Note that this mutual exclusivity relationship is sta= tic: it is true at all times and does not depend on anything else (e.g. it = does not depend on # of available wavelengths on WDM links the transponder = could be connected to). This is the case of MELGs and is focus of our MELG = draft; Case 2. Two virtual links are served by WDM layer. The potential paths supp= orting each VL use a common WDM link that has only one wavelength available= at the moment, hence the two VLs are mutually exclusive. Note that this mu= tual exclusivity is dynamic: as soon as an additional wavelength becomes av= ailable on the common WDM link, the two VLs will be able to be committed at= the same time. This is not the MELG case. We discussed this dynamic mutual= exclusivity (Cyril was the first, I believe, to bring this up) and have de= cided to keep this case out of scope of the MELG draft. Note, that there is= a simple solution for this case based on the VL model, which we will solve= in a separate draft. This solution does not include the inter-layer path c= omputation: the whole point of the VLs is to alleviate the clients from dea= ling with the server layer traffic engineering and path computations. Cheers, Igor From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Friday, April 19, 2013 9:14 PM To: Igor Bryskin; Vishnu Pavan Beeram; Khuzema Pithewan; Dieter Beller Cc: ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, I have explained to Pavan. The path computation element (centralized PCE for inter-layer or multiple P= CEs through communication) can take care of this issue. In addition, in this case, how you advertise MELGS for this two VT links? = Will you advertise that VL 1 must be exclusive with VL2? That is wrong, bec= ause VL1 and VL2 can be used for the disjoint paths in the client layer. Best Regards Fatai From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 19, 2013 8:22 PM To: Fatai Zhang; Vishnu Pavan Beeram; Khuzema Pithewan; Dieter Beller Cc: ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Fatai, What is Virtual Link? As described in RFC6001, it says as below. So my ques= tion is: when there are two VLs created through Call approach as defined in= RFC6001, one has 3 potential paths in the server layer to setup FA-LSP, an= d another has 2 potential paths in the server layer, and only one of the 3 = &2 has the same resource shared in the server layer. How MELGs can help in this case? IB>> Simple: with MELGs the path computer will know in advance that selecti= ng two paths with a virtual link belonging to path #1 and a virtual link be= longing to path #2 having an MELG in common will be a bad idea, because an = attempt to provision such path combination is guaranteed to fail. Without M= ELGs the path computer won't have such knowledge. Cheers, Igor From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Thursday, April 18, 2013 11:26 PM To: Vishnu Pavan Beeram; Khuzema Pithewan; Igor Bryskin; Dieter Beller Cc: ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Pavan, Igor I think there are some concerns about the applicability of MELGs and I have= the same feeling as Khuzema and Dieter. I still think that MELGS can only handle a very small corner case as you pu= t many cases below where MELGs are not needed. What is Virtual Link? As described in RFC6001, it says as below. So my ques= tion is: when there are two VLs created through Call approach as defined in= RFC6001, one has 3 potential paths in the server layer to setup FA-LSP, an= d another has 2 potential paths in the server layer, and only one of the 3 = &2 has the same resource shared in the server layer. How MELGs can help in this case? =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=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 A virtual TE link is defined as a TE link between two upper-layer nodes tha= t is not associated with a fully provisioned FA-LSP in a lower layer [RFC52= 12]. A virtual TE link is advertised a= s any TE link, following the rules in [RFC4206] defined for fully provisioned TE links. A virtual TE link represe= nts thus the potentiality to set up an FA-LSP in the lower layer to support= the TE link that has been advertised. =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=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 Best Regards Fatai From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Vishnu Pavan Beeram Sent: Tuesday, April 16, 2013 10:10 PM To: Khuzema Pithewan Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Khuzema, Hi! MELGs are useful and come into play only when: (1) The server network domain is abstracted and the advertised Virtual TE-l= inks possess some mutual exclusivity relationship. (2) There is a Centralized path computation entity in the client domain (co= mputes paths in terms of Client TE-links/TE-nodes) that is capable of doing= concurrent path computations. If either of the above 2 statements is NOT true, there is no utility for ME= LGs. At the risk of being pedantic: - Are MELGs needed when the server-network domain in not abstracted (no Vir= tual TE links)? The answer is NO. - Are MELGs needed when you have a distributed path-computation architectur= e (Client PCE interacting with Server PCE)? The answer is NO. - Are MELGs needed when the centralized path-computation engine doesn't (ca= n't) do concurrent computations? The answer is NO. The actual procedures involved in abstracting the server network domain is = beyond the scope of . The abstraction procedure itself is impl= ementation-specific (maybe someday someone would put together a draft for d= iscussing this). Though it is true that the primary use-case we had in mind= when coming up with this new construct involves a lambda-layer server netw= ork domain, there is really no restriction (at a conceptual level) on using= this construct when abstracting a packet-layer server network domain or a = TDM-layer server network domain. It is up to the implementation on how to m= ake best use of this construct. When you advertise a Virtual TE-link into a client network domain, you are = doing this based on the existence of some potential underlying server-path.= TE attributes like SRLGs, MELGs, delay etc that get advertised for the Vir= tual TE-link depend on the underlying server-path that is chosen for cateri= ng to this Client TE-link. If the underlying server-path keeps changing (ba= sed on network events), these TE attributes would also keep changing. The p= rocedure for keeping the advertised information "current" is an implementat= ion choice. If there exists such a thing as an abstraction manager (again, this is tota= lly implementation specific), then the assumption is that it does one of th= e following - (a) computes new server-paths for the Virtual TE links whenever there is a = change in the network (may not be very scalable in some architectures), (b) or does periodic path-computation for each Virtual TE link, (c) or uses a policy to pin down the Virtual TE-link to a specific underlyi= ng server-path, (d) or uses a combination of (a), (b), (c). doesn't make any recommendation as to what choice the abstrac= tion manager would need to take. Hope this helps. -Pavan On Tue, Apr 16, 2013 at 7:08 AM, Khuzema Pithewan > wrote: Hi Igor, I am trying to summarize the discussion we had so far. Pls see if my conclu= sion is in sync with the idea of MELG you have MELG is useful when 1. server layer VLs are nailed down for the resources on the server l= ayer links that are shared among multiple VLs. These resources are typicall= y wavelength on a fiber (can it be anything else??). In other words, if 2 V= Ls are pinned to use a particular wavelength on a particular fiber, then th= ese 2 VLs will have MELG for the wavelength. 2. server layer do not have centralized path computation entity which= can be used by client layer to ask for concurrent diverse path computation= within server layer. 3. Client layer has a centralized path computation entity, which woul= d compute paths for client+server layer. 4. The need is to centralized concurrent computation of more than one= client+server layer path that meets some diversity and resource exclusivit= y requirements. Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Monday, April 15, 2013 9:44 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Please, see in-line. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Monday, April 15, 2013 12:05 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, I understand the SRLG and MELG behavior you have penned . My concern was little different. With changing resource consumption (becau= se of dynamicity the network has) in the network links, potential paths a s= et of virtual link can take will change and hence its MELG, as it is tied t= o a resource it can take. So unless virtual links paths are nailed down, it= would be hard to compute MELGs in distributed way. IB>> I think you are missing the point here. Virtual Link server layer path= s are pinned as far as fate sharing is concerned (that is, they are pinned = on server layer link level). It would make little sense to advertise VL SR= LGs if the SRLGs constantly change. The same is true for MELGs. SRLGs/MELG= s advertised for VLs normally do not change: neither over time nor when VLs= become committed/uncommitted. Another point is, virtual links can be viewed as oversubscription of resour= ces (in MELG context). Taking an example (for OTN, I know it would work dif= ferently for a Wavelength in WDM), a link resources are worth 1 TB of BW, u= ser has provisioned 20 virtual links of 100G each going via that OTN link. = Physically, only 10 will get committed. But which 10? It will really depen= d on network dynamics at the time of demand to commit. MELGs are not that e= ffective here. You need some different mechanism. IB>> As I mentioned before MELGs have nothing to do with bandwidth and were= never intended to solve the problems such as you describe (just like it wo= uld not make much sense to solve such problem with SRLGs :=3D) Again, MELG is an extreme case SRLG designed exclusively for VLs (no more = and no less). Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 11:55 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Think about MELG as an SRLG that is shared between two or more links in its= entirety. When two real links have an SRLG in common, it means that two re= al links can co-exist concurrently, but there is something (e.g. common con= duit, note that the conduit has room for more than for one link) that will = bring both these links down, if this something fails (e.g. conduit is cut )= . Now consider that this something must be taken in its entirety by one of = the links to become operational . In this case SRLG becomes MELG. Note that= MELG is only meaningful for virtual links (unlike SRLG that makes sense fo= r either real or virtual link). Why would you advertise two links that mutu= ally exclude each other rather than advertising only one of them at a time,= unless the two are virtual links and hence both available for the client l= ayer connections? Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 1:01 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Do you mean, if virtual link do not have any specific constraint, for examp= le a link in the path (not talking about egress links/interfaces) must be t= raversed to realize the virtual link, there wont be any MELG for the virtua= l link? Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 9:52 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, MELGs have nothing to do with bandwidth. MELG is a concrete network resourc= e in a server layer that two or more Virtual Links in a client layer depend= on in a mutually exclusive way. An example of MELG is a WDM layer transpon= der that can terminate either of respective WDM layer tunnels (but not both= at the same time) for two OTN layer Virtual Links. If you advertise a Virt= ual Link, say, for Ethernet layer that depends on the connection in OTN lay= er going through one of the mentioned OTN links, the Ethernet VL must inher= it the MELG similarly like it does SRLGs advertised for the OTN links. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 12:06 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, For multi-layer (more than 2) network, consider all the layers are meshy (t= hat's when virtual links are useful anyway), MELGs of virtual link will cha= nge as and when BW/wavelength availability changes, because potential paths= , a virtual link can take will change. Mapping lower layer MELGs to higher = layer MELGs won't be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all= the risk and paths (a PCE?), which can be utilized for layer specific path= computation (as it is doing it anyway). This kind of architecture has all the pieces that are required for Inter-PC= E communication (across layers), except the protocol that would actually ma= ke the 2 PCEs talk. You seem to be doing something that you don't like :) Regards Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 8:39 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, I am not a fan of inter-layer path computations (nor I am a fan of inter-PC= E computations). In my mind path computation for a service or services in l= ayer X is performed only in layer X, i.e. considers only X layer links (rea= l or virtual). As Pavan mentioned SRLGs and MELGs that need to be inherited= from lower layers should be translated into X layer link SRLGs/MELGs and s= pecified with X layer specific SRLG/MELG IDs. Cheers, Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 10:55 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Ok. This would be useful if network architecture is based on external PCE o= r mgmt entity as PCE in client layer, but there is no counterpart in server= layer, otherwise one could have inter-PCE communication to achieve diverse= path in server layer without getting into virtual link and MELG stuff. Is that correct? Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 6:36 PM To: Vishnu Pavan Beeram; Khuzema Pithewan Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. Well, when an ingress node is initiating a service, it is doing so on reque= st from some management entity. This management entity can compute paths fo= r many services with some global criteria in mind, and then specify the res= ulting paths as explicit EROs in provisioning requests sent to each of the = service ingresses. How else, for example, you can set up several services = originated from different nodes that are disjoint from each other? Also, wh= at is the point in your opinion of the statefull PCE work? Cheers, Igor From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, April 12, 2013 8:08 AM To: Khuzema Pithewan Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Khuzema, Hi! Please see inline.. 1. When Network has more than 2 layer i.e. Packet-OTN-DWDM, the Pack= et (client) layer will be talking to its immediate server layer i.e. OTN, w= hich in turn is talking to DWDM layer. Using MELG, client layer path comput= ation can take care of resource exclusivity of virtual link for immediate s= erver layer i.e. OTN layer. However if there is resource exclusivity at DW= DM layer, this mechanism doesn't work. You need to do loose routing or use = distributed PCE model [VPB] The behavior is the same as what you would do with SRLGs in a multi-l= ayer architecture. There are architectures that allow the SRLGs in the lowe= st layer to be exported all the way up to the highest layer. The expectatio= n is that MELGs would be treated in the same vein. 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. [VPB] I'm not sure why you think there is no point in having a centralized= computation function compute paths concurrently for LSPs with different se= t of end-points. Even your NMS/planning-software can interact with such com= putation engine, retrieve all the paths and then go about initiating the pa= th-setup from the ingress of each LSP. Regards, -Pavan From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Igor Bryskin Sent: Tuesday, March 26, 2013 7:19 PM To: Dieter Beller; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Dieter, You said: >> I guess we are coming back to the essential point: "and how often concur= rent path computation will be >> used." To be honest, this surprises me quite a bit, Let me give you some of many r= easons as to why concurrent path computations are needed and why this is be= tter than computing one path at a time: 1. Computing several diverse paths for the same service in the context= of service recovery. I hope you realize that computing one path at a time = on many configurations produces no or sub-optimal results. I also hope you = realize the problem of selecting two paths with one of them having a link = with common MELG with a link from another path; 2. Computing paths for multiple services to be sufficiently disjoint f= rom each other; 3. Computing paths for multiple services to achieve a global optimizat= ion criteria (e.g. minimal summary total cost); 4. Computing paths for multiple services for the purpose of removing t= he bandwidth fragmentations; 5. Computing paths for multiple services to plan shared mesh protectio= n/restoration schemes 6. Etc. Also think about this: 1. If concurrent path computation was not important, why PCEP includes= the machinery to do that? 2. My understanding of the statefull PCE is that it does pretty much n= othing but concurrent path computations You also said: >> I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the >> TE-DB, MELG routing extensions are not needed because the information ab= out mutual >>exclusive VLs can be kept in the central TE-DB when VLs are configured. How this logic does not apply to other link attributes such as SRLGs? What if path computation is not centralized? Cheers, Igor From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Dieter Beller Sent: Monday, March 25, 2013 5:52 PM To: Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Hi Pavan, On 25.03.2013 07:29, Fatai Zhang wrote: Hi Pavan, I am not sure how much VL (Virtual Link) will be used in the practical depl= oyment and how often concurrent path computation will be used. I guess we are coming back to the essential point: "and how often concurren= t path computation will be used." This means we are trying to figure out under which conditions MELG routing = extensions could be beneficial. IMHO, they would only make sense, if: * a path computation function supports the calculation of k shortest pa= ths concurrently * if there is only a single path computation function instance per doma= in (pce approach) If path computation is done in a distributed fashion the benefit goes away = because the instances calculate paths independently! I suppose that if a pce approach is used, i.e., path computation is central= ized including the TE-DB, MELG routing extensions are not needed because the information about= mutual exclusive VLs can be kept in the central TE-DB when VLs are configured. Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their applicability is broader. Thanks, Dieter Do you think if it makes sense to add a flag (in routing advertisement) to = indicate a link is a VL or not? Best Regards Fatai From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, March 22, 2013 8:57 PM To: Fatai Zhang Cc: Igor Bryskin; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Fatai, Hi! Good to see that you understand the construct now. This is not a corner case. The utility of the construct becomes quite signi= ficant if you have an application that does concurrent path computations on= an abstract topology. Regards, -Pavan _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp -- DIETER BELLER ALCATEL-LUCENT DEUTSCHLAND AG PROJECT MANAGER ASON/GMPLS CONTROL PLANE CORE NETWORKS BUSINESS DIVISION OPTICS BU, SWITCHING R&D Lorenzstrasse 10 70435 Stuttgart, Germany Phone: +49 711 821 43125 begin_of_the_skype_highlighting [Image removed by = sender.] +49 711 821 43125 FREE end_of_the_skype_highlighting Mobil: +49 175 7266874 begin_of_the_skype_highlighting [Image removed by se= nder.] +49 175 7266874 FREE end_of_the_skype_highlighting Dieter.Beller@alcatel-lucent.com Alcatel-Lucent Deutschland AG Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026 Chairman of the Supervisory Board: Michael Oppenhoff Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe --_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923A963atlsrvmail10atl_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Fatai and Khuzema,

 <= /p>

In my opinion you confuse= two cases:

 <= /p>

Case 1. Two virtual links= are served by WDM layer. The potential paths supporting each VL are termin= ated on the same transponder, hence the two VLs are mutually exclusive. Note that this mutual exclusivity relationship is static: it is= true at all times and does not depend on anything else (e.g. it does not d= epend on # of available wavelengths on WDM links the transponder could be c= onnected to). This is the case of MELGs and is focus of our MELG draft;

 <= /p>

Case 2. Two virtual links= are served by WDM layer. The potential paths supporting each VL use a comm= on WDM link that has only one wavelength available at the moment, hence the two VLs are mutually exclusive. Note that this mutual ex= clusivity is dynamic: as soon as an additional wavelength becomes available= on the common WDM link, the two VLs will be able to be committed at the sa= me time. This is not the MELG case. We discussed this dynamic mutual exclusivity (Cyril was the first, I belie= ve, to bring this up) and have decided to keep this case out of scope of th= e MELG draft. Note, that there is a simple solution for this case based on = the VL model, which we will solve in a separate draft. This solution does not include the inter-layer path c= omputation: the whole point of the VLs is to alleviate the clients from dea= ling with the server layer traffic engineering and path computations.<= /o:p>

 <= /p>

Cheers,=

Igor

 <= /p>

 <= /p>

From: Fatai Zh= ang [mailto:zhangfatai@huawei.com]
Sent: Friday, April 19, 2013 9:14 PM
To: Igor Bryskin; Vishnu Pavan Beeram; Khuzema Pithewan; Dieter Bell= er
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

 

 

 

 

Best Regards

 

Fatai

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 19, 2013 8:22 PM
To: Fatai Zhang; Vishnu Pavan Beeram; Khuzema Pithewan; Dieter Belle= r
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

What is Virtual Link? As described in RFC6001,= it says as below. So my question is: when there are two VLs created through Call approach as defined in RFC6001, one has 3 potential p= aths in the server layer to setup FA-LSP, and another has 2 potential paths= in the server layer, and only one of the 3 &2 has the same resource sh= ared in the server layer.

 

How MELGs can help in this case?

 

IB>> Simple: with MELGs the path compute= r will know in advance that selecting two paths with a virtual link belonging to path #1 and a virtual link belonging to path #2 having an MEL= G in common will be a bad idea, because an attempt to provision such path c= ombination is guaranteed to fail. Without MELGs the path computer won’= ;t have such knowledge.

 

Cheers,

Igor

From: Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Thursday, April 18, 2013 11:26 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan; Igor Bryskin; Dieter Bell= er
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

A virtual TE link is defined as a TE l= ink between two upper-layer nodes that is not associated with a fully provisioned FA-LSP in a lower layer [RFC5212].  A virtual TE link is advertised as any TE link, following the rules in [RFC4206] defined for fully provisioned TE links.  A virtual TE link represents thus the potentiality to set up an FA-LSP= in the lower layer to support the TE link that has been advertised.=

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

 

 

 

 

Best Regards

 

Fatai

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Vishnu Pavan Beeram
Sent: Tuesday, April 16, 2013 10:10 PM
To: Khuzema Pithewan
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Khuzema, = Hi!

 

MELGs are= useful and come into play only when:

(1) The s= erver network domain is abstracted and the advertised Virtual TE-links poss= ess some mutual exclusivity relationship.

(2) There= is a Centralized path computation entity in the client domain (computes pa= ths in terms of Client TE-links/TE-nodes) that is capable of doing concurre= nt path computations.

 

If either= of the above 2 statements is NOT true, there is no utility for MELGs. = ;

At the ri= sk of being pedantic: 

- Are MEL= Gs needed when the server-network domain in not abstracted (no Virtual TE l= inks)? The answer is NO.

- Are MEL= Gs needed when you have a distributed path-computation architecture (Client= PCE interacting with Server PCE)? The answer is NO.

- Are MEL= Gs needed when the centralized path-computation engine doesn't (can't) do c= oncurrent computations? The answer is NO.

 

The actua= l procedures involved in abstracting the server network domain is beyond th= e scope of <draft-melgs>. The abstraction procedure itself is impleme= ntation-specific (maybe someday someone would put together a draft for discussing this). Though it is true that the prim= ary use-case we had in mind when coming up with this new construct involves= a lambda-layer server network domain, there is really no restriction (at a= conceptual level) on using this construct when abstracting a packet-layer server network domain or a TDM-l= ayer server network domain. It is up to the implementation on how to make b= est use of this construct. 

 

When you = advertise a Virtual TE-link into a client network domain, you are doing thi= s based on the existence of some potential underlying server-path. TE attri= butes like SRLGs, MELGs, delay etc that get advertised for the Virtual TE-link depend on the underlying server-pat= h that is chosen for catering to this Client TE-link. If the underlying ser= ver-path keeps changing (based on network events), these TE attributes woul= d also keep changing. The procedure for keeping the advertised information "current" is an implement= ation choice. 

 

If there = exists such a thing as an abstraction manager (again, this is totally imple= mentation specific), then the assumption is that it does one of the followi= ng - 

(a) compu= tes new server-paths for the Virtual TE links whenever there is a change in= the network (may not be very scalable in some architectures), 

(b) or do= es periodic path-computation for each Virtual TE link, 

(c) or us= es a policy to pin down the Virtual TE-link to a specific underlying server= -path, 

(d) or us= es a combination of (a), (b), (c).

 

<draft= -melgs> doesn't make any recommendation as to what choice the abstractio= n manager would need to take.

 

Hope this= helps.

-Pavan

 

On Tue, A= pr 16, 2013 at 7:08 AM, Khuzema Pithewan <kpithewan@infinera.com> wrote:

Hi Igor,

 

I am trying = to summarize the discussion we had so far. Pls see if my conclusion is in sync with the idea of MELG you have

 

MELG is usef= ul when=

1.  = ;     server layer V= Ls are nailed down for the resources on the server layer links that are sha= red among multiple VLs. These resources are typically wavelength on a fiber (can it be anything else??). In other words, if 2 VL= s are pinned to use a particular wavelength on a particular fiber, then the= se 2 VLs will have MELG for the wavelength.

2.  = ;     server layer d= o not have centralized path computation entity which can be used by client = layer to ask for concurrent diverse path computation within server layer.=

3.  = ;     Client layer h= as a centralized path computation entity, which would compute paths for cli= ent+server layer.

4.  = ;     The need is to= centralized concurrent computation of more than one client+server laye= r path that meets some diversity and resource exclusivity requirements.=

 

Regds=

Khuzema

 

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Monday, April 15, 2013 9:44 PM


To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

Please, see = in-line.

 

Igor<= span style=3D"mso-fareast-language:ZH-CN">

 

From: Khuzema Pithewan [mailto:kpithewan@infinera.com]
Sent: Monday, April 15, 2013 12:05 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

I understand= the SRLG and MELG behavior you have penned .

 

My concern w= as little different.  With changing resource consumption (because of dynamicity the network has) in the network links, potential paths a set= of virtual link can take will change and hence its MELG, as it is tied to = a resource it can take. So unless virtual links paths are nailed down, it w= ould be hard to compute MELGs in distributed way.

 

IB>> I= think you are missing the point here. Virtual Link server layer paths are pinned as far as fate sharing is concerned (that is, they are pi= nned on  server layer link level). It would make little sense to adver= tise VL SRLGs if the SRLGs constantly change. The same is true for MELGs. &= nbsp;SRLGs/MELGs advertised for VLs normally do not change: neither over time nor when VLs become committed/uncommitted= .

 

Another poin= t is, virtual links can be viewed as oversubscription of resources (in MELG context). Taking an example (for OTN, I know it would work differ= ently for a Wavelength in WDM), a link resources are worth 1 TB of BW, user= has provisioned 20 virtual links of 100G each going via that OTN link. &nb= sp;Physically, only 10 will get committed. But which 10? It will really depend on network dynamics at the time of dem= and to commit. MELGs are not that effective here. You need some different m= echanism.

 

IB>> A= s I mentioned before MELGs have nothing to do with bandwidth and were never intended to solve the problems such as you describe (just like = it would not make much sense to solve such problem with SRLGs :=3D)<= span style=3D"mso-fareast-language:ZH-CN">

Again,  = ;MELG is an extreme case SRLG designed exclusively for VLs (no more and no less).<= /o:p>

 

Regds=

Khuzema

 

 

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 11:55 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

Think about = MELG as an SRLG that is shared between two or more links in its entirety. When two real links have an SRLG in common, it means that tw= o real links can co-exist concurrently, but there is something (e.g. common= conduit, note that the conduit has room for more than for one link) that w= ill bring both these links down, if this something fails (e.g. conduit is cut ). Now consider that this som= ething must be taken in its entirety by one of the links to become operatio= nal . In this case SRLG becomes MELG. Note that MELG is only meaningful for= virtual links (unlike SRLG that makes sense for either real or virtual link). Why would you advertise two = links that mutually exclude each other rather than advertising only one of = them at a time, unless the two are virtual links and hence both available f= or the client layer connections?

 

Igor

 

 

From: Khuzema Pithewan [mailto:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 1:01 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

Do you mean,= if virtual link do not have any specific constraint, for example a link in the path (not talking about egress links/interfaces) mus= t be traversed to realize the virtual link, there wont be any MELG for the = virtual link?<= /span>

 

Regds=

Khuzema

 

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 9:52 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

MELGs have n= othing to do with bandwidth. MELG is a concrete network resource in a server layer that two or more Virtual Links in a client layer depend = on in a mutually exclusive way. An example of MELG is a WDM layer transpond= er that can terminate either of respective WDM layer tunnels (but not both = at the same time) for two OTN layer Virtual Links. If you advertise a Virtual Link, say, for Ethernet layer th= at depends on the connection in OTN layer going through one of the mentione= d OTN links, the Ethernet VL must inherit the MELG similarly like it does S= RLGs advertised for the OTN links.

 

Igor<= span style=3D"mso-fareast-language:ZH-CN">

 

 

From: Khuzema Pithewan [mailto:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 12:06 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

For multi-la= yer (more than 2) network, consider all the layers are meshy (that’s when virtual links are useful anyway), MELGs of virtual link= will change as and when BW/wavelength availability changes, because potent= ial paths, a virtual link can take will change. Mapping lower layer MELGs t= o higher layer MELGs won’t be practical if done in distributed manner, so it has to be centralized. So you do have= central element in each layer that knows all the risk and paths (a PCE?), = which can be utilized for layer specific path computation (as it is doing i= t anyway).

 

This kind of= architecture has all the pieces that are required for Inter-PCE communication (across layers), except the protocol that would actually mak= e the 2 PCEs talk.

 

You seem to = be doing something that you don’t like J

 

Regards

Khuzema

 

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 8:39 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

I am not a f= an of inter-layer path computations (nor I am a fan of inter-PCE computations). In my mind path computation for a service or services in la= yer X is performed only in layer X, i.e. considers only X layer links (real= or virtual). As Pavan mentioned SRLGs and MELGs that need to be inherited = from lower layers should be translated into X layer link SRLGs/MELGs and specified with X layer specific SRLG/MEL= G IDs.<= /p>

 

Cheers,

Igor<= span style=3D"mso-fareast-language:ZH-CN">

 

 

From: Khuzema Pithewan [mailto:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 10:55 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

Ok. This wou= ld be useful if network architecture is based on external PCE or mgmt entity as PCE in client layer, but there is no counterpart in = server layer, otherwise one could have inter-PCE communication to achieve d= iverse path in server layer without getting into virtual link and MELG stuf= f.

 

Is that corr= ect?

 

Khuzema

 

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 6:36 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

2.       For cases of c= oncurrent computation (case#2-5), you are mainly talking about global optim= ization and diversity among multiple services. You can do the path computation, but to actually enact the computed path the signa= ling needs to be done from the source end of those LSPs.  So there is = no point in doing concurrent computation at one network element for the ser= vices starting from multiple network elements. At best it looks to me a problem to be solved by network managem= ent/planning software.&nb= sp;

Well, when a= n ingress node is initiating a service, it is doing so on request from some management entity. This management entity can compute pa= ths for many services with some global criteria in mind, and then specify t= he resulting paths as explicit EROs in provisioning requests sent to each o= f the service ingresses. How else, for example,  you can set up several services originated from differe= nt nodes that are disjoint from each other? Also, what is the point in your= opinion of the statefull PCE work?

 

Cheers,

Igor<= span style=3D"mso-fareast-language:ZH-CN">

 

From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com]
Sent: Friday, April 12, 2013 8:08 AM
To: Khuzema Pithewan
Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Khuzema, Hi!=


Please see inline..

 

 

 1.       When Network h= as more than 2 layer i.e. Packet-OTN-DWDM, the Packet (client) layer will b= e talking to its immediate server layer i.e. OTN, which in turn is talking to DWDM layer. Using MELG, client layer path computatio= n can take care of resource exclusivity of virtual link for immediate serve= r layer i.e. OTN layer.  However if there is resource exclusivity at D= WDM layer, this mechanism doesn’t work. You need to do loose routing or use distributed PCE model

 

[VPB] The behavior is t= he same as what you would do with SRLGs in a multi-layer architecture. Ther= e are architectures that allow the SRLGs in the lowest layer to be exported all the way up to the highest layer. Th= e expectation is that MELGs would be treated in the same vein. 

2.       For cases of c= oncurrent computation (case#2-5), you are mainly talking about global optim= ization and diversity among multiple services. You can do the path computation, but to actually enact the computed path the signa= ling needs to be done from the source end of those LSPs.  So there is = no point in doing concurrent computation at one network element for the ser= vices starting from multiple network elements. At best it looks to me a problem to be solved by network managem= ent/planning software.&nb= sp;

[VPB]  I'm not sur= e why you think there is no point in having a centralized computation funct= ion compute paths concurrently for LSPs with different set of end-points. Even your NMS/planning-software can interact = with such computation engine, retrieve all the paths and then go about init= iating the path-setup from the ingress of each LSP. =

 

Regards,

-Pavan

 

 

 

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Tuesday, March 26, 2013 7:19 PM
To: Dieter Beller; Vishnu Pavan Beeram


Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Dieter,

 

You said:

>> I guess we are= coming back to the essential point: "and how often concurrent path computation will be >> used."

 

To be honest, this surp= rises me quite a bit, Let me give you some of many reasons as to why concur= rent path computations are needed and why this is better than computing one path at a time:

 

1.      Computing several diverse= paths for the same service in the context of service recovery. I hope you = realize that computing one path at a time on many configurations produces n= o or sub-optimal results. I also hope you realize the problem of selecting two paths with one of them  havi= ng a link with common MELG with a link from another path;=

2.      Computing paths for multi= ple services to be sufficiently disjoint from each other;=

3.      Computing paths for multi= ple services to achieve a global optimization criteria (e.g. minimal summar= y total cost);

4.      Computing paths for multi= ple services for the purpose of removing the bandwidth fragmentations;=

5.      Computing paths for multi= ple services to plan shared mesh protection/restoration schemes<= /span>

6.      Etc.

 

Also think about this:<= o:p>

1.      If concurrent path comput= ation was not important, why PCEP includes the machinery to do that?

2.      My understanding of the s= tatefull PCE is that it does pretty much nothing but concurrent path comput= ations

 

You also said:

>> I suppose that if a = pce approach is used, i.e., path computation is centralized including the >> TE-DB, MELG routing extensions are not needed because the informat= ion about mutual
>>exclusive VLs can be kept in the central TE-DB when VLs are configu= red.

How this logic does not= apply to other link attributes such as SRLGs?

What if path computatio= n is not centralized?

 

Cheers,

Igor

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Hi Pavan,<= /p>

On 25.03.2013 07:29, Fat= ai Zhang wrote:

Hi Pavan,

 

I am not sur= e how much VL (Virtual Link) will be used in the practical deployment and how often concurrent path computation will be used.<= span style=3D"mso-fareast-language:ZH-CN">

I guess we are coming b= ack to the essential point: "and how often concurrent path computation will be used."

This means we are trying to figure out under which conditions MELG routing = extensions
could be beneficial.

IMHO, they would only make sense, if:

  • a path computation function supp= orts the calculation of k shortest paths concurrently
  • if there is only a single path c= omputation function instance per domain (pce approach)
    If path computation is done in a distributed fashion the benefit goes away = because
    the instances calculate paths independently!

I suppose that if a pce appro= ach is used, i.e., path computation is centralized including the
TE-DB, MELG routing extensions are not needed because the information about= mutual
exclusive VLs can be kept in the central TE-DB when VLs are configured.

Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their
applicability is broader.


Thanks,
Dieter

 

Do you think if it ma= kes sense to add a flag (in routing advertisement) to indicate a link is a = VL or not?

 

 

 

Best Regards

 

Fatai

 

From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Fatai, Hi!

 

Good to see that you un= derstand the construct now.

 

This is not a corner ca= se. The utility of the construct becomes quite significant if you have an a= pplication that does concurrent path computations on an abstract topology.

 

Regards,

-Pavan

 

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

 

--

= DIETER BELLER

ALCATEL-LUCEN= T DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 711 821 43125 begin_of_the_skype_highlighting 3D"Image&#= 43;49 711 821 43125 FREE  end_of_the_skype_highlighting
Mobil: +49 175 7266874 begin_of_the_skype_highlighting 3D"=+49 175 7266874 FREE  = end_of_the_skype_highlighting

 

Alcatel-Lucent Deutschland A= G
Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe

 

 

--_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923A963atlsrvmail10atl_-- --_004_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923A963atlsrvmail10atl_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=823; creation-date="Mon, 22 Apr 2013 13:58:28 GMT"; modification-date="Mon, 22 Apr 2013 13:58:28 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABkAGQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigD//2Q== --_004_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923A963atlsrvmail10atl_-- From internet-drafts@ietf.org Mon Apr 22 09:59:08 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0DA621F8F12; Mon, 22 Apr 2013 09:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.095, 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 hSgDqh27HMJG; Mon, 22 Apr 2013 09:59:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEE821F8E77; Mon, 22 Apr 2013 09:59:08 -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.44.p3 Message-ID: <20130422165908.14080.53778.idtracker@ietfa.amsl.com> Date: Mon, 22 Apr 2013 09:59:08 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-rsvp-te-li-lb-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 16:59:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : GMPLS RSVP-TE Extensions for Lock Instruct and Loopback Author(s) : Jie Dong Mach Chen Zhenqiang Li Filename : draft-ietf-ccamp-rsvp-te-li-lb-00.txt Pages : 7 Date : 2013-04-12 Abstract: This document specifies extensions to RSVP-TE to support lock instruct and loopback mechanism for LSPs. The mechanisms are applicable to technologies which use GMPLS as control plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-li-lb There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-li-lb-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kpithewan@infinera.com Mon Apr 22 11:16:28 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0232921F8F6E for ; Mon, 22 Apr 2013 11:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_66=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 0tUknkrTBOvm for ; Mon, 22 Apr 2013 11:16:10 -0700 (PDT) Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id C204B21F8F38 for ; Mon, 22 Apr 2013 11:16:10 -0700 (PDT) Received: from SV-EXDB-PROD2.infinera.com ([fe80::1d05:1822:aaea:ff52]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.02.0342.003; Mon, 22 Apr 2013 11:16:10 -0700 From: Khuzema Pithewan To: Igor Bryskin , Fatai Zhang , Vishnu Pavan Beeram , "Dieter Beller" Thread-Topic: [CCAMP] MELGs - Q&A Thread-Index: AQHOIGPek8R0zdnmbUizkEjN3z7415ivh4owgAA2TQCAATLDIIAAeV3g///IfQCABM8nkIABeO8AgAELY4CAGhSNwIAAhvCAgAAQMoD//6fVoIAAemEA//+PR9AAEKirAAANdD1g//+2wYD//LZZoIAH3AeA//9AGeCAAi+OAIAEAu0AgACV+ACAANeoAIAD+iqAgAAuj6A= Date: Mon, 22 Apr 2013 18:16:09 +0000 Message-ID: References: <5150C704.2040007@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.100.156.118] Content-Type: multipart/related; boundary="_004_D8D01B39D6B38C45AA37C06ECC1D65D53FD04629SVEXDBPROD2infi_"; type="multipart/alternative" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] MELGs - Q&A X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 18:16:28 -0000 --_004_D8D01B39D6B38C45AA37C06ECC1D65D53FD04629SVEXDBPROD2infi_ Content-Type: multipart/alternative; boundary="_000_D8D01B39D6B38C45AA37C06ECC1D65D53FD04629SVEXDBPROD2infi_" --_000_D8D01B39D6B38C45AA37C06ECC1D65D53FD04629SVEXDBPROD2infi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Igor, Indeed you are solving the problem described in the case 1 and probably the= only case MELG is trying to solve, However MELG draft read gives an impres= sion that you are trying to solve far more generic issue of mutual exclusiv= ity of virtual links w.r.t. resources in server layer and this seems farfe= tched and hence confusion and discussion. It might be apt to capture this usecase in draft in such a way that, it act= ually solves only this case. Thanks Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Monday, April 22, 2013 7:28 PM To: Fatai Zhang; Vishnu Pavan Beeram; Khuzema Pithewan; Dieter Beller Cc: ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Fatai and Khuzema, In my opinion you confuse two cases: Case 1. Two virtual links are served by WDM layer. The potential paths supp= orting each VL are terminated on the same transponder, hence the two VLs ar= e mutually exclusive. Note that this mutual exclusivity relationship is sta= tic: it is true at all times and does not depend on anything else (e.g. it = does not depend on # of available wavelengths on WDM links the transponder = could be connected to). This is the case of MELGs and is focus of our MELG = draft; Case 2. Two virtual links are served by WDM layer. The potential paths supp= orting each VL use a common WDM link that has only one wavelength available= at the moment, hence the two VLs are mutually exclusive. Note that this mu= tual exclusivity is dynamic: as soon as an additional wavelength becomes av= ailable on the common WDM link, the two VLs will be able to be committed at= the same time. This is not the MELG case. We discussed this dynamic mutual= exclusivity (Cyril was the first, I believe, to bring this up) and have de= cided to keep this case out of scope of the MELG draft. Note, that there is= a simple solution for this case based on the VL model, which we will solve= in a separate draft. This solution does not include the inter-layer path c= omputation: the whole point of the VLs is to alleviate the clients from dea= ling with the server layer traffic engineering and path computations. Cheers, Igor From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Friday, April 19, 2013 9:14 PM To: Igor Bryskin; Vishnu Pavan Beeram; Khuzema Pithewan; Dieter Beller Cc: ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, I have explained to Pavan. The path computation element (centralized PCE for inter-layer or multiple P= CEs through communication) can take care of this issue. In addition, in this case, how you advertise MELGS for this two VT links? = Will you advertise that VL 1 must be exclusive with VL2? That is wrong, bec= ause VL1 and VL2 can be used for the disjoint paths in the client layer. Best Regards Fatai From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 19, 2013 8:22 PM To: Fatai Zhang; Vishnu Pavan Beeram; Khuzema Pithewan; Dieter Beller Cc: ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Fatai, What is Virtual Link? As described in RFC6001, it says as below. So my ques= tion is: when there are two VLs created through Call approach as defined in= RFC6001, one has 3 potential paths in the server layer to setup FA-LSP, an= d another has 2 potential paths in the server layer, and only one of the 3 = &2 has the same resource shared in the server layer. How MELGs can help in this case? IB>> Simple: with MELGs the path computer will know in advance that selecti= ng two paths with a virtual link belonging to path #1 and a virtual link be= longing to path #2 having an MELG in common will be a bad idea, because an = attempt to provision such path combination is guaranteed to fail. Without M= ELGs the path computer won't have such knowledge. Cheers, Igor From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Thursday, April 18, 2013 11:26 PM To: Vishnu Pavan Beeram; Khuzema Pithewan; Igor Bryskin; Dieter Beller Cc: ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Pavan, Igor I think there are some concerns about the applicability of MELGs and I have= the same feeling as Khuzema and Dieter. I still think that MELGS can only handle a very small corner case as you pu= t many cases below where MELGs are not needed. What is Virtual Link? As described in RFC6001, it says as below. So my ques= tion is: when there are two VLs created through Call approach as defined in= RFC6001, one has 3 potential paths in the server layer to setup FA-LSP, an= d another has 2 potential paths in the server layer, and only one of the 3 = &2 has the same resource shared in the server layer. How MELGs can help in this case? =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=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 A virtual TE link is defined as a TE link between two upper-layer nodes tha= t is not associated with a fully provisioned FA-LSP in a lower layer [RFC52= 12]. A virtual TE link is advertised a= s any TE link, following the rules in [RFC4206] defined for fully provisioned TE links. A virtual TE link represe= nts thus the potentiality to set up an FA-LSP in the lower layer to support= the TE link that has been advertised. =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=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 Best Regards Fatai From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Vishnu Pavan Beeram Sent: Tuesday, April 16, 2013 10:10 PM To: Khuzema Pithewan Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Khuzema, Hi! MELGs are useful and come into play only when: (1) The server network domain is abstracted and the advertised Virtual TE-l= inks possess some mutual exclusivity relationship. (2) There is a Centralized path computation entity in the client domain (co= mputes paths in terms of Client TE-links/TE-nodes) that is capable of doing= concurrent path computations. If either of the above 2 statements is NOT true, there is no utility for ME= LGs. At the risk of being pedantic: - Are MELGs needed when the server-network domain in not abstracted (no Vir= tual TE links)? The answer is NO. - Are MELGs needed when you have a distributed path-computation architectur= e (Client PCE interacting with Server PCE)? The answer is NO. - Are MELGs needed when the centralized path-computation engine doesn't (ca= n't) do concurrent computations? The answer is NO. The actual procedures involved in abstracting the server network domain is = beyond the scope of . The abstraction procedure itself is impl= ementation-specific (maybe someday someone would put together a draft for d= iscussing this). Though it is true that the primary use-case we had in mind= when coming up with this new construct involves a lambda-layer server netw= ork domain, there is really no restriction (at a conceptual level) on using= this construct when abstracting a packet-layer server network domain or a = TDM-layer server network domain. It is up to the implementation on how to m= ake best use of this construct. When you advertise a Virtual TE-link into a client network domain, you are = doing this based on the existence of some potential underlying server-path.= TE attributes like SRLGs, MELGs, delay etc that get advertised for the Vir= tual TE-link depend on the underlying server-path that is chosen for cateri= ng to this Client TE-link. If the underlying server-path keeps changing (ba= sed on network events), these TE attributes would also keep changing. The p= rocedure for keeping the advertised information "current" is an implementat= ion choice. If there exists such a thing as an abstraction manager (again, this is tota= lly implementation specific), then the assumption is that it does one of th= e following - (a) computes new server-paths for the Virtual TE links whenever there is a = change in the network (may not be very scalable in some architectures), (b) or does periodic path-computation for each Virtual TE link, (c) or uses a policy to pin down the Virtual TE-link to a specific underlyi= ng server-path, (d) or uses a combination of (a), (b), (c). doesn't make any recommendation as to what choice the abstrac= tion manager would need to take. Hope this helps. -Pavan On Tue, Apr 16, 2013 at 7:08 AM, Khuzema Pithewan > wrote: Hi Igor, I am trying to summarize the discussion we had so far. Pls see if my conclu= sion is in sync with the idea of MELG you have MELG is useful when 1. server layer VLs are nailed down for the resources on the server l= ayer links that are shared among multiple VLs. These resources are typicall= y wavelength on a fiber (can it be anything else??). In other words, if 2 V= Ls are pinned to use a particular wavelength on a particular fiber, then th= ese 2 VLs will have MELG for the wavelength. 2. server layer do not have centralized path computation entity which= can be used by client layer to ask for concurrent diverse path computation= within server layer. 3. Client layer has a centralized path computation entity, which woul= d compute paths for client+server layer. 4. The need is to centralized concurrent computation of more than one= client+server layer path that meets some diversity and resource exclusivit= y requirements. Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Monday, April 15, 2013 9:44 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Please, see in-line. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Monday, April 15, 2013 12:05 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, I understand the SRLG and MELG behavior you have penned . My concern was little different. With changing resource consumption (becau= se of dynamicity the network has) in the network links, potential paths a s= et of virtual link can take will change and hence its MELG, as it is tied t= o a resource it can take. So unless virtual links paths are nailed down, it= would be hard to compute MELGs in distributed way. IB>> I think you are missing the point here. Virtual Link server layer path= s are pinned as far as fate sharing is concerned (that is, they are pinned = on server layer link level). It would make little sense to advertise VL SR= LGs if the SRLGs constantly change. The same is true for MELGs. SRLGs/MELG= s advertised for VLs normally do not change: neither over time nor when VLs= become committed/uncommitted. Another point is, virtual links can be viewed as oversubscription of resour= ces (in MELG context). Taking an example (for OTN, I know it would work dif= ferently for a Wavelength in WDM), a link resources are worth 1 TB of BW, u= ser has provisioned 20 virtual links of 100G each going via that OTN link. = Physically, only 10 will get committed. But which 10? It will really depen= d on network dynamics at the time of demand to commit. MELGs are not that e= ffective here. You need some different mechanism. IB>> As I mentioned before MELGs have nothing to do with bandwidth and were= never intended to solve the problems such as you describe (just like it wo= uld not make much sense to solve such problem with SRLGs :=3D) Again, MELG is an extreme case SRLG designed exclusively for VLs (no more = and no less). Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 11:55 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Think about MELG as an SRLG that is shared between two or more links in its= entirety. When two real links have an SRLG in common, it means that two re= al links can co-exist concurrently, but there is something (e.g. common con= duit, note that the conduit has room for more than for one link) that will = bring both these links down, if this something fails (e.g. conduit is cut )= . Now consider that this something must be taken in its entirety by one of = the links to become operational . In this case SRLG becomes MELG. Note that= MELG is only meaningful for virtual links (unlike SRLG that makes sense fo= r either real or virtual link). Why would you advertise two links that mutu= ally exclude each other rather than advertising only one of them at a time,= unless the two are virtual links and hence both available for the client l= ayer connections? Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 1:01 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Do you mean, if virtual link do not have any specific constraint, for examp= le a link in the path (not talking about egress links/interfaces) must be t= raversed to realize the virtual link, there wont be any MELG for the virtua= l link? Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 9:52 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, MELGs have nothing to do with bandwidth. MELG is a concrete network resourc= e in a server layer that two or more Virtual Links in a client layer depend= on in a mutually exclusive way. An example of MELG is a WDM layer transpon= der that can terminate either of respective WDM layer tunnels (but not both= at the same time) for two OTN layer Virtual Links. If you advertise a Virt= ual Link, say, for Ethernet layer that depends on the connection in OTN lay= er going through one of the mentioned OTN links, the Ethernet VL must inher= it the MELG similarly like it does SRLGs advertised for the OTN links. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 12:06 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, For multi-layer (more than 2) network, consider all the layers are meshy (t= hat's when virtual links are useful anyway), MELGs of virtual link will cha= nge as and when BW/wavelength availability changes, because potential paths= , a virtual link can take will change. Mapping lower layer MELGs to higher = layer MELGs won't be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all= the risk and paths (a PCE?), which can be utilized for layer specific path= computation (as it is doing it anyway). This kind of architecture has all the pieces that are required for Inter-PC= E communication (across layers), except the protocol that would actually ma= ke the 2 PCEs talk. You seem to be doing something that you don't like :) Regards Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 8:39 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, I am not a fan of inter-layer path computations (nor I am a fan of inter-PC= E computations). In my mind path computation for a service or services in l= ayer X is performed only in layer X, i.e. considers only X layer links (rea= l or virtual). As Pavan mentioned SRLGs and MELGs that need to be inherited= from lower layers should be translated into X layer link SRLGs/MELGs and s= pecified with X layer specific SRLG/MELG IDs. Cheers, Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 10:55 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Ok. This would be useful if network architecture is based on external PCE o= r mgmt entity as PCE in client layer, but there is no counterpart in server= layer, otherwise one could have inter-PCE communication to achieve diverse= path in server layer without getting into virtual link and MELG stuff. Is that correct? Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 6:36 PM To: Vishnu Pavan Beeram; Khuzema Pithewan Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. Well, when an ingress node is initiating a service, it is doing so on reque= st from some management entity. This management entity can compute paths fo= r many services with some global criteria in mind, and then specify the res= ulting paths as explicit EROs in provisioning requests sent to each of the = service ingresses. How else, for example, you can set up several services = originated from different nodes that are disjoint from each other? Also, wh= at is the point in your opinion of the statefull PCE work? Cheers, Igor From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, April 12, 2013 8:08 AM To: Khuzema Pithewan Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Khuzema, Hi! Please see inline.. 1. When Network has more than 2 layer i.e. Packet-OTN-DWDM, the Pack= et (client) layer will be talking to its immediate server layer i.e. OTN, w= hich in turn is talking to DWDM layer. Using MELG, client layer path comput= ation can take care of resource exclusivity of virtual link for immediate s= erver layer i.e. OTN layer. However if there is resource exclusivity at DW= DM layer, this mechanism doesn't work. You need to do loose routing or use = distributed PCE model [VPB] The behavior is the same as what you would do with SRLGs in a multi-l= ayer architecture. There are architectures that allow the SRLGs in the lowe= st layer to be exported all the way up to the highest layer. The expectatio= n is that MELGs would be treated in the same vein. 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. [VPB] I'm not sure why you think there is no point in having a centralized= computation function compute paths concurrently for LSPs with different se= t of end-points. Even your NMS/planning-software can interact with such com= putation engine, retrieve all the paths and then go about initiating the pa= th-setup from the ingress of each LSP. Regards, -Pavan From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Igor Bryskin Sent: Tuesday, March 26, 2013 7:19 PM To: Dieter Beller; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Dieter, You said: >> I guess we are coming back to the essential point: "and how often concur= rent path computation will be >> used." To be honest, this surprises me quite a bit, Let me give you some of many r= easons as to why concurrent path computations are needed and why this is be= tter than computing one path at a time: 1. Computing several diverse paths for the same service in the context= of service recovery. I hope you realize that computing one path at a time = on many configurations produces no or sub-optimal results. I also hope you = realize the problem of selecting two paths with one of them having a link = with common MELG with a link from another path; 2. Computing paths for multiple services to be sufficiently disjoint f= rom each other; 3. Computing paths for multiple services to achieve a global optimizat= ion criteria (e.g. minimal summary total cost); 4. Computing paths for multiple services for the purpose of removing t= he bandwidth fragmentations; 5. Computing paths for multiple services to plan shared mesh protectio= n/restoration schemes 6. Etc. Also think about this: 1. If concurrent path computation was not important, why PCEP includes= the machinery to do that? 2. My understanding of the statefull PCE is that it does pretty much n= othing but concurrent path computations You also said: >> I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the >> TE-DB, MELG routing extensions are not needed because the information ab= out mutual >>exclusive VLs can be kept in the central TE-DB when VLs are configured. How this logic does not apply to other link attributes such as SRLGs? What if path computation is not centralized? Cheers, Igor From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Dieter Beller Sent: Monday, March 25, 2013 5:52 PM To: Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Hi Pavan, On 25.03.2013 07:29, Fatai Zhang wrote: Hi Pavan, I am not sure how much VL (Virtual Link) will be used in the practical depl= oyment and how often concurrent path computation will be used. I guess we are coming back to the essential point: "and how often concurren= t path computation will be used." This means we are trying to figure out under which conditions MELG routing = extensions could be beneficial. IMHO, they would only make sense, if: * a path computation function supports the calculation of k shortest pa= ths concurrently * if there is only a single path computation function instance per doma= in (pce approach) If path computation is done in a distributed fashion the benefit goes away = because the instances calculate paths independently! I suppose that if a pce approach is used, i.e., path computation is central= ized including the TE-DB, MELG routing extensions are not needed because the information about= mutual exclusive VLs can be kept in the central TE-DB when VLs are configured. Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their applicability is broader. Thanks, Dieter Do you think if it makes sense to add a flag (in routing advertisement) to = indicate a link is a VL or not? Best Regards Fatai From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, March 22, 2013 8:57 PM To: Fatai Zhang Cc: Igor Bryskin; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Fatai, Hi! Good to see that you understand the construct now. This is not a corner case. The utility of the construct becomes quite signi= ficant if you have an application that does concurrent path computations on= an abstract topology. Regards, -Pavan _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp -- DIETER BELLER ALCATEL-LUCENT DEUTSCHLAND AG PROJECT MANAGER ASON/GMPLS CONTROL PLANE CORE NETWORKS BUSINESS DIVISION OPTICS BU, SWITCHING R&D Lorenzstrasse 10 70435 Stuttgart, Germany Phone: +49 711 821 43125 begin_of_the_skype_highlighting [Image removed by = sender.] +49 711 821 43125 FREE end_of_the_skype_highlighting Mobil: +49 175 7266874 begin_of_the_skype_highlighting [Image removed by se= nder.] +49 175 7266874 FREE end_of_the_skype_highlighting Dieter.Beller@alcatel-lucent.com Alcatel-Lucent Deutschland AG Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026 Chairman of the Supervisory Board: Michael Oppenhoff Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe --_000_D8D01B39D6B38C45AA37C06ECC1D65D53FD04629SVEXDBPROD2infi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Igor,

 <= /p>

Indeed you are solving th= e problem described in the case 1 and probably the only case MELG is trying= to solve, However MELG draft read gives an impression that you are trying to solve far more generic issue of mutual exclusivity of vi= rtual links w.r.t. resources in server layer  and this seems farfetche= d and hence confusion and discussion.

 <= /p>

It might be apt to captur= e this usecase in draft in such a way that, it actually solves only this ca= se.

 <= /p>

Thanks<= /p>

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptical.com]
Sent: Monday, April 22, 2013 7:28 PM
To: Fatai Zhang; Vishnu Pavan Beeram; Khuzema Pithewan; Dieter Belle= r
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Fatai and Khuzema,

 <= /p>

In my opinion you confuse= two cases:

 <= /p>

Case 1. Two virtual links= are served by WDM layer. The potential paths supporting each VL are termin= ated on the same transponder, hence the two VLs are mutually exclusive. Note that this mutual exclusivity relationship is static: it is= true at all times and does not depend on anything else (e.g. it does not d= epend on # of available wavelengths on WDM links the transponder could be c= onnected to). This is the case of MELGs and is focus of our MELG draft;

 <= /p>

Case 2. Two virtual links= are served by WDM layer. The potential paths supporting each VL use a comm= on WDM link that has only one wavelength available at the moment, hence the two VLs are mutually exclusive. Note that this mutual ex= clusivity is dynamic: as soon as an additional wavelength becomes available= on the common WDM link, the two VLs will be able to be committed at the sa= me time. This is not the MELG case. We discussed this dynamic mutual exclusivity (Cyril was the first, I belie= ve, to bring this up) and have decided to keep this case out of scope of th= e MELG draft. Note, that there is a simple solution for this case based on = the VL model, which we will solve in a separate draft. This solution does not include the inter-layer path c= omputation: the whole point of the VLs is to alleviate the clients from dea= ling with the server layer traffic engineering and path computations.<= /o:p>

 <= /p>

Cheers,=

Igor

 <= /p>

 <= /p>

From: Fatai Zh= ang [mailto:zhangfatai@huawei.com]
Sent: Friday, April 19, 2013 9:14 PM
To: Igor Bryskin; Vishnu Pavan Beeram; Khuzema Pithewan; Dieter Bell= er
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

 

 

 

 

Best Regards

 

Fatai

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 19, 2013 8:22 PM
To: Fatai Zhang; Vishnu Pavan Beeram; Khuzema Pithewan; Dieter Belle= r
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

What is Virtual Link? As described in RFC6001,= it says as below. So my question is: when there are two VLs created through Call approach as defined in RFC6001, one has 3 potential p= aths in the server layer to setup FA-LSP, and another has 2 potential paths= in the server layer, and only one of the 3 &2 has the same resource sh= ared in the server layer.

 

How MELGs can help in this case?

 

IB>> Simple: with MELGs the path compute= r will know in advance that selecting two paths with a virtual link belonging to path #1 and a virtual link belonging to path #2 having an MEL= G in common will be a bad idea, because an attempt to provision such path c= ombination is guaranteed to fail. Without MELGs the path computer won’= ;t have such knowledge.

 

Cheers,

Igor

From: Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Thursday, April 18, 2013 11:26 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan; Igor Bryskin; Dieter Bell= er
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

A virtual TE link is defined as a TE l= ink between two upper-layer nodes that is not associated with a fully provisioned FA-LSP in a lower layer [RFC5212].  A virtual TE link is advertised as any TE link, following the rules in [RFC4206] defined for fully provisioned TE links.  A virtual TE link represents thus the potentiality to set up an FA-LSP= in the lower layer to support the TE link that has been advertised.=

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

 

 

 

 

Best Regards

 

Fatai

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Vishnu Pavan Beeram
Sent: Tuesday, April 16, 2013 10:10 PM
To: Khuzema Pithewan
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Khuzema, = Hi!

 

MELGs are= useful and come into play only when:

(1) The s= erver network domain is abstracted and the advertised Virtual TE-links poss= ess some mutual exclusivity relationship.

(2) There= is a Centralized path computation entity in the client domain (computes pa= ths in terms of Client TE-links/TE-nodes) that is capable of doing concurre= nt path computations.

 

If either= of the above 2 statements is NOT true, there is no utility for MELGs. = ;

At the ri= sk of being pedantic: 

- Are MEL= Gs needed when the server-network domain in not abstracted (no Virtual TE l= inks)? The answer is NO.

- Are MEL= Gs needed when you have a distributed path-computation architecture (Client= PCE interacting with Server PCE)? The answer is NO.

- Are MEL= Gs needed when the centralized path-computation engine doesn't (can't) do c= oncurrent computations? The answer is NO.

 

The actua= l procedures involved in abstracting the server network domain is beyond th= e scope of <draft-melgs>. The abstraction procedure itself is impleme= ntation-specific (maybe someday someone would put together a draft for discussing this). Though it is true that the prim= ary use-case we had in mind when coming up with this new construct involves= a lambda-layer server network domain, there is really no restriction (at a= conceptual level) on using this construct when abstracting a packet-layer server network domain or a TDM-l= ayer server network domain. It is up to the implementation on how to make b= est use of this construct. 

 

When you = advertise a Virtual TE-link into a client network domain, you are doing thi= s based on the existence of some potential underlying server-path. TE attri= butes like SRLGs, MELGs, delay etc that get advertised for the Virtual TE-link depend on the underlying server-pat= h that is chosen for catering to this Client TE-link. If the underlying ser= ver-path keeps changing (based on network events), these TE attributes woul= d also keep changing. The procedure for keeping the advertised information "current" is an implement= ation choice. 

 

If there = exists such a thing as an abstraction manager (again, this is totally imple= mentation specific), then the assumption is that it does one of the followi= ng - 

(a) compu= tes new server-paths for the Virtual TE links whenever there is a change in= the network (may not be very scalable in some architectures), 

(b) or do= es periodic path-computation for each Virtual TE link, 

(c) or us= es a policy to pin down the Virtual TE-link to a specific underlying server= -path, 

(d) or us= es a combination of (a), (b), (c).

 

<draft= -melgs> doesn't make any recommendation as to what choice the abstractio= n manager would need to take.

 

Hope this= helps.

-Pavan

 

On Tue, A= pr 16, 2013 at 7:08 AM, Khuzema Pithewan <kpithewan@infinera.com> wrote:

Hi Igor,

 

I am trying = to summarize the discussion we had so far. Pls see if my conclusion is in sync with the idea of MELG you have

 

MELG is usef= ul when=

1.  = ;     server layer V= Ls are nailed down for the resources on the server layer links that are sha= red among multiple VLs. These resources are typically wavelength on a fiber (can it be anything else??). In other words, if 2 VL= s are pinned to use a particular wavelength on a particular fiber, then the= se 2 VLs will have MELG for the wavelength.

2.  = ;     server layer d= o not have centralized path computation entity which can be used by client = layer to ask for concurrent diverse path computation within server layer.=

3.  = ;     Client layer h= as a centralized path computation entity, which would compute paths for cli= ent+server layer.

4.  = ;     The need is to= centralized concurrent computation of more than one client+server laye= r path that meets some diversity and resource exclusivity requirements.=

 

Regds=

Khuzema

 

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Monday, April 15, 2013 9:44 PM


To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

Please, see = in-line.

 

Igor<= span style=3D"mso-fareast-language:ZH-CN">

 

From: Khuzema Pithewan [mailto:kpithewan@infinera.com]
Sent: Monday, April 15, 2013 12:05 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

I understand= the SRLG and MELG behavior you have penned .

 

My concern w= as little different.  With changing resource consumption (because of dynamicity the network has) in the network links, potential paths a set= of virtual link can take will change and hence its MELG, as it is tied to = a resource it can take. So unless virtual links paths are nailed down, it w= ould be hard to compute MELGs in distributed way.

 

IB>> I= think you are missing the point here. Virtual Link server layer paths are pinned as far as fate sharing is concerned (that is, they are pi= nned on  server layer link level). It would make little sense to adver= tise VL SRLGs if the SRLGs constantly change. The same is true for MELGs. &= nbsp;SRLGs/MELGs advertised for VLs normally do not change: neither over time nor when VLs become committed/uncommitted= .

 

Another poin= t is, virtual links can be viewed as oversubscription of resources (in MELG context). Taking an example (for OTN, I know it would work differ= ently for a Wavelength in WDM), a link resources are worth 1 TB of BW, user= has provisioned 20 virtual links of 100G each going via that OTN link. &nb= sp;Physically, only 10 will get committed. But which 10? It will really depend on network dynamics at the time of dem= and to commit. MELGs are not that effective here. You need some different m= echanism.

 

IB>> A= s I mentioned before MELGs have nothing to do with bandwidth and were never intended to solve the problems such as you describe (just like = it would not make much sense to solve such problem with SRLGs :=3D)<= span style=3D"mso-fareast-language:ZH-CN">

Again,  = ;MELG is an extreme case SRLG designed exclusively for VLs (no more and no less).<= /o:p>

 

Regds=

Khuzema

 

 

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 11:55 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

Think about = MELG as an SRLG that is shared between two or more links in its entirety. When two real links have an SRLG in common, it means that tw= o real links can co-exist concurrently, but there is something (e.g. common= conduit, note that the conduit has room for more than for one link) that w= ill bring both these links down, if this something fails (e.g. conduit is cut ). Now consider that this som= ething must be taken in its entirety by one of the links to become operatio= nal . In this case SRLG becomes MELG. Note that MELG is only meaningful for= virtual links (unlike SRLG that makes sense for either real or virtual link). Why would you advertise two = links that mutually exclude each other rather than advertising only one of = them at a time, unless the two are virtual links and hence both available f= or the client layer connections?

 

Igor

 

 

From: Khuzema Pithewan [mailto:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 1:01 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

Do you mean,= if virtual link do not have any specific constraint, for example a link in the path (not talking about egress links/interfaces) mus= t be traversed to realize the virtual link, there wont be any MELG for the = virtual link?<= /span>

 

Regds=

Khuzema

 

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 9:52 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

MELGs have n= othing to do with bandwidth. MELG is a concrete network resource in a server layer that two or more Virtual Links in a client layer depend = on in a mutually exclusive way. An example of MELG is a WDM layer transpond= er that can terminate either of respective WDM layer tunnels (but not both = at the same time) for two OTN layer Virtual Links. If you advertise a Virtual Link, say, for Ethernet layer th= at depends on the connection in OTN layer going through one of the mentione= d OTN links, the Ethernet VL must inherit the MELG similarly like it does S= RLGs advertised for the OTN links.

 

Igor<= span style=3D"mso-fareast-language:ZH-CN">

 

 

From: Khuzema Pithewan [mailto:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 12:06 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

For multi-la= yer (more than 2) network, consider all the layers are meshy (that’s when virtual links are useful anyway), MELGs of virtual link= will change as and when BW/wavelength availability changes, because potent= ial paths, a virtual link can take will change. Mapping lower layer MELGs t= o higher layer MELGs won’t be practical if done in distributed manner, so it has to be centralized. So you do have= central element in each layer that knows all the risk and paths (a PCE?), = which can be utilized for layer specific path computation (as it is doing i= t anyway).

 

This kind of= architecture has all the pieces that are required for Inter-PCE communication (across layers), except the protocol that would actually mak= e the 2 PCEs talk.

 

You seem to = be doing something that you don’t like J

 

Regards

Khuzema

 

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 8:39 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

I am not a f= an of inter-layer path computations (nor I am a fan of inter-PCE computations). In my mind path computation for a service or services in la= yer X is performed only in layer X, i.e. considers only X layer links (real= or virtual). As Pavan mentioned SRLGs and MELGs that need to be inherited = from lower layers should be translated into X layer link SRLGs/MELGs and specified with X layer specific SRLG/MEL= G IDs.<= /p>

 

Cheers,

Igor<= span style=3D"mso-fareast-language:ZH-CN">

 

 

From: Khuzema Pithewan [mailto:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 10:55 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

Ok. This wou= ld be useful if network architecture is based on external PCE or mgmt entity as PCE in client layer, but there is no counterpart in = server layer, otherwise one could have inter-PCE communication to achieve d= iverse path in server layer without getting into virtual link and MELG stuf= f.

 

Is that corr= ect?

 

Khuzema

 

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 6:36 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

2.       For cases of c= oncurrent computation (case#2-5), you are mainly talking about global optim= ization and diversity among multiple services. You can do the path computation, but to actually enact the computed path the signa= ling needs to be done from the source end of those LSPs.  So there is = no point in doing concurrent computation at one network element for the ser= vices starting from multiple network elements. At best it looks to me a problem to be solved by network managem= ent/planning software.&nb= sp;

Well, when a= n ingress node is initiating a service, it is doing so on request from some management entity. This management entity can compute pa= ths for many services with some global criteria in mind, and then specify t= he resulting paths as explicit EROs in provisioning requests sent to each o= f the service ingresses. How else, for example,  you can set up several services originated from differe= nt nodes that are disjoint from each other? Also, what is the point in your= opinion of the statefull PCE work?

 

Cheers,

Igor<= span style=3D"mso-fareast-language:ZH-CN">

 

From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com]
Sent: Friday, April 12, 2013 8:08 AM
To: Khuzema Pithewan
Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Khuzema, Hi!=


Please see inline..

 

 

 1.       When Network h= as more than 2 layer i.e. Packet-OTN-DWDM, the Packet (client) layer will b= e talking to its immediate server layer i.e. OTN, which in turn is talking to DWDM layer. Using MELG, client layer path computatio= n can take care of resource exclusivity of virtual link for immediate serve= r layer i.e. OTN layer.  However if there is resource exclusivity at D= WDM layer, this mechanism doesn’t work. You need to do loose routing or use distributed PCE model

 

[VPB] The behavior is t= he same as what you would do with SRLGs in a multi-layer architecture. Ther= e are architectures that allow the SRLGs in the lowest layer to be exported all the way up to the highest layer. Th= e expectation is that MELGs would be treated in the same vein. 

2.       For cases of c= oncurrent computation (case#2-5), you are mainly talking about global optim= ization and diversity among multiple services. You can do the path computation, but to actually enact the computed path the signa= ling needs to be done from the source end of those LSPs.  So there is = no point in doing concurrent computation at one network element for the ser= vices starting from multiple network elements. At best it looks to me a problem to be solved by network managem= ent/planning software.&nb= sp;

[VPB]  I'm not sur= e why you think there is no point in having a centralized computation funct= ion compute paths concurrently for LSPs with different set of end-points. Even your NMS/planning-software can interact = with such computation engine, retrieve all the paths and then go about init= iating the path-setup from the ingress of each LSP. =

 

Regards,

-Pavan

 

 

 

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Tuesday, March 26, 2013 7:19 PM
To: Dieter Beller; Vishnu Pavan Beeram


Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Dieter,

 

You said:

>> I guess we are= coming back to the essential point: "and how often concurrent path computation will be >> used."

 

To be honest, this surp= rises me quite a bit, Let me give you some of many reasons as to why concur= rent path computations are needed and why this is better than computing one path at a time:

 

1.      Computing several diverse= paths for the same service in the context of service recovery. I hope you = realize that computing one path at a time on many configurations produces n= o or sub-optimal results. I also hope you realize the problem of selecting two paths with one of them  havi= ng a link with common MELG with a link from another path;=

2.      Computing paths for multi= ple services to be sufficiently disjoint from each other;=

3.      Computing paths for multi= ple services to achieve a global optimization criteria (e.g. minimal summar= y total cost);

4.      Computing paths for multi= ple services for the purpose of removing the bandwidth fragmentations;=

5.      Computing paths for multi= ple services to plan shared mesh protection/restoration schemes<= /span>

6.      Etc.

 

Also think about this:<= o:p>

1.      If concurrent path comput= ation was not important, why PCEP includes the machinery to do that?

2.      My understanding of the s= tatefull PCE is that it does pretty much nothing but concurrent path comput= ations

 

You also said:

>> I suppose that if a = pce approach is used, i.e., path computation is centralized including the >> TE-DB, MELG routing extensions are not needed because the informat= ion about mutual
>>exclusive VLs can be kept in the central TE-DB when VLs are configu= red.

How this logic does not= apply to other link attributes such as SRLGs?

What if path computatio= n is not centralized?

 

Cheers,

Igor

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Hi Pavan,<= /p>

On 25.03.2013 07:29, Fat= ai Zhang wrote:

Hi Pavan,

 

I am not sur= e how much VL (Virtual Link) will be used in the practical deployment and how often concurrent path computation will be used.<= span style=3D"mso-fareast-language:ZH-CN">

I guess we are coming b= ack to the essential point: "and how often concurrent path computation will be used."

This means we are trying to figure out under which conditions MELG routing = extensions
could be beneficial.

IMHO, they would only make sense, if:

  • a path computation function supp= orts the calculation of k shortest paths concurrently
  • if there is only a single path c= omputation function instance per domain (pce approach)
    If path computation is done in a distributed fashion the benefit goes away = because
    the instances calculate paths independently!

I suppose that if a pce appro= ach is used, i.e., path computation is centralized including the
TE-DB, MELG routing extensions are not needed because the information about= mutual
exclusive VLs can be kept in the central TE-DB when VLs are configured.

Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their
applicability is broader.


Thanks,
Dieter

 

Do you think if it ma= kes sense to add a flag (in routing advertisement) to indicate a link is a = VL or not?

 

 

 

Best Regards

 

Fatai

 

From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Fatai, Hi!

 

Good to see that you un= derstand the construct now.

 

This is not a corner ca= se. The utility of the construct becomes quite significant if you have an a= pplication that does concurrent path computations on an abstract topology.

 

Regards,

-Pavan

 

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

 

--

= DIETER BELLER

ALCATEL-LUCEN= T DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 711 821 43125 begin_of_the_skype_highlighting 3D"Image&#= 43;49 711 821 43125 FREE  end_of_the_skype_highlighting
Mobil: +49 175 7266874 begin_of_the_skype_highlighting 3D"=+49 175 7266874 FREE  = end_of_the_skype_highlighting

 

Alcatel-Lucent Deutschland A= G
Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe

 

 

--_000_D8D01B39D6B38C45AA37C06ECC1D65D53FD04629SVEXDBPROD2infi_-- --_004_D8D01B39D6B38C45AA37C06ECC1D65D53FD04629SVEXDBPROD2infi_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=823; creation-date="Mon, 22 Apr 2013 18:16:06 GMT"; modification-date="Mon, 22 Apr 2013 18:16:06 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABkAGQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigD//2Q== --_004_D8D01B39D6B38C45AA37C06ECC1D65D53FD04629SVEXDBPROD2infi_-- From IBryskin@advaoptical.com Mon Apr 22 12:29:12 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0905221F8D27 for ; Mon, 22 Apr 2013 12:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_66=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 oUyTLNM8lR0O for ; Mon, 22 Apr 2013 12:28:58 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1620921F8EE1 for ; Mon, 22 Apr 2013 12:28:56 -0700 (PDT) Received: from MUC-SRV-MBX2.advaoptical.com ([172.20.1.96]) by muc-vsrv-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id r3MJSeSF017167 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Apr 2013 21:28:40 +0200 Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MBX2.advaoptical.com (172.20.1.96) with Microsoft SMTP Server (TLS) id 15.0.620.29; Mon, 22 Apr 2013 21:28:40 +0200 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0123.003; Mon, 22 Apr 2013 15:28:37 -0400 From: Igor Bryskin To: Khuzema Pithewan , Fatai Zhang , Vishnu Pavan Beeram , Dieter Beller Thread-Topic: [CCAMP] MELGs - Q&A Thread-Index: AQHOIGPeoOQf0fNS1kG7ulofq5GmQJivzRoAgABxTHCAAPkpgIAAeAqAgABMBQCABErLAIABAdYAgAC6NQCAGt0OAIAAD52A///KWjCAAGRRgP//wCBQgABTlAD//73CwAAKM0gAAAY9GCAAdYY0gAAQgVwAADCVHoAABlrDAACAXYgAAAonNRAAI4zjAAB2Qw1AABIB6IAABiDkEA== Date: Mon, 22 Apr 2013 19:28:37 +0000 Message-ID: References: <5150C704.2040007@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.21.1.81] Content-Type: multipart/related; boundary="_004_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923AA93atlsrvmail10atl_"; type="multipart/alternative" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-04-22_06:2013-04-22, 2013-04-22, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] MELGs - Q&A X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 19:29:12 -0000 --_004_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923AA93atlsrvmail10atl_ Content-Type: multipart/alternative; boundary="_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923AA93atlsrvmail10atl_" --_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923AA93atlsrvmail10atl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Khuzema, I agree that we need to define the problem more clearly, in particular, to = separate from the case #2. I promise we will provide a solution for case # 2 as well. Thanks, Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Monday, April 22, 2013 2:16 PM To: Igor Bryskin; Fatai Zhang; Vishnu Pavan Beeram; Dieter Beller Cc: ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Indeed you are solving the problem described in the case 1 and probably the= only case MELG is trying to solve, However MELG draft read gives an impres= sion that you are trying to solve far more generic issue of mutual exclusiv= ity of virtual links w.r.t. resources in server layer and this seems farfe= tched and hence confusion and discussion. It might be apt to capture this usecase in draft in such a way that, it act= ually solves only this case. Thanks Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Monday, April 22, 2013 7:28 PM To: Fatai Zhang; Vishnu Pavan Beeram; Khuzema Pithewan; Dieter Beller Cc: ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Fatai and Khuzema, In my opinion you confuse two cases: Case 1. Two virtual links are served by WDM layer. The potential paths supp= orting each VL are terminated on the same transponder, hence the two VLs ar= e mutually exclusive. Note that this mutual exclusivity relationship is sta= tic: it is true at all times and does not depend on anything else (e.g. it = does not depend on # of available wavelengths on WDM links the transponder = could be connected to). This is the case of MELGs and is focus of our MELG = draft; Case 2. Two virtual links are served by WDM layer. The potential paths supp= orting each VL use a common WDM link that has only one wavelength available= at the moment, hence the two VLs are mutually exclusive. Note that this mu= tual exclusivity is dynamic: as soon as an additional wavelength becomes av= ailable on the common WDM link, the two VLs will be able to be committed at= the same time. This is not the MELG case. We discussed this dynamic mutual= exclusivity (Cyril was the first, I believe, to bring this up) and have de= cided to keep this case out of scope of the MELG draft. Note, that there is= a simple solution for this case based on the VL model, which we will solve= in a separate draft. This solution does not include the inter-layer path c= omputation: the whole point of the VLs is to alleviate the clients from dea= ling with the server layer traffic engineering and path computations. Cheers, Igor From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Friday, April 19, 2013 9:14 PM To: Igor Bryskin; Vishnu Pavan Beeram; Khuzema Pithewan; Dieter Beller Cc: ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, I have explained to Pavan. The path computation element (centralized PCE for inter-layer or multiple P= CEs through communication) can take care of this issue. In addition, in this case, how you advertise MELGS for this two VT links? = Will you advertise that VL 1 must be exclusive with VL2? That is wrong, bec= ause VL1 and VL2 can be used for the disjoint paths in the client layer. Best Regards Fatai From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 19, 2013 8:22 PM To: Fatai Zhang; Vishnu Pavan Beeram; Khuzema Pithewan; Dieter Beller Cc: ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Fatai, What is Virtual Link? As described in RFC6001, it says as below. So my ques= tion is: when there are two VLs created through Call approach as defined in= RFC6001, one has 3 potential paths in the server layer to setup FA-LSP, an= d another has 2 potential paths in the server layer, and only one of the 3 = &2 has the same resource shared in the server layer. How MELGs can help in this case? IB>> Simple: with MELGs the path computer will know in advance that selecti= ng two paths with a virtual link belonging to path #1 and a virtual link be= longing to path #2 having an MELG in common will be a bad idea, because an = attempt to provision such path combination is guaranteed to fail. Without M= ELGs the path computer won't have such knowledge. Cheers, Igor From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Thursday, April 18, 2013 11:26 PM To: Vishnu Pavan Beeram; Khuzema Pithewan; Igor Bryskin; Dieter Beller Cc: ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Pavan, Igor I think there are some concerns about the applicability of MELGs and I have= the same feeling as Khuzema and Dieter. I still think that MELGS can only handle a very small corner case as you pu= t many cases below where MELGs are not needed. What is Virtual Link? As described in RFC6001, it says as below. So my ques= tion is: when there are two VLs created through Call approach as defined in= RFC6001, one has 3 potential paths in the server layer to setup FA-LSP, an= d another has 2 potential paths in the server layer, and only one of the 3 = &2 has the same resource shared in the server layer. How MELGs can help in this case? =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=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 A virtual TE link is defined as a TE link between two upper-layer nodes tha= t is not associated with a fully provisioned FA-LSP in a lower layer [RFC52= 12]. A virtual TE link is advertised a= s any TE link, following the rules in [RFC4206] defined for fully provisioned TE links. A virtual TE link represe= nts thus the potentiality to set up an FA-LSP in the lower layer to support= the TE link that has been advertised. =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=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 Best Regards Fatai From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Vishnu Pavan Beeram Sent: Tuesday, April 16, 2013 10:10 PM To: Khuzema Pithewan Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Khuzema, Hi! MELGs are useful and come into play only when: (1) The server network domain is abstracted and the advertised Virtual TE-l= inks possess some mutual exclusivity relationship. (2) There is a Centralized path computation entity in the client domain (co= mputes paths in terms of Client TE-links/TE-nodes) that is capable of doing= concurrent path computations. If either of the above 2 statements is NOT true, there is no utility for ME= LGs. At the risk of being pedantic: - Are MELGs needed when the server-network domain in not abstracted (no Vir= tual TE links)? The answer is NO. - Are MELGs needed when you have a distributed path-computation architectur= e (Client PCE interacting with Server PCE)? The answer is NO. - Are MELGs needed when the centralized path-computation engine doesn't (ca= n't) do concurrent computations? The answer is NO. The actual procedures involved in abstracting the server network domain is = beyond the scope of . The abstraction procedure itself is impl= ementation-specific (maybe someday someone would put together a draft for d= iscussing this). Though it is true that the primary use-case we had in mind= when coming up with this new construct involves a lambda-layer server netw= ork domain, there is really no restriction (at a conceptual level) on using= this construct when abstracting a packet-layer server network domain or a = TDM-layer server network domain. It is up to the implementation on how to m= ake best use of this construct. When you advertise a Virtual TE-link into a client network domain, you are = doing this based on the existence of some potential underlying server-path.= TE attributes like SRLGs, MELGs, delay etc that get advertised for the Vir= tual TE-link depend on the underlying server-path that is chosen for cateri= ng to this Client TE-link. If the underlying server-path keeps changing (ba= sed on network events), these TE attributes would also keep changing. The p= rocedure for keeping the advertised information "current" is an implementat= ion choice. If there exists such a thing as an abstraction manager (again, this is tota= lly implementation specific), then the assumption is that it does one of th= e following - (a) computes new server-paths for the Virtual TE links whenever there is a = change in the network (may not be very scalable in some architectures), (b) or does periodic path-computation for each Virtual TE link, (c) or uses a policy to pin down the Virtual TE-link to a specific underlyi= ng server-path, (d) or uses a combination of (a), (b), (c). doesn't make any recommendation as to what choice the abstrac= tion manager would need to take. Hope this helps. -Pavan On Tue, Apr 16, 2013 at 7:08 AM, Khuzema Pithewan > wrote: Hi Igor, I am trying to summarize the discussion we had so far. Pls see if my conclu= sion is in sync with the idea of MELG you have MELG is useful when 1. server layer VLs are nailed down for the resources on the server l= ayer links that are shared among multiple VLs. These resources are typicall= y wavelength on a fiber (can it be anything else??). In other words, if 2 V= Ls are pinned to use a particular wavelength on a particular fiber, then th= ese 2 VLs will have MELG for the wavelength. 2. server layer do not have centralized path computation entity which= can be used by client layer to ask for concurrent diverse path computation= within server layer. 3. Client layer has a centralized path computation entity, which woul= d compute paths for client+server layer. 4. The need is to centralized concurrent computation of more than one= client+server layer path that meets some diversity and resource exclusivit= y requirements. Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Monday, April 15, 2013 9:44 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Please, see in-line. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Monday, April 15, 2013 12:05 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, I understand the SRLG and MELG behavior you have penned . My concern was little different. With changing resource consumption (becau= se of dynamicity the network has) in the network links, potential paths a s= et of virtual link can take will change and hence its MELG, as it is tied t= o a resource it can take. So unless virtual links paths are nailed down, it= would be hard to compute MELGs in distributed way. IB>> I think you are missing the point here. Virtual Link server layer path= s are pinned as far as fate sharing is concerned (that is, they are pinned = on server layer link level). It would make little sense to advertise VL SR= LGs if the SRLGs constantly change. The same is true for MELGs. SRLGs/MELG= s advertised for VLs normally do not change: neither over time nor when VLs= become committed/uncommitted. Another point is, virtual links can be viewed as oversubscription of resour= ces (in MELG context). Taking an example (for OTN, I know it would work dif= ferently for a Wavelength in WDM), a link resources are worth 1 TB of BW, u= ser has provisioned 20 virtual links of 100G each going via that OTN link. = Physically, only 10 will get committed. But which 10? It will really depen= d on network dynamics at the time of demand to commit. MELGs are not that e= ffective here. You need some different mechanism. IB>> As I mentioned before MELGs have nothing to do with bandwidth and were= never intended to solve the problems such as you describe (just like it wo= uld not make much sense to solve such problem with SRLGs :=3D) Again, MELG is an extreme case SRLG designed exclusively for VLs (no more = and no less). Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 11:55 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Think about MELG as an SRLG that is shared between two or more links in its= entirety. When two real links have an SRLG in common, it means that two re= al links can co-exist concurrently, but there is something (e.g. common con= duit, note that the conduit has room for more than for one link) that will = bring both these links down, if this something fails (e.g. conduit is cut )= . Now consider that this something must be taken in its entirety by one of = the links to become operational . In this case SRLG becomes MELG. Note that= MELG is only meaningful for virtual links (unlike SRLG that makes sense fo= r either real or virtual link). Why would you advertise two links that mutu= ally exclude each other rather than advertising only one of them at a time,= unless the two are virtual links and hence both available for the client l= ayer connections? Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 1:01 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Do you mean, if virtual link do not have any specific constraint, for examp= le a link in the path (not talking about egress links/interfaces) must be t= raversed to realize the virtual link, there wont be any MELG for the virtua= l link? Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 9:52 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, MELGs have nothing to do with bandwidth. MELG is a concrete network resourc= e in a server layer that two or more Virtual Links in a client layer depend= on in a mutually exclusive way. An example of MELG is a WDM layer transpon= der that can terminate either of respective WDM layer tunnels (but not both= at the same time) for two OTN layer Virtual Links. If you advertise a Virt= ual Link, say, for Ethernet layer that depends on the connection in OTN lay= er going through one of the mentioned OTN links, the Ethernet VL must inher= it the MELG similarly like it does SRLGs advertised for the OTN links. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 12:06 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, For multi-layer (more than 2) network, consider all the layers are meshy (t= hat's when virtual links are useful anyway), MELGs of virtual link will cha= nge as and when BW/wavelength availability changes, because potential paths= , a virtual link can take will change. Mapping lower layer MELGs to higher = layer MELGs won't be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all= the risk and paths (a PCE?), which can be utilized for layer specific path= computation (as it is doing it anyway). This kind of architecture has all the pieces that are required for Inter-PC= E communication (across layers), except the protocol that would actually ma= ke the 2 PCEs talk. You seem to be doing something that you don't like :) Regards Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 8:39 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, I am not a fan of inter-layer path computations (nor I am a fan of inter-PC= E computations). In my mind path computation for a service or services in l= ayer X is performed only in layer X, i.e. considers only X layer links (rea= l or virtual). As Pavan mentioned SRLGs and MELGs that need to be inherited= from lower layers should be translated into X layer link SRLGs/MELGs and s= pecified with X layer specific SRLG/MELG IDs. Cheers, Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 10:55 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Ok. This would be useful if network architecture is based on external PCE o= r mgmt entity as PCE in client layer, but there is no counterpart in server= layer, otherwise one could have inter-PCE communication to achieve diverse= path in server layer without getting into virtual link and MELG stuff. Is that correct? Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 6:36 PM To: Vishnu Pavan Beeram; Khuzema Pithewan Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. Well, when an ingress node is initiating a service, it is doing so on reque= st from some management entity. This management entity can compute paths fo= r many services with some global criteria in mind, and then specify the res= ulting paths as explicit EROs in provisioning requests sent to each of the = service ingresses. How else, for example, you can set up several services = originated from different nodes that are disjoint from each other? Also, wh= at is the point in your opinion of the statefull PCE work? Cheers, Igor From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, April 12, 2013 8:08 AM To: Khuzema Pithewan Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Khuzema, Hi! Please see inline.. 1. When Network has more than 2 layer i.e. Packet-OTN-DWDM, the Pack= et (client) layer will be talking to its immediate server layer i.e. OTN, w= hich in turn is talking to DWDM layer. Using MELG, client layer path comput= ation can take care of resource exclusivity of virtual link for immediate s= erver layer i.e. OTN layer. However if there is resource exclusivity at DW= DM layer, this mechanism doesn't work. You need to do loose routing or use = distributed PCE model [VPB] The behavior is the same as what you would do with SRLGs in a multi-l= ayer architecture. There are architectures that allow the SRLGs in the lowe= st layer to be exported all the way up to the highest layer. The expectatio= n is that MELGs would be treated in the same vein. 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. [VPB] I'm not sure why you think there is no point in having a centralized= computation function compute paths concurrently for LSPs with different se= t of end-points. Even your NMS/planning-software can interact with such com= putation engine, retrieve all the paths and then go about initiating the pa= th-setup from the ingress of each LSP. Regards, -Pavan From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Igor Bryskin Sent: Tuesday, March 26, 2013 7:19 PM To: Dieter Beller; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Dieter, You said: >> I guess we are coming back to the essential point: "and how often concur= rent path computation will be >> used." To be honest, this surprises me quite a bit, Let me give you some of many r= easons as to why concurrent path computations are needed and why this is be= tter than computing one path at a time: 1. Computing several diverse paths for the same service in the context= of service recovery. I hope you realize that computing one path at a time = on many configurations produces no or sub-optimal results. I also hope you = realize the problem of selecting two paths with one of them having a link = with common MELG with a link from another path; 2. Computing paths for multiple services to be sufficiently disjoint f= rom each other; 3. Computing paths for multiple services to achieve a global optimizat= ion criteria (e.g. minimal summary total cost); 4. Computing paths for multiple services for the purpose of removing t= he bandwidth fragmentations; 5. Computing paths for multiple services to plan shared mesh protectio= n/restoration schemes 6. Etc. Also think about this: 1. If concurrent path computation was not important, why PCEP includes= the machinery to do that? 2. My understanding of the statefull PCE is that it does pretty much n= othing but concurrent path computations You also said: >> I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the >> TE-DB, MELG routing extensions are not needed because the information ab= out mutual >>exclusive VLs can be kept in the central TE-DB when VLs are configured. How this logic does not apply to other link attributes such as SRLGs? What if path computation is not centralized? Cheers, Igor From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Dieter Beller Sent: Monday, March 25, 2013 5:52 PM To: Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Hi Pavan, On 25.03.2013 07:29, Fatai Zhang wrote: Hi Pavan, I am not sure how much VL (Virtual Link) will be used in the practical depl= oyment and how often concurrent path computation will be used. I guess we are coming back to the essential point: "and how often concurren= t path computation will be used." This means we are trying to figure out under which conditions MELG routing = extensions could be beneficial. IMHO, they would only make sense, if: * a path computation function supports the calculation of k shortest pa= ths concurrently * if there is only a single path computation function instance per doma= in (pce approach) If path computation is done in a distributed fashion the benefit goes away = because the instances calculate paths independently! I suppose that if a pce approach is used, i.e., path computation is central= ized including the TE-DB, MELG routing extensions are not needed because the information about= mutual exclusive VLs can be kept in the central TE-DB when VLs are configured. Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their applicability is broader. Thanks, Dieter Do you think if it makes sense to add a flag (in routing advertisement) to = indicate a link is a VL or not? Best Regards Fatai From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, March 22, 2013 8:57 PM To: Fatai Zhang Cc: Igor Bryskin; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Fatai, Hi! Good to see that you understand the construct now. This is not a corner case. The utility of the construct becomes quite signi= ficant if you have an application that does concurrent path computations on= an abstract topology. Regards, -Pavan _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp -- DIETER BELLER ALCATEL-LUCENT DEUTSCHLAND AG PROJECT MANAGER ASON/GMPLS CONTROL PLANE CORE NETWORKS BUSINESS DIVISION OPTICS BU, SWITCHING R&D Lorenzstrasse 10 70435 Stuttgart, Germany Phone: +49 711 821 43125 begin_of_the_skype_highlighting [Image removed by = sender.] +49 711 821 43125 FREE end_of_the_skype_highlighting Mobil: +49 175 7266874 begin_of_the_skype_highlighting [Image removed by se= nder.] +49 175 7266874 FREE end_of_the_skype_highlighting Dieter.Beller@alcatel-lucent.com Alcatel-Lucent Deutschland AG Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026 Chairman of the Supervisory Board: Michael Oppenhoff Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe --_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923AA93atlsrvmail10atl_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Khuzema,

 <= /p>

I agree that we need to d= efine the problem more clearly, in particular, to separate from the case #2= .

I promise we will provide= a solution for case # 2 as well.

 <= /p>

Thanks,=

Igor

 <= /p>

 <= /p>

From: Khuzema = Pithewan [mailto:kpithewan@infinera.com]
Sent: Monday, April 22, 2013 2:16 PM
To: Igor Bryskin; Fatai Zhang; Vishnu Pavan Beeram; Dieter Beller Cc: ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 <= /p>

Indeed you are solving th= e problem described in the case 1 and probably the only case MELG is trying= to solve, However MELG draft read gives an impression that you are trying to solve far more generic issue of mutual exclusivity of vi= rtual links w.r.t. resources in server layer  and this seems farfetche= d and hence confusion and discussion.

 <= /p>

It might be apt to captur= e this usecase in draft in such a way that, it actually solves only this ca= se.

 <= /p>

Thanks<= /p>

Khuzema=

 <= /p>

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Monday, April 22, 2013 7:28 PM
To: Fatai Zhang; Vishnu Pavan Beeram; Khuzema Pithewan; Dieter Belle= r
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Fatai and Khuzema,

 <= /p>

In my opinion you confuse= two cases:

 <= /p>

Case 1. Two virtual links= are served by WDM layer. The potential paths supporting each VL are termin= ated on the same transponder, hence the two VLs are mutually exclusive. Note that this mutual exclusivity relationship is static: it is= true at all times and does not depend on anything else (e.g. it does not d= epend on # of available wavelengths on WDM links the transponder could be c= onnected to). This is the case of MELGs and is focus of our MELG draft;

 <= /p>

Case 2. Two virtual links= are served by WDM layer. The potential paths supporting each VL use a comm= on WDM link that has only one wavelength available at the moment, hence the two VLs are mutually exclusive. Note that this mutual ex= clusivity is dynamic: as soon as an additional wavelength becomes available= on the common WDM link, the two VLs will be able to be committed at the sa= me time. This is not the MELG case. We discussed this dynamic mutual exclusivity (Cyril was the first, I belie= ve, to bring this up) and have decided to keep this case out of scope of th= e MELG draft. Note, that there is a simple solution for this case based on = the VL model, which we will solve in a separate draft. This solution does not include the inter-layer path c= omputation: the whole point of the VLs is to alleviate the clients from dea= ling with the server layer traffic engineering and path computations.<= /o:p>

 <= /p>

Cheers,=

Igor

 <= /p>

 <= /p>

 

 

 

 

 

Best Regards

 

Fatai

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 19, 2013 8:22 PM
To: Fatai Zhang; Vishnu Pavan Beeram; Khuzema Pithewan; Dieter Belle= r
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

What is Virtual Link? As described in RFC6001,= it says as below. So my question is: when there are two VLs created through Call approach as defined in RFC6001, one has 3 potential p= aths in the server layer to setup FA-LSP, and another has 2 potential paths= in the server layer, and only one of the 3 &2 has the same resource sh= ared in the server layer.

 

How MELGs can help in this case?

 

IB>> Simple: with MELGs the path compute= r will know in advance that selecting two paths with a virtual link belonging to path #1 and a virtual link belonging to path #2 having an MEL= G in common will be a bad idea, because an attempt to provision such path c= ombination is guaranteed to fail. Without MELGs the path computer won’= ;t have such knowledge.

 

Cheers,

Igor

From: Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Thursday, April 18, 2013 11:26 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan; Igor Bryskin; Dieter Bell= er
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

A virtual TE link is defined as a TE l= ink between two upper-layer nodes that is not associated with a fully provisioned FA-LSP in a lower layer [RFC5212].  A virtual TE link is advertised as any TE link, following the rules in [RFC4206] defined for fully provisioned TE links.  A virtual TE link represents thus the potentiality to set up an FA-LSP= in the lower layer to support the TE link that has been advertised.=

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

 

 

 

 

Best Regards

 

Fatai

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Vishnu Pavan Beeram
Sent: Tuesday, April 16, 2013 10:10 PM
To: Khuzema Pithewan
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Khuzema, = Hi!

 

MELGs are= useful and come into play only when:

(1) The s= erver network domain is abstracted and the advertised Virtual TE-links poss= ess some mutual exclusivity relationship.

(2) There= is a Centralized path computation entity in the client domain (computes pa= ths in terms of Client TE-links/TE-nodes) that is capable of doing concurre= nt path computations.

 

If either= of the above 2 statements is NOT true, there is no utility for MELGs. = ;

At the ri= sk of being pedantic: 

- Are MEL= Gs needed when the server-network domain in not abstracted (no Virtual TE l= inks)? The answer is NO.

- Are MEL= Gs needed when you have a distributed path-computation architecture (Client= PCE interacting with Server PCE)? The answer is NO.

- Are MEL= Gs needed when the centralized path-computation engine doesn't (can't) do c= oncurrent computations? The answer is NO.

 

The actua= l procedures involved in abstracting the server network domain is beyond th= e scope of <draft-melgs>. The abstraction procedure itself is impleme= ntation-specific (maybe someday someone would put together a draft for discussing this). Though it is true that the prim= ary use-case we had in mind when coming up with this new construct involves= a lambda-layer server network domain, there is really no restriction (at a= conceptual level) on using this construct when abstracting a packet-layer server network domain or a TDM-l= ayer server network domain. It is up to the implementation on how to make b= est use of this construct. 

 

When you = advertise a Virtual TE-link into a client network domain, you are doing thi= s based on the existence of some potential underlying server-path. TE attri= butes like SRLGs, MELGs, delay etc that get advertised for the Virtual TE-link depend on the underlying server-pat= h that is chosen for catering to this Client TE-link. If the underlying ser= ver-path keeps changing (based on network events), these TE attributes woul= d also keep changing. The procedure for keeping the advertised information "current" is an implement= ation choice. 

 

If there = exists such a thing as an abstraction manager (again, this is totally imple= mentation specific), then the assumption is that it does one of the followi= ng - 

(a) compu= tes new server-paths for the Virtual TE links whenever there is a change in= the network (may not be very scalable in some architectures), 

(b) or do= es periodic path-computation for each Virtual TE link, 

(c) or us= es a policy to pin down the Virtual TE-link to a specific underlying server= -path, 

(d) or us= es a combination of (a), (b), (c).

 

<draft= -melgs> doesn't make any recommendation as to what choice the abstractio= n manager would need to take.

 

Hope this= helps.

-Pavan

 

On Tue, A= pr 16, 2013 at 7:08 AM, Khuzema Pithewan <kpithewan@infinera.com> wrote:

Hi Igor,

 

I am trying = to summarize the discussion we had so far. Pls see if my conclusion is in sync with the idea of MELG you have

 

MELG is usef= ul when=

1.  = ;     server layer V= Ls are nailed down for the resources on the server layer links that are sha= red among multiple VLs. These resources are typically wavelength on a fiber (can it be anything else??). In other words, if 2 VL= s are pinned to use a particular wavelength on a particular fiber, then the= se 2 VLs will have MELG for the wavelength.

2.  = ;     server layer d= o not have centralized path computation entity which can be used by client = layer to ask for concurrent diverse path computation within server layer.=

3.  = ;     Client layer h= as a centralized path computation entity, which would compute paths for cli= ent+server layer.

4.  = ;     The need is to= centralized concurrent computation of more than one client+server laye= r path that meets some diversity and resource exclusivity requirements.=

 

Regds=

Khuzema

 

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Monday, April 15, 2013 9:44 PM


To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

Please, see = in-line.

 

Igor<= span style=3D"mso-fareast-language:ZH-CN">

 

From: Khuzema Pithewan [mailto:kpithewan@infinera.com]
Sent: Monday, April 15, 2013 12:05 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

I understand= the SRLG and MELG behavior you have penned .

 

My concern w= as little different.  With changing resource consumption (because of dynamicity the network has) in the network links, potential paths a set= of virtual link can take will change and hence its MELG, as it is tied to = a resource it can take. So unless virtual links paths are nailed down, it w= ould be hard to compute MELGs in distributed way.

 

IB>> I= think you are missing the point here. Virtual Link server layer paths are pinned as far as fate sharing is concerned (that is, they are pi= nned on  server layer link level). It would make little sense to adver= tise VL SRLGs if the SRLGs constantly change. The same is true for MELGs. &= nbsp;SRLGs/MELGs advertised for VLs normally do not change: neither over time nor when VLs become committed/uncommitted= .

 

Another poin= t is, virtual links can be viewed as oversubscription of resources (in MELG context). Taking an example (for OTN, I know it would work differ= ently for a Wavelength in WDM), a link resources are worth 1 TB of BW, user= has provisioned 20 virtual links of 100G each going via that OTN link. &nb= sp;Physically, only 10 will get committed. But which 10? It will really depend on network dynamics at the time of dem= and to commit. MELGs are not that effective here. You need some different m= echanism.

 

IB>> A= s I mentioned before MELGs have nothing to do with bandwidth and were never intended to solve the problems such as you describe (just like = it would not make much sense to solve such problem with SRLGs :=3D)<= span style=3D"mso-fareast-language:ZH-CN">

Again,  = ;MELG is an extreme case SRLG designed exclusively for VLs (no more and no less).<= /o:p>

 

Regds=

Khuzema

 

 

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 11:55 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

Think about = MELG as an SRLG that is shared between two or more links in its entirety. When two real links have an SRLG in common, it means that tw= o real links can co-exist concurrently, but there is something (e.g. common= conduit, note that the conduit has room for more than for one link) that w= ill bring both these links down, if this something fails (e.g. conduit is cut ). Now consider that this som= ething must be taken in its entirety by one of the links to become operatio= nal . In this case SRLG becomes MELG. Note that MELG is only meaningful for= virtual links (unlike SRLG that makes sense for either real or virtual link). Why would you advertise two = links that mutually exclude each other rather than advertising only one of = them at a time, unless the two are virtual links and hence both available f= or the client layer connections?

 

Igor

 

 

From: Khuzema Pithewan [mailto:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 1:01 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

Do you mean,= if virtual link do not have any specific constraint, for example a link in the path (not talking about egress links/interfaces) mus= t be traversed to realize the virtual link, there wont be any MELG for the = virtual link?<= /span>

 

Regds=

Khuzema

 

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 9:52 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

MELGs have n= othing to do with bandwidth. MELG is a concrete network resource in a server layer that two or more Virtual Links in a client layer depend = on in a mutually exclusive way. An example of MELG is a WDM layer transpond= er that can terminate either of respective WDM layer tunnels (but not both = at the same time) for two OTN layer Virtual Links. If you advertise a Virtual Link, say, for Ethernet layer th= at depends on the connection in OTN layer going through one of the mentione= d OTN links, the Ethernet VL must inherit the MELG similarly like it does S= RLGs advertised for the OTN links.

 

Igor<= span style=3D"mso-fareast-language:ZH-CN">

 

 

From: Khuzema Pithewan [mailto:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 12:06 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

For multi-la= yer (more than 2) network, consider all the layers are meshy (that’s when virtual links are useful anyway), MELGs of virtual link= will change as and when BW/wavelength availability changes, because potent= ial paths, a virtual link can take will change. Mapping lower layer MELGs t= o higher layer MELGs won’t be practical if done in distributed manner, so it has to be centralized. So you do have= central element in each layer that knows all the risk and paths (a PCE?), = which can be utilized for layer specific path computation (as it is doing i= t anyway).

 

This kind of= architecture has all the pieces that are required for Inter-PCE communication (across layers), except the protocol that would actually mak= e the 2 PCEs talk.

 

You seem to = be doing something that you don’t like J

 

Regards

Khuzema

 

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 8:39 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

I am not a f= an of inter-layer path computations (nor I am a fan of inter-PCE computations). In my mind path computation for a service or services in la= yer X is performed only in layer X, i.e. considers only X layer links (real= or virtual). As Pavan mentioned SRLGs and MELGs that need to be inherited = from lower layers should be translated into X layer link SRLGs/MELGs and specified with X layer specific SRLG/MEL= G IDs.<= /p>

 

Cheers,

Igor<= span style=3D"mso-fareast-language:ZH-CN">

 

 

From: Khuzema Pithewan [mailto:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 10:55 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

Ok. This wou= ld be useful if network architecture is based on external PCE or mgmt entity as PCE in client layer, but there is no counterpart in = server layer, otherwise one could have inter-PCE communication to achieve d= iverse path in server layer without getting into virtual link and MELG stuf= f.

 

Is that corr= ect?

 

Khuzema

 

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 6:36 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

2.       For cases of c= oncurrent computation (case#2-5), you are mainly talking about global optim= ization and diversity among multiple services. You can do the path computation, but to actually enact the computed path the signa= ling needs to be done from the source end of those LSPs.  So there is = no point in doing concurrent computation at one network element for the ser= vices starting from multiple network elements. At best it looks to me a problem to be solved by network managem= ent/planning software.&nb= sp;

Well, when a= n ingress node is initiating a service, it is doing so on request from some management entity. This management entity can compute pa= ths for many services with some global criteria in mind, and then specify t= he resulting paths as explicit EROs in provisioning requests sent to each o= f the service ingresses. How else, for example,  you can set up several services originated from differe= nt nodes that are disjoint from each other? Also, what is the point in your= opinion of the statefull PCE work?

 

Cheers,

Igor<= span style=3D"mso-fareast-language:ZH-CN">

 

From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com]
Sent: Friday, April 12, 2013 8:08 AM
To: Khuzema Pithewan
Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Khuzema, Hi!=


Please see inline..

 

 

 1.       When Network h= as more than 2 layer i.e. Packet-OTN-DWDM, the Packet (client) layer will b= e talking to its immediate server layer i.e. OTN, which in turn is talking to DWDM layer. Using MELG, client layer path computatio= n can take care of resource exclusivity of virtual link for immediate serve= r layer i.e. OTN layer.  However if there is resource exclusivity at D= WDM layer, this mechanism doesn’t work. You need to do loose routing or use distributed PCE model

 

[VPB] The behavior is t= he same as what you would do with SRLGs in a multi-layer architecture. Ther= e are architectures that allow the SRLGs in the lowest layer to be exported all the way up to the highest layer. Th= e expectation is that MELGs would be treated in the same vein. 

2.       For cases of c= oncurrent computation (case#2-5), you are mainly talking about global optim= ization and diversity among multiple services. You can do the path computation, but to actually enact the computed path the signa= ling needs to be done from the source end of those LSPs.  So there is = no point in doing concurrent computation at one network element for the ser= vices starting from multiple network elements. At best it looks to me a problem to be solved by network managem= ent/planning software.&nb= sp;

[VPB]  I'm not sur= e why you think there is no point in having a centralized computation funct= ion compute paths concurrently for LSPs with different set of end-points. Even your NMS/planning-software can interact = with such computation engine, retrieve all the paths and then go about init= iating the path-setup from the ingress of each LSP. =

 

Regards,

-Pavan

 

 

 

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Tuesday, March 26, 2013 7:19 PM
To: Dieter Beller; Vishnu Pavan Beeram


Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Dieter,

 

You said:

>> I guess we are= coming back to the essential point: "and how often concurrent path computation will be >> used."

 

To be honest, this surp= rises me quite a bit, Let me give you some of many reasons as to why concur= rent path computations are needed and why this is better than computing one path at a time:

 

1.      Computing several diverse= paths for the same service in the context of service recovery. I hope you = realize that computing one path at a time on many configurations produces n= o or sub-optimal results. I also hope you realize the problem of selecting two paths with one of them  havi= ng a link with common MELG with a link from another path;=

2.      Computing paths for multi= ple services to be sufficiently disjoint from each other;=

3.      Computing paths for multi= ple services to achieve a global optimization criteria (e.g. minimal summar= y total cost);

4.      Computing paths for multi= ple services for the purpose of removing the bandwidth fragmentations;=

5.      Computing paths for multi= ple services to plan shared mesh protection/restoration schemes<= /span>

6.      Etc.

 

Also think about this:<= o:p>

1.      If concurrent path comput= ation was not important, why PCEP includes the machinery to do that?

2.      My understanding of the s= tatefull PCE is that it does pretty much nothing but concurrent path comput= ations

 

You also said:

>> I suppose that if a = pce approach is used, i.e., path computation is centralized including the >> TE-DB, MELG routing extensions are not needed because the informat= ion about mutual
>>exclusive VLs can be kept in the central TE-DB when VLs are configu= red.

How this logic does not= apply to other link attributes such as SRLGs?

What if path computatio= n is not centralized?

 

Cheers,

Igor

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Hi Pavan,<= /p>

On 25.03.2013 07:29, Fat= ai Zhang wrote:

Hi Pavan,

 

I am not sur= e how much VL (Virtual Link) will be used in the practical deployment and how often concurrent path computation will be used.<= span style=3D"mso-fareast-language:ZH-CN">

I guess we are coming b= ack to the essential point: "and how often concurrent path computation will be used."

This means we are trying to figure out under which conditions MELG routing = extensions
could be beneficial.

IMHO, they would only make sense, if:

  • a path computation function supp= orts the calculation of k shortest paths concurrently
  • if there is only a single path c= omputation function instance per domain (pce approach)
    If path computation is done in a distributed fashion the benefit goes away = because
    the instances calculate paths independently!

I suppose that if a pce appro= ach is used, i.e., path computation is centralized including the
TE-DB, MELG routing extensions are not needed because the information about= mutual
exclusive VLs can be kept in the central TE-DB when VLs are configured.

Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their
applicability is broader.


Thanks,
Dieter

 

Do you think if it ma= kes sense to add a flag (in routing advertisement) to indicate a link is a = VL or not?

 

 

 

Best Regards

 

Fatai

 

From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Fatai, Hi!

 

Good to see that you un= derstand the construct now.

 

This is not a corner ca= se. The utility of the construct becomes quite significant if you have an a= pplication that does concurrent path computations on an abstract topology.

 

Regards,

-Pavan

 

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

 

--

= DIETER BELLER

ALCATEL-LUCEN= T DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 711 821 43125 begin_of_the_skype_highlighting 3D"Image&#= 43;49 711 821 43125 FREE  end_of_the_skype_highlighting
Mobil: +49 175 7266874 begin_of_the_skype_highlighting 3D"=+49 175 7266874 FREE  = end_of_the_skype_highlighting

 

Alcatel-Lucent Deutschland A= G
Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe

 

 

--_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923AA93atlsrvmail10atl_-- --_004_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923AA93atlsrvmail10atl_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=823; creation-date="Mon, 22 Apr 2013 19:28:36 GMT"; modification-date="Mon, 22 Apr 2013 19:28:36 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABkAGQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigD//2Q== --_004_CDAC6F6F5401B245A2C68D0CF8AFDF0A1923AA93atlsrvmail10atl_-- From zhangfatai@huawei.com Mon Apr 22 18:03:59 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98AC421F9323 for ; Mon, 22 Apr 2013 18:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_66=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 x62ffyExTQOJ for ; Mon, 22 Apr 2013 18:03:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4B89021F91B7 for ; Mon, 22 Apr 2013 18:03:43 -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 ASC02940; Tue, 23 Apr 2013 01:03:41 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Apr 2013 02:03:16 +0100 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Apr 2013 02:03:39 +0100 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.222]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Tue, 23 Apr 2013 09:03:35 +0800 From: Fatai Zhang To: Igor Bryskin , Khuzema Pithewan , Vishnu Pavan Beeram , Dieter Beller Thread-Topic: [CCAMP] MELGs - Q&A Thread-Index: AQHOIGPek8R0zdnmbUizkEjN3z7415ivh4owgAA2TQCAATLDIIAAeV3g///IfQCABM8nkIAAfXoAgAELY4CAGovgAIAAD52AgAAQMoCAAB55gIAAA70AgAAP9wCAAASVAIAACsYAgAAXnYCAA8Z+gIAAy+KAgAE80oCAADLWAIAEhDjAgAAUrACAAVyggIADdTOAgABH/YCAABRAgIAA4yEw Date: Tue, 23 Apr 2013 01:03:35 +0000 Message-ID: References: <5150C704.2040007@alcatel-lucent.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: multipart/related; boundary="_004_F82A4B6D50F9464B8EBA55651F541CF84317682ESZXEML552MBXchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] MELGs - Q&A X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 01:03:59 -0000 --_004_F82A4B6D50F9464B8EBA55651F541CF84317682ESZXEML552MBXchi_ Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF84317682ESZXEML552MBXchi_" --_000_F82A4B6D50F9464B8EBA55651F541CF84317682ESZXEML552MBXchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Igor, It is OK to have different drafts(solutions) for different cases of VT, but= it is better to find a generic solution for all the cases of VT. Best Regards Fatai From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Tuesday, April 23, 2013 3:29 AM To: Khuzema Pithewan; Fatai Zhang; Vishnu Pavan Beeram; Dieter Beller Cc: ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, I agree that we need to define the problem more clearly, in particular, to = separate from the case #2. I promise we will provide a solution for case # 2 as well. Thanks, Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Monday, April 22, 2013 2:16 PM To: Igor Bryskin; Fatai Zhang; Vishnu Pavan Beeram; Dieter Beller Cc: ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Indeed you are solving the problem described in the case 1 and probably the= only case MELG is trying to solve, However MELG draft read gives an impres= sion that you are trying to solve far more generic issue of mutual exclusiv= ity of virtual links w.r.t. resources in server layer and this seems farfe= tched and hence confusion and discussion. It might be apt to capture this usecase in draft in such a way that, it act= ually solves only this case. Thanks Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Monday, April 22, 2013 7:28 PM To: Fatai Zhang; Vishnu Pavan Beeram; Khuzema Pithewan; Dieter Beller Cc: ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Fatai and Khuzema, In my opinion you confuse two cases: Case 1. Two virtual links are served by WDM layer. The potential paths supp= orting each VL are terminated on the same transponder, hence the two VLs ar= e mutually exclusive. Note that this mutual exclusivity relationship is sta= tic: it is true at all times and does not depend on anything else (e.g. it = does not depend on # of available wavelengths on WDM links the transponder = could be connected to). This is the case of MELGs and is focus of our MELG = draft; Case 2. Two virtual links are served by WDM layer. The potential paths supp= orting each VL use a common WDM link that has only one wavelength available= at the moment, hence the two VLs are mutually exclusive. Note that this mu= tual exclusivity is dynamic: as soon as an additional wavelength becomes av= ailable on the common WDM link, the two VLs will be able to be committed at= the same time. This is not the MELG case. We discussed this dynamic mutual= exclusivity (Cyril was the first, I believe, to bring this up) and have de= cided to keep this case out of scope of the MELG draft. Note, that there is= a simple solution for this case based on the VL model, which we will solve= in a separate draft. This solution does not include the inter-layer path c= omputation: the whole point of the VLs is to alleviate the clients from dea= ling with the server layer traffic engineering and path computations. Cheers, Igor From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Friday, April 19, 2013 9:14 PM To: Igor Bryskin; Vishnu Pavan Beeram; Khuzema Pithewan; Dieter Beller Cc: ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, I have explained to Pavan. The path computation element (centralized PCE for inter-layer or multiple P= CEs through communication) can take care of this issue. In addition, in this case, how you advertise MELGS for this two VT links? = Will you advertise that VL 1 must be exclusive with VL2? That is wrong, bec= ause VL1 and VL2 can be used for the disjoint paths in the client layer. Best Regards Fatai From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 19, 2013 8:22 PM To: Fatai Zhang; Vishnu Pavan Beeram; Khuzema Pithewan; Dieter Beller Cc: ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Fatai, What is Virtual Link? As described in RFC6001, it says as below. So my ques= tion is: when there are two VLs created through Call approach as defined in= RFC6001, one has 3 potential paths in the server layer to setup FA-LSP, an= d another has 2 potential paths in the server layer, and only one of the 3 = &2 has the same resource shared in the server layer. How MELGs can help in this case? IB>> Simple: with MELGs the path computer will know in advance that selecti= ng two paths with a virtual link belonging to path #1 and a virtual link be= longing to path #2 having an MELG in common will be a bad idea, because an = attempt to provision such path combination is guaranteed to fail. Without M= ELGs the path computer won't have such knowledge. Cheers, Igor From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Thursday, April 18, 2013 11:26 PM To: Vishnu Pavan Beeram; Khuzema Pithewan; Igor Bryskin; Dieter Beller Cc: ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Pavan, Igor I think there are some concerns about the applicability of MELGs and I have= the same feeling as Khuzema and Dieter. I still think that MELGS can only handle a very small corner case as you pu= t many cases below where MELGs are not needed. What is Virtual Link? As described in RFC6001, it says as below. So my ques= tion is: when there are two VLs created through Call approach as defined in= RFC6001, one has 3 potential paths in the server layer to setup FA-LSP, an= d another has 2 potential paths in the server layer, and only one of the 3 = &2 has the same resource shared in the server layer. How MELGs can help in this case? =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=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 A virtual TE link is defined as a TE link between two upper-layer nodes tha= t is not associated with a fully provisioned FA-LSP in a lower layer [RFC52= 12]. A virtual TE link is advertised a= s any TE link, following the rules in [RFC4206] defined for fully provisioned TE links. A virtual TE link represe= nts thus the potentiality to set up an FA-LSP in the lower layer to support= the TE link that has been advertised. =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=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 Best Regards Fatai From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Vishnu Pavan Beeram Sent: Tuesday, April 16, 2013 10:10 PM To: Khuzema Pithewan Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Khuzema, Hi! MELGs are useful and come into play only when: (1) The server network domain is abstracted and the advertised Virtual TE-l= inks possess some mutual exclusivity relationship. (2) There is a Centralized path computation entity in the client domain (co= mputes paths in terms of Client TE-links/TE-nodes) that is capable of doing= concurrent path computations. If either of the above 2 statements is NOT true, there is no utility for ME= LGs. At the risk of being pedantic: - Are MELGs needed when the server-network domain in not abstracted (no Vir= tual TE links)? The answer is NO. - Are MELGs needed when you have a distributed path-computation architectur= e (Client PCE interacting with Server PCE)? The answer is NO. - Are MELGs needed when the centralized path-computation engine doesn't (ca= n't) do concurrent computations? The answer is NO. The actual procedures involved in abstracting the server network domain is = beyond the scope of . The abstraction procedure itself is impl= ementation-specific (maybe someday someone would put together a draft for d= iscussing this). Though it is true that the primary use-case we had in mind= when coming up with this new construct involves a lambda-layer server netw= ork domain, there is really no restriction (at a conceptual level) on using= this construct when abstracting a packet-layer server network domain or a = TDM-layer server network domain. It is up to the implementation on how to m= ake best use of this construct. When you advertise a Virtual TE-link into a client network domain, you are = doing this based on the existence of some potential underlying server-path.= TE attributes like SRLGs, MELGs, delay etc that get advertised for the Vir= tual TE-link depend on the underlying server-path that is chosen for cateri= ng to this Client TE-link. If the underlying server-path keeps changing (ba= sed on network events), these TE attributes would also keep changing. The p= rocedure for keeping the advertised information "current" is an implementat= ion choice. If there exists such a thing as an abstraction manager (again, this is tota= lly implementation specific), then the assumption is that it does one of th= e following - (a) computes new server-paths for the Virtual TE links whenever there is a = change in the network (may not be very scalable in some architectures), (b) or does periodic path-computation for each Virtual TE link, (c) or uses a policy to pin down the Virtual TE-link to a specific underlyi= ng server-path, (d) or uses a combination of (a), (b), (c). doesn't make any recommendation as to what choice the abstrac= tion manager would need to take. Hope this helps. -Pavan On Tue, Apr 16, 2013 at 7:08 AM, Khuzema Pithewan > wrote: Hi Igor, I am trying to summarize the discussion we had so far. Pls see if my conclu= sion is in sync with the idea of MELG you have MELG is useful when 1. server layer VLs are nailed down for the resources on the server l= ayer links that are shared among multiple VLs. These resources are typicall= y wavelength on a fiber (can it be anything else??). In other words, if 2 V= Ls are pinned to use a particular wavelength on a particular fiber, then th= ese 2 VLs will have MELG for the wavelength. 2. server layer do not have centralized path computation entity which= can be used by client layer to ask for concurrent diverse path computation= within server layer. 3. Client layer has a centralized path computation entity, which woul= d compute paths for client+server layer. 4. The need is to centralized concurrent computation of more than one= client+server layer path that meets some diversity and resource exclusivit= y requirements. Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Monday, April 15, 2013 9:44 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Please, see in-line. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Monday, April 15, 2013 12:05 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, I understand the SRLG and MELG behavior you have penned . My concern was little different. With changing resource consumption (becau= se of dynamicity the network has) in the network links, potential paths a s= et of virtual link can take will change and hence its MELG, as it is tied t= o a resource it can take. So unless virtual links paths are nailed down, it= would be hard to compute MELGs in distributed way. IB>> I think you are missing the point here. Virtual Link server layer path= s are pinned as far as fate sharing is concerned (that is, they are pinned = on server layer link level). It would make little sense to advertise VL SR= LGs if the SRLGs constantly change. The same is true for MELGs. SRLGs/MELG= s advertised for VLs normally do not change: neither over time nor when VLs= become committed/uncommitted. Another point is, virtual links can be viewed as oversubscription of resour= ces (in MELG context). Taking an example (for OTN, I know it would work dif= ferently for a Wavelength in WDM), a link resources are worth 1 TB of BW, u= ser has provisioned 20 virtual links of 100G each going via that OTN link. = Physically, only 10 will get committed. But which 10? It will really depen= d on network dynamics at the time of demand to commit. MELGs are not that e= ffective here. You need some different mechanism. IB>> As I mentioned before MELGs have nothing to do with bandwidth and were= never intended to solve the problems such as you describe (just like it wo= uld not make much sense to solve such problem with SRLGs :=3D) Again, MELG is an extreme case SRLG designed exclusively for VLs (no more = and no less). Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 11:55 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, Think about MELG as an SRLG that is shared between two or more links in its= entirety. When two real links have an SRLG in common, it means that two re= al links can co-exist concurrently, but there is something (e.g. common con= duit, note that the conduit has room for more than for one link) that will = bring both these links down, if this something fails (e.g. conduit is cut )= . Now consider that this something must be taken in its entirety by one of = the links to become operational . In this case SRLG becomes MELG. Note that= MELG is only meaningful for virtual links (unlike SRLG that makes sense fo= r either real or virtual link). Why would you advertise two links that mutu= ally exclude each other rather than advertising only one of them at a time,= unless the two are virtual links and hence both available for the client l= ayer connections? Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 1:01 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Do you mean, if virtual link do not have any specific constraint, for examp= le a link in the path (not talking about egress links/interfaces) must be t= raversed to realize the virtual link, there wont be any MELG for the virtua= l link? Regds Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 9:52 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, MELGs have nothing to do with bandwidth. MELG is a concrete network resourc= e in a server layer that two or more Virtual Links in a client layer depend= on in a mutually exclusive way. An example of MELG is a WDM layer transpon= der that can terminate either of respective WDM layer tunnels (but not both= at the same time) for two OTN layer Virtual Links. If you advertise a Virt= ual Link, say, for Ethernet layer that depends on the connection in OTN lay= er going through one of the mentioned OTN links, the Ethernet VL must inher= it the MELG similarly like it does SRLGs advertised for the OTN links. Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 12:06 PM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, For multi-layer (more than 2) network, consider all the layers are meshy (t= hat's when virtual links are useful anyway), MELGs of virtual link will cha= nge as and when BW/wavelength availability changes, because potential paths= , a virtual link can take will change. Mapping lower layer MELGs to higher = layer MELGs won't be practical if done in distributed manner, so it has to = be centralized. So you do have central element in each layer that knows all= the risk and paths (a PCE?), which can be utilized for layer specific path= computation (as it is doing it anyway). This kind of architecture has all the pieces that are required for Inter-PC= E communication (across layers), except the protocol that would actually ma= ke the 2 PCEs talk. You seem to be doing something that you don't like :) Regards Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 8:39 PM To: Khuzema Pithewan; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, I am not a fan of inter-layer path computations (nor I am a fan of inter-PC= E computations). In my mind path computation for a service or services in l= ayer X is performed only in layer X, i.e. considers only X layer links (rea= l or virtual). As Pavan mentioned SRLGs and MELGs that need to be inherited= from lower layers should be translated into X layer link SRLGs/MELGs and s= pecified with X layer specific SRLG/MELG IDs. Cheers, Igor From: Khuzema Pithewan [mailto:kpithewan@infinera.com] Sent: Friday, April 12, 2013 10:55 AM To: Igor Bryskin; Vishnu Pavan Beeram Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Hi Igor, Ok. This would be useful if network architecture is based on external PCE o= r mgmt entity as PCE in client layer, but there is no counterpart in server= layer, otherwise one could have inter-PCE communication to achieve diverse= path in server layer without getting into virtual link and MELG stuff. Is that correct? Khuzema From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, April 12, 2013 6:36 PM To: Vishnu Pavan Beeram; Khuzema Pithewan Cc: Dieter Beller; ccamp@ietf.org Subject: RE: [CCAMP] MELGs - Q&A Khuzema, 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. Well, when an ingress node is initiating a service, it is doing so on reque= st from some management entity. This management entity can compute paths fo= r many services with some global criteria in mind, and then specify the res= ulting paths as explicit EROs in provisioning requests sent to each of the = service ingresses. How else, for example, you can set up several services = originated from different nodes that are disjoint from each other? Also, wh= at is the point in your opinion of the statefull PCE work? Cheers, Igor From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, April 12, 2013 8:08 AM To: Khuzema Pithewan Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Khuzema, Hi! Please see inline.. 1. When Network has more than 2 layer i.e. Packet-OTN-DWDM, the Pack= et (client) layer will be talking to its immediate server layer i.e. OTN, w= hich in turn is talking to DWDM layer. Using MELG, client layer path comput= ation can take care of resource exclusivity of virtual link for immediate s= erver layer i.e. OTN layer. However if there is resource exclusivity at DW= DM layer, this mechanism doesn't work. You need to do loose routing or use = distributed PCE model [VPB] The behavior is the same as what you would do with SRLGs in a multi-l= ayer architecture. There are architectures that allow the SRLGs in the lowe= st layer to be exported all the way up to the highest layer. The expectatio= n is that MELGs would be treated in the same vein. 2. For cases of concurrent computation (case#2-5), you are mainly tal= king about global optimization and diversity among multiple services. You c= an do the path computation, but to actually enact the computed path the sig= naling needs to be done from the source end of those LSPs. So there is no = point in doing concurrent computation at one network element for the servic= es starting from multiple network elements. At best it looks to me a proble= m to be solved by network management/planning software. [VPB] I'm not sure why you think there is no point in having a centralized= computation function compute paths concurrently for LSPs with different se= t of end-points. Even your NMS/planning-software can interact with such com= putation engine, retrieve all the paths and then go about initiating the pa= th-setup from the ingress of each LSP. Regards, -Pavan From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Igor Bryskin Sent: Tuesday, March 26, 2013 7:19 PM To: Dieter Beller; Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Dieter, You said: >> I guess we are coming back to the essential point: "and how often concur= rent path computation will be >> used." To be honest, this surprises me quite a bit, Let me give you some of many r= easons as to why concurrent path computations are needed and why this is be= tter than computing one path at a time: 1. Computing several diverse paths for the same service in the context= of service recovery. I hope you realize that computing one path at a time = on many configurations produces no or sub-optimal results. I also hope you = realize the problem of selecting two paths with one of them having a link = with common MELG with a link from another path; 2. Computing paths for multiple services to be sufficiently disjoint f= rom each other; 3. Computing paths for multiple services to achieve a global optimizat= ion criteria (e.g. minimal summary total cost); 4. Computing paths for multiple services for the purpose of removing t= he bandwidth fragmentations; 5. Computing paths for multiple services to plan shared mesh protectio= n/restoration schemes 6. Etc. Also think about this: 1. If concurrent path computation was not important, why PCEP includes= the machinery to do that? 2. My understanding of the statefull PCE is that it does pretty much n= othing but concurrent path computations You also said: >> I suppose that if a pce approach is used, i.e., path computation is cent= ralized including the >> TE-DB, MELG routing extensions are not needed because the information ab= out mutual >>exclusive VLs can be kept in the central TE-DB when VLs are configured. How this logic does not apply to other link attributes such as SRLGs? What if path computation is not centralized? Cheers, Igor From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Dieter Beller Sent: Monday, March 25, 2013 5:52 PM To: Vishnu Pavan Beeram Cc: ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Hi Pavan, On 25.03.2013 07:29, Fatai Zhang wrote: Hi Pavan, I am not sure how much VL (Virtual Link) will be used in the practical depl= oyment and how often concurrent path computation will be used. I guess we are coming back to the essential point: "and how often concurren= t path computation will be used." This means we are trying to figure out under which conditions MELG routing = extensions could be beneficial. IMHO, they would only make sense, if: * a path computation function supports the calculation of k shortest pa= ths concurrently * if there is only a single path computation function instance per doma= in (pce approach) If path computation is done in a distributed fashion the benefit goes away = because the instances calculate paths independently! I suppose that if a pce approach is used, i.e., path computation is central= ized including the TE-DB, MELG routing extensions are not needed because the information about= mutual exclusive VLs can be kept in the central TE-DB when VLs are configured. Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their applicability is broader. Thanks, Dieter Do you think if it makes sense to add a flag (in routing advertisement) to = indicate a link is a VL or not? Best Regards Fatai From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: Friday, March 22, 2013 8:57 PM To: Fatai Zhang Cc: Igor Bryskin; ccamp@ietf.org Subject: Re: [CCAMP] MELGs - Q&A Fatai, Hi! Good to see that you understand the construct now. This is not a corner case. The utility of the construct becomes quite signi= ficant if you have an application that does concurrent path computations on= an abstract topology. Regards, -Pavan _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp -- DIETER BELLER ALCATEL-LUCENT DEUTSCHLAND AG PROJECT MANAGER ASON/GMPLS CONTROL PLANE CORE NETWORKS BUSINESS DIVISION OPTICS BU, SWITCHING R&D Lorenzstrasse 10 70435 Stuttgart, Germany Phone: +49 711 821 43125 begin_of_the_skype_highlighting [Image removed by = sender.] +49 711 821 43125 FREE end_of_the_skype_highlighting Mobil: +49 175 7266874 begin_of_the_skype_highlighting [Image removed by se= nder.] +49 175 7266874 FREE end_of_the_skype_highlighting Dieter.Beller@alcatel-lucent.com Alcatel-Lucent Deutschland AG Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026 Chairman of the Supervisory Board: Michael Oppenhoff Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe --_000_F82A4B6D50F9464B8EBA55651F541CF84317682ESZXEML552MBXchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Igor,

 = ;

It is OK t= o have different drafts(solutions) for different cases of VT, but it is bet= ter to find a generic solution for all the cases of VT.

 = ;

 

 

 

Best Regards

 

Fatai

 = ;

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Tuesday, April 23, 2013 3:29 AM
To: Khuzema Pithewan; Fatai Zhang; Vishnu Pavan Beeram; Dieter Belle= r
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 = ;

I agree th= at we need to define the problem more clearly, in particular, to separate f= rom the case #2.

I promise = we will provide a solution for case # 2 as well.

 = ;

Thanks,

Igor<= /o:p>

 = ;

 = ;

From: Khuzema Pithewan [mailto:kpithewan@infinera.com]
Sent: Monday, April 22, 2013 2:16 PM
To: Igor Bryskin; Fatai Zhang; Vishnu Pavan Beeram; Dieter Beller Cc: ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 = ;

Indeed you= are solving the problem described in the case 1 and probably the only case= MELG is trying to solve, However MELG draft read gives an impression that you are trying to solve far more generic issue of mutual e= xclusivity of virtual links w.r.t. resources in server layer  and this= seems farfetched and hence confusion and discussion.

 = ;

It might b= e apt to capture this usecase in draft in such a way that, it actually solv= es only this case.

 = ;

Thanks

Khuzema

 = ;

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Monday, April 22, 2013 7:28 PM
To: Fatai Zhang; Vishnu Pavan Beeram; Khuzema Pithewan; Dieter Belle= r
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Fatai and = Khuzema,

 = ;

In my opin= ion you confuse two cases:

 = ;

Case 1. Tw= o virtual links are served by WDM layer. The potential paths supporting eac= h VL are terminated on the same transponder, hence the two VLs are mutually exclusive. Note that this mutual exclusivity relationship= is static: it is true at all times and does not depend on anything else (e= .g. it does not depend on # of available wavelengths on WDM links the trans= ponder could be connected to). This is the case of MELGs and is focus of our MELG draft;

 = ;

Case 2. Tw= o virtual links are served by WDM layer. The potential paths supporting eac= h VL use a common WDM link that has only one wavelength available at the moment, hence the two VLs are mutually exclusive. Note that this mu= tual exclusivity is dynamic: as soon as an additional wavelength becomes av= ailable on the common WDM link, the two VLs will be able to be committed at= the same time. This is not the MELG case. We discussed this dynamic mutual exclusivity (Cyril was the fir= st, I believe, to bring this up) and have decided to keep this case out of = scope of the MELG draft. Note, that there is a simple solution for this cas= e based on the VL model, which we will solve in a separate draft. This solution does not include the inter-l= ayer path computation: the whole point of the VLs is to alleviate the clien= ts from dealing with the server layer traffic engineering and path computat= ions.

 = ;

Cheers,

Igor<= /o:p>

 = ;

 = ;

From: Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Friday, April 19, 2013 9:14 PM
To: Igor Bryskin; Vishnu Pavan Beeram; Khuzema Pithewan; Dieter Bell= er
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

I have exp= lained to Pavan.

 

The path c= omputation element (centralized PCE for inter-layer or multiple PCEs throug= h communication) can take care of this issue.

 

In additio= n, in this case, how you advertise MELGS for this two VT links?  Will = you advertise that VL 1 must be exclusive with VL2? That is wrong, because VL1 and VL2 can be used for the disjoint paths in the client layer= .

 

 

 

 

 

Best Regards

 

Fatai

 

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Friday, April 19, 2013 8:22 PM
To: Fatai Zhang; Vishnu Pavan Beeram; Khuzema Pithewan; Dieter Belle= r
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Fatai,

 

What is Virtual Link? As described in RFC6001, it says a= s below. So my question is: when there are two VLs created through Call approach as defined in RFC6001, one has 3 potential paths in the serv= er layer to setup FA-LSP, and another has 2 potential paths in the server l= ayer, and only one of the 3 &2 has the same resource shared in the serv= er layer.

 

How MELGs can help in this case?

 

IB>> Simple: with MELGs the path computer will kno= w in advance that selecting two paths with a virtual link belonging to path #1 and a virtual link belonging to path #2 having an MELG in commo= n will be a bad idea, because an attempt to provision such path combination= is guaranteed to fail. Without MELGs the path computer won’t have su= ch knowledge.

 

Cheers,

Igor

 

 

From: Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Thursday, April 18, 2013 11:26 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan; Igor Bryskin; Dieter Bell= er
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Pavan, = Igor

 

I think th= ere are some concerns about the applicability of MELGs and I have the same = feeling as Khuzema and Dieter.

 

I still th= ink that MELGS can only handle a very small corner case as you put many cas= es below where MELGs are not needed.=

 

What is Vi= rtual Link? As described in RFC6001, it says as below. So my question is: w= hen there are two VLs created through Call approach as defined in RFC6001, one has 3 potential paths in the server layer to setup FA-LSP,= and another has 2 potential paths in the server layer, and only one of the= 3 &2 has the same resource shared in the server layer.

 

How MELGs = can help in this case?

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

A virtual TE link is defined as a TE link between = two upper-layer nodes that is not associated with a fully provisioned FA-LSP in a lower layer [R= FC5212].  A virtual TE link is advertised as any TE link, following the rules in [RFC4206] defined for fully provisioned TE links.  A virtual TE link represents thus the potentiality to set up an FA-LSP in the lower layer to support the TE link that has been advertised.=

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

 

 

 

 

 

Best Regards

 

Fatai

 

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Vishnu Pavan Beeram
Sent: Tuesday, April 16, 2013 10:10 PM
To: Khuzema Pithewan
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Khuzema, Hi!<= /p>

 

MELGs are useful and come into = play only when:

(1) The server network domain i= s abstracted and the advertised Virtual TE-links possess some mutual exclus= ivity relationship.

(2) There is a Centralized path= computation entity in the client domain (computes paths in terms of Client= TE-links/TE-nodes) that is capable of doing concurrent path computations.<= o:p>

 

If either of the above 2 statem= ents is NOT true, there is no utility for MELGs. 

At the risk of being pedantic:&= nbsp;

- Are MELGs needed when the ser= ver-network domain in not abstracted (no Virtual TE links)? The answer is N= O.

- Are MELGs needed when you hav= e a distributed path-computation architecture (Client PCE interacting with = Server PCE)? The answer is NO.

- Are MELGs needed when the cen= tralized path-computation engine doesn't (can't) do concurrent computations= ? The answer is NO.

 

The actual procedures involved = in abstracting the server network domain is beyond the scope of <draft-m= elgs>. The abstraction procedure itself is implementation-specific (mayb= e someday someone would put together a draft for discussing this). Though it is true that the primary use-case we had i= n mind when coming up with this new construct involves a lambda-layer serve= r network domain, there is really no restriction (at a conceptual level) on= using this construct when abstracting a packet-layer server network domain or a TDM-layer server network domain.= It is up to the implementation on how to make best use of this construct.&= nbsp;

 

When you advertise a Virtual TE= -link into a client network domain, you are doing this based on the existen= ce of some potential underlying server-path. TE attributes like SRLGs, MELG= s, delay etc that get advertised for the Virtual TE-link depend on the underlying server-path that is chosen fo= r catering to this Client TE-link. If the underlying server-path keeps chan= ging (based on network events), these TE attributes would also keep changin= g. The procedure for keeping the advertised information "current" is an implementation choice.&nb= sp;

 

If there exists such a thing as= an abstraction manager (again, this is totally implementation specific), t= hen the assumption is that it does one of the following - <= /span>

(a) computes new server-paths f= or the Virtual TE links whenever there is a change in the network (may not = be very scalable in some architectures), 

(b) or does periodic path-compu= tation for each Virtual TE link, 

(c) or uses a policy to pin dow= n the Virtual TE-link to a specific underlying server-path, 

(d) or uses a combination of (a= ), (b), (c).

 

<draft-melgs> doesn't mak= e any recommendation as to what choice the abstraction manager would need t= o take.

 

Hope this helps.

-Pavan

=  

On Tue, Apr 16, 2013 at 7:08 AM= , Khuzema Pithewan <kpithewan@infinera.com> wrote:

Hi Igor,

 

I am trying to summarize= the discussion we had so far. Pls see if my conclusion is in sync with the idea of MELG you have

 

MELG is useful when

1.      = ; server layer VLs are naile= d down for the resources on the server layer links that are shared among mu= ltiple VLs. These resources are typically wavelength on a fiber (can it be anything else??). In other words, if 2 VLs are pinned t= o use a particular wavelength on a particular fiber, then these 2 VLs will = have MELG for the wavelength.=

2.      = ; server layer do not have c= entralized path computation entity which can be used by client layer to ask= for concurrent diverse path computation within server layer.

3.      = ; Client layer has a central= ized path computation entity, which would compute paths for client+serv= er layer.

4.      = ; The need is to centralized= concurrent computation of more than one client+server layer path that = meets some diversity and resource exclusivity requirements.

 

Regds

Khuzema

 

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Monday, April 15, 2013 9:44 PM


To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

Please, see in-line.

 

Igor

 

From: Khuzema Pithewan [mailto:kpithewan@infinera.com]
Sent: Monday, April 15, 2013 12:05 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

I understand the SRLG an= d MELG behavior you have penned .

 

My concern was little di= fferent.  With changing resource consumption (because of dynamicity the network has) in the network links, potential paths a set of virtual li= nk can take will change and hence its MELG, as it is tied to a resource it = can take. So unless virtual links paths are nailed down, it would be hard t= o compute MELGs in distributed way.<= /span>

 

IB>> I think you a= re missing the point here. Virtual Link server layer paths are pinned as far as fate sharing is concerned (that is, they are pinned on  ser= ver layer link level). It would make little sense to advertise VL SRLGs if = the SRLGs constantly change. The same is true for MELGs.  SRLGs/MELGs = advertised for VLs normally do not change: neither over time nor when VLs become committed/uncommitted.

 

Another point is, virtua= l links can be viewed as oversubscription of resources (in MELG context). Taking an example (for OTN, I know it would work differently for= a Wavelength in WDM), a link resources are worth 1 TB of BW, user has prov= isioned 20 virtual links of 100G each going via that OTN link.  Physic= ally, only 10 will get committed. But which 10? It will really depend on network dynamics at the time of demand = to commit. MELGs are not that effective here. You need some different mecha= nism.

 

IB>> As I mentione= d before MELGs have nothing to do with bandwidth and were never intended to solve the problems such as you describe (just like it would not make mu= ch sense to solve such problem with SRLGs :=3D)=

Again,  MELG is an = extreme case SRLG designed exclusively for VLs (no more and no less).

 

Regds

Khuzema

 

 

From: Igor Bryskin [mai= lto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 11:55 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

Think about MELG as an S= RLG that is shared between two or more links in its entirety. When two real links have an SRLG in common, it means that two real links c= an co-exist concurrently, but there is something (e.g. common conduit, note= that the conduit has room for more than for one link) that will bring both= these links down, if this something fails (e.g. conduit is cut ). Now consider that this something must be tak= en in its entirety by one of the links to become operational . In this case= SRLG becomes MELG. Note that MELG is only meaningful for virtual links (un= like SRLG that makes sense for either real or virtual link). Why would you advertise two links that mutually exc= lude each other rather than advertising only one of them at a time, unless = the two are virtual links and hence both available for the client layer con= nections?

 

Igor

 

 

From: Khuzema Pithewan [mail= to:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 1:01 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

Do you mean, if virtual = link do not have any specific constraint, for example a link in the path (not talking about egress links/interfaces) must be traversed = to realize the virtual link, there wont be any MELG for the virtual link?

 

Regds

Khuzema

 

From: Igor Bryskin [mai= lto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 9:52 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

MELGs have nothing to do= with bandwidth. MELG is a concrete network resource in a server layer that two or more Virtual Links in a client layer depend on in a mutu= ally exclusive way. An example of MELG is a WDM layer transponder that can = terminate either of respective WDM layer tunnels (but not both at the same = time) for two OTN layer Virtual Links. If you advertise a Virtual Link, say, for Ethernet layer that depen= ds on the connection in OTN layer going through one of the mentioned OTN li= nks, the Ethernet VL must inherit the MELG similarly like it does SRLGs adv= ertised for the OTN links.

 

Igor

 

 

From: Khuzema Pithewan [mail= to:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 12:06 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

For multi-layer (more th= an 2) network, consider all the layers are meshy (that’s when virtual links are useful anyway), MELGs of virtual link will change as and= when BW/wavelength availability changes, because potential paths, a virtua= l link can take will change. Mapping lower layer MELGs to higher layer MELG= s won’t be practical if done in distributed manner, so it has to be centralized. So you do have central el= ement in each layer that knows all the risk and paths (a PCE?), which can b= e utilized for layer specific path computation (as it is doing it anyway).

 

This kind of architectur= e has all the pieces that are required for Inter-PCE communication (across layers), except the protocol that would actually make the 2 PCEs t= alk.

 

You seem to be doing som= ething that you don’t like J

 

Regards

Khuzema

 

From: Igor Bryskin [mai= lto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 8:39 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

I am not a fan of inter-= layer path computations (nor I am a fan of inter-PCE computations). In my mind path computation for a service or services in layer X is perfor= med only in layer X, i.e. considers only X layer links (real or virtual). A= s Pavan mentioned SRLGs and MELGs that need to be inherited from lower laye= rs should be translated into X layer link SRLGs/MELGs and specified with X layer specific SRLG/MELG IDs.=

 

Cheers,

Igor

 

 

From: Khuzema Pithewan [mail= to:kpithewan@infinera.com]
Sent: Friday, April 12, 2013 10:55 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Hi Igor,

 

Ok. This would be useful= if network architecture is based on external PCE or mgmt entity as PCE in client layer, but there is no counterpart in server layer, other= wise one could have inter-PCE communication to achieve diverse path in serv= er layer without getting into virtual link and MELG stuff.

 

Is that correct?<= span lang=3D"EN-US">

 

Khuzema

 

From: Igor Bryskin [mai= lto:IBryskin@advaoptical.com]
Sent: Friday, April 12, 2013 6:36 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan
Cc: Dieter Beller; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

 

Khuzema,

 

2= . =       For cases of concurrent co= mputation (case#2-5), you are mainly talking about global optimization and = diversity among multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done fro= m the source end of those LSPs.  So there is no point in doing concurr= ent computation at one network element for the services starting from multi= ple network elements. At best it looks to me a problem to be solved by network management/planning software. 

Well, when an ingress no= de is initiating a service, it is doing so on request from some management entity. This management entity can compute paths for many servi= ces with some global criteria in mind, and then specify the resulting paths= as explicit EROs in provisioning requests sent to each of the service ingr= esses. How else, for example,  you can set up several services originated from different nodes that are disjo= int from each other? Also, what is the point in your opinion of the statefu= ll PCE work?

 

Cheers,

Igor

 

From: Vishnu Pavan Beeram [m= ailto:vishnupavan@gmail.com]
Sent: Friday, April 12, 2013 8:08 AM
To: Khuzema Pithewan
Cc: Igor Bryskin; Dieter Beller; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Khuzema, Hi!


Please see inline..

 

 

 1.    = ;   When Network has more than= 2 layer i.e. Packet-OTN-DWDM, the Packet (client) layer will be talking to= its immediate server layer i.e. OTN, which in turn is talking to DWDM layer. Using MELG, client layer path computation can take care of = resource exclusivity of virtual link for immediate server layer i.e. OTN la= yer.  However if there is resource exclusivity at DWDM layer, this mec= hanism doesn’t work. You need to do loose routing or use distributed PCE model

 

[VPB] The behavior is the same as what you wo= uld do with SRLGs in a multi-layer architecture. There are architectures th= at allow the SRLGs in the lowest layer to be exported all the way up to the highest layer. The expectation is tha= t MELGs would be treated in the same vein. 

2= . =       For cases of concurrent co= mputation (case#2-5), you are mainly talking about global optimization and = diversity among multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done fro= m the source end of those LSPs.  So there is no point in doing concurr= ent computation at one network element for the services starting from multi= ple network elements. At best it looks to me a problem to be solved by network management/planning software. 

[VPB]  I'm not sure why you think there = is no point in having a centralized computation function compute paths conc= urrently for LSPs with different set of end-points. Even your NMS/planning-software can interact with such computation engine,= retrieve all the paths and then go about initiating the path-setup from th= e ingress of each LSP. 

 

Regards,

-Pavan

 

 

 

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Tuesday, March 26, 2013 7:19 PM
To: Dieter Beller; Vishnu Pavan Beeram


Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Dieter,

 

You said:

>> I guess we are coming back to the es= sential point: "and how often concurrent path computation will be >> used."

 

To be honest, this surprises me quite a bit, = Let me give you some of many reasons as to why concurrent path computations= are needed and why this is better than computing one path at a time:

 

1.      Computing several diverse paths for the same service i= n the context of service recovery. I hope you realize that computing one pa= th at a time on many configurations produces no or sub-optimal results. I a= lso hope you realize the problem of selecting two paths with one of them  having a link with common MELG = with a link from another path;

2.      Computing paths for multiple services to be sufficient= ly disjoint from each other;

3.      Computing paths for multiple services to achieve a glo= bal optimization criteria (e.g. minimal summary total cost);

4.      Computing paths for multiple services for the purpose = of removing the bandwidth fragmentations;

5.      Computing paths for multiple services to plan shared m= esh protection/restoration schemes

6.      Etc.

 

Also think about this:

1.      If concurrent path computation was not important, why = PCEP includes the machinery to do that?

2.      My understanding of the statefull PCE is that it does = pretty much nothing but concurrent path computations

 

You also said:

>> I suppose that if a pce approach is used, = i.e., path computation is centralized including the
>> TE-DB, MELG routing extensions are not needed because the informat= ion about mutual
>>exclusive VLs can be kept in the central TE-DB when VLs are configu= red.

How this logic does not apply to other link a= ttributes such as SRLGs?

What if path computation is not centralized?<= o:p>

 

Cheers,

Igor

 

From: ccamp-bounces@i= etf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: ccamp@ietf.o= rg
Subject: Re: [CCAMP] MELGs - Q&A

 

Hi Pavan,

On 25.03.2013 07:29, Fat= ai Zhang wrote:

Hi Pavan,

 

I am not sure how much V= L (Virtual Link) will be used in the practical deployment and how often concurrent path computation will be used.

I guess we are coming back to the essential p= oint: "and how often concurrent path computation will be used."

This means we are trying to figure out under which conditions MELG routing = extensions
could be beneficial.

IMHO, they would only make sense, if:

  • a path computation function supports the calculation o= f k shortest paths concurrently
  • if there is only a single path computation function in= stance per domain (pce approach)
    If path computation is done in a distributed fashion the benefit goes away = because
    the instances calculate paths independently!

I suppose that if a pce approach is used, i.e., pat= h computation is centralized including the
TE-DB, MELG routing extensions are not needed because the information about= mutual
exclusive VLs can be kept in the central TE-DB when VLs are configured.

Hence, it is quite doubtful whether MELG routing extensions are really usef= ul unless their
applicability is broader.


Thanks,
Dieter

 

Do you think if it makes sense to= add a flag (in routing advertisement) to indicate a link is a VL or not?

 

 

 

Best Regards

 

Fatai=

 

From: Vishnu Pavan Beeram [m= ailto:vishnupavan@gmail.com]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

 

Fatai, Hi!

 

Good to see that you understand the construct= now.

 

This is not a corner case. The utility of the= construct becomes quite significant if you have an application that does c= oncurrent path computations on an abstract topology.

 

Regards,

-Pavan

 

_______________________________________________
CCAMP mailing list
CCAMP@iet=
f.org
https://www.ietf.org/mailman/listinfo/ccamp

 

--

DIETER BELLE= R

ALCATEL-LUCENT DEUTSCHLAN= D AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 711 821 43125 begin_of_the_skype_highlighting 3D"Image&#= 43;49 711 821 43125 FREE  end_of_the_skype_highlighting
Mobil: +49 175 7266874 begin_of_the_skype_highlighting 3D"=+49 175 7266874 FREE  = end_of_the_skype_highlighting

 

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe

 

 

--_000_F82A4B6D50F9464B8EBA55651F541CF84317682ESZXEML552MBXchi_-- --_004_F82A4B6D50F9464B8EBA55651F541CF84317682ESZXEML552MBXchi_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=823; creation-date="Tue, 23 Apr 2013 01:03:35 GMT"; modification-date="Tue, 23 Apr 2013 01:03:35 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABkAGQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigD//2Q== --_004_F82A4B6D50F9464B8EBA55651F541CF84317682ESZXEML552MBXchi_-- From jie.dong@huawei.com Tue Apr 23 06:05:18 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B541321F9675 for ; Tue, 23 Apr 2013 06:05:18 -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 dc85tKKemsMc for ; Tue, 23 Apr 2013 06:05:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4718621F966F for ; Tue, 23 Apr 2013 06:05:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASC57535; Tue, 23 Apr 2013 13:05:09 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Apr 2013 14:04:35 +0100 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Apr 2013 14:05:03 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.76]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.01.0323.007; Tue, 23 Apr 2013 21:04:56 +0800 From: Jie Dong To: Lou Berger , "ccamp@ietf.org" , "draft-dong-ccamp-rsvp-te-mpls-tp-li-lb@tools.ietf.org" Thread-Topic: [CCAMP] poll on making draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05 a WG document Thread-Index: AQHON4lxNyhhcxJLVEyf6yxc+kBPf5jj1lFw Date: Tue, 23 Apr 2013 13:04:56 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927331BCF08@nkgeml512-mbx.china.huawei.com> References: <51545098.4060609@labn.net> <5168187E.2080301@labn.net> In-Reply-To: <5168187E.2080301@labn.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.192.136] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [CCAMP] poll on making draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05 a WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 13:05:18 -0000 Dear chairs,=20 draft-ietf-ccamp-rsvp-te-li-lb-00 has been submitted successfully, thanks. Best regards, Jie > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Lou Berger > Sent: Friday, April 12, 2013 5:22 PM > To: ccamp@ietf.org; draft-dong-ccamp-rsvp-te-mpls-tp-li-lb@tools.ietf.org > Subject: Re: [CCAMP] poll on making draft-dong-ccamp-rsvp-te-mpls-tp-li-l= b-05 > a WG document >=20 >=20 > All, >=20 > This poll is closed. The document is adopted. >=20 > Authors, >=20 > Please resubmit with name change only to draft-ietf-ccamp-rsvp-te-li-lb >=20 > Thank you, > Lou (and Deborah) >=20 > On 3/28/2013 10:15 AM, Lou Berger wrote: > > All, > > > > This is to start a two week poll on making > > draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05 a ccamp working group > > document. Please send mail to the list indicating "yes/support" > > or "no/do not support". If indicating no, please state your technical > > reservations with the document. > > > > All authors have stated that they are not aware of any IPR that > > applies to the draft. > > > > The poll ends Thursday April 11. > > > > Much thanks, > > Lou (and Deborah) > > > > > > _______________________________________________ > > 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 From julien.meuric@orange.com Wed Apr 24 01:04:51 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2846B21F8DBB for ; Wed, 24 Apr 2013 01:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 TPBH3jsO25Uz for ; Wed, 24 Apr 2013 01:04:50 -0700 (PDT) Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id ACB9E21F8D92 for ; Wed, 24 Apr 2013 01:04:49 -0700 (PDT) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A38D15D8AF4 for ; Wed, 24 Apr 2013 10:04:48 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.orange.com (Postfix) with ESMTP id 9B7545D8AF2 for ; Wed, 24 Apr 2013 10:04:48 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 24 Apr 2013 10:04:48 +0200 Received: from [10.193.71.218] ([10.193.71.218]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 24 Apr 2013 10:04:47 +0200 Message-ID: <5177921F.4090200@orange.com> Date: Wed, 24 Apr 2013 10:04:47 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: ccamp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 24 Apr 2013 08:04:48.0089 (UTC) FILETIME=[63B3E490:01CE40C2] Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-swcaps-update X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 08:04:51 -0000 Hi Deborah. No, I am not aware of any applicable IPR. Regards, Julien Le 18/04/2013 18:30, BRUNGARD, DEBORAH A a écrit : > Authors, Contributors, (CCAMP) > In preparation of this document for Last Call: > Are you aware of any IPR that applies to draft-ietf-ccamp-swcaps-update? > 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 answer > the above > by responding to this email regardless of whether or not you are aware > of any > relevant IPR. This document will not advance to the next stage until a > response > has been received from each author and listed contributor. > If you are on the CCAMP WG email list but are not listed as an author or > contributor, we remind you of your obligations under the IETF IPR > rules which > encourages you to notify the IETF if you are aware of IPR of others on > an IETF > contribution, or to refrain from participating in any contribution or > discussion > related to your undisclosed IPR. For more information, please see the > RFCs listed > above and > _http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty_. > Thank you, > CCAMP WG Chairs > PS Please include all listed in the headers of this message in your > response. > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From fred.gruman@us.fujitsu.com Wed Apr 24 09:11:44 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2399D21F8DA6 for ; Wed, 24 Apr 2013 09:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 TUJLSqBErIkC for ; Wed, 24 Apr 2013 09:11:43 -0700 (PDT) Received: from fncnmp03.fnc.fujitsu.com (fncnmp03.fnc.fujitsu.com [168.127.0.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0120E21F93B2 for ; Wed, 24 Apr 2013 09:11:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,542,1363150800"; d="scan'208";a="31522151" Received: from rchexhcp2.fnc.net.local ([168.127.134.76]) by fncnmp01.fnc.fujitsu.com with ESMTP/TLS/AES128-SHA; 24 Apr 2013 11:11:42 -0500 Received: from RCHEXMBP1.fnc.net.local ([169.254.2.136]) by RCHEXHCP2.fnc.net.local ([168.127.134.76]) with mapi id 14.02.0309.002; Wed, 24 Apr 2013 11:11:42 -0500 From: "Gruman, Fred" To: John E Drake , Daniele Ceccarelli Thread-Topic: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt Thread-Index: Ac47BbOWqrw6KEYeXEevrzCZSajLdgAWuz+wAWb0biA= Date: Wed, 24 Apr 2013 16:11:42 +0000 Message-ID: <5DF87403A81B0C43AF3EB1626511B29263C90620@RCHEXMBP1.fnc.net.local> References: <4A1562797D64E44993C5CBF38CF1BE480AEC6B@ESESSMB301.ericsson.se> <0182DEA5604B3A44A2EE61F3EE3ED69E1D4A5428@BL2PRD0510MB349.namprd05.prod.outlook.com> In-Reply-To: <0182DEA5604B3A44A2EE61F3EE3ED69E1D4A5428@BL2PRD0510MB349.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [168.127.136.253] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19822.000 x-tm-as-result: No--87.899500-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 16:11:44 -0000 Hi John/Daniele, It was pointed out to me that ITU was thinking of additional TSGs when they= look at beyond ODU4. There is no need to add additional TSGs until these a= re standardized in future versions of G.709. But if there are additional va= lues, it may be more intuitive encoding to use bitmaps. But as I mention i= n my email, there is really nothing wrong with the current method (ENUM). In response to Daniele's question regarding "an interface might support dif= ferent TSGs at the same time", I would agree that the only time this would = probably be the case is before the first LO-ODU was provisioned and we want= to show the potential to support different TSGs against the HO-ODU. Once t= he first LO-ODU was activated, then the TSG would be locked for that HO-ODU= . Best Regards, Fred -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Wednesday, April 17, 2013 5:45 AM To: Daniele Ceccarelli; Gruman, Fred Cc: ccamp@ietf.org Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-06.= txt Fred, Other than to demonstrate it is always possible to add additional complexit= y to OTN, is there any reason to add additional TSG values? Irrespectively Yours, John > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Daniele Ceccarelli > Sent: Tuesday, April 16, 2013 5:52 PM > To: fred.gruman@us.fujitsu.com > Cc: ccamp@ietf.org > Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-ospf- > g709v3-06.txt >=20 > Hi Fred, >=20 > Thanks again for the suggestions. No worries, if this is a change that > makes sense we can fix it before the second last call. >=20 > Just wanted a clarification (more loud thinking than a question): do > you think that an interface might support different TSGs at the same > time? If the answer is yes the bitmap makes sense, otherwise an enum > would be more bits-saving. > I would say that until no LSP is configured it is possible to > advertise/support multiple of them (e.g. The newest one plus the ones > it is possible to rollback to for backward compatibility issues) and > then, after the instantiation of the first LSP, a single one. >=20 > Best regards > Daniele >=20 > *** E-mail via DME powered by mobile broadband *** >=20 > --Original message--- > Sender: "Gruman, Fred" Sent time: > 14/apr/2013 09:02 > To: daniele.ceccarelli@ericsson.com, ccamp@ietf.org > Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-ospf- > g709v3-06.txt >=20 > Hi Daniele, >=20 > Thanks for making the update to the TSG examples in Section 5.2 >=20 > I have a one additional comments regarding TSG: >=20 > 1) during an OIF conference call, Stephen Shew indicated that ITU may > be considering additional tributary slot granularity in the future (in > addition to 1.25 and 2.5G). There was a concern about handling more > complex combinations in the future. >=20 > It was suggested that perhaps instead of enumerating each combination, > the TSG be treated as bit flags where the first bit could indicate > 1.25G, second bit indicates 2.5G, third bit and beyond (perhaps into > the reserve fields in the future) could indicate future TSG rates. The > encoding could then be: > 00 - ignored > 10 - 1.25G only > 01 - 2.5G only > 11 - Both 1.25G and 2.5G supported >=20 > This may make it easier to understand the encoding if additional TSGs > are added later. >=20 > I realize this comment may be coming in late so you might prefer to not > make any changes (this is ok with me as the current encodings are > technically correct). >=20 > Best Regards, > Fred >=20 >=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Daniele Ceccarelli > Sent: Thursday, April 04, 2013 10:46 AM > To: ccamp@ietf.org > Subject: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3- > 06.txt >=20 > Dear OTNers, >=20 > Info model and OSPF drafts have been updated accordingly to the > discussion in Orlando. The OSPF draft also includes some last call > comments that had not been addressed in v05 and suggestions received on > the list. >=20 > On the other side the framework draft doesn't need any change, while > the signaling will be updated soon. >=20 > BR > Daniele, Sergio, Fatai >=20 >=20 > >-----Original Message----- > >From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > >Of internet-drafts@ietf.org > >Sent: gioved=EC 4 aprile 2013 17.40 > >To: i-d-announce@ietf.org > >Cc: ccamp@ietf.org > >Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-06.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 : Traffic Engineering Extensions to > >OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN > >Networks > > Author(s) : Daniele Ceccarelli > > Diego Caviglia > > Fatai Zhang > > Dan Li > > Sergio Belotti > > Pietro Vittorio Grandi > > Rajan Rao > > Khuzema Pithewan > > John E Drake > > Filename : draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt > > Pages : 35 > > Date : 2013-04-04 > > > >Abstract: > > ITU-T Recommendation G.709 [G.709-2012] has introduced new fixed > and > > flexible Optical Data Unit (ODU) containers, enabling optimized > > support for an increasingly abundant service mix. > > > > This document describes Open Shortest Path First - Traffic > > Engineering (OSPF-TE) routing protocol extensions to support > > Generalized MPLS (GMPLS) control of all currently defined ODU > > containers, in support of both sub-lambda and lambda level routing > > granularity. > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-ospf-g709v3 > > > >There's also a htmlized version available at: > >http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-06 > > > >A diff from the previous version is available at: > >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-gmpls-ospf-g709v3-06 > > > > > >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 From leeyoung@huawei.com Wed Apr 24 09:17:28 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F4A21F8F0F for ; Wed, 24 Apr 2013 09:17:27 -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 HPX69T5SYTUe for ; Wed, 24 Apr 2013 09:17:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 86F3021F9026 for ; Wed, 24 Apr 2013 09:17:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASD64795; Wed, 24 Apr 2013 16:17:17 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 24 Apr 2013 17:16:46 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 24 Apr 2013 17:17:17 +0100 Received: from dfweml511-mbs.china.huawei.com ([169.254.15.13]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.007; Wed, 24 Apr 2013 09:17:12 -0700 From: Leeyoung To: Lou Berger Thread-Topic: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 Thread-Index: AQHOMYCjjSbgAyDhM0mIOPaGuA1CEpjloTRA Date: Wed, 24 Apr 2013 16:17:11 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172913671A@dfweml511-mbs.china.huawei.com> References: <8DC6547C806B644F998A0566E79E15920F7DFF60@DEMUMBX006.nsn-intra.net> <7AEB3D6833318045B4AE71C2C87E8E172911828D@dfweml511-mbs.china.huawei.com> <8DC6547C806B644F998A0566E79E15920F7E1284@DEMUMBX006.nsn-intra.net> <7AEB3D6833318045B4AE71C2C87E8E172911D7BA@dfweml511-mbs.china.huawei.com> <51471168.3000400@labn.net> <7AEB3D6833318045B4AE71C2C87E8E172911DC5E@dfweml511-mbs.china.huawei.com> <514895C5.7080300@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729121785@dfweml511-mbs.china.huawei.com> <515DF956.1020305@labn.net> In-Reply-To: <515DF956.1020305@labn.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.198] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CCAMP , "draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org" Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 16:17:28 -0000 Hi Lou, I think the main point is if we need to advertise add/drop (tributary) port= s in generic context? You said in the previous email: "I agree that that is how it is normally done, but WSON seems to be changin= g this in two respects: 1) By advertising G-PID at all, 2) By advertising add/drop ports, where prior GMPLS approaches have only ad= vertised the network facing interfaces." These elements above are part of regeneration elements that constitute a WS= ON lightpath which begins the line side of ingress and ends the line side o= f egress. See the diagram below: ---- ---- | |<------------ -------------->| | ---- | | ---- -------- | REG | -------- There is a clear use case for this for WSON as REG's are integral part of a= WSON lightpath which can cause an incompatibility/blocking issue of the pa= th. Drop/Add ports here in REG element may have wavelength restriction and = that is why this is an additional constraint to look at.=20 Advertising tributary ports in general context is a different matter to me.= Not sure if there is a clear use case that can be justified to support adv= ertising tributary ports in general context. Even if there is, I don't thin= k that is part of the scope of the generic encoding.=20 Regards, Young -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= ou Berger Sent: Thursday, April 04, 2013 5:06 PM To: Leeyoung Cc: CCAMP; draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 Young, Please see below. On 3/27/2013 1:59 PM, Leeyoung wrote: > Hi Lou, >=20 > Please see my comments in-line.=20 >=20 > Thanks. > Young >=20 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Tuesday, March 19, 2013 11:44 AM > To: Leeyoung > Cc: CCAMP; Margaria, Cyril (NSN - DE/Munich);=20 > draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org > Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 >=20 >=20 > Young, > See below. > On 3/18/2013 1:02 PM, Leeyoung wrote: >> Hi Lou, >> >> The encoding is a part of the Resource Block >=20 > Understood, but my comment was more on the definition of=20 > / encoding. >=20 >> (that includes Regenerators and Wavelength converters) which is a WSON s= pecific entity. >=20 > So I agree that the need for transit nodes to have detailed encoding=20 > and adaptation information to support 3R and certain other types of=20 > switching is (at least to my understanding) specific to WSON. >=20 Y> YOUNG>> RFC 3471 and RFC 4328 discuss G-PID as part of Generalized Y> Label Request parameters to indicate client/tributary layer of the=20 Y> LSP at the source/sink. Y> Y> I was not clear on what you meant "trib side resources." If you meant=20 Y> "trib side resources" are LSP encoding type, Switching Type and G-PID=20 Y> (which are covered by RFC 3471/4328), I believe RFC 3471/4328 are=20 Y> sufficient; if not could you elaborate? trib side =3D add/drop port at ingress/egress resources =3D attributes related to data that port can transport >=20 > But unless I misunderstand the WSON info draft, this same information=20 > can be advertised in support of the trib side resources (i.e., at the=20 > source/destination for add/drop) and this is a generic requirement=20 > shared with other technologies. >=20 y> YOUNG>> Here you seemed to allude the need for advertizing the y> Source/Destination tributary resource information using IGP. In=20 y> general, OSPF does not advertise the trib-side information, does it? y> I believe signaling check on the tributary resource info on LSP level=20 y> is good enough per RFC 3471/4328. Please correct me if my=20 y> understanding is wrong. I agree that that is how it is normally done, but WSON seems to be changing= this in two respects: 1) By advertising G-PID at all, 2) By advertising add/drop ports, where prior GMPLS approaches have only ad= vertised the network facing interfaces. Did I misunderstand the intent of mentioning drop ports in several places i= n Section 6 of the info document? >=20 > So this lead me to ask about changing the G-PID list encoding to be=20 > defined in the generic drafts (to facilitate PID advertisement for=20 > non-WSON technologies.) Perhaps just having a generic encoding for a=20 > G-PID list won't be of much value, but I suspect that we'll end up=20 > needing it for other technologies too. >=20 Y> YOUNG>> This point is carried from the above discussion. G-PID has Y> been specified to cover all GMPLS related technologies. Agreed that this is a derivative point and can wait until the above is clar= ified. > -- For what it's worth I am having some trouble understanding how=20 > G-PID is advertised for add/drop. As far as I can tell, you have a=20 > per add/drop port, mapped to , to a=20 > and infer output G-PID from the . > At least that's how I'm reading the info draft. Y> YOUNG>> Actually G-PID is advertised as part of the Node Y> information: ::=3D [...= ] Y> [] Got that. That's what I was referring to when I said " mapped to " >=20 > Look at the diagram below from info draft: >=20 > I1 +-------------+ +-------------+ E1 > ----->| | +--------+ | |-----> > I2 | +------+ Rb #1 +-------+ | E2 > ----->| | +--------+ | |-----> > | | | | > | Resource | +--------+ | Resource | > | Pool +------+ +-------+ Pool | > | | + Rb #2 + | | > | Input +------+ +-------| Output | > | Connection | +--------+ | Connection | > | Matrix | . | Matrix | > | | . | | > | | . | | > IN | | +--------+ | | EM > ----->| +------+ Rb #P +-------+ |-----> > | | +--------+ | | > +-------------+ ^ ^ +-------------+ > | | > | | > | | > | | >=20 > Input wavelength Output wavelength > constraints for constraints for > each resource each resource >=20 > Figure 1 Schematic diagram of resource pool model. >=20 > Add/Drop ports to/from Resource Pool (i.e., I1,...IN and E1,..EN) is=20 > part of link information and advertised as link-TLV; however Resource=20 > Blocks and its internal connectivity is not modeled as node property=20 > as they are internal to Resource Pool. >=20 > ::=3D ... > [...] [...] > [] >=20 > We modeled how RB's are accessible via matrices (input/ouput), if=20 > there are wavelength limitations and if RB's are available. All of=20 > these are modeled as the node property. >=20 > And within RBinfo, we included Input/Output Constraints where ClientSigna= lList (GPID) is specified.=20 >=20 > ::=3D ([] > [] )* >=20 > Where=20 > ::=3D [] > [] >=20 >=20 >=20 > I was delaying asking if a couple of related questions until the above=20 > was resolved, but perhaps it makes sense to ask them now: > - Shouldn't also be allowed under ? >=20 > YOUNG>> It is implied. is checked in = and has obviously the same property. We can add this c= omment to clarify.=20 >=20 So there is/will never (be) a case where the differ fro= m the ? As you say, this certainly should be made explici= t. > - Doesn't it make sense to simplify the add/drop G-PID identification=20 > by adding somewhere under (generic) ? >=20 y> YOUNG>> I think you meant doing this at the source/destination. sure, but aren't add/drop always at source/destination? (I guess you can c= ome up with a case where they aren't, but this isn't the norm...) Y> Again y> I am not sure if we really need to advertise tributary client signal=20 y> as link TLV. We have signaling mechanism to verify this. As you say, this point is covered above. > Thanks, > Lou >=20 >> >> Regards, >> Young >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Monday, March 18, 2013 8:07 AM >> To: Leeyoung; CCAMP >> Cc: Margaria, Cyril (NSN - DE/Munich);=20 >> draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >> Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 >> >> Young/All, >> >> Some of the discussions last week (on 709 and dimitri's) got me=20 >> thinking more about the inclusion of G-PID on the wson specific=20 >> encoding. As G-PID and other client/input information is not=20 >> technology specific, and it looks like there's a likely a need for a=20 >> general solution, shouldn't the G-PID (and other 'client/input')=20 >> information be in draft-ietf-ccamp-general-constraint-encode? >> >> Thoughts? >> >> Lou >> >> On 3/15/2013 5:35 AM, Leeyoung wrote: >>> Thanks.=20 >>> >>> Young >>> >>> -----Original Message----- >>> From: Margaria, Cyril (NSN - DE/Munich)=20 >>> [mailto:cyril.margaria@nsn.com] >>> Sent: Thursday, March 14, 2013 5:53 PM >>> To: Leeyoung; CCAMP; draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >>> Subject: RE: Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>> >>> >>> Hi, >>> >>> Thanks for the quick feedback. As this introduce a dependency with=20 >>> the GPID, the text should indicate that the number of bit rate MUST mat= ch the number of GPID. >>> >>> Other than that I think this is acceptable >>> >>> >>> >>> Best regards / Mit freundlichen Gr=FC=DFen Cyril Margaria >>> >>> >>>> -----Original Message----- >>>> From: ext Leeyoung [mailto:leeyoung@huawei.com] >>>> Sent: Wednesday, March 13, 2013 9:33 PM >>>> To: Margaria, Cyril (NSN - DE/Munich); CCAMP; draft-ietf-ccamp-rwa- >>>> wson-encode@tools.ietf.org >>>> Subject: RE: Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>>> >>>> Hi Cyril, >>>> >>>> Thanks for your comment. >>>> >>>> This refers to the "Input Bit Rate" of the associated client Signal >>>> Type in the RB. >>>> Below is a new section 5.4 that defines Input Bit Rate List Sub-Sub- >>>> TLV. We removed "range" from this Sub-Sub-TLV. >>>> >>>> Let me know if this is acceptable. >>>> >>>> Thanks. >>>> Young >>>> >>>> --------------------------------------------------------------------- >>>> >>>> 5.4. Input Bit Rate List Sub-Sub-TLV >>>> >>>> This sub-sub-TLV contains a list of bit rate of each input client >>>> signal types specified in the Input Client Signal List Sub-Sub-TLV. >>>> Type :=3D Input Bit Rate List >>>> Value :=3D IEEE 32-bit IEEE Floating Point >>>> >>>> 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 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Input Bit Rate of GPID #1 | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> : : >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Input Bit Rate of GPID #N | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >>>> Of Margaria, Cyril (NSN - DE/Munich) >>>> Sent: Wednesday, March 13, 2013 8:54 AM >>>> To: CCAMP; draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >>>> Subject: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>>> >>>> Dear Authors, >>>> >>>> I have the following comments on draft-ietf-ccamp-rwa-wson-encode-19 >>>> >>>> Section 5.1 Resource Block Information Sub-TLV >>>> >>>> The sub-TLV format defines the "Input Bit Rate Range List Sub-Sub-TLV >>>> (opt)" >>>> No section defines the Input Bit range List Sub-Sub-TLV, while it was >>>> present in the previous version. >>>> >>>> I think the section should be re-added. >>>> >>>> >>>> Mit freundlichen Gr=FC=DFen / Best Regards >>>> Cyril Margaria >>>> >>>> Nokia Siemens Networks Optical GmbH >>>> St.Martin-Str. 76 >>>> D-81541 M=FCnchen >>>> Germany >>>> mailto:cyril.margaria@nsn.com >>>> Phone: +49-89-5159-16934 >>>> Fax: +49-89-5159-44-16934 >>>> ---------------------------------------------------------------- >>>> Nokia Siemens Networks Optical GmbH >>>> Gesch=E4ftsleitung / Board of Directors: Gero Neumeier, Dr. Rolf Nauer= z >>>> Sitz der Gesellschaft: M=FCnchen / Registered office: Munich >>>> Registergericht: M=FCnchen / Commercial registry: Munich, HRB 197143 >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >>> >>> >> >> >> >> >=20 >=20 >=20 >=20 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From db3546@att.com Fri Apr 26 10:35:05 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985C821F992A for ; Fri, 26 Apr 2013 10:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.109 X-Spam-Level: X-Spam-Status: No, score=-105.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 Ib95hci2WAVD for ; Fri, 26 Apr 2013 10:35:04 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2B121F9846 for ; Fri, 26 Apr 2013 10:35:04 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 5caba715.0.203829.00-322.569398.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 26 Apr 2013 17:35:04 +0000 (UTC) X-MXL-Hash: 517abac82a36a844-b834bf3ce27a13f99344d475f9ca3bcfe94704a7 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3QHZ1P7017790 for ; Fri, 26 Apr 2013 13:35:01 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3QHYnf8017572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 26 Apr 2013 13:34:56 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by mlpi408.sfdc.sbc.com (RSA Interceptor) for ; Fri, 26 Apr 2013 17:34:36 GMT Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.02.0342.003; Fri, 26 Apr 2013 13:34:36 -0400 From: "BRUNGARD, DEBORAH A" To: "ccamp@ietf.org" Thread-Topic: WG Last Call on draft-ietf-ccamp-swcaps-update-01.txt Thread-Index: Ac5CpFGQuVimYnF0R+e2aPHfvQiJcg== Date: Fri, 26 Apr 2013 17:34:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C82C2A2AMISOUT7MSGUSR9OIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=RJIE6fe+ c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=RWEAq7CW3jcA:10 a=lZHTLzeqT6kA:10 a=ofMgfj31e3cA:10 a=KWR] X-AnalysisOut: [eWi5eUu4A:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=7xdm98gX3QkA:10 a=dyffm4UfW2pelP8trvAA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=PV0jEgmCKQCAVoUm6wwA:9 a=_W_S_7VecoQA:10 a=frz] X-AnalysisOut: [4AuCg-hUA:10 a=RNNtfrrZ-6KpEBg0:21] Subject: [CCAMP] WG Last Call on draft-ietf-ccamp-swcaps-update-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 17:35:05 -0000 --_000_F64C10EAA68C8044B33656FA214632C82C2A2AMISOUT7MSGUSR9OIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, This starts a two-week working group last call on draft-ietf-ccamp-swcaps-u= pdate-01.txt. This working group last call ends May 10th, 2013. Please send your comments to the CCAMP mailing list. Deborah (and Lou) --_000_F64C10EAA68C8044B33656FA214632C82C2A2AMISOUT7MSGUSR9OIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,
 
This starts a two-week working group last call on draft-ietf-ccamp-swc= aps-update-01.txt.
 
This working group last call ends May 10th, 2013.
 
Please send your comments to the CCAMP mailing list.
 
Deborah (and Lou)
 
 
 --_000_F64C10EAA68C8044B33656FA214632C82C2A2AMISOUT7MSGUSR9OIT_-- From johnsonhammond2@hushmail.com Sat Apr 27 10:12:47 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDEF121F9822 for ; Sat, 27 Apr 2013 10:12:47 -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 b0Dy4GCiXWhm for ; Sat, 27 Apr 2013 10:12:47 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by ietfa.amsl.com (Postfix) with ESMTP id A179521F9821 for ; Sat, 27 Apr 2013 10:12:47 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by smtp1.hushmail.com (Postfix) with SMTP id 785963053E for ; Sat, 27 Apr 2013 17:12:47 +0000 (UTC) Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.52]) by smtp1.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:12:47 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 2F3A214DBE1; Sat, 27 Apr 2013 17:12:47 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:12:46 -0400 To: ccamp@ietf.org From: johnsonhammond2@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427171247.2F3A214DBE1@smtp.hushmail.com> Subject: [CCAMP] Biggest Fake Conference in Computer Science X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 18:08:06 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From daniele.ceccarelli@ericsson.com Sun Apr 28 10:34:20 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0167821F9A06 for ; Sun, 28 Apr 2013 10:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 WDmCJBdr6FaH for ; Sun, 28 Apr 2013 10:34:19 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEAE21F9805 for ; Sun, 28 Apr 2013 10:34:18 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-df-517d5d98b111 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 99.5D.10459.89D5D715; Sun, 28 Apr 2013 19:34:16 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.55]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Sun, 28 Apr 2013 19:34:16 +0200 From: Daniele Ceccarelli To: "Gruman, Fred" , John E Drake Thread-Topic: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt Thread-Index: Ac47BbOWzTuuOSgCzkqIPxCgYq5HeQASnhMAAWleSAAAOk/coA== Date: Sun, 28 Apr 2013 17:34:15 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE480C0EDE@ESESSMB301.ericsson.se> References: <4A1562797D64E44993C5CBF38CF1BE480AEC6B@ESESSMB301.ericsson.se> <0182DEA5604B3A44A2EE61F3EE3ED69E1D4A5428@BL2PRD0510MB349.namprd05.prod.outlook.com> <5DF87403A81B0C43AF3EB1626511B29263C90620@RCHEXMBP1.fnc.net.local> In-Reply-To: <5DF87403A81B0C43AF3EB1626511B29263C90620@RCHEXMBP1.fnc.net.local> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvre6M2NpAg23NuhZP5txgsehvnc1q MeeuswOzx5IlP5k8rjddZfeY9msNWwBzFJdNSmpOZllqkb5dAlfGyebzTAVb7Sva5u1lamA8 bNTFyMkhIWAi0fX/OCOELSZx4d56ti5GLg4hgcOMEtcPzWeCcBYzSjT0rgCq4uBgE7CSeHLI B6RBRCBE4ub7JrBmZgFVibbrp1hBSoQFAiR+HK2DKAmUeH13AiuE7SRx9/dTNhCbBaj8wJpl TCA2r4C3xNZ7f9lBbCGB54wSsw/wg9icAv4SFxesZgaxGQVkJSbsXgS1Slzi1pP5TBA3C0gs 2XOeGcIWlXj5+B8rhK0ocXX6ciaIej2JG1OnsEHY2hLLFr5mhtgrKHFy5hOWCYxis5CMnYWk ZRaSlllIWhYwsqxiZM9NzMxJLzfcxAiMmYNbfuvuYDx1TuQQozQHi5I473SpykAhgfTEktTs 1NSC1KL4otKc1OJDjEwcnFINjK4uawrZe/nTZb/XHtjgcLFma8XGMNM7F465VLVMVFfymBI0 +6TtXPHtu044nn3w93rZ8l+JLE/0Y0M+Ht9wTtb5uOin7doWa+eWrElO3dzDaJIVoyEbn3rf +HPQihlxYf0umi829TsIvjcpi4qROVYwI87QRWzv6cn9+0SfRLO9z5I4pTT9jRJLcUaioRZz UXEiAHW737xnAgAA Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 17:34:20 -0000 Hi Fred, It seems we are on the same page. All of the considerations below are more = than reasonable but it seems at the time being we don't have enough info to= state whether an enum is better than a bitmap or viceversa. I would sugges= t to keep the actual encoding but many thanks for raising up the issue. Many thanks Daniele >-----Original Message----- >From: Gruman, Fred [mailto:fred.gruman@us.fujitsu.com]=20 >Sent: mercoled=EC 24 aprile 2013 18.12 >To: John E Drake; Daniele Ceccarelli >Cc: ccamp@ietf.org >Subject: RE: [CCAMP] FW: I-D Action:=20 >draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt > >Hi John/Daniele, > >It was pointed out to me that ITU was thinking of additional=20 >TSGs when they look at beyond ODU4. There is no need to add=20 >additional TSGs until these are standardized in future=20 >versions of G.709. But if there are additional values, it may=20 >be more intuitive encoding to use bitmaps. But as I mention=20 >in my email, there is really nothing wrong with the current=20 >method (ENUM). > >In response to Daniele's question regarding "an interface=20 >might support different TSGs at the same time", I would agree=20 >that the only time this would probably be the case is before=20 >the first LO-ODU was provisioned and we want to show the=20 >potential to support different TSGs against the HO-ODU. Once=20 >the first LO-ODU was activated, then the TSG would be locked=20 >for that HO-ODU. > >Best Regards, >Fred > >-----Original Message----- >From: John E Drake [mailto:jdrake@juniper.net] >Sent: Wednesday, April 17, 2013 5:45 AM >To: Daniele Ceccarelli; Gruman, Fred >Cc: ccamp@ietf.org >Subject: RE: [CCAMP] FW: I-D Action:=20 >draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt > >Fred, > >Other than to demonstrate it is always possible to add=20 >additional complexity to OTN, is there any reason to add=20 >additional TSG values? > >Irrespectively Yours, > >John > > >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]=20 >On Behalf=20 >> Of Daniele Ceccarelli >> Sent: Tuesday, April 16, 2013 5:52 PM >> To: fred.gruman@us.fujitsu.com >> Cc: ccamp@ietf.org >> Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-ospf-=20 >> g709v3-06.txt >>=20 >> Hi Fred, >>=20 >> Thanks again for the suggestions. No worries, if this is a=20 >change that=20 >> makes sense we can fix it before the second last call. >>=20 >> Just wanted a clarification (more loud thinking than a question): do=20 >> you think that an interface might support different TSGs at the same=20 >> time? If the answer is yes the bitmap makes sense, otherwise an enum=20 >> would be more bits-saving. >> I would say that until no LSP is configured it is possible to=20 >> advertise/support multiple of them (e.g. The newest one plus=20 >the ones=20 >> it is possible to rollback to for backward compatibility issues) and=20 >> then, after the instantiation of the first LSP, a single one. >>=20 >> Best regards >> Daniele >>=20 >> *** E-mail via DME powered by mobile broadband *** >>=20 >> --Original message--- >> Sender: "Gruman, Fred" Sent time: >> 14/apr/2013 09:02 >> To: daniele.ceccarelli@ericsson.com, ccamp@ietf.org >> Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-ospf-=20 >> g709v3-06.txt >>=20 >> Hi Daniele, >>=20 >> Thanks for making the update to the TSG examples in Section 5.2 >>=20 >> I have a one additional comments regarding TSG: >>=20 >> 1) during an OIF conference call, Stephen Shew indicated=20 >that ITU may=20 >> be considering additional tributary slot granularity in the=20 >future (in=20 >> addition to 1.25 and 2.5G). There was a concern about handling more=20 >> complex combinations in the future. >>=20 >> It was suggested that perhaps instead of enumerating each=20 >combination,=20 >> the TSG be treated as bit flags where the first bit could indicate=20 >> 1.25G, second bit indicates 2.5G, third bit and beyond (perhaps into=20 >> the reserve fields in the future) could indicate future TSG rates. =20 >> The encoding could then be: >> 00 - ignored >> 10 - 1.25G only >> 01 - 2.5G only >> 11 - Both 1.25G and 2.5G supported >>=20 >> This may make it easier to understand the encoding if=20 >additional TSGs=20 >> are added later. >>=20 >> I realize this comment may be coming in late so you might prefer to=20 >> not make any changes (this is ok with me as the current=20 >encodings are=20 >> technically correct). >>=20 >> Best Regards, >> Fred >>=20 >>=20 >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]=20 >On Behalf=20 >> Of Daniele Ceccarelli >> Sent: Thursday, April 04, 2013 10:46 AM >> To: ccamp@ietf.org >> Subject: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3- >> 06.txt >>=20 >> Dear OTNers, >>=20 >> Info model and OSPF drafts have been updated accordingly to the=20 >> discussion in Orlando. The OSPF draft also includes some last call=20 >> comments that had not been addressed in v05 and suggestions received=20 >> on the list. >>=20 >> On the other side the framework draft doesn't need any change, while=20 >> the signaling will be updated soon. >>=20 >> BR >> Daniele, Sergio, Fatai >>=20 >>=20 >> >-----Original Message----- >> >From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 >> >Behalf Of internet-drafts@ietf.org >> >Sent: gioved=EC 4 aprile 2013 17.40 >> >To: i-d-announce@ietf.org >> >Cc: ccamp@ietf.org >> >Subject: [CCAMP] I-D Action:=20 >> >draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt >> > >> > >> >A New Internet-Draft is available from the on-line Internet-Drafts=20 >> >directories. >> > This draft is a work item of the Common Control and Measurement=20 >> >Plane Working Group of the IETF. >> > >> > Title : Traffic Engineering Extensions to >> >OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN=20 >> >Networks >> > Author(s) : Daniele Ceccarelli >> > Diego Caviglia >> > Fatai Zhang >> > Dan Li >> > Sergio Belotti >> > Pietro Vittorio Grandi >> > Rajan Rao >> > Khuzema Pithewan >> > John E Drake >> > Filename : draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt >> > Pages : 35 >> > Date : 2013-04-04 >> > >> >Abstract: >> > ITU-T Recommendation G.709 [G.709-2012] has introduced new fixed >> and >> > flexible Optical Data Unit (ODU) containers, enabling optimized >> > support for an increasingly abundant service mix. >> > >> > This document describes Open Shortest Path First - Traffic >> > Engineering (OSPF-TE) routing protocol extensions to support >> > Generalized MPLS (GMPLS) control of all currently defined ODU >> > containers, in support of both sub-lambda and lambda=20 >level routing >> > granularity. >> > >> > >> >The IETF datatracker status page for this draft is: >> >https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-ospf-g709v3 >> > >> >There's also a htmlized version available at: >> >http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-06 >> > >> >A diff from the previous version is available at: >>=20 >>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-gmpls-ospf-g709v3-0 >> >6 >> > >> > >> >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 > > >=