From nobody Mon Dec 1 09:18:12 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 059681A7034 for ; Mon, 1 Dec 2014 09:18:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b_jm4_A2o1Pm for ; Mon, 1 Dec 2014 09:18:08 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 010281A7028 for ; Mon, 1 Dec 2014 09:18:07 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 3836F37416F for ; Mon, 1 Dec 2014 18:18:06 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 1A1D815805B for ; Mon, 1 Dec 2014 18:18:06 +0100 (CET) Received: from [10.193.71.211] (10.197.38.6) by PEXCVZYH01.corporate.adroot.infra.ftgroup (10.114.1.186) with Microsoft SMTP Server (TLS) id 14.3.210.2; Mon, 1 Dec 2014 18:18:05 +0100 Message-ID: <12631_1417454286_547CA2CE_12631_12333_1_547CA2CA.1050804@orange.com> Date: Mon, 1 Dec 2014 18:18:02 +0100 From: Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "pce@ietf.org" Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.197.38.6] X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.1.163918 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/PcJ5gBy2uqWAmilDKMqVjQyl6Ss Subject: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01 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, 01 Dec 2014 17:18:10 -0000 Dear all, As planned, this message ignites a 3-week WG Last Call on both draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01. It will end on Monday December 22 at 11:59 PM, HST. Please send your comments to the PCE mailing list. Thanks, JP & Julien _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Mon Dec 1 11:07:55 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 D7AC71A896B for ; Mon, 1 Dec 2014 11:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 mifizFoUgFkT for ; Mon, 1 Dec 2014 11:07:48 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8C581A8969 for ; Mon, 1 Dec 2014 11:07:48 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-cd-547c6c93e714 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 74.B7.03307.39C6C745; Mon, 1 Dec 2014 14:26:44 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0195.001; Mon, 1 Dec 2014 14:07:45 -0500 From: Jeff Tantsura To: "julien.meuric@orange.com" , "pce@ietf.org" Thread-Topic: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01 Thread-Index: AQHQDYrMXlCSIzc90EirLJ94dG4O+px65sWA Date: Mon, 1 Dec 2014 19:07:45 +0000 Message-ID: References: <12631_1417454286_547CA2CE_12631_12333_1_547CA2CA.1050804@orange.com> In-Reply-To: <12631_1417454286_547CA2CE_12631_12333_1_547CA2CA.1050804@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyuXRPrO6UnJoQgzVreCz+nP7LZNF0/wa7 A5PHkiU/mTxanp1kC2CK4rJJSc3JLEst0rdL4MpYdG01W8Fivoq17fwNjB08XYycHBICJhJL li5mhbDFJC7cW8/WxcjFISRwhFGiYf0UNpCEkMAyRomuGR4gNpuAgcT/b8dZQGwRgSiJ2we3 M4HYwgJVEqcvbGWCiFdLTLnWAGUbSbxZup4dxGYRUJHoXvUdLM4rYC7R0PeQCWJ+oMT5a4eA juDg4BQIkvh6TA0kzAh0z/dTa8BKmAXEJW49mc8EcaeAxJI955khbFGJl4//gd0vKqAn8WzD ZnaIuKLEvv7p7BC9OhILdn9ig7CtJXbeuskCYWtLLFv4mhniHEGJkzOfsExgFJ+FZN0sJO2z kLTPQtI+C0n7AkbWVYwcpcWpZbnpRgabGIERdUyCTXcH456XlocYBTgYlXh4DTKrQ4RYE8uK K3MPMUpzsCiJ886qnRcsJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgbGm7/ULFjH+r5IbvXKK 70rMUTUX49mra5WSbOukqLaoVGSPoUh88uU7luW7d27/w6Qz434Wd25/xrmn4qrGDG6b5uWt NVyYKfDv+Ky4nwzO7BOCX2vu0xWO/8H6VveER+xFD7Wkqpo9AT8TJq3yW832KUH2zSXr5Yf/ HBXl4pt5hCX1S+bXDiWW4oxEQy3mouJEACr4VcmJAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/pce/1Apuq6FhmXFZgq0RuIO2y7bqtyY Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01 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, 01 Dec 2014 19:07:51 -0000 Yes/support Cheers, Jeff -----Original Message----- From: "julien.meuric@orange.com" Organization: Orange Date: Monday, December 1, 2014 at 9:18 AM To: "pce@ietf.org" Subject: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01 >Dear all, > >As planned, this message ignites a 3-week WG Last Call on both >draft-ietf-pce-pce-initiated-lsp-02 and >draft-ietf-pce-stateful-sync-optimizations-01. It will end on Monday >December 22 at 11:59 PM, HST. > >Please send your comments to the PCE mailing list. > >Thanks, > >JP & Julien > > >__________________________________________________________________________ >_______________________________________________ > >Ce message et ses pieces jointes peuvent contenir des informations >confidentielles ou privilegiees et ne doivent donc >pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >recu ce message par erreur, veuillez le signaler >a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >electroniques etant susceptibles d'alteration, >Orange decline toute responsabilite si ce message a ete altere, deforme >ou falsifie. Merci. > >This message and its attachments may contain confidential or privileged >information that may be protected by law; >they should not be distributed, used or copied without authorisation. >If you have received this email in error, please notify the sender and >delete this message and its attachments. >As emails may be altered, Orange is not liable for messages that have >been modified, changed or falsified. >Thank you. > >_______________________________________________ >Pce mailing list >Pce@ietf.org >https://www.ietf.org/mailman/listinfo/pce From nobody Mon Dec 1 11:29:14 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 0B49C1A89C4; Mon, 1 Dec 2014 11:29:11 -0800 (PST) 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 xXNdT7y4gbnv; Mon, 1 Dec 2014 11:29:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B02831A89F5; Mon, 1 Dec 2014 11:29:07 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141201192907.26347.57126.idtracker@ietfa.amsl.com> Date: Mon, 01 Dec 2014 11:29:07 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/g3YMLJFE2siX0rBv_EqnUIw2gTc Cc: pce mailing list , pce chair , RFC Editor Subject: [Pce] Document Action: 'PCEP Requirements for WSON Routing and Wavelength Assignment' to Informational RFC (draft-ietf-pce-wson-routing-wavelength-15.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, 01 Dec 2014 19:29:11 -0000 The IESG has approved the following document: - 'PCEP Requirements for WSON Routing and Wavelength Assignment' (draft-ietf-pce-wson-routing-wavelength-15.txt) as Informational RFC This document is the product of the Path Computation Element Working Group. The IESG contact persons are Adrian Farrel and Alia Atlas. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pce-wson-routing-wavelength/ Technical Summary 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 PCEP extensions in support of optical impairments will be addressed in a separate document. Working Group Summary There are some closely related I-Ds just coming out of CCAMP. The PCE WG waited until those I-Ds had completed WG last call in CCAMP to ensure compatibility. but there is no strong dependency that requires this document to be held up or reviewed at the same time as the other documents. There was nothing contentious in the WG process. Document Quality This is a requirements specification and so not ripe for implementation. Cyril Margaria & Ramon Casllas did useful LC reviews. Personnel Julien Meuric is the Document Shepherd Adrian Farrel is the Responsible Area Director From nobody Tue Dec 2 11:45:49 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 850521A6FFB for ; Tue, 2 Dec 2014 11:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, 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 5pfdYWebqf4w for ; Tue, 2 Dec 2014 11:45:46 -0800 (PST) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 722521A6FE2 for ; Tue, 2 Dec 2014 11:45:46 -0800 (PST) Received: by mail-vc0-f177.google.com with SMTP id ij19so6112400vcb.36 for ; Tue, 02 Dec 2014 11:45:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WIeApccKCnxpGzSjVZEkZGPRFVwUc09Jt6d2oCMvFKk=; b=TkbrzHGC/pPwFVSynVF64+7Djyggs7Kc/xYS17k9Yz2JUDQ3BXRmCcdFVTfZ8ObE/y Ky664BfDb9RufhBNNK2A7vykJhnPTAIKQPdrkmU7HpTTAZ3Jr3FtYXg4o0kNt2WV5KsG DTXYeVB8knrB6YWWaAiWBzepbaRM153zw8pEfJPpFyYLcKnXR2c8PIyTH6CCUFPaEGOo PzFGhdj7zp0yF+7A+aEvlv5ecaIBGEeMSBxoo5zDuqt1USzQ15a7BL4IizTzij3N+Pa2 X2+neQ91Us8UQbxK+GqAimzmtT/e/A8tPgYm23TYpu/Dv3weKJzfqmQt/uoaEwWIt50u fFNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WIeApccKCnxpGzSjVZEkZGPRFVwUc09Jt6d2oCMvFKk=; b=nG4YlcfepKhSVN8X1XJlZkace9YIqgRvusQ123kP0YL5BdG2VU6m1PQW+Umrg7UC92 TQc2AbtYH+mtDXH2C9nLa7p8F4rGz2PkdAaD4VtEcNXfeu/XQHws/5g3docq8HFwDQVd w+xAICtiXDd1Sc3btcgrPPNyIx+jvt4dxAlDbJuegNQ0e2H60wKjQZSlh3j4XbH6oygZ 2tC5zSqKCkm8nVd7ojS4gByKrLMaApmbeMYLlD2eAaPAAmhQGM9Y16XZzlqBImiyUfCG pjMbMHFZid3xZzf8VXA8v+jeyjd0CqvwCaYGgBMMa7u6EtlnGK8VQEjD1xOoo0h/KAon Yu1g== X-Gm-Message-State: ALoCoQnUgzOQgpUzefPE6D4s8EgFQYkQjyw/Uxedgm80C1Zgm0zfjT0mgB8049ZUmQUt7256VHs4 MIME-Version: 1.0 X-Received: by 10.220.101.81 with SMTP id b17mr777762vco.14.1417549545524; Tue, 02 Dec 2014 11:45:45 -0800 (PST) Received: by 10.52.254.129 with HTTP; Tue, 2 Dec 2014 11:45:45 -0800 (PST) In-Reply-To: <12631_1417454286_547CA2CE_12631_12333_1_547CA2CA.1050804@orange.com> References: <12631_1417454286_547CA2CE_12631_12333_1_547CA2CA.1050804@orange.com> Date: Tue, 2 Dec 2014 11:45:45 -0800 Message-ID: From: Ina Minei To: Julien Meuric Content-Type: multipart/alternative; boundary=047d7b3a8a7c1cf85b050940f9a7 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/pOQqGZjp0G2Xz_1UtlZZM1NlS7o Cc: "pce@ietf.org" Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01 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, 02 Dec 2014 19:45:48 -0000 --047d7b3a8a7c1cf85b050940f9a7 Content-Type: text/plain; charset=UTF-8 Support as co-author. On Mon, Dec 1, 2014 at 9:18 AM, wrote: > Dear all, > > As planned, this message ignites a 3-week WG Last Call on both > draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01. > It will end on Monday December 22 at 11:59 PM, HST. > > Please send your comments to the PCE mailing list. > > Thanks, > > JP & Julien > > > ____________________________________________________________ > _____________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --047d7b3a8a7c1cf85b050940f9a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Support as co-author.=C2=A0

On Mon, Dec 1, 2014 at 9:18 AM, <= julien.meuric@orange.com> wrote:
Dear all,

As planned, this message ignites a 3-week WG Last Call on both draft-ietf-p= ce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-opti= mizations-01. It will end on Monday December 22 at 11:59 PM, HST.

Please send your comments to the PCE mailing list.

Thanks,

JP & Julien


_____________________________________________________________= ____________________________________________________________<= br>
Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.
Thank you.

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

--047d7b3a8a7c1cf85b050940f9a7-- From nobody Tue Dec 2 11:50: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 9CA3A1A6D3F for ; Tue, 2 Dec 2014 11:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERR5BiMeGNUM for ; Tue, 2 Dec 2014 11:49:58 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0694.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:694]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA55A1A1E0E for ; Tue, 2 Dec 2014 11:49:57 -0800 (PST) Received: from CY1PR0401MB1019.namprd04.prod.outlook.com (25.160.161.11) by CY1PR0401MB1019.namprd04.prod.outlook.com (25.160.161.11) with Microsoft SMTP Server (TLS) id 15.1.26.15; Tue, 2 Dec 2014 19:49:34 +0000 Received: from CY1PR0401MB1019.namprd04.prod.outlook.com ([25.160.161.11]) by CY1PR0401MB1019.namprd04.prod.outlook.com ([25.160.161.11]) with mapi id 15.01.0026.003; Tue, 2 Dec 2014 19:49:34 +0000 From: Hariharan Ananthakrishnan To: "julien.meuric@orange.com" , "pce@ietf.org" Thread-Topic: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01 Thread-Index: AQHQDYrNfpLxEZ11x0uDuvpp4CNFcpx8MPwA Date: Tue, 2 Dec 2014 19:49:33 +0000 Message-ID: References: <12631_1417454286_547CA2CE_12631_12333_1_547CA2CA.1050804@orange.com> In-Reply-To: <12631_1417454286_547CA2CE_12631_12333_1_547CA2CA.1050804@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [38.99.127.66] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0401MB1019; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CY1PR0401MB1019; x-forefront-prvs: 0413C9F1ED x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(164054003)(189002)(377454003)(479174003)(199003)(24454002)(51704005)(31966008)(20776003)(101416001)(21056001)(33656002)(4396001)(66066001)(64706001)(36756003)(83716003)(15975445006)(87936001)(2656002)(82746002)(40100003)(50986999)(86362001)(76176999)(54356999)(19580405001)(19580395003)(92726001)(92566001)(105586002)(106116001)(95666004)(46102003)(107046002)(77156002)(99286002)(107886001)(106356001)(230783001)(122556002)(120916001)(97736003)(62966003)(68736005)(99396003)(2501002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0401MB1019; H:CY1PR0401MB1019.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-ID: <492F76036393734DA2AF2BCC65A5EA04@namprd04.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: packetdesign.com Archived-At: http://mailarchive.ietf.org/arch/msg/pce/GcZKCkgAS_ps64qtYdrlXZOV4yc Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01 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, 02 Dec 2014 19:49:59 -0000 U3VwcG9ydC4NCg0KLSBIYXJpDQoNCg0KDQoNCk9uIDAxLzEyLzIwMTQgMTc6MTgsICJqdWxpZW4u bWV1cmljQG9yYW5nZS5jb20iIDxqdWxpZW4ubWV1cmljQG9yYW5nZS5jb20+IA0Kd3JvdGU6DQoN Cj5EZWFyIGFsbCwNCj4NCj5BcyBwbGFubmVkLCB0aGlzIG1lc3NhZ2UgaWduaXRlcyBhIDMtd2Vl ayBXRyBMYXN0IENhbGwgb24gYm90aCANCj5kcmFmdC1pZXRmLXBjZS1wY2UtaW5pdGlhdGVkLWxz cC0wMiBhbmQgDQo+ZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtc3luYy1vcHRpbWl6YXRpb25zLTAx LiBJdCB3aWxsIGVuZCBvbiBNb25kYXkgDQo+RGVjZW1iZXIgMjIgYXQgMTE6NTkgUE0sIEhTVC4N Cj4NCj5QbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBQQ0UgbWFpbGluZyBsaXN0Lg0K Pg0KPlRoYW5rcywNCj4NCj5KUCAmIEp1bGllbg0KPg0KPg0KPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4NCj5DZSBt ZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1h dGlvbnMgDQo+Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRv bmMNCj5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNh dGlvbi4gU2kgdm91cyBhdmV6IA0KPnJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxl eiBsZSBzaWduYWxlcg0KPmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBs ZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyANCj5lbGVjdHJvbmlxdWVzIGV0YW50IHN1 c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQo+T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2Fi aWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgDQo+b3UgZmFsc2lmaWUu IE1lcmNpLg0KPg0KPlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWlu IGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIA0KPmluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHBy b3RlY3RlZCBieSBsYXc7DQo+dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9y IGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCANCj5kZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+QXMgZW1haWxzIG1heSBiZSBhbHRl cmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIA0KPmJlZW4g bW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPlRoYW5rIHlvdS4NCj4NCj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPlBjZSBtYWlsaW5nIGxp c3QNCj5QY2VAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3BjZQ0K From nobody Tue Dec 2 19:10: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 D35BB1A0052 for ; Tue, 2 Dec 2014 19:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWjD8se3l-k0 for ; Tue, 2 Dec 2014 19:09:54 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4A7A1A0008 for ; Tue, 2 Dec 2014 19:09:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1878; q=dns/txt; s=iport; t=1417576193; x=1418785793; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=17tAaAfVZGvdc/MI4VGgivbhgp4ouA2chYoQ1YGT26Y=; b=ILiSbbhpXypC+iTfGMGP1NM8k6eFZ2ASjsPDOw+LTMlHE7ZIFbPEzW46 U/BPIPwJIjq+aCFrwWjTUs5GtH9k91tEAdoqeSvS9CBGkgsCsZJEvleIM a3eG1kC4kK4aPfOLUI3KVHd51p8SCtt84GXCAGuDegHHI5eaT10DnuV+4 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFACJ+flStJV2a/2dsb2JhbABbgwdSWQTHCQqGHwKBFRYBAQEBAX2EAwEBBAEBATc0GwIBCA4oBQsnCyUCBAESiEAN1g8BAQEBAQEBAQEBAQEBAQEBAQEBFQSQDREBSwyESAEEkGGLJYEsgziMO4QCgjeBRG+BDTmBAQEBAQ X-IronPort-AV: E=Sophos;i="5.07,505,1413244800"; d="scan'208";a="102124291" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP; 03 Dec 2014 03:09:53 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sB339riX032152 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Dec 2014 03:09:53 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.7]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Tue, 2 Dec 2014 21:09:52 -0600 From: "Jan Medved (jmedved)" To: Hariharan Ananthakrishnan , "julien.meuric@orange.com" , "pce@ietf.org" Thread-Topic: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01 Thread-Index: AQHQDYrN5lVmRLsMFk6So5BT8xh3spx9G6+A///0KQA= Date: Wed, 3 Dec 2014 03:09:52 +0000 Message-ID: References: <12631_1417454286_547CA2CE_12631_12333_1_547CA2CA.1050804@orange.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [10.24.194.145] Content-Type: text/plain; charset="us-ascii" Content-ID: <91D22629B3B42F42B94986B6439E34C9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/csKfO_jYeBFn0Ax82W1gDka00B4 Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01 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, 03 Dec 2014 03:09:56 -0000 Support on both On 12/2/14, 11:49 AM, "Hariharan Ananthakrishnan" wrote: >Support. > >- Hari > > > > >On 01/12/2014 17:18, "julien.meuric@orange.com" > >wrote: > >>Dear all, >> >>As planned, this message ignites a 3-week WG Last Call on both >>draft-ietf-pce-pce-initiated-lsp-02 and >>draft-ietf-pce-stateful-sync-optimizations-01. It will end on Monday >>December 22 at 11:59 PM, HST. >> >>Please send your comments to the PCE mailing list. >> >>Thanks, >> >>JP & Julien >> >> >>_________________________________________________________________________ >>_ >>_______________________________________________ >> >>Ce message et ses pieces jointes peuvent contenir des informations >>confidentielles ou privilegiees et ne doivent donc >>pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >>recu ce message par erreur, veuillez le signaler >>a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >>electroniques etant susceptibles d'alteration, >>Orange decline toute responsabilite si ce message a ete altere, deforme >>ou falsifie. Merci. >> >>This message and its attachments may contain confidential or privileged >>information that may be protected by law; >>they should not be distributed, used or copied without authorisation. >>If you have received this email in error, please notify the sender and >>delete this message and its attachments. >>As emails may be altered, Orange is not liable for messages that have >>been modified, changed or falsified. >>Thank you. >> >>_______________________________________________ >>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 Dec 4 08:50:10 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 71E741AD4F9 for ; Thu, 4 Dec 2014 08:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 8-pOKIX_DR2a for ; Thu, 4 Dec 2014 08:50:03 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 996701AD4E0 for ; Thu, 4 Dec 2014 08:49:41 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 270BB5A8BFF1F; Thu, 4 Dec 2014 16:49:37 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id sB4GndnP022072 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Dec 2014 17:49:39 +0100 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.228]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 17:49:39 +0100 From: "BELOTTI, SERGIO (SERGIO)" To: "julien.meuric@orange.com" , "pce@ietf.org" Thread-Topic: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01 Thread-Index: AQHQDYrMZlVMJ2H6TESdsRwzQQLQWZx/onfQ Date: Thu, 4 Dec 2014 16:49:38 +0000 Message-ID: References: <12631_1417454286_547CA2CE_12631_12333_1_547CA2CA.1050804@orange.com> In-Reply-To: <12631_1417454286_547CA2CE_12631_12333_1_547CA2CA.1050804@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.38] 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/Gop6F7V284uTKpPhetQeJxWq4MY Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01 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, 04 Dec 2014 16:50:07 -0000 Support both but with two comments : Draft-ietf-pce-pce-initiated-lsp-02:=20 in the 3.2 Operation Overview is mentioned R flag in SRP object before to h= ave defined it (this is new ). So I would suggest, as in other PCE-drafts, = to ad a little session about the NEW PCEP things introduced that means : New PCEP message --> INITIATE New flag I in the Stateful PCE capability TLV New flag R in SRP object New flag C in LSP object Draft-ietf-pce-stateful-synch-optimization-01: Just an editorial note , in figure 7 it is likely to be D=3D1 not T=3D1 sin= ce the example is for incremental delta syncronization . Thanks Sergio -----Original Message----- From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of julien.meuric@orange.c= om Sent: luned=EC 1 dicembre 2014 18:18 To: pce@ietf.org Subject: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draf= t-ietf-pce-stateful-sync-optimizations-01 Dear all, As planned, this message ignites a 3-week WG Last Call on both draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimi= zations-01. It will end on Monday December 22 at 11:59 PM, HST. Please send your comments to the PCE mailing list. Thanks, JP & Julien ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From nobody Thu Dec 4 09:50:15 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 E4B091A1BDE for ; Thu, 4 Dec 2014 09:50:13 -0800 (PST) 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 9ZfT_Hou6UoA for ; Thu, 4 Dec 2014 09:50:12 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FC441A1BB3 for ; Thu, 4 Dec 2014 09:50:12 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id sB4HoAJ3007567 for ; Thu, 4 Dec 2014 17:50:10 GMT 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 sB4Ho9HL007511 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 4 Dec 2014 17:50:09 GMT From: "Adrian Farrel" To: Date: Thu, 4 Dec 2014 17:50:04 -0000 Message-ID: <0fad01d00fea$bc930520$35b90f60$@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: AdAP6mdYl+vDhKOGQ/+Pc+N2+vXdHw== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21150.001 X-TM-AS-Result: No--0.713-10.0-31-10 X-imss-scan-details: No--0.713-10.0-31-10 X-TMASE-MatchedRID: LCb8eCaOGWC6de0YULw0Fq+dYEguu4aVGWAN/II9wcQnyZAGkQFaTqPF jJEFr+olfeZdJ1XsorgUBfgS1SLQ+AtuKBGekqUpbGVEmIfjf3t6jtQmKy48pG9EGXzOsLp8GEf oj7eeji8/3Wk9dGhstWV0Kgrvvcynuet5r9Bdhvd06cjxY8Ylm1csa0AGV/SbwvwdumFAO/g= Archived-At: http://mailarchive.ietf.org/arch/msg/pce/1r_CTkE41OKCj9s6HSo6L798Ewc Subject: [Pce] Recharter and TEAS 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, 04 Dec 2014 17:50:14 -0000 Hi, The IESG has just approved the creation of TEAS and the re-chartering of PCE was approved on 11/25. Formal announcements of these changes will come out soon and I will be working with all of the chairs to ensure that documents are assigned to the right WGs and that milestones are posted. Adrian From nobody Fri Dec 5 07:50: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 886541A1A0F; Fri, 5 Dec 2014 07:50:12 -0800 (PST) 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 kET0YtCCtTCS; Fri, 5 Dec 2014 07:50:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D9BD21ACEDC; Fri, 5 Dec 2014 07:50:08 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141205155008.3527.31348.idtracker@ietfa.amsl.com> Date: Fri, 05 Dec 2014 07:50:08 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/_86nKX2jDiLtZx2DfydfprofcIg Cc: pce WG Subject: [Pce] WG Action: Rechartered Path Computation Element (pce) 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: Fri, 05 Dec 2014 15:50:12 -0000 The Path Computation Element (pce) working group in the Routing Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. Path Computation Element (pce) ------------------------------------------------ Current Status: Active WG Chairs: JP Vasseur Julien Meuric Secretaries: Daniel King Assigned Area Director: Adrian Farrel Mailing list Address: pce@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/pce Archive: http://www.ietf.org/mail-archive/web/pce/ Charter: The PCE Working Group is chartered to specify the required protocols so as to enable a Path Computation Element (PCE)-based architecture for the computation of paths for MPLS and GMPLS Point to Point and Point to Multi-point Traffic Engineered LSPs. In this architecture path computation does not necessarily occur on the head-end (ingress) LSR, but on some other path computation entity that may not be physically located on each head-end LSR. The TEAS Working Group is responsible for defining and extending architectures for Traffic Engineering (TE) and it is expected that the PCE and TEAS WGs will work closely together on elements of TE architectures that utilize PCE. The PCE WG works on the application of this model within a single domain or within a group of domains (where a domain is a layer, IGP area or Autonomous System with limited visibility from the head-end LSR). At this time, applying this model to large groups of domains such as the Internet is not thought to be possible, and the PCE WG will not spend energy on that topic. The WG specifies the PCE communication Protocol (PCEP) and needed extensions for communication between Path Computation Clients (PCCs) and PCEs, and between cooperating PCEs. Security mechanisms such as authentication and confidentiality are included. The WG determines requirements for extensions to existing routing and signaling protocols in support of the PCE architecture and the signaling of inter-domain paths (e.g., RSVP-TE and its GMPLS variations). Any necessary extensions will be produced in collaboration with the Working Groups responsible for the protocols. The WG also works on the mechanisms to for multi-layer path computation and PCEP extensions for communication between several network layers. The WG defines the required PCEP extensions for Wavelength Switched Optical Networks (WSON) while keeping consistency with the GMPLS protocols specified in the CCAMP and TEAS WGs. Work Items: - PCEP extensions to support MPLS and GMPLS Traffic Engineered LSP path computation models involving PCEs. This includes the case of computing the paths of intra- and inter-domain TE LSPs. Such path computation includes the generation of primary, protection and recovery paths, as well as computations for (local/global) reoptimization and load balancing. Both intra- and inter-domain applications are covered. - In cooperation with the TEAS Working Group, development of PCE- based architectures for Traffic Engineering. - In cooperation with protocol specific Working Group (e.g., MPLS, CCAMP), development of LSP signaling (RSVP-TE) extensions required to support PCE-based path computation models. - Specification of PCEP extensions for expressing path computation requests and responses in the various GMPLS-controlled networks, including WSON. - Definition of PCEP extensions for path computation in multi-layer networks. - Definition of the PCEP extensions used by a stateful PCE for recommending a new path for an existing or new LSP to the PCC/PCE. Further protocol extensions must cover the case where receiving PCC/PCE chooses to not follow the recommendation. Milestones: Done - Submit first draft of PCE architecture document Done - Submit first draft of PCE discovery requirements and protocol extensions documents Done - Submit first draft of the PCE communication protocol requirements Done - Submit first draft of the definition of objective metrics Done - Submit first draft of the PCE communication protocol specification Done - Submit PCE architecture specification to the IESG to be considered as Informational RFC Done - Submit first draft of the MIB module for the PCE protocol Done - Submit PCE communication protocol requirements to the IESG to be considered as an Informational RFC Done - Submit PCE discovery protocol extensions specifications to the IESG to be considered as a Proposed Standard Done - Submit PCE communication protocol specification to the IESG to be considered as a Proposed Standard Done - Submit first draft of the PCE P2MP communication requirements Done - Submit first draft of the PCE P2MP PCEP protocol extensions Done - Submit PCE P2MP communication requirements to the IESG to be considered as an Informational RFC Done - Submit PCE P2MP PCEP protocol extensions to the IESG to be considered as an Proposed Standard RFC Done - Submit applicability and metrics documents to the IESG Done - Submit the GMPLS requirements to the IESG to be considered as an Informational RFC Sep 2013 - Submit inter-area/AS applicability statement to the IESG as an informational RFC Sep 2013 - Submit PCEP extensions for GMPLS to the IESG to be considered as a Proposed Standard Nov 2013 - Submit inter-layer extensions to the IESG to be considered as a Proposed Standard Nov 2013 - Submit extensions for hierarchical model to the IESG to be considered as a Proposed Standard Jan 2014 - Submit the PCEP MIB to the IESG to be considered as a Proposed Standard Apr 2014 - Submit the discovery MIB to the IESG to be considered as a Proposed Standard Apr 2014 - Submit P2MP MIB to the IESG to be considered as a Proposed Standard Sep 2014 - Submit the stateful PCE document(s) to the IESG Feb 2015 - Evaluate WG progress, recharter or close From nobody Fri Dec 5 15:38:56 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 371A71A7000 for ; Fri, 5 Dec 2014 15:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 VVC5aXXOYDtO for ; Fri, 5 Dec 2014 15:38:53 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1A431A6FFF for ; Fri, 5 Dec 2014 15:38:52 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 25D512A41CD4B for ; Fri, 5 Dec 2014 23:38:45 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id sB5Ncmot026011 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 5 Dec 2014 18:38:48 -0500 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.84]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Fri, 5 Dec 2014 18:38:48 -0500 From: "Aissaoui, Mustapha (Mustapha)" To: "pce@ietf.org" Thread-Topic: Path Computation Request in Active Stateful PCE Thread-Index: AdAQ5J2m2IxfSn+OQtqRXzt/b1cSZw== Date: Fri, 5 Dec 2014 23:38:48 +0000 Message-ID: <4A79394211F1AF4EB57D998426C9340D947BA673@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_4A79394211F1AF4EB57D998426C9340D947BA673US70UWXCHMBA04z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/80U9XDfR6jugmblBmX0731cNlTU Subject: [Pce] Path Computation Request in Active Stateful PCE 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: Fri, 05 Dec 2014 23:38:55 -0000 --_000_4A79394211F1AF4EB57D998426C9340D947BA673US70UWXCHMBA04z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, The use of PCReq/PCRep messages with the passive stateful PCE is well docum= ented in draft-ietf-pce-stateful-pce-10. There is however no explicit proce= dures for using PCReq/PCRep with active stateful PCE. There are cases where the router will not be able to compute the initial pa= th for an LSP configured on the router. This can be for example a Segment R= outing TE LSP which has a bandwidth requirement. In this case, the LSP will= remain down until PCE computes a path for it. In such a case, the PCC must make a request to PCE for the computation of t= he initial path for the LSP. I can think of two different ways for achievin= g this but none of these are explicitly described in the draft: 1. The PCC starts with the passive stateful procedures and uses the PCRe= q/PCRep message to request the initial path for the LSP. If the PCE returns= a path, then the PCC can delegate the LSP to the PCE in the subsequent PCR= pt message after the LSP is instantiated on the PCC. From there on, the act= ive stateful procedures with PCRpt/PCUpd messages can be followed until suc= h time the LSP delegation is changed. This method seems appropriate and com= plete but it is not described in the draft. In other words, there is no sta= tement that an active stateful PCE can operate in passive mode for a given = LSP when delegation of the LSP has not been given to it. 2. The PCC starts in the active stateful mode and delegates the LSP, whi= ch is in down state, using the PCRpt message. In this case, the PCRpt is us= ed to synchronize the state of the LSP with the PCE but also as an implicit= way to request the initial LSP path computation. The issue though is that = the PCRpt message is not an explicit path computation request and lacks the= following: a. path request timeout: draft-ietf-pce-stateful-pce-10 does not describe a timer mechanism that a P= CC might use to detect an initial path request timeout. From reading the dr= aft, the PCE is not mandated to compute a path and send a PCUpd message in = response to a PCRpt message even when the LSP is down. b. No path found by PCE: Even if one assumes that the PCE attempts a path computation within a reaso= nable time from receiving the PCRpt message, how will it communicate to PCC= a failure to find a path for that LSP? c. Synchronous path computation: How can a PCC request synchronous path computation for a set of link/node/S= RLG disjoint LSP paths? With PCReq/PCRep, this was possible via the SVEC ob= ject. I appreciate if you could provide comments on the above points. Regards, Mustapha. --_000_4A79394211F1AF4EB57D998426C9340D947BA673US70UWXCHMBA04z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

The use of PCReq/PCRep messages with the = passive stateful PCE is well documented in draft-ietf-pce-stateful-pce-10. = There is however no explicit procedures for using PCReq/PCRep with active stateful PCE.

 

There are cases where the router will not= be able to compute the initial path for an LSP configured on the router. T= his can be for example a Segment Routing TE LSP which has a bandwidth requirement. In this case, the LSP will remain down until PCE = computes a path for it.

 

In such a case, the PCC must make a reque= st to PCE for the computation of the initial path for the LSP. I can think = of two different ways for achieving this but none of these are explicitly described in the draft:

 

1.<= span style=3D"font:7.0pt "Times New Roman"">    The PCC starts with the passive s= tateful procedures and uses the PCReq/PCRep message to request the initial = path for the LSP. If the PCE returns a path, then the PCC can delegate the LSP to the PCE in the subsequent PCRpt message after = the LSP is instantiated on the PCC. From there on, the active stateful proc= edures with PCRpt/PCUpd messages can be followed until such time the LSP de= legation is changed. This method seems appropriate and complete but it is not described in the draft. In ot= her words, there is no statement that an active stateful PCE can operate in= passive mode for a given LSP when delegation of the LSP has not been given= to it.

 

2.<= span style=3D"font:7.0pt "Times New Roman"">    The PCC starts in the active stat= eful mode and delegates the LSP, which is in down state, using the PCRpt me= ssage. In this case, the PCRpt is used to synchronize the state of the LSP with the PCE but also as an implicit way to request t= he initial LSP path computation. The issue though is that the PCRpt message= is not an explicit path computation request and lacks the following:<= /o:p>

 

a.    path request timeout:

draft-= ietf-pce-stateful-pce-10 does not describe a timer mechanism that a PCC mig= ht use to detect an initial path request timeout. From reading the draft, the PCE is not mandated to compute a path and send a PCUpd mess= age in response to a PCRpt message even when the LSP is down.

&= nbsp;

b.    No path found by PCE:<= /span>

Even i= f one assumes that the PCE attempts a path computation within a reasonable = time from receiving the PCRpt message, how will it communicate to PCC a failure to find a path for that LSP?

&= nbsp;

c.    Synchronous path computation:

How ca= n a PCC request synchronous path computation for a set of link/node/SRLG di= sjoint LSP paths? With PCReq/PCRep, this was possible via the SVEC object.

 

I appreciate if you could provide comment= s on the above points.

 

Regards,

Mustapha.

--_000_4A79394211F1AF4EB57D998426C9340D947BA673US70UWXCHMBA04z_-- From nobody Fri Dec 5 22:24: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 D3EFA1A1B59 for ; Fri, 5 Dec 2014 22:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 xzT-OVL0vzny for ; Fri, 5 Dec 2014 22:24:23 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B34A1A01EC for ; Fri, 5 Dec 2014 22:24:23 -0800 (PST) Received: by mail-ig0-f172.google.com with SMTP id hl2so403240igb.17 for ; Fri, 05 Dec 2014 22:24:22 -0800 (PST) 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=a4H/XaY6yPlduRLMKXjRLRya1quhF1vzMWUJCbqrZ7w=; b=I6GZpCUrN3xmwN4FWDlFbVYky+45bgUQN3568EFCAPHIvtzxMU1l6U40oKjxtlX+QO ic8hGrW/E5QpxLSV3nJfgdhb4F2WDQGKFJ0B0CC7Ut5nL6RpCPKxFHHoRfQgFTDkZXcP HuyIvXIvzFYW5+Q31W7KI294K2XKiuDMjFaA5h1w2DBeE0pyDSy8kL2Ba1faIVhztYuO tO9VZ6TNl9QpilUNoIV2L9jLLA8jKB8b3gejdnhjWwF1l7HWwONJ3Kre6hOGtB2GLgT4 WAC/rSNMUFNec0xHaB+A9ivo44L0zxhPXKLy9Af0X2YJUsm+GoyC/kbqpF0DknllRhb0 /rVg== MIME-Version: 1.0 X-Received: by 10.50.39.15 with SMTP id l15mr5931072igk.49.1417847062244; Fri, 05 Dec 2014 22:24:22 -0800 (PST) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.154.68 with HTTP; Fri, 5 Dec 2014 22:24:22 -0800 (PST) In-Reply-To: <4A79394211F1AF4EB57D998426C9340D947BA673@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <4A79394211F1AF4EB57D998426C9340D947BA673@US70UWXCHMBA04.zam.alcatel-lucent.com> Date: Sat, 6 Dec 2014 11:54:22 +0530 X-Google-Sender-Auth: fsetPePgRY7g8ocx0nnKF0970FA Message-ID: From: Dhruv Dhody To: "Aissaoui, Mustapha (Mustapha)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/6rhs5h-biXCol7n-IY5Vq2_sftQ Cc: "pce@ietf.org" Subject: Re: [Pce] Path Computation Request in Active Stateful PCE 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: Sat, 06 Dec 2014 06:24:26 -0000 Hi Mustapha, Since delegation is applied per LSP and not all LSPs are delegated it is perfectly fine for an active stateful PCE to receive PCReq/PCRep. In your mail you apply a passive / active property to whole PCC/PCE which is not correct. I see this as - Stateless PCE Stateless PCE + PCRpt (LSPBD) = Passive Stateful PCE Stateless PCE + PCRpt (LSPBD) + PCUpd (delegation) = Active Stateful PCE At the same time, someone may choose to implement (as per some SDN like deployment) to only support delegation. But that is their choice. Some more inline.... On Sat, Dec 6, 2014 at 5:08 AM, Aissaoui, Mustapha (Mustapha) wrote: > Dear all, > > The use of PCReq/PCRep messages with the passive stateful PCE is well > documented in draft-ietf-pce-stateful-pce-10. There is however no explicit > procedures for using PCReq/PCRep with active stateful PCE. > To me this is implicit, as above. > > > There are cases where the router will not be able to compute the initial > path for an LSP configured on the router. This can be for example a Segment > Routing TE LSP which has a bandwidth requirement. In this case, the LSP will > remain down until PCE computes a path for it. > > > > In such a case, the PCC must make a request to PCE for the computation of > the initial path for the LSP. I can think of two different ways for > achieving this but none of these are explicitly described in the draft: > > > > 1. The PCC starts with the passive stateful procedures and uses the > PCReq/PCRep message to request the initial path for the LSP. If the PCE > returns a path, then the PCC can delegate the LSP to the PCE in the > subsequent PCRpt message after the LSP is instantiated on the PCC. From > there on, the active stateful procedures with PCRpt/PCUpd messages can be > followed until such time the LSP delegation is changed. This method seems > appropriate and complete but it is not described in the draft. In other > words, there is no statement that an active stateful PCE can operate in > passive mode for a given LSP when delegation of the LSP has not been given > to it. > > Correct! Since delegation is applied per LSP, PCC should be able to use PCReq/PCRep (passive) for an undelegated LSP and later delegate the same LSP. Need for text can be evaluated by the WG. > > 2. The PCC starts in the active stateful mode and delegates the LSP, > which is in down state, using the PCRpt message. In this case, the PCRpt is > used to synchronize the state of the LSP with the PCE but also as an > implicit way to request the initial LSP path computation. The issue though > is that the PCRpt message is not an explicit path computation request and > lacks the following: > > It is completely fine for PCC to delegate an unsignalled LSP to PCE. But I think we should not equate a path computation request with delegation completely. With delegation your aim is to give up some control and let PCE run the show, one should not expect the behavior of this action to be exactly same as a path computation request/response. > > a. path request timeout: > > draft-ietf-pce-stateful-pce-10 does not describe a timer mechanism that a > PCC might use to detect an initial path request timeout. From reading the > draft, the PCE is not mandated to compute a path and send a PCUpd message in > response to a PCRpt message even when the LSP is down. > > PCC can have faith in the PCE to respond as it sees fit based on the overall network. PCC can always choose to revoke the delegation if it is not happy. > > b. No path found by PCE: > > Even if one assumes that the PCE attempts a path computation within a > reasonable time from receiving the PCRpt message, how will it communicate to > PCC a failure to find a path for that LSP? > This is interesting, can a PCUpd message with empty ERO fulfill this? Another interesting case is when the path is not found because of some constraint, PCE can still send PCUpd message with a path relaxing some constraints and its attributes. PCC has a choice to accept them or not. > > > c. Synchronous path computation: > > How can a PCC request synchronous path computation for a set of > link/node/SRLG disjoint LSP paths? With PCReq/PCRep, this was possible via > the SVEC object. > > We need to enhance the mechanism to group LSPs via [1] to consider the above. It is in my to do list :) [1] http://datatracker.ietf.org/doc/draft-minei-pce-association-group/ Regards, Dhruv > > I appreciate if you could provide comments on the above points. > > > > Regards, > > Mustapha. > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > From nobody Sun Dec 7 06:31: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 540E51A876A for ; Sun, 7 Dec 2014 06:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 XjpZK22Se-b8 for ; Sun, 7 Dec 2014 06:31:02 -0800 (PST) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F9261A8768 for ; Sun, 7 Dec 2014 06:31:02 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id ex7so2654376wid.0 for ; Sun, 07 Dec 2014 06:31:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=p99yAJUjTvhwgRLrjVOzKtCgsnjqsfv9pOC6oBxeC8Y=; b=kw4SawKA+4xAy7SsnJaOx0KVUFk2eromzoDcH3/j47ESpEhI3cUgg/0vxAeJciaYg4 6lZqbZzl1n/d5a1jbUjxJsocv2zdjDm9HTNWxMMolBl7HRujXqYMlbS5HzO0/iTpEd0/ vuovCvm7JnQ0q5CDSIkHpf7DMqjzykxADQTMHRCmQ4vsq2XmAyv/k12EtzcEmat1vTLP ufKAQdbsotQoWcpvl6Lqow13w+vt5erd699JgsaShGAJnjKfxTh3nG48iYgDod3IwzuX vLyUitzWtiOfysuAMPMwOTWUdq9ZE9TLi3rYK3oGR8SVwNSBG5qR9xQX9FodWCPQMEpj NF1g== X-Gm-Message-State: ALoCoQnVIhX4cHcAfVY5gynOt0TgP+tQoj0UfKf+m+2WGiSXPtL36uQJUhnaCIaUbAbYKMXUp4d1 X-Received: by 10.180.105.131 with SMTP id gm3mr18079795wib.34.1417962661273; Sun, 07 Dec 2014 06:31:01 -0800 (PST) Received: from MAL ([31.6.35.172]) by mx.google.com with ESMTPSA id gl5sm6038808wib.0.2014.12.07.06.30.59 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 07 Dec 2014 06:31:00 -0800 (PST) Sender: Daniel King X-Google-Original-Sender: "Daniel King" From: "'Daniel King'" To: Date: Sun, 7 Dec 2014 14:31:00 -0000 Message-ID: <001001d0122a$6c96e860$45c4b920$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01D0122A.6C9784A0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdASKk5ny4AiDaBBTg69PHzhvpCijQ== Content-Language: en-gb Archived-At: http://mailarchive.ietf.org/arch/msg/pce/ZylqBdEcZbQUBeLeHEOWj4AONAg Subject: [Pce] IETF 91 Minutes for PCE Session 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: Sun, 07 Dec 2014 14:31:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0011_01D0122A.6C9784A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Folks, Please note the IETF 91 minutes were uploaded: https://tools.ietf.org/wg/pce/minutes?item=minutes-91-pce.html If you have any amendments or updates please let us know. Thanks again to Jon for taking the minutes BR, Dan. ------=_NextPart_000_0011_01D0122A.6C9784A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Folks,

 

Please note = the IETF 91 minutes were uploaded:

 

https://tools.ietf.org/wg/pce/minutes?item=3Dminutes-91-pce.html

 

If you have any amendments or updates please let us = know.

 

Thanks again to Jon for taking the = minutes

 

BR, Dan.

 

------=_NextPart_000_0011_01D0122A.6C9784A0-- From nobody Sun Dec 7 21:37: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 5593E1A6F03; Sun, 7 Dec 2014 21:37:45 -0800 (PST) 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 L0afGHhdqEKo; Sun, 7 Dec 2014 21:37:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D561A6EFE; Sun, 7 Dec 2014 21:37:44 -0800 (PST) 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.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141208053744.1060.44402.idtracker@ietfa.amsl.com> Date: Sun, 07 Dec 2014 21:37:44 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/eQS6ATquSzzj1QsgWz20_hnvqVI Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-pcep-service-aware-06.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, 08 Dec 2014 05:37:45 -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 : Extensions to the Path Computation Element Communication Protocol (PCEP) to compute service aware Label Switched Path (LSP). Authors : Dhruv Dhody Qin Wu Vishwas Manral Zafar Ali Kenji Kumaki Filename : draft-ietf-pce-pcep-service-aware-06.txt Pages : 27 Date : 2014-12-07 Abstract: In certain networks like financial information network (stock/ commodity trading) and enterprises using cloud based applications, Latency (delay), Latency Variation (jitter) and Packet Loss is becoming a key requirement for path computation along with other constraints and metrics. Latency, Latency Variation and Packet Loss is associated with the Service Level Agreement (SLA) between customers and service providers. The Link Bandwidth Utilization (the total bandwidth of a link in current use for the forwarding) is also an important factor to consider during path computation. IGP Traffic Engineering (TE) Metric extensions describes mechanisms with which network performance information is distributed via OSPF and IS-IS respectively. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. This document describes the extension to PCEP to carry Latency, Latency Variation, Packet Loss, and Link Bandwidth Utilization as constraints for end to end path computation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-service-aware/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-pcep-service-aware-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-service-aware-06 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 Sun Dec 7 21:46:13 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 784411A6F1D for ; Sun, 7 Dec 2014 21:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 5eB_fzFMBWth for ; Sun, 7 Dec 2014 21:46:10 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 404121A6F13 for ; Sun, 7 Dec 2014 21:46:10 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPT78413; Mon, 08 Dec 2014 05:46:08 +0000 (GMT) Received: from blreml403-hub.china.huawei.com (10.18.96.135) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 8 Dec 2014 05:46:08 +0000 Received: from BLREML504-MBX.china.huawei.com ([169.254.1.96]) by blreml403-hub.china.huawei.com ([10.18.96.135]) with mapi id 14.03.0158.001; Mon, 8 Dec 2014 11:16:00 +0530 From: Dhruv Dhody To: "pce@ietf.org" Thread-Topic: [Pce] Regd pcep-service-aware & pcep-link-bw-utilization drafts Thread-Index: AQHP/8dlYJqgg6TiX0y9lEG0Y2QgK5yFUzUQ Date: Mon, 8 Dec 2014 05:45:59 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B86FFF683@blreml504-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.146.248] 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/aoVpimOASqeK85b6SFPJP8xh3ic Subject: Re: [Pce] Regd pcep-service-aware & pcep-link-bw-utilization drafts 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, 08 Dec 2014 05:46:12 -0000 Hi WG,=20 We have uploaded the merged document.=20 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-service-aware/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-pcep-service-aware-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-pcep-service-aware-06 Note that there are no major technical change, just reorganization to accom= modate the draft-wu-pce-pcep-link-bw-utilization text.=20 Request WG to have a relook and provide comments on this version. As the co= mpanion OSPF/ISIS WG documents have made progress and heading to IESG, we w= ould be requesting PCE WG to move this document along as well.=20 Thanks!=20 Dhruv=20 > -----Original Message----- > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Dhruv Dhody > Sent: 14 November 2014 10:26 > To: pce@ietf.org > Subject: [Pce] Regd pcep-service-aware & pcep-link-bw-utilization > drafts >=20 > Hi, >=20 > During the discussion with chairs regarding moving the following > drafts along - >=20 > http://datatracker.ietf.org/doc/draft-ietf-pce-pcep-service-aware/ > http://datatracker.ietf.org/doc/draft-wu-pce-pcep-link-bw- > utilization/ >=20 > It was pointed out that for the sake of consistency with OSPF/ISIS- > metric extension documents (in post-WG-LC and ongoing-WG-LC), that > having a single merged document from PCEP would be a better choice. >=20 > We can merge the second document content into the first one and get a > new version out soon after IETF week, once the dust is settled. >=20 > If you have concerns with this approach, do let us know. >=20 > Thanks! > Dhruv >=20 > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From nobody Mon Dec 8 11:44: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 6F9C11A8859 for ; Mon, 8 Dec 2014 11:44:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaBM9Jrp0QKq for ; Mon, 8 Dec 2014 11:44:38 -0800 (PST) Received: from mail-vc0-x241.google.com (mail-vc0-x241.google.com [IPv6:2607:f8b0:400c:c03::241]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B644D1A8772 for ; Mon, 8 Dec 2014 11:44:37 -0800 (PST) Received: by mail-vc0-f193.google.com with SMTP id hq11so667091vcb.4 for ; Mon, 08 Dec 2014 11:44:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Ow+dxA7R1FbbwZR1jg/G7PEaf/JX9m45xcljW2O97wQ=; b=y2vL7vQEDkt2+hoBOJF7rwOpkis31ADceZIMC5KEKQtZLE8w12UVH4PFo8yQJaiLbC Fk/SigXXyPgswXGPhgSoTgsNmZIxgMVm8oDCSGFjbohttHTdb/z7YaWOtrAEYH8+sIT8 9xjowz35dw3h/4S3PwlEr/glzOD+vfbtEEB3pChbemzbufVIDWuvPSJXD12N9qZsdpVo JB6sUO9xI7pZ+NTGMhcryib1apBMYyF6zKRd9FwKyq2DN35M/unQFecTc9L43ELFiCy7 0NkIgsfKKYzLwi7g7XKARKA+gQp3bLZ8OtOjyI/Wp7N2aCIngKsjDJse1ykTlvuQz1Ni N2pQ== MIME-Version: 1.0 X-Received: by 10.220.103.74 with SMTP id j10mr26305751vco.58.1418067876842; Mon, 08 Dec 2014 11:44:36 -0800 (PST) Received: by 10.31.16.159 with HTTP; Mon, 8 Dec 2014 11:44:36 -0800 (PST) In-Reply-To: References: Date: Mon, 8 Dec 2014 11:44:36 -0800 Message-ID: From: Girish Birajdar To: pce@ietf.org, dhruv.ietf@gmail.com Content-Type: multipart/alternative; boundary=047d7b343ada1112060509b9a8d0 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/s0DoNvRSgh5g8dawr-NA-LDPXFE Subject: Re: [Pce] Pce Digest, Vol 123, Issue 6 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, 08 Dec 2014 19:44:39 -0000 --047d7b343ada1112060509b9a8d0 Content-Type: text/plain; charset=UTF-8 Hi Dhruv, Thanks for the response. Few questions/comments, please see inline On Sat, Dec 6, 2014 at 12:00 PM, wrote: > > Date: Sat, 6 Dec 2014 11:54:22 +0530 > From: Dhruv Dhody > To: "Aissaoui, Mustapha (Mustapha)" > > Cc: "pce@ietf.org" > Subject: Re: [Pce] Path Computation Request in Active Stateful PCE > Message-ID: > < > CAB75xn5iv5oKS02Sd2UfVUDrZhGgPR2isZqGRXkBonfQYX8nXw@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi Mustapha, > > Since delegation is applied per LSP and not all LSPs are delegated it > is perfectly fine for an active stateful PCE to receive PCReq/PCRep. > In your mail you apply a passive / active property to whole PCC/PCE > which is not correct. > > I see this as - > > Stateless PCE > Stateless PCE + PCRpt (LSPBD) = Passive Stateful PCE > Stateless PCE + PCRpt (LSPBD) + PCUpd (delegation) = Active Stateful PCE > The draft too mentions this as definitions. Active stateful PCE is extension to functionality supported by passive stateful PCE. However the interaction shown in section 5.6.1 and 5.6.2 gives impression that PCRequest is handled by PCE acting as "passive stateful" and not "active stateful". Verbatim interpretation of these section contradict the definitions given in beginning of the draft. Would it be possible for the authors to address this issue in next draft, unless the the description in section 5.6.1 is not meant for "active stateful" PCE. > At the same time, someone may choose to implement (as per some SDN > like deployment) to only support delegation. But that is their choice. > In case one implements a PCE only with "PCRpt (LSPBD) + PCUpd (delegation)", is it expected to respond to a PCRpt with down path in case the path was not computed at PCE? The draft is clear about use of PCUpd - mainly to handle topology events that affect existing paths or to allow operator to optimize network. > > > > > > 2. The PCC starts in the active stateful mode and delegates the LSP, > > which is in down state, using the PCRpt message. In this case, the PCRpt > is > > used to synchronize the state of the LSP with the PCE but also as an > > implicit way to request the initial LSP path computation. The issue > though > > is that the PCRpt message is not an explicit path computation request and > > lacks the following: > > > > > > It is completely fine for PCC to delegate an unsignalled LSP to PCE. > But I think we should not equate a path computation request with > delegation completely. With delegation your aim is to give up some > control and let PCE run the show, one should not expect the behavior > of this action to be exactly same as a path computation > request/response. > > Is it reasonable for PCC to expect PCUpd (with path)? or the PCE returns error for path that was never computed either by PCE or locally by PCC? We recently had interaction with vendor implementing PCEP test tools, they seem to interpret "active stateful PCE" need not support the RFC5440 functionality and a PCC could get path computed by sending PCRpt!!! I hope this is not a widely conceived opinion in order to circumvent PCRequest/PCReply. Thanks, Girish --047d7b343ada1112060509b9a8d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Dhruv,

