From nobody Tue Apr 1 09:01:06 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0A41A0994 for ; Tue, 1 Apr 2014 09:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.005 X-Spam-Level: * X-Spam-Status: No, score=1.005 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, SPF_SOFTFAIL=0.665, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTfhHkBfdfMx for ; Tue, 1 Apr 2014 09:01:03 -0700 (PDT) Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACD81A099C for ; Tue, 1 Apr 2014 09:01:01 -0700 (PDT) Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7E50CDE4009 for ; Tue, 1 Apr 2014 18:02:40 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.orange.com (Postfix) with ESMTP id 758AFDE4003 for ; Tue, 1 Apr 2014 18:02:40 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Apr 2014 18:00:55 +0200 Received: from [10.193.71.94] ([10.193.71.94]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Apr 2014 18:00:55 +0200 Message-ID: <533AE2B6.8080707@orange.com> Date: Tue, 01 Apr 2014 18:00:54 +0200 From: Julien Meuric Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: pce@ietf.org References: <53270A63.1060306@orange.com> In-Reply-To: <53270A63.1060306@orange.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Apr 2014 16:00:55.0351 (UTC) FILETIME=[9064A470:01CF4DC3] Archived-At: http://mailarchive.ietf.org/arch/msg/pce/Q6amIKnRewFXYT3Ra651ZRP2VGE Subject: Re: [Pce] WG Last Call for draft-ietf-pce-pcep-mib-07 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 16:01:04 -0000 Hi. This WG LC has ended. A great step for one of our oldest I-Ds. JP & Julien Mar. 17, 2014 - Julien Meuric: > Hi all. > > This message ignites a PCE WG last call on draft-ietf-pce-pcep-mib-07. > It will end on Monday, March 31, 11:59 PM (UTC-12). > > Thanks, > > JP & Julien > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > From nobody Wed Apr 2 02:20:28 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043E41A017D; Wed, 2 Apr 2014 02:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NI3z6EWXBgBM; Wed, 2 Apr 2014 02:20:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 986EB1A0188; Wed, 2 Apr 2014 02:20:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140402092022.32169.99094.idtracker@ietfa.amsl.com> Date: Wed, 02 Apr 2014 02:20:22 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/hBsOyi-tuOnnJdbvuwCm3YPOwJ4 Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-pcep-mib-08.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 09:20:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Path Computation Element Protocol (PCEP) Management Information Base Authors : A S Kiran Koushik Emile Stephan Quintin Zhao Daniel King Jonathan Hardwick Filename : draft-ietf-pce-pcep-mib-08.txt Pages : 47 Date : 2014-04-02 Abstract: This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Path Computation Element communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-pcep-mib-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-mib-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 2 02:23:48 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18EB51A0191 for ; Wed, 2 Apr 2014 02:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2Y1NzWRS_cR for ; Wed, 2 Apr 2014 02:23:42 -0700 (PDT) Received: from ENFICSETS1.metaswitch.com (enficsets1.metaswitch.com [192.91.191.38]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6821A0132 for ; Wed, 2 Apr 2014 02:23:42 -0700 (PDT) Received: from ENFIRHCAS1.datcon.co.uk (172.18.209.38) by ENFICSETS1.metaswitch.com (172.18.4.18) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 2 Apr 2014 10:23:34 +0100 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHCAS1.datcon.co.uk ([fe80::85a7:aa4e:2516:c2ad%11]) with mapi id 14.03.0174.001; Wed, 2 Apr 2014 10:23:37 +0100 From: Jonathan Hardwick To: "pce@ietf.org" Thread-Topic: [Pce] I-D Action: draft-ietf-pce-pcep-mib-08.txt Thread-Index: AQHPTlTK7Np1WBd+dkaxpAOtJZF8cJr+DQOg Date: Wed, 2 Apr 2014 09:23:37 +0000 Message-ID: <09CE6C3BE5E1EA40B987BF5F25D8DDBAE137A6FB@ENFICSMBX1.datcon.co.uk> References: <20140402092022.32169.99094.idtracker@ietfa.amsl.com> In-Reply-To: <20140402092022.32169.99094.idtracker@ietfa.amsl.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.34.141] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/JHXTPhe6pFzzJIGiQFfYdzgbIOE Subject: Re: [Pce] I-D Action: draft-ietf-pce-pcep-mib-08.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 09:23:47 -0000 This new version of the PCEP MIB draft addresses the single comment that we= received during working group last call, which was to remove some redundan= t definitions from the terminology section. Jon -----Original Message----- From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.o= rg Sent: 02 April 2014 10:20 To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-pcep-mib-08.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Path Computation Element Working Group of= the IETF. Title : Path Computation Element Protocol (PCEP) Manageme= nt Information Base Authors : A S Kiran Koushik Emile Stephan Quintin Zhao Daniel King Jonathan Hardwick Filename : draft-ietf-pce-pcep-mib-08.txt Pages : 47 Date : 2014-04-02 Abstract: This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Path Computation Element communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-pcep-mib-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-pcep-mib-08 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From nobody Thu Apr 3 07:30:30 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3411A020E for ; Thu, 3 Apr 2014 07:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.894 X-Spam-Level: X-Spam-Status: No, score=-0.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, SPF_SOFTFAIL=0.665, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDfEME6swsMH for ; Thu, 3 Apr 2014 07:30:25 -0700 (PDT) Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id C43511A0211 for ; Thu, 3 Apr 2014 07:30:08 -0700 (PDT) Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C20D5DE4004 for ; Thu, 3 Apr 2014 16:31:46 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.orange.com (Postfix) with ESMTP id B5478DE4001 for ; Thu, 3 Apr 2014 16:31:46 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Apr 2014 16:30:02 +0200 Received: from [10.193.71.94] ([10.193.71.94]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Apr 2014 16:30:02 +0200 Message-ID: <533D7069.5030609@orange.com> Date: Thu, 03 Apr 2014 16:30:01 +0200 From: Julien Meuric Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: pce@ietf.org References: <20140206112220.911.91885.idtracker@ietfa.amsl.com> <013e01cf232e$d24a0d90$76de28b0$@olddog.co.uk> <268e01cf4162$c4d68fb0$4e83af10$@olddog.co.uk> <23CE718903A838468A8B325B80962F9B75548BAF@szxeml556-mbs.china.huawei.com> <277201cf41d5$b934d2c0$2b9e7840$@olddog.co.uk> <23CE718903A838468A8B325B80962F9B75548F62@szxeml556-mbs.china.huawei.com> <013201cf4297$c4021740$4c0645c0$@olddog.co.uk> In-Reply-To: <013201cf4297$c4021740$4c0645c0$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Apr 2014 14:30:02.0026 (UTC) FILETIME=[32C8C8A0:01CF4F49] Archived-At: http://mailarchive.ietf.org/arch/msg/pce/20feWRATMmapSnACK04wFzwNgyI Subject: Re: [Pce] Terminology for PCE-Initiated LSP (Was I-D Action: draft-ietf-pce-questions-02.txt) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 14:30:29 -0000 Hi all. This thread started to tackle an interesting issue. More feedback would have been much welcome. Let me try to rephrase. What we agree on: the WG (whatever its name) works on PCEP. What may be discussed: is a PCE defined as "a path computation function" or as "a deciding end of a PCEP session"? The former being defined in RFC 4655, I believe "splitting hairs" avoids ambiguity and moving forward with draft-ietf-pce-questions as it is would make no harm. If noone objects, we will soon start a WG LC. Back to the latter definition, we have started to identify this boundary by introducing the phrases "passive PCE" (i.e. legacy definition) and "active PCE". This looks like an oxymoron to refer to a "PCEP-based LSP coordinator", but PCE is growing up, it is no longer as small as it used to be. Confusion is there, but it is quite common for evolving technologies. Sometimes, I still struggle with some people who understand MPLS as LDP-signalled only and leave MPLS-TE out of MPLS; with some others to explain that an IGP-TE is not just a routing protocol but a TED synchronization mechanism... Bottom line: more than ever, we must make sure in our documents that the terms are correctly defined and put some effort in avoiding the ambiguity related to that vocabulary transition/extension. Alternate path: should we be able to get consensus on a less ambiguous term, we might search&replace all "active PCE" instances (the phrase is not RFC yet)... [Chair hat off] Most of the "accurate" phrases I could think of are too long to be successful, but I'm not a native speaker. Regards, Julien Mar. 18, 2014 - Adrian Farrel: > Dhruv, > How right you are: a decision is needed and the WG should discuss it. > > I suspect it will not help us to quote one draft or another, because we are > trying to converge on consensus from a variety of work-in-progress documents. > > *The* crunch from my perspective is whether a PCE is a provisioning source or > not. Please note that this is a very different question from whether PCEP can be > used as a provisioning protocol. > > RFC 4655 has: > PCE: Path Computation Element. An entity (component, application, or > network node) that is capable of computing a network path or route > based on a network graph and applying computational constraints. > > The debate, I suppose, is about whether we stick with that definition, or > broaden it. I would personally prefer to draw boxes around functional > components. Thus, from my point of view, what is being discussed is a variant of > Figure 5 from RFC 4655. In that variant, the PCE is a component of the NMS, and > the NMS uses PCEP as the service request protocol. This vision keeps the concept > of a PCE as a simple computation engine, and allows all of the rest of the > function as before. > > One might draw the following ASCII Art... > > > ----------------------------------- > | ------ ----- | > | NMS |LSP-DB| | TED |<-+-----------> > | / ------ ----- | TED synchronization > | -------------/ | | | mechanism (for example, > | | LSP | | | | routing protocol) > | | Coordinator | v v | > | | | -------------- | > | | |-| PCE | | > | ------------- -------------- | > | | | | > | --------------------------- | > | | PCEP Protocol Engine | | > | --------------------------- | > | | A | > | | | | > -------+-----+--------------------- > Provisioning | |Computation > Request | |Request/Response > V V > ---------- Signaling ---------- > | Head-End | Protocol | Adjacent | > | Node |<------------->| Node | > ---------- ---------- > > > Now, draft-ietf-pce-pce-initiated-lsp currently says... > > A PCC or PCE indicates its ability to support PCE provisioned dynamic > LSPs > > And I think this is a little confused. I think it is referring to the use of > PCEP for provisioning LSPs. > > Maybe I am splitting hairs, or maybe I am trying to ensure that new work remains > consistent with the architecture without preventing any of the new work. > > In my opinion the use of terms in the new work has conflated what we implement > and sell as a PCE (wonderful, glowing marketing term), and what the functional > components are. This debate as one of the primary reasons why I started > draft-ietf-pce-questions, so I would clearly like to see it resolved. > > Thanks, > Adrian > > > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Dhruv Dhody > Sent: 18 March 2014 06:24 > To:pce@ietf.org > Subject: [Pce] Terminology for PCE-Initiated LSP (Was I-D Action: > draft-ietf-pce-questions-02.txt) > > WG, > > Regarding PCE-Initiated LSP. > > (1)http://tools.ietf.org/html/draft-ietf-pce-questions-04#section-20 > use the term "suggest" or "recommend" LSP and considers "LSP Instantiation" as > out of scope. > > (2)http://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-00 > http://tools.ietf.org/html/draft-ali-pce-remote-initiated-gmpls-lsp-03 (WG -00 > yet to be posted) > http://tools.ietf.org/html/draft-palle-pce-stateful-pce-initiated-p2mp-lsp-01 > all use the term "LSP instantiation" for PCE-Initiated LSP. > > We need to come to some consensus regarding this and use the same terminology > across WG documents. > > Thoughts? > > Dhruv > > > --------------------------------------------------------------- > Dhruv Dhody > System Architect, > Huawei Technologies India Pvt. Ltd., > Banagalore > This e-mail and its attachments contain confidential information from HUAWEI, > which > is intended only for the person or entity whose address is listed above. Any use > of the > information contained herein in any way (including, but not limited to, total or > partial > disclosure, reproduction, or dissemination) by persons other than the intended > recipient(s) is prohibited. If you receive this e-mail in error, please notify > the sender by > phone or email immediately and delete it! > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: 17 March 2014 17:11 > To: Dhruv Dhody > Cc:pce@ietf.org; 'Dhruv Dhody' > Subject: RE: [Pce] I-D Action: draft-ietf-pce-questions-02.txt > > Sorry for the HTML, but I am hoping this thread can be closed soon. > > You're killing me :-) > Hoping you are not red/green colourblind. > > Look in line for [DD]. > > [Snipped to only the points for discussion] > > * Sec 5. How Do I Select Between PCEs? > Along with capability, you can also mention the PCE's preference for each > computation scope as carried in the PATH-SCOPE subtlv. > > You are going to have to remind me, I'm afraid. Where is the PATH-SCOPE subtlv > defined? > I suppose I was considering that a PCC is only going to choose a PCE in its own > domain, but I can add a note. > [DD] Its in RFC5088, 5089, the idea being PCC should select the PCE in its own > domain which matches with the path computation scope (inter-area, inter-AS, > inter-layer) along with the capability. > > Ah, ah, ah! I was busy thinking this was a PCEP sub-tlv. > > OLD: > When more then one PCE is discovered or configured, a PCC will need > to select which PCE to use. It may make this decision on any > arbitrary algorithm (for example, first-listed, or round-robin), but > it may also be the case that different PCEs have different > capabilities, in which case the PCC will want to select the PCE most > likely to be able to satisfy any one request. The first requirement, > of course, is that the PCE can compute paths for the relevant domain. > NEW: > When more than one PCE is discovered or configured, a PCC will need > to select which PCE to use. It may make this decision on any > arbitrary algorithm (for example, first-listed, or round-robin), but > it may also be the case that different PCEs have different > capabilities and path computation scope, in which case the PCC will > want to select the PCE most likely to be able to satisfy any one request. > The first requirement, of course, is that the PCE can compute paths for > the relevant domain. > > Yeah, OK for that. It duplicates the final sentence I added to this paragraph, > but it does no harm. > > * Sec 20. Comparison of Stateless and Stateful PCE > Can you have a re look at this wrt draft-ietf-pce-pce-initiated-lsp-00 is now a > WG draft. > > Mutter! > Which document is right? > What specific issue are you raising? > [DD]http://tools.ietf.org/html/draft-ietf-pce-questions-03#section-20 says > | Stateless | Stateful | > ------------------------+-----------+-----------+ > Passive | 1 | 2 | > Active delegated LSPs | 3 | 4 | > Active suggest new LSPs | 5 | 6 | > Active instantiate LSPs | 7 | 7 | > > 7. These modes are out of scope for PCE as currently described. > > Where does draft-ietf-pce-pce-initiated-lsp fits in, in my reading this was 7, > and thus I suggested it should not be out of scope. > If you agree, ignore below text. > > Otherwise we have some confusion over the terms. > IMO 'Suggest new LSP' was same as PCE sends an update message triggering setup > of a new LSP in MBB fashion. > 'Instantiate LSP' was PCE send an LSP initiate message to instantiate an LSP. > (7) > Maybe you can clarify what is your understanding of these terms. > > OK, the difference I am trying to arrive at is whether the Active PCE can > *require* the establishment of an LSP, or whether it is *suggesting* it. > > The difference is (IMHO) between an NMS or CLI that dictates what the LSR does, > and an Active PCE that requests the LSR to act. > More precisely, absent access controls, an LSR obeys the NMS, but an LSR can > implement policy to filter or modify requests from a PCE. > > I realise that this view might not be popular with implementers of Active PCEs, > but I think that they are failing to distinguish between the blob of code they > are writing and naming "Company Foo's most Excellent Active PCE", and the > architectural components. This, at least, is part of what I am trying to convey > in Section 19 of this document and in the ABNO document. > > The bottom line, I think, is that a PCE is not a provisioning tool, it is a path > computation element. The fact that PCEP is used as a provisioning protocol does > not make the thing that does the provisioning into a PCE. > > Of course, I don't want to go against consensus with this, but I do think it is > an important architectural principle. Thus, I have been looking for words that > suit both viewpoints... > > For an Active PCE to "suggest new LSPs" or to "recommend new LSPs" as described > in Sections 19 and 20 allows, IMHO, an LSR to have a policy that says "always do > what is recommended" and so achieving PCE-initiated LSPs. Yet, these words also > allow a policy of "look both ways before crossing the road" which fits more > closely with my world-view. > > >From my perspective "sending an update message to trigger setup of a new LSP in > MBB fashion" is no different from setting up any other LSP. First there was no > LSP, then there is one. So I think the distinction you are drawing doesn't work. > > I hope that explains my motivation, and I believe the words in the draft fit > this explanation. > > Cheers, > Adrian > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > From nobody Thu Apr 3 08:40:11 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216251A021B for ; Thu, 3 Apr 2014 08:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_NAIL=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdG7sLuinyZk for ; Thu, 3 Apr 2014 08:40:05 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 187231A01FA for ; Thu, 3 Apr 2014 08:40:03 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id rl12so1916977iec.8 for ; Thu, 03 Apr 2014 08:39:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=oXsBfU1qNe+aTDYncGQZUpyHf0akGhjmFHqj4jw/CDo=; b=uhWByMMq3Rg2e0ubyyDuWQE5H68XkPLikrtm3wJwTrwrl2InUTkPNVlvvwUHRFgJXB /JPt4XqK/WrJWm0YXRg1j3boIjA1lbnvEMIMWJAk+9DwGZJYHfdgjdGr2cf5/jz1Cscs 0/LIAvOhHPbiYzOYEfGGlE8JxYdKgiGLdCM5f/5xWXSC4+gDgsxkgy4mByRrujvsMW0w KW2RrblaZog8XJsuXcVxqHSPIH3jPiF55MN4Vt7GzZuMDB37LtYY78KIa46CVnxuTcfD jJC6okk9xCMfvG19SlVYhuubP/FElIW8jvJXlUE+gr5rFBujJ62ulBLeBPjELnnOuR0J EwUQ== MIME-Version: 1.0 X-Received: by 10.50.122.8 with SMTP id lo8mr16414007igb.31.1396539598732; Thu, 03 Apr 2014 08:39:58 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.118.42 with HTTP; Thu, 3 Apr 2014 08:39:58 -0700 (PDT) In-Reply-To: <533D7069.5030609@orange.com> References: <20140206112220.911.91885.idtracker@ietfa.amsl.com> <013e01cf232e$d24a0d90$76de28b0$@olddog.co.uk> <268e01cf4162$c4d68fb0$4e83af10$@olddog.co.uk> <23CE718903A838468A8B325B80962F9B75548BAF@szxeml556-mbs.china.huawei.com> <277201cf41d5$b934d2c0$2b9e7840$@olddog.co.uk> <23CE718903A838468A8B325B80962F9B75548F62@szxeml556-mbs.china.huawei.com> <013201cf4297$c4021740$4c0645c0$@olddog.co.uk> <533D7069.5030609@orange.com> Date: Thu, 3 Apr 2014 21:09:58 +0530 X-Google-Sender-Auth: JBleEGWiddJpV-qir-4mpvZt-p4 Message-ID: From: Dhruv Dhody To: Julien Meuric Content-Type: multipart/alternative; boundary=089e015384feb284d204f62536f4 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/sYuOogKTEMLBbcqGpLl1_JABg7U Cc: "pce@ietf.org" Subject: Re: [Pce] Terminology for PCE-Initiated LSP (Was I-D Action: draft-ietf-pce-questions-02.txt) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 15:40:10 -0000 --089e015384feb284d204f62536f4 Content-Type: text/plain; charset=ISO-8859-1 Hi Julien n All, (1) Considering the definition of active PCE as per http://tools.ietf.org/html/draft-ietf-pce-questions-04#section-17 An Active PCE is one that issues provisioning "recommendations" to the network. These recommendations may be new routes for existing LSPs, or routes for new LSPs. So active PCE allows delegation of LSP and PCE can make recommendations for new routes. Further it also can recommend routes for new LSP (i.e. PCE-Initiated LSP). IMO, so far this might be inline with other stateful I.D.s and would require just some minor tweak perhaps. So the first question to the WG would be - are we happy with these terms or should be find new ones as Julien suggested? (2) http://tools.ietf.org/html/draft-ietf-pce-questions-04#section-20 says 'instantiate' as out of scope. And PCE-Initiated I.D.s use the word 'instantiate' to mean "recommend new LSP". So the second question would be - whats a right term for this? I hope the word-smiths in the WG can come up with something that we can build consensus around. Regards, Dhruv On Thu, Apr 3, 2014 at 8:00 PM, Julien Meuric wrote: > Hi all. > > This thread started to tackle an interesting issue. More feedback would > have been much welcome. > > Let me try to rephrase. > What we agree on: the WG (whatever its name) works on PCEP. > What may be discussed: is a PCE defined as "a path computation function" > or as "a deciding end of a PCEP session"? > > The former being defined in RFC 4655, I believe "splitting hairs" avoids > ambiguity and moving forward with draft-ietf-pce-questions as it is would > make no harm. If noone objects, we will soon start a WG LC. > > Back to the latter definition, we have started to identify this boundary > by introducing the phrases "passive PCE" (i.e. legacy definition) and > "active PCE". This looks like an oxymoron to refer to a "PCEP-based LSP > coordinator", but PCE is growing up, it is no longer as small as it used to > be. Confusion is there, but it is quite common for evolving technologies. > Sometimes, I still struggle with some people who understand MPLS as > LDP-signalled only and leave MPLS-TE out of MPLS; with some others to > explain that an IGP-TE is not just a routing protocol but a TED > synchronization mechanism... > > Bottom line: more than ever, we must make sure in our documents that the > terms are correctly defined and put some effort in avoiding the ambiguity > related to that vocabulary transition/extension. > > Alternate path: should we be able to get consensus on a less ambiguous > term, we might search&replace all "active PCE" instances (the phrase is not > RFC yet)... > [Chair hat off] Most of the "accurate" phrases I could think of are too > long to be successful, but I'm not a native speaker. > > Regards, > > Julien > > > Mar. 18, 2014 - Adrian Farrel: > >> Dhruv, >> How right you are: a decision is needed and the WG should discuss it. >> >> I suspect it will not help us to quote one draft or another, because we >> are >> trying to converge on consensus from a variety of work-in-progress >> documents. >> >> *The* crunch from my perspective is whether a PCE is a provisioning >> source or >> not. Please note that this is a very different question from whether PCEP >> can be >> used as a provisioning protocol. >> >> RFC 4655 has: >> PCE: Path Computation Element. An entity (component, application, or >> network node) that is capable of computing a network path or route >> based on a network graph and applying computational constraints. >> >> The debate, I suppose, is about whether we stick with that definition, or >> broaden it. I would personally prefer to draw boxes around functional >> components. Thus, from my point of view, what is being discussed is a >> variant of >> Figure 5 from RFC 4655. In that variant, the PCE is a component of the >> NMS, and >> the NMS uses PCEP as the service request protocol. This vision keeps the >> concept >> of a PCE as a simple computation engine, and allows all of the rest of the >> function as before. >> >> One might draw the following ASCII Art... >> >> >> ----------------------------------- >> | ------ ----- | >> | NMS |LSP-DB| | TED |<-+-----------> >> | / ------ ----- | TED synchronization >> | -------------/ | | | mechanism (for example, >> | | LSP | | | | routing protocol) >> | | Coordinator | v v | >> | | | -------------- | >> | | |-| PCE | | >> | ------------- -------------- | >> | | | | >> | --------------------------- | >> | | PCEP Protocol Engine | | >> | --------------------------- | >> | | A | >> | | | | >> -------+-----+--------------------- >> Provisioning | |Computation >> Request | |Request/Response >> V V >> ---------- Signaling ---------- >> | Head-End | Protocol | Adjacent | >> | Node |<------------->| Node | >> ---------- ---------- >> >> >> Now, draft-ietf-pce-pce-initiated-lsp currently says... >> >> A PCC or PCE indicates its ability to support PCE provisioned dynamic >> LSPs >> >> And I think this is a little confused. I think it is referring to the use >> of >> PCEP for provisioning LSPs. >> >> Maybe I am splitting hairs, or maybe I am trying to ensure that new work >> remains >> consistent with the architecture without preventing any of the new work. >> >> In my opinion the use of terms in the new work has conflated what we >> implement >> and sell as a PCE (wonderful, glowing marketing term), and what the >> functional >> components are. This debate as one of the primary reasons why I started >> draft-ietf-pce-questions, so I would clearly like to see it resolved. >> >> Thanks, >> Adrian >> >> >> From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Dhruv Dhody >> Sent: 18 March 2014 06:24 >> To:pce@ietf.org >> Subject: [Pce] Terminology for PCE-Initiated LSP (Was I-D Action: >> draft-ietf-pce-questions-02.txt) >> >> WG, >> >> Regarding PCE-Initiated LSP. >> >> (1)http://tools.ietf.org/html/draft-ietf-pce-questions-04#section-20 >> >> use the term "suggest" or "recommend" LSP and considers "LSP >> Instantiation" as >> out of scope. >> >> (2)http://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-00 >> >> http://tools.ietf.org/html/draft-ali-pce-remote-initiated-gmpls-lsp-03 (WG -00 >> yet to be posted) >> http://tools.ietf.org/html/draft-palle-pce-stateful-pce- >> initiated-p2mp-lsp-01 >> all use the term "LSP instantiation" for PCE-Initiated LSP. >> >> We need to come to some consensus regarding this and use the same >> terminology >> across WG documents. >> >> Thoughts? >> >> Dhruv >> >> >> --------------------------------------------------------------- >> Dhruv Dhody >> System Architect, >> Huawei Technologies India Pvt. Ltd., >> Banagalore >> This e-mail and its attachments contain confidential information from >> HUAWEI, >> which >> is intended only for the person or entity whose address is listed above. >> Any use >> of the >> information contained herein in any way (including, but not limited to, >> total or >> partial >> disclosure, reproduction, or dissemination) by persons other than the >> intended >> recipient(s) is prohibited. If you receive this e-mail in error, please >> notify >> the sender by >> phone or email immediately and delete it! >> >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >> Sent: 17 March 2014 17:11 >> To: Dhruv Dhody >> Cc:pce@ietf.org; 'Dhruv Dhody' >> Subject: RE: [Pce] I-D Action: draft-ietf-pce-questions-02.txt >> >> Sorry for the HTML, but I am hoping this thread can be closed soon. >> >> >> You're killing me :-) >> Hoping you are not red/green colourblind. >> >> Look in line for [DD]. >> >> [Snipped to only the points for discussion] >> >> * Sec 5. How Do I Select Between PCEs? >> Along with capability, you can also mention the PCE's preference for each >> computation scope as carried in the PATH-SCOPE subtlv. >> >> You are going to have to remind me, I'm afraid. Where is the PATH-SCOPE >> subtlv >> defined? >> I suppose I was considering that a PCC is only going to choose a PCE in >> its own >> domain, but I can add a note. >> [DD] Its in RFC5088, 5089, the idea being PCC should select the PCE in >> its own >> domain which matches with the path computation scope (inter-area, >> inter-AS, >> inter-layer) along with the capability. >> >> Ah, ah, ah! I was busy thinking this was a PCEP sub-tlv. >> >> OLD: >> When more then one PCE is discovered or configured, a PCC will need >> to select which PCE to use. It may make this decision on any >> arbitrary algorithm (for example, first-listed, or round-robin), but >> it may also be the case that different PCEs have different >> capabilities, in which case the PCC will want to select the PCE most >> likely to be able to satisfy any one request. The first requirement, >> of course, is that the PCE can compute paths for the relevant >> domain. >> NEW: >> When more than one PCE is discovered or configured, a PCC will need >> to select which PCE to use. It may make this decision on any >> arbitrary algorithm (for example, first-listed, or round-robin), but >> it may also be the case that different PCEs have different >> capabilities and path computation scope, in which case the PCC will >> want to select the PCE most likely to be able to satisfy any one >> request. >> The first requirement, of course, is that the PCE can compute paths >> for >> the relevant domain. >> >> Yeah, OK for that. It duplicates the final sentence I added to this >> paragraph, >> but it does no harm. >> >> * Sec 20. Comparison of Stateless and Stateful PCE >> Can you have a re look at this wrt draft-ietf-pce-pce-initiated-lsp-00 >> is now a >> WG draft. >> >> Mutter! >> Which document is right? >> What specific issue are you raising? >> [DD]http://tools.ietf.org/html/draft-ietf-pce-questions-03#section-20 says >> | Stateless | Stateful | >> ------------------------+-----------+-----------+ >> Passive | 1 | 2 | >> Active delegated LSPs | 3 | 4 | >> Active suggest new LSPs | 5 | 6 | >> Active instantiate LSPs | 7 | 7 | >> >> 7. These modes are out of scope for PCE as currently described. >> >> Where does draft-ietf-pce-pce-initiated-lsp fits in, in my reading this >> was 7, >> and thus I suggested it should not be out of scope. >> If you agree, ignore below text. >> >> Otherwise we have some confusion over the terms. >> >> IMO 'Suggest new LSP' was same as PCE sends an update message triggering >> setup >> of a new LSP in MBB fashion. >> 'Instantiate LSP' was PCE send an LSP initiate message to instantiate an >> LSP. >> (7) >> Maybe you can clarify what is your understanding of these terms. >> >> >> OK, the difference I am trying to arrive at is whether the Active PCE can >> *require* the establishment of an LSP, or whether it is *suggesting* it. >> >> The difference is (IMHO) between an NMS or CLI that dictates what the LSR >> does, >> and an Active PCE that requests the LSR to act. >> More precisely, absent access controls, an LSR obeys the NMS, but an LSR >> can >> implement policy to filter or modify requests from a PCE. >> >> I realise that this view might not be popular with implementers of Active >> PCEs, >> but I think that they are failing to distinguish between the blob of code >> they >> are writing and naming "Company Foo's most Excellent Active PCE", and the >> architectural components. This, at least, is part of what I am trying to >> convey >> in Section 19 of this document and in the ABNO document. >> >> The bottom line, I think, is that a PCE is not a provisioning tool, it is >> a path >> computation element. The fact that PCEP is used as a provisioning >> protocol does >> not make the thing that does the provisioning into a PCE. >> >> Of course, I don't want to go against consensus with this, but I do think >> it is >> an important architectural principle. Thus, I have been looking for words >> that >> suit both viewpoints... >> >> For an Active PCE to "suggest new LSPs" or to "recommend new LSPs" as >> described >> in Sections 19 and 20 allows, IMHO, an LSR to have a policy that says >> "always do >> what is recommended" and so achieving PCE-initiated LSPs. Yet, these >> words also >> allow a policy of "look both ways before crossing the road" which fits >> more >> closely with my world-view. >> >> >From my perspective "sending an update message to trigger setup of a new >> LSP in >> MBB fashion" is no different from setting up any other LSP. First there >> was no >> LSP, then there is one. So I think the distinction you are drawing >> doesn't work. >> >> I hope that explains my motivation, and I believe the words in the draft >> fit >> this explanation. >> >> Cheers, >> Adrian >> >> _______________________________________________ >> Pce mailing list >> Pce@ietf.org >> https://www.ietf.org/mailman/listinfo/pce >> >> >> > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --089e015384feb284d204f62536f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Julien n All,

(1) Considering the definition of active PCE as per
http:= //tools.ietf.org/html/draft-ietf-pce-questions-04#section-17

<= pre style=3D"font-size:1em;margin-bottom:0px;margin-top:0px"> An Active P= CE is one that issues provisioning "recommendations" to the network. These recommendations may be new routes for existing LSPs, or routes for new LSPs.

So active PCE allows delegatio= n of LSP and PCE can make recommendations for new routes. Further it also c= an recommend routes for new LSP (i.e. PCE-Initiated LSP).=A0

IMO, so far this might be inline with other stateful I.D.s and would requi= re just some minor tweak perhaps.

So the first question to the WG would be - are we happy with these terms o= r should be find new ones as Julien suggested?

(2) http://tools.ietf.org/h= tml/draft-ietf-pce-questions-04#section-20
says 'instantiate' as out of scope.=A0

And PCE-Initiated I.D.s use the word 'instan= tiate' to mean "recommend new LSP".=A0
So the second q= uestion would be - whats a right term for this?=A0

I hope the word-smiths in the WG can come up with something that we ca= n build consensus=A0around.=A0
Regards,
Dhruv




On Thu, Apr 3, 2014 at 8:00 PM, Julien Meuri= c <julien.meuric@orange.com> wrote:
Hi all.

This thread started to tackle an interesting issue. More feedback would hav= e been much welcome.

Let me try to rephrase.
What we agree on: the WG (whatever its name) works on PCEP.
What may be discussed: is a PCE defined as "a path computation functio= n" or as "a deciding end of a PCEP session"?

The former being defined in RFC 4655, I believe "splitting hairs"= avoids ambiguity and moving forward with draft-ietf-pce-questions as it is= would make no harm. If noone objects, we will soon start a WG LC.

Back to the latter definition, we have started to identify this boundary by= introducing the phrases "passive PCE" (i.e. legacy definition) a= nd "active PCE". This looks like an oxymoron to refer to a "= PCEP-based LSP coordinator", but PCE is growing up, it is no longer as= small as it used to be. Confusion is there, but it is quite common for evo= lving technologies. Sometimes, I still struggle with some people who unders= tand MPLS as LDP-signalled only and leave MPLS-TE out of MPLS; with some ot= hers to explain that an IGP-TE is not just a routing protocol but a TED syn= chronization mechanism...

Bottom line: more than ever, we must make sure in our documents that the te= rms are correctly defined and put some effort in avoiding the ambiguity rel= ated to that vocabulary transition/extension.

Alternate path: should we be able to get consensus on a less ambiguous term= , we might search&replace all "active PCE" instances (the phr= ase is not RFC yet)...
[Chair hat off] Most of the "accurate" phrases I could think of a= re too long to be successful, but I'm not a native speaker.

Regards,

Julien


Mar. 18, 2014 - Adrian Farrel:
Dhruv,
How right you are: a decision is needed and the WG should discuss it.

I suspect it will not help us to quote one draft or another, because we are=
trying to converge on consensus from a variety of work-in-progress document= s.

*The* crunch from my perspective is whether a PCE is a provisioning source = or
not. Please note that this is a very different question from whether PCEP c= an be
used as a provisioning protocol.

RFC 4655 has:
=A0 =A0 PCE: Path Computation Element. =A0An entity (component, application= , or
=A0 =A0 network node) that is capable of computing a network path or route<= br> =A0 =A0 based on a network graph and applying computational constraints.
The debate, I suppose, is about whether we stick with that definition, or broaden it. I would personally prefer to draw boxes around functional
components. Thus, from my point of view, what is being discussed is a varia= nt of
Figure 5 from RFC 4655. In that variant, the PCE is a component of the NMS,= and
the NMS uses PCEP as the service request protocol. This vision keeps the co= ncept
of a PCE as a simple computation engine, and allows all of the rest of the<= br> function as before.

One might draw the following ASCII Art...

<font non-proportional>
=A0 =A0 =A0 =A0 =A0 -----------------------------------
=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0------ =A0 ----- = =A0 |
=A0 =A0 =A0 =A0 =A0| NMS =A0 =A0 =A0 =A0 =A0 =A0 |LSP-DB| | TED |<-+----= ------->
=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/ ------ =A0 ----- =A0 = | =A0TED synchronization
=A0 =A0 =A0 =A0 =A0| =A0-------------/ =A0 =A0| =A0 =A0 =A0 =A0| =A0 =A0 | = =A0mechanism (for example,
=A0 =A0 =A0 =A0 =A0| | LSP =A0 =A0 =A0 =A0 | =A0 =A0| =A0 =A0 =A0 =A0| =A0 = =A0 | =A0routing protocol)
=A0 =A0 =A0 =A0 =A0| | Coordinator | =A0 =A0v =A0 =A0 =A0 =A0v =A0 =A0 | =A0 =A0 =A0 =A0 =A0| | =A0 =A0 =A0 =A0 =A0 =A0 | =A0-------------- =A0 | =A0 =A0 =A0 =A0 =A0| | =A0 =A0 =A0 =A0 =A0 =A0 |-| =A0 =A0 PCE =A0 =A0 =A0|= =A0|
=A0 =A0 =A0 =A0 =A0| =A0------------- =A0 -------------- =A0 |
=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 = =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0| =A0 =A0--------------------------- =A0 =A0|
=A0 =A0 =A0 =A0 =A0| =A0 | =A0 =A0PCEP Protocol Engine =A0 | =A0 |
=A0 =A0 =A0 =A0 =A0| =A0 =A0--------------------------- =A0 =A0|
=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 | =A0 =A0 A =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 | =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0 -------+-----+---------------------
=A0 =A0 Provisioning | =A0 =A0 |Computation
=A0 =A0 =A0 =A0 =A0Request | =A0 =A0 |Request/Response
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0V =A0 =A0 V
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ---------- =A0 =A0Signaling =A0 =A0--------= --
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Head-End | =A0 Protocol =A0 =A0| Adjacent = |
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0Node =A0 =A0|<------------->| =A0= Node =A0 |
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ---------- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = ----------
</font>

Now, draft-ietf-pce-pce-initiated-lsp currently says...

=A0 =A0 A PCC or PCE indicates its ability to support PCE provisioned dynam= ic
=A0 =A0 LSPs

And I think this is a little confused. I think it is referring to the use o= f
PCEP for provisioning LSPs.

Maybe I am splitting hairs, or maybe I am trying to ensure that new work re= mains
consistent with the architecture without preventing any of the new work.
In my opinion the use of terms in the new work has conflated what we implem= ent
and sell as a PCE (wonderful, glowing marketing term), and what the functio= nal
components are. This debate as one of the primary reasons why I started
draft-ietf-pce-questions, so I would clearly like to see it resolved.

Thanks,
Adrian


From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Dhruv Dhody
Sent: 18 March 2014 06:24
To:pce@ietf.org<= br> Subject: [Pce] Terminology for PCE-Initiated LSP (Was I-D Action:
draft-ietf-pce-questions-02.txt)

WG,

Regarding PCE-Initiated LSP.

(1)http://tools.ietf.org/html/draft-ietf-pce-qu= estions-04#section-20

use the term "suggest" or "recommend" LSP and considers= "LSP Instantiation" as
out of scope.

(2)http://tools.ietf.org/html/draft-ietf-pce-pce-i= nitiated-lsp-00

http://tools.ietf.org/html/draft-ali-pce-r= emote-initiated-gmpls-lsp-03 =A0(WG -00
yet to be posted)
http://tools.ietf.org/html/draft-pa= lle-pce-stateful-pce-initiated-p2mp-lsp-01
all use the term "LSP instantiation" for PCE-Initiated LSP.