Thanks for the response.
Few questions/comments,= please see inline


On Sat, Dec 6, 2014 at 12:00 PM, <pce-request@ietf.or= g> wrote:
dhruv.ietf@gm= ail.com>
To: "Aissaoui, Mustapha (Mustapha)"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mustapha.aissaoui@alcatel-lucent.com>
Cc: "pce@ietf.org" <pce@ietf.org>
Subject: Re: [Pce] Path Computation Request in Active Stateful PCE
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CAB75xn5iv5oKS02Sd2UfVUDrZhGgPR2= isZqGRXkBonfQYX8nXw@mail.gmail.com>
Content-Type: text/plain; charset=3DUTF-8

Hi Mustapha,

Since delegation is applied per LSP and not all LSPs are delegated it
is perfectly fine for an active stateful PCE to receive PCReq/PCRep.
In your mail you apply a passive / active property to whole PCC/PCE
which is not correct.

I see this as -

Stateless PCE
Stateless PCE + PCRpt (LSPBD) =3D Passive Stateful PCE
Stateless PCE + PCRpt (LSPBD) + PCUpd (delegation) =3D Active Stateful PCE<= br>
=C2=A0
The draft too mentions this as definitions.=C2= =A0 Active stateful PCE is extension to functionality supported by passive = stateful PCE.
However the interaction shown in section 5.6.1=C2=A0 and 5= .6.2=C2=A0 gives impression that PCRequest is handled by PCE acting as &quo= t;passive stateful" and not "active stateful". Verbatim inte= rpretation of these section contradict the definitions given in beginning o= f the draft. Would it be possible for the authors to address this issue in = next draft, unless the the description in section 5.6.1 is not meant for &q= uot;active stateful" PCE.
=C2=A0
At the same time, someone may choose to implement (as per some SDN
like deployment) to only support delegation. But that is their choice.
<= /blockquote>


In case one implements a PCE only with = "PCRpt (LSPBD) + PCUpd (delegation)",=C2=A0 is it expected to res= pond to a PCRpt with down path in case the path was not computed at PCE?
The draft is clear about use of PCUpd - mainly to handle topol= ogy events that affect existing paths or to allow operator to optimize netw= ork.


=C2=A0


>
> 2.=C2=A0 =C2=A0 The PCC starts in the active stateful mode and delegat= es the LSP,
> which is in down state, using the PCRpt message. In this case, the PCR= pt is
> used to synchronize the state of the LSP with the PCE but also as an > implicit way to request the initial LSP path computation. The issue th= ough
> is that the PCRpt message is not an explicit path computation request = and
> lacks the following:
>
>

It is completely fine for PCC to delegate an unsignalled LSP to PCE.
But I think we should not equate a path computation request with
delegation completely. With delegation your aim is to give up some
control and let PCE run the show, one should not expect the behavior
of this action to be exactly same as a path computation
request/response.


Is it reasonable for PCC to expect PCU= pd (with path)? or the PCE returns error for path that was never computed e= ither by PCE or locally by PCC?

We recently had interaction with ven= dor implementing PCEP test tools,=20 they seem to interpret "active stateful PCE" need not support the= =20 RFC5440 functionality and a PCC could get path computed by sending=20 PCRpt!!! I hope this is not a widely conceived opinion in order to=20 circumvent PCRequest/PCReply.

Thanks,
Giri= sh

--047d7b343ada1112060509b9a8d0-- From nobody Mon Dec 8 15:17:35 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 852901A0086 for ; Mon, 8 Dec 2014 15:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tem2SNb-ZYhG for ; Mon, 8 Dec 2014 15:17:19 -0800 (PST) Received: from mail-vc0-x241.google.com (mail-vc0-x241.google.com [IPv6:2607:f8b0:400c:c03::241]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F1661A0060 for ; Mon, 8 Dec 2014 15:17:19 -0800 (PST) Received: by mail-vc0-f193.google.com with SMTP id hq11so699382vcb.4 for ; Mon, 08 Dec 2014 15:17:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=5RqZS07kdBk49EVQnRTsFytMZWvZEPdONgcbE6korzY=; b=O1+dlbZ1rVbZeEuope7mfg/5mwFBvq86PQzG8KTg8gPVxW2tPYjW6X5Hp8uyCqeic6 EqDZIXNzVLuaZi4cEwUTU7wjFDmNVAjr+edliXrWMcC34DC6oTvYkwtXMrpFq5JpZrS+ +BLfmVASgzpNjuH6Os6+cIlLPSJG0BM9KZ9gwcDqPuyzfcNigiC+i42uNuJDN2DhAcqz se/7I7fO45fZVRWGVK+p+hWFbmEC1eue7pM23nHrjJTP0DE8XdeRNb2fo4GQ4zRu18js i6SlWGQh3MUajSBnYGER5cMQXSPIOlPndc1r7Mjq9E5SHgU+xbCGv8qy2ouPQvlEyhRg BLqg== MIME-Version: 1.0 X-Received: by 10.52.163.44 with SMTP id yf12mr3535450vdb.85.1418080637639; Mon, 08 Dec 2014 15:17:17 -0800 (PST) Received: by 10.31.16.159 with HTTP; Mon, 8 Dec 2014 15:17:17 -0800 (PST) Date: Mon, 8 Dec 2014 15:17:17 -0800 Message-ID: From: Girish Birajdar To: pce@ietf.org, dhruv.ietf@gmail.com Content-Type: multipart/alternative; boundary=001a11c28fc2ab60f30509bca0d3 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/YFcbDrmuzl6IasK2PlO8LupP0Ec Subject: Re: [Pce] Path Computation Request in Active Stateful PCE 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, 08 Dec 2014 23:17:21 -0000 --001a11c28fc2ab60f30509bca0d3 Content-Type: text/plain; charset=UTF-8 re-sending with correct email subject. Earlier email was reply to digest format Hi Dhruv, > > Thanks for the response. > Few questions/comments, please see inline > > > On Sat, Dec 6, 2014 at 12:00 PM, wrote: > >> >> Date: Sat, 6 Dec 2014 11:54:22 +0530 >> From: Dhruv Dhody >> To: "Aissaoui, Mustapha (Mustapha)" >> >> Cc: "pce@ietf.org" >> Subject: Re: [Pce] Path Computation Request in Active Stateful PCE >> Message-ID: >> < >> CAB75xn5iv5oKS02Sd2UfVUDrZhGgPR2isZqGRXkBonfQYX8nXw@mail.gmail.com> >> Content-Type: text/plain; charset=UTF-8 >> >> Hi Mustapha, >> >> Since delegation is applied per LSP and not all LSPs are delegated it >> is perfectly fine for an active stateful PCE to receive PCReq/PCRep. >> In your mail you apply a passive / active property to whole PCC/PCE >> which is not correct. >> >> I see this as - >> >> Stateless PCE >> Stateless PCE + PCRpt (LSPBD) = Passive Stateful PCE >> Stateless PCE + PCRpt (LSPBD) + PCUpd (delegation) = Active Stateful PCE >> > > The draft too mentions this as definitions. Active stateful PCE is > extension to functionality supported by passive stateful PCE. > However the interaction shown in section 5.6.1 and 5.6.2 gives > impression that PCRequest is handled by PCE acting as "passive stateful" > and not "active stateful". Verbatim interpretation of these section > contradict the definitions given in beginning of the draft. Would it be > possible for the authors to address this issue in next draft, unless the > the description in section 5.6.1 is not meant for "active stateful" PCE. > > >> At the same time, someone may choose to implement (as per some SDN >> like deployment) to only support delegation. But that is their choice. >> > > > In case one implements a PCE only with "PCRpt (LSPBD) + PCUpd > (delegation)", is it expected to respond to a PCRpt with down path in case > the path was not computed at PCE? > The draft is clear about use of PCUpd - mainly to handle topology events > that affect existing paths or to allow operator to optimize network. > > > > >> >> >> > >> > 2. The PCC starts in the active stateful mode and delegates the LSP, >> > which is in down state, using the PCRpt message. In this case, the >> PCRpt is >> > used to synchronize the state of the LSP with the PCE but also as an >> > implicit way to request the initial LSP path computation. The issue >> though >> > is that the PCRpt message is not an explicit path computation request >> and >> > lacks the following: >> > >> > >> >> It is completely fine for PCC to delegate an unsignalled LSP to PCE. >> But I think we should not equate a path computation request with >> delegation completely. With delegation your aim is to give up some >> control and let PCE run the show, one should not expect the behavior >> of this action to be exactly same as a path computation >> request/response. >> >> > Is it reasonable for PCC to expect PCUpd (with path)? or the PCE returns > error for path that was never computed either by PCE or locally by PCC? > > We recently had interaction with vendor implementing PCEP test tools, they > seem to interpret "active stateful PCE" need not support the RFC5440 > functionality and a PCC could get path computed by sending PCRpt!!! I hope > this is not a widely conceived opinion in order to circumvent > PCRequest/PCReply. > > Thanks, > Girish > > --001a11c28fc2ab60f30509bca0d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

re-sending with correct email subject.=
Earlier email was reply to digest format


Hi Dhruv,

Thanks for the response.
Few questions/comments, pleas= e see inline


On Sat, Dec 6, 2014 at 12:00 PM, <pce-reque= st@ietf.org> wrote:

Date: Sat, 6 Dec 2014 11:54:22 +0530
From: Dhruv Dhody <dhruv.ietf@gmail.com>
To: "Aissaoui, Mustapha (Mustapha)"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mustapha.aissaoui@alcatel-lucent.com>=
Cc: "pce@ietf.org" <pce@ietf.org<= /a>>
Subject: Re: [Pce] Path Computation Request in Active Stateful PCE
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CAB75xn5iv5oKS= 02Sd2UfVUDrZhGgPR2isZqGRXkBonfQYX8nXw@mail.gmail.com>
Content-Type: text/plain; charset=3DUTF-8

Hi Mustapha,

Since delegation is applied per LSP and not all LSPs are delegated it
is perfectly fine for an active stateful PCE to receive PCReq/PCRep.
In your mail you apply a passive / active property to whole PCC/PCE
which is not correct.

I see this as -

Stateless PCE
Stateless PCE + PCRpt (LSPBD) =3D Passive Stateful PCE
Stateless PCE + PCRpt (LSPBD) + PCUpd (delegation) =3D Active Stateful PCE<= br>
=C2=A0
The draft too mentions this as definitio= ns.=C2=A0 Active stateful PCE is extension to functionality supported by pa= ssive stateful PCE.
However the interaction shown in section 5.6.1=C2=A0= and 5.6.2=C2=A0 gives impression that PCRequest is handled by PCE acting a= s "passive stateful" and not "active stateful". Verbati= m interpretation of these section contradict the definitions given in begin= ning of the draft. Would it be possible for the authors to address this iss= ue in next draft, unless the the description in section 5.6.1 is not meant = for "active stateful" PCE.
=C2=A0<= /div>
At the same time, someone may choose to implement (as per some SDN
like deployment) to only support delegation. But that is their choice.
<= /blockquote>


In case one implements a PCE onl= y with "PCRpt (LSPBD) + PCUpd (delegation)",=C2=A0 is it expected= to respond to a PCRpt with down path in case the path was not computed at = PCE?
The draft is clear about use of PCUpd - mainly to handl= e topology events that affect existing paths or to allow operator to optimi= ze network.


=C2=A0


>
> 2.=C2=A0 =C2=A0 The PCC starts in the active stateful mode and delegat= es the LSP,
> which is in down state, using the PCRpt message. In this case, the PCR= pt is
> used to synchronize the state of the LSP with the PCE but also as an > implicit way to request the initial LSP path computation. The issue th= ough
> is that the PCRpt message is not an explicit path computation request = and
> lacks the following:
>
>

It is completely fine for PCC to delegate an unsignalled LSP to PCE.
But I think we should not equate a path computation request with
delegation completely. With delegation your aim is to give up some
control and let PCE run the show, one should not expect the behavior
of this action to be exactly same as a path computation
request/response.


Is it reasonable for PCC to exp= ect PCUpd (with path)? or the PCE returns error for path that was never com= puted either by PCE or locally by PCC?

We recently had interaction w= ith vendor implementing PCEP test tools,=20 they seem to interpret "active stateful PCE" need not support the= =20 RFC5440 functionality and a PCC could get path computed by sending=20 PCRpt!!! I hope this is not a widely conceived opinion in order to=20 circumvent PCRequest/PCReply.

Thanks,
Giri= sh


--001a11c28fc2ab60f30509bca0d3-- From nobody Tue Dec 9 00:51: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 15B7C1A6FFB for ; Tue, 9 Dec 2014 00:51:28 -0800 (PST) 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 w4zXX8St3HBY for ; Tue, 9 Dec 2014 00:51:25 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D46C1A6F45 for ; Tue, 9 Dec 2014 00:51:25 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id l13so4437137iga.3 for ; Tue, 09 Dec 2014 00:51:24 -0800 (PST) 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=IMEE+mdGYJ9la+ykRZ2im+UEhfwIrSglRwY+8jhP1k4=; b=z1tmATimpiVN2GuOD1fpwlBTmXpSavBB+PpKsYZT9MueNbXwUBl45X7UdTvA71GarM +d3d6UCzNUVa8JvmkFhYuFH5LNO9d8NaGt3y6BtbjvTJ2J6R9W7kU6Dwx1tW0Av301J5 jwgVzfppXIYPdzaPgXoPMB9TNWERHuyT4b8ZllvLN93VH0ZUfDa6FAsXHrRbNJHTQzfx CVFY0KWubyBfDdGyc2SN8aDIsfcd6C+p3XrolEhfTlnYArvaR1jB0mPo68RzzyLWB5Ty mgTwfYl+vF8koLqCvUOh7U9lH6oTE7jjtwtpBLj8wmFd/Z2zwA7y5kWqpyl5PGLjTiOo xXWg== MIME-Version: 1.0 X-Received: by 10.107.158.11 with SMTP id h11mr15399446ioe.37.1418115084544; Tue, 09 Dec 2014 00:51:24 -0800 (PST) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.154.68 with HTTP; Tue, 9 Dec 2014 00:51:24 -0800 (PST) In-Reply-To: References: Date: Tue, 9 Dec 2014 14:21:24 +0530 X-Google-Sender-Auth: tHci8wI_bia2r5lutq9u0_AI-gI Message-ID: From: Dhruv Dhody To: Girish Birajdar Content-Type: multipart/alternative; boundary=001a1140888cdd73ae0509c4a538 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/hPCupL5UW910TrNrpNWBTVwc7GI Cc: "pce@ietf.org" Subject: Re: [Pce] Path Computation Request in Active Stateful PCE 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, 09 Dec 2014 08:51:28 -0000 --001a1140888cdd73ae0509c4a538 Content-Type: text/plain; charset=UTF-8 Hi Girish, See inline.... On Dec 9, 2014 4:47 AM, "Girish Birajdar" wrote: > > > re-sending with correct email subject. > Earlier email was reply to digest format > > >> Hi Dhruv, >> >> Thanks for the response. >> Few questions/comments, please see inline >> >> >> On Sat, Dec 6, 2014 at 12:00 PM, wrote: >>> >>> >>> Date: Sat, 6 Dec 2014 11:54:22 +0530 >>> From: Dhruv Dhody >>> To: "Aissaoui, Mustapha (Mustapha)" >>> >>> Cc: "pce@ietf.org" >>> Subject: Re: [Pce] Path Computation Request in Active Stateful PCE >>> Message-ID: >>> < CAB75xn5iv5oKS02Sd2UfVUDrZhGgPR2isZqGRXkBonfQYX8nXw@mail.gmail.com> >>> Content-Type: text/plain; charset=UTF-8 >>> >>> >>> Hi Mustapha, >>> >>> Since delegation is applied per LSP and not all LSPs are delegated it >>> is perfectly fine for an active stateful PCE to receive PCReq/PCRep. >>> In your mail you apply a passive / active property to whole PCC/PCE >>> which is not correct. >>> >>> I see this as - >>> >>> Stateless PCE >>> Stateless PCE + PCRpt (LSPBD) = Passive Stateful PCE >>> Stateless PCE + PCRpt (LSPBD) + PCUpd (delegation) = Active Stateful PCE >> >> >> The draft too mentions this as definitions. Active stateful PCE is extension to functionality supported by passive stateful PCE. >> However the interaction shown in section 5.6.1 and 5.6.2 gives impression that PCRequest is handled by PCE acting as "passive stateful" and not "active stateful". Verbatim interpretation of these section contradict the definitions given in beginning of the draft. Would it be possible for the authors to address this issue in next draft, unless the the description in section 5.6.1 is not meant for "active stateful" PCE. #DD - Since I am not the author, I will let them or the shepherd respond. >> >>> >>> At the same time, someone may choose to implement (as per some SDN >>> like deployment) to only support delegation. But that is their choice. >> >> >> >> In case one implements a PCE only with "PCRpt (LSPBD) + PCUpd (delegation)", is it expected to respond to a PCRpt with down path in case the path was not computed at PCE? >> The draft is clear about use of PCUpd - mainly to handle topology events that affect existing paths or to allow operator to optimize network. #DD - IMO this boils down to - does every delegation requires a response/ack from the PCE. We all seem to be fine with not getting a response when the LSP was already up. For a down LSP, do we need to change this procedure? IMO, No, let the PCE decide what should be done... wait for network change, or log this and do nothing, or PCE can send PCUpd with down if the implementation chooses to go that way. >> >> >> >>> >>> >>> >>> > >>> > 2. The PCC starts in the active stateful mode and delegates the LSP, >>> > which is in down state, using the PCRpt message. In this case, the PCRpt is >>> > used to synchronize the state of the LSP with the PCE but also as an >>> > implicit way to request the initial LSP path computation. The issue though >>> > is that the PCRpt message is not an explicit path computation request and >>> > lacks the following: >>> > >>> > >>> >>> It is completely fine for PCC to delegate an unsignalled LSP to PCE. >>> But I think we should not equate a path computation request with >>> delegation completely. With delegation your aim is to give up some >>> control and let PCE run the show, one should not expect the behavior >>> of this action to be exactly same as a path computation >>> request/response. >>> >> >> Is it reasonable for PCC to expect PCUpd (with path)? or the PCE returns error for path that was never computed either by PCE or locally by PCC? #DD - As above, by delegating. PCC has given up control and it is PCE's prerogative to choose the right action (or inaction). PCC can always revoke delegation and rely on passive PCReq. >> >> We recently had interaction with vendor implementing PCEP test tools, they seem to interpret "active stateful PCE" need not support the RFC5440 functionality and a PCC could get path computed by sending PCRpt!!! I hope this is not a widely conceived opinion in order to circumvent PCRequest/PCReply. #DD - I agree and that is why I am suggesting to not equate the procedures of PCReq with that of delegation... Both have a different role to play. Dhruv >> >> Thanks, >> Girish >> > --001a1140888cdd73ae0509c4a538 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Girish,

See inline....

On Dec 9, 2014 4:47 AM, "Girish Birajdar" <girish134@gmail.com> wrote:
>
>
> re-sending with correct email subject.
> Earlier email was reply to digest format
>
>
>> Hi Dhruv,
>>
>> Thanks for the response.
>> Few questions/comments, please see inline
>>
>>
>> On Sat, Dec 6, 2014 at 12:00 PM, <pce-request@ietf.org> wrote:
>>>
>>>
>>> Date: Sat, 6 Dec 2014 11:54:22 +0530
>>> From: Dhruv Dhody <dhruv.ietf@gmail.com>
>>> To: "Aissaoui, Mustapha (Mustapha)"
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mustapha.aissaoui@alcatel-lucen= t.com>
>>> Cc: "pc= e@ietf.org" <= pce@ietf.org>
>>> Subject: Re: [Pce] Path Computation Request in Active Stateful= PCE
>>> Message-ID:
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <C= AB75xn5iv5oKS02Sd2UfVUDrZhGgPR2isZqGRXkBonfQYX8nXw@mail.gmail.com> >>> Content-Type: text/plain; charset=3DUTF-8
>>>
>>>
>>> Hi Mustapha,
>>>
>>> Since delegation is applied per LSP and not all LSPs are deleg= ated it
>>> is perfectly fine for an active stateful PCE to receive PCReq/= PCRep.
>>> In your mail you apply a passive / active property to whole PC= C/PCE
>>> which is not correct.
>>>
>>> I see this as -
>>>
>>> Stateless PCE
>>> Stateless PCE + PCRpt (LSPBD) =3D Passive Stateful PCE
>>> Stateless PCE + PCRpt (LSPBD) + PCUpd (delegation) =3D Active = Stateful PCE
>>
>> =C2=A0
>> The draft too mentions this as definitions.=C2=A0 Active stateful = PCE is extension to functionality supported by passive stateful PCE.
>> However the interaction shown in section 5.6.1=C2=A0 and 5.6.2=C2= =A0 gives impression that PCRequest is handled by PCE acting as "passi= ve stateful" and not "active stateful". Verbatim interpretat= ion of these section contradict the definitions given in beginning of the d= raft. Would it be possible for the authors to address this issue in next dr= aft, unless the the description in section 5.6.1 is not meant for "act= ive stateful" PCE.

#DD - =C2=A0Since I am not the author, I will let them or th= e shepherd respond.

>> =C2=A0
>>>
>>> At the same time, someone may choose to implement (as per some= SDN
>>> like deployment) to only support delegation. But that is their= choice.
>>
>>
>>
>> In case one implements a PCE only with "PCRpt (LSPBD) + PCUpd= (delegation)",=C2=A0 is it expected to respond to a PCRpt with down p= ath in case the path was not computed at PCE?
>> The draft is clear about use of PCUpd - mainly to handle topology = events that affect existing paths or to allow operator to optimize network.=

#DD - IMO this boils down to - =C2=A0does every delegation r= equires a=C2=A0response/ack from the PCE. We all seem to be fine with not g= etting a response when the LSP was already up. For a down LSP, do we need t= o change this procedure? IMO, No, let the PCE decide what should be done...= wait for network change, or log this and do nothing, or PCE can send PCUpd= with down if the implementation chooses to go that way.

>>
>>
>> =C2=A0
>>>
>>>
>>>
>>> >
>>> > 2.=C2=A0 =C2=A0 The PCC starts in the active stateful mod= e and delegates the LSP,
>>> > which is in down state, using the PCRpt message. In this = case, the PCRpt is
>>> > used to synchronize the state of the LSP with the PCE but= also as an
>>> > implicit way to request the initial LSP path computation.= The issue though
>>> > is that the PCRpt message is not an explicit path computa= tion request and
>>> > lacks the following:
>>> >
>>> >
>>>
>>> It is completely fine for PCC to delegate an unsignalled LSP t= o PCE.
>>> But I think we should not equate a path computation request wi= th
>>> delegation completely. With delegation your aim is to give up = some
>>> control and let PCE run the show, one should not expect the be= havior
>>> of this action to be exactly same as a path computation
>>> request/response.
>>>
>>
>> Is it reasonable for PCC to expect PCUpd (with path)? or the PCE r= eturns error for path that was never computed either by PCE or locally by P= CC?

#DD - As above, by delegating. PCC has given up control and = it is PCE's=C2=A0prerogative to choose the right action (or inaction). = PCC can always revoke delegation and rely on passive PCReq.

>>
>> We recently had interaction with vendor implementing PCEP test too= ls, they seem to interpret "active stateful PCE" need not support= the RFC5440 functionality and a PCC could get path computed by sending PCR= pt!!! I hope this is not a widely conceived opinion in order to circumvent = PCRequest/PCReply.

#DD - I agree and that is why I am suggesting to not equate = the procedures of PCReq with that of delegation... Both have a different ro= le to play.

Dhruv


>>
>> Thanks,
>> Girish
>>
>

--001a1140888cdd73ae0509c4a538-- From nobody Wed Dec 10 14:35:41 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 9507B1AC3CA for ; Wed, 10 Dec 2014 14:35:39 -0800 (PST) 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 YKQL92qcsXhs for ; Wed, 10 Dec 2014 14:35:38 -0800 (PST) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEC8E1ABD35 for ; Wed, 10 Dec 2014 14:35:37 -0800 (PST) Received: by mail-yh0-f41.google.com with SMTP id a41so1761429yho.28 for ; Wed, 10 Dec 2014 14:35:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=IS6KYbpiX7b6348H5fQ+Sgn7QT6OiVNRJ38myQi/NVg=; b=lRAUTauzitolS+eh4PtbjFKfgNuWRohI/eH3l/0I0IKgiYhDn0yHlnXReK9750k1dm NZx6PowSslAt6JLtehZzBRlLk4QstbUDZ26lGy3rcZ0MOp+pSWQ/FXN8aetGf9Rev9Rp 05Wn63DKJeXy/WLm/1NJxds3fv2ZQ9nNbVsIh4UsguyjQSCaxHrwQ0/LWGA0oVPGUgvM 6fWjgdDtZepilkqgaddnLR/IXqcLhEnGEZUdZ6sekTSi0NI/GC0fgi675avZ/+n7AUVG xmsMWG6CbNa8NySDZtY2l9nRffUdrxio6ovRRL8LCSVqAAvsMFwtY0jOSMvEn1WVqxSp Qfgg== MIME-Version: 1.0 X-Received: by 10.170.122.134 with SMTP id o128mr5778122ykb.55.1418250937054; Wed, 10 Dec 2014 14:35:37 -0800 (PST) Received: by 10.170.136.132 with HTTP; Wed, 10 Dec 2014 14:35:37 -0800 (PST) Date: Wed, 10 Dec 2014 17:35:37 -0500 Message-ID: From: Alia Atlas To: "pce@ietf.org" , draft-ietf-pce-rfc7150bis@tools.ietf.org Content-Type: multipart/alternative; boundary=001a1139da804e3cad0509e44747 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/svK4CzU10SqKNZfJ_g7MtyticLM Subject: [Pce] AD review of draft-ietf-pce-rfc7150bis-01 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, 10 Dec 2014 22:35:39 -0000 --001a1139da804e3cad0509e44747 Content-Type: text/plain; charset=UTF-8 I've done my usual AD review of draft-ietf-pce-rfc7150bis-01. I have found no issues and requested that IETF Last Call. Regards, Alia --001a1139da804e3cad0509e44747 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've done my usual AD review of draft-ietf-pce-rfc7150= bis-01.=C2=A0 I have found no issues and requested that IETF Last Call.
Regards,
Alia
--001a1139da804e3cad0509e44747-- From nobody Wed Dec 10 15:03: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 C310B1AC418; Wed, 10 Dec 2014 15:03:41 -0800 (PST) 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 lv_KMXfGycKt; Wed, 10 Dec 2014 15:03:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6231A1A4D; Wed, 10 Dec 2014 15:03:40 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141210230340.17575.27245.idtracker@ietfa.amsl.com> Date: Wed, 10 Dec 2014 15:03:40 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/E-xY8T15xI9EewD6cQFo0Y5Hsuw Cc: pce@ietf.org Subject: [Pce] Last Call: (Conveying Vendor-Specific Constraints in the Path Computation Element communication Protocol) to Proposed Standard X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 23:03:42 -0000 The IESG has received a request from the Path Computation Element WG (pce) to consider the following document: - 'Conveying Vendor-Specific Constraints in the Path Computation Element communication Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-12-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Path Computation Element communication Protocol (PCEP) is used to convey path computation requests and responses both between Path Computation Clients (PCCs) and Path Computation Elements (PCEs) and between cooperating PCEs. In PCEP, the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation. This document defines a facility to carry vendor-specific information in PCEP using a dedicated object and a new Type-Length-Value (TLV) that can be carried in any PCEP object that supports TLVs. This document obsoletes RFC 7150. The only changes from that document are a clarification of the use of the new Type-Length-Value and the allocation of a different code point for the VENDOR- INFORMATION object. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pce-rfc7150bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pce-rfc7150bis/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Sun Dec 14 10:46:04 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 AFB641A0137 for ; Sun, 14 Dec 2014 10:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 YRZeEFFI_Du4 for ; Sun, 14 Dec 2014 10:46:00 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 428911A0126 for ; Sun, 14 Dec 2014 10:46:00 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id n3so7038312wiv.1 for ; Sun, 14 Dec 2014 10:45:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=0vMRfnPVLBmQYK8ZXLA5qTzKDbi5pUnaH0CVOIJk/8o=; b=EB/1QRzOenMX4K8iyF75YFm3qnxtVZ9ixxF03wPeKq9uzX+BhCUxvUaxQWk8XMdwOl x0hfgOwqurrBNMRmsDOj/fJMQQETmskYmFu28wJ3JoPy7uycrfJNLXDodBgR2T+jSS4a wnecarNm//xBGemEKdWkOpIIy6pO5xfSflDRn1BkVbS1cISSJ/806N7BWStEMO+egQkr yHP8eJNcP1hMErG27QG0iaws+6xWaq7TWnINRzbQC57V0UwLflqxANSwccieGdHWJYRW 4bIXtVF27hMgGoYosNszfB7z+vdkJMo6cB/k0v+hN+GdsdUmy135Mde6tMTVqex0+LJz Q3lQ== X-Gm-Message-State: ALoCoQkpSwej1LvhUW+381ZGePXCgMamTMwtc0WJdb8amujEhKDCNICRg75zvcCOly67sn0Donm3 X-Received: by 10.194.63.229 with SMTP id j5mr45914218wjs.23.1418582758930; Sun, 14 Dec 2014 10:45:58 -0800 (PST) Received: from Serenity ([213.205.251.241]) by mx.google.com with ESMTPSA id ej10sm10351948wib.2.2014.12.14.10.45.57 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 14 Dec 2014 10:45:58 -0800 (PST) Sender: Daniel King X-Google-Original-Sender: "Daniel King" From: "Daniel King" To: Date: Sun, 14 Dec 2014 18:45:51 -0000 Message-ID: <004901d017ce$301af800$9050e800$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdAXy3zH/JYY7uk6QJCLd36tlY8gcw== Content-Language: en-gb Archived-At: http://mailarchive.ietf.org/arch/msg/pce/KbbFEIA0Cxr-1PLeWmKhLguEgxE Subject: [Pce] FW: [CCAMP] TEAS WG Virtual Interim Meeting (December 18, 20:00 UTC) 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: Sun, 14 Dec 2014 18:46:02 -0000 Just an FYI on the upcoming TE topology YANG model (interim) meeting. Date/Time: December 18, 20:00 UTC. http://www.ietf.org/mail-archive/web/teas/current/msg00027.html No call info has been posted as yet. BR, Dan. -----Original Message----- From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of IESG Secretary Sent: 05 December 2014 16:02 To: IETF Announcement List Cc: ccamp@ietf.org; teas@ietf.org Subject: [CCAMP] TEAS WG Virtual Interim Meeting: December 18, starting at 20:00 UTC (formerly CCAMP WG Virtual Interim) The previously announced TE Topology Yang Model Virtual Interim will be held as announced, but will be hosted by the new TEAS WG rather than the CCAMP WG. The original announcement is below. On Dec 3, 2014, at 12:26 PM, IESG Secretary wrote: > TE Topology Yang Model Virtual Interim (CCAMP) > > There is a cluster of work around YANG models for topology and the TED > (TE Topology Database). The Routing ADs are planning to have the TEAS > working group formalized soon and the group is expected to have an > explicit deliverable of a YANG model for the TED. We, the current > CCAMP chairs, have been asked to get this effort moving by arranging a > virtual interim meeting on the topic. > > The primary objectives of the meeting are to (a) get some basic > agreement on TE topology model 'use cases' (e.g., driven by I2RS, PCE, > ALTO, TEAS), (b) establish the dependencies/relationships of a TE > topology model to other models (e.g., router, topology, routing > protocols, ...) and finally, (c) to provide the needed foundation for > a TEAS design team to be formed and deliver a TE Topology Yang Model > draft by Dallas. > > A related activity has also started in the MPLS WG on a TE LSP Yang > Model. This topic will *not* be the focus of this interim and we > expect that work to continue concurrently. > > The Virtual interim is scheduled for 2-3 hours on December 18, > starting at 20:00 UTC. > > The agenda and other logistic information for the meeting will be > posted & discussed on the CCAMP and new TEAS mailing list > (ccamp@ietf.org and teas@ietf.org). > > The existing set of related drafts includes: > draft-liu-yang-abstract-te-topo > draft-clemm-i2rs-yang-l3-topo > draft-clemm-i2rs-yang-network-topo > draft-amante-i2rs-topology-use-cases > draft-chen-mpls-te-yang-cfg (LSP focused) > draft-gandhi-mpls-te-yang-model (LSP focused) > draft-ietf-netmod-routing-cfg (Foundational work, not topology > specific) > > Deborah and Lou > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From nobody Tue Dec 16 08:43:52 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 1553D1A1B05 for ; Tue, 16 Dec 2014 08:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 S00bgWX_hpoc for ; Tue, 16 Dec 2014 08:43:46 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6E4C1A1BA3 for ; Tue, 16 Dec 2014 08:43:45 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 17B4D3E178477; Tue, 16 Dec 2014 16:43:40 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id sBGGhg0H032636 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Dec 2014 11:43:42 -0500 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.84]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Tue, 16 Dec 2014 11:43:42 -0500 From: "Aissaoui, Mustapha (Mustapha)" To: Dhruv Dhody , Girish Birajdar Thread-Topic: [Pce] Path Computation Request in Active Stateful PCE Thread-Index: AQHQEz0b2IxfSn+OQtqRXzt/b1cSZ5yHR/YAgAssSrA= Date: Tue, 16 Dec 2014 16:43:41 +0000 Message-ID: <4A79394211F1AF4EB57D998426C9340D947C1F2D@US70UWXCHMBA04.zam.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_4A79394211F1AF4EB57D998426C9340D947C1F2DUS70UWXCHMBA04z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/7sXaYdB6r2H1e1Wdkx3ydMiKr0c Cc: "pce@ietf.org" Subject: Re: [Pce] Path Computation Request in Active Stateful PCE 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, 16 Dec 2014 16:43:50 -0000 --_000_4A79394211F1AF4EB57D998426C9340D947C1F2DUS70UWXCHMBA04z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIERocnV2IGZvciBhbGwgdGhlIGluc2lnaHRzLg0KDQpJdCB3b3VsZCBiZSBncmVhdCBp ZiB0aGUgYXV0aG9ycyBvZiBkcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1wY2UgYWRkZWQgYSBjbGFy aWZpY2F0aW9uIHRvIHNlY3Rpb24gNS42LjIgdG8gc3RhdGUgdGhhdCBQQ0MgY2FuIHVzZSB0aGUg UENSZXEvUENSZXAgcHJvY2VkdXJlcyB3aXRoIGFuIEFjdGl2ZSBTdGF0ZWZ1bCBQQ0UgdG8gcmVx dWVzdCB0aGUgaW5pdGlhbCBwYXRoIG9mIGFuIExTUCBiZWZvcmUgZGVsZWdhdGlvbiB0byBQQ0Ug YW5kIGFsc28gc3Vic2VxdWVudGx5IGlmIHJlcXVpcmVkIGJ5IHJldm9raW5nIGRlbGVnYXRpb24g ZnJvbSBQQ0UuDQoNCldlIGJlbGlldmUgdGhpcyB3aWxsIHJlbW92ZSBzb21lIGFtYmlndWl0eS4g QXMgR2lyaXNoIHNhaWQsIHdlIGhhZCBzb21lIGZlZWRiYWNrIGZyb20gYSB0ZXN0IGVxdWlwbWVu dCB2ZW5kb3IgdGhhdCB0aGVpciBpbnRlcnByZXRhdGlvbiB3YXMgdGhhdCBBY3RpdmUgU3RhdGVm dWwgUENFIGRvZXMgbm90IGhhdmUgdG8gc3VwcG9ydCBQQ1JlcS9QQ1JlcCBwcm9jZWR1cmVzIGFu ZCB0aGF0IHRoZSBQQ1JwdCBpcyB0byBiZSB1c2VkIHRvIHJlcXVlc3QgYSBwYXRoIGNvbXB1dGF0 aW9uLg0KDQpSZWdhcmRzLA0KTXVzdGFwaGEuDQoNCkZyb206IFBjZSBbbWFpbHRvOnBjZS1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGhydXYgRGhvZHkNClNlbnQ6IFR1ZXNkYXksIERl Y2VtYmVyIDA5LCAyMDE0IDM6NTEgQU0NClRvOiBHaXJpc2ggQmlyYWpkYXINCkNjOiBwY2VAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbUGNlXSBQYXRoIENvbXB1dGF0aW9uIFJlcXVlc3QgaW4gQWN0 aXZlIFN0YXRlZnVsIFBDRQ0KDQoNCkhpIEdpcmlzaCwNCg0KU2VlIGlubGluZS4uLi4NCg0KT24g RGVjIDksIDIwMTQgNDo0NyBBTSwgIkdpcmlzaCBCaXJhamRhciIgPGdpcmlzaDEzNEBnbWFpbC5j b208bWFpbHRvOmdpcmlzaDEzNEBnbWFpbC5jb20+PiB3cm90ZToNCj4NCj4NCj4gcmUtc2VuZGlu ZyB3aXRoIGNvcnJlY3QgZW1haWwgc3ViamVjdC4NCj4gRWFybGllciBlbWFpbCB3YXMgcmVwbHkg dG8gZGlnZXN0IGZvcm1hdA0KPg0KPg0KPj4gSGkgRGhydXYsDQo+Pg0KPj4gVGhhbmtzIGZvciB0 aGUgcmVzcG9uc2UuDQo+PiBGZXcgcXVlc3Rpb25zL2NvbW1lbnRzLCBwbGVhc2Ugc2VlIGlubGlu ZQ0KPj4NCj4+DQo+PiBPbiBTYXQsIERlYyA2LCAyMDE0IGF0IDEyOjAwIFBNLCA8cGNlLXJlcXVl c3RAaWV0Zi5vcmc8bWFpbHRvOnBjZS1yZXF1ZXN0QGlldGYub3JnPj4gd3JvdGU6DQo+Pj4NCj4+ Pg0KPj4+IERhdGU6IFNhdCwgNiBEZWMgMjAxNCAxMTo1NDoyMiArMDUzMA0KPj4+IEZyb206IERo cnV2IERob2R5IDxkaHJ1di5pZXRmQGdtYWlsLmNvbTxtYWlsdG86ZGhydXYuaWV0ZkBnbWFpbC5j b20+Pg0KPj4+IFRvOiAiQWlzc2FvdWksIE11c3RhcGhhIChNdXN0YXBoYSkiDQo+Pj4gICAgICAg ICA8bXVzdGFwaGEuYWlzc2FvdWlAYWxjYXRlbC1sdWNlbnQuY29tPG1haWx0bzptdXN0YXBoYS5h aXNzYW91aUBhbGNhdGVsLWx1Y2VudC5jb20+Pg0KPj4+IENjOiAicGNlQGlldGYub3JnPG1haWx0 bzpwY2VAaWV0Zi5vcmc+IiA8cGNlQGlldGYub3JnPG1haWx0bzpwY2VAaWV0Zi5vcmc+Pg0KPj4+ IFN1YmplY3Q6IFJlOiBbUGNlXSBQYXRoIENvbXB1dGF0aW9uIFJlcXVlc3QgaW4gQWN0aXZlIFN0 YXRlZnVsIFBDRQ0KPj4+IE1lc3NhZ2UtSUQ6DQo+Pj4gICAgICAgICA8Q0FCNzV4bjVpdjVvS1Mw MlNkMlVmVlVEclpoR2dQUjJpc1pxR1JYa0JvbmZRWVg4blh3QG1haWwuZ21haWwuY29tPG1haWx0 bzpDQUI3NXhuNWl2NW9LUzAyU2QyVWZWVURyWmhHZ1BSMmlzWnFHUlhrQm9uZlFZWDhuWHdAbWFp bC5nbWFpbC5jb20+Pg0KPj4+IENvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD1VVEYt OA0KPj4+DQo+Pj4NCj4+PiBIaSBNdXN0YXBoYSwNCj4+Pg0KPj4+IFNpbmNlIGRlbGVnYXRpb24g aXMgYXBwbGllZCBwZXIgTFNQIGFuZCBub3QgYWxsIExTUHMgYXJlIGRlbGVnYXRlZCBpdA0KPj4+ IGlzIHBlcmZlY3RseSBmaW5lIGZvciBhbiBhY3RpdmUgc3RhdGVmdWwgUENFIHRvIHJlY2VpdmUg UENSZXEvUENSZXAuDQo+Pj4gSW4geW91ciBtYWlsIHlvdSBhcHBseSBhIHBhc3NpdmUgLyBhY3Rp dmUgcHJvcGVydHkgdG8gd2hvbGUgUENDL1BDRQ0KPj4+IHdoaWNoIGlzIG5vdCBjb3JyZWN0Lg0K Pj4+DQo+Pj4gSSBzZWUgdGhpcyBhcyAtDQo+Pj4NCj4+PiBTdGF0ZWxlc3MgUENFDQo+Pj4gU3Rh dGVsZXNzIFBDRSArIFBDUnB0IChMU1BCRCkgPSBQYXNzaXZlIFN0YXRlZnVsIFBDRQ0KPj4+IFN0 YXRlbGVzcyBQQ0UgKyBQQ1JwdCAoTFNQQkQpICsgUENVcGQgKGRlbGVnYXRpb24pID0gQWN0aXZl IFN0YXRlZnVsIFBDRQ0KPj4NCj4+DQo+PiBUaGUgZHJhZnQgdG9vIG1lbnRpb25zIHRoaXMgYXMg ZGVmaW5pdGlvbnMuICBBY3RpdmUgc3RhdGVmdWwgUENFIGlzIGV4dGVuc2lvbiB0byBmdW5jdGlv bmFsaXR5IHN1cHBvcnRlZCBieSBwYXNzaXZlIHN0YXRlZnVsIFBDRS4NCj4+IEhvd2V2ZXIgdGhl IGludGVyYWN0aW9uIHNob3duIGluIHNlY3Rpb24gNS42LjEgIGFuZCA1LjYuMiAgZ2l2ZXMgaW1w cmVzc2lvbiB0aGF0IFBDUmVxdWVzdCBpcyBoYW5kbGVkIGJ5IFBDRSBhY3RpbmcgYXMgInBhc3Np dmUgc3RhdGVmdWwiIGFuZCBub3QgImFjdGl2ZSBzdGF0ZWZ1bCIuIFZlcmJhdGltIGludGVycHJl dGF0aW9uIG9mIHRoZXNlIHNlY3Rpb24gY29udHJhZGljdCB0aGUgZGVmaW5pdGlvbnMgZ2l2ZW4g aW4gYmVnaW5uaW5nIG9mIHRoZSBkcmFmdC4gV291bGQgaXQgYmUgcG9zc2libGUgZm9yIHRoZSBh dXRob3JzIHRvIGFkZHJlc3MgdGhpcyBpc3N1ZSBpbiBuZXh0IGRyYWZ0LCB1bmxlc3MgdGhlIHRo ZSBkZXNjcmlwdGlvbiBpbiBzZWN0aW9uIDUuNi4xIGlzIG5vdCBtZWFudCBmb3IgImFjdGl2ZSBz dGF0ZWZ1bCIgUENFLg0KDQojREQgLSAgU2luY2UgSSBhbSBub3QgdGhlIGF1dGhvciwgSSB3aWxs IGxldCB0aGVtIG9yIHRoZSBzaGVwaGVyZCByZXNwb25kLg0KDQo+Pg0KPj4+DQo+Pj4gQXQgdGhl IHNhbWUgdGltZSwgc29tZW9uZSBtYXkgY2hvb3NlIHRvIGltcGxlbWVudCAoYXMgcGVyIHNvbWUg U0RODQo+Pj4gbGlrZSBkZXBsb3ltZW50KSB0byBvbmx5IHN1cHBvcnQgZGVsZWdhdGlvbi4gQnV0 IHRoYXQgaXMgdGhlaXIgY2hvaWNlLg0KPj4NCj4+DQo+Pg0KPj4gSW4gY2FzZSBvbmUgaW1wbGVt ZW50cyBhIFBDRSBvbmx5IHdpdGggIlBDUnB0IChMU1BCRCkgKyBQQ1VwZCAoZGVsZWdhdGlvbiki LCAgaXMgaXQgZXhwZWN0ZWQgdG8gcmVzcG9uZCB0byBhIFBDUnB0IHdpdGggZG93biBwYXRoIGlu IGNhc2UgdGhlIHBhdGggd2FzIG5vdCBjb21wdXRlZCBhdCBQQ0U/DQo+PiBUaGUgZHJhZnQgaXMg Y2xlYXIgYWJvdXQgdXNlIG9mIFBDVXBkIC0gbWFpbmx5IHRvIGhhbmRsZSB0b3BvbG9neSBldmVu dHMgdGhhdCBhZmZlY3QgZXhpc3RpbmcgcGF0aHMgb3IgdG8gYWxsb3cgb3BlcmF0b3IgdG8gb3B0 aW1pemUgbmV0d29yay4NCg0KI0REIC0gSU1PIHRoaXMgYm9pbHMgZG93biB0byAtICBkb2VzIGV2 ZXJ5IGRlbGVnYXRpb24gcmVxdWlyZXMgYSByZXNwb25zZS9hY2sgZnJvbSB0aGUgUENFLiBXZSBh bGwgc2VlbSB0byBiZSBmaW5lIHdpdGggbm90IGdldHRpbmcgYSByZXNwb25zZSB3aGVuIHRoZSBM U1Agd2FzIGFscmVhZHkgdXAuIEZvciBhIGRvd24gTFNQLCBkbyB3ZSBuZWVkIHRvIGNoYW5nZSB0 aGlzIHByb2NlZHVyZT8gSU1PLCBObywgbGV0IHRoZSBQQ0UgZGVjaWRlIHdoYXQgc2hvdWxkIGJl IGRvbmUuLi4gd2FpdCBmb3IgbmV0d29yayBjaGFuZ2UsIG9yIGxvZyB0aGlzIGFuZCBkbyBub3Ro aW5nLCBvciBQQ0UgY2FuIHNlbmQgUENVcGQgd2l0aCBkb3duIGlmIHRoZSBpbXBsZW1lbnRhdGlv biBjaG9vc2VzIHRvIGdvIHRoYXQgd2F5Lg0KDQo+Pg0KPj4NCj4+DQo+Pj4NCj4+Pg0KPj4+DQo+ Pj4gPg0KPj4+ID4gMi4gICAgVGhlIFBDQyBzdGFydHMgaW4gdGhlIGFjdGl2ZSBzdGF0ZWZ1bCBt b2RlIGFuZCBkZWxlZ2F0ZXMgdGhlIExTUCwNCj4+PiA+IHdoaWNoIGlzIGluIGRvd24gc3RhdGUs IHVzaW5nIHRoZSBQQ1JwdCBtZXNzYWdlLiBJbiB0aGlzIGNhc2UsIHRoZSBQQ1JwdCBpcw0KPj4+ ID4gdXNlZCB0byBzeW5jaHJvbml6ZSB0aGUgc3RhdGUgb2YgdGhlIExTUCB3aXRoIHRoZSBQQ0Ug YnV0IGFsc28gYXMgYW4NCj4+PiA+IGltcGxpY2l0IHdheSB0byByZXF1ZXN0IHRoZSBpbml0aWFs IExTUCBwYXRoIGNvbXB1dGF0aW9uLiBUaGUgaXNzdWUgdGhvdWdoDQo+Pj4gPiBpcyB0aGF0IHRo ZSBQQ1JwdCBtZXNzYWdlIGlzIG5vdCBhbiBleHBsaWNpdCBwYXRoIGNvbXB1dGF0aW9uIHJlcXVl c3QgYW5kDQo+Pj4gPiBsYWNrcyB0aGUgZm9sbG93aW5nOg0KPj4+ID4NCj4+PiA+DQo+Pj4NCj4+ PiBJdCBpcyBjb21wbGV0ZWx5IGZpbmUgZm9yIFBDQyB0byBkZWxlZ2F0ZSBhbiB1bnNpZ25hbGxl ZCBMU1AgdG8gUENFLg0KPj4+IEJ1dCBJIHRoaW5rIHdlIHNob3VsZCBub3QgZXF1YXRlIGEgcGF0 aCBjb21wdXRhdGlvbiByZXF1ZXN0IHdpdGgNCj4+PiBkZWxlZ2F0aW9uIGNvbXBsZXRlbHkuIFdp dGggZGVsZWdhdGlvbiB5b3VyIGFpbSBpcyB0byBnaXZlIHVwIHNvbWUNCj4+PiBjb250cm9sIGFu ZCBsZXQgUENFIHJ1biB0aGUgc2hvdywgb25lIHNob3VsZCBub3QgZXhwZWN0IHRoZSBiZWhhdmlv cg0KPj4+IG9mIHRoaXMgYWN0aW9uIHRvIGJlIGV4YWN0bHkgc2FtZSBhcyBhIHBhdGggY29tcHV0 YXRpb24NCj4+PiByZXF1ZXN0L3Jlc3BvbnNlLg0KPj4+DQo+Pg0KPj4gSXMgaXQgcmVhc29uYWJs ZSBmb3IgUENDIHRvIGV4cGVjdCBQQ1VwZCAod2l0aCBwYXRoKT8gb3IgdGhlIFBDRSByZXR1cm5z IGVycm9yIGZvciBwYXRoIHRoYXQgd2FzIG5ldmVyIGNvbXB1dGVkIGVpdGhlciBieSBQQ0Ugb3Ig bG9jYWxseSBieSBQQ0M/DQoNCiNERCAtIEFzIGFib3ZlLCBieSBkZWxlZ2F0aW5nLiBQQ0MgaGFz IGdpdmVuIHVwIGNvbnRyb2wgYW5kIGl0IGlzIFBDRSdzIHByZXJvZ2F0aXZlIHRvIGNob29zZSB0 aGUgcmlnaHQgYWN0aW9uIChvciBpbmFjdGlvbikuIFBDQyBjYW4gYWx3YXlzIHJldm9rZSBkZWxl Z2F0aW9uIGFuZCByZWx5IG9uIHBhc3NpdmUgUENSZXEuDQoNCj4+DQo+PiBXZSByZWNlbnRseSBo YWQgaW50ZXJhY3Rpb24gd2l0aCB2ZW5kb3IgaW1wbGVtZW50aW5nIFBDRVAgdGVzdCB0b29scywg dGhleSBzZWVtIHRvIGludGVycHJldCAiYWN0aXZlIHN0YXRlZnVsIFBDRSIgbmVlZCBub3Qgc3Vw cG9ydCB0aGUgUkZDNTQ0MCBmdW5jdGlvbmFsaXR5IGFuZCBhIFBDQyBjb3VsZCBnZXQgcGF0aCBj b21wdXRlZCBieSBzZW5kaW5nIFBDUnB0ISEhIEkgaG9wZSB0aGlzIGlzIG5vdCBhIHdpZGVseSBj b25jZWl2ZWQgb3BpbmlvbiBpbiBvcmRlciB0byBjaXJjdW12ZW50IFBDUmVxdWVzdC9QQ1JlcGx5 Lg0KDQojREQgLSBJIGFncmVlIGFuZCB0aGF0IGlzIHdoeSBJIGFtIHN1Z2dlc3RpbmcgdG8gbm90 IGVxdWF0ZSB0aGUgcHJvY2VkdXJlcyBvZiBQQ1JlcSB3aXRoIHRoYXQgb2YgZGVsZWdhdGlvbi4u LiBCb3RoIGhhdmUgYSBkaWZmZXJlbnQgcm9sZSB0byBwbGF5Lg0KDQpEaHJ1dg0KDQoNCg0KPj4N Cj4+IFRoYW5rcywNCj4+IEdpcmlzaA0KPj4NCj4NCg== --_000_4A79394211F1AF4EB57D998426C9340D947C1F2DUS70UWXCHMBA04z_ 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 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhhbmtzIERocnV2IGZvciBhbGwgdGhlIGluc2lnaHRz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkl0IHdvdWxkIGJlIGdyZWF0IGlm IHRoZSBhdXRob3JzIG9mIGRyYWZ0LWlldGYtcGNlLXN0YXRlZnVsLXBjZSBhZGRlZCBhIGNsYXJp ZmljYXRpb24gdG8gc2VjdGlvbiA1LjYuMiB0byBzdGF0ZSB0aGF0IFBDQyBjYW4gdXNlIHRoZSBQ Q1JlcS9QQ1JlcCBwcm9jZWR1cmVzIHdpdGggYW4gQWN0aXZlIFN0YXRlZnVsDQogUENFIHRvIHJl cXVlc3QgdGhlIGluaXRpYWwgcGF0aCBvZiBhbiBMU1AgYmVmb3JlIGRlbGVnYXRpb24gdG8gUENF IGFuZCBhbHNvIHN1YnNlcXVlbnRseSBpZiByZXF1aXJlZCBieSByZXZva2luZyBkZWxlZ2F0aW9u IGZyb20gUENFLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+V2UgYmVsaWV2 ZSB0aGlzIHdpbGwgcmVtb3ZlIHNvbWUgYW1iaWd1aXR5LiBBcyBHaXJpc2ggc2FpZCwgd2UgaGFk IHNvbWUgZmVlZGJhY2sgZnJvbSBhIHRlc3QgZXF1aXBtZW50IHZlbmRvciB0aGF0IHRoZWlyIGlu dGVycHJldGF0aW9uIHdhcyB0aGF0IEFjdGl2ZSBTdGF0ZWZ1bCBQQ0UgZG9lcyBub3QNCiBoYXZl IHRvIHN1cHBvcnQgUENSZXEvUENSZXAgcHJvY2VkdXJlcyBhbmQgdGhhdCB0aGUgUENScHQgaXMg dG8gYmUgdXNlZCB0byByZXF1ZXN0IGEgcGF0aCBjb21wdXRhdGlvbi48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk11c3RhcGhhLg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUGNlIFttYWlsdG86cGNlLWJvdW5jZXNAaWV0Zi5v cmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkRocnV2IERob2R5PGJyPg0KPGI+U2VudDo8L2I+IFR1 ZXNkYXksIERlY2VtYmVyIDA5LCAyMDE0IDM6NTEgQU08YnI+DQo8Yj5Ubzo8L2I+IEdpcmlzaCBC aXJhamRhcjxicj4NCjxiPkNjOjwvYj4gcGNlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbUGNlXSBQYXRoIENvbXB1dGF0aW9uIFJlcXVlc3QgaW4gQWN0aXZlIFN0YXRlZnVsIFBD RTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cD5IaSBHaXJpc2gsPG86cD48L286 cD48L3A+DQo8cD5TZWUgaW5saW5lLi4uLjxvOnA+PC9vOnA+PC9wPg0KPHA+T24gRGVjIDksIDIw MTQgNDo0NyBBTSwgJnF1b3Q7R2lyaXNoIEJpcmFqZGFyJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86Z2lyaXNoMTM0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdpcmlzaDEzNEBnbWFpbC5j b208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgcmUtc2VuZGlu ZyB3aXRoIGNvcnJlY3QgZW1haWwgc3ViamVjdC48YnI+DQomZ3Q7IEVhcmxpZXIgZW1haWwgd2Fz IHJlcGx5IHRvIGRpZ2VzdCBmb3JtYXQ8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7 IEhpIERocnV2LDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhhbmtzIGZvciB0aGUgcmVz cG9uc2UuIDxicj4NCiZndDsmZ3Q7IEZldyBxdWVzdGlvbnMvY29tbWVudHMsIHBsZWFzZSBzZWUg aW5saW5lIDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBPbiBTYXQs IERlYyA2LCAyMDE0IGF0IDEyOjAwIFBNLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBjZS1yZXF1ZXN0 QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cGNlLXJlcXVlc3RAaWV0Zi5vcmc8L2E+Jmd0OyB3 cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsgRGF0ZTogU2F0LCA2IERlYyAyMDE0IDExOjU0OjIyICYjNDM7MDUzMDxicj4NCiZndDsmZ3Q7 Jmd0OyBGcm9tOiBEaHJ1diBEaG9keSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRocnV2LmlldGZAZ21h aWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGhydXYuaWV0ZkBnbWFpbC5jb208L2E+Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0OyBUbzogJnF1b3Q7QWlzc2FvdWksIE11c3RhcGhhIChNdXN0YXBoYSkmcXVv dDs8YnI+DQomZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDs8YSBo cmVmPSJtYWlsdG86bXVzdGFwaGEuYWlzc2FvdWlAYWxjYXRlbC1sdWNlbnQuY29tIiB0YXJnZXQ9 Il9ibGFuayI+bXVzdGFwaGEuYWlzc2FvdWlAYWxjYXRlbC1sdWNlbnQuY29tPC9hPiZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsgQ2M6ICZxdW90OzxhIGhyZWY9Im1haWx0bzpwY2VAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5wY2VAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 cGNlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cGNlQGlldGYub3JnPC9hPiZndDs8YnI+DQom Z3Q7Jmd0OyZndDsgU3ViamVjdDogUmU6IFtQY2VdIFBhdGggQ29tcHV0YXRpb24gUmVxdWVzdCBp biBBY3RpdmUgU3RhdGVmdWwgUENFPGJyPg0KJmd0OyZndDsmZ3Q7IE1lc3NhZ2UtSUQ6PGJyPg0K Jmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFp bHRvOkNBQjc1eG41aXY1b0tTMDJTZDJVZlZVRHJaaEdnUFIyaXNacUdSWGtCb25mUVlYOG5Yd0Bt YWlsLmdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkNBQjc1eG41aXY1b0tTMDJTZDJVZlZVRHJa aEdnUFIyaXNacUdSWGtCb25mUVlYOG5Yd0BtYWlsLmdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7IENvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD1VVEYtODxicj4NCiZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBIaSBNdXN0YXBo YSw8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgU2luY2UgZGVsZWdhdGlvbiBp cyBhcHBsaWVkIHBlciBMU1AgYW5kIG5vdCBhbGwgTFNQcyBhcmUgZGVsZWdhdGVkIGl0PGJyPg0K Jmd0OyZndDsmZ3Q7IGlzIHBlcmZlY3RseSBmaW5lIGZvciBhbiBhY3RpdmUgc3RhdGVmdWwgUENF IHRvIHJlY2VpdmUgUENSZXEvUENSZXAuPGJyPg0KJmd0OyZndDsmZ3Q7IEluIHlvdXIgbWFpbCB5 b3UgYXBwbHkgYSBwYXNzaXZlIC8gYWN0aXZlIHByb3BlcnR5IHRvIHdob2xlIFBDQy9QQ0U8YnI+ DQomZ3Q7Jmd0OyZndDsgd2hpY2ggaXMgbm90IGNvcnJlY3QuPGJyPg0KJmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7IEkgc2VlIHRoaXMgYXMgLTxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyBTdGF0ZWxlc3MgUENFPGJyPg0KJmd0OyZndDsmZ3Q7IFN0YXRlbGVzcyBQQ0Ug JiM0MzsgUENScHQgKExTUEJEKSA9IFBhc3NpdmUgU3RhdGVmdWwgUENFPGJyPg0KJmd0OyZndDsm Z3Q7IFN0YXRlbGVzcyBQQ0UgJiM0MzsgUENScHQgKExTUEJEKSAmIzQzOyBQQ1VwZCAoZGVsZWdh dGlvbikgPSBBY3RpdmUgU3RhdGVmdWwgUENFPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAm bmJzcDs8YnI+DQomZ3Q7Jmd0OyBUaGUgZHJhZnQgdG9vIG1lbnRpb25zIHRoaXMgYXMgZGVmaW5p dGlvbnMuJm5ic3A7IEFjdGl2ZSBzdGF0ZWZ1bCBQQ0UgaXMgZXh0ZW5zaW9uIHRvIGZ1bmN0aW9u YWxpdHkgc3VwcG9ydGVkIGJ5IHBhc3NpdmUgc3RhdGVmdWwgUENFLjxicj4NCiZndDsmZ3Q7IEhv d2V2ZXIgdGhlIGludGVyYWN0aW9uIHNob3duIGluIHNlY3Rpb24gNS42LjEmbmJzcDsgYW5kIDUu Ni4yJm5ic3A7IGdpdmVzIGltcHJlc3Npb24gdGhhdCBQQ1JlcXVlc3QgaXMgaGFuZGxlZCBieSBQ Q0UgYWN0aW5nIGFzICZxdW90O3Bhc3NpdmUgc3RhdGVmdWwmcXVvdDsgYW5kIG5vdCAmcXVvdDth Y3RpdmUgc3RhdGVmdWwmcXVvdDsuIFZlcmJhdGltIGludGVycHJldGF0aW9uIG9mIHRoZXNlIHNl Y3Rpb24gY29udHJhZGljdCB0aGUgZGVmaW5pdGlvbnMgZ2l2ZW4gaW4gYmVnaW5uaW5nIG9mDQog dGhlIGRyYWZ0LiBXb3VsZCBpdCBiZSBwb3NzaWJsZSBmb3IgdGhlIGF1dGhvcnMgdG8gYWRkcmVz cyB0aGlzIGlzc3VlIGluIG5leHQgZHJhZnQsIHVubGVzcyB0aGUgdGhlIGRlc2NyaXB0aW9uIGlu IHNlY3Rpb24gNS42LjEgaXMgbm90IG1lYW50IGZvciAmcXVvdDthY3RpdmUgc3RhdGVmdWwmcXVv dDsgUENFLjxvOnA+PC9vOnA+PC9wPg0KPHA+I0REIC0gJm5ic3A7U2luY2UgSSBhbSBub3QgdGhl IGF1dGhvciwgSSB3aWxsIGxldCB0aGVtIG9yIHRoZSBzaGVwaGVyZCByZXNwb25kLiA8bzpwPg0K PC9vOnA+PC9wPg0KPHA+Jmd0OyZndDsgJm5ic3A7PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7IEF0IHRoZSBzYW1lIHRpbWUsIHNvbWVvbmUgbWF5IGNob29zZSB0byBpbXBsZW1l bnQgKGFzIHBlciBzb21lIFNETjxicj4NCiZndDsmZ3Q7Jmd0OyBsaWtlIGRlcGxveW1lbnQpIHRv IG9ubHkgc3VwcG9ydCBkZWxlZ2F0aW9uLiBCdXQgdGhhdCBpcyB0aGVpciBjaG9pY2UuPGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSW4gY2Fz ZSBvbmUgaW1wbGVtZW50cyBhIFBDRSBvbmx5IHdpdGggJnF1b3Q7UENScHQgKExTUEJEKSAmIzQz OyBQQ1VwZCAoZGVsZWdhdGlvbikmcXVvdDssJm5ic3A7IGlzIGl0IGV4cGVjdGVkIHRvIHJlc3Bv bmQgdG8gYSBQQ1JwdCB3aXRoIGRvd24gcGF0aCBpbiBjYXNlIHRoZSBwYXRoIHdhcyBub3QgY29t cHV0ZWQgYXQgUENFPw0KPGJyPg0KJmd0OyZndDsgVGhlIGRyYWZ0IGlzIGNsZWFyIGFib3V0IHVz ZSBvZiBQQ1VwZCAtIG1haW5seSB0byBoYW5kbGUgdG9wb2xvZ3kgZXZlbnRzIHRoYXQgYWZmZWN0 IGV4aXN0aW5nIHBhdGhzIG9yIHRvIGFsbG93IG9wZXJhdG9yIHRvIG9wdGltaXplIG5ldHdvcmsu PG86cD48L286cD48L3A+DQo8cD4jREQgLSBJTU8gdGhpcyBib2lscyBkb3duIHRvIC0gJm5ic3A7 ZG9lcyBldmVyeSBkZWxlZ2F0aW9uIHJlcXVpcmVzIGEmbmJzcDtyZXNwb25zZS9hY2sgZnJvbSB0 aGUgUENFLiBXZSBhbGwgc2VlbSB0byBiZSBmaW5lIHdpdGggbm90IGdldHRpbmcgYSByZXNwb25z ZSB3aGVuIHRoZSBMU1Agd2FzIGFscmVhZHkgdXAuIEZvciBhIGRvd24gTFNQLCBkbyB3ZSBuZWVk IHRvIGNoYW5nZSB0aGlzIHByb2NlZHVyZT8gSU1PLCBObywgbGV0IHRoZSBQQ0UgZGVjaWRlIHdo YXQNCiBzaG91bGQgYmUgZG9uZS4uLiB3YWl0IGZvciBuZXR3b3JrIGNoYW5nZSwgb3IgbG9nIHRo aXMgYW5kIGRvIG5vdGhpbmcsIG9yIFBDRSBjYW4gc2VuZCBQQ1VwZCB3aXRoIGRvd24gaWYgdGhl IGltcGxlbWVudGF0aW9uIGNob29zZXMgdG8gZ28gdGhhdCB3YXkuPG86cD48L286cD48L3A+DQo8 cD4mZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJm5ic3A7PGJyPg0KJmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyAyLiZuYnNwOyAmbmJzcDsgVGhlIFBDQyBz dGFydHMgaW4gdGhlIGFjdGl2ZSBzdGF0ZWZ1bCBtb2RlIGFuZCBkZWxlZ2F0ZXMgdGhlIExTUCw8 YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyB3aGljaCBpcyBpbiBkb3duIHN0YXRlLCB1c2luZyB0aGUg UENScHQgbWVzc2FnZS4gSW4gdGhpcyBjYXNlLCB0aGUgUENScHQgaXM8YnI+DQomZ3Q7Jmd0OyZn dDsgJmd0OyB1c2VkIHRvIHN5bmNocm9uaXplIHRoZSBzdGF0ZSBvZiB0aGUgTFNQIHdpdGggdGhl IFBDRSBidXQgYWxzbyBhcyBhbjxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7IGltcGxpY2l0IHdheSB0 byByZXF1ZXN0IHRoZSBpbml0aWFsIExTUCBwYXRoIGNvbXB1dGF0aW9uLiBUaGUgaXNzdWUgdGhv dWdoPGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsgaXMgdGhhdCB0aGUgUENScHQgbWVzc2FnZSBpcyBu b3QgYW4gZXhwbGljaXQgcGF0aCBjb21wdXRhdGlvbiByZXF1ZXN0IGFuZDxicj4NCiZndDsmZ3Q7 Jmd0OyAmZ3Q7IGxhY2tzIHRoZSBmb2xsb3dpbmc6PGJyPg0KJmd0OyZndDsmZ3Q7ICZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBJ dCBpcyBjb21wbGV0ZWx5IGZpbmUgZm9yIFBDQyB0byBkZWxlZ2F0ZSBhbiB1bnNpZ25hbGxlZCBM U1AgdG8gUENFLjxicj4NCiZndDsmZ3Q7Jmd0OyBCdXQgSSB0aGluayB3ZSBzaG91bGQgbm90IGVx dWF0ZSBhIHBhdGggY29tcHV0YXRpb24gcmVxdWVzdCB3aXRoPGJyPg0KJmd0OyZndDsmZ3Q7IGRl bGVnYXRpb24gY29tcGxldGVseS4gV2l0aCBkZWxlZ2F0aW9uIHlvdXIgYWltIGlzIHRvIGdpdmUg dXAgc29tZTxicj4NCiZndDsmZ3Q7Jmd0OyBjb250cm9sIGFuZCBsZXQgUENFIHJ1biB0aGUgc2hv dywgb25lIHNob3VsZCBub3QgZXhwZWN0IHRoZSBiZWhhdmlvcjxicj4NCiZndDsmZ3Q7Jmd0OyBv ZiB0aGlzIGFjdGlvbiB0byBiZSBleGFjdGx5IHNhbWUgYXMgYSBwYXRoIGNvbXB1dGF0aW9uPGJy Pg0KJmd0OyZndDsmZ3Q7IHJlcXVlc3QvcmVzcG9uc2UuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJcyBpdCByZWFzb25hYmxlIGZvciBQQ0MgdG8gZXhwZWN0 IFBDVXBkICh3aXRoIHBhdGgpPyBvciB0aGUgUENFIHJldHVybnMgZXJyb3IgZm9yIHBhdGggdGhh dCB3YXMgbmV2ZXIgY29tcHV0ZWQgZWl0aGVyIGJ5IFBDRSBvciBsb2NhbGx5IGJ5IFBDQz88bzpw PjwvbzpwPjwvcD4NCjxwPiNERCAtIEFzIGFib3ZlLCBieSBkZWxlZ2F0aW5nLiBQQ0MgaGFzIGdp dmVuIHVwIGNvbnRyb2wgYW5kIGl0IGlzIFBDRSdzJm5ic3A7cHJlcm9nYXRpdmUgdG8gY2hvb3Nl IHRoZSByaWdodCBhY3Rpb24gKG9yIGluYWN0aW9uKS4gUENDIGNhbiBhbHdheXMgcmV2b2tlIGRl bGVnYXRpb24gYW5kIHJlbHkgb24gcGFzc2l2ZSBQQ1JlcS48bzpwPjwvbzpwPjwvcD4NCjxwPiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgV2UgcmVjZW50bHkgaGFkIGludGVyYWN0aW9uIHdpdGggdmVu ZG9yIGltcGxlbWVudGluZyBQQ0VQIHRlc3QgdG9vbHMsIHRoZXkgc2VlbSB0byBpbnRlcnByZXQg JnF1b3Q7YWN0aXZlIHN0YXRlZnVsIFBDRSZxdW90OyBuZWVkIG5vdCBzdXBwb3J0IHRoZSBSRkM1 NDQwIGZ1bmN0aW9uYWxpdHkgYW5kIGEgUENDIGNvdWxkIGdldCBwYXRoIGNvbXB1dGVkIGJ5IHNl bmRpbmcgUENScHQhISEgSSBob3BlIHRoaXMgaXMgbm90IGEgd2lkZWx5IGNvbmNlaXZlZCBvcGlu aW9uDQogaW4gb3JkZXIgdG8gY2lyY3VtdmVudCBQQ1JlcXVlc3QvUENSZXBseS48bzpwPjwvbzpw PjwvcD4NCjxwPiNERCAtIEkgYWdyZWUgYW5kIHRoYXQgaXMgd2h5IEkgYW0gc3VnZ2VzdGluZyB0 byBub3QgZXF1YXRlIHRoZSBwcm9jZWR1cmVzIG9mIFBDUmVxIHdpdGggdGhhdCBvZiBkZWxlZ2F0 aW9uLi4uIEJvdGggaGF2ZSBhIGRpZmZlcmVudCByb2xlIHRvIHBsYXkuPG86cD48L286cD48L3A+ DQo8cD5EaHJ1djxvOnA+PC9vOnA+PC9wPg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD4m Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7Jmd0OyBHaXJpc2g8YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4A79394211F1AF4EB57D998426C9340D947C1F2DUS70UWXCHMBA04z_-- From nobody Thu Dec 18 06:45:09 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 50ADC1A8A39 for ; Thu, 18 Dec 2014 06:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.105 X-Spam-Level: X-Spam-Status: No, score=-0.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, RCVD_IN_DNSWL_NONE=-0.0001, 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 ZCt0zj7pZkIs for ; Thu, 18 Dec 2014 06:45:02 -0800 (PST) Received: from mail.hq.sk (hq.sk [81.89.59.181]) by ietfa.amsl.com (Postfix) with ESMTP id AF6E31A8A3D for ; Thu, 18 Dec 2014 06:45:02 -0800 (PST) Received: from [172.16.4.81] (fw.pantheon.sk [81.89.59.166]) by mail.hq.sk (Postfix) with ESMTPSA id 827FC24032D; Thu, 18 Dec 2014 15:45:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1418913900; bh=oaTP7P+6jAPyyEVa5fhQ4Kd6J2VtZxL8yCufwMR93kg=; h=Date:From:To:Subject:References:In-Reply-To; b=TnAQxhgOGWy/O5giRIhdKmHhg4dV/sl7Yl55azbmrnnYL3AkV3IeJP0KJbH0rh+Mu 37QPjy30UrjTmxKBDY574md3MjHB2c1CA5vwd23+q+p9P2bRwIgJTn1rVw9bw+Pk3e Mi3fNGZJ5PO7NCKMmGatTfVNwvKyvAoCfkyIMdoQ= Message-ID: <5492E86B.9080200@hq.sk> Date: Thu, 18 Dec 2014 15:44:59 +0100 From: Robert Varga User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: julien.meuric@orange.com, "pce@ietf.org" References: <12631_1417454286_547CA2CE_12631_12333_1_547CA2CA.1050804@orange.com> In-Reply-To: <12631_1417454286_547CA2CE_12631_12333_1_547CA2CA.1050804@orange.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/pce/T5YsF6mfPgkXdn3XLcAbi56zEdg Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01 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, 18 Dec 2014 14:45:06 -0000 Hello, donning the implementer (as opposed to co-author) hat, I have comments pertaining to draft-ietf-pce-pce-initiated-lsp, specifically to Section 6. In general it seems to contradict the general outline of the extension as stated in section 3.2 paragraph 4. The first paragraph clearly forbids the use of PCRpt D=0 for PCE-initiated LSPs. It is not clear whether this restriction applies to all PCRpts, or only the PCRpt solicited by the PCInitiate message. Section 3.2 paragraph 4 seems to indicate this applies to solicited PCRpts only, which is what makes sense. A clarification is definitely needed. The third paragraph seems to be replacing the normal delegation mechanics with a PCInitiate-driven exchange. It does not specify whether it is legal for a PCE to send PCUpd(D=1) after a session flap or not. It feels like it is not legal and PCInitiate is intended to fully replace it, but that would contradict section 3.2 paragraph 4. This needs to be clarified. My preference would be to remove pretty much all of this paragraph, bringing the mechanics to what section 3.2 outlines. Unfortunately there are already some implementations deployed, so we need to factor in the compatiblity with the installed base. Can we perhaps allocate another bit in the Stateful PCE Capability TLV and mark the current one as reserved/deprecated? Thanks, Robert On 12/01/2014 06:18 PM, julien.meuric@orange.com wrote: > Dear all, > > As planned, this message ignites a 3-week WG Last Call on both > draft-ietf-pce-pce-initiated-lsp-02 and > draft-ietf-pce-stateful-sync-optimizations-01. It will end on Monday > December 22 at 11:59 PM, HST. > > Please send your comments to the PCE mailing list. > > Thanks, > > JP & Julien > > > _________________________________________________________________________________________________________________________ > > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, > deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > Thank you. > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From nobody Fri Dec 19 01:35:56 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 3BBB01A6F1E for ; Fri, 19 Dec 2014 01:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MANGLED_TRNFER=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Lytv5b6UMyLs for ; Fri, 19 Dec 2014 01:35:53 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40E171A6F01 for ; Fri, 19 Dec 2014 01:35:53 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 49A0C191171 for ; Fri, 19 Dec 2014 10:35:51 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 34090C8065 for ; Fri, 19 Dec 2014 10:35:51 +0100 (CET) Received: from [10.193.71.211] (10.197.38.6) by PEXCVZYH01.corporate.adroot.infra.ftgroup (10.114.1.186) with Microsoft SMTP Server (TLS) id 14.3.210.2; Fri, 19 Dec 2014 10:35:50 +0100 Message-ID: <8075_1418981751_5493F177_8075_9652_1_5493F176.2050504@orange.com> Date: Fri, 19 Dec 2014 10:35:50 +0100 From: Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "pce@ietf.org" References: <20141219004257.5CD03181CD6@rfc-editor.org> In-Reply-To: <20141219004257.5CD03181CD6@rfc-editor.org> X-Forwarded-Message-Id: <20141219004257.5CD03181CD6@rfc-editor.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.197.38.6] X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.19.74820 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/p7ylnxyTMJ1uMsIZJ6O1yGFMoA8 Subject: [Pce] Fwd: RFC 7413 on TCP Fast Open 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: Fri, 19 Dec 2014 09:35:55 -0000 FYI: an experimental RFC. -------- Message transféré -------- Date : Thu, 18 Dec 2014 16:42:57 -0800 De : rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 7413 Title: TCP Fast Open Author: Y. Cheng, J. Chu, S. Radhakrishnan, A. Jain Status: Experimental Stream: IETF Date: December 2014 Mailbox: ycheng@google.com, hkchu@google.com, sivasankar@cs.ucsd.edu, arvind@google.com Pages: 26 Characters: 59945 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tcpm-fastopen-10.txt URL: https://www.rfc-editor.org/rfc/rfc7413.txt This document describes an experimental TCP mechanism called TCP Fast Open (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, and saves up to one full round-trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged. However, TFO deviates from the standard TCP semantics, since the data in the SYN could be replayed to an application in some rare circumstances. Applications should not use TFO unless they can tolerate this issue, as detailed in the Applicability section. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Fri Dec 19 03:57:39 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 E0CC41A907A for ; Fri, 19 Dec 2014 03:57:37 -0800 (PST) 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 vSINxwcMSP9C for ; Fri, 19 Dec 2014 03:57:36 -0800 (PST) Received: from rudy.puc.rediris.es (rudy.puc.rediris.es [IPv6:2001:720:418:ca01::132]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C77F1A90EE for ; Fri, 19 Dec 2014 03:57:36 -0800 (PST) Received: from [84.88.62.208] (helo=leo) by rudy.puc.rediris.es with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Y1wBW-0006Le-LZ for pce@ietf.org; Fri, 19 Dec 2014 12:57:32 +0100 Received: from [84.88.61.50] (unknown [84.88.61.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id 275F21FE2C for ; Fri, 19 Dec 2014 12:57:25 +0100 (CET) X-Envelope-From: ramon.casellas@cttc.es Message-ID: <5494129E.7070504@cttc.es> Date: Fri, 19 Dec 2014 12:57:18 +0100 From: Ramon Casellas User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: pce@ietf.org References: <12631_1417454286_547CA2CE_12631_12333_1_547CA2CA.1050804@orange.com> In-Reply-To: <12631_1417454286_547CA2CE_12631_12333_1_547CA2CA.1050804@orange.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spamina-Bogosity: Unsure X-Spamina-Spam-Score: -0.2 (/) X-Spamina-Spam-Report: Content analysis details: (-0.2 points) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4355] 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: orange.com] Archived-At: http://mailarchive.ietf.org/arch/msg/pce/5veJPWa5hJaOgzC855EHsALQXRQ Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01 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: Fri, 19 Dec 2014 11:57:38 -0000 El 01/12/2014 a las 18:18, julien.meuric@orange.com escribió: > Dear all, > > As planned, this message ignites a 3-week WG Last Call on both > draft-ietf-pce-pce-initiated-lsp-02 Hi authors, all, A fast review of the draft, please note: * Error: "To indicate a delete operation, the PCE MUST use the R flag in the SRP object in a PCUpd message. As a result of the deletion request, the PCC MUST remove all state related to the LSP, and send a PCRpt with the R flag set in the LSP object for the removed state" it should be PCInitiate, as later described in Section 5.4 "PCE-initiated removal of a PCE-initiated LSP is done by setting the R (remove) flag in the SRP Object in the PCInitiate message from the PCE." as well as the RBNF (note that, personally I would favor being picky as in "in the SRP object of the PCE-initiated-lsp-instantiation within the PCInitiate message" etc. notably when multiple lsp requests can be in a message) * Confused by the sentence " Every request from the PCE receives a new SRP-ID-number. This number is unique per PCEP session and is incremented each time an operation (initiation, update, etc) is requested from the PCE" i.e., the "unicity-per-session" (although the intent is clear) * Indent 0,1,2,3 digits to describe bit position in the SRP object format. * Minor nit: IANA considerations section should mention new R flag in SRP. * Error-value=13: LSP cleanup TLV missing -> this looks like a leftover from an old version? * I would have some very minor comments about error conditions, hopefully triggering some discussion - I am a bit confused about the differences between ET=19 -Invalid operation- and ET=24 -LSP instantiation error- ("Is the error a result of an invalid operation? ;)" - Why is "non-zero plsp-id" an invalid operation rather than a "bad parameter value"? - Why is "Speaker identity included for an LSP that is not PCE-initiated" a bad parameter rather than an invalid operation? - Why is there a type "bad parameter value" yet the error "unacceptable instantiation parameters" a value within the "instantiation error" type? I am aware there may be deployments and changing this may be problematic, Best regards Ramon From nobody Fri Dec 19 13:15: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 DF3941A8035; Fri, 19 Dec 2014 13:15:06 -0800 (PST) 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 e9WLim3R6AFO; Fri, 19 Dec 2014 13:15:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5D51A710C; Fri, 19 Dec 2014 13:15:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Liaison Statement Management Tool To: JP Vasseur , Julien Meuric X-Test-IDTracker: no X-IETF-IDTracker: 5.9.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141219211504.11734.57620.idtracker@ietfa.amsl.com> Date: Fri, 19 Dec 2014 13:15:04 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/LPLebAO6-IhqEmPQG_2IjFYvZv0 Cc: Scott Mansfield , pce@ietf.org, naotaka.morita@ntt-at.co.jp Subject: [Pce] New Liaison Statement, "LS on ITU-T SG15 OTNT standardization work plan to pce" 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: Fri, 19 Dec 2014 21:15:07 -0000 Title: LS on ITU-T SG15 OTNT standardization work plan to pce Submission Date: 2014-12-19 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1368/ Please reply by 2015-06-07 From: ITU-T SG 15 (Greg Jones ) To: Path Computation Element (JP Vasseur , Julien Meuric ) Cc: Adrian Farrel ,Alia Atlas ,pce@ietf.org,John Drake ,Scott Mansfield Response Contact: naotaka.morita@ntt-at.co.jp Technical Contact: Purpose: For comment Body: Thank you for your previous review and comments on “Optical Transport Networks & Technologies standardization work plan.†Attached is Issue 19, the latest version that was updated by the SG15 meeting in December 2014. We appreciate your continued review and comments which allow us to keep the document up-to-date. Attach: − OTNT standardization work plan, Issue 19 (TD282/PLEN Rev.1) Attachments: LS on ITU-T SG15 OTNT standardization work plan to pce https://datatracker.ietf.org/documents/LIAISON/liaison-2014-12-19-itu-t-sg-15-pce-ls-on-itu-t-sg15-otnt-standardization-work-plan-to-pce-attachment-1.zip From nobody Mon Dec 22 02:44:01 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 064421A8A44 for ; Mon, 22 Dec 2014 02:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 xV0Vayp8bCIB for ; Mon, 22 Dec 2014 02:43:52 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 482F51A8A5A for ; Mon, 22 Dec 2014 02:43:46 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNE31253; Mon, 22 Dec 2014 10:43:44 +0000 (GMT) Received: from blreml403-hub.china.huawei.com (10.18.96.135) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 22 Dec 2014 10:43:43 +0000 Received: from BLREML504-MBX.china.huawei.com ([169.254.1.96]) by blreml403-hub.china.huawei.com ([10.18.96.135]) with mapi id 14.03.0158.001; Mon, 22 Dec 2014 16:13:39 +0530 From: Dhruv Dhody To: "julien.meuric@orange.com" , "pce@ietf.org" Thread-Topic: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01 Thread-Index: AQHQDYrNBgKkLU6uSkm3AuIgHaEXSJybM31g Date: Mon, 22 Dec 2014 10:43:39 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8700D7AD@blreml504-mbx.china.huawei.com> References: <12631_1417454286_547CA2CE_12631_12333_1_547CA2CA.1050804@orange.com> In-Reply-To: <12631_1417454286_547CA2CE_12631_12333_1_547CA2CA.1050804@orange.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.146.248] 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/I5QDBjReAj1YMS6IDkfYiQ-8bKw Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01 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, 22 Dec 2014 10:43:56 -0000 Hi All,=20 > As planned, this message ignites a 3-week WG Last Call on both > draft-ietf-pce-pce-initiated-lsp-02=20 Support with following comments:=20 (1) We should align the tone of the draft to http://tools.ietf.org/html/rfc= 7399#section-20 which differentiates between the recommendation for instant= iation (this draft), and the actual (NMS like) instantiation of the LSPs (m= arked out of scope). This could either be done by a suitable text in Introd= uction and/or use of phrase 'recommend instantiation' in the document.=20 (2) In sec 3.2, OLD: To indicate a delete operation, the PCE MUST use the R flag in the SRP object in a PCUpd message. NEW: To indicate a delete operation, the PCE MUST use the R flag in the SRP object in a PCInitiate message. I guess Ramon pointed this out already!=20 (3) In sec 5.3.1, we are changing the meaning of the SPEAKER-IDENTITY-ID TL= V, which was earlier used in OPEN to identify the exact PCEP-Speaker but no= w here it identifies the PCE that initiated the LSP. This looks like a hack= , a better idea would be to define a new TLV type PCE-INITIATED-IDENTITY-ID= with the same format.=20 (4) Section 9.1, it says... Rapid flaps triggered by the PCE can also be an attack vector. This will be discussed in a future version of this document. The text for this needs to be added.=20 (5) It would be nice to have a manageability consideration section.=20 (6) Few lines on state synchronization should also be added - If the DB di= d not survive the PCC restart, PCE must send the PCE initiated message agai= n. During state synchronization the PCE should get the status of PCE Initia= ted LSPs with C flag set in the LSP object. Incase of redelegation to a dif= ferent PCE the same should be reported during state synchnronization with D= =3D0. The original PCE should also be allowed to send PCInitiate to get bac= k the delegation. (this is not allowed in the current text as PCInitiate wi= th non-zero PLSP-ID is allowed only during State Timeout timer) =20 Nits - Reference to 2119, as SHOULD, MUST are used in the document=20 - Expand on first use LER, LSR etc=20 - Reference to SRP, LSP, PLSP-ID as defined in [I-D.ietf-pce-stateful-pce] - section 3.2 s/PCinitiate/PCInitiate/ - section 4 s/A PCC indicates its ability.../A PCEP speaker indicates its a= bility/ (because both PCC and PCE needs to do this) - section 4.1 Type=3D16 should be removed as its TBD in the base document a= s well http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-10#section-7.= 1.1 - section 4.1=20 OLD: If set to 1 by a PCE, the I flag indicates that the PCE will attempt to instantiate LSPs. NEW: If set to 1 by a PCE, the I flag indicates that the PCE can attempt to instantiate LSPs. > and draft-ietf-pce-stateful-sync- > optimizations-01.=20 Support (As a co-author) Regards, Dhruv > It will end on Monday December 22 at 11:59 PM, HST. >=20 > Please send your comments to the PCE mailing list. >=20 > Thanks, >=20 > JP & Julien >=20 >=20 > _____________________________________________________________________ > ____________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > que les pieces jointes. Les messages electroniques etant susceptibles > d'alteration, Orange decline toute responsabilite si ce message a ete > altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or > privileged information that may be protected by law; they should not > be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender > and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From nobody Mon Dec 22 02:45:18 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 EDAA41A8A45 for ; Mon, 22 Dec 2014 02:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 gtTbeFyytUT0 for ; Mon, 22 Dec 2014 02:45:09 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEE541A8A44 for ; Mon, 22 Dec 2014 02:45:08 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNE31417; Mon, 22 Dec 2014 10:45:07 +0000 (GMT) Received: from blreml402-hub.china.huawei.com (10.18.96.69) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 22 Dec 2014 10:45:06 +0000 Received: from BLREML504-MBX.china.huawei.com ([169.254.1.96]) by blreml402-hub.china.huawei.com ([10.18.96.69]) with mapi id 14.03.0158.001; Mon, 22 Dec 2014 16:14:56 +0530 From: Dhruv Dhody To: Robert Varga , "julien.meuric@orange.com" , "pce@ietf.org" Thread-Topic: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01 Thread-Index: AQHQDYrNBgKkLU6uSkm3AuIgHaEXSJyVKxuAgAZUNUA= Date: Mon, 22 Dec 2014 10:44:56 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8700D7BB@blreml504-mbx.china.huawei.com> References: <12631_1417454286_547CA2CE_12631_12333_1_547CA2CA.1050804@orange.com> <5492E86B.9080200@hq.sk> In-Reply-To: <5492E86B.9080200@hq.sk> Accept-Language: en-GB, en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.146.248] 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/N67h__EkzzjRYQxWT45sOAxNN9A Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01 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, 22 Dec 2014 10:45:13 -0000 Hi Robert,=20 See inline... > -----Original Message----- > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Robert Varga > Sent: 18 December 2014 20:15 > To: julien.meuric@orange.com; pce@ietf.org > Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp- > 02 and draft-ietf-pce-stateful-sync-optimizations-01 >=20 > Hello, >=20 > donning the implementer (as opposed to co-author) hat, I have > comments pertaining to draft-ietf-pce-pce-initiated-lsp, specifically > to Section 6. In general it seems to contradict the general outline > of the extension as stated in section 3.2 paragraph 4. >=20 > The first paragraph clearly forbids the use of PCRpt D=3D0 for PCE- > initiated LSPs. It is not clear whether this restriction applies to > all PCRpts, or only the PCRpt solicited by the PCInitiate message. > Section 3.2 paragraph 4 seems to indicate this applies to solicited > PCRpts only, which is what makes sense. A clarification is definitely > needed. But http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-10#section-5.5.1= says..=20 Note that for an LSP to remain delegated to a PCE, the PCC MUST set the Delegate flag to 1 on each LSP Status Report sent to the PCE. So the D flag must be set on all PCRpts (including the solicited (first) PC= Rpt and any other PCRpt message).=20 I am not sure what text in section 3.2 paragraph 4 is an issue? =20 >=20 > The third paragraph seems to be replacing the normal delegation > mechanics with a PCInitiate-driven exchange. It does not specify > whether it is legal for a PCE to send PCUpd(D=3D1) after a session flap > or not. It feels like it is not legal and PCInitiate is intended to > fully replace it, but that would contradict section 3.2 paragraph 4. > This needs to be clarified. I think some clarification is needed. The text says.. In case of PCEP session failure, control over PCE-initiated LSPs reverts to the PCC at the expiration of the redelegation timeout. To obtain control of a PCE-initiated LSP, a PCE (either the original or one of its backups) sends a PCInitiate message, including just the SRP and LSP objects, and carrying the PLSP-ID of the LSP it wants to take control of. During state synchronization itself (full or incremental) the D flag could = be set while reporting the status of PCE-Initiated LSP (with C flag set) if= re-delegation is not done to another PCE. I feel the same behavior make se= nse for PCC-Initiated LSP as well incase one wants to delegate to the same = PCE again after session down. It should not be mandatory to send PCInitiage= message in all cases.=20 Regards, Dhruv >=20 > My preference would be to remove pretty much all of this paragraph, > bringing the mechanics to what section 3.2 outlines. Unfortunately > there are already some implementations deployed, so we need to factor > in the compatiblity with the installed base. Can we perhaps allocate > another bit in the Stateful PCE Capability TLV and mark the current > one as reserved/deprecated? >=20 > Thanks, > Robert >=20 > On 12/01/2014 06:18 PM, julien.meuric@orange.com wrote: > > Dear all, > > > > As planned, this message ignites a 3-week WG Last Call on both > > draft-ietf-pce-pce-initiated-lsp-02 and > > draft-ietf-pce-stateful-sync-optimizations-01. It will end on > Monday > > December 22 at 11:59 PM, HST. > > > > Please send your comments to the PCE mailing list. > > > > Thanks, > > > > JP & Julien > > > > > > > _____________________________________________________________________ > _ > > ___________________________________________________ > > > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre > diffuses, > > exploites ou copies sans autorisation. Si vous avez recu ce message > > par erreur, veuillez le signaler a l'expediteur et le detruire > ainsi > > que les pieces jointes. Les messages electroniques etant > susceptibles > > d'alteration, Orange decline toute responsabilite si ce message a > ete > > altere, deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; they should > not > > be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender > and > > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that > have > > been modified, changed or falsified. > > Thank you. > > > > _______________________________________________ > > Pce mailing list > > Pce@ietf.org > > https://www.ietf.org/mailman/listinfo/pce >=20 > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From nobody Mon Dec 22 02:59: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 93C691A037B for ; Mon, 22 Dec 2014 02:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 Ns07iy0jAcQF for ; Mon, 22 Dec 2014 02:59:08 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B1551A8A61 for ; Mon, 22 Dec 2014 02:59:07 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id A510E8F7246B4; Mon, 22 Dec 2014 10:59:04 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id sBMAx3Jg002248 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Dec 2014 11:59:04 +0100 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.228]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 22 Dec 2014 11:59:04 +0100 From: "BELOTTI, SERGIO (SERGIO)" To: Dhruv Dhody Thread-Topic: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01 Thread-Index: AQHQDYrMZlVMJ2H6TESdsRwzQQLQWZybfHGAgAATyGA= Date: Mon, 22 Dec 2014 10:59:03 +0000 Message-ID: References: <12631_1417454286_547CA2CE_12631_12333_1_547CA2CA.1050804@orange.com> <23CE718903A838468A8B325B80962F9B8700D7AD@blreml504-mbx.china.huawei.com> In-Reply-To: <23CE718903A838468A8B325B80962F9B8700D7AD@blreml504-mbx.china.huawei.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.38] Content-Type: multipart/alternative; boundary="_000_B9FEE68CE3A78C41A2B3C67549A96F486D5624A4FR711WXCHMBA05z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/7ld3Pbc38pjqpOz4dSZg4G_04fk Cc: "pce@ietf.org" Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01 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, 22 Dec 2014 10:59:11 -0000 --_000_B9FEE68CE3A78C41A2B3C67549A96F486D5624A4FR711WXCHMBA05z_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Druhv, as I pointed out in mail, in section 3.2 , when you talked about R flad in SRP, the fleg is new and i= s introduced in the following chapter. For me text should be: (2) In sec 3.2, OLD: To indicate a delete operation, the PCE MUST use the R flag in the SRP obje= ct in a PCUpd message. NEW: To indicate a delete operation, a new R flag is introduced in the SRP objec= t and to be used in a PCInitiate message. Thanks Sergio -----Original Message----- From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Dhruv Dhody Sent: luned=EC 22 dicembre 2014 11:44 To: julien.meuric@orange.com; pce@ietf.org Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and = draft-ietf-pce-stateful-sync-optimizations-01 Hi All, > As planned, this message ignites a 3-week WG Last Call on both > draft-ietf-pce-pce-initiated-lsp-02 Support with following comments: (1) We should align the tone of the draft to http://tools.ietf.org/html/rfc= 7399#section-20 which differentiates between the recommendation for instant= iation (this draft), and the actual (NMS like) instantiation of the LSPs (m= arked out of scope). This could either be done by a suitable text in Introd= uction and/or use of phrase 'recommend instantiation' in the document. (2) In sec 3.2, OLD: To indicate a delete operation, the PCE MUST use the R flag in the SRP obje= ct in a PCUpd message. NEW: To indicate a delete operation, the PCE MUST use the R flag in the SRP obje= ct in a PCInitiate message. I guess Ramon pointed this out already! (3) In sec 5.3.1, we are changing the meaning of the SPEAKER-IDENTITY-ID TL= V, which was earlier used in OPEN to identify the exact PCEP-Speaker but no= w here it identifies the PCE that initiated the LSP. This looks like a hack= , a better idea would be to define a new TLV type PCE-INITIATED-IDENTITY-ID= with the same format. (4) Section 9.1, it says... Rapid flaps triggered by the PCE can also be an attack vector. This will b= e discussed in a future version of this document. The text for this needs to be added. (5) It would be nice to have a manageability consideration section. (6) Few lines on state synchronization should also be added - If the DB di= d not survive the PCC restart, PCE must send the PCE initiated message agai= n. During state synchronization the PCE should get the status of PCE Initia= ted LSPs with C flag set in the LSP object. Incase of redelegation to a dif= ferent PCE the same should be reported during state synchnronization with D= =3D0. The original PCE should also be allowed to send PCInitiate to get bac= k the delegation. (this is not allowed in the current text as PCInitiate wi= th non-zero PLSP-ID is allowed only during State Timeout timer) Nits - Reference to 2119, as SHOULD, MUST are used in the document - Expand on first use LER, LSR etc - Reference to SRP, LSP, PLSP-ID as defined in [I-D.ietf-pce-stateful-pce] - section 3.2 s/PCinitiate/PCInitiate/ - section 4 s/A PCC indicates its ability.../A PCEP speaker indicates its a= bility/ (because both PCC and PCE needs to do this) - section 4.1 Type=3D16 should be removed as its TBD in the base document a= s well http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-10#section-7.= 1.1 - section 4.1 OLD: If set to 1 by a PCE, the I flag indicates that the PCE will attempt to ins= tantiate LSPs. NEW: If set to 1 by a PCE, the I flag indicates that the PCE can attempt to inst= antiate LSPs. > and draft-ietf-pce-stateful-sync- > optimizations-01. Support (As a co-author) Regards, Dhruv > It will end on Monday December 22 at 11:59 PM, HST. > > Please send your comments to the PCE mailing list. > > Thanks, > > JP & Julien > > > _____________________________________________________________________ > ____________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > que les pieces jointes. Les messages electroniques etant susceptibles > d'alteration, Orange decline toute responsabilite si ce message a ete > altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; they should not > be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > Thank you. > > _______________________________________________ > 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 --_000_B9FEE68CE3A78C41A2B3C67549A96F486D5624A4FR711WXCHMBA05z_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Druhv,