We need to come to some consensus regarding this and use the same terminolo= gy
across WG documents.

Thoughts?

Dhruv


-------------------------------------------------------------= --
Dhruv Dhody
System Architect,
Huawei Technologies India Pvt. Ltd.,
Banagalore
This e-mail and its attachments contain confidential information from HUAWE= I,
which
is intended only for the person or entity whose address is listed above. An= y use
of the
information contained herein in any way (including, but not limited to, tot= al or
partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify
the sender by
phone or email immediately and delete it!

From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: 17 March 2014 17:11
To: Dhruv Dhody
Cc:pce@ietf.org;= 'Dhruv Dhody'
Subject: RE: [Pce] I-D Action: draft-ietf-pce-questions-02.txt

Sorry for the HTML, but I am hoping this thread can be closed soon.


You're killing me :-)
Hoping you are not red/green colourblind.

Look in line for [DD].

[Snipped to only the points for discussion]

* Sec 5. =A0How Do I Select Between PCEs?
Along with capability, you can also mention the PCE's preference for ea= ch
computation scope as carried in the PATH-SCOPE subtlv.

You are going to have to remind me, I'm afraid. Where is the PATH-SCOPE= subtlv
defined?
I suppose I was considering that a PCC is only going to choose a PCE in its= own
domain, but I can add a note.
[DD] Its in RFC5088, 5089, the idea being PCC should select the PCE in its = own
domain which matches with the path computation scope (inter-area, inter-AS,=
inter-layer) along with the capability.

Ah, ah, ah! I was busy thinking this was a PCEP sub-tlv.

OLD:
=A0 =A0 When more then one PCE is discovered or configured, a PCC will need=
=A0 =A0 to select which PCE to use. =A0It may make this decision on any
=A0 =A0 arbitrary algorithm (for example, first-listed, or round-robin), bu= t
=A0 =A0 it may also be the case that different PCEs have different
=A0 =A0 capabilities, in which case the PCC will want to select the PCE mos= t
=A0 =A0 likely to be able to satisfy any one request. =A0The first requirem= ent,
=A0 =A0 =A0 of course, is that the PCE can compute paths for the relevant d= omain.
NEW:
=A0 =A0 When more than one PCE is discovered or configured, a PCC will need=
=A0 =A0 to select which PCE to use. =A0It may make this decision on any
=A0 =A0 arbitrary algorithm (for example, first-listed, or round-robin), bu= t
=A0 =A0 it may also be the case that different PCEs have different
=A0 =A0 capabilities and path computation scope, in which case the PCC will=
=A0 =A0 want to select the PCE most likely to be able to satisfy any one re= quest.
=A0 =A0 =A0 The first requirement, of course, is that the PCE can compute p= aths for
=A0 =A0 =A0 the relevant domain.

Yeah, OK for that. It duplicates the final sentence I added to this paragra= ph,
but it does no harm.

* Sec 20. =A0Comparison of Stateless and Stateful PCE
Can you have a re look at this wrt draft-ietf-pce-pce-initiated-lsp-= 00 is now a
WG draft.

Mutter!
Which document is right?
What specific issue are you raising?
[DD]http://tools.ietf.org/html/draft-ietf-pce-q= uestions-03#section-20 =A0says
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Stateless = | =A0Stateful |
=A0 =A0 =A0 =A0------------------------+-----------+-----------+
=A0 =A0 =A0 =A0Passive =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 1 =A0 =A0 = | =A0 =A0 2 =A0 =A0 |
=A0 =A0 =A0 =A0Active delegated LSPs =A0 | =A0 =A0 3 =A0 =A0 | =A0 =A0 4 = =A0 =A0 |
=A0 =A0 =A0 =A0Active suggest new LSPs | =A0 =A0 5 =A0 =A0 | =A0 =A0 6 =A0 = =A0 |
=A0 =A0 =A0 =A0 =A0Active instantiate LSPs | =A0 =A0 7 =A0 =A0 | =A0 =A0 7 = =A0 =A0 |

=A0 =A0 =A0 =A07. These modes are out of scope for PCE as currently describ= ed.

Where does draft-ietf-pce-pce-initiated-lsp fits in, in my reading t= his was 7,
and thus I suggested it should not be out of scope.
If you agree, ignore below text.

Otherwise we have some confusion over the terms.

IMO 'Suggest new LSP' was same as PCE sends an update message trigg= ering setup
of a new LSP in MBB fashion.
'Instantiate LSP' was PCE send an LSP initiate message to instantia= te an LSP.
(7)
Maybe you can clarify what is your understanding of these terms.
<= br>
OK, the difference I am trying to arrive at is whether the Active PCE can *require* the establishment of an LSP, or whether it is *suggesting* it.
The difference is (IMHO) between an NMS or CLI that dictates what the LSR d= oes,
and an Active PCE that requests the LSR to act.
More precisely, absent access controls, an LSR obeys the NMS, but an LSR ca= n
implement policy to filter or modify requests from a PCE.

I realise that this view might not be popular with implementers of Active P= CEs,
but I think that they are failing to distinguish between the blob of code t= hey
are writing and naming "Company Foo's most Excellent Active PCE&qu= ot;, and the
architectural components. =A0This, at least, is part of what I am trying to= convey
in Section 19 of this document and in the ABNO document.

The bottom line, I think, is that a PCE is not a provisioning tool, it is a= path
computation element. The fact that PCEP is used as a provisioning protocol = does
not make the thing that does the provisioning into a PCE.

Of course, I don't want to go against consensus with this, but I do thi= nk it is
an important architectural principle. Thus, I have been looking for words t= hat
suit both viewpoints...

For an Active PCE to "suggest new LSPs" or to "recommend new= LSPs" as described
in Sections 19 and 20 allows, IMHO, an LSR to have a policy that says "= ;always do
what is recommended" and so achieving PCE-initiated LSPs. Yet, these w= ords also
allow a policy of "look both ways before crossing the road" which= fits more
closely with my world-view.

>From my perspective "sending an update message to trigger setup of= a new LSP in
MBB fashion" is no different from setting up any other LSP. First ther= e was no
LSP, then there is one. So I think the distinction you are drawing doesn= 9;t work.

I hope that explains my motivation, and I believe the words in the draft fi= t
this explanation.

Cheers,
Adrian

_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce



_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce

--089e015384feb284d204f62536f4-- From nobody Thu Apr 3 09:42:54 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C071A0279 for ; Thu, 3 Apr 2014 09:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.599 X-Spam-Level: X-Spam-Status: No, score=-99.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_NAIL=2.3, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPtge2ieVndZ for ; Thu, 3 Apr 2014 09:42:45 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id A65311A0264 for ; Thu, 3 Apr 2014 09:42:44 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s33GgctA008054; Thu, 3 Apr 2014 17:42:38 +0100 Received: from 950129200 (16.17.90.92.rev.sfr.net [92.90.17.16]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s33GgYXg008043 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Apr 2014 17:42:36 +0100 From: "Adrian Farrel" To: "'Dhruv Dhody'" , "'Julien Meuric'" References: <20140206112220.911.91885.idtracker@ietfa.amsl.com> <013e01cf232e$d24a0d90$76de28b0$@olddog.co.uk> <268e01cf4162$c4d68fb0$4e83af10$@olddog.co.uk> <23CE718903A838468A8B325B80962F9B75548BAF@szxeml556-mbs.china.huawei.com> <277201cf41d5$b934d2c0$2b9e7840$@olddog.co.uk> <23CE718903A838468A8B325B80962F9B75548F62@szxeml556-mbs.china.huawei.com> <013201cf4297$c4021740$4c0645c0$@olddog.co.uk> <533D7069.5030609@orange.com> In-Reply-To: Date: Thu, 3 Apr 2014 17:42:35 +0100 Message-ID: <082301cf4f5b$b91b0e10$2b512a30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0824_01CF4F64.1AE98830" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNBTAKt13E+qb+7zl793QfaTCZ0wQHZAZ2OAhNqv0oB1xANVQJi0xgoAXB+QJACn46nhQGepni7AjKPMKwCKau5X5eKlNLQ Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20606.007 X-TM-AS-Result: No--31.653-10.0-31-10 X-imss-scan-details: No--31.653-10.0-31-10 X-TMASE-MatchedRID: 8lMhm884qkpDZFBd1jLr/nNpNmoJ1zd8MhomkrNJ+uz+TXZJvYxoeYG4 sPPOSZLXHBbGdKu0UXwUQEIP1jeXd/nVY0DWsTq3lY5qr7f6fHKWesyrtKuK7Rfu/zSku+UH4P2 k6c8cDOHoGyTzvJHCOSA6R/kVmVMpEXIhhl7oVxIM+FbAnNWFvtMGD8JuBXZP/ZNsWvQIY4M6C4 MpibDzzuKzKQac9nHQHnzehKaulgE6q0cNvkl2ilPjo7D4SFg4gdhI7ndNtOBZps+y1VXzqe2Wg 0dzNDgaI437g5q8nH/oiR7ArEMjXbqO765EzZu1B05B1LT2M8Vb2iL0xnz/Er/tumWFs8JCGqKm 6RGTPi47sj8n3TZO4HaFn7IXJICPAM0/G7XUdePThGbP9qB93B4O5NdyuOuyAVscD1Oo0tB9DdP rf+FnXyO/Xbfv9pr0riRGsgh/X+KjG/WUQM0mI4lD2T5imTkJQa2sDHLkQ06RfqKA4oV+e0g9oI El5+XgUr9+KuqT2Tp+5yQvmkVO2kzKND1XrU3IWZbr7hxHnYR+RK30aqYpVVS+oHmj8upzhGNvq r32yUnpzR7lEeZYS8GZkRlrbOdcVjg+8PDYqGOPmEs8Jfdl0+gaAT0y0CV6VL0StfkdQ2LvIn0Q 5i5coDxO6D+LeXIcVJEx4ytxQeKHKD8u15Oop+J28KqpjndpjOOSc4z5Qmio+b+yOP0oGHL58xe MnljGBLmjugkj0SOoSEEfveL5m4vyjdRKrHFa5qhand0wQAMhauGyjTkf9f3y7vT+lH0aZ473Qv y05nrta0YB2m0CKUUxj2KvNFNZ9pdQnl+Y9F+eAiCmPx4NwGmRqNBHmBvevqq8s2MNhPDPPeN6H N6d7BvN55cjuhyzbdTuPa9VRGsj80Za3RRg8Ajhadazkcdq6Tn6Ujzzx2+J6bFL9JduXaEwJcM/ YtqK4JuxhNWpcyM= Archived-At: http://mailarchive.ietf.org/arch/msg/pce/5SOLRMB9wwcLjEV7l6wbmdUewrQ Cc: pce@ietf.org Subject: Re: [Pce] Terminology for PCE-Initiated LSP (Was I-D Action: draft-ietf-pce-questions-02.txt) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 16:42:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0824_01CF4F64.1AE98830 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Nice summary, Dhruv. The reason why I didn't like "instantiate" was because it conveys (to me) more force than "recommendation." Of course "recommend instantiation" might be fine, and we could use it in both documents. Adrian From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Dhruv Dhody Sent: 03 April 2014 16:40 To: Julien Meuric Cc: pce@ietf.org Subject: Re: [Pce] Terminology for PCE-Initiated LSP (Was I-D Action: draft-ietf-pce-questions-02.txt) Hi Julien n All, (1) Considering the definition of active PCE as per http://tools.ietf.org/html/draft-ietf-pce-questions-04#section-17 An Active PCE is one that issues provisioning "recommendations" to the network. These recommendations may be new routes for existing LSPs, or routes for new LSPs. So active PCE allows delegation of LSP and PCE can make recommendations for new routes. Further it also can recommend routes for new LSP (i.e. PCE-Initiated LSP). IMO, so far this might be inline with other stateful I.D.s and would require just some minor tweak perhaps. So the first question to the WG would be - are we happy with these terms or should be find new ones as Julien suggested? (2) http://tools.ietf.org/html/draft-ietf-pce-questions-04#section-20 says 'instantiate' as out of scope. And PCE-Initiated I.D.s use the word 'instantiate' to mean "recommend new LSP". So the second question would be - whats a right term for this? I hope the word-smiths in the WG can come up with something that we can build consensus around. Regards, Dhruv On Thu, Apr 3, 2014 at 8:00 PM, Julien Meuric wrote: Hi all. This thread started to tackle an interesting issue. More feedback would have been much welcome. Let me try to rephrase. What we agree on: the WG (whatever its name) works on PCEP. What may be discussed: is a PCE defined as "a path computation function" or as "a deciding end of a PCEP session"? The former being defined in RFC 4655, I believe "splitting hairs" avoids ambiguity and moving forward with draft-ietf-pce-questions as it is would make no harm. If noone objects, we will soon start a WG LC. Back to the latter definition, we have started to identify this boundary by introducing the phrases "passive PCE" (i.e. legacy definition) and "active PCE". This looks like an oxymoron to refer to a "PCEP-based LSP coordinator", but PCE is growing up, it is no longer as small as it used to be. Confusion is there, but it is quite common for evolving technologies. Sometimes, I still struggle with some people who understand MPLS as LDP-signalled only and leave MPLS-TE out of MPLS; with some others to explain that an IGP-TE is not just a routing protocol but a TED synchronization mechanism... Bottom line: more than ever, we must make sure in our documents that the terms are correctly defined and put some effort in avoiding the ambiguity related to that vocabulary transition/extension. Alternate path: should we be able to get consensus on a less ambiguous term, we might search&replace all "active PCE" instances (the phrase is not RFC yet)... [Chair hat off] Most of the "accurate" phrases I could think of are too long to be successful, but I'm not a native speaker. Regards, Julien Mar. 18, 2014 - Adrian Farrel: Dhruv, How right you are: a decision is needed and the WG should discuss it. I suspect it will not help us to quote one draft or another, because we are trying to converge on consensus from a variety of work-in-progress documents. *The* crunch from my perspective is whether a PCE is a provisioning source or not. Please note that this is a very different question from whether PCEP can be used as a provisioning protocol. RFC 4655 has: PCE: Path Computation Element. An entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints. The debate, I suppose, is about whether we stick with that definition, or broaden it. I would personally prefer to draw boxes around functional components. Thus, from my point of view, what is being discussed is a variant of Figure 5 from RFC 4655. In that variant, the PCE is a component of the NMS, and the NMS uses PCEP as the service request protocol. This vision keeps the concept of a PCE as a simple computation engine, and allows all of the rest of the function as before. One might draw the following ASCII Art... ----------------------------------- | ------ ----- | | NMS |LSP-DB| | TED |<-+-----------> | / ------ ----- | TED synchronization | -------------/ | | | mechanism (for example, | | LSP | | | | routing protocol) | | Coordinator | v v | | | | -------------- | | | |-| PCE | | | ------------- -------------- | | | | | | --------------------------- | | | PCEP Protocol Engine | | | --------------------------- | | | A | | | | | -------+-----+--------------------- Provisioning | |Computation Request | |Request/Response V V ---------- Signaling ---------- | Head-End | Protocol | Adjacent | | Node |<------------->| Node | ---------- ---------- Now, draft-ietf-pce-pce-initiated-lsp currently says... A PCC or PCE indicates its ability to support PCE provisioned dynamic LSPs And I think this is a little confused. I think it is referring to the use of PCEP for provisioning LSPs. Maybe I am splitting hairs, or maybe I am trying to ensure that new work remains consistent with the architecture without preventing any of the new work. In my opinion the use of terms in the new work has conflated what we implement and sell as a PCE (wonderful, glowing marketing term), and what the functional components are. This debate as one of the primary reasons why I started draft-ietf-pce-questions, so I would clearly like to see it resolved. Thanks, Adrian From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Dhruv Dhody Sent: 18 March 2014 06:24 To:pce@ietf.org Subject: [Pce] Terminology for PCE-Initiated LSP (Was I-D Action: draft-ietf-pce-questions-02.txt) WG, Regarding PCE-Initiated LSP. (1)http://tools.ietf.org/html/draft-ietf-pce-questions-04#section-20 use the term "suggest" or "recommend" LSP and considers "LSP Instantiation" as out of scope. (2)http://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-00 http://tools.ietf.org/html/draft-ali-pce-remote-initiated-gmpls-lsp-03 (WG -00 yet to be posted) http://tools.ietf.org/html/draft-palle-pce-stateful-pce-initiated-p2mp-lsp-01 all use the term "LSP instantiation" for PCE-Initiated LSP. We need to come to some consensus regarding this and use the same terminology across WG documents. Thoughts? Dhruv --------------------------------------------------------------- Dhruv Dhody System Architect, Huawei Technologies India Pvt. Ltd., Banagalore This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: 17 March 2014 17:11 To: Dhruv Dhody Cc:pce@ietf.org ; 'Dhruv Dhody' Subject: RE: [Pce] I-D Action: draft-ietf-pce-questions-02.txt Sorry for the HTML, but I am hoping this thread can be closed soon. You're killing me :-) Hoping you are not red/green colourblind. Look in line for [DD]. [Snipped to only the points for discussion] * Sec 5. How Do I Select Between PCEs? Along with capability, you can also mention the PCE's preference for each computation scope as carried in the PATH-SCOPE subtlv. You are going to have to remind me, I'm afraid. Where is the PATH-SCOPE subtlv defined? I suppose I was considering that a PCC is only going to choose a PCE in its own domain, but I can add a note. [DD] Its in RFC5088, 5089, the idea being PCC should select the PCE in its own domain which matches with the path computation scope (inter-area, inter-AS, inter-layer) along with the capability. Ah, ah, ah! I was busy thinking this was a PCEP sub-tlv. OLD: When more then one PCE is discovered or configured, a PCC will need to select which PCE to use. It may make this decision on any arbitrary algorithm (for example, first-listed, or round-robin), but it may also be the case that different PCEs have different capabilities, in which case the PCC will want to select the PCE most likely to be able to satisfy any one request. The first requirement, of course, is that the PCE can compute paths for the relevant domain. NEW: When more than one PCE is discovered or configured, a PCC will need to select which PCE to use. It may make this decision on any arbitrary algorithm (for example, first-listed, or round-robin), but it may also be the case that different PCEs have different capabilities and path computation scope, in which case the PCC will want to select the PCE most likely to be able to satisfy any one request. The first requirement, of course, is that the PCE can compute paths for the relevant domain. Yeah, OK for that. It duplicates the final sentence I added to this paragraph, but it does no harm. * Sec 20. Comparison of Stateless and Stateful PCE Can you have a re look at this wrt draft-ietf-pce-pce-initiated-lsp-00 is now a WG draft. Mutter! Which document is right? What specific issue are you raising? [DD]http://tools.ietf.org/html/draft-ietf-pce-questions-03#section-20 says | Stateless | Stateful | ------------------------+-----------+-----------+ Passive | 1 | 2 | Active delegated LSPs | 3 | 4 | Active suggest new LSPs | 5 | 6 | Active instantiate LSPs | 7 | 7 | 7. These modes are out of scope for PCE as currently described. Where does draft-ietf-pce-pce-initiated-lsp fits in, in my reading this was 7, and thus I suggested it should not be out of scope. If you agree, ignore below text. Otherwise we have some confusion over the terms. IMO 'Suggest new LSP' was same as PCE sends an update message triggering setup of a new LSP in MBB fashion. 'Instantiate LSP' was PCE send an LSP initiate message to instantiate an LSP. (7) Maybe you can clarify what is your understanding of these terms. OK, the difference I am trying to arrive at is whether the Active PCE can *require* the establishment of an LSP, or whether it is *suggesting* it. The difference is (IMHO) between an NMS or CLI that dictates what the LSR does, and an Active PCE that requests the LSR to act. More precisely, absent access controls, an LSR obeys the NMS, but an LSR can implement policy to filter or modify requests from a PCE. I realise that this view might not be popular with implementers of Active PCEs, but I think that they are failing to distinguish between the blob of code they are writing and naming "Company Foo's most Excellent Active PCE", and the architectural components. This, at least, is part of what I am trying to convey in Section 19 of this document and in the ABNO document. The bottom line, I think, is that a PCE is not a provisioning tool, it is a path computation element. The fact that PCEP is used as a provisioning protocol does not make the thing that does the provisioning into a PCE. Of course, I don't want to go against consensus with this, but I do think it is an important architectural principle. Thus, I have been looking for words that suit both viewpoints... For an Active PCE to "suggest new LSPs" or to "recommend new LSPs" as described in Sections 19 and 20 allows, IMHO, an LSR to have a policy that says "always do what is recommended" and so achieving PCE-initiated LSPs. Yet, these words also allow a policy of "look both ways before crossing the road" which fits more closely with my world-view. >From my perspective "sending an update message to trigger setup of a new LSP in MBB fashion" is no different from setting up any other LSP. First there was no LSP, then there is one. So I think the distinction you are drawing doesn't work. I hope that explains my motivation, and I believe the words in the draft fit this explanation. Cheers, Adrian _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce ------=_NextPart_000_0824_01CF4F64.1AE98830 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nice summary, = Dhruv.

 

The reason why I didn't like = "instantiate" was because it conveys (to me) more force than = "recommendation."

 

Of course "recommend = instantiation" might be fine, and we could use it in both = documents.

 

Adrian

 

From: Pce = [mailto:pce-bounces@ietf.org] On Behalf Of Dhruv = Dhody
Sent: 03 April 2014 16:40
To: Julien = Meuric
Cc: pce@ietf.org
Subject: Re: [Pce] = Terminology for PCE-Initiated LSP (Was I-D Action: = draft-ietf-pce-questions-02.txt)

 

Hi Julien n = All,

 

(1) Considering the definition of = active PCE as per

 

   =
An Active PCE is one that issues provisioning =
"recommendations" to
   =
the network.  These =
recommendations may be new routes for =
existing
   =
LSPs, or routes for new =
LSPs.

 

So active = PCE allows delegation of LSP and PCE can make recommendations for new = routes. Further it also can recommend routes for new LSP (i.e. = PCE-Initiated LSP). 

 

IMO, so far = this might be inline with other stateful I.D.s and would require just = some minor tweak perhaps.

 

So the first = question to the WG would be - are we happy with these terms or should be = find new ones as Julien suggested?

 

says 'instantiate' as out of = scope. 

 

And = PCE-Initiated I.D.s use the word 'instantiate' to mean "recommend = new LSP". 

So the = second question would be - whats a right term for = this? 

 

I hope the = word-smiths in the WG can come up with something that we can build = consensus around. 

 

Regards,

Dhruv

 

 

 

On Thu, Apr 3, 2014 at 8:00 PM, Julien Meuric <julien.meuric@orange.com> = wrote:

Hi all.

This thread = started to tackle an interesting issue. More feedback would have been = much welcome.

Let me try to rephrase.
What we agree on: the WG = (whatever its name) works on PCEP.
What may be discussed: is a PCE = defined as "a path computation function" or as "a = deciding end of a PCEP session"?

The former being defined in = RFC 4655, I believe "splitting hairs" avoids ambiguity and = moving forward with draft-ietf-pce-questions as it is would make no = harm. If noone objects, we will soon start a WG LC.

Back to the = latter definition, we have started to identify this boundary by = introducing the phrases "passive PCE" (i.e. legacy definition) = and "active PCE". This looks like an oxymoron to refer to a = "PCEP-based LSP coordinator", but PCE is growing up, it is no = longer as small as it used to be. Confusion is there, but it is quite = common for evolving technologies. Sometimes, I still struggle with some = people who understand MPLS as LDP-signalled only and leave MPLS-TE out = of MPLS; with some others to explain that an IGP-TE is not just a = routing protocol but a TED synchronization mechanism...

Bottom = line: more than ever, we must make sure in our documents that the terms = are correctly defined and put some effort in avoiding the ambiguity = related to that vocabulary transition/extension.

Alternate path: = should we be able to get consensus on a less ambiguous term, we might = search&replace all "active PCE" instances (the phrase is = not RFC yet)...
[Chair hat off] Most of the "accurate" = phrases I could think of are too long to be successful, but I'm not a = native speaker.

Regards,

Julien


Mar. 18, 2014 - = Adrian Farrel:

Dhruv,
How right you are: a decision = is needed and the WG should discuss it.

I suspect it will not = help us to quote one draft or another, because we are
trying to = converge on consensus from a variety of work-in-progress = documents.

*The* crunch from my perspective is whether a PCE is a = provisioning source or
not. Please note that this is a very different = question from whether PCEP can be
used as a provisioning = protocol.

RFC 4655 has:
    PCE: Path Computation = Element.  An entity (component, application, or
    = network node) that is capable of computing a network path or = route
    based on a network graph and applying = computational constraints.

The debate, I suppose, is about = whether we stick with that definition, or
broaden it. I would = personally prefer to draw boxes around functional
components. Thus, = from my point of view, what is being discussed is a variant of
Figure = 5 from RFC 4655. In that variant, the PCE is a component of the NMS, = and
the NMS uses PCEP as the service request protocol. This vision = keeps the concept
of a PCE as a simple computation engine, and allows = all of the rest of the
function as before.

One might draw the = following ASCII Art...

<font non-proportional>
  =         = -----------------------------------
        =  |                 =  ------   -----   |
        =  | NMS             |LSP-DB| | TED = |<-+----------->
         |   =              / ------   ----- =   |  TED synchronization
        =  |  -------------/    |        | =     |  mechanism (for example,
      =    | | LSP         |    |   =      |     |  routing protocol)
  =        | | Coordinator |    v   =      v     |
        =  | |             | =  --------------   |
         | | =             |-|     PCE   =    |  |
         | =  -------------   --------------   |
    =      |         |       =         |         |
  =        |    --------------------------- =    |
         |   |   =  PCEP Protocol Engine   |   |
      =    |    ---------------------------   =  |
         |       | =     A                 =     |
         |     =   |     |             =         |
          = -------+-----+---------------------
    Provisioning | =     |Computation
         Request = |     |Request/Response
          =        V     V
      =           ----------    Signaling =    ----------
            =    | Head-End |   Protocol    | Adjacent = |
               |  Node =    |<------------->|   Node   |
  =               ----------   =               = ----------
</font>

Now, draft-ietf-pce-pce-initiated-lsp = currently says...

    A PCC or PCE indicates its = ability to support PCE provisioned dynamic
    = LSPs

And I think this is a little confused. I think it is = referring to the use of
PCEP for provisioning LSPs.

Maybe I am = splitting hairs, or maybe I am trying to ensure that new work = remains
consistent with the architecture without preventing any of = the new work.

In my opinion the use of terms in the new work has = conflated what we implement
and sell as a PCE (wonderful, glowing = marketing term), and what the functional
components are. This debate = as one of the primary reasons why I started
draft-ietf-pce-questions, = so I would clearly like to see it = resolved.

Thanks,
Adrian


From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Dhruv = Dhody
Sent: 18 March 2014 06:24
To:pce@ietf.org
Subject: [Pce] Terminology for = PCE-Initiated LSP (Was I-D = Action:
draft-ietf-pce-questions-02.txt)

WG,

Regarding PCE-Initiated LSP.

(1)http://tools.ietf.org/html/draft-ietf-pce-questions-04#= section-20


use the term "suggest" or = "recommend" LSP and considers "LSP Instantiation" = as
out of scope.

(2)http://tools.ietf.org/html/draft-ietf-pce-pce-initiated= -lsp-00


http://tools.ietf.org/html/draft-ali-pce-remote-initiat= ed-gmpls-lsp-03  (WG -00
yet to be posted)
http://tools.ietf.org/html/draft-palle-pce-stateful-pce= -initiated-p2mp-lsp-01
all use the term "LSP = instantiation" for PCE-Initiated LSP.

We need to come to = some consensus regarding this and use the same terminology
across WG = documents.

Thoughts?

Dhruv


---------------------= ------------------------------------------
Dhruv Dhody
System = Architect,
Huawei Technologies India Pvt. Ltd.,
Banagalore
This = e-mail and its attachments contain confidential information from = HUAWEI,
which
is intended only for the person or entity whose = address is listed above. Any use
of the
information contained = herein in any way (including, but not limited to, total = or
partial
disclosure, reproduction, or dissemination) by persons = other than the intended
recipient(s) is prohibited. If you receive = this e-mail in error, please notify
the sender by
phone or email = immediately and delete it!

From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: 17 March 2014 = 17:11
To: Dhruv Dhody
Cc:pce@ietf.org; 'Dhruv Dhody'
Subject: RE: = [Pce] I-D Action: = draft-ietf-pce-questions-02.txt

Sorry for the HTML, but I am hoping this thread can be = closed soon.



You're = killing me :-)
Hoping you are not red/green colourblind.

Look = in line for [DD].

[Snipped to only the points for = discussion]

* Sec 5.  How Do I Select Between PCEs?
Along = with capability, you can also mention the PCE's preference for = each
computation scope as carried in the PATH-SCOPE = subtlv.

You are going to have to remind me, I'm afraid. Where is = the PATH-SCOPE subtlv
defined?
I suppose I was considering that a = PCC is only going to choose a PCE in its own
domain, but I can add a = note.
[DD] Its in RFC5088, 5089, the idea being PCC should select the = PCE in its own
domain which matches with the path computation scope = (inter-area, inter-AS,
inter-layer) along with the = capability.

Ah, ah, ah! I was busy thinking this was a PCEP = sub-tlv.

OLD:
    When more then one PCE is = discovered or configured, a PCC will need
    to select = which PCE to use.  It may make this decision on any
  =   arbitrary algorithm (for example, first-listed, or round-robin), = but
    it may also be the case that different PCEs have = different
    capabilities, in which case the PCC will want = to select the PCE most
    likely to be able to satisfy any = one request.  The first requirement,
      of = course, is that the PCE can compute paths for the relevant = domain.
NEW:
    When more than one PCE is discovered or = configured, a PCC will need
    to select which PCE to use. =  It may make this decision on any
    arbitrary = algorithm (for example, first-listed, or round-robin), but
  =   it may also be the case that different PCEs have = different
    capabilities and path computation scope, in = which case the PCC will
    want to select the PCE most = likely to be able to satisfy any one request.
      = The first requirement, of course, is that the PCE can compute paths = for
      the relevant domain.

Yeah, OK for = that. It duplicates the final sentence I added to this paragraph,
but = it does no harm.

* Sec 20.  Comparison of Stateless and = Stateful PCE
Can you have a re look at this wrt = draft-ietf-pce-pce-initiated-lsp-00 is now a
WG = draft.

Mutter!
Which document is right?
What specific issue = are you raising?
[DD]http://tools.ietf.org/html/draft-ietf-pce-questions-03#= section-20  says
            =                    | = Stateless |  Stateful |
      =  ------------------------+-----------+-----------+
    =    Passive               =   |     1     |     2     = |
       Active delegated LSPs   |   =   3     |     4     |
  =      Active suggest new LSPs |     5   =   |     6     |
        =  Active instantiate LSPs |     7     |   =   7     |

       7. These = modes are out of scope for PCE as currently described.

Where does = draft-ietf-pce-pce-initiated-lsp fits in, in my reading this was = 7,
and thus I suggested it should not be out of = scope.

If you agree, = ignore below text.

Otherwise we have some confusion over the = terms.


IMO 'Suggest new LSP' = was same as PCE sends an update message triggering setup
of a new LSP = in MBB fashion.
'Instantiate LSP' was PCE send an LSP initiate = message to instantiate an LSP.
(7)

Maybe you can clarify what is your understanding of = these terms.



OK, the difference I am trying to = arrive at is whether the Active PCE can
*require* the establishment = of an LSP, or whether it is *suggesting* it.

The difference is = (IMHO) between an NMS or CLI that dictates what the LSR does,
and an = Active PCE that requests the LSR to act.
More precisely, absent = access controls, an LSR obeys the NMS, but an LSR can
implement = policy to filter or modify requests from a PCE.

I realise that = this view might not be popular with implementers of Active PCEs,
but = I think that they are failing to distinguish between the blob of code = they
are writing and naming "Company Foo's most Excellent Active = PCE", and the
architectural components.  This, at least, is = part of what I am trying to convey
in Section 19 of this document and = in the ABNO document.

The bottom line, I think, is that a PCE is = not a provisioning tool, it is a path
computation element. The fact = that PCEP is used as a provisioning protocol does
not make the thing = that does the provisioning into a PCE.

Of course, I don't want to = go against consensus with this, but I do think it is
an important = architectural principle. Thus, I have been looking for words = that
suit both viewpoints...

For an Active PCE to = "suggest new LSPs" or to "recommend new LSPs" as = described
in Sections 19 and 20 allows, IMHO, an LSR to have a policy = that says "always do
what is recommended" and so achieving = PCE-initiated LSPs. Yet, these words also
allow a policy of = "look both ways before crossing the road" which fits = more
closely with my world-view.

>From my perspective = "sending an update message to trigger setup of a new LSP in
MBB = fashion" is no different from setting up any other LSP. First there = was no
LSP, then there is one. So I think the distinction you are = drawing doesn't work.

I hope that explains my motivation, and I = believe the words in the draft fit
this = explanation.

Cheers,
Adrian

____________________________= ___________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce


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

 

------=_NextPart_000_0824_01CF4F64.1AE98830-- From nobody Wed Apr 9 01:22:57 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F93F1A016F for ; Wed, 9 Apr 2014 01:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.544 X-Spam-Level: * X-Spam-Status: No, score=1.544 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.272, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhGTv34SZ49R for ; Wed, 9 Apr 2014 01:22:55 -0700 (PDT) Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 39F3C1A016B for ; Wed, 9 Apr 2014 01:22:55 -0700 (PDT) Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 41959DE4005 for ; Wed, 9 Apr 2014 10:24:37 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.orange.com (Postfix) with ESMTP id 341F9DE4003 for ; Wed, 9 Apr 2014 10:24:37 +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, 9 Apr 2014 10:22:52 +0200 Received: from [10.193.71.94] ([10.193.71.94]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Apr 2014 10:22:52 +0200 Message-ID: <5345035B.7080909@orange.com> Date: Wed, 09 Apr 2014 10:22:51 +0200 From: Julien Meuric Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "pce@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Apr 2014 08:22:52.0294 (UTC) FILETIME=[E684F260:01CF53CC] Archived-At: http://mailarchive.ietf.org/arch/msg/pce/NAeXupkHLfOsMJSkuudf4ziEaGw Subject: [Pce] WG Last Call for draft-ietf-pce-questions-04 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 08:22:56 -0000 Hi all. This message ignites a PCE WG last call on draft-ietf-pce-questions-04. It will end on Wednesday, April 23, 11:59 PM (UTC-12). Thanks, JP & Julien From nobody Wed Apr 9 09:23:16 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21A461A03B1 for ; Wed, 9 Apr 2014 09:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5pdW87Pql4T for ; Wed, 9 Apr 2014 09:23:11 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7591A03BD for ; Wed, 9 Apr 2014 09:23:04 -0700 (PDT) X-AuditID: c618062d-b7f948e000000b0c-9b-534571944d5b Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 74.90.02828.49175435; Wed, 9 Apr 2014 18:13:09 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Wed, 9 Apr 2014 12:23:03 -0400 From: Jeff Tantsura To: Julien Meuric , "pce@ietf.org" Thread-Topic: [Pce] WG Last Call for draft-ietf-pce-questions-04 Thread-Index: AQHPU8zwmqci68hvv0mKIKGu0uknKJsJRgyA Date: Wed, 9 Apr 2014 16:23:02 +0000 Message-ID: References: <5345035B.7080909@orange.com> In-Reply-To: <5345035B.7080909@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <987DAC6C349D724DB4F86EC11848F321@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyuXSPn+7UQtdgg62nmCz+nP7LZNF0/wa7 A5PHkiU/mTxanp1kC2CK4rJJSc3JLEst0rdL4MpoOLWEreAoS8X6aZPYGhgfMncxcnJICJhI /Jr5EcoWk7hwbz1bFyMXh5DAUUaJhXvmsEA4yxgltt99xwRSxSZgIPH/23EWEFtEwFvi27VH rCC2sIC9RPudr1BxB4ne+asYIWwjiZefr7GD2CwCKhLrfhwFm8MrYC4xZ94rMFtIQFPi6r45 YPWcAloSKw4cB7uIEeii76fWgNUwC4hL3HoynwniUgGJJXvOQ10tKvHy8T+wG0QF9CTuPZrL AhFXkpi09BwrRK+OxILdn9ggbGuJhRvbGCFsbYllC18zQ9wjKHFy5hOWCYzis5Csm4WkfRaS 9llI2mchaV/AyLqKkaO0OLUsN93IYBMjMK6OSbDp7mDc89LyEKM0B4uSOO+Xt85BQgLpiSWp 2ampBalF8UWlOanFhxiZODilGhh1t10zUffawe86Z/qf/MUVYm07tIu1p89JvlQq2Zm50bDa cvKbmf25lzb2rb9h6Hn2/QFn51VMFuvC/OoX/wwzs512y/PU4qC039oqlpJiulZpjaxtFYf1 LNie/FjdpaJx8c78D89yz3h/fMHysmTdxgdva1209glX53nk5uu+Wd3E8ehw23olluKMREMt 5qLiRABafX7ReQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/pce/g4u258XY8cyhBviQfl1HGSlrkEI Subject: Re: [Pce] WG Last Call for draft-ietf-pce-questions-04 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 16:23:15 -0000 Yes/support Cheers, Jeff -----Original Message----- From: Julien Meuric Organization: Orange Date: Wednesday, April 9, 2014 1:22 AM To: "pce@ietf.org" Subject: [Pce] WG Last Call for draft-ietf-pce-questions-04 >Hi all. > >This message ignites a PCE WG last call on draft-ietf-pce-questions-04. >It will end on Wednesday, April 23, 11:59 PM (UTC-12). > >Thanks, > >JP & Julien > >_______________________________________________ >Pce mailing list >Pce@ietf.org >https://www.ietf.org/mailman/listinfo/pce From nobody Wed Apr 9 09:29:02 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC231A03CA for ; Wed, 9 Apr 2014 09:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJ-a5IeY0N43 for ; Wed, 9 Apr 2014 09:29:00 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2D61A032E for ; Wed, 9 Apr 2014 09:29:00 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s39GSv7x019266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 Apr 2014 11:28:59 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s39GSv8G030135 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Apr 2014 18:28:57 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.139]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 9 Apr 2014 18:28:57 +0200 From: "BELOTTI, SERGIO (SERGIO)" To: Julien Meuric Thread-Topic: [Pce] WG Last Call for draft-ietf-pce-questions-04 Thread-Index: AQHPU8z1FsbY7LivDU+kUL6M2+/TtJsJedLQ Date: Wed, 9 Apr 2014 16:28:57 +0000 Message-ID: References: <5345035B.7080909@orange.com> In-Reply-To: <5345035B.7080909@orange.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/0Khy8xVOlz9vlWT7KzzFOe8-CLk Cc: "pce@ietf.org" Subject: Re: [Pce] WG Last Call for draft-ietf-pce-questions-04 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 16:29:01 -0000 Yes/support Best Regards Sergio -----Original Message----- From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Julien Meuric Sent: mercoled=EC 9 aprile 2014 10:23 To: pce@ietf.org Subject: [Pce] WG Last Call for draft-ietf-pce-questions-04 Hi all. This message ignites a PCE WG last call on draft-ietf-pce-questions-04.=20 It will end on Wednesday, April 23, 11:59 PM (UTC-12). Thanks, JP & Julien _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From nobody Wed Apr 9 17:01:42 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0891A03B3 for ; Wed, 9 Apr 2014 17:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.021 X-Spam-Level: X-Spam-Status: No, score=-97.021 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqHvUQfuGvWB for ; Wed, 9 Apr 2014 17:01:33 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id D21061A0118 for ; Wed, 9 Apr 2014 17:01:30 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id E0D2F1255346 for ; Thu, 10 Apr 2014 08:01:22 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 131EF177BF41; Thu, 10 Apr 2014 08:01:22 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s3A01NXD075111; Thu, 10 Apr 2014 08:01:23 +0800 (GMT-8) (envelope-from wang.qilei@zte.com.cn) In-Reply-To: <5345035B.7080909@orange.com> To: Julien Meuric MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: wang.qilei@zte.com.cn Date: Thu, 10 Apr 2014 08:01:18 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-04-10 08:01:18, Serialize complete at 2014-04-10 08:01:18 Content-Type: multipart/alternative; boundary="=_alternative 0000204848257CB6_=" X-MAIL: mse02.zte.com.cn s3A01NXD075111 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/SBoUocTJaStM-YLBdonjPsBnn1Y Cc: "pce@ietf.org" Subject: Re: [Pce] WG Last Call for draft-ietf-pce-questions-04 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 00:01:39 -0000 This is a multipart message in MIME format. --=_alternative 0000204848257CB6_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 eWVzL3N1cHBvcnQNCg0KVGhpcyBkcmFmdCBkbyBhbnN3ZXIgbWFueSBxdWVzaXRvbnMuDQoNClRo YW5rcw0KUWlsZWkgV2FuZw0KDQoNCg0KDQpKdWxpZW4gTWV1cmljIDxqdWxpZW4ubWV1cmljQG9y YW5nZS5jb20+IA0Kt6K8/sjLOiAgIlBjZSIgPHBjZS1ib3VuY2VzQGlldGYub3JnPg0KMjAxNC8w NC8wOSAxNjoyMg0KDQrK1bz+yMsNCiJwY2VAaWV0Zi5vcmciIDxwY2VAaWV0Zi5vcmc+DQqzrcvN DQoNCtb3zOINCltQY2VdIFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi1wY2UtcXVlc3Rpb25z LTA0DQoNCg0KDQoNCg0KDQpIaSBhbGwuDQoNClRoaXMgbWVzc2FnZSBpZ25pdGVzIGEgUENFIFdH IGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLXBjZS1xdWVzdGlvbnMtMDQuIA0KSXQgd2lsbCBlbmQg b24gV2VkbmVzZGF5LCBBcHJpbCAyMywgMTE6NTkgUE0gKFVUQy0xMikuDQoNClRoYW5rcywNCg0K SlAgJiBKdWxpZW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NClBjZSBtYWlsaW5nIGxpc3QNClBjZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9wY2UNCg0KDQo= --=_alternative 0000204848257CB6_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnllcy9zdXBwb3J0PC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGlzIGRyYWZ0IGRvIGFu c3dlciBtYW55IHF1ZXNpdG9ucy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPlRoYW5rczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+UWlsZWkgV2FuZzwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3 aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzYlPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj48Yj5KdWxpZW4gTWV1cmljICZsdDtqdWxpZW4ubWV1cmljQG9yYW5n ZS5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij63orz+yMs6ICZuYnNwOyZxdW90O1BjZSZxdW90OyAmbHQ7cGNlLWJvdW5jZXNAaWV0Zi5vcmcm Z3Q7PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTQvMDQvMDkg MTY6MjI8L2ZvbnQ+DQo8dGQgd2lkdGg9NjMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+JnF1b3Q7cGNlQGlldGYub3JnJnF1b3Q7ICZsdDtwY2VAaWV0Zi5vcmcmZ3Q7PC9mb250 Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W 98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5bUGNl XSBXRyBMYXN0IENhbGwgZm9yIGRyYWZ0LWlldGYtcGNlLXF1ZXN0aW9ucy0wNDwvZm9udD48L3Rh YmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4N Cjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+SGkgYWxsLjxi cj4NCjxicj4NClRoaXMgbWVzc2FnZSBpZ25pdGVzIGEgUENFIFdHIGxhc3QgY2FsbCBvbiBkcmFm dC1pZXRmLXBjZS1xdWVzdGlvbnMtMDQuDQo8YnI+DQpJdCB3aWxsIGVuZCBvbiBXZWRuZXNkYXks IEFwcmlsIDIzLCAxMTo1OSBQTSAoVVRDLTEyKS48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KPGJy Pg0KSlAgJmFtcDsgSnVsaWVuPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpQY2UgbWFpbGluZyBsaXN0PGJyPg0KUGNlQGlldGYu b3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY2U8YnI+DQo8 L3R0PjwvZm9udD4NCjxicj4NCg== --=_alternative 0000204848257CB6_=-- From nobody Mon Apr 14 00:04:27 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0CC61A0389 for ; Mon, 14 Apr 2014 00:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.2 X-Spam-Level: X-Spam-Status: No, score=-99.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crLL6N_jPvAu for ; Mon, 14 Apr 2014 00:04:23 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 683F41A00EA for ; Mon, 14 Apr 2014 00:04:23 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3E74Jgt004562 for ; Mon, 14 Apr 2014 08:04:19 +0100 Received: from 950129200 ([149.254.186.186]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3E73eOx004019 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 14 Apr 2014 08:04:02 +0100 From: "Adrian Farrel" To: References: <5345035B.7080909@orange.com> In-Reply-To: <5345035B.7080909@orange.com> Date: Mon, 14 Apr 2014 08:03:21 +0100 Message-ID: <002701cf57af$bb391f50$31ab5df0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG9hvfwSzX9RgkJtgoF+XF9nPjUPps0TxDw Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20630.005 X-TM-AS-Result: No--7.520-10.0-31-10 X-imss-scan-details: No--7.520-10.0-31-10 X-TMASE-MatchedRID: nVQUmLJJeyYzx9GDMr0HvzYTypjB3iDVEtdrY/Wb3fOelziUTGhiaikQ dD3vS/pCVdm0TceO+8Dn568UTWBqAHDTzBSSF/pz8eSmTJSmEv1R3sGN+j7mNAs0C/9ZMoH+0u5 faGP8ztTuq8ZwqBHyp5Ylxuk1ogQA+zoAW8R15l8c8J6ZrWP/q30tCKdnhB58vqq8s2MNhPB/KM EkOe61SFBIVsvVu9ABIAcCikR3vq8wH8xKqAkSOqwTkgemkLahAgd0NTbvSk9KCYvaLGcaDx/Sw a4t463A Archived-At: http://mailarchive.ietf.org/arch/msg/pce/BIaiRt3QNEjKxLeAs6_I4vkeQuY Subject: Re: [Pce] WG Last Call for draft-ietf-pce-questions-04 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 07:04:26 -0000 Thanks chairs, As part of the last call I would like to know whether we reached complete closure on the initiated/suggested LSP debate. I think the main protagonists would be the authors of draft-ietf-pce-pce-initiated-lsp and Dhruv who raised the issue in the first place. Thanks, Adrian > -----Original Message----- > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Julien Meuric > Sent: 09 April 2014 09:23 > To: pce@ietf.org > Subject: [Pce] WG Last Call for draft-ietf-pce-questions-04 > > Hi all. > > This message ignites a PCE WG last call on draft-ietf-pce-questions-04. > It will end on Wednesday, April 23, 11:59 PM (UTC-12). > > Thanks, > > JP & Julien > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From nobody Mon Apr 14 01:27:23 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C551A0293 for ; Mon, 14 Apr 2014 01:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.715 X-Spam-Level: *** X-Spam-Status: No, score=3.715 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PQ4opD4kab6 for ; Mon, 14 Apr 2014 01:27:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F2B191A0292 for ; Mon, 14 Apr 2014 01:27:18 -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.7-GA FastPath queued) with ESMTP id BFP38679; Mon, 14 Apr 2014 08:27:15 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 14 Apr 2014 09:25:56 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 14 Apr 2014 09:27:12 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Mon, 14 Apr 2014 16:27:05 +0800 From: Qin Wu To: Julien Meuric , "pce@ietf.org" Thread-Topic: [Pce] WG Last Call for draft-ietf-pce-questions-04 Thread-Index: AQHPU8z2+G2IwSoPaUi7GrqJfOEbyJsQyihA Date: Mon, 14 Apr 2014 08:27:05 +0000 Message-ID: References: <5345035B.7080909@orange.com> In-Reply-To: <5345035B.7080909@orange.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.114] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pce/gk--1GnevsxZQlYpt410JnWj2XA Subject: [Pce] =?gb2312?b?tPC4tDogIFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi1w?= =?gb2312?b?Y2UtcXVlc3Rpb25zLTA0?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 08:27:21 -0000 SGk6DQpJIGhhdmUgcmV2aWV3ZWQgZHJhZnQtaWV0Zi1wY2UtcXVlc3Rpb25zLTA0IGFuZCBoYWQg YSBmZXcgY29tbWVudHMgdG8gYmVsbG93cyA6DQoNCjEuIFNlY3Rpb24gMTksIHNlY29uZCBwYXJh Z3JhcGggc2F5czoNCiINCiAgIFRoZXJlIGlzIGEgc3VidGxlIGRpc3RpbmN0aW9uIGJldHdlZW4g YW4gTk1TIGFuZCBhbiBBY3RpdmUgUENFIHdpdGgNCiAgIExTUCBkZWxlZ2F0aW9uLiAgQW4gTk1T IGlzIGluIGNvbnRyb2wgb2YgdGhlIExTUHMgaW4gdGhlIG5ldHdvcmsgYW5kDQogICBjYW4gcmVx dWVzdCB0aGF0IHRoZXkgYXJlIHNldCB1cCwgbW9kaWZpZWQsIG9yIHRvcm4gZG93bi4gIEFuIEFj dGl2ZQ0KICAgUENFIGNhbiBvbmx5IG1ha2Ugc3VnZ2VzdGlvbnMgYWJvdXQgTFNQcyB0aGF0IGhh dmUgYmVlbiBkZWxlZ2F0ZWQgdG8NCiAgIHRoZSBQQ0UgYnkgYSBQQ0MgLg0KIg0KSXMgUENDIE5N UyBvciBMU1IgaGVhZGVuZD8gSWYgUENDIGlzIE5NUywgaXQgaXMgYSBsaXR0bGUgYml0IGNvbmZ1 c2luZyB0byBjb21wYXJlIEFjdGl2ZSBQQ0Ugd2l0aCBMU1AgZGVsZWdhdGlvbiB3aXRoIE5NUz8N Cg0KMi4gU2VjdGlvbiAyMCBzYXlzOg0KIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCBTdGF0ZWxlc3MgfCAgU3RhdGVmdWwgfA0KICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKw0KICAgICAgUGFzc2l2ZSAgICAgICAgICAgICAgICAg fCAgICAgMSAgICAgfCAgICAgMiAgICAgfA0KICAgICAgQWN0aXZlIGRlbGVnYXRlZCBMU1BzICAg fCAgICAgMyAgICAgfCAgICAgNCAgICAgfA0KICAgICAgQWN0aXZlIHN1Z2dlc3QgbmV3IExTUHMg fCAgICAgNSAgICAgfCAgICAgNiAgICAgfA0KICAgICAgQWN0aXZlIGluc3RhbnRpYXRlIExTUHMg fCAgICAgNyAgICAgfCAgICAgNyAgICAgfA0KIg0KV2hhdKGvcyB0aGUgZGlmZmVyZW5jZSBiZXR3 ZWVuIGRlbGVnYXRlZCBMU1AgYW5kIHN1Z2dlc3RlZCBuZXcgTFNQPyBXaGF0oa9zIHRoZSBkaWZm ZXJlbmNlIGJldHdlZW4gc3VnZ2VzdCBuZXcgTFNQIGFuZCBJbnN0YW50aWF0ZSBMU1BzPyBJcyBB Y3RpdmUgSW5zdGFudGlhdGUgTFNQcyByZWxhdGVkIHRvIFBDRSBpbml0aWF0ZWQgTFNQPw0KDQoz LiBTZWN0aW9uIDIyLCBsYXN0IGJ1bGxldCBzYXlzOg0KIg0KICAgICBUaGUgVk5UTSB3aWxsIG5l ZWQgdG8gaXNzdWUgcHJvdmlzaW9uaW5nIHJlcXVlc3RzL2NvbW1hbmRzICB0byB0aGUNCiAgICAg bG93ZXIgbGF5ZXIgbmV0d29ya3MgdG8gY2F1c2UgTFNQcyB0byBiZSBzZXQgdXAgdG8gYWN0IGFz IFRFIGxpbmtzDQogICAgIGluIHRoZSBoaWdoZXIgbGF5ZXIgbmV0d29yay4gIEEgbnVtYmVyIG9m IHBvdGVudGlhbCBwcm90b2NvbHMgZXhpc3QNCiAgICAgZm9yIHRoaXMgZnVuY3Rpb24gYXMgZGVz Y3JpYmVkIGluIFtJLUQuZmFycmtpbmdlbC1wY2UtYWJuby0NCiAgICAgYXJjaGl0ZWN0dXJlXSwg YnV0IGl0IHNob3VsZCBiZSBub3RlZCB0aGF0IGl0IG1ha2VzIGEgbG90IG9mIHNlbnNlDQogICAg IGZvciB0aGlzIGludGVyZmFjZSB0byBiZSB0aGUgc2FtZSBhcyB0aGF0IHVzZWQgYnkgYW4gQWN0 aXZlIFBDRQ0KICAgICB3aGVuIHByb3ZpZGluZyBwYXRocyB0byB0aGUgbmV0d29yay4NCiINCldo eSBWTlRNIHNob3VsZCBpc3N1ZSBwcm92aXNpb24gcmVxdWVzdD8gSXNuoa90IGl0IHRoZSBqb2Ig b2YgUHJvdmlzaW9uIG1hbmFnZXI/IE9yIFZOVE0gYXNrIFByb3Zpc2lvbiBtYW5hZ2VyIHRvIGlz c3VlIHByb3Zpc2lvbiByZXF1ZXN0Pw0KDQo0LiBTZWN0aW9uIDIzLCAybmQgcGFyYWdyYXBoDQpz L25ldHdvcmsgbm90ZS9uZXR3b3JrIG5vZGUNCg0KNS4gU2VjdGlvbiAyMywgM3JkIHBhcmFncmFw aCBzYXlzOg0KIg0KICAgQ29udmVyc2VseSwgYSBjZW50cmFsaXplZCBkYXRhYmFzZSBvZiByZXNv dXJjZXMgYW5kIExTUHMgc3VjaCBhcw0KICAgbWFpbnRhaW5lZCBieSBhIFN0YXRlZnVsIFBDRSBj YW4gYmUgZW5oYW5jZWQgd2l0aCBhIHRpbWUtYmFzZWQNCiAgIGJvb2tpbmcgc3lzdGVtLiAgIElm IHRoZSBQQ0UgaXMgYWxzbyBBY3RpdmUsIHRoZW4gd2hlbiB0aGUgdGltZSBjb21lcw0KICAgZm9y IHRoZSBMU1AgdG8gYmUgc2V0IHVwIChvciBsYXRlciwgd2hlbiBpdCBpcyB0byBiZSB0b3JuIGRv d24pIHRoZQ0KICAgUENFIGNhbiBjb250cm9sIHRoZSBuZXR3b3JrLg0KIg0KSXQgbG9va3MgdGhp cyBzZW50ZW5jZSBicmVha3MgYW5kIGNhbiBub3QgYmUgcGFyc2VkIGZyb20gobBhbmQgTFNQIHN1 Y2ggYXMgbWFpbnRhaW5lZCBieSBhIHN0YXRlZnVsIFBDRaGxDQpJdCBsb29rcyChsHN1Y2ggYXOh sSBuZWVkcyB0byBiZSByZW1vdmVkIG9yDQpzLyBhbmQgTFNQcyBzdWNoIGFzIG1haW50YWluZWQg Ynkvc3VjaCBhcyBMU1AgbWFpbnRhaW5lZCBieQ0KDQo2LiBTZWN0aW9uIDIzLCBsYXN0IHBhcmFn cmFwaCwgc2F5czoNCiINCiAgICBJdCBtYXkgYWxzbyBiZSBuZWNlc3NhcnkNCiAgIHRvIHJlcG9z aXRpb24gZXhpc3Rpbmcgb3IgcGxhbm5lZCBMU1BzICBhcyBuZXcgYm9va2luZ3MgYXJyaXZlLg0K ICAgRnVydGhlcm1vcmUsIHRoZSBib29raW5nIGRhdGFiYXNlIHRoYXQgY29udGFpbnMgYm90aCB0 aGUgc2NoZWR1bGVkDQogICBMU1BzIGFuZCB0aGVpciBpbXBhY3Qgb24gdGhlIG5ldHdvcmsgcmVz b3VyY2VzIGNhbiBiZWNvbWUgcXVpdGUNCiAgIGxhcmdlLg0KIg0KSXMgcGxhbm5lZCBMU1Agc2No ZWR1bGVkIExTUD8gSWYgbm90LCB0ZWxsIGRpZmZlcmVuY2UsIGlmIHllcywgbWFrZSBjb25zaXN0 ZW50Lg0KDQoNClJlZ2FyZHMhDQotUWluDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogUGNl IFttYWlsdG86cGNlLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gSnVsaWVuIE1ldXJpYw0Kt6LLzcqx vOQ6IDIwMTTE6jTUwjnI1SAxNjoyMw0KytW8/sjLOiBwY2VAaWV0Zi5vcmcNCtb3zOI6IFtQY2Vd IFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi1wY2UtcXVlc3Rpb25zLTA0DQoNCkhpIGFsbC4N Cg0KVGhpcyBtZXNzYWdlIGlnbml0ZXMgYSBQQ0UgV0cgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYt cGNlLXF1ZXN0aW9ucy0wNC4gDQpJdCB3aWxsIGVuZCBvbiBXZWRuZXNkYXksIEFwcmlsIDIzLCAx MTo1OSBQTSAoVVRDLTEyKS4NCg0KVGhhbmtzLA0KDQpKUCAmIEp1bGllbg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUGNlIG1haWxpbmcgbGlzdA0K UGNlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjZQ0K From nobody Mon Apr 14 06:58:16 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AADAB1A049D for ; Mon, 14 Apr 2014 06:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srYMEbwPlkGA for ; Mon, 14 Apr 2014 06:58:12 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 653EA1A049C for ; Mon, 14 Apr 2014 06:58:12 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id rd18so7868877iec.7 for ; Mon, 14 Apr 2014 06:58:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Jeajv9eL0beKAyX8LBNnCuO9hQDcJnlAXOtOek++3H4=; b=bL7Za178kKebk/WIZFukgzRphbTjh2tNEt6lk3QVa40pLwQUr2ZMoQVpLKc8E0qBs3 Rojm5ncreAg1BisvjSV7rLaU2IzdW7m1eAYXI1JyahJ+yodsBTVYJh4hfnQfzmwP9zUK 6YZHnr781niMCC8HlihdpUKT2t8zWncP3plitoSnbWy+jtIu/tRj1gBnPxrKqG3QZbag c+nixiEiqyJF2Io21Da0HSXTGAIqUUS/g/9bM0OsMiYpWS5U5KyPmjZaGqO/7ek5iNiB ijYN/rmoumXVMTv88JviV3hIiRVXa34sI9YEZSbbQDECXiO8rUfz9qa+4KFN2JOQW5QN DRBw== MIME-Version: 1.0 X-Received: by 10.50.79.161 with SMTP id k1mr16383526igx.31.1397483889804; Mon, 14 Apr 2014 06:58:09 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.179.103 with HTTP; Mon, 14 Apr 2014 06:58:09 -0700 (PDT) In-Reply-To: <002701cf57af$bb391f50$31ab5df0$@olddog.co.uk> References: <5345035B.7080909@orange.com> <002701cf57af$bb391f50$31ab5df0$@olddog.co.uk> Date: Mon, 14 Apr 2014 19:28:09 +0530 X-Google-Sender-Auth: en1bSsmHIjSv7bI5HaSHRntRfXc Message-ID: From: Dhruv Dhody To: Farrel Adrian Content-Type: multipart/alternative; boundary=089e01183c36d4d3f104f701127c Archived-At: http://mailarchive.ietf.org/arch/msg/pce/_JRimykdI0qxEzBzZHKUKAFcARI Cc: "pce@ietf.org" , draft-ietf-pce-pce-initiated-lsp@tools.ietf.org Subject: Re: [Pce] WG Last Call for draft-ietf-pce-questions-04 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 13:58:14 -0000 --089e01183c36d4d3f104f701127c Content-Type: text/plain; charset=UTF-8 Hi Adrian, Chairs, Use of "recommend instantiation" as suggested by Adrian works for me. ( http://www.ietf.org/mail-archive/web/pce/current/msg03711.html) Can the authors of draft-ietf-pce-pce-initiated-lsp confirm? Dhruv On Mon, Apr 14, 2014 at 12:33 PM, Adrian Farrel wrote: > Thanks chairs, > > As part of the last call I would like to know whether we reached complete > closure on the initiated/suggested LSP debate. I think the main > protagonists > would be the authors of draft-ietf-pce-pce-initiated-lsp and Dhruv who > raised > the issue in the first place. > > Thanks, > Adrian > > > -----Original Message----- > > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Julien Meuric > > Sent: 09 April 2014 09:23 > > To: pce@ietf.org > > Subject: [Pce] WG Last Call for draft-ietf-pce-questions-04 > > > > Hi all. > > > > This message ignites a PCE WG last call on draft-ietf-pce-questions-04. > > It will end on Wednesday, April 23, 11:59 PM (UTC-12). > > > > Thanks, > > > > JP & Julien > > > > _______________________________________________ > > Pce mailing list > > Pce@ietf.org > > https://www.ietf.org/mailman/listinfo/pce > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --089e01183c36d4d3f104f701127c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Adrian, Chairs,

Use of "recommend instanti= ation" as suggested by Adrian works for me. (http://www.ietf.org/mail-= archive/web/pce/current/msg03711.html)

Can the authors of draft-ietf-pce-pce-initiated-lsp confirm?

Dh= ruv


On Mon, A= pr 14, 2014 at 12:33 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:
Thanks chairs,

As part of the last call I would like to know whether we reached complete closure on the initiated/suggested LSP debate. I think the main protagonist= s
would be the authors of draft-ietf-pce-pce-initiated-lsp and Dhruv who rais= ed
the issue in the first place.

Thanks,
Adrian

> -----Original Message-----
> From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Julien Meuric
> Sent: 09 April 2014 09:23
> To: pce@ietf.org=
> Subject: [Pce] WG Last Call for draft-ietf-pce-questions-04
>
> Hi all.
>
> This message ignites a PCE WG last call on draft-ietf-pce-questions-04= .
> It will end on Wednesday, April 23, 11:59 PM (UTC-12).
>
> Thanks,
>
> JP & Julien
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce

_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce

--089e01183c36d4d3f104f701127c-- From nobody Mon Apr 14 14:18:00 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0051A064D for ; Mon, 14 Apr 2014 14:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocKsoDfVlsbf for ; Mon, 14 Apr 2014 14:17:54 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 765601A0705 for ; Mon, 14 Apr 2014 14:17:53 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3ELHmCv031944; Mon, 14 Apr 2014 22:17:48 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3ELHkTq031904 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 Apr 2014 22:17:47 +0100 From: "Adrian Farrel" To: "'Dhruv Dhody'" References: <5345035B.7080909@orange.com> <002701cf57af$bb391f50$31ab5df0$@olddog.co.uk> In-Reply-To: Date: Mon, 14 Apr 2014 22:17:47 +0100 Message-ID: <00f701cf5826$fc464960$f4d2dc20$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F8_01CF582F.5E169840" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG9hvfwSzX9RgkJtgoF+XF9nPjUPgHBy9yDAuU6MTGbEALAgA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20632.002 X-TM-AS-Result: No--26.285-10.0-31-10 X-imss-scan-details: No--26.285-10.0-31-10 X-TMASE-MatchedRID: 4DzIFjPGnphDZFBd1jLr/p/wX1j1/jpj1GdxOr7L6H2o+b+yOP0oGB4u a24ul9od8JYMUCgKxzRT2j9KDY4iRQtrOhDKumbSLUfH1TEwaN2ecqDE0OIf9VpbYq2f4jz+BXb mYqeVw+xf1nKueGVY5dUVI7zBzAKkqj7Od3gwc7lGypC5CVFOH+JZuHloClM7T7S4ZU4XTxDImJ UezF9c+KoBzzUCy9kVFyCVjv7dlo7VFtf7bVfns7MjW/sniEQKa/fioJ9l4Hiyd65qZFFPk+Cmx jHOTu+1A72lF8jbwSkx0tA1lQwSRO1ICoBEyO68YwqrCoawWFxPn74Ug5EKECXR/ftQqB53wuan iM9QXy2tmpf2iRnuMBJDErdDEki6YWo9dIuk10Ac8J6ZrWP/q2Rt0giz+0LSqVVEdEr2LUr+GQF LLcthDar+vu6NNM2HixYJ8/oaa/kyfzA/sEpfw47Su3QulAZ5FKliqHKCaOnrKAwxOgrz3aeFnJ sqgWxcQt2470g7vecsWi4sXciGhT8G3G/wjVDpcLw8nYQVLsggFyxci4S+VuRnWbJNcqgXKqHlx TJ7eJUibp8py4XIryhHQrcMnybC1lfDCm9+EZUWVP8qCAvKPSVbKC+1NyXA4pinC0b7AdVGrs1o WaIIgM5B/9LVe+0QAL9vhpOS4MWLMWEQIO6h8PilM7nponT8kBfdTMRAXUalF7MF/8ayEnii5kS OR4tGsJkYS7cb8jqGAoXhhbsbIC95uXownWhRnQrZDK7DrTqZEoWHC6Rh/WTNuWQFsA2GYBBGfc v6WOGNIndKSIasU9eS5VWUkyw9nHoiWJ/w7MaeAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyLm0EqN7 mnB3uEmMBEXHLXtDt39psV+cVOAkWSdoP8r5nk1/l1zZNngKETy3WPrjmI= Archived-At: http://mailarchive.ietf.org/arch/msg/pce/zD5qQ6S4qOtq_z6GoAZ44aP5MSo Cc: pce@ietf.org, draft-ietf-pce-pce-initiated-lsp@tools.ietf.org Subject: Re: [Pce] WG Last Call for draft-ietf-pce-questions-04 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 21:17:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00F8_01CF582F.5E169840 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, =20 Thanks for that Dhruv. =20 On that basis, I would update the second paragraph in Section 17 as... =20 OLD An Active PCE is one that issues provisioning "recommendations" to the network. These recommendations may be new routes for existing LSPs, or routes for new LSPs. An Active PCE may be stateless or stateful, but in order that it can reroute existing LSPs effectively, it is likely to hold state for at least those LSPs that it will reroute. NEW An Active PCE is one that issues provisioning "recommendations" to the network. These recommendations may be new routes for existing LSPs, or routes for new LSPs (that is, an Active PCE may recommend the instantiation of new LSPs). An Active PCE may be stateless or stateful, but in order that it can reroute existing LSPs effectively, it is likely to hold state for at least those LSPs that it will reroute. END =20 ...and the penultimate paragraph of Section 18 as... =20 OLD It is important, however, to distinguish between an LSP established within the network and subsequently delegated to a PCE, and an LSP that was established by a commands from an Active PCE. NEW It is important, however, to distinguish between an LSP established within the network and subsequently delegated to a PCE, and an LSP that was established as the result of an Active PCE's recommendation for LSP instantiation. END =20 ...and in Section 19... =20 OLD There is a subtle distinction between an NMS and an Active PCE with LSP delegation. An NMS is in control of the LSPs in the network and can request that they are set up, modified, or torn down. An Active PCE can only make suggestions about LSPs that have been delegated to the PCE by a PCC. NEW There is a subtle distinction between an NMS and an Active PCE with LSP delegation. An NMS is in control of the LSPs in the network and can request that they are set up, modified, or torn down. An Active PCE can only make suggestions about LSPs that have been delegated to the PCE by a PCC, or make recommendations for the instantiation of new LSPs. END =20 ...and lastly in Section 20... =20 OLD 6. This mode has potential for recommending new LSPs. 7. These modes are out of scope for PCE as currently described. NEW 6. This mode has potential for recommending the instantiation of new LSPs. 7. These modes are out of scope for PCE as currently described. That is, the PCE can recommend instantiation, but cannot=20 actually instantiate the LSPs. END =20 Cheers, Adrian =20 From: dhruvdhody@gmail.com [mailto:dhruvdhody@gmail.com] On Behalf Of = Dhruv Dhody Sent: 14 April 2014 14:58 To: Farrel Adrian Cc: pce@ietf.org; draft-ietf-pce-pce-initiated-lsp@tools.ietf.org Subject: Re: [Pce] WG Last Call for draft-ietf-pce-questions-04 =20 Hi Adrian, Chairs,=20 Use of "recommend instantiation" as suggested by Adrian works for me. = (http://www.ietf.org/mail-archive/web/pce/current/msg03711.html) Can the authors of draft-ietf-pce-pce-initiated-lsp confirm?=20 Dhruv=20 =20 On Mon, Apr 14, 2014 at 12:33 PM, Adrian Farrel = wrote: Thanks chairs, As part of the last call I would like to know whether we reached = complete closure on the initiated/suggested LSP debate. I think the main = protagonists would be the authors of draft-ietf-pce-pce-initiated-lsp and Dhruv who = raised the issue in the first place. Thanks, Adrian > -----Original Message----- > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Julien Meuric > Sent: 09 April 2014 09:23 > To: pce@ietf.org > Subject: [Pce] WG Last Call for draft-ietf-pce-questions-04 > > Hi all. > > This message ignites a PCE WG last call on = draft-ietf-pce-questions-04. > It will end on Wednesday, April 23, 11:59 PM (UTC-12). > > Thanks, > > JP & Julien > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce =20 ------=_NextPart_000_00F8_01CF582F.5E169840 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

 

Thanks for that = Dhruv.

 

On that basis, I would update = the second paragraph in Section 17 as...

 

OLD

=C2=A0=C2=A0 An Active PCE is one that = issues provisioning "recommendations" = to

=C2=A0=C2=A0 the network.=C2=A0 These recommendations may be = new routes for existing

=C2=A0=C2=A0 LSPs, or routes for new = LSPs.=C2=A0 An Active PCE may be = stateless or

=C2=A0=C2=A0 stateful, but in order = that it can reroute existing LSPs effectively,

=C2=A0=C2=A0 it is likely to hold = state for at least those LSPs that it will

=C2=A0=C2=A0 = reroute.

NEW

=C2=A0=C2=A0 An Active PCE is one that = issues provisioning "recommendations" = to

=C2=A0=C2=A0 the network.=C2=A0 These recommendations may be = new routes for existing

=C2=A0=C2=A0 LSPs, or routes for new = LSPs (that is, an Active PCE may recommend

=C2=A0=C2=A0 the instantiation of new = LSPs).=C2=A0 An Active PCE may = be stateless or

=C2=A0=C2=A0 stateful, but in order = that it can reroute existing LSPs effectively,

=C2=A0=C2=A0 it is likely to hold = state for at least those LSPs that it will

=C2=A0=C2=A0 = reroute.

END

 

...and the penultimate = paragraph of Section 18 as...

 

OLD

=C2=A0=C2=A0 It is important, however, = to distinguish between an LSP established

=C2=A0=C2=A0 within the network and = subsequently delegated to a PCE, and an LSP

=C2=A0=C2=A0 that was established by a = commands from an Active PCE.

NEW

=C2=A0=C2=A0 It is important, however, = to distinguish between an LSP established

=C2=A0=C2=A0 within the network and = subsequently delegated to a PCE, and an LSP

=C2=A0=C2=A0 that was established as = the result of an=C2=A0 Active = PCE's recommendation

=C2=A0=C2=A0 for LSP = instantiation.

END

 

...and in Section = 19...

 

OLD

=C2=A0=C2=A0 There is a subtle = distinction between an NMS and an Active PCE = with

=C2=A0=C2=A0 LSP delegation.=C2=A0 An NMS is in control of the = LSPs in the network and

=C2=A0=C2=A0 can request that they are = set up, modified, or torn down.=C2=A0 = An Active

=C2=A0=C2=A0 PCE can only make = suggestions about LSPs that have been delegated = to

=C2=A0=C2=A0 the PCE by a = PCC.

NEW

=C2=A0=C2=A0 There is a subtle = distinction between an NMS and an Active PCE = with

=C2=A0=C2=A0 LSP delegation.=C2=A0 An NMS is in control of the = LSPs in the network and

=C2=A0=C2=A0 can request that they are = set up, modified, or torn down.=C2=A0 = An Active

=C2=A0=C2=A0 PCE can only make = suggestions about LSPs that have been delegated = to

=C2=A0=C2=A0 the PCE by a PCC, or make = recommendations for the instantiation of

=C2=A0=C2=A0 new = LSPs.

END

 

...and lastly in Section = 20...

 

OLD

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 6. This = mode has potential for recommending new LSPs.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 7. = These modes are out of scope for PCE as currently = described.

NEW

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 6. This = mode has potential for recommending the instantiation = of

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= new LSPs.

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A07. These modes are = out of scope for PCE as currently described.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= That is, the PCE can recommend instantiation, but cannot =

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0actually instantiate the LSPs.

END

 

Cheers,

Adrian

 

From: = dhruvdhody@gmail.com [mailto:dhruvdhody@gmail.com] On Behalf Of = Dhruv Dhody
Sent: 14 April 2014 14:58
To: Farrel = Adrian
Cc: pce@ietf.org; = draft-ietf-pce-pce-initiated-lsp@tools.ietf.org
Subject: Re: = [Pce] WG Last Call for = draft-ietf-pce-questions-04

 

Hi = Adrian, Chairs,

Use of "recommend instantiation" as = suggested by Adrian works for me. (h= ttp://www.ietf.org/mail-archive/web/pce/current/msg03711.html)
Can the authors of draft-ietf-pce-pce-initiated-lsp confirm? =

Dhruv

 

On Mon, Apr 14, 2014 at 12:33 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:

Thanks chairs,

As part of the last call I would = like to know whether we reached complete
closure on the = initiated/suggested LSP debate. I think the main protagonists
would = be the authors of draft-ietf-pce-pce-initiated-lsp and Dhruv who = raised
the issue in the first = place.

Thanks,
Adrian


> -----Original Message-----
> From: Pce = [mailto:pce-bounces@ietf.org] On Behalf Of Julien = Meuric

> Sent: 09 = April 2014 09:23
> To: pce@ietf.org
> Subject: [Pce] WG Last Call = for draft-ietf-pce-questions-04
>
> Hi all.
>
> = This message ignites a PCE WG last call on = draft-ietf-pce-questions-04.
> It will end on Wednesday, April 23, = 11:59 PM (UTC-12).
>
> Thanks,
>
> JP & = Julien
>
> = _______________________________________________
> Pce mailing = list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce

__= _____________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

 

------=_NextPart_000_00F8_01CF582F.5E169840-- From nobody Mon Apr 14 14:32:08 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58FBD1A0751 for ; Mon, 14 Apr 2014 14:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.171 X-Spam-Level: X-Spam-Status: No, score=-1.171 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krcK_MVZayGs for ; Mon, 14 Apr 2014 14:32:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC891A0750 for ; Mon, 14 Apr 2014 14:32:00 -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.7-GA FastPath queued) with ESMTP id BFQ10775; Mon, 14 Apr 2014 21:31:56 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 14 Apr 2014 22:30:12 +0100 Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 14 Apr 2014 22:31:43 +0100 Received: from DFWEML706-CHM.china.huawei.com ([169.254.8.2]) by dfweml705-chm.china.huawei.com ([169.254.7.19]) with mapi id 14.03.0158.001; Mon, 14 Apr 2014 14:31:36 -0700 From: Leeyoung To: Cyril Margaria Thread-Topic: FW: FW: [Pce] I-D Action: draft-ietf-pce-wson-routing-wavelength-11.txt Thread-Index: AQHPWCLhjkILIDXFvESlc62ZkCuejZsRmwCg Date: Mon, 14 Apr 2014 21:31:36 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729BDF0F6@dfweml706-chm.china.huawei.com> References: <7AEB3D6833318045B4AE71C2C87E8E1729BCC17B@dfweml706-chm.china.huawei.com> <7AEB3D6833318045B4AE71C2C87E8E1729BCC299@dfweml706-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.239] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729BDF0F6dfweml706chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pce/nNBL0kzpuIvX3EWhSTlZR_fKE4U Cc: "pce@ietf.org" Subject: Re: [Pce] FW: FW: I-D Action: draft-ietf-pce-wson-routing-wavelength-11.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 21:32:06 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729BDF0F6dfweml706chmchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ3lyaWwsDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50LiBJIHdpbGwgcmVmbGVjdCB0aGUg dHdvIGNoYW5nZXMgaW4gdGhlIG5leHQgcmV2aXNpb24uIFBsZWFzZSBzZWUgaW4tbGluZSBmb3Ig bXkgY29tbWVudC4NCg0KUmVnYXJkcywNCllvdW5nDQoNCkZyb206IEN5cmlsIE1hcmdhcmlhIFtt YWlsdG86Y3lyaWwubWFyZ2FyaWFAZ21haWwuY29tXQ0KU2VudDogTW9uZGF5LCBBcHJpbCAxNCwg MjAxNCAzOjQ4IFBNDQpUbzogTGVleW91bmcNClN1YmplY3Q6IFJlOiBGVzogRlc6IFtQY2VdIEkt RCBBY3Rpb246IGRyYWZ0LWlldGYtcGNlLXdzb24tcm91dGluZy13YXZlbGVuZ3RoLTExLnR4dA0K DQpIaSwNCkkgaGFkIHRpbWUgdG8gcmV2aWV3IHRoZSBjaGFuZ2VzLCB0aGVyZSBhcmUgdHdvIGNo YW5nZXMgdGhhdCB5b3UgYWNjZXB0ZWQsIGJ1dCBpcyBub3QgcmVmbGVjdGVkIGludG8gdGhlIGRv Y3VtZW50Lg0KDQoNCg0KSGkgUENFcnMsDQoNCkkgaGF2ZSBhIGZldyBjb21tZW50cyBvbiB0aGUg ZG9jdW1lbnQ6DQoNCg0KU2VjdGlvbiAxLjEgOiBTdHJhbmdlIGluZGVudGF0aW9uDQoNCg0KWU9V Tkc+PiBJIHdpbGwgbG9vayBpbnRvIHRoYXQuDQoNCkN5cmlsPj4+IERvbmUNCg0KDQppbmRlbnRh dGlvbjoNCj09PT09PT09PT09PQ0KVGhlIGluZGVudGF0aW9uIG9mIHRoZSBmb2xsb3dpbmcgc2Vj dGlvbiBpcyBub3QgY29uc2lzdGVudDoNCg0KU2VjdGlvbiAxLjENClNlY3Rpb24gMi4xDQpTZWN0 aW9uIDIuMS4xDQpTZWN0aW9uIDMuMQ0KDQpTZWN0aW9uIDMuMg0KLi4uDQoNCg0KDQpZT1VORz4+ IEkgd2lsbCBsb29rIGludG8gdGhhdC4NCg0KQ3lyaWw+Pj4gRG9uZQ0KDQoNClNlY3Rpb24gMi4x LjENCj09PT09PT09PT09PT0NCg0KSXMgdGhlcmUgYSByZXF1aWVyZW1lbnQgZm9yIFJXQS1jYXBh YmxlIFBDRSBkaXNjb3Zlcnk/DQpJR1AtYmFzZWQgZGlzY292ZXJ5IGlzIGFkZHJlc3NlZCBpbiBz ZWN0aW9uIDMuNSwgYnV0IE9QRU4gZXh0ZW5zaW9uIGNvdWxkIGFsc28gYmUgY292ZXJlZC4NCg0K QSBQQ0MgZXhwZWN0aW5nIFJXQS1jYXBhYmxlIFBDRSB3aWxsIG9ubHkgYmUgYWJsZSB0byBkZXRl Y3QgYSBub24gUldBIGNhcGFibGUgdXBvbiByZXF1ZXN0Lg0KDQpJdCBpcyBsaWtlbHkgdGhhdCBy ZXF1ZXN0IGFyZSBub3QgdmVyeSBmcmVxdWVudCBpbiBXU09OIG5ldHdvcmtzLCBzbyBhIG1pc2Nv bmZpZ3VyYXRpb24gbWF5IGJlIGRpc2NvdmVyZWQgcXVpdGUgbGF0ZS4NCg0KT1BFTiBleHRlbnNp b24gd291bGQgYWxsb3cgYSBmYXN0ZXIgZGV0ZWN0aW9uLg0KDQpZT1VORz4+ICBQQ0UgZGlzY292 ZXJ5IGlzIG5vdCBhIHJlcXVpcmVtZW50LCBidXQgY2FuIGJlIGNvbnNpZGVyZWQgYXMgYW4gb3B0 aW9uLiBXaGF0IGlzIE9QRU4gZXh0ZW5zaW9uPyBJIGNhbiBhZGQgaWYgeW91IHdhbnQgdGhlIHJl ZmVyZW5jZSBpbmZvIGluIFNlY3Rpb24gMy41LiBJbiBXU09OIGVudmlyb25tZW50LCBSV0EtY2Fw YWJsZSBQQ0UgZGlzY292ZXJ5IGNhbiBiZSBjb25maWd1cmVkIGluc3RlYWQgb2YgZGVwZW5kaW5n IG9uIGRpc2NvdmVyeSBtZWNoYW5pc21zLCBJTUhPLg0KDQpDeXJpbD4+PiB0aGUgbmV3IHRleHQg aXMgT0sNCg0KDQpSZXEgMikgOiBJIGJlbGlldmUgaWkpIGlzIG5vdCBvbmx5IGZvciBELVJXQSwg YnV0IGFsc28gY292ZXJzIFJXQS4NCk9MRDoNCiAgICAgKGkpIEV4cGxpY2l0IExhYmVsIENvbnRy b2wgKEVMQykgW1JGQzQwMDNdDQoNCiAgICAgKGlpKSAgICBOb24tRXhwbGljaXQgbGFiZWxzIGlu IHRoZSBmb3JtIG9mIExhYmVsIFNldHMgKFRoaXMgd2lsbA0KICAgICAgICAgICAgYWxsb3cgRGlz dHJpYnV0ZWQgV0EgYXQgYSBub2RlIGxldmVsIHdoZXJlIGVhY2ggbm9kZSB3b3VsZA0KICAgICAg ICAgICAgc2VsZWN0IHRoZSB3YXZlbGVuZ3RoIGZyb20gdGhlIExhYmVsIFNldHMpDQoNCk5FVzoN CiAgICAgKGkpICBFeHBsaWNpdCBMYWJlbCBDb250cm9sIChFTEMpIFtSRkM0MDAzXS4NCg0KICAg ICAoaWkpIE5vbi1FeHBsaWNpdCBsYWJlbHMgaW4gdGhlIGZvcm0gb2YgTGFiZWwgU2V0cy4gVGhl IFBDQyBjYW4gc2VsZWN0IHRoZSBsYWJlbCBiYXNlZCBvbiBsb2NhbCBwb2xpY3kuDQoNCiAgIE5v dGUgdGhhdCBvcHRpb24gaWkpIG1heSBhbHNvIGJlIHVzZWQgaW4gUitXQSBvciBEV0EuDQoNCllP VU5HPj4gQWdyZWUuIFdpbGwgY2hhbmdlLg0KQ3lyaWw+Pj4gRG9uZQ0KDQoNClNlY3Rpb24gMi4x LjINCj09PT09PT09PT09PT0NCg0KICBJcyBpdCBwb3NzaWJsZSB0byBtaXggaW4gYSBidWxrIHJl cXVlc3QsIFIgYW5kIFJXQSByZXF1ZXN0cz8NCg0KDQoNCllPVU5HPj4gTm90IHN1cmUgd2hhdCB0 aGUgbWl4ZWQgYnVsayByZXF1ZXN0cyBhY2hpZXZlLiBHQ08gW1JGQyA1NTU3XSBhZGRyZXNzZXMg dGhlIGJ1bGsgcmVxdWVzdCBmb3IgUi4NCg0KQ3lyaWw+Pj4gRG9uZQ0KDQpTZWN0aW9uIDIuMS40 DQo9PT09PT09PT09PT09DQoNCg0KT0xEDQogICBGb3IgYW55IFBDUmVxIE1lc3NhZ2UgdGhhdCBp cyBhc3NvY2lhdGVkIHdpdGggYSByZXF1ZXN0IGZvcg0KICAgd2F2ZWxlbmd0aCBhc3NpZ25tZW50 IHRoZSByZXF1ZXN0ZXIgKFBDQykgTVVTVCBiZSBhYmxlIHRvIHNwZWNpZnkgYQ0KICAgcmVzdHJp Y3Rpb24gb24gdGhlIHdhdmVsZW5ndGhzIHRvIGJlIHVzZWQuDQpORVcNCiAgIEZvciBhIFJXQSBy ZXF1ZXN0LCB0aGUgcmVxdWVzdCBNVVNUIGJlIGFibGUgdG8gc3BlY2lmeSBhbiBvcHRpb24gZm9y DQogICBhIHJlc3RyaWN0aW9uIG9uIHRoZSB3YXZlbGVuZ3RocyB0byBiZSB1c2VkLg0KICAgVGhl IHJlcXVlc3RlciBNQVkgdXNlIHRoaXMgb3B0aW9uIHRvIHJlc3RyaWN0IHRoZSBhc3NpZ25lZCB3 YXZlbGVuZ2h0IGZvcg0KICAgRXhwbGljdCBMYWJlbCBvciBMYWJlbCBTZXRzLg0KDQoNCllPVU5H Pj4gIGFjY2VwdGVkLg0KDQpDeXJpbD4+PiBOb3QgZG9uZT8NCg0KWU9VTkc+PiBUaGlzIHdhcyBk b25lIGluIGEgbGl0dGxlIGRpZmZlcmVudCB3b3JkaW5nLiBQbGVhc2Ugc2VlIFNlY3Rpb24gMy41 IHdoZXJlDQoNCjMuNS4gIFdhdmVsZW5ndGggUmFuZ2UgQ29uc3RyYWludA0KDQogICBGb3IgYW55 IFJXQSBjb21wdXRhdGlvbiB0eXBlIHJlcXVlc3QsIHRoZSByZXF1ZXN0ZXIgKFBDQykgTUFZDQog ICBzcGVjaWZ5IGEgcmVzdHJpY3Rpb24gb24gdGhlIHdhdmVsZW5ndGhzIHRvIGJlIHVzZWQuDQoN CllPVU5HPj4gVGhlIHJlYXNvbiBmb3Ig4oCcTVVTVCAtPiBNQVnigJ0gaXMgdGhhdCB0aGlzIGlz IGFuIG9wdGlvbmFsIHJlcXVpcmVtZW50IHJhdGhlciB0aGFuIG1hbmRhdG9yeS4gKFRoaXMgd2Fz IGFjdHVhbGx5IHBlciBSYW1vbuKAmXMgY29tbWVudCwgd2hpY2ggSSB0aGluayBJIGFncmVlZCB3 aXRoIGhpbSkNCg0KSSB3aWxsIGFkZCB0aGUgZm9sbG93aW5nIGNsYXVzZSwg4oCcVGhlIHJlcXVl c3RlciBNQVkgdXNlIHRoaXMgb3B0aW9uIHRvIHJlc3RyaWN0IHRoZSBhc3NpZ25lZCB3YXZlbGVu Z3RoIGZvcg0KICAgRXhwbGljdCBMYWJlbCBvciBMYWJlbCBTZXRzLuKAnQ0KDQoNCg0KDQoNCg0K LS0NCiBUaGlzIGlzIG1vcmUgaW4gbGluZSB3aXRoIHRoZSByZXN0IG9mIHRoZSBkb2N1bWVudC4g VGhlIHJlcSBiZWluZyBvbiB0aGUgcHJvdG9jb2wsIG5vdCBpbnZvbHZpbmcgdGhlIFBDQyBpcyBi ZXR0ZXIuDQoNCg0KDQoNCg0KT0xEDQogICBOb3RlIHRoYXQgdGhlIHJlcXVlc3RvciAoUENDKSBp cyBOT1QgcmVxdWlyZWQgdG8gZnVybmlzaCBhbnkgcmFuZ2UNCiAgIHJlc3RyaWN0aW9ucy4gVGhp cyByZXN0cmljdGlvbiBpcyB0byBiZSBpbnRlcnByZXRlZCBieSB0aGUgUENFIGFzIGENCiAgIGNv bnN0cmFpbnQgb24gdGhlIHR1bmluZyBhYmlsaXR5IG9mIHRoZSBvcmlnaW5hdGlvbiBsYXNlcg0K ICAgdHJhbnNtaXR0ZXIuDQoNCk5FVw0KICAgTm90ZSB0aGF0IHRoZSByZXF1ZXN0b3IgaXMgTk9U IHJlcXVpcmVkIHRvIGZ1cm5pc2ggYW55IHJhbmdlDQogICByZXN0cmljdGlvbnMuIFRoaXMgcmVz dHJpY3Rpb24gbWF5IGZvciBleGFtcGxlIGNvbWUgZnJvbSB0aGUgdHVuaW5nDQogICBhYmlsaXR5 IG9mIGEgbGFzZXIgdHJhbnNtaXR0ZXIsIGFueSBvcHRpY2FsIGVsZW1lbnQsIG9yIGFuIHBvbGlj eSBiYXNlZCByZXN0cmljdGlvbi4NCg0KDQpZT1VORz4+ICBIb3cgYWJvdXQgdGhlIGZvbGxvd2lu ZzoNCg0KTm90ZSB0aGF0IHRoZSByZXF1ZXN0b3IgKGUuZy4sIFBDQykgaXMgTk9UIHJlcXVpcmVk IHRvIGZ1cm5pc2ggYW55IHJhbmdlDQoNCg0KICAgcmVzdHJpY3Rpb25zLiBUaGlzIHJlc3RyaWN0 aW9uIG1heSBmb3IgZXhhbXBsZSBjb21lIGZyb20gdGhlIHR1bmluZw0KICAgYWJpbGl0eSBvZiBh IGxhc2VyIHRyYW5zbWl0dGVyLCBhbnkgb3B0aWNhbCBlbGVtZW50LCBvciBhbiBwb2xpY3kgYmFz ZWQgcmVzdHJpY3Rpb24uDQoNCkN5cmlsPj4+IFRoZSBwcm9wb3NhbCBpcyBPSywgYnV0IG5vdCBh cHBsaWVkIHRvIHZlcnNpb24gLTExDQoNCllPVU5HPj4gQWdyZWUuIEkgd2lsbCBjb3JyZWN0Lg0K DQoNCg0KLS0NCiBUaGUgUENFIHNob3VsZCBub3QgaW50ZXJwcmV0IHRoZSByZXN0cmljdGlvbiwg anVzdCBhcHBseSBpdC4NCg0KU2VjdGlvbiAyLjEuNQ0KPT09PT09PT09PT09PQ0KDQppbiAiVGhl IFBDUmVxIE1lc3NhZ2UgTWF5IGluY2x1ZGUgc3BlY2lmaWMgb3BlcmF0b3IncyBwb2xpY3kiLCBk byB5b3UgbWVhbiBNQVk/DQoNCllPVU5HPj4gWWVzLg0KDQpDeXJpbD4+PiBuZXcgdGV4dCBpcyBP Sw0KDQoNCg0KVGhlIHNlY3Rpb24gY291bGQgYmUgcmVuYW1lZCAiV2F2ZWxlbmd0aCBhc3NpZ25l bWVudCBwb2xpY3kgY29uc3RyYWludHMiDQoNCllPVU5HPj4gR29vZCBzdWdnZXN0aW9uLCBXaWxs IGNoYW5nZS4NCg0KQ3lyaWw+Pj4gbmV3IHRleHQgaXMgZGlmZmVyZW50LCBuZXcgdGV4dCBpcyBP Sw0KDQoNCg0KVGhlIGV4cGxpY2l0IGxhYmVsIHZlcnN1cyBMYWJlbCBzZXQgY291bGQgYWxzbyBm aXQgaW4gdGhpcyBzZWN0aW9uLCBvciBzZWN0aW9uIDIuMS4xIHJlcSAyIHNob3VsZCByZWZlciB0 byB0aGlzIHNlY3Rpb24uDQoNCg0KDQpZT1VORz4+IEluIFNlY3Rpb24gMi4xLjEsIHJlcSAyIHdp bGwgcmVmZXIgdG8gU2VjdGlvbiAyLjEuNSBmb3IgdGhpcyByZXF1aXJlbWVudC4NCg0KQ3lyaWw+ Pj4gTmV3IHRleHQgaXMgT0sNCg0KT0xEDQogIFRoZSBQQ1JlcSBNZXNzYWdlIFNIT1VMRCBiZSBh YmxlIHRvIHJlcXVlc3QsIHdoZW4gcmVxdWVzdGluZyBhIDErMQ0KICBjb25uZWN0aW9uIChlLmcu IGxpbmsgZGlzam9pbnQgcGF0aHMpLCB0aGF0IGJvdGggcGF0aHMgdXNlIHRoZSBzYW1lDQogIHdh dmVsZW5ndGguDQpORVcNCiAgQSByZXF1ZXN0IGZvciAyIG9yIG1vcmUgcGF0aCBNVVNUIGJlIGFi bGUgdG8gc3BlY2lmeSBhbiBvcHRpb24gY29uc3RyYWluaW5nIHRoZSBwYXRoIHRvIGhhdmUgdGhl IHNhbWUgd2F2ZWxlbmd0aChzKSBhc3NpZ25lZC4NCg0KWU9VTkc+Pg0KDQpORVc6DQoNCiAgQSBy ZXF1ZXN0IGZvciAyIG9yIG1vcmUgcGF0aCAoZS5nLiwgMSsxIGxpbmsgZGlzam9pbnQgcGF0aHMp IE1VU1QgYmUgYWJsZSB0byBzcGVjaWZ5IGFuIG9wdGlvbiBjb25zdHJhaW5pbmcgdGhlIHBhdGgg dG8gaGF2ZSB0aGUgc2FtZSB3YXZlbGVuZ3RoKHMpIGFzc2lnbmVkLg0KDQpDeXJpbD4+PiBPSywg bmV3IHRlc3QgaXMgT0sNCg0KDQotLQ0KIENvbXB1dGluZyBhIDErMSBwYXRoIGlzIG9uZSB1c2Ug Y2FzZSwgYnV0IHRoaXMgbWF5IGFwcGx5IGZvciBvdGhlciBwcm90ZWN0aW9uIHR5cGUuIFRoaXMg Y2FuIGJlIGFjaGlldmVkIGJ5IHJlbW92aW5nIHRoZSBwcm90ZWN0aW9uIGFzcGVjdC4NCg0KWU9V Tkc+PiBJIHB1dCBhcyBhbiBleGFtcGxlIGluIHRoZSBhYm92ZSBzdWdnZXN0aW9uLg0KDQoNCg0K U2VjdGlvbiAyLjEuNg0KPT09PT09PT09PT09PQ0KDQpORVcNCiAgICAgIG8gT0lDIGxpc3QNCg0K DQoNCllPVU5HPj4gSSB0aGluayBPSUMgaXMgYSBzb2x1dGlvbiBmb3Igc2lnbmFsIGNvbXBhdGli aWxpdHkgZm9yIEZFQyBhbmQgTW9kdWxhdGlvbi4gQXMgYSByZXF1aXJlbWVudCwgSSB0aGluayB0 aGUgY3VycmVudCB0ZXh0IGlzIGZpbmUuDQoNCkN5cmlsPj4+IE9LDQoNCi0tDQoNCmRyYWZ0LWll dGYtY2NhbXAtcndhLWluZm8tMjEgZGVmaW5lcyB0aGUgY29uY2VwdCBvZiBPSUMsIFBDRVAgc2hv dWxkIGJlIGFibGUgdG8gdHJhbnNwb3J0IHRoZSBzYW1lIGtpbmQgb2YgaW5mbw0KDQpZT1VORz4+ IEFncmVlLCBhcyBhIHNvbHV0aW9uLCBidXQgbm90IGFzIGEgcmVxdWlyZW1lbnQuDQoNCkN5cmls Pj4+IE9LDQoNCk9uIDE4IE1hcmNoIDIwMTQgMTg6NTgsIExlZXlvdW5nIDxsZWV5b3VuZ0BodWF3 ZWkuY29tPG1haWx0bzpsZWV5b3VuZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQpUaGFua3MgQ3lyaWws IGhhdmUgYSBzYWZlIHRyaXAhDQoNCllvdW5nDQoNCkZyb206IEN5cmlsIE1hcmdhcmlhIFttYWls dG86Y3lyaWwubWFyZ2FyaWFAZ21haWwuY29tPG1haWx0bzpjeXJpbC5tYXJnYXJpYUBnbWFpbC5j b20+XQ0KU2VudDogVHVlc2RheSwgTWFyY2ggMTgsIDIwMTQgNTo1OCBQTQ0KVG86IExlZXlvdW5n DQpTdWJqZWN0OiBSZTogRlc6IEZXOiBbUGNlXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXBjZS13 c29uLXJvdXRpbmctd2F2ZWxlbmd0aC0xMS50eHQNCg0KSSB3aWxsIHRyeSB0byBkbyBpdCBzb29u IChBZnRlciBjaGFuZ2luZyBjb21wYW5pZXMsIEkgYW0gY2hhbmdpbmcgY29udGluZW50cyksIEkg aGFkIGEgbG9vayB0byB5b3VyIHJlc29sdXRpb24gcHJvcG9zYWwsIHRoZXkgbG9va2VkIGFsbCBm aW5lLCBJIGp1c3QgbmVlZCB0byBkbyBhIHBhc3MgYW5kIEkgd2lsbCByZXNwb25kIHRvIHRoZSBN TC4NCg0KT24gMTggTWFyY2ggMjAxNCAyMTozMywgTGVleW91bmcgPGxlZXlvdW5nQGh1YXdlaS5j b208bWFpbHRvOmxlZXlvdW5nQGh1YXdlaS5jb20+PiB3cm90ZToNCkhpIEN5cmlsLA0KDQpXb3Vs ZCB5b3UgYmUgYWJsZSB0byBjb21tZW50IG9uIHRoZSBuZXcgdXBkYXRlIG9uIFBDRSBXU09OIGRy YWZ0Pw0KDQpSYW1vbiBoYXMgY2xlYXJlZCBvbiB0aGUgdXBkYXRlLiBUaGFua3MuDQoNCllvdW5n DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSYW1vbiBDYXNlbGxhcyBbbWFp bHRvOnJhbW9uLmNhc2VsbGFzQGN0dGMuZXM8bWFpbHRvOnJhbW9uLmNhc2VsbGFzQGN0dGMuZXM+ XQ0KU2VudDogVGh1cnNkYXksIE1hcmNoIDEzLCAyMDE0IDEyOjQ5IFBNDQpUbzogTGVleW91bmc7 IEN5cmlsIE1hcmdhcmlhDQpDYzogSnVsaWVuIE1ldXJpYw0KU3ViamVjdDogUmU6IEZXOiBbUGNl XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXBjZS13c29uLXJvdXRpbmctd2F2ZWxlbmd0aC0xMS50 eHQNCg0KRWwgMTIvMDMvMjAxNCAyOjA5LCBMZWV5b3VuZyBlc2NyaWJpw7M6DQo+IEhpIFJhbW9u IGFuZCBDeXJpbCwNCj4NCj4gVGhhbmtzIGZvciBwcm92aWRpbmcgdmFsdWFibGUgY29tbWVudHMg dGhhdCBpbXByb3ZlZCBjbGFyaXR5IGFuZCByZWFkYWJpbGl0eSBvZiB0aGUgZHJhZnQuDQo+IExl dCBtZSBrbm93IGlmIHRoaXMgdXBkYXRlIGlzIGdvb2QgdG8gZ28gb3Igc3RpbGwgbmVlZHMgZnVy dGhlciByZWZpbmVtZW50cy4NCj4NCj4NCkkgYW0gb2sgd2l0aCB0aGUgY2hhbmdlcywgSSBndWVz cyBzb21lIG9mIHRoZSBjb25mdXNpb24gY2FtZSBmcm9tIHRoZSBzdHJhbmdlIGluZGVudGF0aW9u IGFuZCBzZWxlY3Rpb24gb2YgdGl0bGVzIFIuDQoNCi0tDQpSYW1vbiBDYXNlbGxhcywgUGguRC4g LS0gU2VuaW9yIFJlc2VhcmNoIEFzc29jaWF0ZSAtLSBOZXR3b3JrcyBEaXZpc2lvbiBPcHRpY2Fs IE5ldHdvcmtzIGFuZCBTeXN0ZW1zIERlcGFydG1lbnQgLS0gaHR0cDovL3dpa2lvbmEuY3R0Yy5l cyBDVFRDIC0gQ2VudHJlIFRlY25vbMOyZ2ljIGRlIFRlbGVjb211bmljYWNpb25zIGRlIENhdGFs dW55YSBQYXJjIE1lZGl0ZXJyYW5pIGRlIGxhIFRlY25vbG9naWEgKFBNVCkgLSBFZGlmaWNpIEI0 IEF2LiBDYXJsIEZyaWVkcmljaCBHYXVzcywgNyAtIDA4ODYwIENhc3RlbGxkZWZlbHMgKEJhcmNl bG9uYSkgLSBTcGFpbg0KVGVsLjogKzM0IDkzIDY0NSAyOSAwMCBleHQgMjE2ODx0ZWw6JTJCMzQl MjA5MyUyMDY0NSUyMDI5JTIwMDAlMjBleHQlMjAyMTY4Pi0tIEZheC4gKzM0IDkzIDY0NSAyOSAw MTx0ZWw6JTJCMzQlMjA5MyUyMDY0NSUyMDI5JTIwMDE+DQoNCg0K --_000_7AEB3D6833318045B4AE71C2C87E8E1729BDF0F6dfweml706chmchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv QWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28t c3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SGkgQ3lyaWwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHlvdXIgY29tbWVudC4gSSB3aWxs IHJlZmxlY3QgdGhlIHR3byBjaGFuZ2VzIGluIHRoZSBuZXh0IHJldmlzaW9uLiBQbGVhc2Ugc2Vl IGluLWxpbmUgZm9yIG15IGNvbW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5Zb3VuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQ3lyaWwgTWFyZ2FyaWEgW21haWx0 bzpjeXJpbC5tYXJnYXJpYUBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBB cHJpbCAxNCwgMjAxNCAzOjQ4IFBNPGJyPg0KPGI+VG86PC9iPiBMZWV5b3VuZzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogRlc6IEZXOiBbUGNlXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXBjZS13 c29uLXJvdXRpbmctd2F2ZWxlbmd0aC0xMS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkhp LCA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYWQgdGlt ZSB0byByZXZpZXcgdGhlIGNoYW5nZXMsIHRoZXJlIGFyZSB0d28gY2hhbmdlcyB0aGF0IHlvdSBh Y2NlcHRlZCwgYnV0IGlzIG5vdCByZWZsZWN0ZWQgaW50byB0aGUgZG9jdW1lbnQuPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KSGkgUENFcnMsPGJyPg0KPGJyPg0KSSBoYXZlIGEgZmV3IGNvbW1lbnRz IG9uIHRoZSBkb2N1bWVudDo8YnI+DQo8YnI+DQo8YnI+DQpTZWN0aW9uIDEuMSA6IFN0cmFuZ2Ug aW5kZW50YXRpb248YnI+DQo8YnI+DQombmJzcDs8YnI+DQpZT1VORyZndDsmZ3Q7IEkgd2lsbCBs b29rIGludG8gdGhhdC48YnI+DQo8YnI+DQo8Yj5DeXJpbCZndDsmZ3Q7Jmd0OyBEb25lPGJyPg0K PC9iPjxicj4NCjxicj4NCmluZGVudGF0aW9uOjxicj4NCj09PT09PT09PT09PTxicj4NClRoZSBp bmRlbnRhdGlvbiBvZiB0aGUgZm9sbG93aW5nIHNlY3Rpb24gaXMgbm90IGNvbnNpc3RlbnQ6PGJy Pg0KPGJyPg0KU2VjdGlvbiAxLjE8YnI+DQpTZWN0aW9uIDIuMSA8YnI+DQpTZWN0aW9uIDIuMS4x IDxicj4NClNlY3Rpb24gMy4xPGJyPg0KPGJyPg0KU2VjdGlvbiAzLjI8YnI+DQouLi4gPGJyPg0K PGJyPg0KJm5ic3A7PGJyPg0KPGJyPg0KWU9VTkcmZ3Q7Jmd0OyBJIHdpbGwgbG9vayBpbnRvIHRo YXQuPGJyPg0KPGJyPg0KPGI+Q3lyaWwmZ3Q7Jmd0OyZndDsgRG9uZTwvYj48YnI+DQo8YnI+DQo8 YnI+DQpTZWN0aW9uIDIuMS4xPGJyPg0KPT09PT09PT09PT09PTxicj4NCjxicj4NCklzIHRoZXJl IGEgcmVxdWllcmVtZW50IGZvciBSV0EtY2FwYWJsZSBQQ0UgZGlzY292ZXJ5PyA8YnI+DQpJR1At YmFzZWQgZGlzY292ZXJ5IGlzIGFkZHJlc3NlZCBpbiBzZWN0aW9uIDMuNSwgYnV0IE9QRU4gZXh0 ZW5zaW9uIGNvdWxkIGFsc28gYmUgY292ZXJlZC48YnI+DQo8YnI+DQpBIFBDQyBleHBlY3Rpbmcg UldBLWNhcGFibGUgUENFIHdpbGwgb25seSBiZSBhYmxlIHRvIGRldGVjdCBhIG5vbiBSV0EgY2Fw YWJsZSB1cG9uIHJlcXVlc3QuPGJyPg0KPGJyPg0KSXQgaXMgbGlrZWx5IHRoYXQgcmVxdWVzdCBh cmUgbm90IHZlcnkgZnJlcXVlbnQgaW4gV1NPTiBuZXR3b3Jrcywgc28gYSBtaXNjb25maWd1cmF0 aW9uIG1heSBiZSBkaXNjb3ZlcmVkIHF1aXRlIGxhdGUuPGJyPg0KPGJyPg0KT1BFTiBleHRlbnNp b24gd291bGQgYWxsb3cgYSBmYXN0ZXIgZGV0ZWN0aW9uLjxicj4NCjxicj4NCllPVU5HJmd0OyZn dDsmbmJzcDsgUENFIGRpc2NvdmVyeSBpcyBub3QgYSByZXF1aXJlbWVudCwgYnV0IGNhbiBiZSBj b25zaWRlcmVkIGFzIGFuIG9wdGlvbi4gV2hhdCBpcyBPUEVOIGV4dGVuc2lvbj8gSSBjYW4gYWRk IGlmIHlvdSB3YW50IHRoZSByZWZlcmVuY2UgaW5mbyBpbiBTZWN0aW9uIDMuNS4gSW4gV1NPTiBl bnZpcm9ubWVudCwgUldBLWNhcGFibGUgUENFIGRpc2NvdmVyeSBjYW4gYmUgY29uZmlndXJlZCBp bnN0ZWFkIG9mIGRlcGVuZGluZyBvbiBkaXNjb3ZlcnkNCiBtZWNoYW5pc21zLCBJTUhPLiA8YnI+ DQo8YnI+DQo8Yj5DeXJpbCZndDsmZ3Q7Jmd0OyB0aGUgbmV3IHRleHQgaXMgT0s8L2I+PGJyPg0K PGJyPg0KPGJyPg0KUmVxIDIpIDogSSBiZWxpZXZlIGlpKSBpcyBub3Qgb25seSBmb3IgRC1SV0Es IGJ1dCBhbHNvIGNvdmVycyBSV0EuPGJyPg0KT0xEOjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAoaSkgRXhwbGljaXQgTGFiZWwgQ29udHJvbCAoRUxDKSBbUkZDNDAwM108YnI+DQo8YnI+ DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKGlpKSZuYnNwOyZuYnNwOyZuYnNwOyBOb24tRXhw bGljaXQgbGFiZWxzIGluIHRoZSBmb3JtIG9mIExhYmVsIFNldHMgKFRoaXMgd2lsbDxicj4NCiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBhbGxvdyBEaXN0cmlidXRlZCBXQSBhdCBhIG5vZGUgbGV2ZWwgd2hlcmUgZWFjaCBu b2RlIHdvdWxkPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNlbGVjdCB0aGUgd2F2ZWxlbmd0aCBmcm9tIHRoZSBM YWJlbCBTZXRzKTxicj4NCjxicj4NCk5FVzo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg KGkpJm5ic3A7IEV4cGxpY2l0IExhYmVsIENvbnRyb2wgKEVMQykgW1JGQzQwMDNdLjxicj4NCjxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAoaWkpIE5vbi1FeHBsaWNpdCBsYWJlbHMgaW4g dGhlIGZvcm0gb2YgTGFiZWwgU2V0cy4gVGhlIFBDQyBjYW4gc2VsZWN0IHRoZSBsYWJlbCBiYXNl ZCBvbiBsb2NhbCBwb2xpY3kuPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7IE5vdGUgdGhhdCBvcHRp b24gaWkpIG1heSBhbHNvIGJlIHVzZWQgaW4gUiYjNDM7V0Egb3IgRFdBLjxicj4NCjxicj4NCllP VU5HJmd0OyZndDsgQWdyZWUuIFdpbGwgY2hhbmdlLjxicj4NCjxiPkN5cmlsJmd0OyZndDsmZ3Q7 IERvbmU8L2I+PGJyPg0KPGJyPg0KPGJyPg0KU2VjdGlvbiAyLjEuMjxicj4NCj09PT09PT09PT09 PT08YnI+DQo8YnI+DQombmJzcDsgSXMgaXQgcG9zc2libGUgdG8gbWl4IGluIGEgYnVsayByZXF1 ZXN0LCBSIGFuZCBSV0EgcmVxdWVzdHM/PGJyPg0KPGJyPg0KJm5ic3A7PGJyPg0KPGJyPg0KWU9V TkcmZ3Q7Jmd0OyBOb3Qgc3VyZSB3aGF0IHRoZSBtaXhlZCBidWxrIHJlcXVlc3RzIGFjaGlldmUu IEdDTyBbUkZDIDU1NTddIGFkZHJlc3NlcyB0aGUgYnVsayByZXF1ZXN0IGZvciBSLjxicj4NCjxi cj4NCjxiPkN5cmlsJmd0OyZndDsmZ3Q7IERvbmU8L2I+PGJyPg0KPGJyPg0KU2VjdGlvbiAyLjEu NDxicj4NCj09PT09PT09PT09PT08YnI+DQo8YnI+DQo8YnI+DQpPTEQ8YnI+DQombmJzcDsmbmJz cDsgRm9yIGFueSBQQ1JlcSBNZXNzYWdlIHRoYXQgaXMgYXNzb2NpYXRlZCB3aXRoIGEgcmVxdWVz dCBmb3I8YnI+DQombmJzcDsmbmJzcDsgd2F2ZWxlbmd0aCBhc3NpZ25tZW50IHRoZSByZXF1ZXN0 ZXIgKFBDQykgTVVTVCBiZSBhYmxlIHRvIHNwZWNpZnkgYTxicj4NCiZuYnNwOyZuYnNwOyByZXN0 cmljdGlvbiBvbiB0aGUgd2F2ZWxlbmd0aHMgdG8gYmUgdXNlZC48YnI+DQpORVc8YnI+DQombmJz cDsmbmJzcDsgRm9yIGEgUldBIHJlcXVlc3QsIHRoZSByZXF1ZXN0IE1VU1QgYmUgYWJsZSB0byBz cGVjaWZ5IGFuIG9wdGlvbiBmb3I8YnI+DQombmJzcDsmbmJzcDsgYSByZXN0cmljdGlvbiBvbiB0 aGUgd2F2ZWxlbmd0aHMgdG8gYmUgdXNlZC48YnI+DQombmJzcDsmbmJzcDsgVGhlIHJlcXVlc3Rl ciBNQVkgdXNlIHRoaXMgb3B0aW9uIHRvIHJlc3RyaWN0IHRoZSBhc3NpZ25lZCB3YXZlbGVuZ2h0 IGZvcjxicj4NCiZuYnNwOyZuYnNwOyBFeHBsaWN0IExhYmVsIG9yIExhYmVsIFNldHMuPGJyPg0K PGJyPg0KPGJyPg0KWU9VTkcmZ3Q7Jmd0OyZuYnNwOyBhY2NlcHRlZC48YnI+DQo8YnI+DQo8Yj5D eXJpbCZndDsmZ3Q7Jmd0OyBOb3QgZG9uZT8gPC9iPjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzU0OERENCI+WU9VTkcmZ3Q7 Jmd0OyBUaGlzIHdhcyBkb25lIGluIGEgbGl0dGxlIGRpZmZlcmVudCB3b3JkaW5nLiBQbGVhc2Ug c2VlIFNlY3Rpb24gMy41IHdoZXJlPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNTQ4REQ0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bGluZS1oZWlnaHQ6MTQuNHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+My41LiZuYnNwOyBXYXZlbGVuZ3RoIFJhbmdl IENvbnN0cmFpbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibGluZS1oZWlnaHQ6MTQuNHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE0LjRwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBGb3IgYW55IFJXQSBjb21wdXRhdGlvbiB0eXBlIHJlcXVl c3QsIHRoZSByZXF1ZXN0ZXIgKFBDQykgTUFZPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE0LjRwdCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyBzcGVjaWZ5IGEgcmVzdHJpY3Rpb24gb24gdGhlIHdhdmVsZW5ndGhzIHRvIGJlIHVz ZWQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bGluZS1oZWlnaHQ6MTQuNHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE0LjRwdCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1NDhERDQiPllPVU5HJmd0OyZndDsgVGhl IHJlYXNvbiBmb3Ig4oCcTVVTVCAtJmd0OyBNQVnigJ0gaXMgdGhhdCB0aGlzIGlzIGFuIG9wdGlv bmFsIHJlcXVpcmVtZW50IHJhdGhlciB0aGFuIG1hbmRhdG9yeS4gKFRoaXMgd2FzIGFjdHVhbGx5 IHBlciBSYW1vbuKAmXMNCiBjb21tZW50LCB3aGljaCBJIHRoaW5rIEkgYWdyZWVkIHdpdGggaGlt KSA8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImxpbmUtaGVpZ2h0OjE0LjRwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiM1NDhERDQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTQuNHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzU0OERENCI+SSB3aWxsIGFkZCB0aGUgZm9sbG93aW5nIGNsYXVzZSwg 4oCcPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzU0OERE NCI+VGhlDQogcmVxdWVzdGVyIE1BWSB1c2UgdGhpcyBvcHRpb24gdG8gcmVzdHJpY3QgdGhlIGFz c2lnbmVkIHdhdmVsZW5ndGggZm9yPGJyPg0KJm5ic3A7Jm5ic3A7IEV4cGxpY3QgTGFiZWwgb3Ig TGFiZWwgU2V0cy7igJ08L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM1NDhERDQiPjxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJs aW5lLWhlaWdodDoxNC40cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTQuNHB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImxpbmUtaGVpZ2h0OjE0LjRwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQotLTxicj4NCiZuYnNwO1Ro aXMgaXMgbW9yZSBpbiBsaW5lIHdpdGggdGhlIHJlc3Qgb2YgdGhlIGRvY3VtZW50LiBUaGUgcmVx IGJlaW5nIG9uIHRoZSBwcm90b2NvbCwgbm90IGludm9sdmluZyB0aGUgUENDIGlzIGJldHRlci48 YnI+DQo8YnI+DQombmJzcDs8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpPTEQ8YnI+DQombmJzcDsm bmJzcDsgTm90ZSB0aGF0IHRoZSByZXF1ZXN0b3IgKFBDQykgaXMgTk9UIHJlcXVpcmVkIHRvIGZ1 cm5pc2ggYW55IHJhbmdlPGJyPg0KJm5ic3A7Jm5ic3A7IHJlc3RyaWN0aW9ucy4gVGhpcyByZXN0 cmljdGlvbiBpcyB0byBiZSBpbnRlcnByZXRlZCBieSB0aGUgUENFIGFzIGE8YnI+DQombmJzcDsm bmJzcDsgY29uc3RyYWludCBvbiB0aGUgdHVuaW5nIGFiaWxpdHkgb2YgdGhlIG9yaWdpbmF0aW9u IGxhc2VyPGJyPg0KJm5ic3A7Jm5ic3A7IHRyYW5zbWl0dGVyLjxicj4NCjxicj4NCk5FVzxicj4N CiZuYnNwOyZuYnNwOyBOb3RlIHRoYXQgdGhlIHJlcXVlc3RvciBpcyBOT1QgcmVxdWlyZWQgdG8g ZnVybmlzaCBhbnkgcmFuZ2U8YnI+DQombmJzcDsmbmJzcDsgcmVzdHJpY3Rpb25zLiBUaGlzIHJl c3RyaWN0aW9uIG1heSBmb3IgZXhhbXBsZSBjb21lIGZyb20gdGhlIHR1bmluZzxicj4NCiZuYnNw OyZuYnNwOyBhYmlsaXR5IG9mIGEgbGFzZXIgdHJhbnNtaXR0ZXIsIGFueSBvcHRpY2FsIGVsZW1l bnQsIG9yIGFuIHBvbGljeSBiYXNlZCByZXN0cmljdGlvbi48YnI+DQo8YnI+DQo8YnI+DQpZT1VO RyZndDsmZ3Q7Jm5ic3A7IEhvdyBhYm91dCB0aGUgZm9sbG93aW5nOjxicj4NCjxicj4NCk5vdGUg dGhhdCB0aGUgcmVxdWVzdG9yIChlLmcuLCBQQ0MpIGlzIE5PVCByZXF1aXJlZCB0byBmdXJuaXNo IGFueSByYW5nZTxicj4NCjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyByZXN0cmljdGlvbnMuIFRo aXMgcmVzdHJpY3Rpb24gbWF5IGZvciBleGFtcGxlIGNvbWUgZnJvbSB0aGUgdHVuaW5nPGJyPg0K Jm5ic3A7Jm5ic3A7IGFiaWxpdHkgb2YgYSBsYXNlciB0cmFuc21pdHRlciwgYW55IG9wdGljYWwg ZWxlbWVudCwgb3IgYW4gcG9saWN5IGJhc2VkIHJlc3RyaWN0aW9uLjxicj4NCjxicj4NCjxiPkN5 cmlsJmd0OyZndDsmZ3Q7IFRoZSBwcm9wb3NhbCBpcyBPSywgYnV0IG5vdCBhcHBsaWVkIHRvIHZl cnNpb24gLTExPG86cD48L286cD48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PG86 cD4mbmJzcDs8L286cD48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUt aGVpZ2h0OjE0LjRwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1NDhE RDQiPllPVU5HJmd0OyZndDsgQWdyZWUuIEkgd2lsbCBjb3JyZWN0Lg0KPC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCi0tPGJyPg0KJm5ic3A7 VGhlIFBDRSBzaG91bGQgbm90IGludGVycHJldCB0aGUgcmVzdHJpY3Rpb24sIGp1c3QgYXBwbHkg aXQuPGJyPg0KPGJyPg0KU2VjdGlvbiAyLjEuNTxicj4NCj09PT09PT09PT09PT08YnI+DQo8YnI+ DQppbiAmcXVvdDtUaGUgUENSZXEgTWVzc2FnZSBNYXkgaW5jbHVkZSBzcGVjaWZpYyBvcGVyYXRv cidzIHBvbGljeSZxdW90OywgZG8geW91IG1lYW4gTUFZPzxicj4NCjxicj4NCllPVU5HJmd0OyZn dDsgWWVzLjxicj4NCjxicj4NCjxiPkN5cmlsJmd0OyZndDsmZ3Q7IG5ldyB0ZXh0IGlzIE9LPC9i Pjxicj4NCjxicj4NCjxicj4NCjxicj4NClRoZSBzZWN0aW9uIGNvdWxkIGJlIHJlbmFtZWQgJnF1 b3Q7V2F2ZWxlbmd0aCBhc3NpZ25lbWVudCBwb2xpY3kgY29uc3RyYWludHMmcXVvdDs8YnI+DQo8 YnI+DQpZT1VORyZndDsmZ3Q7IEdvb2Qgc3VnZ2VzdGlvbiwgV2lsbCBjaGFuZ2UuPGJyPg0KPGJy Pg0KPGI+Q3lyaWwmZ3Q7Jmd0OyZndDsgbmV3IHRleHQgaXMgZGlmZmVyZW50LCBuZXcgdGV4dCBp cyBPSzwvYj48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpUaGUgZXhwbGljaXQgbGFiZWwgdmVyc3Vz IExhYmVsIHNldCBjb3VsZCBhbHNvIGZpdCBpbiB0aGlzIHNlY3Rpb24sIG9yIHNlY3Rpb24gMi4x LjEgcmVxIDIgc2hvdWxkIHJlZmVyIHRvIHRoaXMgc2VjdGlvbi48YnI+DQo8YnI+DQombmJzcDs8 YnI+DQo8YnI+DQpZT1VORyZndDsmZ3Q7IEluIFNlY3Rpb24gMi4xLjEsIHJlcSAyIHdpbGwgcmVm ZXIgdG8gU2VjdGlvbiAyLjEuNSBmb3IgdGhpcyByZXF1aXJlbWVudC48YnI+DQo8YnI+DQo8Yj5D eXJpbCZndDsmZ3Q7Jmd0OyBOZXcgdGV4dCBpcyBPSzwvYj48YnI+DQo8YnI+DQpPTEQ8YnI+DQom bmJzcDsgVGhlIFBDUmVxIE1lc3NhZ2UgU0hPVUxEIGJlIGFibGUgdG8gcmVxdWVzdCwgd2hlbiBy ZXF1ZXN0aW5nIGEgMSYjNDM7MTxicj4NCiZuYnNwOyBjb25uZWN0aW9uIChlLmcuIGxpbmsgZGlz am9pbnQgcGF0aHMpLCB0aGF0IGJvdGggcGF0aHMgdXNlIHRoZSBzYW1lPGJyPg0KJm5ic3A7IHdh dmVsZW5ndGguPGJyPg0KTkVXPGJyPg0KJm5ic3A7IEEgcmVxdWVzdCBmb3IgMiBvciBtb3JlIHBh dGggTVVTVCBiZSBhYmxlIHRvIHNwZWNpZnkgYW4gb3B0aW9uIGNvbnN0cmFpbmluZyB0aGUgcGF0 aCB0byBoYXZlIHRoZSBzYW1lIHdhdmVsZW5ndGgocykgYXNzaWduZWQuPGJyPg0KPGJyPg0KWU9V TkcmZ3Q7Jmd0Ozxicj4NCjxicj4NCk5FVzo8YnI+DQo8YnI+DQombmJzcDsgQSByZXF1ZXN0IGZv ciAyIG9yIG1vcmUgcGF0aCAoZS5nLiwgMSYjNDM7MSBsaW5rIGRpc2pvaW50IHBhdGhzKSBNVVNU IGJlIGFibGUgdG8gc3BlY2lmeSBhbiBvcHRpb24gY29uc3RyYWluaW5nIHRoZSBwYXRoIHRvIGhh dmUgdGhlIHNhbWUgd2F2ZWxlbmd0aChzKSBhc3NpZ25lZC48YnI+DQo8YnI+DQo8Yj5DeXJpbCZn dDsmZ3Q7Jmd0OyBPSywgbmV3IHRlc3QgaXMgT0s8L2I+PGJyPg0KPGJyPg0KPGJyPg0KLS08YnI+ DQombmJzcDtDb21wdXRpbmcgYSAxJiM0MzsxIHBhdGggaXMgb25lIHVzZSBjYXNlLCBidXQgdGhp cyBtYXkgYXBwbHkgZm9yIG90aGVyIHByb3RlY3Rpb24gdHlwZS4gVGhpcyBjYW4gYmUgYWNoaWV2 ZWQgYnkgcmVtb3ZpbmcgdGhlIHByb3RlY3Rpb24gYXNwZWN0Ljxicj4NCjxicj4NCllPVU5HJmd0 OyZndDsgSSBwdXQgYXMgYW4gZXhhbXBsZSBpbiB0aGUgYWJvdmUgc3VnZ2VzdGlvbi48YnI+DQo8 YnI+DQo8YnI+DQo8YnI+DQpTZWN0aW9uIDIuMS42PGJyPg0KPT09PT09PT09PT09PTxicj4NCjxi cj4NCk5FVzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvIE9JQyBsaXN0PGJy Pg0KPGJyPg0KJm5ic3A7PGJyPg0KPGJyPg0KWU9VTkcmZ3Q7Jmd0OyBJIHRoaW5rIE9JQyBpcyBh IHNvbHV0aW9uIGZvciBzaWduYWwgY29tcGF0aWJpbGl0eSBmb3IgRkVDIGFuZCBNb2R1bGF0aW9u LiBBcyBhIHJlcXVpcmVtZW50LCBJIHRoaW5rIHRoZSBjdXJyZW50IHRleHQgaXMgZmluZS48YnI+ DQo8YnI+DQo8Yj5DeXJpbCZndDsmZ3Q7Jmd0OyBPSzwvYj48YnI+DQo8YnI+DQotLTxicj4NCjxi cj4NCmRyYWZ0LWlldGYtY2NhbXAtcndhLWluZm8tMjEgZGVmaW5lcyB0aGUgY29uY2VwdCBvZiBP SUMsIFBDRVAgc2hvdWxkIGJlIGFibGUgdG8gdHJhbnNwb3J0IHRoZSBzYW1lIGtpbmQgb2YgaW5m bzxicj4NCjxicj4NCllPVU5HJmd0OyZndDsgQWdyZWUsIGFzIGEgc29sdXRpb24sIGJ1dCBub3Qg YXMgYSByZXF1aXJlbWVudC48YnI+DQo8YnI+DQo8Yj5DeXJpbCZndDsmZ3Q7Jmd0OyBPSzwvYj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gMTggTWFyY2ggMjAxNCAxODo1OCwgTGVleW91bmcgJmx0Ozxh IGhyZWY9Im1haWx0bzpsZWV5b3VuZ0BodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+bGVleW91 bmdAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5UaGFua3MgQ3lyaWwsIGhhdmUgYSBzYWZlIHRyaXAhPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ WW91bmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBDeXJpbCBNYXJnYXJpYSBbbWFpbHRvOjxhIGhyZWY9Im1h aWx0bzpjeXJpbC5tYXJnYXJpYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5jeXJpbC5tYXJn YXJpYUBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE1hcmNoIDE4 LCAyMDE0IDU6NTggUE08YnI+DQo8Yj5Ubzo8L2I+IExlZXlvdW5nPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBGVzogRlc6IFtQY2VdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtcGNlLXdzb24tcm91 dGluZy13YXZlbGVuZ3RoLTExLnR4dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSB3aWxsIHRyeSB0byBkbyBpdCBzb29uIChB ZnRlciBjaGFuZ2luZyBjb21wYW5pZXMsIEkgYW0gY2hhbmdpbmcgY29udGluZW50cyksIEkgaGFk IGEgbG9vayB0byB5b3VyIHJlc29sdXRpb24gcHJvcG9zYWwsIHRoZXkgbG9va2VkIGFsbCBmaW5l LCBJIGp1c3QgbmVlZCB0byBkbyBhIHBhc3MgYW5kIEkgd2lsbA0KIHJlc3BvbmQgdG8gdGhlIE1M LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIDE4IE1hcmNo IDIwMTQgMjE6MzMsIExlZXlvdW5nICZsdDs8YSBocmVmPSJtYWlsdG86bGVleW91bmdAaHVhd2Vp LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmxlZXlvdW5nQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgQ3lyaWwsPGJyPg0KPGJy Pg0KV291bGQgeW91IGJlIGFibGUgdG8gY29tbWVudCBvbiB0aGUgbmV3IHVwZGF0ZSBvbiBQQ0Ug V1NPTiBkcmFmdD88YnI+DQo8YnI+DQpSYW1vbiBoYXMgY2xlYXJlZCBvbiB0aGUgdXBkYXRlLiBU aGFua3MuPGJyPg0KPGJyPg0KWW91bmc8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1i b3R0b206MTIuMHB0Ij48YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206 IFJhbW9uIENhc2VsbGFzIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnJhbW9uLmNhc2VsbGFzQGN0 dGMuZXMiIHRhcmdldD0iX2JsYW5rIj5yYW1vbi5jYXNlbGxhc0BjdHRjLmVzPC9hPl08YnI+DQpT ZW50OiBUaHVyc2RheSwgTWFyY2ggMTMsIDIwMTQgMTI6NDkgUE08YnI+DQpUbzogTGVleW91bmc7 IEN5cmlsIE1hcmdhcmlhPGJyPg0KQ2M6IEp1bGllbiBNZXVyaWM8YnI+DQpTdWJqZWN0OiBSZTog Rlc6IFtQY2VdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtcGNlLXdzb24tcm91dGluZy13YXZlbGVu Z3RoLTExLnR4dDxicj4NCjxicj4NCkVsIDEyLzAzLzIwMTQgMjowOSwgTGVleW91bmcgZXNjcmli acOzOjxicj4NCiZndDsgSGkgUmFtb24gYW5kIEN5cmlsLDxicj4NCiZndDs8YnI+DQomZ3Q7IFRo YW5rcyBmb3IgcHJvdmlkaW5nIHZhbHVhYmxlIGNvbW1lbnRzIHRoYXQgaW1wcm92ZWQgY2xhcml0 eSBhbmQgcmVhZGFiaWxpdHkgb2YgdGhlIGRyYWZ0Ljxicj4NCiZndDsgTGV0IG1lIGtub3cgaWYg dGhpcyB1cGRhdGUgaXMgZ29vZCB0byBnbyBvciBzdGlsbCBuZWVkcyBmdXJ0aGVyIHJlZmluZW1l bnRzLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KSSBhbSBvayB3aXRoIHRoZSBjaGFuZ2VzLCBJ IGd1ZXNzIHNvbWUgb2YgdGhlIGNvbmZ1c2lvbiBjYW1lIGZyb20gdGhlIHN0cmFuZ2UgaW5kZW50 YXRpb24gYW5kIHNlbGVjdGlvbiBvZiB0aXRsZXMgUi48YnI+DQo8YnI+DQotLTxicj4NClJhbW9u IENhc2VsbGFzLCBQaC5ELiAtLSBTZW5pb3IgUmVzZWFyY2ggQXNzb2NpYXRlIC0tIE5ldHdvcmtz IERpdmlzaW9uIE9wdGljYWwgTmV0d29ya3MgYW5kIFN5c3RlbXMgRGVwYXJ0bWVudCAtLQ0KPGEg aHJlZj0iaHR0cDovL3dpa2lvbmEuY3R0Yy5lcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93aWtp b25hLmN0dGMuZXM8L2E+IENUVEMgLSBDZW50cmUgVGVjbm9sw7JnaWMgZGUgVGVsZWNvbXVuaWNh Y2lvbnMgZGUgQ2F0YWx1bnlhIFBhcmMgTWVkaXRlcnJhbmkgZGUgbGEgVGVjbm9sb2dpYSAoUE1U KSAtIEVkaWZpY2kgQjQgQXYuIENhcmwgRnJpZWRyaWNoIEdhdXNzLCA3IC0gMDg4NjAgQ2FzdGVs bGRlZmVscyAoQmFyY2Vsb25hKSAtIFNwYWluPGJyPg0KVGVsLjogPGEgaHJlZj0idGVsOiUyQjM0 JTIwOTMlMjA2NDUlMjAyOSUyMDAwJTIwZXh0JTIwMjE2OCIgdGFyZ2V0PSJfYmxhbmsiPiYjNDM7 MzQgOTMgNjQ1IDI5IDAwIGV4dCAyMTY4PC9hPi0tIEZheC4NCjxhIGhyZWY9InRlbDolMkIzNCUy MDkzJTIwNjQ1JTIwMjklMjAwMSIgdGFyZ2V0PSJfYmxhbmsiPiYjNDM7MzQgOTMgNjQ1IDI5IDAx PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7AEB3D6833318045B4AE71C2C87E8E1729BDF0F6dfweml706chmchi_-- From nobody Mon Apr 14 14:54:22 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8921A04A1 for ; Mon, 14 Apr 2014 14:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.25 X-Spam-Level: X-Spam-Status: No, score=-93.25 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id or8SxQwNMxa3 for ; Mon, 14 Apr 2014 14:54:19 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD4E1A0230 for ; Mon, 14 Apr 2014 14:54:18 -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 s3ELs4sP021246; Mon, 14 Apr 2014 22:54:04 +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 s3ELs3cm021240 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 Apr 2014 22:54:03 +0100 From: "Adrian Farrel" To: "'Qin Wu'" References: <5345035B.7080909@orange.com> In-Reply-To: Date: Mon, 14 Apr 2014 22:54:03 +0100 Message-ID: <011d01cf582c$0d6daad0$28490070$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG9hvfwSzX9RgkJtgoF+XF9nPjUPgIijbAfmyQqa5A= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.0.0.1014-20632.002 X-TM-AS-Result: No--12.049-10.0-31-10 X-imss-scan-details: No--12.049-10.0-31-10 X-TMASE-MatchedRID: gjZGo2H/wj8zx9GDMr0HvzYTypjB3iDVEtdrY/Wb3fNGF+ZMjV6QiIP+ YDa/Dhu9nKUAfq2r6oqgE4umcRqEtLlepOYfePOtypeMiaCPnxsvfgjwim9BwhAgJNTZvwXZReP kuk87TYFvBDMvW81xkE6nIMfjRtNUXnfQBOtn0jlnCZCpd7/ywxmyTBaqiJvcoVKHbnELtOlYX0 O93I2OpfoGsM+t3ssrSkyTQMUkCyYJkGXJpTkmgZVIEKhlTKpsk9atiES99p1q4coTktrGX0d6y 3aT7JM11ZYbLEu1Qqv/2bsD6e1675VSBURTFYjQc+QhWKJM04MF15s6prCIuxy/A9iZcrIfjJ/G XJkevFNm2nBSC02opHyI5P+Rj6u0U+EPfBiq3G9CnGIuUMP0VfSEh8AqyHUv+yNYYwngrxZllnd VQSPeh6KQTuWu6CkKb9nci6zjYi7rcMhBmp6epgPZZctd3P4BjcUdKJrkZs1JJReS9JUB3IQmEN BkUZwTirzHOtw45k8fZdczzDm/ulh7pGxMM9J9VJ5fWlRo81/af1N18C+ZAhe9CQaLe2PPjoczm uoPCq1t3XSEYmMoBHSiYFiC6KGDjM/mSYmJ1tk3CNEnVn3MufLKXKQc59kZ Archived-At: http://mailarchive.ietf.org/arch/msg/pce/4wVu-SVKPFm_H5ROkIaR-yhQybo Cc: pce@ietf.org Subject: Re: [Pce] =?gb2312?b?tPC4tDogIFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi1w?= =?gb2312?b?Y2UtcXVlc3Rpb25zLTA0?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 21:54:20 -0000 Thanks Qin, See also my answer to Dhruv since that modifies some of the text you are = asking about. > 1. Section 19, second paragraph says: > " > There is a subtle distinction between an NMS and an Active PCE with > LSP delegation. An NMS is in control of the LSPs in the network = and > can request that they are set up, modified, or torn down. An = Active > PCE can only make suggestions about LSPs that have been delegated = to > the PCE by a PCC . > " > Is PCC NMS or LSR headend? If PCC is NMS, it is a little bit confusing = to compare > Active PCE with LSP delegation with NMS? I thought about this a bit and decided that the text is right as it = stands. The possibilities are: - An NMS uses a passive PCE to compute paths and then instructs the network. - An NMS uses an active PCE to recommend *to*it* the changes to=20 delegated LSPs and to recommend *to*it* new LSPs to be instantiated, then the NMS instructs the network. - An NMS instructs an LSR to set up an LSP and the LSR consults a passive PCE to determine a path. - An NMS instructs an LSR to set up an LSP and the LSR delegates the LSP to an active PCE. - An LSR determines to set up an LSP and the LSR consults a passive PCE to determine a path. - An LSR uses an active PCE to recommend to it the changes to=20 delegated LSPs and to recommend *to*it* new LSPs to be instantiated, The distinction in all these cases is that the active PCE makes = recommendations to the PCC, but the NMS issues instructions to the network. I think that one word of clarification comes out of this. In the text = you quote I will s/request/command/ > 2. Section 20 says: > " > | Stateless | Stateful | > ------------------------+-----------+-----------+ > Passive | 1 | 2 | > Active delegated LSPs | 3 | 4 | > Active suggest new LSPs | 5 | 6 | > Active instantiate LSPs | 7 | 7 | > " > What=A1=AFs the difference between delegated LSP and suggested new = LSP? What=A1=AFs > the difference between suggest new LSP and Instantiate LSPs? Is Active > Instantiate LSPs related to PCE initiated LSP? Well, this is not only the subject of the previous sections, but also = has been the focus of a bit of debate on the list. > What=A1=AFs the difference between delegated LSP and suggested new = LSP? The former is an LSP that has been set up and is then passed (delegated) = to the active PCE for it to recommend changes. The latter does not exist as an = LSP until the active PCE recommends its instantiation. > What=A1=AFs the difference between suggest new LSP and Instantiate = LSPs? "Suggestion" is recommending instantiation. But just because something = is recommended, doesn't mean you do it! (Except in some cultures: I had an interesting discussion with a TSA officer about this once ;-) On the = other hand, "instantiate LSP" implies absolute control. > Is Active Instantiate LSPs related to PCE initiated LSP This is the point Dhruv and I are trying to dance around. The topic only = applies to active PCEs, so we need only compare "instantiate" with "initiate". = The WG draft on LSP initiation does not (IMHO) have an active PCE issuing = commands that the PCC must obey. I think it has a PCE that "recommends the = instantiation of LSPs" and the PCC can determine according to policy and weather = conditions if it wishes to follow the recommendation. Thus, the WG draft on LSP initiation does not talk about what I call = "LSP instantiation" because it does not compel the PCC to set up the LSP.=20 This is consistent with my view that a PCE cannot instantiate an LSP, it = can only recommend instantiation. > 3. Section 22, last bullet says: > " > The VNTM will need to issue provisioning requests/commands to = the > lower layer networks to cause LSPs to be set up to act as TE = links > in the higher layer network. A number of potential protocols = exist > for this function as described in [I-D.farrkingel-pce-abno- > architecture], but it should be noted that it makes a lot of = sense > for this interface to be the same as that used by an Active PCE > when providing paths to the network. > " > Why VNTM should issue provision request? Isn=A1=AFt it the job of = Provision manager? > Or VNTM ask Provision manager to issue provision request? Good catch. Everything should go via Provisioning Manager. This text was = written before Provisioning manager added to ABNO. I'll update. > 4. Section 23, 2nd paragraph > s/network note/network node ack > 5. Section 23, 3rd paragraph says: > " > Conversely, a centralized database of resources and LSPs such as > maintained by a Stateful PCE can be enhanced with a time-based > booking system. If the PCE is also Active, then when the time = comes > for the LSP to be set up (or later, when it is to be torn down) the > PCE can control the network. > " > It looks this sentence breaks and can not be parsed from =A1=B0and LSP = such as > maintained by a stateful PCE=A1=B1 > It looks =A1=B0such as=A1=B1 needs to be removed or > s/ and LSPs such as maintained by/such as LSP maintained by The "such as" applies to the DB. I'll reword. > 6. Section 23, last paragraph, says: > " > It may also be necessary > to reposition existing or planned LSPs as new bookings arrive. > Furthermore, the booking database that contains both the scheduled > LSPs and their impact on the network resources can become quite > large. > " > Is planned LSP scheduled LSP? If not, tell difference, if yes, make consistent. The term "scheduled LSP" is not used, so nothing to make consistent = with, I think. The section begins... LSP scheduling or calendaring is a process where LSPs are planned ahead of time, and only set up when needed. =20 ...so to me it is clear what a planned LSP is. If you have a specific suggestion, then I'd be happy to hear it. Many thanks, Adrian From nobody Thu Apr 24 03:29:46 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB521A0175 for ; Thu, 24 Apr 2014 03:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.743 X-Spam-Level: X-Spam-Status: No, score=0.743 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.272, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnL3ErbZSsV8 for ; Thu, 24 Apr 2014 03:29:43 -0700 (PDT) Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC091A0171 for ; Thu, 24 Apr 2014 03:29:43 -0700 (PDT) Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 391E0DE4005 for ; Thu, 24 Apr 2014 12:31:19 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.orange.com (Postfix) with ESMTP id 310D9DE4002 for ; Thu, 24 Apr 2014 12:31:19 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Apr 2014 12:29:34 +0200 Received: from [10.193.75.121] ([10.193.75.121]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Apr 2014 12:29:34 +0200 Message-ID: <5358E78D.4040604@orange.com> Date: Thu, 24 Apr 2014 12:29:33 +0200 From: Julien Meuric Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: pce@ietf.org References: <5345035B.7080909@orange.com> In-Reply-To: <5345035B.7080909@orange.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2014 10:29:34.0596 (UTC) FILETIME=[160A6C40:01CF5FA8] Archived-At: http://mailarchive.ietf.org/arch/msg/pce/POMaQV9UR-tx81cDJVSLiJ_YNQY Subject: Re: [Pce] WG Last Call for draft-ietf-pce-questions-04 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 10:29:44 -0000 Hi all. This last call has ended. We have seen interesting discussion. If people who raised comments feel the proposed resolutions are not satisfying, please shout. Otherwise, we will move forward the accordingly updated document. Thanks, JP & Julien Apr. 09, 2014 - Julien Meuric: > Hi all. > > This message ignites a PCE WG last call on > draft-ietf-pce-questions-04. It will end on Wednesday, April 23, > 11:59 PM (UTC-12). > > Thanks, > > JP & Julien > > _______________________________________________ Pce mailing list > Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce > > From nobody Thu Apr 24 03:39:37 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3B81A0176 for ; Thu, 24 Apr 2014 03:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYeQLaKmnnO1 for ; Thu, 24 Apr 2014 03:39:28 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFFC1A0171 for ; Thu, 24 Apr 2014 03:39:28 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3OAdKQk027487; Thu, 24 Apr 2014 11:39:21 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3OAdI3E027344 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Apr 2014 11:39:20 +0100 From: "Adrian Farrel" To: "'Julien Meuric'" , References: <5345035B.7080909@orange.com> <5358E78D.4040604@orange.com> In-Reply-To: <5358E78D.4040604@orange.com> Date: Thu, 24 Apr 2014 11:39:10 +0100 Message-ID: <012201cf5fa9$7297daa0$57c78fe0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG9hvfwSzX9RgkJtgoF+XF9nPjUPgJegcaumzFQsoA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20652.006 X-TM-AS-Result: No--19.835-10.0-31-10 X-imss-scan-details: No--19.835-10.0-31-10 X-TMASE-MatchedRID: oTBA/+sdKaYzx9GDMr0HvzYTypjB3iDVEtdrY/Wb3fNq4coTktrGX9fI 5PQFG8uhYK8+BIRGUQgkTpaDR3J9kNcUNjoF7YuVRxVrKtb83dQZskwWqoib3MUmcSma304Td8R kwqWc0YB0y9+LWqGXxznYVr4jRB90w5B5ycCESluNZ7kc4Uq+4wBzfxM7vRJxnvbaEOoeixM38g +AdQdV8I9Zm8Ov7SprPDF4aOlLYwdKl5uDD6k69p4CIKY/Hg3AtOt1ofVlaoKm8jxRk5/juNRnE QCUU+jzjoczmuoPCq2UTGVAhB5EbQ== Archived-At: http://mailarchive.ietf.org/arch/msg/pce/99YojAgYI2e_oCDZZRMPFERkFSg Subject: Re: [Pce] WG Last Call for draft-ietf-pce-questions-04 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 10:39:32 -0000 Thanks Julien, I collected changes as the discussion went on, so I'll post them now and people can diff to see the updates. Adrian > -----Original Message----- > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Julien Meuric > Sent: 24 April 2014 11:30 > To: pce@ietf.org > Subject: Re: [Pce] WG Last Call for draft-ietf-pce-questions-04 > > Hi all. > > This last call has ended. > > We have seen interesting discussion. If people who raised comments feel > the proposed resolutions are not satisfying, please shout. Otherwise, we > will move forward the accordingly updated document. > > Thanks, > > JP & Julien > > > Apr. 09, 2014 - Julien Meuric: > > Hi all. > > > > This message ignites a PCE WG last call on > > draft-ietf-pce-questions-04. It will end on Wednesday, April 23, > > 11:59 PM (UTC-12). > > > > Thanks, > > > > JP & Julien > > > > _______________________________________________ Pce mailing list > > Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce > > > > > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From nobody Thu Apr 24 04:05:40 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35E861A019B; Thu, 24 Apr 2014 04:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEA1rgM64BDm; Thu, 24 Apr 2014 04:05:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB101A0191; Thu, 24 Apr 2014 04:05:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140424110533.29521.70873.idtracker@ietfa.amsl.com> Date: Thu, 24 Apr 2014 04:05:33 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/vfEK5lGZG3xR5z49fXwBGYcZHfs Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-questions-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 11:05:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Unanswered Questions in the Path Computation Element Architecture Authors : Adrian Farrel Daniel King Filename : draft-ietf-pce-questions-05.txt Pages : 26 Date : 2014-04-24 Abstract: The Path Computation Element (PCE) architecture is set out in RFC 4655. The architecture is extended for multi-layer networking with the introduction of the Virtual Network Topology Manager in RFC 5623, and generalized to Hierarchical PCE in RFC 6805. These three architectural views of PCE deliberately leave some key questions unanswered especially with respect to the interactions between architectural components. This document draws out those questions and discusses them in an architectural context with reference to other architectural components, existing protocols, and recent IETF work efforts. This document does not update the architecture documents and does not define how protocols or components must be used. It does, however, suggest how the architectural components might be combined to provide advanced PCE function. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-questions/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-questions-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-questions-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 25 05:37:44 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1861A0416; Thu, 24 Apr 2014 15:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8az1mmeV3Gc; Thu, 24 Apr 2014 15:21:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 420A41A0412; Thu, 24 Apr 2014 15:21:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Liaison Statement Management Tool To: The IETF Chair X-Test-IDTracker: no X-IETF-IDTracker: 5.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140424222128.1431.43278.idtracker@ietfa.amsl.com> Date: Thu, 24 Apr 2014 15:21:28 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/FRCpEwBc90JrtMOAwglEf0tRHns X-Mailman-Approved-At: Fri, 25 Apr 2014 05:37:37 -0700 Cc: mpls@ietf.org, ccamp@ietf.org, Scott Mansfield , pce@ietf.org, The IESG , ohara.takuya@lab.ntt.co.jp Subject: [Pce] New Liaison Statement, "LS on ITU-T SG15 OTNT standardization work plan" X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 22:21:30 -0000 Title: LS on ITU-T SG15 OTNT standardization work plan Submission Date: 2014-04-24 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1322/ Please reply by 2014-11-07 From: ITU-T SG 15 (Greg Jones ) To: The IETF (The IETF Chair ) Cc: The IESG ,John Drake ,Scott Mansfield ,ccamp@ietf.org,pce@ietf.org,mpls@ietf.org Response Contact: ohara.takuya@lab.ntt.co.jp Technical Contact: Purpose: For action Body: Thank you for your previous review and comments for “Optical Transport Networks & Technologies Standardization Work Plan”. Attached is the updated version from this SG15 meeting (Geneva, 24 March – 4 April 2014). This version reflects recent development of related standards and your valuable input. We appreciate your review of this latest version and comments. Attach: − Draft revised Optical Transport Networks & Technologies Standardization Work Plan, Issue 18 (TD231R2/PLEN). Attachments: Draft revised Optical Transport Networks & Technologies Standardization Work Plan, Issue 18 https://datatracker.ietf.org/documents/LIAISON/liaison-2014-04-24-itu-t-sg-15-the-ietf-ls-on-itu-t-sg15-otnt-standardization-work-plan-attachment-1.pdf From nobody Mon Apr 28 09:28:34 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CE71A6F67; Mon, 28 Apr 2014 09:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQ9JpfytnHDh; Mon, 28 Apr 2014 09:28:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C472A1A08C5; Mon, 28 Apr 2014 09:28:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140428162831.5885.20142.idtracker@ietfa.amsl.com> Date: Mon, 28 Apr 2014 09:28:31 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/Z5UEpLMK9kHo0VNUwtloAPLDy6I Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-wson-routing-wavelength-12.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 16:28:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : PCEP Requirements for WSON Routing and Wavelength Assignment Authors : Young Lee Greg Bernstein Jonas Martensson Tomonori Takeda Takehiro Tsuritani Oscar Gonzalez de Dios Filename : draft-ietf-pce-wson-routing-wavelength-12.txt Pages : 14 Date : 2014-04-28 Abstract: This memo provides application-specific requirements for the Path Computation Element communication Protocol (PCEP) for the support of Wavelength Switched Optical Networks (WSON). Lightpath provisioning in WSONs requires a routing and wavelength assignment (RWA) process. From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical light path computation. Requirements for Optical impairments will be addressed in a separate document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-wson-routing-wavelength/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-wson-routing-wavelength-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-wson-routing-wavelength-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 28 09:31:47 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D23C1A0A7F for ; Mon, 28 Apr 2014 09:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtieGgpmmB5q for ; Mon, 28 Apr 2014 09:31:43 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A3E6D1A6F20 for ; Mon, 28 Apr 2014 09:31:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDP45122; Mon, 28 Apr 2014 16:31:41 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 28 Apr 2014 17:30:29 +0100 Received: from DFWEML701-CHM.china.huawei.com (10.193.5.50) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 28 Apr 2014 17:31:40 +0100 Received: from DFWEML706-CHM.china.huawei.com ([169.254.8.2]) by dfweml701-chm.china.huawei.com ([169.254.1.127]) with mapi id 14.03.0158.001; Mon, 28 Apr 2014 09:31:30 -0700 From: Leeyoung To: Julien Meuric Thread-Topic: [Pce] I-D Action: draft-ietf-pce-wson-routing-wavelength-12.txt Thread-Index: AQHPYv7rzHzZFU5jKECdZpEvO1J4yZsnN/UA Date: Mon, 28 Apr 2014 16:31:29 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729BE1B9D@dfweml706-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pce/d1MkQllYFa6CwAPuxuo2P5xvMjs Cc: "pce@ietf.org" , Cyril Margaria Subject: [Pce] FW: I-D Action: draft-ietf-pce-wson-routing-wavelength-12.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 16:31:45 -0000 Hi Julien, This update reflects all the comments received from Cyril and Ramon as part= of the WG LC.=20 Cyril, please let the WG know if this update satisfies your comment.=20 Best Regards, Young -----Original Message----- From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.o= rg Sent: Monday, April 28, 2014 11:29 AM To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-wson-routing-wavelength-12.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Path Computation Element Working Group of= the IETF. Title : PCEP Requirements for WSON Routing and Wavelength= Assignment Authors : Young Lee Greg Bernstein Jonas Martensson Tomonori Takeda Takehiro Tsuritani Oscar Gonzalez de Dios Filename : draft-ietf-pce-wson-routing-wavelength-12.txt Pages : 14 Date : 2014-04-28 Abstract: This memo provides application-specific requirements for the Path Computation Element communication Protocol (PCEP) for the support of Wavelength Switched Optical Networks (WSON). Lightpath provisioning in WSONs requires a routing and wavelength assignment (RWA) process. From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical light path computation. Requirements for Optical impairments will be addressed in a separate document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-wson-routing-wavelength/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-wson-routing-wavelength-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-wson-routing-wavelength-1= 2 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From nobody Mon Apr 28 09:57:37 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0161A6F8E for ; Mon, 28 Apr 2014 09:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X919YqXn3AiA for ; Mon, 28 Apr 2014 09:57:33 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 90B7B1A6F87 for ; Mon, 28 Apr 2014 09:57:33 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id z2so6036255wiv.6 for ; Mon, 28 Apr 2014 09:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mCm6ipmisUX0dJeLz0AHPvKFph3W+pb5LPoVudAQMao=; b=Y+GtG/POvJmT3c8YFh77gk3Zyu3bR+fb1qxi86KRxaiTY3+X37uuFEl0CPe89BY1hd vo/O8kLeJXtslGBxzyWz3dXcPOiYAHdhtngbmfu6Tdl18wof1T8K5+DLTNPoL861rAyp tQHxH4VLRcVRXXlVylzvMdJ3DwqL3uCHqLMVRHwElWHy3y0KyUayREye0zJx9eDnyNd9 qut8jwj/UrTiGuJ19Wy6f7EcB0OPZc07nWC3rAKvXTqR7w94dKlWvqxNKZ6lwCc9XHBP T1cA0D56bzrc+cuWolP6aViPm4yX0S602u91uwFpNDrd22AGLQI3CMEeoxBbXBCx5j3u uvpA== MIME-Version: 1.0 X-Received: by 10.180.14.199 with SMTP id r7mr16477482wic.0.1398704252283; Mon, 28 Apr 2014 09:57:32 -0700 (PDT) Received: by 10.216.151.201 with HTTP; Mon, 28 Apr 2014 09:57:32 -0700 (PDT) In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729BE1B9D@dfweml706-chm.china.huawei.com> References: <7AEB3D6833318045B4AE71C2C87E8E1729BE1B9D@dfweml706-chm.china.huawei.com> Date: Mon, 28 Apr 2014 12:57:32 -0400 Message-ID: From: Cyril Margaria To: Leeyoung Content-Type: multipart/alternative; boundary=f46d04138e5f1af2bd04f81d367e Archived-At: http://mailarchive.ietf.org/arch/msg/pce/3NwARyprNtLoVCOoce4aDS73_uU Cc: "pce@ietf.org" Subject: Re: [Pce] FW: I-D Action: draft-ietf-pce-wson-routing-wavelength-12.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 16:57:35 -0000 --f46d04138e5f1af2bd04f81d367e Content-Type: text/plain; charset=UTF-8 Hi Young, This update reflects all my comments, I am OK with this version. Best Regards, Cyril. On 28 April 2014 12:31, Leeyoung wrote: > Hi Julien, > > This update reflects all the comments received from Cyril and Ramon as > part of the WG LC. > > Cyril, please let the WG know if this update satisfies your comment. > > Best Regards, > Young > > -----Original Message----- > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Monday, April 28, 2014 11:29 AM > To: i-d-announce@ietf.org > Cc: pce@ietf.org > Subject: [Pce] I-D Action: draft-ietf-pce-wson-routing-wavelength-12.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Path Computation Element Working Group > of the IETF. > > Title : PCEP Requirements for WSON Routing and > Wavelength Assignment > Authors : Young Lee > Greg Bernstein > Jonas Martensson > Tomonori Takeda > Takehiro Tsuritani > Oscar Gonzalez de Dios > Filename : draft-ietf-pce-wson-routing-wavelength-12.txt > Pages : 14 > Date : 2014-04-28 > > Abstract: > This memo provides application-specific requirements for the Path > Computation Element communication Protocol (PCEP) for the support of > Wavelength Switched Optical Networks (WSON). Lightpath provisioning > in WSONs requires a routing and wavelength assignment (RWA) process. > From a path computation perspective, wavelength assignment is the > process of determining which wavelength can be used on each hop of a > path and forms an additional routing constraint to optical light > path computation. Requirements for Optical impairments will be > addressed in a separate document. > > > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-pce-wson-routing-wavelength/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-pce-wson-routing-wavelength-12 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-wson-routing-wavelength-12 > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --f46d04138e5f1af2bd04f81d367e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Young,

This update reflect= s all my comments, I am OK with this version.

Best Regards,
Cyril.



On 28 April 2014 12:31, Leeyoung <leeyoung@huawei.com> wro= te:
Hi Julien,

This update reflects all the comments received from Cyril and Ramon as part= of the WG LC.

Cyril, please let the WG know if this update satisfies your comment.

Best Regards,
Young

-----Original Message-----
From: Pce [mailto:pce-bounces@ietf.= org] On Behalf Of internet-= drafts@ietf.org
Sent: Monday, April 28, 2014 11:29 AM
To: i-d-announce@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-wson-routing-wavelength-12.txt

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Path Computation Element Working Gro= up of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PCEP= Requirements for WSON Routing and Wavelength Assignment
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Young Lee=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Greg Bernstein
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Jonas Martensson
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Tomonori Takeda
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Takehiro Tsuritani
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Oscar Gonzalez de Dios
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-iet= f-pce-wson-routing-wavelength-12.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 14 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2014-04-28

Abstract:
=C2=A0 =C2=A0This memo provides application-specific requirements for the P= ath
=C2=A0 =C2=A0Computation Element communication Protocol (PCEP) for the supp= ort of
=C2=A0 =C2=A0Wavelength Switched Optical Networks (WSON). Lightpath provisi= oning
=C2=A0 =C2=A0in WSONs requires a routing and wavelength assignment (RWA) pr= ocess.
=C2=A0 =C2=A0From a path computation perspective, wavelength assignment is = the
=C2=A0 =C2=A0process of determining which wavelength can be used on each ho= p of a
=C2=A0 =C2=A0path and forms an additional routing constraint to optical lig= ht
=C2=A0 =C2=A0path computation. Requirements for Optical impairments will be=
=C2=A0 =C2=A0addressed in a separate document.





The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce= -wson-routing-wavelength/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pce-wson-rout= ing-wavelength-12

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ie= tf-pce-wson-routing-wavelength-12


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce

--f46d04138e5f1af2bd04f81d367e--