as I pointed out in mail,

in section 3.2 , when you ta= lked about R flad in SRP, the fleg is new and is introduced in the followin= g chapter.

For me text should be:<= /o:p>

(2) In sec 3.2,

OLD:

To indicate a delete operati= on, the PCE MUST use the R flag in the SRP object in a PCUpd message.<= /o:p>

NEW:

To indicate a delete operati= on, a new R flag is introduced in the SRP object and to be used in a PCInitiate= message.

 

Thanks

 

Sergio

 

 

 

-----Original Message----- From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Dhruv Dhody
Sent: luned=EC 22 dicembre 2014 11:44
To: julien.meuric@orange.com; pce@ietf.org
Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and = draft-ietf-pce-stateful-sync-optimizations-01

 

Hi All,

 

> As planned, this message ignites a 3-week WG= Last Call on both

> draft-ietf-pce-pce-initiated-lsp-02

 

Support with following comments:

 

(1) We should align the tone of the draft to http://tools.ietf.org= /html/rfc7399#section-20 which differentiates between the recomm= endation for instantiation (this draft), and the actual (NMS like) instanti= ation of the LSPs (marked out of scope). This could either be done by a suitable text in Introduction and/or use of= phrase 'recommend instantiation' in the document.

 

(2) In sec 3.2,

OLD:

To indicate a delete operation, the PCE MUST use = the R flag in the SRP object in a PCUpd message.

NEW:

To indicate a delete operation, the PCE MUST use = the R flag in the SRP object in a PCInitiate message.

 

I guess Ramon pointed this out already!

 

(3) In sec 5.3.1, we are changing the meaning of = the SPEAKER-IDENTITY-ID TLV, which was earlier used in OPEN to identify the= exact PCEP-Speaker but now here it identifies the PCE that initiated the L= SP. This looks like a hack, a better idea would be to define a new TLV type PCE-INITIATED-IDENTITY-ID with the = same format.

 

(4) Section 9.1, it says...

Rapid flaps triggered by the PCE can also be an a= ttack vector.  This will be discussed in a future version of this docu= ment.

 

The text for this needs to be added. <= /p>

 

(5) It would be nice to have a manageability cons= ideration section.

 

(6) Few lines on state synchronization should als= o be added -  If the DB did not survive the PCC restart, PCE must send= the PCE initiated message again. During state synchronization the PCE shou= ld get the status of PCE Initiated LSPs with C flag set in the LSP object. Incase of redelegation to a different P= CE the same should be reported during state synchnronization with D=3D0. Th= e original PCE should also be allowed to send PCInitiate to get back the de= legation. (this is not allowed in the current text as PCInitiate with non-zero PLSP-ID is allowed only durin= g State Timeout timer) 

 

Nits

- Reference to 2119, as SHOULD, MUST are used in = the document

- Expand on first use LER, LSR etc

- Reference to SRP, LSP, PLSP-ID as defined in [I= -D.ietf-pce-stateful-pce]

- section 3.2 s/PCinitiate/PCInitiate/=

- section 4 s/A PCC indicates its ability.../A PC= EP speaker indicates its ability/ (because both PCC and PCE needs to do thi= s)

- section 4.1 Type=3D16 should be removed as its = TBD in the base document as well http://tools.ietf.org= /html/draft-ietf-pce-stateful-pce-10#section-7.1.1

- section 4.1

OLD:

If set to 1 by a PCE, the I flag indicates that t= he PCE will attempt to instantiate LSPs.

NEW:

If set to 1 by a PCE, the I flag indicates that t= he PCE can attempt to instantiate LSPs.

 

 

> and draft-ietf-pce-stateful-sync-=

> optimizations-01.

 

Support (As a co-author)

 

Regards,

Dhruv

 

> It will end on Monday December 22 at 11:59 P= M, HST.

>

> Please send your comments to the PCE mailing= list.

>

> Thanks,

>

> JP & Julien

>

>

> ____________________________________________= _________________________

> ____________________________________________= ________

>

> Ce message et ses pieces jointes peuvent con= tenir des informations

> confidentielles ou privilegiees et ne doiven= t donc pas etre diffuses,

> exploites ou copies sans autorisation. Si vo= us avez recu ce message

> par erreur, veuillez le signaler a l'expedit= eur et le detruire ainsi

> que les pieces jointes. Les messages electro= niques etant susceptibles

> d'alteration, Orange decline toute responsab= ilite si ce message a ete

> altere, deforme ou falsifie. Merci.

>

> This message and its attachments may contain= confidential or

> privileged information that may be protected= by law; they should not

> be distributed, used or copied without autho= risation.

> If you have received this email in error, pl= ease notify the sender and

> delete this message and its attachments.

> As emails may be altered, Orange is not liab= le for messages that have

> been modified, changed or falsified.

> Thank you.

>

> ____________________________________________= ___

> 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

--_000_B9FEE68CE3A78C41A2B3C67549A96F486D5624A4FR711WXCHMBA05z_-- From nobody Mon Dec 22 07:07:53 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 08A381A90D1 for ; Mon, 22 Dec 2014 07:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.104 X-Spam-Level: X-Spam-Status: No, score=-0.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 T9OANbYNADpp for ; Mon, 22 Dec 2014 07:07:44 -0800 (PST) Received: from mail.hq.sk (hq.sk [81.89.59.181]) by ietfa.amsl.com (Postfix) with ESMTP id AF47B1A1A04 for ; Mon, 22 Dec 2014 07:07:43 -0800 (PST) Received: from [192.168.43.246] (pat-ip-195-91-13-119.gprs.as5628.telecom.sk [195.91.13.119]) by mail.hq.sk (Postfix) with ESMTPSA id 5C1C0241797; Mon, 22 Dec 2014 16:07:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1419260861; bh=R/vr25jujUa0DV9M1zgySVtA+HKFp9IEhefaVVMccMM=; h=Date:From:To:Subject:References:In-Reply-To; b=ITiJa9P/lNIKk7Z6w6UokRH1TP1heHBV2HZBdeVTEKB2HTVf/chHW0uXD58UIDHA/ 9mayuUCLceJB8MBv+7B0QSCSP2o4yYQyjstQVHZc40oVmDW3ojkCU6Rx8Dl+HSRIcx omuU6qXQiwAwZI5sqD83tCtkeAzaqbp5hzXfry38= Message-ID: <549833BC.1020203@hq.sk> Date: Mon, 22 Dec 2014 16:07:40 +0100 From: Robert Varga User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Dhruv Dhody , "julien.meuric@orange.com" , "pce@ietf.org" References: <12631_1417454286_547CA2CE_12631_12333_1_547CA2CA.1050804@orange.com> <5492E86B.9080200@hq.sk> <23CE718903A838468A8B325B80962F9B8700D7BB@blreml504-mbx.china.huawei.com> In-Reply-To: <23CE718903A838468A8B325B80962F9B8700D7BB@blreml504-mbx.china.huawei.com> Content-Type: multipart/alternative; boundary="------------090608060408040606010404" Archived-At: http://mailarchive.ietf.org/arch/msg/pce/mdDZfloXlR3vvr5-qb_auzKZQS8 Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01 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, 22 Dec 2014 15:07:49 -0000 This is a multi-part message in MIME format. --------------090608060408040606010404 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 12/22/2014 11:44 AM, Dhruv Dhody wrote: > Hi Robert, Hello Dhruv, See inline > See inline... > >> -----Original Message----- >> From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Robert Varga >> Sent: 18 December 2014 20:15 >> To: julien.meuric@orange.com; pce@ietf.org >> Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp- >> 02 and draft-ietf-pce-stateful-sync-optimizations-01 >> >> Hello, >> >> donning the implementer (as opposed to co-author) hat, I have >> comments pertaining to draft-ietf-pce-pce-initiated-lsp, specifically >> to Section 6. In general it seems to contradict the general outline >> of the extension as stated in section 3.2 paragraph 4. >> >> The first paragraph clearly forbids the use of PCRpt D=0 for PCE- >> initiated LSPs. It is not clear whether this restriction applies to >> all PCRpts, or only the PCRpt solicited by the PCInitiate message. >> Section 3.2 paragraph 4 seems to indicate this applies to solicited >> PCRpts only, which is what makes sense. A clarification is definitely >> needed. > > But http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-10#section-5.5.1 says.. > > Note that for an LSP to remain delegated to a PCE, the PCC MUST set > the Delegate flag to 1 on each LSP Status Report sent to the PCE. > > So the D flag must be set on all PCRpts (including the solicited (first) PCRpt and any other PCRpt message). Right, but that would also mean that a PCE-initiated LSP cannot be reported to backup PCEs, as that would mean the LSP is delegated to multiple PCEs at the same time... > > > I am not sure what text in section 3.2 paragraph 4 is an issue? The specific text is this: Once instantiated, the delegation procedures for PCE-initiated LSPs are the same as for PCC initiated LSPs as described in [I-D.ietf-pce-stateful-pce ]. This applies to the case of a PCE failure as well. Which is precisely what I understand you are implying in your response below. >> The third paragraph seems to be replacing the normal delegation >> mechanics with a PCInitiate-driven exchange. It does not specify >> whether it is legal for a PCE to send PCUpd(D=1) after a session flap >> or not. It feels like it is not legal and PCInitiate is intended to >> fully replace it, but that would contradict section 3.2 paragraph 4. >> This needs to be clarified. > I think some clarification is needed. The text says.. > > In case of PCEP session failure, control over PCE-initiated LSPs > reverts to the PCC at the expiration of the redelegation timeout. To > obtain control of a PCE-initiated LSP, a PCE (either the original or > one of its backups) sends a PCInitiate message, including just the > SRP and LSP objects, and carrying the PLSP-ID of the LSP it wants to > take control of. > > During state synchronization itself (full or incremental) the D flag could be set while reporting the status of PCE-Initiated LSP (with C flag set) if re-delegation is not done to another PCE. I feel the same behavior make sense for PCC-Initiated LSP as well incase one wants to delegate to the same PCE again after session down. It should not be mandatory to send PCInitiage message in all cases. > > Regards, > Dhruv Bye, Robert >> My preference would be to remove pretty much all of this paragraph, >> bringing the mechanics to what section 3.2 outlines. Unfortunately >> there are already some implementations deployed, so we need to factor >> in the compatiblity with the installed base. Can we perhaps allocate >> another bit in the Stateful PCE Capability TLV and mark the current >> one as reserved/deprecated? >> >> Thanks, >> Robert >> >> On 12/01/2014 06:18 PM, julien.meuric@orange.com wrote: >>> Dear all, >>> >>> As planned, this message ignites a 3-week WG Last Call on both >>> draft-ietf-pce-pce-initiated-lsp-02 and >>> draft-ietf-pce-stateful-sync-optimizations-01. It will end on >> Monday >>> December 22 at 11:59 PM, HST. >>> >>> Please send your comments to the PCE mailing list. >>> >>> Thanks, >>> >>> JP & Julien >>> >>> >>> >> _____________________________________________________________________ >> _ >>> ___________________________________________________ >>> >>> >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre >> diffuses, >>> exploites ou copies sans autorisation. Si vous avez recu ce message >>> par erreur, veuillez le signaler a l'expediteur et le detruire >> ainsi >>> que les pieces jointes. Les messages electroniques etant >> susceptibles >>> d'alteration, Orange decline toute responsabilite si ce message a >> ete >>> altere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should >> not >>> be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender >> and >>> delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that >> have >>> been modified, changed or falsified. >>> Thank you. >>> >>> _______________________________________________ >>> 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 --------------090608060408040606010404 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
On 12/22/2014 11:44 AM, Dhruv Dhody wrote:
Hi Robert,

Hello Dhruv,

See inline

See inline...


-----Original Message-----
From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Robert Varga
Sent: 18 December 2014 20:15
To: julien.meuric@orange.com; pce@ietf.org
Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-
02 and draft-ietf-pce-stateful-sync-optimizations-01

Hello,

donning the implementer (as opposed to co-author) hat, I have
comments pertaining to draft-ietf-pce-pce-initiated-lsp, specifically
to Section 6. In general it seems to contradict the general outline
of the extension as stated in section 3.2 paragraph 4.

The first paragraph clearly forbids the use of PCRpt D=0 for PCE-
initiated LSPs. It is not clear whether this restriction applies to
all PCRpts, or only the PCRpt solicited by the PCInitiate message.
Section 3.2 paragraph 4 seems to indicate this applies to solicited
PCRpts only, which is what makes sense. A clarification is definitely
needed.


But http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-10#section-5.5.1 says.. 

Note that for an LSP to remain delegated to a PCE, the PCC MUST set
the Delegate flag to 1 on each LSP Status Report sent to the PCE.

So the D flag must be set on all PCRpts (including the solicited (first) PCRpt and any other PCRpt message).

Right, but that would also mean that a PCE-initiated LSP cannot be reported to backup PCEs, as that would mean the LSP is delegated to multiple PCEs at the same time...

 

I am not sure what text in section 3.2 paragraph 4 is an issue?

The specific text is this:
   Once instantiated, the delegation procedures for PCE-initiated LSPs
   are the same as for PCC initiated LSPs as described in
   [I-D.ietf-pce-stateful-pce].  This applies to the case of a PCE
   failure as well.
Which is precisely what I understand you are implying in your response below.


The third paragraph seems to be replacing the normal delegation
mechanics with a PCInitiate-driven exchange. It does not specify
whether it is legal for a PCE to send PCUpd(D=1) after a session flap
or not. It feels like it is not legal and PCInitiate is intended to
fully replace it, but that would contradict section 3.2 paragraph 4.
This needs to be clarified.

I think some clarification is needed. The text says..

In case of PCEP session failure, control over PCE-initiated LSPs
reverts to the PCC at the expiration of the redelegation timeout.  To
obtain control of a PCE-initiated LSP, a PCE (either the original or
one of its backups) sends a PCInitiate message, including just the
SRP and LSP objects, and carrying the PLSP-ID of the LSP it wants to
take control of.

During state synchronization itself (full or incremental) the D flag could be set while reporting the status of PCE-Initiated LSP (with C flag set) if re-delegation is not done to another PCE. I feel the same behavior make sense for PCC-Initiated LSP as well incase one wants to delegate to the same PCE again after session down. It should not be mandatory to send PCInitiage message in all cases. 

Regards,
Dhruv

Bye,
Robert


      

        
My preference would be to remove pretty much all of this paragraph,
bringing the mechanics to what section 3.2 outlines. Unfortunately
there are already some implementations deployed, so we need to factor
in the compatiblity with the installed base. Can we perhaps allocate
another bit in the Stateful PCE Capability TLV and mark the current
one as reserved/deprecated?

Thanks,
Robert

On 12/01/2014 06:18 PM, julien.meuric@orange.com wrote:


        

          
Dear all,

As planned, this message ignites a 3-week WG Last Call on both
draft-ietf-pce-pce-initiated-lsp-02 and
draft-ietf-pce-stateful-sync-optimizations-01. It will end on


        

        
Monday


        

          
December 22 at 11:59 PM, HST.

Please send your comments to the PCE mailing list.

Thanks,

JP & Julien





        

        
_____________________________________________________________________
_


        

          
___________________________________________________


Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc pas etre


        

        
diffuses,


        

          
exploites ou copies sans autorisation. Si vous avez recu ce message
par erreur, veuillez le signaler a l'expediteur et le detruire


        

        
ainsi


        

          
que les pieces jointes. Les messages electroniques etant


        

        
susceptibles


        

          
d'alteration, Orange decline toute responsabilite si ce message a


        

        
ete


        

          
altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or
privileged information that may be protected by law; they should


        

        
not


        

          
be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender


        

        
and


        

          
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that


        

        
have


        

          
been modified, changed or falsified.
Thank you.

_______________________________________________
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


      

    

    

  


--------------090608060408040606010404--


From nobody Mon Dec 22 08:36:49 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 DFDF61A1A29 for ; Mon, 22 Dec 2014 08:36:44 -0800 (PST)
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 JLQ1ke3ts5kG for ; Mon, 22 Dec 2014 08:36:38 -0800 (PST)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D3941A0687 for ; Mon, 22 Dec 2014 08:36:38 -0800 (PST)
Received: by mail-wi0-f176.google.com with SMTP id ex7so8569596wid.3 for ; Mon, 22 Dec 2014 08:36:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YfFYKT3px/2PUXqu9BvpjfiJUM8O4S5i/Ze4Un9OE9M=; b=MmWdx5uZTE1/pPnWO7W/y8kpQFSOotKX2B0yPFlsXvR/nbdNrWH62u5SRfaATSrcqF w54iUl8nn4v/mf3WFAKW8fthZ1v9DIAYCY3w/zIe2NukHA1FHp4fsU+RRhc0t/XxaZ5T FMRTdPewxNfzkPeSIgX1M1rJaqOcaCr2sBE0aYDo/ZvJiefKGktgjj0FCL/fj5cKDEz+ RrexGtWBvnHCMzDR6URr3t8hLRl8mOowKgiZHv45WXkgePu/WtVU8Gz1m+1YOUBXKXXy BFFON5wmyc31FUiNWaunCIUOrf4kgLmNhsHTdRfKLfEnPpZse+J3LzTcrG/AUCtY6cAg sAAQ==
MIME-Version: 1.0
X-Received: by 10.194.175.2 with SMTP id bw2mr35823313wjc.117.1419266196366; Mon, 22 Dec 2014 08:36:36 -0800 (PST)
Received: by 10.27.89.133 with HTTP; Mon, 22 Dec 2014 08:36:36 -0800 (PST)
In-Reply-To: 
References: <12631_1417454286_547CA2CE_12631_12333_1_547CA2CA.1050804@orange.com> <23CE718903A838468A8B325B80962F9B8700D7AD@blreml504-mbx.china.huawei.com> 
Date: Mon, 22 Dec 2014 11:36:36 -0500
Message-ID: 
From: Cyril Margaria 
To: "BELOTTI, SERGIO (SERGIO)" 
Content-Type: multipart/alternative; boundary=089e013d0f8479ebbb050ad0a987
Archived-At: http://mailarchive.ietf.org/arch/msg/pce/fr7ndNHcZFIRA3fxXu7gyqPVjkE
Cc: "pce@ietf.org" 
Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01
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, 22 Dec 2014 16:36:45 -0000

--089e013d0f8479ebbb050ad0a987
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

I have the following comments on draft-ietf-pce-pce-initiated-lsp-02:
Some comments require non minor changes (security section). I think the
document should progress, but I am not sure its fully ready for LC.

Section 3.2. "Operation overview"

- "A PCE may return a delegation to the PCC in order to facilitate
re-delegation of its LSPs to an alternate PCE."
  In this context (protocol operation), a MAY seems appropriate.

Section 4.1:
-  In draft-ietf-pce-stateful-sync-optimizations-01, the U is referenced in
the list of flags. draft-ietf-pce-pce-initiated-lsp-02 could use the same
format.


Section 5

 - The section is a mix of object definition and procedures, the procedures
could be more clearly marked (having separate object format and procedure
section, or changing the section titles)

Section 5.1.

 - The error procedure refers to I-D.ietf-pce-stateful-pce for a message
defined in this document, I-D.ietf-pce-stateful-pce should not define error
procedure for unknown message.
   I believe you are refering to the error values
  OLD:
  "If either the SRP or the LSP object is missing, the PCC MUST send a
PCErr as described in [I-D.ietf-pce-stateful-pce]."

  NEW:
  "If either the SRP or the LSP object is missing, the PCC MUST send a
PCErr with error-type 6 (Mandatory Object missing) and error-value=3D10 (SR=
P
Object missing), respectively error-value=3D8 (LSP Object missing). Those
errors are defined defined in [I-D.ietf-pce-stateful-pce]."

 - Section 3.2 has a more strict definition of the message content, that
matches the RBNF, namely including the ERO and ENDPOINTS objects,
   the text of section 3.2 sould be moved to this section (the overview
being more detailed than the definition), but its also repeated in section
5.3., maybe better to reference section 5.3 or have section 5.3 be a
"procedures" subsection

Section 5.2.

 - "The type object is defined in [I-D.ietf-pce-stateful-pce]."
  This sentence could be removed


Section 5.3

- OLD: "The LSP is set up using RSVP-TE, extensions for other setup methods
are outside the scope of this draft."
  NEW: "The LSP is assumed to be set up using RSVP-TE, extensions for other
setup methods are outside the scope of this draft."

- OLD: "The END-POINTS Object is mandatory for an instantiation request of
an RSVP-signaled LSP."
  NEW: "The END-POINTS Object is mandatory for an instantiation request."

 Regardless of RSVP or other protocol, the END-POINTS is required on a lot
of PCEP messages, so if new signaling protocols does not require the
END-POINTS, its better to leave the new definition that will affect other
PCEP messages to that document.

 - Error code 6 (Object missing) for a missing TLV seems confusing, its
more a malformed object content (as the TLV is part of the object), the TLV
missing error should be reparented to error-type=3D10 (Reception of an
invalid object)
 - "If there is conflict with
   the LSP name, the PCC MUST send a PCErr message with Error-type=3D23
   (Bad Parameter value) and Error-value=3D1 (SYMBOLIC-PATH-NAME in use).
   The only exception to this rule is for LSPs for which the State
   timeout timer is running (see Section 6)."
 I am unsure the exception is a good mechanism, this is detailed further in
the comment for section 6.


 - "LSPs that were instantiated as a result of a PCInitiate message MUST
have the C flag set in the LSP object."
  C flag is not yet defined, please add reference to the section or has
Object extensions then procedures

 - "If the PCC determines that the LSP parameters proposed in the
PCInitiate message are unacceptable, it MUST trigger a PCErr with
   error-type=3DTBD (PCE instantiation error) and error-value=3D1 (Unaccept=
able
instantiation parameters)."

  This procedure is cleaner and offers more possibility for the PCE to know
which parameter was wrong, base draft should use the same

 - "A PCC MUST relay to the PCE errors it encounters in the..."
  This imply that the PCC SHOULD wait for the LSP to be signaled before
reporting the LSP State,  I would suggest the following text:

 "The PCC SHOULD respond to the PCInitiate message when the LSP has been
signaled. On succesful completion ... (Last paragraph).
  On unsucessfull completion a PCC MUST relay ..."

 - on PCInitiate , the Symbolic Path Name TLV is mandatory, the LSP
Identifiers TLVs may be present unless specified (I do not see any
drawback/limitation, behavior is the same as mplsTunnelIndex)
   is this correct?
 - Are the LSP Error Code TLV and  RSVP Error Spec TLV accepted, rejected
or ignored?
 - Section 5.3.1 indicated a new optional TLV (SPEAKER-IDENTITY-ID), maybe
a TLV presence rules section could be usefull, its now distributed over
different sections and levels.


Section 5.3.1.

 - Is there any specific reason to have the flag defined as a subsection of
the instantiation procedure rather than a separate section as the R flag?
 - Nits : draft-ietf-pce-stateful-pce-10 define Flag, the document defines
Flags, name should be aligned

 - "If the TLV appears for an LSP for which the C flag is 0,
   the TLV MUST be ignored the PCC MUST send a PCErr message with Error-
   type 23 ("Bad parameter value") and error value 2 ("Speaker identity
   included for an LSP that is not PCE-initiated")."

 To ease procedure,  why not allow it? this can be set to the PCC
SPEAKER-IDENTITY-ID for that matter, or simply ignored, it can be up to the
PCE. Why is the error necessary here?

Section 5.4:

 - OLD: "If the PLSP-ID specified in the PCInitiate message was not created
by the PCE, the PCC MUST send a PCErr message indicating "LSP is not PCE
initiated" (Error code 19,
   error value TBD)."
 - NEW: "If the PLSP-ID specified in the PCInitiate message was not created
by a PCE, the PCC MUST send a PCErr message indicating "LSP is not PCE
initiated" (Error code 19,
   error value TBD)."
 (In case of multiple PCEs)

 - TLV presence rules are missing:
  - is symbolic path name, lsp identifiers, ..etc  allowed or ignored?
  - does it make sense to allow the SPEAKER-IDENTITY TLV for debugging
purpose in the subsequent PCRpt ?

Section 6:
 - For the delegation bit, adding "to the PCE the LSP is delegated to"
would make the text more clear

 - What does contains the PCErr message of type 19 (Invalid Operation) and
value TBD "Delegation for PCE-initiated LSP cannot be revoked"?
   I believe it should at least contains the LSP object.

 - 'A PCE MAY return a delegation to the PCC, to allow for LSP transfer
   between PCEs.  Doing so MUST trigger the State Timeout Interval timer
   ([I-D.ietf-pce-stateful-pce]).'

   the state timeout interval is defined as "time period before flushing
LSP state associated
      with that PCEP session" (in case of session closed)
   In the context of a PCE returning the delegation, the State Timeout
interval should only apply to the LSP, not the the state associated to the
session. This should be stated

 - "To  obtain control of a PCE-initiated LSP, a PCE (either the original
or one of its backups) sends a PCInitiate message, ..."
   It feels a bit of a patch, I believe the PCC can redelegate the LSP to
the "original" PCE or to the "preferred" PCE by itself (Policies and
SPEAKER-IDENTITY-ID would allow for that), rather than adding an exception
(who wins in case the timeout is long and several PCEs connect at the same
time, for say a network failure?)

Section 8.

- Missing the new bit definition of Section 4.1. Stateful PCE Capability
TLV (according to draft-ietf-pce-stateful-pce-10, section 8.6.)
   I : bit  29
- Missing the new bit definition of Section 5.2. The R flag in the SRP
Object - The bit number should be defined (bit 31), should a new registry
be defined at this point?

Section 8.3
 - As described before, error-type=3D23, error-value=3D2 is not needed
 - Error-type=3D24, error-value=3D3 : OLD: "RSVP signaling error" , NEW:
"signaling error" The type of error is included in the TLV, Restricting the
error to RSVP is too stong.

Section 9.1:
 "Rapid flaps triggered by the PCE can also be an attack vector.  This will
be discussed in a future version of this document."
 Its rather time to document them

 The exception mechanism also introduce another attack (restart the session
and steal LSPs)

 Was the END-POINTS under PCE control considered? This would allow a
malicious PCE to strain other AS/domains.



On 22 December 2014 at 05:59, BELOTTI, SERGIO (SERGIO) <
sergio.belotti@alcatel-lucent.com> wrote:

>  Hi Druhv,
>
> as I pointed out in mail,
>
> in section 3.2 , when you talked about R flad in SRP, the fleg is new and
> is introduced in the following chapter.
>
> For me text should be:
>
> (2) In sec 3.2,
>
> OLD:
>
> To indicate a delete operation, the PCE MUST use the R flag in the SRP
> object in a PCUpd message.
>
> NEW:
>
> To indicate a delete operation, a new R flag is introduced in the SRP
> object and to be used in a PCInitiate message.
>
>
>
> Thanks
>
>
>
> Sergio
>
>
>
>
>
>
>
> -----Original Message-----
> From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Dhruv Dhody
> Sent: luned=C3=AC 22 dicembre 2014 11:44
> To: julien.meuric@orange.com; pce@ietf.org
> Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 an=
d
> draft-ietf-pce-stateful-sync-optimizations-01
>
>
>
> Hi All,
>
>
>
> > As planned, this message ignites a 3-week WG Last Call on both
>
> > draft-ietf-pce-pce-initiated-lsp-02
>
>
>
> Support with following comments:
>
>
>
> (1) We should align the tone of the draft to
> http://tools.ietf.org/html/rfc7399#section-20 which differentiates
> between the recommendation for instantiation (this draft), and the actual
> (NMS like) instantiation of the LSPs (marked out of scope). This could
> either be done by a suitable text in Introduction and/or use of phrase
> 'recommend instantiation' in the document.
>
>
>
> (2) In sec 3.2,
>
> OLD:
>
> To indicate a delete operation, the PCE MUST use the R flag in the SRP
> object in a PCUpd message.
>
> NEW:
>
> To indicate a delete operation, the PCE MUST use the R flag in the SRP
> object in a PCInitiate message.
>
>
>
> I guess Ramon pointed this out already!
>
>
>
> (3) In sec 5.3.1, we are changing the meaning of the SPEAKER-IDENTITY-ID
> TLV, which was earlier used in OPEN to identify the exact PCEP-Speaker bu=
t
> now here it identifies the PCE that initiated the LSP. This looks like a
> hack, a better idea would be to define a new TLV type
> PCE-INITIATED-IDENTITY-ID with the same format.
>
>
>
> (4) Section 9.1, it says...
>
> Rapid flaps triggered by the PCE can also be an attack vector.  This will
> be discussed in a future version of this document.
>
>
>
> The text for this needs to be added.
>
>
>
> (5) It would be nice to have a manageability consideration section.
>
>
>
> (6) Few lines on state synchronization should also be added -  If the DB
> did not survive the PCC restart, PCE must send the PCE initiated message
> again. During state synchronization the PCE should get the status of PCE
> Initiated LSPs with C flag set in the LSP object. Incase of redelegation =
to
> a different PCE the same should be reported during state synchnronization
> with D=3D0. The original PCE should also be allowed to send PCInitiate to=
 get
> back the delegation. (this is not allowed in the current text as PCInitia=
te
> with non-zero PLSP-ID is allowed only during State Timeout timer)
>
>
>
> Nits
>
> - Reference to 2119, as SHOULD, MUST are used in the document
>
> - Expand on first use LER, LSR etc
>
> - Reference to SRP, LSP, PLSP-ID as defined in [I-D.ietf-pce-stateful-pce=
]
>
> - section 3.2 s/PCinitiate/PCInitiate/
>
> - section 4 s/A PCC indicates its ability.../A PCEP speaker indicates its
> ability/ (because both PCC and PCE needs to do this)
>
> - section 4.1 Type=3D16 should be removed as its TBD in the base document=
 as
> well
> http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-10#section-7.1.1
>
> - section 4.1
>
> OLD:
>
> If set to 1 by a PCE, the I flag indicates that the PCE will attempt to
> instantiate LSPs.
>
> NEW:
>
> If set to 1 by a PCE, the I flag indicates that the PCE can attempt to
> instantiate LSPs.
>
>
>
>
>
> > and draft-ietf-pce-stateful-sync-
>
> > optimizations-01.
>
>
>
> Support (As a co-author)
>
>
>
> Regards,
>
> Dhruv
>
>
>
> > It will end on Monday December 22 at 11:59 PM, HST.
>
> >
>
> > Please send your comments to the PCE mailing list.
>
> >
>
> > Thanks,
>
> >
>
> > JP & Julien
>
> >
>
> >
>
> > _____________________________________________________________________
>
> > ____________________________________________________
>
> >
>
> > Ce message et ses pieces jointes peuvent contenir des informations
>
> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>
> > exploites ou copies sans autorisation. Si vous avez recu ce message
>
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
>
> > que les pieces jointes. Les messages electroniques etant susceptibles
>
> > d'alteration, Orange decline toute responsabilite si ce message a ete
>
> > altere, deforme ou falsifie. Merci.
>
> >
>
> > This message and its attachments may contain confidential or
>
> > privileged information that may be protected by law; they should not
>
> > be distributed, used or copied without authorisation.
>
> > If you have received this email in error, please notify the sender and
>
> > delete this message and its attachments.
>
> > As emails may be altered, Orange is not liable for messages that have
>
> > been modified, changed or falsified.
>
> > Thank you.
>
> >
>
> > _______________________________________________
>
> > 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
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
>

--089e013d0f8479ebbb050ad0a987
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi, 

I have the following comments on draft-ietf-pc=
e-pce-initiated-lsp-02:
Some comments require non minor changes (securit=
y section). I think the document should progress, but I am not sure its ful=
ly ready for LC.

Section 3.2. "Operation overview"

=
- "A PCE may return a delegation to the PCC in order to facilitate re-=
delegation of its LSPs to an alternate PCE."
=C2=A0 In this context=
 (protocol operation), a MAY seems appropriate.

Section 4.1:
-=C2=
=A0 In draft-ietf-pce-stateful-sync-optimizations-01, the U is referenced i=
n the list of flags. draft-ietf-pce-pce-initiated-lsp-02 could use the same=
 format.


Section 5

=C2=A0- The section is a mix of object=
 definition and procedures, the procedures could be more clearly marked (ha=
ving separate object format and procedure section, or changing the section =
titles) 

Section 5.1.
=C2=A0
=C2=A0- The error procedure refer=
s to I-D.ietf-pce-stateful-pce for a message defined in this document, I-D.=
ietf-pce-stateful-pce should not define error procedure for unknown message=
.
=C2=A0=C2=A0 I believe you are refering to the error values
=C2=A0 =
OLD:
=C2=A0 "If either the SRP or the LSP object is missing, the PC=
C MUST send a PCErr as described in [I-D.ietf-pce-stateful-pce]."
<=
br>=C2=A0 NEW:
=C2=A0 "If either the SRP or the LSP object is missi=
ng, the PCC MUST send a PCErr with error-type 6 (Mandatory Object missing) =
and error-value=3D10 (SRP Object missing), respectively error-value=3D8 (LS=
P Object missing). Those errors are defined defined in [I-D.ietf-pce-statef=
ul-pce]."

=C2=A0- Section 3.2 has a more strict definition of t=
he message content, that matches the RBNF, namely including the ERO and END=
POINTS objects,
=C2=A0=C2=A0 the text of section 3.2 sould be moved to t=
his section (the overview being more detailed than the definition), but its=
 also repeated in section 5.3., maybe better to reference section 5.3 or ha=
ve section 5.3 be a "procedures" subsection 

Section 5.2.<=
br>=C2=A0
=C2=A0- "The type object is defined in [I-D.ietf-pce-stat=
eful-pce]."
=C2=A0 This sentence could be removed
=C2=A0 
Section 5.3

- OLD: "The LSP is set up using RSVP-TE, extension=
s for other setup methods are outside the scope of this draft."
=C2=
=A0 NEW: "The LSP is assumed to be set up using RSVP-TE, extensions fo=
r other setup methods are outside the scope of this draft."
=C2=A0 =

- OLD: "The END-POINTS Object is mandatory for an instantiation re=
quest of an RSVP-signaled LSP."
=C2=A0 NEW: "The END-POINTS Ob=
ject is mandatory for an instantiation request."
=C2=A0
=C2=A0Re=
gardless of RSVP or other protocol, the END-POINTS is required on a lot of =
PCEP messages, so if new signaling protocols does not require the END-POINT=
S, its better to leave the new definition that will affect other PCEP messa=
ges to that document.

=C2=A0- Error code 6 (Object missing) for a mi=
ssing TLV seems confusing, its more a malformed object content (as the TLV =
is part of the object), the TLV missing error should be reparented to error=
-type=3D10 (Reception of an invalid object) 
=C2=A0- "If there is c=
onflict with
=C2=A0=C2=A0 the LSP name, the PCC MUST send a PCErr messag=
e with Error-type=3D23
=C2=A0=C2=A0 (Bad Parameter value) and Error-valu=
e=3D1 (SYMBOLIC-PATH-NAME in use).
=C2=A0=C2=A0 The only exception to th=
is rule is for LSPs for which the State
=C2=A0=C2=A0 timeout timer is ru=
nning (see Section 6)."
=C2=A0I am unsure the exception is a good m=
echanism, this is detailed further in the comment for section 6.
=C2=A0 =


=C2=A0- "LSPs that were instantiated as a result of a PCInitia=
te message MUST have the C flag set in the LSP object."
=C2=A0 C fl=
ag is not yet defined, please add reference to the section or has Object ex=
tensions then procedures

=C2=A0- "If the PCC determines that th=
e LSP parameters proposed in the PCInitiate message are unacceptable, it MU=
ST trigger a PCErr with
=C2=A0=C2=A0 error-type=3DTBD (PCE instantiation=
 error) and error-value=3D1 (Unacceptable instantiation parameters)."<=
br>
=C2=A0 This procedure is cleaner and offers more possibility for the=
 PCE to know which parameter was wrong, base draft should use the same 
=

=C2=A0- "A PCC MUST relay to the PCE errors it encounters in the..=
."
=C2=A0 This imply that the PCC SHOULD wait for the LSP to be sig=
naled before reporting the LSP State,=C2=A0 I would suggest the following t=
ext:

=C2=A0"The PCC SHOULD respond to the PCInitiate message wh=
en the LSP has been signaled. On succesful completion ... (Last paragraph).=

=C2=A0 On unsucessfull completion a PCC MUST relay ..." 

=
=C2=A0- on PCInitiate , the Symbolic Path Name TLV is mandatory, the LSP Id=
entifiers TLVs may be present unless specified (I do not see any drawback/l=
imitation, behavior is the same as mplsTunnelIndex) 
=C2=A0=C2=A0 is thi=
s correct?
=C2=A0- Are the LSP Error Code TLV and=C2=A0 RSVP Error Spec =
TLV accepted, rejected or ignored? 
=C2=A0- Section 5.3.1 indicated a ne=
w optional TLV (SPEAKER-IDENTITY-ID), maybe a TLV presence rules section co=
uld be usefull, its now distributed over different sections and levels.
=
=C2=A0

Section 5.3.1.

=C2=A0- Is there any specific reason to=
 have the flag defined as a subsection of the instantiation procedure rathe=
r than a separate section as the R flag?
=C2=A0- Nits : draft-ietf-pce-s=
tateful-pce-10 define Flag, the document defines Flags, name should be alig=
ned

=C2=A0- "If the TLV appears for an LSP for which the C flag=
 is 0,
=C2=A0=C2=A0 the TLV MUST be ignored the PCC MUST send a PCErr me=
ssage with Error-
=C2=A0=C2=A0 type 23 ("Bad parameter value")=
 and error value 2 ("Speaker identity
=C2=A0=C2=A0 included for an =
LSP that is not PCE-initiated")."
=C2=A0
=C2=A0To ease proc=
edure,=C2=A0 why not allow it? this can be set to the PCC SPEAKER-IDENTITY-=
ID for that matter, or simply ignored, it can be up to the PCE. Why is the =
error necessary here?

Section 5.4:

=C2=A0- OLD: "If the =
PLSP-ID specified in the PCInitiate message was not created by the PCE, the=
 PCC MUST send a PCErr message indicating "LSP is not PCE initiated&qu=
ot; (Error code 19,
=C2=A0=C2=A0 error value TBD)."
=C2=A0- NEW:=
 "If the PLSP-ID specified in the PCInitiate message was not created b=
y a PCE, the PCC MUST send a PCErr message indicating "LSP is not PCE =
initiated" (Error code 19,
=C2=A0=C2=A0 error value TBD)."
=
=C2=A0(In case of multiple PCEs)

=C2=A0- TLV presence rules are miss=
ing:
=C2=A0 - is symbolic path name, lsp identifiers, ..etc=C2=A0 allowe=
d or ignored?
=C2=A0 - does it make sense to allow the SPEAKER-IDENTITY =
TLV for debugging purpose in the subsequent PCRpt ? 
=C2=A0 
Section =
6:
=C2=A0- For the delegation bit, adding "to the PCE the LSP is de=
legated to" would make the text more clear 

=C2=A0- What does c=
ontains the PCErr message of type 19 (Invalid Operation) and value TBD &quo=
t;Delegation for PCE-initiated LSP cannot be revoked"? =C2=A0=C2=A0=C2=
=A0 
=C2=A0=C2=A0 I believe it should at least contains the LSP object.<=
br>
=C2=A0- 'A PCE MAY return a delegation to the PCC, to allow for =
LSP transfer
=C2=A0=C2=A0 between PCEs.=C2=A0 Doing so MUST trigger the =
State Timeout Interval timer
=C2=A0=C2=A0 ([I-D.ietf-pce-stateful-pce]).=
'
=C2=A0=C2=A0 
=C2=A0=C2=A0 the state timeout interval is define=
d as "time period before flushing LSP state associated
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 with that PCEP session" (in case of session closed)=

=C2=A0=C2=A0 In the context of a PCE returning the delegation, the Stat=
e Timeout interval should only apply to the LSP, not the the state associat=
ed to the session. This should be stated

=C2=A0- "To=C2=A0 obta=
in control of a PCE-initiated LSP, a PCE (either the original or one of its=
 backups) sends a PCInitiate message, ..."
=C2=A0=C2=A0 It feels a =
bit of a patch, I believe the PCC can redelegate the LSP to the "origi=
nal" PCE or to the "preferred" PCE by itself (Policies and S=
PEAKER-IDENTITY-ID would allow for that), rather than adding an exception (=
who wins in case the timeout is long and several PCEs connect at the same t=
ime, for say a network failure?)

Section 8.

- Missing the new=
 bit definition of Section 4.1. Stateful PCE Capability TLV (according to d=
raft-ietf-pce-stateful-pce-10, section 8.6.)
=C2=A0=C2=A0 I : bit=C2=A0 =
29 
- Missing the new bit definition of Section 5.2. The R flag in the S=
RP Object - The bit number should be defined (bit 31), should a new registr=
y be defined at this point? 

Section 8.3 
=C2=A0- As described be=
fore, error-type=3D23, error-value=3D2 is not needed
=C2=A0- Error-type=
=3D24, error-value=3D3 : OLD: "RSVP signaling error" , NEW: "=
;signaling error" The type of error is included in the TLV, Restrictin=
g the error to RSVP is too stong.

Section 9.1:
=C2=A0"Rapid =
flaps triggered by the PCE can also be an attack vector.=C2=A0 This will be=
 discussed in a future version of this document."
=C2=A0Its rather =
time to document them

=C2=A0The exception mechanism also introduce a=
nother attack (restart the session and steal LSPs) 

=C2=A0Was the EN=
D-POINTS under PCE control considered? This would allow a malicious PCE to =
strain other AS/domains.



On 22 December 2014 at 05:59, BELOTTI, SERGIO (SER=
GIO) <sergio.belotti@alcatel-lucent.com> wro=
te:











Hi Druhv,


as I pointed out in mail, 


in section 3.2 , when you talked about R flad in SR=
P, the fleg is new and is introduced in the following chapter.


For me text should be:


(2) In sec 3.2,


OLD:


To indicate a delete operation, the PCE MUST use th=
e R flag in the SRP object in a PCUpd message.


NEW:


To indicate a delete operation, 
a new R flag is introduced in the SRP object and to be used in a PCInitiate=
 message.


=C2=A0


Thanks


=C2=A0


Sergio


=C2=A0


=C2=A0


=C2=A0


-----Original Message-----

From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Dhruv Dhody

Sent: luned=C3=AC 22 dicembre 2014 11:44

To: julien.me=
uric@orange.com; pce@=
ietf.org

Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and =
draft-ietf-pce-stateful-sync-optimizations-01


=C2=A0


Hi All, 


=C2=A0


> As planned, this message ignites a 3-week WG Last Call on both


> draft-ietf-pce-pce-initiated-lsp-02


=C2=A0


Support with following comments: 


=C2=A0


(1) We should align the tone of the draft to 
http://tools.ietf.org=
/html/rfc7399#section-20 which differentiates between the recomm=
endation for instantiation (this draft), and the actual (NMS like) instanti=
ation of the LSPs (marked out of scope).
 This could either be done by a suitable text in Introduction and/or use of=
 phrase 'recommend instantiation' in the document.



=C2=A0


(2) In sec 3.2,


OLD:


To indicate a delete operation, the PCE MUST use the R flag in the SRP o=
bject in a PCUpd message.


NEW:


To indicate a delete operation, the PCE MUST use the R flag in the SRP o=
bject in a PCInitiate message.


=C2=A0


I guess Ramon pointed this out already! 


=C2=A0


(3) In sec 5.3.1, we are changing the meaning of the SPEAKER-IDENTITY-ID=
 TLV, which was earlier used in OPEN to identify the exact PCEP-Speaker but=
 now here it identifies the PCE that initiated the LSP. This looks like a h=
ack, a better
 idea would be to define a new TLV type PCE-INITIATED-IDENTITY-ID with the =
same format.



=C2=A0


(4) Section 9.1, it says...


Rapid flaps triggered by the PCE can also be an attack vector.=C2=A0 Thi=
s will be discussed in a future version of this document.


=C2=A0


The text for this needs to be added. 


=C2=A0


(5) It would be nice to have a manageability consideration section.



=C2=A0


(6) Few lines on state synchronization should also be added -=C2=A0 If t=
he DB did not survive the PCC restart, PCE must send the PCE initiated mess=
age again. During state synchronization the PCE should get the status of PC=
E Initiated LSPs
 with C flag set in the LSP object. Incase of redelegation to a different P=
CE the same should be reported during state synchnronization with D=3D0. Th=
e original PCE should also be allowed to send PCInitiate to get back the de=
legation. (this is not allowed in
 the current text as PCInitiate with non-zero PLSP-ID is allowed only durin=
g State Timeout timer)=C2=A0



=C2=A0


Nits


- Reference to 2119, as SHOULD, MUST are used in the document<=
/u>


- Expand on first use LER, LSR etc


- Reference to SRP, LSP, PLSP-ID as defined in [I-D.ietf-pce-stateful-pc=
e]


- section 3.2 s/PCinitiate/PCInitiate/


- section 4 s/A PCC indicates its ability.../A PCEP speaker indicates it=
s ability/ (because both PCC and PCE needs to do this)


- section 4.1 Type=3D16 should be removed as its TBD in the base documen=
t as well

http://tools.ietf.org=
/html/draft-ietf-pce-stateful-pce-10#section-7.1.1=



- section 4.1


OLD:


If set to 1 by a PCE, the I flag indicates that the PCE will attempt to =
instantiate LSPs.


NEW:


If set to 1 by a PCE, the I flag indicates that the PCE can attempt to i=
nstantiate LSPs.


=C2=A0


=C2=A0


> and draft-ietf-pce-stateful-sync-


> optimizations-01. 


=C2=A0


Support (As a co-author)


=C2=A0


Regards,


Dhruv


=C2=A0


> It will end on Monday December 22 at 11:59 PM, HST.

> 


> Please send your comments to the PCE mailing list.

> 


> Thanks,


> 


> JP & Julien


> 


> 


> ___________________________________________________________________=
__


> ____________________________________________________<=
/p>

> 


> Ce message et ses pieces jointes peuvent contenir des informations



> confidentielles ou privilegiees et ne doivent donc pas etre diffuse=
s,



> exploites ou copies sans autorisation. Si vous avez recu ce message



> par erreur, veuillez le signaler a l'expediteur et le detruire =
ainsi



> que les pieces jointes. Les messages electroniques etant susceptibl=
es



> d'alteration, Orange decline toute responsabilite si ce message=
 a ete



> altere, deforme ou falsifie. Merci.


> 


> This message and its attachments may contain confidential or



> privileged information that may be protected by law; they should no=
t



> be distributed, used or copied without authorisation.=



> If you have received this email in error, please notify the sender =
and



> delete this message and its attachments.


> As emails may be altered, Orange is not liable for messages that ha=
ve



> been modified, changed or falsified.


> Thank you.


> 


> _______________________________________________


> Pce mailing list


> Pce@ietf.org<=
/p>

> https://www.ietf=
.org/mailman/listinfo/pce


=C2=A0


_______________________________________________


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





--089e013d0f8479ebbb050ad0a987--


From nobody Mon Dec 22 09:18:49 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 46AB61A1B6E for ; Mon, 22 Dec 2014 09:18:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 Vnq2PU4brK63 for ; Mon, 22 Dec 2014 09:18:32 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8558C1A1B48 for ; Mon, 22 Dec 2014 09:18:18 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQI94038; Mon, 22 Dec 2014 17:18:17 +0000 (GMT)
Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 22 Dec 2014 17:18:16 +0000
Received: from BLREML504-MBX.china.huawei.com ([169.254.1.96]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0158.001; Mon, 22 Dec 2014 22:48:13 +0530
From: Dhruv Dhody 
To: Robert Varga , "julien.meuric@orange.com" , "pce@ietf.org" 
Thread-Topic: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01
Thread-Index: AQHQDYrNBgKkLU6uSkm3AuIgHaEXSJyVKxuAgAZUNUD///t1AIAAfxaw
Date: Mon, 22 Dec 2014 17:18:13 +0000
Message-ID: <23CE718903A838468A8B325B80962F9B8700DA7E@blreml504-mbx.china.huawei.com>
References: <12631_1417454286_547CA2CE_12631_12333_1_547CA2CA.1050804@orange.com> <5492E86B.9080200@hq.sk> <23CE718903A838468A8B325B80962F9B8700D7BB@blreml504-mbx.china.huawei.com> <549833BC.1020203@hq.sk>
In-Reply-To: <549833BC.1020203@hq.sk>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.195.42.47]
Content-Type: multipart/alternative; boundary="_000_23CE718903A838468A8B325B80962F9B8700DA7Eblreml504mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/pce/Yrr-ojmp-w6FupDpAjGyC-Lmugc
Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01
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, 22 Dec 2014 17:18:39 -0000

--_000_23CE718903A838468A8B325B80962F9B8700DA7Eblreml504mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Robert,

(snip)



Hello,



donning the implementer (as opposed to co-author) hat, I have

comments pertaining to draft-ietf-pce-pce-initiated-lsp, specifically

to Section 6. In general it seems to contradict the general outline

of the extension as stated in section 3.2 paragraph 4.



The first paragraph clearly forbids the use of PCRpt D=3D0 for PCE-

initiated LSPs. It is not clear whether this restriction applies to

all PCRpts, or only the PCRpt solicited by the PCInitiate message.

Section 3.2 paragraph 4 seems to indicate this applies to solicited

PCRpts only, which is what makes sense. A clarification is definitely

needed.





But http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-10#section-5.5.1=
 says..



Note that for an LSP to remain delegated to a PCE, the PCC MUST set

the Delegate flag to 1 on each LSP Status Report sent to the PCE.



So the D flag must be set on all PCRpts (including the solicited (first) PC=
Rpt and any other PCRpt message).

Right, but that would also mean that a PCE-initiated LSP cannot be reported=
 to backup PCEs, as that would mean the LSP is delegated to multiple PCEs a=
t the same time...

[Dhruv]: A clarification that one is referring to the PCE that initiated th=
e LSP in the paragraph should clear that up.



I am not sure what text in section 3.2 paragraph 4 is an issue?

The specific text is this:

   Once instantiated, the delegation procedures for PCE-initiated LSPs

   are the same as for PCC initiated LSPs as described in

   [I-D.ietf-pce-stateful-pce].  This applies to the ca=
se of a PCE

   failure as well.
Which is precisely what I understand you are implying in your response belo=
w.

[Dhruv]:




The third paragraph seems to be replacing the normal delegation

mechanics with a PCInitiate-driven exchange. It does not specify

whether it is legal for a PCE to send PCUpd(D=3D1) after a session flap

or not. It feels like it is not legal and PCInitiate is intended to

fully replace it, but that would contradict section 3.2 paragraph 4.

This needs to be clarified.



I think some clarification is needed. The text says..



In case of PCEP session failure, control over PCE-initiated LSPs

reverts to the PCC at the expiration of the redelegation timeout.  To

obtain control of a PCE-initiated LSP, a PCE (either the original or

one of its backups) sends a PCInitiate message, including just the

SRP and LSP objects, and carrying the PLSP-ID of the LSP it wants to

take control of.



During state synchronization itself (full or incremental) the D flag could =
be set while reporting the status of PCE-Initiated LSP (with C flag set) if=
 re-delegation is not done to another PCE. I feel the same behavior make se=
nse for PCC-Initiated LSP as well incase one wants to delegate to the same =
PCE again after session down. It should not be mandatory to send PCInitiage=
 message in all cases.



Regards,

Dhruv

Bye,
Robert







My preference would be to remove pretty much all of this paragraph,

bringing the mechanics to what section 3.2 outlines. Unfortunately

there are already some implementations deployed, so we need to factor

in the compatiblity with the installed base. Can we perhaps allocate

another bit in the Stateful PCE Capability TLV and mark the current

one as reserved/deprecated?



Thanks,

Robert



On 12/01/2014 06:18 PM, julien.meuric@orange.com wrote:

Dear all,



As planned, this message ignites a 3-week WG Last Call on both

draft-ietf-pce-pce-initiated-lsp-02 and

draft-ietf-pce-stateful-sync-optimizations-01. It will end on

Monday

December 22 at 11:59 PM, HST.



Please send your comments to the PCE mailing list.



Thanks,



JP & Julien







_____________________________________________________________________

_

___________________________________________________





Ce message et ses pieces jointes peuvent contenir des informations

confidentielles ou privilegiees et ne doivent donc pas etre

diffuses,

exploites ou copies sans autorisation. Si vous avez recu ce message

par erreur, veuillez le signaler a l'expediteur et le detruire

ainsi

que les pieces jointes. Les messages electroniques etant

susceptibles

d'alteration, Orange decline toute responsabilite si ce message a

ete

altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or

privileged information that may be protected by law; they should

not

be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender

and

delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that

have

been modified, changed or falsified.

Thank you.



_______________________________________________

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


--_000_23CE718903A838468A8B325B80962F9B8700DA7Eblreml504mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Robert,



 <=
/p>

(snip)<=
/p>





 


Hello,


 


donning the implementer (as opposed to co-author) hat, I have


comments pertaining to draft-ietf-pce-pce-initiated-lsp, specifically<=
o:p>


to Section 6. In general it seems to contradict the general outline


of the extension as stated in section 3.2 paragraph 4.

 


The first paragraph clearly forbids the use of PCRpt D=3D0 for PCE-


initiated LSPs. It is not clear whether this restriction applies to


all PCRpts, or only the PCRpt solicited by the PCInitiate message.


Section 3.2 paragraph 4 seems to indicate this applies to solicited


PCRpts only, which is what makes sense. A clarification is definitely<=
o:p>


needed.




 


 


But http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-10=
#section-5.5.1 says.. 


 


Note that for an LSP to remain delegated to a PCE, the PCC MUST set


the Delegate flag to 1 on each LSP Status Report sent to the PCE.=



 


So the D flag must be set on all PCRpts (including the solicited (firs=
t) PCRpt and any other PCRpt message).




Right, but that would also mean that a PCE-initiated LSP cannot be reported=
 to backup PCEs, as that would mean the LSP is delegated to multiple PCEs a=
t the same time...


 <=
/p>

[Dhruv]: A clarification =
that one is referring to the PCE that initiated the LSP in the paragraph sh=
ould clear that up.  


 


I am not sure what text in section 3.2 paragraph 4 is an issue? <=
/o:p>




The specific text is this:


   Once instantiated, the delegation procedures for PCE-init=
iated LSPs


   are the same as for PCC initiated LSPs as described in


   [I-D.i=
etf-pce-stateful-pce].  This applies to the case of a PCE


   failure as well.


Which is precisely what I understand you are implyin=
g in your response below.



[Dhruv]: 








 


The third paragraph seems to be replacing the normal delegation


mechanics with a PCInitiate-driven exchange. It does not specify<=
/o:p>


whether it is legal for a PCE to send PCUpd(D=3D1) after a session fla=
p


or not. It feels like it is not legal and PCInitiate is intended to


fully replace it, but that would contradict section 3.2 paragraph 4.


This needs to be clarified.




 


I think some clarification is needed. The text says..


 


In case of PCEP session failure, control over PCE-initiated LSPs<=
/o:p>


reverts to the PCC at the expiration of the redelegation timeout. =
; To


obtain control of a PCE-initiated LSP, a PCE (either the original or


one of its backups) sends a PCInitiate message, including just the


SRP and LSP objects, and carrying the PLSP-ID of the LSP it wants to


take control of.


 


During state synchronization itself (full or incremental) the D flag c=
ould be set while reporting the status of PCE-Initiated LSP (with C flag se=
t) if re-delegation is not done to another PCE. I feel the same behavior ma=
ke sense for PCC-Initiated LSP as well incase one wants to delegate to the =
same PCE again after session down. It should not be mandatory to send PCIni=
tiage message in all cases. 


 


Regards,


Dhruv




Bye,

Robert








 




 


My preference would be to remove pretty much all of this paragraph,


bringing the mechanics to what section 3.2 outlines. Unfortunately


there are already some implementations deployed, so we need to factor<=
o:p>


in the compatiblity with the installed base. Can we perhaps allocate


another bit in the Stateful PCE Capability TLV and mark the current


one as reserved/deprecated?


 


Thanks,


Robert


 


On 12/01/2014 06:18 PM, ju=
lien.meuric@orange.com wrote:




Dear all,


 


As planned, this message ignites a 3-week WG Last Call on both


draft-ietf-pce-pce-initiated-lsp-02 and


draft-ietf-pce-stateful-sync-optimizations-01. It will end on




Monday




December 22 at 11:59 PM, HST.


 


Please send your comments to the PCE mailing list.


 


Thanks,


 


JP & Julien


 


 


 




_____________________________________________________________________<=
o:p>


_




___________________________________________________


 


 


Ce message et ses pieces jointes peuvent contenir des informations


confidentielles ou privilegiees et ne doivent donc pas etre=





diffuses,




exploites ou copies sans autorisation. Si vous avez recu ce message


par erreur, veuillez le signaler a l'expediteur et le detruire




ainsi




que les pieces jointes. Les messages electroniques etant



susceptibles




d'alteration, Orange decline toute responsabilite si ce message a=





ete




altere, deforme ou falsifie. Merci.


 


This message and its attachments may contain confidential or


privileged information that may be protected by law; they should<=
/o:p>




not




be distributed, used or copied without authorisation.


If you have received this email in error, please notify the sender




and




delete this message and its attachments.


As emails may be altered, Orange is not liable for messages that<=
/o:p>




have




been modified, changed or falsified.


Thank you.


 


_______________________________________________


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




 








--_000_23CE718903A838468A8B325B80962F9B8700DA7Eblreml504mbxchi_--


From nobody Mon Dec 22 09:24:12 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 F09A81A1B64 for ; Mon, 22 Dec 2014 09:24:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 k0qeBuwlOIV8 for ; Mon, 22 Dec 2014 09:24:08 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 049C51A1B72 for ; Mon, 22 Dec 2014 09:24:07 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQI94430; Mon, 22 Dec 2014 17:24:06 +0000 (GMT)
Received: from BLREML405-HUB.china.huawei.com (10.20.4.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 22 Dec 2014 17:24:04 +0000
Received: from BLREML504-MBX.china.huawei.com ([169.254.1.96]) by BLREML405-HUB.china.huawei.com ([10.20.4.41]) with mapi id 14.03.0158.001; Mon, 22 Dec 2014 22:53:55 +0530
From: Dhruv Dhody 
To: Dhruv Dhody , Robert Varga , "julien.meuric@orange.com" , "pce@ietf.org" 
Thread-Topic: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01
Thread-Index: AQHQDYrNBgKkLU6uSkm3AuIgHaEXSJyVKxuAgAZUNUD///t1AIAAfxawgAAB40A=
Date: Mon, 22 Dec 2014 17:23:54 +0000
Message-ID: <23CE718903A838468A8B325B80962F9B8700DAB0@blreml504-mbx.china.huawei.com>
References: <12631_1417454286_547CA2CE_12631_12333_1_547CA2CA.1050804@orange.com> <5492E86B.9080200@hq.sk> <23CE718903A838468A8B325B80962F9B8700D7BB@blreml504-mbx.china.huawei.com> <549833BC.1020203@hq.sk> 
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.195.42.47]
Content-Type: multipart/alternative; boundary="_000_23CE718903A838468A8B325B80962F9B8700DAB0blreml504mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/pce/g8yIMOyx2Vx80SM3OuYDQty1bFU
Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01
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, 22 Dec 2014 17:24:11 -0000

--_000_23CE718903A838468A8B325B80962F9B8700DAB0blreml504mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hit sent by mistake while I was still typing my response, jumping directly =
to it inline...





I am not sure what text in section 3.2 paragraph 4 is an issue?

The specific text is this:

   Once instantiated, the delegation procedures for PCE-initiated LSPs

   are the same as for PCC initiated LSPs as described in

   [I-D.ietf-pce-stateful-pce].  This applies to the ca=
se of a PCE

   failure as well.
Which is precisely what I understand you are implying in your response belo=
w.

[Dhruv]: I guess the basic delegation procedure is same, but the difference=
 comes out in revoking of delegation, re-delegation etc, so I agree a bette=
r clarifying text is needed.


Regards,
Dhruv

--_000_23CE718903A838468A8B325B80962F9B8700DAB0blreml504mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hit sent by mistake while=
 I was still typing my response, jumping directly to it inline…



 <=
/p>





<snip>


 


I am not sure what text in section 3.2 paragraph 4 is an issue? <=
/o:p>




The specific text is this:


   Once instantiated, the delegation procedures for PCE-init=
iated LSPs


   are the same as for PCC initiated LSPs as described in


   [I-D.i=
etf-pce-stateful-pce].  This applies to the case of a PCE


   failure as well.


Which is precisely wh=
at I understand you are implying in your response below.



[Dhruv]: I guess the basic delegation procedure =
is same, but the difference comes out in revoking of delegation, re-delegat=
ion etc, so I agree a better clarifying text is needed.
  


<snip>


 <=
/p>

Regards,


Dhruv









--_000_23CE718903A838468A8B325B80962F9B8700DAB0blreml504mbxchi_--


From nobody Mon Dec 22 11:03:36 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 237CF1A6F3B for ; Mon, 22 Dec 2014 11:03:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id al20-CeCulkF for ; Mon, 22 Dec 2014 11:03:31 -0800 (PST)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45F5A1A6F39 for ; Mon, 22 Dec 2014 11:03:31 -0800 (PST)
Received: by mail-wi0-f181.google.com with SMTP id r20so8839516wiv.14 for ; Mon, 22 Dec 2014 11:03:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tl8uhiOjt8gWP075o2LEAGMho7jkQ8E3QuEty3bQDo4=; b=DRq0k0yNiIn4gnoEbTtj+/EuDVJ4Yw322JPNTVZVzAvdNnVqAxmm33RTiODqIATbIV 557V/T2PtFSwgRCddYx24/xowrtg8pNdrJ3nCjp7hUoSxLV8QNZ9YBQvXiUptvnLxjIW 8AqBaT0Tn2rfXCYU88VRJVTlDpGq3Id4gc0vodNDklHNq4Ca1dJMGMZI6E3YE+pKaz6s sGJ/dYN7P7PaWzqSUNTuhge8CNC4CSLfB5i/P7xkoGATYFmlvQYnrdo90Tn3eTxtprFA OseSF6bGH7O1xWCZdPKZI05E9THMT7QbL+YF1IEomj+DJB3nDIAspIHqiJ2yhRa/gC7X FRbQ==
MIME-Version: 1.0
X-Received: by 10.180.72.33 with SMTP id a1mr33676817wiv.18.1419275010064; Mon, 22 Dec 2014 11:03:30 -0800 (PST)
Received: by 10.27.89.133 with HTTP; Mon, 22 Dec 2014 11:03:29 -0800 (PST)
In-Reply-To: <12631_1417454286_547CA2CE_12631_12333_1_547CA2CA.1050804@orange.com>
References: <12631_1417454286_547CA2CE_12631_12333_1_547CA2CA.1050804@orange.com>
Date: Mon, 22 Dec 2014 14:03:29 -0500
Message-ID: 
From: Cyril Margaria 
To: Julien Meuric 
Content-Type: multipart/alternative; boundary=001a11c24cbcd04622050ad2b643
Archived-At: http://mailarchive.ietf.org/arch/msg/pce/AT3FPYkq__LNLgOidir33dXH2N4
Cc: "pce@ietf.org" 
Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01
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, 22 Dec 2014 19:03:34 -0000

--001a11c24cbcd04622050ad2b643
Content-Type: text/plain; charset=UTF-8

Hi,

I have the following comments on
draft-ietf-pce-stateful-sync-optimizations-01.


Section 3 :
  The documents proposes different optimizations, spending a paragraph or
two to describe the different optimizations, then a list of extensions, and
finish with procedures would help.

Section 3.2
 - A bit INCLUDE-DB-VERSION (IDB) is defined, section 7 defines the S bit.

Section 3.2.2
 - OLD: "The type of the TLV is [TBD] and it has a a variable length, which
         MUST be greater than 0 and padded to 4-octet alignment (, and
padding
         is not included in the Length field).
         "
   NEW: "The type of the TLV is [TBD] and it has a a variable length, which
         MUST be greater than 0. The Value is padded to 4-octet alignment.
The  padding
        is not included in the Length field"

   The value field is padded, not the lenght


Section 4.

-  Incremental is not allowed, because Paragraph 6 of section 3.2 indicates:
   "Otherwise, the PCC MUST perform state synchronization to the stateful
PCE."
   Section 3.2 should take into consideration all the bits defined, moving
the procedures after all the object definition would allow for an easier
understanding.
- proposes-> defines

Section 4.2.
  - Figure 7: I believe this is the D flag, not the T flag

Section 5.

The use case is different from section 6, but they use the same bit to
advertize that capability, so if T bit is set, the PCC MUST/SHOULD/MAY wait
the trigger from the PCE??


Section 6.2.
 - OLD: "The PCC MUST respond with a PCRpt message and SHOULD include the
SRP-ID-number of  the PCUpd that triggered the resynchronization."
   NEW: "The PCC MUST respond with a PCRpt message with the LSP state, SYNC
Flag set to 0 and MUST include the SRP-ID-number of  the PCUpd that
triggered the resynchronization."
    SHOULD -> MUST.
        draft-ietf-pce-stateful-pce-10, section 5.6.2 indicates that the
PCRpt MUST include the SRP id in the subsequent PCErr or PCRpt. I see no
justification in the text to change the mechanism described in
draft-ietf-pce-stateful-pce-10.
    The SYNC flag MUST be set to 0, otherwise it may be confused with a
full sync.

 - I believe all those updates are scoped only to the session that
triggered the delta/PCE triggered sync, adding it explicitly would be good,
as its a change in the PCRpt mechanism of the PCC.

- What happens if the PCE sends multiple resync requests while the a full
resync is in progress?


Section 7:

- This should under section 3.3. PCEP Extensions, and refer to the section
defining the bit behavior,
- D bit requires the S bit to be set, correct? A corresponding error is
missing
- The behavior of T bit is not clear, see comment of section 5.
- T bit and D&S bit combination : it seems the T bit behavior does not
depend on the INCLUDE-DB-VERSION and Delta, so it can be set independently.
This should be specified.


Manageability section is missing.

Section 8.3.
Suggested values are off, 29 is the suggested value of the I bit of
draft-ietf-pce-pce-initiated-lsp-02.
I believed this should be:

TBD(suggested value 27)  DELTA-LSP-SYNC-CAPABILITY   This document
TBD(suggested value 28)  TRIGGERED-SYNC              This document
TBD(suggested value 30)  INCLUDE-DB-VERSION          This document


Section 9.

 The document introduces new messages that may introduce load on the PCC, a
malicious PCE may flood the PCC with resync requests, this should be
mentioned.




On 1 December 2014 at 12:18,  wrote:

> Dear all,
>
> As planned, this message ignites a 3-week WG Last Call on both
> draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01.
> It will end on Monday December 22 at 11:59 PM, HST.
>
> Please send your comments to the PCE mailing list.
>
> Thanks,
>
> JP & Julien
>
>
> ____________________________________________________________
> _____________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>

--001a11c24cbcd04622050ad2b643
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

I have the following comments on draft-ietf-pce=
-stateful-sync-optimizations-01.


Section 3 : 
=C2=A0 The docu=
ments proposes different optimizations, spending a paragraph or two to desc=
ribe the different optimizations, then a list of extensions, and finish wit=
h procedures would help.

Section 3.2
=C2=A0- A bit INCLUDE-DB-VER=
SION (IDB) is defined, section 7 defines the S bit.

Section 3.2.2=C2=A0- OLD: "The type of the TLV is [TBD] and it has a a variable le=
ngth, which
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MUST be gre=
ater than 0 and padded to 4-octet alignment (, and padding
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is not included in the Length field).<=
br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "
=C2=A0=C2=A0 =
NEW: "The type of the TLV is [TBD] and it has a a variable length, whi=
ch
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MUST be greater than=
 0. The Value is padded to 4-octet alignment. The=C2=A0 padding
=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is not included in the Length field&qu=
ot;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 
=C2=A0=C2=A0 The valu=
e field is padded, not the lenght
=C2=A0

Section 4.

-=C2=
=A0 Incremental is not allowed, because Paragraph 6 of section 3.2 indicate=
s:
=C2=A0=C2=A0 "Otherwise, the PCC MUST perform state synchronizat=
ion to the stateful PCE."
=C2=A0=C2=A0 Section 3.2 should take into=
 consideration all the bits defined, moving the procedures after all the ob=
ject definition would allow for an easier understanding.
- proposes->=
 defines

Section 4.2.
=C2=A0 - Figure 7: I believe this is the D =
flag, not the T flag

Section 5.

The use case is different fro=
m section 6, but they use the same bit to advertize that capability, so if =
T bit is set, the PCC MUST/SHOULD/MAY wait the trigger from the PCE??
=C2=A0
Section 6.2.
=C2=A0- OLD: "The PCC MUST respond with a =
PCRpt message and SHOULD include the SRP-ID-number of=C2=A0 the PCUpd that =
triggered the resynchronization."
=C2=A0=C2=A0 NEW: "The PCC M=
UST respond with a PCRpt message with the LSP state, SYNC Flag set to 0 and=
 MUST include the SRP-ID-number of=C2=A0 the PCUpd that triggered the resyn=
chronization."
=C2=A0=C2=A0=C2=A0 SHOULD -> MUST.
=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-ietf-pce-stateful-pce-10, section 5=
.6.2 indicates that the PCRpt MUST include the SRP id in the subsequent PCE=
rr or PCRpt. I see no justification in the text to change the mechanism des=
cribed in draft-ietf-pce-stateful-pce-10.
=C2=A0=C2=A0=C2=A0 The SYNC fl=
ag MUST be set to 0, otherwise it may be confused with a full sync. 
=C2=A0- I believe all those updates are scoped only to the session that tr=
iggered the delta/PCE triggered sync, adding it explicitly would be good, a=
s its a change in the PCRpt mechanism of the PCC.

- What happens if =
the PCE sends multiple resync requests while the a full resync is in progre=
ss? 


Section 7:

- This should under section 3.3. PCEP Ext=
ensions, and refer to the section defining the bit behavior, 
- D bit re=
quires the S bit to be set, correct? A corresponding error is missing 
-=
 The behavior of T bit is not clear, see comment of section 5.
- T bit a=
nd D&S bit combination : it seems the T bit behavior does not depend on=
 the INCLUDE-DB-VERSION and Delta, so it can be set independently. This sho=
uld be specified.


Manageability section is missing.

Secti=
on 8.3.
Suggested values are off, 29 is the suggested value of the I bit=
 of draft-ietf-pce-pce-initiated-lsp-02.
I believed this should be:
<=
br>TBD(suggested value 27)=C2=A0 DELTA-LSP-SYNC-CAPABILITY=C2=A0=C2=A0 This=
 document
TBD(suggested value 28)=C2=A0 TRIGGERED-SYNC=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 This document<=
br>TBD(suggested value 30)=C2=A0 INCLUDE-DB-VERSION=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This document
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 

Section 9.

=C2=A0The document introduces new messages th=
at may introduce load on the PCC, a malicious PCE may flood the PCC with re=
sync requests, this should be mentioned. 




On 1 December 2014 at 12:18=
,  <julien.meuric@orange.com> wrote:
Dear all,



As planned, this message ignites a 3-week WG Last Call on both draft-ietf-p=
ce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-opti=
mizations-01. It will end on Monday December 22 at 11:59 PM, HST.



Please send your comments to the PCE mailing list.



Thanks,



JP & Julien





_____________________________________________________________=
____________________________________________________________<=
br>


Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.



This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and dele=
te this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.

Thank you.



_______________________________________________

Pce mailing list

Pce@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/pce





--001a11c24cbcd04622050ad2b643--


From nobody Mon Dec 22 11:04:29 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 E345C1A1E0F for ; Mon, 22 Dec 2014 11:04:26 -0800 (PST)
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 rtZHj6eFlWNH for ; Mon, 22 Dec 2014 11:04:18 -0800 (PST)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B7691A1B39 for ; Mon, 22 Dec 2014 11:04:17 -0800 (PST)
Received: by mail-wi0-f172.google.com with SMTP id n3so8915815wiv.5 for ; Mon, 22 Dec 2014 11:04:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=durSfpxu54N3jkRpgw5R5437bCdaKs0iJM7LI4MEJaE=; b=1ASl7SZLgsJuKDbj5BExGY8JigNIY4j1VfG2f5g/BCbyQYZD8fLgqPds6tgIf+8cBg jGKTmubcwQ7eSZ5n/bxuL0QpcMb0cf2QuZvmTGSv/Xb2GPW3Sy+Zqk7dFCadgoeA+PgD XNhiFfSLxaJpyhGhbX5kJGeu39Pcxc3UTSLwzLHOWBXmQZKXwbe+qVPkGSFxFwZXfARx PLKTP+44dV9yjfpJAjXPNHgNgASvArekQkoSZ/NbVL+k3u0zMHvisAMe8/uOgBXidfky OTrmRr6NJyA0i7kGcLdkfpbzVCvmG5tGWQ5eqk4lbcDHnnVBwUSpIB1466rO5GApfDQW hgSA==
MIME-Version: 1.0
X-Received: by 10.180.72.177 with SMTP id e17mr33615459wiv.42.1419275055895; Mon, 22 Dec 2014 11:04:15 -0800 (PST)
Received: by 10.27.89.133 with HTTP; Mon, 22 Dec 2014 11:04:15 -0800 (PST)
In-Reply-To: 
References: <12631_1417454286_547CA2CE_12631_12333_1_547CA2CA.1050804@orange.com> <23CE718903A838468A8B325B80962F9B8700D7AD@blreml504-mbx.china.huawei.com>  
Date: Mon, 22 Dec 2014 14:04:15 -0500
Message-ID: 
From: Cyril Margaria 
To: "BELOTTI, SERGIO (SERGIO)" 
Content-Type: multipart/alternative; boundary=f46d043c7c168b9adb050ad2b900
Archived-At: http://mailarchive.ietf.org/arch/msg/pce/Q7eO7nvEB8SfCcO2c0e7v1iC_WI
Cc: "pce@ietf.org" 
Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01
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, 22 Dec 2014 19:04:27 -0000

--f46d043c7c168b9adb050ad2b900
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

While reviewing draft-ietf-pce-stateful-sync-optimizations, I catched the
following additional nit:

SPEAKER-IDENTITY-ID -> SPEAKER-ENTITY-ID

- Missing a Manageability Considerations section, following RFC6123



On 22 December 2014 at 11:36, Cyril Margaria 
wrote:

> Hi,
>
> I have the following comments on draft-ietf-pce-pce-initiated-lsp-02:
> Some comments require non minor changes (security section). I think the
> document should progress, but I am not sure its fully ready for LC.
>
> Section 3.2. "Operation overview"
>
> - "A PCE may return a delegation to the PCC in order to facilitate
> re-delegation of its LSPs to an alternate PCE."
>   In this context (protocol operation), a MAY seems appropriate.
>
> Section 4.1:
> -  In draft-ietf-pce-stateful-sync-optimizations-01, the U is referenced
> in the list of flags. draft-ietf-pce-pce-initiated-lsp-02 could use the
> same format.
>
>
> Section 5
>
>  - The section is a mix of object definition and procedures, the
> procedures could be more clearly marked (having separate object format an=
d
> procedure section, or changing the section titles)
>
> Section 5.1.
>
>  - The error procedure refers to I-D.ietf-pce-stateful-pce for a message
> defined in this document, I-D.ietf-pce-stateful-pce should not define err=
or
> procedure for unknown message.
>    I believe you are refering to the error values
>   OLD:
>   "If either the SRP or the LSP object is missing, the PCC MUST send a
> PCErr as described in [I-D.ietf-pce-stateful-pce]."
>
>   NEW:
>   "If either the SRP or the LSP object is missing, the PCC MUST send a
> PCErr with error-type 6 (Mandatory Object missing) and error-value=3D10 (=
SRP
> Object missing), respectively error-value=3D8 (LSP Object missing). Those
> errors are defined defined in [I-D.ietf-pce-stateful-pce]."
>
>  - Section 3.2 has a more strict definition of the message content, that
> matches the RBNF, namely including the ERO and ENDPOINTS objects,
>    the text of section 3.2 sould be moved to this section (the overview
> being more detailed than the definition), but its also repeated in sectio=
n
> 5.3., maybe better to reference section 5.3 or have section 5.3 be a
> "procedures" subsection
>
> Section 5.2.
>
>  - "The type object is defined in [I-D.ietf-pce-stateful-pce]."
>   This sentence could be removed
>
>
> Section 5.3
>
> - OLD: "The LSP is set up using RSVP-TE, extensions for other setup
> methods are outside the scope of this draft."
>   NEW: "The LSP is assumed to be set up using RSVP-TE, extensions for
> other setup methods are outside the scope of this draft."
>
> - OLD: "The END-POINTS Object is mandatory for an instantiation request o=
f
> an RSVP-signaled LSP."
>   NEW: "The END-POINTS Object is mandatory for an instantiation request."
>
>  Regardless of RSVP or other protocol, the END-POINTS is required on a lo=
t
> of PCEP messages, so if new signaling protocols does not require the
> END-POINTS, its better to leave the new definition that will affect other
> PCEP messages to that document.
>
>  - Error code 6 (Object missing) for a missing TLV seems confusing, its
> more a malformed object content (as the TLV is part of the object), the T=
LV
> missing error should be reparented to error-type=3D10 (Reception of an
> invalid object)
>  - "If there is conflict with
>    the LSP name, the PCC MUST send a PCErr message with Error-type=3D23
>    (Bad Parameter value) and Error-value=3D1 (SYMBOLIC-PATH-NAME in use).
>    The only exception to this rule is for LSPs for which the State
>    timeout timer is running (see Section 6)."
>  I am unsure the exception is a good mechanism, this is detailed further
> in the comment for section 6.
>
>
>  - "LSPs that were instantiated as a result of a PCInitiate message MUST
> have the C flag set in the LSP object."
>   C flag is not yet defined, please add reference to the section or has
> Object extensions then procedures
>
>  - "If the PCC determines that the LSP parameters proposed in the
> PCInitiate message are unacceptable, it MUST trigger a PCErr with
>    error-type=3DTBD (PCE instantiation error) and error-value=3D1
> (Unacceptable instantiation parameters)."
>
>   This procedure is cleaner and offers more possibility for the PCE to
> know which parameter was wrong, base draft should use the same
>
>  - "A PCC MUST relay to the PCE errors it encounters in the..."
>   This imply that the PCC SHOULD wait for the LSP to be signaled before
> reporting the LSP State,  I would suggest the following text:
>
>  "The PCC SHOULD respond to the PCInitiate message when the LSP has been
> signaled. On succesful completion ... (Last paragraph).
>   On unsucessfull completion a PCC MUST relay ..."
>
>  - on PCInitiate , the Symbolic Path Name TLV is mandatory, the LSP
> Identifiers TLVs may be present unless specified (I do not see any
> drawback/limitation, behavior is the same as mplsTunnelIndex)
>    is this correct?
>  - Are the LSP Error Code TLV and  RSVP Error Spec TLV accepted, rejected
> or ignored?
>  - Section 5.3.1 indicated a new optional TLV (SPEAKER-IDENTITY-ID), mayb=
e
> a TLV presence rules section could be usefull, its now distributed over
> different sections and levels.
>
>
> Section 5.3.1.
>
>  - Is there any specific reason to have the flag defined as a subsection
> of the instantiation procedure rather than a separate section as the R fl=
ag?
>  - Nits : draft-ietf-pce-stateful-pce-10 define Flag, the document define=
s
> Flags, name should be aligned
>
>  - "If the TLV appears for an LSP for which the C flag is 0,
>    the TLV MUST be ignored the PCC MUST send a PCErr message with Error-
>    type 23 ("Bad parameter value") and error value 2 ("Speaker identity
>    included for an LSP that is not PCE-initiated")."
>
>  To ease procedure,  why not allow it? this can be set to the PCC
> SPEAKER-IDENTITY-ID for that matter, or simply ignored, it can be up to t=
he
> PCE. Why is the error necessary here?
>
> Section 5.4:
>
>  - OLD: "If the PLSP-ID specified in the PCInitiate message was not
> created by the PCE, the PCC MUST send a PCErr message indicating "LSP is
> not PCE initiated" (Error code 19,
>    error value TBD)."
>  - NEW: "If the PLSP-ID specified in the PCInitiate message was not
> created by a PCE, the PCC MUST send a PCErr message indicating "LSP is no=
t
> PCE initiated" (Error code 19,
>    error value TBD)."
>  (In case of multiple PCEs)
>
>  - TLV presence rules are missing:
>   - is symbolic path name, lsp identifiers, ..etc  allowed or ignored?
>   - does it make sense to allow the SPEAKER-IDENTITY TLV for debugging
> purpose in the subsequent PCRpt ?
>
> Section 6:
>  - For the delegation bit, adding "to the PCE the LSP is delegated to"
> would make the text more clear
>
>  - What does contains the PCErr message of type 19 (Invalid Operation) an=
d
> value TBD "Delegation for PCE-initiated LSP cannot be revoked"?
>    I believe it should at least contains the LSP object.
>
>  - 'A PCE MAY return a delegation to the PCC, to allow for LSP transfer
>    between PCEs.  Doing so MUST trigger the State Timeout Interval timer
>    ([I-D.ietf-pce-stateful-pce]).'
>
>    the state timeout interval is defined as "time period before flushing
> LSP state associated
>       with that PCEP session" (in case of session closed)
>    In the context of a PCE returning the delegation, the State Timeout
> interval should only apply to the LSP, not the the state associated to th=
e
> session. This should be stated
>
>  - "To  obtain control of a PCE-initiated LSP, a PCE (either the original
> or one of its backups) sends a PCInitiate message, ..."
>    It feels a bit of a patch, I believe the PCC can redelegate the LSP to
> the "original" PCE or to the "preferred" PCE by itself (Policies and
> SPEAKER-IDENTITY-ID would allow for that), rather than adding an exceptio=
n
> (who wins in case the timeout is long and several PCEs connect at the sam=
e
> time, for say a network failure?)
>
> Section 8.
>
> - Missing the new bit definition of Section 4.1. Stateful PCE Capability
> TLV (according to draft-ietf-pce-stateful-pce-10, section 8.6.)
>    I : bit  29
> - Missing the new bit definition of Section 5.2. The R flag in the SRP
> Object - The bit number should be defined (bit 31), should a new registry
> be defined at this point?
>
> Section 8.3
>  - As described before, error-type=3D23, error-value=3D2 is not needed
>  - Error-type=3D24, error-value=3D3 : OLD: "RSVP signaling error" , NEW:
> "signaling error" The type of error is included in the TLV, Restricting t=
he
> error to RSVP is too stong.
>
> Section 9.1:
>  "Rapid flaps triggered by the PCE can also be an attack vector.  This
> will be discussed in a future version of this document."
>  Its rather time to document them
>
>  The exception mechanism also introduce another attack (restart the
> session and steal LSPs)
>
>  Was the END-POINTS under PCE control considered? This would allow a
> malicious PCE to strain other AS/domains.
>
>
>
> On 22 December 2014 at 05:59, BELOTTI, SERGIO (SERGIO) <
> sergio.belotti@alcatel-lucent.com> wrote:
>
>>  Hi Druhv,
>>
>> as I pointed out in mail,
>>
>> in section 3.2 , when you talked about R flad in SRP, the fleg is new an=
d
>> is introduced in the following chapter.
>>
>> For me text should be:
>>
>> (2) In sec 3.2,
>>
>> OLD:
>>
>> To indicate a delete operation, the PCE MUST use the R flag in the SRP
>> object in a PCUpd message.
>>
>> NEW:
>>
>> To indicate a delete operation, a new R flag is introduced in the SRP
>> object and to be used in a PCInitiate message.
>>
>>
>>
>> Thanks
>>
>>
>>
>> Sergio
>>
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Dhruv Dhody
>> Sent: luned=C3=AC 22 dicembre 2014 11:44
>> To: julien.meuric@orange.com; pce@ietf.org
>> Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02
>> and draft-ietf-pce-stateful-sync-optimizations-01
>>
>>
>>
>> Hi All,
>>
>>
>>
>> > As planned, this message ignites a 3-week WG Last Call on both
>>
>> > draft-ietf-pce-pce-initiated-lsp-02
>>
>>
>>
>> Support with following comments:
>>
>>
>>
>> (1) We should align the tone of the draft to
>> http://tools.ietf.org/html/rfc7399#section-20 which differentiates
>> between the recommendation for instantiation (this draft), and the actua=
l
>> (NMS like) instantiation of the LSPs (marked out of scope). This could
>> either be done by a suitable text in Introduction and/or use of phrase
>> 'recommend instantiation' in the document.
>>
>>
>>
>> (2) In sec 3.2,
>>
>> OLD:
>>
>> To indicate a delete operation, the PCE MUST use the R flag in the SRP
>> object in a PCUpd message.
>>
>> NEW:
>>
>> To indicate a delete operation, the PCE MUST use the R flag in the SRP
>> object in a PCInitiate message.
>>
>>
>>
>> I guess Ramon pointed this out already!
>>
>>
>>
>> (3) In sec 5.3.1, we are changing the meaning of the SPEAKER-IDENTITY-ID
>> TLV, which was earlier used in OPEN to identify the exact PCEP-Speaker b=
ut
>> now here it identifies the PCE that initiated the LSP. This looks like a
>> hack, a better idea would be to define a new TLV type
>> PCE-INITIATED-IDENTITY-ID with the same format.
>>
>>
>>
>> (4) Section 9.1, it says...
>>
>> Rapid flaps triggered by the PCE can also be an attack vector.  This wil=
l
>> be discussed in a future version of this document.
>>
>>
>>
>> The text for this needs to be added.
>>
>>
>>
>> (5) It would be nice to have a manageability consideration section.
>>
>>
>>
>> (6) Few lines on state synchronization should also be added -  If the DB
>> did not survive the PCC restart, PCE must send the PCE initiated message
>> again. During state synchronization the PCE should get the status of PCE
>> Initiated LSPs with C flag set in the LSP object. Incase of redelegation=
 to
>> a different PCE the same should be reported during state synchnronizatio=
n
>> with D=3D0. The original PCE should also be allowed to send PCInitiate t=
o get
>> back the delegation. (this is not allowed in the current text as PCIniti=
ate
>> with non-zero PLSP-ID is allowed only during State Timeout timer)
>>
>>
>>
>> Nits
>>
>> - Reference to 2119, as SHOULD, MUST are used in the document
>>
>> - Expand on first use LER, LSR etc
>>
>> - Reference to SRP, LSP, PLSP-ID as defined in [I-D.ietf-pce-stateful-pc=
e]
>>
>> - section 3.2 s/PCinitiate/PCInitiate/
>>
>> - section 4 s/A PCC indicates its ability.../A PCEP speaker indicates it=
s
>> ability/ (because both PCC and PCE needs to do this)
>>
>> - section 4.1 Type=3D16 should be removed as its TBD in the base documen=
t
>> as well
>> http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-10#section-7.1.1
>>
>> - section 4.1
>>
>> OLD:
>>
>> If set to 1 by a PCE, the I flag indicates that the PCE will attempt to
>> instantiate LSPs.
>>
>> NEW:
>>
>> If set to 1 by a PCE, the I flag indicates that the PCE can attempt to
>> instantiate LSPs.
>>
>>
>>
>>
>>
>> > and draft-ietf-pce-stateful-sync-
>>
>> > optimizations-01.
>>
>>
>>
>> Support (As a co-author)
>>
>>
>>
>> Regards,
>>
>> Dhruv
>>
>>
>>
>> > It will end on Monday December 22 at 11:59 PM, HST.
>>
>> >
>>
>> > Please send your comments to the PCE mailing list.
>>
>> >
>>
>> > Thanks,
>>
>> >
>>
>> > JP & Julien
>>
>> >
>>
>> >
>>
>> > _____________________________________________________________________
>>
>> > ____________________________________________________
>>
>> >
>>
>> > Ce message et ses pieces jointes peuvent contenir des informations
>>
>> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>>
>> > exploites ou copies sans autorisation. Si vous avez recu ce message
>>
>> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
>>
>> > que les pieces jointes. Les messages electroniques etant susceptibles
>>
>> > d'alteration, Orange decline toute responsabilite si ce message a ete
>>
>> > altere, deforme ou falsifie. Merci.
>>
>> >
>>
>> > This message and its attachments may contain confidential or
>>
>> > privileged information that may be protected by law; they should not
>>
>> > be distributed, used or copied without authorisation.
>>
>> > If you have received this email in error, please notify the sender and
>>
>> > delete this message and its attachments.
>>
>> > As emails may be altered, Orange is not liable for messages that have
>>
>> > been modified, changed or falsified.
>>
>> > Thank you.
>>
>> >
>>
>> > _______________________________________________
>>
>> > 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
>>
>> _______________________________________________
>> Pce mailing list
>> Pce@ietf.org
>> https://www.ietf.org/mailman/listinfo/pce
>>
>>
>

--f46d043c7c168b9adb050ad2b900
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

While reviewing draft-ietf-pce-stateful-sync-op=
timizations, I catched the following additional nit:

SPEAKER-IDENTIT=
Y-ID -> SPEAKER-ENTITY-ID 

- Missing a Manageability Consideratio=
ns section, following RFC6123


<=
br>
On 22 December 2014 at 11:36, Cyril Margaria =
<cyril.margaria@gmail.com> wrote:
Hi, 

I have the following comments o=
n draft-ietf-pce-pce-initiated-lsp-02:
Some comments require non minor c=
hanges (security section). I think the document should progress, but I am n=
ot sure its fully ready for LC.

Section 3.2. "Operation overvie=
w"

- "A PCE may return a delegation to the PCC in order to=
 facilitate re-delegation of its LSPs to an alternate PCE."
=C2=A0 =
In this context (protocol operation), a MAY seems appropriate.

Secti=
on 4.1:
-=C2=A0 In draft-ietf-pce-stateful-sync-optimizations-01, the U =
is referenced in the list of flags. draft-ietf-pce-pce-initiated-lsp-02 cou=
ld use the same format.


Section 5

=C2=A0- The section is =
a mix of object definition and procedures, the procedures could be more cle=
arly marked (having separate object format and procedure section, or changi=
ng the section titles) 

Section 5.1.
=C2=A0
=C2=A0- The error =
procedure refers to I-D.ietf-pce-stateful-pce for a message defined in this=
 document, I-D.ietf-pce-stateful-pce should not define error procedure for =
unknown message.
=C2=A0=C2=A0 I believe you are refering to the error va=
lues
=C2=A0 OLD:
=C2=A0 "If either the SRP or the LSP object is =
missing, the PCC MUST send a PCErr as described in [I-D.ietf-pce-stateful-p=
ce]."

=C2=A0 NEW:
=C2=A0 "If either the SRP or the LSP =
object is missing, the PCC MUST send a PCErr with error-type 6 (Mandatory O=
bject missing) and error-value=3D10 (SRP Object missing), respectively erro=
r-value=3D8 (LSP Object missing). Those errors are defined defined in [I-D.=
ietf-pce-stateful-pce]."

=C2=A0- Section 3.2 has a more strict =
definition of the message content, that matches the RBNF, namely including =
the ERO and ENDPOINTS objects,
=C2=A0=C2=A0 the text of section 3.2 soul=
d be moved to this section (the overview being more detailed than the defin=
ition), but its also repeated in section 5.3., maybe better to reference se=
ction 5.3 or have section 5.3 be a "procedures" subsection 
Section 5.2.
=C2=A0
=C2=A0- "The type object is defined in [I-=
D.ietf-pce-stateful-pce]."
=C2=A0 This sentence could be removed=C2=A0 

Section 5.3

- OLD: "The LSP is set up using RSV=
P-TE, extensions for other setup methods are outside the scope of this draf=
t."
=C2=A0 NEW: "The LSP is assumed to be set up using RSVP-TE=
, extensions for other setup methods are outside the scope of this draft.&q=
uot;
=C2=A0 
- OLD: "The END-POINTS Object is mandatory for an i=
nstantiation request of an RSVP-signaled LSP."
=C2=A0 NEW: "Th=
e END-POINTS Object is mandatory for an instantiation request."
=C2=
=A0
=C2=A0Regardless of RSVP or other protocol, the END-POINTS is requir=
ed on a lot of PCEP messages, so if new signaling protocols does not requir=
e the END-POINTS, its better to leave the new definition that will affect o=
ther PCEP messages to that document.

=C2=A0- Error code 6 (Object mi=
ssing) for a missing TLV seems confusing, its more a malformed object conte=
nt (as the TLV is part of the object), the TLV missing error should be repa=
rented to error-type=3D10 (Reception of an invalid object) 
=C2=A0- &quo=
t;If there is conflict with
=C2=A0=C2=A0 the LSP name, the PCC MUST send=
 a PCErr message with Error-type=3D23
=C2=A0=C2=A0 (Bad Parameter value)=
 and Error-value=3D1 (SYMBOLIC-PATH-NAME in use).
=C2=A0=C2=A0 The only =
exception to this rule is for LSPs for which the State
=C2=A0=C2=A0 time=
out timer is running (see Section 6)."
=C2=A0I am unsure the except=
ion is a good mechanism, this is detailed further in the comment for sectio=
n 6.
=C2=A0 

=C2=A0- "LSPs that were instantiated as a resul=
t of a PCInitiate message MUST have the C flag set in the LSP object."=

=C2=A0 C flag is not yet defined, please add reference to the section o=
r has Object extensions then procedures

=C2=A0- "If the PCC det=
ermines that the LSP parameters proposed in the PCInitiate message are unac=
ceptable, it MUST trigger a PCErr with
=C2=A0=C2=A0 error-type=3DTBD (PC=
E instantiation error) and error-value=3D1 (Unacceptable instantiation para=
meters)."

=C2=A0 This procedure is cleaner and offers more poss=
ibility for the PCE to know which parameter was wrong, base draft should us=
e the same 

=C2=A0- "A PCC MUST relay to the PCE errors it enco=
unters in the..."
=C2=A0 This imply that the PCC SHOULD wait for th=
e LSP to be signaled before reporting the LSP State,=C2=A0 I would suggest =
the following text:

=C2=A0"The PCC SHOULD respond to the PCInit=
iate message when the LSP has been signaled. On succesful completion ... (L=
ast paragraph).
=C2=A0 On unsucessfull completion a PCC MUST relay ...&q=
uot; 

=C2=A0- on PCInitiate , the Symbolic Path Name TLV is mandator=
y, the LSP Identifiers TLVs may be present unless specified (I do not see a=
ny drawback/limitation, behavior is the same as mplsTunnelIndex) 
=C2=A0=
=C2=A0 is this correct?
=C2=A0- Are the LSP Error Code TLV and=C2=A0 RSV=
P Error Spec TLV accepted, rejected or ignored? 
=C2=A0- Section 5.3.1 i=
ndicated a new optional TLV (SPEAKER-IDENTITY-ID), maybe a TLV presence rul=
es section could be usefull, its now distributed over different sections an=
d levels.
=C2=A0

Section 5.3.1.

=C2=A0- Is there any speci=
fic reason to have the flag defined as a subsection of the instantiation pr=
ocedure rather than a separate section as the R flag?
=C2=A0- Nits : dra=
ft-ietf-pce-stateful-pce-10 define Flag, the document defines Flags, name s=
hould be aligned

=C2=A0- "If the TLV appears for an LSP for whi=
ch the C flag is 0,
=C2=A0=C2=A0 the TLV MUST be ignored the PCC MUST se=
nd a PCErr message with Error-
=C2=A0=C2=A0 type 23 ("Bad parameter=
 value") and error value 2 ("Speaker identity
=C2=A0=C2=A0 inc=
luded for an LSP that is not PCE-initiated")."
=C2=A0
=C2=
=A0To ease procedure,=C2=A0 why not allow it? this can be set to the PCC SP=
EAKER-IDENTITY-ID for that matter, or simply ignored, it can be up to the P=
CE. Why is the error necessary here?

Section 5.4:

=C2=A0- OLD=
: "If the PLSP-ID specified in the PCInitiate message was not created =
by the PCE, the PCC MUST send a PCErr message indicating "LSP is not P=
CE initiated" (Error code 19,
=C2=A0=C2=A0 error value TBD)."<=
br>=C2=A0- NEW: "If the PLSP-ID specified in the PCInitiate message wa=
s not created by a PCE, the PCC MUST send a PCErr message indicating "=
LSP is not PCE initiated" (Error code 19,
=C2=A0=C2=A0 error value =
TBD)."
=C2=A0(In case of multiple PCEs)

=C2=A0- TLV presence=
 rules are missing:
=C2=A0 - is symbolic path name, lsp identifiers, ..e=
tc=C2=A0 allowed or ignored?
=C2=A0 - does it make sense to allow the SP=
EAKER-IDENTITY TLV for debugging purpose in the subsequent PCRpt ? 
=C2=
=A0 
Section 6:
=C2=A0- For the delegation bit, adding "to the P=
CE the LSP is delegated to" would make the text more clear 

=C2=
=A0- What does contains the PCErr message of type 19 (Invalid Operation) an=
d value TBD "Delegation for PCE-initiated LSP cannot be revoked"?=
 =C2=A0=C2=A0=C2=A0 
=C2=A0=C2=A0 I believe it should at least contains =
the LSP object.

=C2=A0- 'A PCE MAY return a delegation to the PC=
C, to allow for LSP transfer
=C2=A0=C2=A0 between PCEs.=C2=A0 Doing so M=
UST trigger the State Timeout Interval timer
=C2=A0=C2=A0 ([I-D.ietf-pce=
-stateful-pce]).'
=C2=A0=C2=A0 
=C2=A0=C2=A0 the state timeout in=
terval is defined as "time period before flushing LSP state associated=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 with that PCEP session" (in case of=
 session closed)
=C2=A0=C2=A0 In the context of a PCE returning the dele=
gation, the State Timeout interval should only apply to the LSP, not the th=
e state associated to the session. This should be stated

=C2=A0- &qu=
ot;To=C2=A0 obtain control of a PCE-initiated LSP, a PCE (either the origin=
al or one of its backups) sends a PCInitiate message, ..."
=C2=A0=
=C2=A0 It feels a bit of a patch, I believe the PCC can redelegate the LSP =
to the "original" PCE or to the "preferred" PCE by itse=
lf (Policies and SPEAKER-IDENTITY-ID would allow for that), rather than add=
ing an exception (who wins in case the timeout is long and several PCEs con=
nect at the same time, for say a network failure?)

Section 8.
- Missing the new bit definition of Section 4.1. Stateful PCE Capability T=
LV (according to draft-ietf-pce-stateful-pce-10, section 8.6.)
=C2=A0=C2=
=A0 I : bit=C2=A0 29 
- Missing the new bit definition of Section 5.2. T=
he R flag in the SRP Object - The bit number should be defined (bit 31), sh=
ould a new registry be defined at this point? 

Section 8.3 
=C2=
=A0- As described before, error-type=3D23, error-value=3D2 is not needed=C2=A0- Error-type=3D24, error-value=3D3 : OLD: "RSVP signaling error=
" , NEW: "signaling error" The type of error is included in =
the TLV, Restricting the error to RSVP is too stong.

Section 9.1:
=C2=A0"Rapid flaps triggered by the PCE can also be =
an attack vector.=C2=A0 This will be discussed in a future version of this =
document."
=C2=A0Its rather time to document them

=C2=
=A0The exception mechanism also introduce another attack (restart the sessi=
on and steal LSPs) 

=C2=A0Was the END-POINTS under PCE control consi=
dered? This would allow a malicious PCE to strain other AS/domains.

=


On 22 December 2014 at 05:59, BELOTTI, SER=
GIO (SERGIO) <sergio.belotti@alcatel-lucent.com> wrote:











Hi Druhv,


as I pointed out in mail, 


in section 3.2 , when you talked about R flad in SR=
P, the fleg is new and is introduced in the following chapter.


For me text should be:


(2) In sec 3.2,


OLD:


To indicate a delete operation, the PCE MUST use th=
e R flag in the SRP object in a PCUpd message.


NEW:


To indicate a delete operation, 
a new R flag is introduced in the SRP object and to be used in a PCInitiate=
 message.


=C2=A0


Thanks


=C2=A0


Sergio


=C2=A0


=C2=A0


=C2=A0


-----Original Message-----

From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Dhruv Dhody

Sent: luned=C3=AC 22 dicembre 2014 11:44

To: julien.me=
uric@orange.com; pce@=
ietf.org

Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and =
draft-ietf-pce-stateful-sync-optimizations-01


=C2=A0


Hi All, 


=C2=A0


> As planned, this message ignites a 3-week WG Last Call on both


> draft-ietf-pce-pce-initiated-lsp-02


=C2=A0


Support with following comments: 


=C2=A0


(1) We should align the tone of the draft to 
http://tools.ietf.org=
/html/rfc7399#section-20 which differentiates between the recomm=
endation for instantiation (this draft), and the actual (NMS like) instanti=
ation of the LSPs (marked out of scope).
 This could either be done by a suitable text in Introduction and/or use of=
 phrase 'recommend instantiation' in the document.



=C2=A0


(2) In sec 3.2,


OLD:


To indicate a delete operation, the PCE MUST use the R flag in the SRP o=
bject in a PCUpd message.


NEW:


To indicate a delete operation, the PCE MUST use the R flag in the SRP o=
bject in a PCInitiate message.


=C2=A0


I guess Ramon pointed this out already! 


=C2=A0


(3) In sec 5.3.1, we are changing the meaning of the SPEAKER-IDENTITY-ID=
 TLV, which was earlier used in OPEN to identify the exact PCEP-Speaker but=
 now here it identifies the PCE that initiated the LSP. This looks like a h=
ack, a better
 idea would be to define a new TLV type PCE-INITIATED-IDENTITY-ID with the =
same format.



=C2=A0


(4) Section 9.1, it says...


Rapid flaps triggered by the PCE can also be an attack vector.=C2=A0 Thi=
s will be discussed in a future version of this document.


=C2=A0


The text for this needs to be added. 


=C2=A0


(5) It would be nice to have a manageability consideration section.



=C2=A0


(6) Few lines on state synchronization should also be added -=C2=A0 If t=
he DB did not survive the PCC restart, PCE must send the PCE initiated mess=
age again. During state synchronization the PCE should get the status of PC=
E Initiated LSPs
 with C flag set in the LSP object. Incase of redelegation to a different P=
CE the same should be reported during state synchnronization with D=3D0. Th=
e original PCE should also be allowed to send PCInitiate to get back the de=
legation. (this is not allowed in
 the current text as PCInitiate with non-zero PLSP-ID is allowed only durin=
g State Timeout timer)=C2=A0



=C2=A0


Nits


- Reference to 2119, as SHOULD, MUST are used in the document<=
/u>


- Expand on first use LER, LSR etc


- Reference to SRP, LSP, PLSP-ID as defined in [I-D.ietf-pce-stateful-pc=
e]


- section 3.2 s/PCinitiate/PCInitiate/


- section 4 s/A PCC indicates its ability.../A PCEP speaker indicates it=
s ability/ (because both PCC and PCE needs to do this)


- section 4.1 Type=3D16 should be removed as its TBD in the base documen=
t as well

http://tools.ietf.org=
/html/draft-ietf-pce-stateful-pce-10#section-7.1.1=



- section 4.1


OLD:


If set to 1 by a PCE, the I flag indicates that the PCE will attempt to =
instantiate LSPs.


NEW:


If set to 1 by a PCE, the I flag indicates that the PCE can attempt to i=
nstantiate LSPs.


=C2=A0


=C2=A0


> and draft-ietf-pce-stateful-sync-


> optimizations-01. 


=C2=A0


Support (As a co-author)


=C2=A0


Regards,


Dhruv


=C2=A0


> It will end on Monday December 22 at 11:59 PM, HST.

> 


> Please send your comments to the PCE mailing list.

> 


> Thanks,


> 


> JP & Julien


> 


> 


> ___________________________________________________________________=
__


> ____________________________________________________<=
/p>

> 


> Ce message et ses pieces jointes peuvent contenir des informations



> confidentielles ou privilegiees et ne doivent donc pas etre diffuse=
s,



> exploites ou copies sans autorisation. Si vous avez recu ce message



> par erreur, veuillez le signaler a l'expediteur et le detruire =
ainsi



> que les pieces jointes. Les messages electroniques etant susceptibl=
es



> d'alteration, Orange decline toute responsabilite si ce message=
 a ete



> altere, deforme ou falsifie. Merci.


> 


> This message and its attachments may contain confidential or



> privileged information that may be protected by law; they should no=
t



> be distributed, used or copied without authorisation.=



> If you have received this email in error, please notify the sender =
and



> delete this message and its attachments.


> As emails may be altered, Orange is not liable for messages that ha=
ve



> been modified, changed or falsified.


> Thank you.


> 


> _______________________________________________


> Pce mailing list


> Pce@ietf.org<=
/p>

> https://www.ietf=
.org/mailman/listinfo/pce


=C2=A0


_______________________________________________


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








--f46d043c7c168b9adb050ad2b900--


From nobody Tue Dec 23 20:59:55 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 65A431ACC86; Tue, 23 Dec 2014 20:59:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.912
X-Spam-Level: 
X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 F2U4H0cllnKe; Tue, 23 Dec 2014 20:59:46 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 582451AC44C; Tue, 23 Dec 2014 20:59:46 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 1D62A18123F; Tue, 23 Dec 2014 20:59:06 -0800 (PST)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
X-PHP-Originating-Script: 6000:ams_util_lib.php
From: rfc-editor@rfc-editor.org
Message-Id: <20141224045906.1D62A18123F@rfc-editor.org>
Date: Tue, 23 Dec 2014 20:59:06 -0800 (PST)
Archived-At: http://mailarchive.ietf.org/arch/msg/pce/_dWFueB1lu2clE2l7tKyGr2KP9A
Cc: drafts-update-ref@iana.org, pce@ietf.org, rfc-editor@rfc-editor.org
Subject: [Pce] RFC 7420 on Path Computation Element Communication Protocol (PCEP)Management Information Base (MIB) Module
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, 24 Dec 2014 04:59:52 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 7420

        Title:      Path Computation Element Communication Protocol 
                    (PCEP) Management Information Base (MIB) Module 
        Author:     A. Koushik, E. Stephan,
                    Q. Zhao, D. King, J. Hardwick
        Status:     Standards Track
        Stream:     IETF
        Date:       December 2014
        Mailbox:    kkoushik@brocade.com, 
                    emile.stephan@orange.com, 
                    qzhao@huawei.com,
                    daniel@olddog.co.uk, 
                    jonathan.hardwick@metaswitch.com
        Pages:      65
        Characters: 130964
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-pce-pcep-mib-11.txt

        URL:        https://www.rfc-editor.org/rfc/rfc7420.txt

This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects for modeling of the Path
Computation Element Communication Protocol (PCEP) for communications
between a Path Computation Client (PCC) and a Path Computation
Element (PCE), or between two PCEs.

This document is a product of the Path Computation Element Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From nobody Tue Dec 30 05:09:41 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 C44D01A00AE; Tue, 30 Dec 2014 05:09:37 -0800 (PST)
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 UouO-W_OXdC3; Tue, 30 Dec 2014 05:09:36 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0912E1A0099; Tue, 30 Dec 2014 05:09:36 -0800 (PST)
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.10.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141230130936.28650.13373.idtracker@ietfa.amsl.com>
Date: Tue, 30 Dec 2014 05:09:36 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/pce/verTjbsWBkqqq8mmd2r6R49-S9A
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-pcep-domain-sequence-07.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: Tue, 30 Dec 2014 13:09:38 -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           : Standard Representation of Domain-Sequence
        Authors         : Dhruv Dhody
                          Udayasree Palle
                          Ramon Casellas
	Filename        : draft-ietf-pce-pcep-domain-sequence-07.txt
	Pages           : 30
	Date            : 2014-12-30

Abstract:
   The ability to compute shortest constrained Traffic Engineering Label
   Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and
   Generalized MPLS (GMPLS) networks across multiple domains has been
   identified as a key requirement.  In this context, a domain is a
   collection of network elements within a common sphere of address
   management or path computational responsibility such as an Interior
   Gateway Protocol (IGP) area or an Autonomous System (AS).  This
   document specifies a standard representation and encoding of a
   Domain-Sequence, which is defined as an ordered sequence of domains
   traversed to reach the destination domain to be used by Path
   Computation Elements (PCEs) to compute inter-domain constrained
   shortest paths across a predetermined sequence of domains . This
   document also defines new subobjects to be used to encode domain
   identifiers.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-domain-sequence/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pce-pcep-domain-sequence-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-domain-sequence-07


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 Tue Dec 30 05:13:04 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 D85CF1A00A2 for ; Tue, 30 Dec 2014 05:13:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, 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 aPt3-AG4-j_Z for ; Tue, 30 Dec 2014 05:13:01 -0800 (PST)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF9731A0099 for ; Tue, 30 Dec 2014 05:13:00 -0800 (PST)
Received: by mail-ig0-f169.google.com with SMTP id z20so1709058igj.2 for ; Tue, 30 Dec 2014 05:13:00 -0800 (PST)
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:content-type; bh=SdxmEnRy6PwKirehw3ry22XSZDWbcGNmiFI7o1NFyCI=; b=VSSwfv7/v5fzTbi9A0/aY1U7QFVwCAmKkIz3Rim6DC8qjfZFIU2a8U9ZE7tAv7v3k0 s/WEsnzkLh0wd//SWG6lOiJHa0lZrlI4Su86SscSK0rkJbAqhF6k2AKW76/SHxK1TZDc EXRb5/v/XoncWbu4MP+8vLEpm+yFiDAYgZ493hwny40VQTPGPCxPWuEknRmBHauStkUl bxdj/T14NYWB2zm4L9Z5wmSWPqA/swvWf9cH51Y6Dk74N2mMMS2pyLMP/rSf3zbQNJjj sf5rcP3kx+clXKd9Gqya9Yme7lXUKHDfc371CgbLV+ArZOCFQhsbJOoefVv8X/SKtnXB zJDw==
MIME-Version: 1.0
X-Received: by 10.43.38.9 with SMTP id tg9mr44874502icb.1.1419945179907; Tue, 30 Dec 2014 05:12:59 -0800 (PST)
Sender: dhruvdhody@gmail.com
X-Google-Sender-Delegation: dhruvdhody@gmail.com
Received: by 10.50.154.68 with HTTP; Tue, 30 Dec 2014 05:12:59 -0800 (PST)
In-Reply-To: <20141230130936.28650.13373.idtracker@ietfa.amsl.com>
References: <20141230130936.28650.13373.idtracker@ietfa.amsl.com>
Date: Tue, 30 Dec 2014 18:42:59 +0530
X-Google-Sender-Auth: z7GbSCWqDuYrRlOqTdNKMX1lOrM
Message-ID: 
From: Dhruv Dhody 
To: "pce@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/pce/-SraWnmMU24Abqcs2NrElHFJ4bc
Subject: Re: [Pce] I-D Action: draft-ietf-pce-pcep-domain-sequence-07.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: Tue, 30 Dec 2014 13:13:03 -0000

Hi PCErs,

This update handles some editorial comments that I received during the
RFC editor early review exercise during IETF 91.

Happy 2015.

Dhruv

On Tue, Dec 30, 2014 at 6:39 PM,   wrote:
>
> 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           : Standard Representation of Domain-Sequence
>         Authors         : Dhruv Dhody
>                           Udayasree Palle
>                           Ramon Casellas
>         Filename        : draft-ietf-pce-pcep-domain-sequence-07.txt
>         Pages           : 30
>         Date            : 2014-12-30
>
> Abstract:
>    The ability to compute shortest constrained Traffic Engineering Label
>    Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and
>    Generalized MPLS (GMPLS) networks across multiple domains has been
>    identified as a key requirement.  In this context, a domain is a
>    collection of network elements within a common sphere of address
>    management or path computational responsibility such as an Interior
>    Gateway Protocol (IGP) area or an Autonomous System (AS).  This
>    document specifies a standard representation and encoding of a
>    Domain-Sequence, which is defined as an ordered sequence of domains
>    traversed to reach the destination domain to be used by Path
>    Computation Elements (PCEs) to compute inter-domain constrained
>    shortest paths across a predetermined sequence of domains . This
>    document also defines new subobjects to be used to encode domain
>    identifiers.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-domain-sequence/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-pce-pcep-domain-sequence-07
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-domain-sequence-07
>
>
> 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


From nobody Tue Dec 30 05:22:19 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 ECB611A00B1 for ; Tue, 30 Dec 2014 05:22:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level: 
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 rbg1wEoGTg4S for ; Tue, 30 Dec 2014 05:22:13 -0800 (PST)
Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAE1C1A00AE for ; Tue, 30 Dec 2014 05:22:12 -0800 (PST)
Received: by mail-ie0-f179.google.com with SMTP id rp18so13519299iec.38 for ; Tue, 30 Dec 2014 05:22:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=LTFizSL1NSLnsfVNHv7SljPU/b1IHpLjVtMUsfInJ0s=; b=h1rww9mlx4A3UTtmFlHhD2JPAkWCqotQq4BqnoLcfDu5EPLbpgu11TLeHiAFDlCVkc HD/7aVXZCN0Wz6I11NUxjeqchEWbPt22wNwXhOYTVbdi3bWlktqlg7CQkwJpJGhxI94x K1caCdyeuKzYnnyz7hlR7otF13VkzBS+YEmOIISLfdK8xFqy1RF5FRvkSagh5fhMIsN7 mpuBFzT3kqySDrdWoQQga7fefYUE4VrCZdH/jNrmyY2uSfTVivptxzAb4OPhz12E2D/i PA9upGnLZqieqOmeETOqpES8F4lc7ZhbP+mbLKo47+aYJy3pG1gprmp/+X+m3WZ/o80U tJug==
MIME-Version: 1.0
X-Received: by 10.42.103.7 with SMTP id k7mr46148392ico.33.1419945731853; Tue, 30 Dec 2014 05:22:11 -0800 (PST)
Sender: dhruvdhody@gmail.com
X-Google-Sender-Delegation: dhruvdhody@gmail.com
Received: by 10.50.154.68 with HTTP; Tue, 30 Dec 2014 05:22:11 -0800 (PST)
In-Reply-To: 
References: 
Date: Tue, 30 Dec 2014 18:52:11 +0530
X-Google-Sender-Auth: v6nocYWpZ_HJFRBGu8wRsRcXxmA
Message-ID: 
From: Dhruv Dhody 
To: Wenhu Lu 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/pce/bDMxfqurV4R_vXz86-RZguYPPNU
Cc: "pce@ietf.org" 
Subject: Re: [Pce] draft-ietf-pce-pcep-domain-sequence-06
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, 30 Dec 2014 13:22:18 -0000

Hi Wenhu,

It was pointed out to me by my co-author that somehow I missed
replying to your mail. Apologies for that.

See inline...

On Fri, Nov 21, 2014 at 2:58 AM, Wenhu Lu  wrote:
>
> Dear authors,
>
>
>
> Following the presentation in IETF91, I would like to add several comment=
s
> below:
>
>
>
> o   Which track:
>
> o   Protocol and ability to define domain wide sequence is gaining
> importance recently, and in particular when applied to the use-cases like
>
> =C2=A7  SDN controller
>
> =C2=B7      It will have to determine the set of entities and the order o=
f them
> in forming paths
>
> =C2=A7  In SPRING, the sequence can serve as input in source routing
>
> o   I=E2=80=99m not sure if it=E2=80=99s too late. But I think this draft=
 can be on the
> standard track.

As authors/editors, we do not have any strong opinion on this. We
would love to hear from the WG if we should change track for the
document to "standards track"?

>
> o   Section 1 =E2=80=9CThe Domain-Sequence =E2=80=A6 out of scope=E2=80=
=9D
>
> o   I think this should be included as =E2=80=9Cin-scope=E2=80=9D, or def=
ined in a separate
> document

Updated in -07 version.

>
> =C2=A7  We can define strict and loose sequence
>
> =C2=B7      similar to RSVP EROs, loose or strict
>
> =C2=B7      In case of loose, it can be either
>
> o   Administratively, giving admin/controller power/flexibility
>]
> =C2=A7  This may include Policy (Similar to RPL/ACL)
>
> =C2=A7  And if one wants to go non-conventional paths
>
> =C2=A7  Even H-PCE can be considered as in this category, as one has to d=
ecide
> how to partition and arrange the tree
>
> o   Automated
>
> =C2=A7  ABR/ASBR negotiation (capability and dependency)
>
> =C2=A7  There are drafts doing =E2=80=9Clowest-cost=E2=80=9D (similar to =
IGP=E2=80=99s shortest path)
> algorithm

- This draft supports Loose-Bit (L-Bit) in IRO as per the IRO
specification update
[http://datatracker.ietf.org/doc/draft-dhody-pce-iro-update/]. So the
above is supported and an implementation may set the L-bit based on
any of these use cases. Do you see a need to discuss the above in the
PCEP protocol specification document? If yes, perhaps you can provide
some text that the WG can evaluate.

>
> o   Typo: section 7.5 =E2=80=9Cand signaling message=E2=80=9D should be =
=E2=80=9Ca signaling
> message=E2=80=9D
>

Thanks, updated in -07 version.

Thanks again for your comments and sorry for my delayed response.

Regards,
Dhruv

>
>
> Regards,
>
> -wenhu
>
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>