From pce-bounces@ietf.org Thu May 1 09:30:56 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A77013A6922; Thu, 1 May 2008 09:30:56 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB70A3A6DD9; Wed, 30 Apr 2008 07:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9klNKzw9-a6; Wed, 30 Apr 2008 07:29:18 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id BABBC3A6958; Wed, 30 Apr 2008 07:29:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,728,1199682000"; d="scan'208";a="124292535" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 30 Apr 2008 10:29:20 -0400 X-IronPort-AV: E=Sophos;i="4.25,728,1199682000"; d="scan'208";a="188582571" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 30 Apr 2008 10:29:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Apr 2008 16:29:17 +0200 Message-ID: In-reply-to: <20080416204850.8E0A43A6F68@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-ietf-pce-pcep (Path Computation Element (PCE) Communication Protocol (PCEP)) to Proposed Standard Thread-Index: AcigA9rkWmkwlOt0RpeO4vdaX3KdkgKydwuA References: <20080416204850.8E0A43A6F68@core3.amsl.com> From: "Romascanu, Dan (Dan)" To: , "IETF-Announce" X-Mailman-Approved-At: Thu, 01 May 2008 09:30:56 -0700 Cc: ops-dir@ietf.org, pce@ietf.org Subject: Re: [Pce] Last Call: draft-ietf-pce-pcep (Path Computation Element (PCE) Communication Protocol (PCEP)) to Proposed Standard X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org I would like to congratulate the editors for the inclusion and content of the Manageability Consideration section. It is well written, and includes detailed information that will be very useful for implementers as well as for operators who will deploy the protocol. One nit: in section 8.6 s/number of session/number of sessions/ Dan > -----Original Message----- > From: ietf-announce-bounces@ietf.org > [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG > Sent: Wednesday, April 16, 2008 11:49 PM > To: IETF-Announce > Cc: pce@ietf.org > Subject: Last Call: draft-ietf-pce-pcep (Path Computation > Element (PCE) Communication Protocol (PCEP)) to Proposed Standard > > The IESG has received a request from the Path Computation Element WG > (pce) to consider the following document: > > - 'Path Computation Element (PCE) Communication Protocol (PCEP) ' > as a 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 > 2008-04-30. 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. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-12.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=vie > w_id&dTag=14049&rfc_flag=0 > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Thu May 1 09:30:56 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB4673A6AFE; Thu, 1 May 2008 09:30:56 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF7773A6E29; Thu, 1 May 2008 08:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-s+zf1EmCHz; Thu, 1 May 2008 08:36:01 -0700 (PDT) Received: from ogud.com (hlid.ogud.com [66.92.146.160]) by core3.amsl.com (Postfix) with ESMTP id 2616928C3FB; Thu, 1 May 2008 08:33:42 -0700 (PDT) Received: from Puki.ogud.com (ns.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m41FXcn2013012; Thu, 1 May 2008 11:33:38 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200805011533.m41FXcn2013012@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 01 May 2008 11:33:36 -0400 To: "Romascanu, Dan (Dan)" , , "IETF-Announce" From: Olafur Gudmundsson In-Reply-To: References: <20080416204850.8E0A43A6F68@core3.amsl.com> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 X-Mailman-Approved-At: Thu, 01 May 2008 09:30:56 -0700 Cc: ops-dir@ietf.org, pce@ietf.org Subject: Re: [Pce] Last Call: draft-ietf-pce-pcep (Path Computation Element (PCE) Communication Protocol (PCEP)) to Proposed Standard X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Yes this is well written document, I find it scary how many flags fields the document defines in message types with no flags defined and NO GUIDANCE on the scope of these flags. Are they per "object Class +object type" or per message type. Are these needed or just nice to have? What is the harm to just define these fields as Reserved ? Olafur At 05:56 30/04/2008, Romascanu, Dan (Dan) wrote: >I would like to congratulate the editors for the inclusion and content >of the Manageability Consideration section. It is well written, and >includes detailed information that will be very useful for implementers >as well as for operators who will deploy the protocol. > >One nit: in section 8.6 s/number of session/number of sessions/ > >Dan > > > > -----Original Message----- > > From: ietf-announce-bounces@ietf.org > > [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG > > Sent: Wednesday, April 16, 2008 11:49 PM > > To: IETF-Announce > > Cc: pce@ietf.org > > Subject: Last Call: draft-ietf-pce-pcep (Path Computation > > Element (PCE) Communication Protocol (PCEP)) to Proposed Standard > > > > The IESG has received a request from the Path Computation Element WG > > (pce) to consider the following document: > > > > - 'Path Computation Element (PCE) Communication Protocol (PCEP) ' > > as a 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 > > 2008-04-30. 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. > > > > The file can be obtained via > > http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-12.txt > > > > > > IESG discussion can be tracked via > > https://datatracker.ietf.org/public/pidtracker.cgi?command=vie > > w_id&dTag=14049&rfc_flag=0 > > > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-announce > > >_______________________________________________ >IETF mailing list >IETF@ietf.org >https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Mon May 5 01:04:48 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EA5F3A6FEE; Mon, 5 May 2008 01:04:48 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AD373A6FEE for ; Mon, 5 May 2008 01:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYnI5xrksVQW for ; Mon, 5 May 2008 01:04:40 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.184]) by core3.amsl.com (Postfix) with ESMTP id C6EE328C255 for ; Mon, 5 May 2008 01:01:29 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so608280tib.25 for ; Mon, 05 May 2008 01:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type; bh=x59bVONZLVy0b41oEQcal8qX817MgVoW6k1N52NJAs0=; b=TeTWtv2e8JLddfJa3rdTy+uxamIAJdUWYpN6pwxWInRSLUUpQmvgD8TUyhkVjPViWPCpagEeAFlhsOsPsbJSi2xjoIxEw9FS2z9XkZ5mstUCx2QFMlGFFtJiEgjHO3s04iVvUsBR9oNRyqhwozsvO0MwqjUO8uFBg1hdJ2bLsws= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type; b=XSj/qjfaQRG/PMiMe5CyRjNF2yuWQr27J9vIW/FlM7GYYrSwWLrOHGA8jUiEkTuS/vx4VBslBx9Q77CToTDb4LLkHC9i2tIgnx2h7J3qqsObClmvTjIG9rOjDqR8MG8E7dTguzamVUMW9gchGcVH5P7dh8HUKw30yfFr+YuEK8Q= Received: by 10.110.84.2 with SMTP id h2mr168167tib.47.1209974487823; Mon, 05 May 2008 01:01:27 -0700 (PDT) Received: by 10.110.52.8 with HTTP; Mon, 5 May 2008 01:01:27 -0700 (PDT) Message-ID: Date: Mon, 5 May 2008 13:31:27 +0530 From: "pavan bhat" To: pce@ietf.org MIME-Version: 1.0 Subject: [Pce] inter area route calculation using multiple pce X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0992737928==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --===============0992737928== Content-Type: multipart/alternative; boundary="----=_Part_13467_542001.1209974487807" ------=_Part_13467_542001.1209974487807 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi , If at all one considers multiple PCE architecture to find a Inter area route ( a route has to be determined from a source in one area to destination in another area) how will PCE know which PCE to select in another area (how to make the decision dynamically ?) as the PCE wii have visibility for its own area only. Thanks Pavan ------=_Part_13467_542001.1209974487807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi ,

If at all one considers multiple PCE architecture to find a Inter area route ( a route  has to be determined from a source in one area to destination in another area) how will PCE know which PCE to select in another area (how to make the decision dynamically ?) as the PCE wii have visibility for its own area only.


Thanks

Pavan
------=_Part_13467_542001.1209974487807-- --===============0992737928== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --===============0992737928==-- From pce-bounces@ietf.org Mon May 5 12:48:13 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D413A28C309; Mon, 5 May 2008 12:48:13 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 799DF28C309 for ; Mon, 5 May 2008 12:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.135 X-Spam-Level: X-Spam-Status: No, score=-3.135 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+5J1UWf8ltg for ; Mon, 5 May 2008 12:48:11 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 0C9D13A6E47 for ; Mon, 5 May 2008 12:47:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,439,1204531200"; d="scan'208,217";a="25335549" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 05 May 2008 12:47:13 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m45Jl9fK016607 for ; Mon, 5 May 2008 12:47:09 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m45Jl9fL000429 for ; Mon, 5 May 2008 19:47:09 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 May 2008 15:47:09 -0400 Received: from 161.44.71.254 ([161.44.71.254]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Mon, 5 May 2008 19:47:09 +0000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Mon, 05 May 2008 15:47:07 -0400 From: JP Vasseur To: Message-ID: Thread-Topic: [Pce] draft-ietf-pce-path-key-02.txt Thread-Index: Acij6QqQrYfthLjuzU2uUbNNulEbZwK/8IiZ In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 05 May 2008 19:47:09.0372 (UTC) FILETIME=[CE1D1FC0:01C8AEE8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3218; t=1210016832; x=1210880832; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce]=20draft-ietf-pce-path-key-02.txt |Sender:=20; bh=mLr7dettH0uW3bncejG/I6C7YLdR3xkxoWNduKLf1Hc=; b=VB6vxCxSjv/2z1i7tK6U/iFFojtf/A8nvYL2hPbDJg+flY3LaPdHirpSxC wRaacjgymw4lDQnaVc19NEbfXn3maYWBzqzVr910erVboH+Ustc1Nw1MBpU9 6clfjFEl6S; Authentication-Results: sj-dkim-3; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Pce] draft-ietf-pce-path-key-02.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0823607097==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0823607097== Content-type: multipart/alternative; boundary="B_3292847228_22075079" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3292847228_22075079 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi, draft-ietf-pce-path-key-02.txt has received a good level of attention in the past and passed Working Last Call with no further comment. We will send the publication request. Thanks. JP. On 4/21/08 3:51 PM, "JP Vasseur" wrote: > Dear WG, > > This starts a two week Working Group Last Call on > draft-ietf-pce-path-key-02.txt that will end on May 4 at noon ET. Please send > your comment to the Mailing List and co-authors. Since both co-chairs are > co-authors (the Editor is Rich Bradford), please feel to indicate to our Area > Directors if you have any concern. > > Thanks. > > JP and Arian. > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce --B_3292847228_22075079 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [Pce] draft-ietf-pce-path-key-02.txt Hi,
 
draft-ietf-pce-path-key-02.txt has received a good level of= attention in the past and passed Working Last Call with no further comment.= We will send the publication request.

Thanks.

JP.



On 4/21/08 3:51 PM, "JP Vasseur" <jvasseur@cisco.com> wrote= :

Dear WG,

This starts a two week Working Group Last Call on draft-ietf-pce-path-key-0= 2.txt that will end on May 4 at noon ET. Please send your comment to the Mai= ling List and co-authors. Since both co-chairs are co-authors (the Editor is= Rich Bradford), please feel to indicate to our Area Directors if you have a= ny concern.
 Thanks.
 JP and Arian.

__________________________= _____________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
--B_3292847228_22075079-- --===============0823607097== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --===============0823607097==-- From pce-bounces@ietf.org Tue May 6 10:45:09 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3102028C414; Tue, 6 May 2008 10:45:09 -0700 (PDT) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7E0CA28C392; Tue, 6 May 2008 10:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080506174501.7E0CA28C392@core3.amsl.com> Date: Tue, 6 May 2008 10:45:01 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-interas-pcecp-reqs-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --NextPart 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 : Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP) Author(s) : N. Bitar Filename : draft-ietf-pce-interas-pcecp-reqs-05.txt Pages : 16 Date : 2008-5-6 Multiprotocol Label Switching Traffic Engineered (MPLS TE) Label Switched Paths (LSPs) may be established wholly within an Autonomous System (AS) or may cross AS boundaries. The Path Computation Element (PCE) is a component that is capable of computing constrained paths for (G)MPLS TE LSPs. The PCE Communication Protocol(PCECP) is defined to allow communication between Path Computation Clients (PCCs) and PCEs, and between PCEs. The PCECP is used to request constrained paths and to supply computed paths in response. Generic requirements for the PCECP are set out in "Path Computation Element(PCE) Communication Protocol Generic Requirements", RFC 4657. This document extends those requirements to cover the use of PCECP in support of inter-AS MPLS TE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-interas-pcecp-reqs-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-interas-pcecp-reqs-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-5-6103750.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@ietf.org Wed May 7 05:45:06 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAA4A3A691B; Wed, 7 May 2008 05:45:04 -0700 (PDT) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5A21E3A6C55; Wed, 7 May 2008 05:45:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080507124501.5A21E3A6C55@core3.amsl.com> Date: Wed, 7 May 2008 05:45:01 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-interas-pcecp-reqs-06.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --NextPart 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 : Inter-AS Requirements for the Path Computation Element Communication Protocol (PCEP) Author(s) : N. Bitar, et al. Filename : draft-ietf-pce-interas-pcecp-reqs-06.txt Pages : 14 Date : 2008-05-07 Multiprotocol Label Switching Traffic Engineered (MPLS TE) Label Switched Paths (LSPs) may be established wholly within an Autonomous System (AS) or may cross AS boundaries. The Path Computation Element (PCE) is a component that is capable of computing constrained paths for (G)MPLS TE LSPs. The PCE Communication Protocol(PCEP) is defined to allow communication between Path Computation Clients (PCCs) and PCEs, and between PCEs. The PCEP is used to request constrained paths and to supply computed paths in response. Generic requirements for the PCEP are set out in "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657. This document extends those requirements to cover the use of PCEP in support of inter-AS MPLS TE.Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-interas-pcecp-reqs-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-interas-pcecp-reqs-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-07053338.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@ietf.org Wed May 7 05:49:13 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B86433A6B63; Wed, 7 May 2008 05:49:13 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12BE53A691B for ; Wed, 7 May 2008 05:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edcDeLSOV7cv for ; Wed, 7 May 2008 05:49:11 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 122F53A6896 for ; Wed, 7 May 2008 05:49:10 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m47Cn7uF021503 for ; Wed, 7 May 2008 13:49:07 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m47Cmwbg021408 for ; Wed, 7 May 2008 13:49:07 +0100 Message-ID: <09ae01c8b040$b26afa50$0400a8c0@your029b8cecfe> From: "Adrian Farrel" To: References: <20080507124501.5A21E3A6C55@core3.amsl.com> Date: Wed, 7 May 2008 13:48:46 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Pce] I-D Action:draft-ietf-pce-interas-pcecp-reqs-06.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi, Changes are just simple formatting issues. Cheers, Adrian ----- Original Message ----- From: >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 : Inter-AS Requirements for the Path Computation Element > Communication Protocol (PCEP) > Author(s) : N. Bitar, et al. > Filename : draft-ietf-pce-interas-pcecp-reqs-06.txt > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-interas-pcecp-reqs-06.txt _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Wed May 7 09:38:24 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E845B28C48F; Wed, 7 May 2008 09:38:24 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D1E328C26E for ; Wed, 7 May 2008 09:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTcdkk5+Yb9z for ; Wed, 7 May 2008 09:38:22 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 383273A6BF9 for ; Wed, 7 May 2008 09:33:07 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m47GX2l3006694; Wed, 7 May 2008 17:33:02 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m47GWucA006668; Wed, 7 May 2008 17:33:02 +0100 Message-ID: <0a1f01c8b05f$fb87ecb0$0400a8c0@your029b8cecfe> From: "Adrian Farrel" To: References: <02f501c893fe$94f30570$0300a8c0@your029b8cecfe> <023101c8a536$22cff450$0300a8c0@your029b8cecfe> Date: Wed, 7 May 2008 17:32:33 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: pce@ietf.org Subject: Re: [Pce] Quesitons about OF draft X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi Jean-Louis, Sorry for a long delay in closing this down... Summary, if you (and the WG) agree the two points below are unimportant, we are done. A >>Soooo. >>I was assuming that you may need: >>- an OF to apply to the set of synchornized requests >>- an OF to apply to each of the requests > > Yes this is what we need. Maybe we need to clarify the terminology, here > by > "set of synchronized requests" we mean the set of requests listed in a > SVEC. OK, I think the confusion here is that the PCReq carries the following structure... ::= [] where: ::=[] ::=[] = set of request IDs That is, is a list of lists. So, now we have three things to which we might apply an OF: 1. An individual request 2. All of the requests in an SVEC object 3. All of the requests in an SVEC list. In your I-D, you have... ::= [] where: ::= [] [] ::=[] ::= [] etc. So you have covered case 1 and case 2. You don't appear to have covered case 3. >>What you appear to have is: >>- an OF to apply to each synchronized request >> through the OF in the SVEC-list > > That is it applies to the set of synchronized requests listed in an SVEC > object. > >>- an OF to apply to each of the requests >> through the OF in the request > >> It seems to me that you do not have the ability to supply a meta-OF that >> applies to the whole SVEC-list, but you have two separate ways >> to supply an OF for each request. > > We have the ability to supply an OF for the set of requests listed in an > SVEC object, and to supply an OF for each request. This is what is > required. Now, I may be wrong, but the SVEC says "please synchronize all requests listed in this SVEC object." And the point of having multiple SVEC objects (i.e. an SVEC list) is to allow multiple synchornizations to be made. If you are saying that there is never any need to apply an OF across multiple (i.e. all) SVECs in the SVEC list (and assuming no-one disagrees), then we are done. Cheers, Adrian >>>> Now, suppose the request desires (not requires) an OF, and >>>> the response says No-Path. Shouldn't the response also say >>>> which OF was used to produce this result? >>> >>> Strictly speaking the reason for no path is never an >>> objective function, the reason is a constraint. >> >>Yes, that is very true. >> >>But, nevertheless, isn't it helpful to report the OF that was used? > > We used to have it in an earlier version. Fabien asked to remove it and > indeed > we did not find any good reason to keep it. > Knowing the OF that was used would not really help the PCC as there is no > path whatever the OF applied.... Well... The PCE's free choice of an OF may lead it to fail to find a path where if the PCC controlled that choice of OF (by specifying it) a path would be found. Obviously, the PCC can only usefully specify the OF on the PCReq retry if it knows which OF was used the first time. Maybe can introduce this again in a later I-D when we see that it is of benefit, although it doesn't seem so expensive to include it as optional in this I-D. Cheers, Adrian _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Thu May 8 08:22:26 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C253728D0E8; Thu, 8 May 2008 08:21:42 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 256E428D771 for ; Thu, 8 May 2008 08:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=-0.579, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPOLCIKm9eXp for ; Thu, 8 May 2008 08:21:07 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 9DDFC28D145 for ; Thu, 8 May 2008 06:49:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,454,1204520400"; d="scan'208,217";a="7653156" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 08 May 2008 08:15:30 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m48CFU9A028728; Thu, 8 May 2008 08:15:30 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m48CFU7A010065; Thu, 8 May 2008 12:15:30 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 May 2008 08:15:30 -0400 Received: from 161.44.71.254 ([161.44.71.254]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 8 May 2008 12:15:29 +0000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Thu, 08 May 2008 08:15:27 -0400 From: JP Vasseur To: Message-ID: Thread-Topic: Publication Request for draft-ietf-pce-interas-pcecp-reqs-06.txt Thread-Index: AcixBTMU8+gbKbyd7EqBTd4Tl0O08g== Mime-version: 1.0 X-OriginalArrivalTime: 08 May 2008 12:15:30.0149 (UTC) FILETIME=[34F51950:01C8B105] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=23898; t=1210248930; x=1211112930; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Publication=20Request=20for=20draft-ietf-pce-in teras-pcecp-reqs-06.txt |Sender:=20 |To:=20; bh=LMTMQvR0xugBzGWB7k/zccoIE1o0p8VfJXWiB2+v4g0=; b=KtvXjahouiP5gycLaxetwkJT5kA0ZHnmwQiS9mJ3Laz5EJFc02CEHLr1am 80jZyki9iazEdDIEoN04z/efM9FMAzzVevIsWOPt4fmGNnKVGL+FiTH1njHV onemUaLDBT; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: "nabil.n.bitar@verizon.com" , Raymond_zhang@bt.com, pce@ietf.org, David Ward , Kenji Kumaki Subject: [Pce] Publication Request for draft-ietf-pce-interas-pcecp-reqs-06.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0624386323==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0624386323== Content-type: multipart/alternative; boundary="B_3293079328_30380789" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3293079328_30380789 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Ross, Here is the proto write-up for draft-ietf-pce-interas-pcecp-reqs-06.txt Intended status : Informational Track > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? JP Vasseur is the document shepherd. Both co-chairs (JP Vasseur and Adrian Farrel) have reviewed the document. They think that the document is ready to be forwarded to the IESG for publication. > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? The document has been discussed and reviewed by several key WG members. Further, Sandy Murphy from the Security Directorate made a thorough review of the document (http://www.ietf.org/mail-archive/web/pce/current/msg01393.html) and Adrian Farrel has worked with the authors to address the comments. > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? No concerns. > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. No specific concern about this document. The requirements expressed in this document had a good support in the WG and complement the generic requirements for the PCECP defined in RFC4657. There was no filed IPR disclosure related to this document. > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? Good consensus. No concern or additional comments received during WG Last Call. > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) No threats. No discontent. > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? The Document has been checked. > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. References split. No downrefs. > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC2434]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? This document makes no requests for IANA action > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? No such formal language is used. > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up. Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: > > Technical Summary > Relevant content can frequently be found in the abstract > and/or introduction of the document. If not, this may be > an indication that there are deficiencies in the abstract > or introduction. [RFC4216] defines the scenarios motivating the deployment of inter-AS Multiprotocol Label Switching Traffic Engineering (MPLS TE) and specifies the requirements for inter-AS MPLS TE when the ASes are under the administration of one Service Provider (SP) or the administration of different SPs. Three signaling options are defined for setting up an inter-AS TE LSP: 1) contiguous TE LSP as documented in [RFC5151]; 2) stitched inter-AS TE LSP discussed in [RFC5150]; 3) nested TE LSP as in [RFC4206]. [RFC5152] defines mechanisms for the computation of inter-domain TE Label Switched Paths (LSPs) using network elements along the signaling paths to compute per-domain constrained path segments. The mechanisms in [RFC5152] do not guarantee an optimum constrained path across multiple ASes where an optimum path for an TE LSP is one that has the smallest cost, according to a normalized TE metric (based upon a TE metric or Interior Gateway Protocol (IGP) metric adopted in each transit AS) among all possible paths that satisfy the LSP TE constraints. The Path Computation Element (PCE) [RFC4655] is a component that is capable of computing paths for MPLS TE and Generalized Multiprotcol Label Switching Protocol ((G)MPLS TE) LSPs. The requirements for a PCE have come from SP demands to compute optimum constrained paths across multiple areas and/or domains, and to be able to separate the path computation elements from the forwarding elements. The PCE Communication Protocol (PCEP) is defined to allow communication between Path Computation Clients (PCCs) and PCEs, and between PCEs. The PCEP is used to request (G)MPLS TE paths and to supply computed paths in response. Generic requirements for the PCEP are discussed in [RFC4657]. This document provides a set of PCEP requirements that are specific to inter-AS (G)MPLS TE path computation. > Working Group Summary > Was there anything in WG process that is worth noting? For > example, was there controversy about particular points or > were there decisions where the consensus was particularly > rough? The PCE WG has good consensus with no disagreement. > Document Quality > Are there existing implementations of the protocol? Have a > significant number of vendors indicated their plan to > implement the specification? Are there any reviewers that > merit special mention as having done a thorough review, > e.g., one that resulted in important changes or a > conclusion that the document had no substantive issues? If > there was a MIB Doctor, Media Type or other expert review, > what was its course (briefly)? In the case of a Media Type > review, on what date was the request posted? draft-ietf-pce-interas-pcecp-reqs-06.txt is a requirement document. --B_3293079328_30380789 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Publication Request for draft-ietf-pce-interas-pcecp-reqs-06.txt</TI= TLE> </HEAD> <BODY> <FONT SIZE=3D"4"><FONT FACE=3D"Consolas, Courier New, Courier"><SPAN STYLE=3D'fon= t-size:10pt'>Hi Ross,<BR> <BR> Here is the proto write-up for draft-ietf-pce-interas-pcecp-reqs-06.txt<BR> <BR> Intended status : Informational Track<BR> <BR> > (1.a)  Who is the Document Shepherd for this document?  Has = the<BR> >        Document Shepherd personally= reviewed this version of the<BR> >        document and, in particular,= does he or she believe this<BR> >        version is ready for forward= ing to the IESG for publication?<BR> <BR> JP Vasseur is the document shepherd. Both co-chairs (JP Vasseur and Adrian = Farrel) have reviewed the document. They think that the document is ready to= be forwarded to the IESG for publication.<BR> <BR> > (1.b)  Has the document had adequate review both from key WG memb= ers<BR> >        and from key non-WG members?=  Does the Document Shepherd have<BR> >        any concerns about the depth= or breadth of the reviews that<BR> >        have been performed?<BR> <BR> <BR> The document has been discussed and reviewed by several key WG members. Fur= ther, Sandy Murphy from the Security Directorate made a thorough review of t= he document (<a href=3D"http://www.ietf.org/mail-archive/web/pce/current/msg01= 393.html)">http://www.ietf.org/mail-archive/web/pce/current/msg01393.html)</= a> and Adrian Farrel has worked with the authors to address the comments.<BR= > <BR> > (1.c)  Does the Document Shepherd have concerns that the document= <BR> >        needs more review from a par= ticular or broader perspective,<BR> >        e.g., security, operational = complexity, someone familiar with<BR> >        AAA, internationalization or= XML?<BR> <BR> No concerns.<BR> <BR> > (1.d)  Does the Document Shepherd have any specific concerns or<B= R> >        issues with this document th= at the Responsible Area Director<BR> >        and/or the IESG should be aw= are of?  For example, perhaps he<BR> >        or she is uncomfortable with= certain parts of the document, or<BR> >        has concerns whether there r= eally is a need for it.  In any<BR> >        event, if the WG has discuss= ed those issues and has indicated<BR> >        that it still wishes to adva= nce the document, detail those<BR> >        concerns here.  Has an = IPR disclosure related to this document<BR> >        been filed?  If so, ple= ase include a reference to the<BR> >        disclosure and summarize the= WG discussion and conclusion on<BR> >        this issue.<BR> <BR> No specific concern about this document. The requirements expressed in this= document had a good support in the WG and complement the generic requiremen= ts for the PCECP defined in RFC4657.<BR> <BR> There was no filed IPR disclosure related to this document. <BR> <BR> > (1.e)  How solid is the WG consensus behind this document?  = Does it<BR> >        represent the strong concurr= ence of a few individuals, with<BR> >        others being silent, or does= the WG as a whole understand and<BR> >        agree with it?<BR> <BR> Good consensus. No concern or additional comments received during WG Last C= all.<BR> <BR> > (1.f)  Has anyone threatened an appeal or otherwise indicated ext= reme<BR> >        discontent?  If so, ple= ase summarise the areas of conflict in<BR> >        separate email messages to t= he Responsible Area Director.  (It<BR> >        should be in a separate emai= l because this questionnaire is<BR> >        entered into the ID Tracker.= )<BR> <BR> No threats. No discontent.<BR> <BR> > (1.g)  Has the Document Shepherd personally verified that the<BR> >        document satisfies all ID ni= ts?  (See<BR> >        <FONT COLOR=3D"#0000FF"><U><a = href=3D"http://www.ietf.org/ID-Checklist.html">http://www.ietf.org/ID-Checklis= t.html</a></U></FONT> and<BR> >        <FONT COLOR=3D"#0000FF"><U><a = href=3D"http://tools.ietf.org/tools/idnits/)">http://tools.ietf.org/tools/idni= ts/)</a></U></FONT>.  Boilerplate checks are<BR> >        not enough; this check needs= to be thorough.  Has the document<BR> >        met all formal review criter= ia it needs to, such as the MIB<BR> >        Doctor, media type and URI t= ype reviews?<BR> <BR> The Document has been checked.<BR> <BR> > (1.h)  Has the document split its references into normative and<B= R> >        informative?  Are there= normative references to documents that<BR> >        are not ready for advancemen= t or are otherwise in an unclear<BR> >        state?  If such normati= ve references exist, what is the<BR> >        strategy for their completio= n?  Are there normative references<BR> >        that are downward references= , as described in [RFC3967]?  If<BR> >        so, list these downward refe= rences to support the Area<BR> >        Director in the Last Call pr= ocedure for them [RFC3967].<BR> <BR> References split.<BR> No downrefs.<BR> <BR> > (1.i)  Has the Document Shepherd verified that the document IANA<= BR> >        consideration section exists= and is consistent with the body<BR> >        of the document?  If th= e document specifies protocol<BR> >        extensions, are reservations= requested in appropriate IANA<BR> >        registries?  Are the IA= NA registries clearly identified?  If<BR> >        the document creates a new r= egistry, does it define the<BR> >        proposed initial contents of= the registry and an allocation<BR> >        procedure for future registr= ations?  Does it suggest a<BR> >        reasonable name for the new = registry?  See [RFC2434].  If the<BR> >        document describes an Expert= Review process has Shepherd<BR> >        conferred with the Responsib= le Area Director so that the IESG<BR> >        can appoint the needed Exper= t during the IESG Evaluation?<BR> <BR> </SPAN></FONT><SPAN STYLE=3D'font-size:10pt'><FONT FACE=3D"Courier, Courier New= ">This document makes no requests for IANA action<BR> </FONT><FONT FACE=3D"Consolas, Courier New, Courier"><BR> > (1.j)  Has the Document Shepherd verified that sections of the<BR= > >        document that are written in= a formal language, such as XML<BR> >        code, BNF rules, MIB definit= ions, etc., validate correctly in<BR> >        an automated checker?<BR> <BR> No such formal language is used.<BR> <BR> > (1.k)  The IESG approval announcement includes a Document<BR> >        Announcement Write-Up.  = ;Please provide such a Document<BR> >        Announcement Write-Up.  = ;Recent examples can be found in the<BR> >        "Action" announcem= ents for approved documents.  The approval<BR> >        announcement contains the fo= llowing sections:<BR> ><BR> >        Technical Summary<BR> >           Relevant c= ontent can frequently be found in the abstract<BR> >           and/or int= roduction of the document.  If not, this may be<BR> >           an indicat= ion that there are deficiencies in the abstract<BR> >           or introdu= ction.<BR> <BR> [RFC4216] defines the scenarios motivating the deployment of inter-AS<BR>    Multiprotocol Label Switching Traffic Engineering (MPLS T= E) and<BR>    specifies the requirements for inter-AS MPLS TE when the = ASes are<BR>    under the administration of one Service Provider (SP) or = the<BR>    administration of different SPs.<BR> <BR>    Three signaling options are defined for setting up an int= er-AS TE<BR>    LSP:<BR>        1) contiguous TE LSP as documente= d in [RFC5151];<BR>        2) stitched inter-AS TE LSP discu= ssed in [RFC5150];<BR>        3) nested TE LSP as in [RFC4206].= <BR> <BR>    [RFC5152] defines mechanisms for the computation of inter= -domain TE<BR>    Label Switched Paths (LSPs) using network elements along = the<BR>    signaling paths to compute per-domain constrained path se= gments. The<BR>    mechanisms in [RFC5152] do not guarantee an optimum const= rained path<BR>    across multiple ASes where an optimum path for an TE LSP = is one that<BR>    has the smallest cost, according to a normalized TE metri= c (based<BR>    upon a TE metric or Interior Gateway Protocol (IGP) metri= c adopted<BR>    in each transit AS) among all possible paths that satisfy= the LSP TE<BR>    constraints.<BR> <BR>    The Path Computation Element (PCE) [RFC4655] is a compone= nt that is<BR>    capable of computing paths for MPLS TE and Generalized Mu= ltiprotcol<BR>    Label Switching Protocol ((G)MPLS TE) LSPs. The requireme= nts for a<BR>    PCE have come from SP demands to compute optimum constrai= ned paths<BR>    across multiple areas and/or domains, and to be able to s= eparate the<BR>    path computation elements from the forwarding elements.<B= R> <BR>    The PCE Communication Protocol (PCEP) is defined to allow= <BR>    communication between Path Computation Clients (PCCs) and= PCEs, and<BR>    between PCEs. The PCEP is used to request (G)MPLS TE path= s and to<BR>    supply computed paths in response. Generic requirements f= or the<BR>    PCEP are discussed in [RFC4657]. This document provides a= set of<BR>    PCEP requirements that are specific to inter-AS (G)MPLS T= E path<BR>    computation.<BR> <BR> >        Working Group Summary<BR> >           Was there = anything in WG process that is worth noting?  For<BR> >           example, w= as there controversy about particular points or<BR> >           were there= decisions where the consensus was particularly<BR> >           rough?<BR> <BR> The PCE WG has good consensus with no disagreement.<BR> <BR> <BR> >        Document Quality<BR> >           Are there = existing implementations of the protocol?  Have a<BR> >           significan= t number of vendors indicated their plan to<BR> >           implement = the specification?  Are there any reviewers that<BR> >           merit spec= ial mention as having done a thorough review,<BR> >           e.g., one = that resulted in important changes or a<BR> >           conclusion= that the document had no substantive issues?  If<BR> >           there was = a MIB Doctor, Media Type or other expert review,<BR> >           what was i= ts course (briefly)?  In the case of a Media Type<BR> >           review, on= what date was the request posted?<BR> <BR> draft-ietf-pce-interas-pcecp-reqs-06.txt is a requirement document.<BR> <BR> <BR> </FONT></SPAN></FONT> </BODY> </HTML> --B_3293079328_30380789-- --===============0624386323== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --===============0624386323==-- From pce-bounces@ietf.org Mon May 12 03:48:14 2008 Return-Path: <pce-bounces@ietf.org> X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DCB03A680D; Mon, 12 May 2008 03:48:14 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58C4A3A680D for <pce@core3.amsl.com>; Mon, 12 May 2008 03:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqJ0U8NOMuCJ for <pce@core3.amsl.com>; Mon, 12 May 2008 03:48:11 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 480643A67F9 for <pce@ietf.org>; Mon, 12 May 2008 03:48:11 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m4CAlLpl029355 for <pce@ietf.org>; Mon, 12 May 2008 11:47:21 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m4CAlIDr029267 for <pce@ietf.org>; Mon, 12 May 2008 11:47:20 +0100 Message-ID: <037d01c8b41d$85124f00$0200a8c0@your029b8cecfe> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <pce@ietf.org> Date: Mon, 12 May 2008 11:46:38 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [Pce] Fw: I-D Action:draft-yasukawa-pce-p2mp-req-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel <adrian@olddog.co.uk> List-Id: Path Computation Element <pce.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/pce> List-Post: <mailto:pce@ietf.org> List-Help: <mailto:pce-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi PCE, We are keeping this I-D alive pending the update to the charter to include P2MP. In this version, we have just made a few small changes to the text for clarity. Thanks, Adrian ----- Original Message ----- From: <Internet-Drafts@ietf.org> To: <i-d-announce@ietf.org> Sent: Monday, May 12, 2008 11:15 AM Subject: I-D Action:draft-yasukawa-pce-p2mp-req-05.txt >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : PCC-PCE Communication Requirements for Point to > Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE) > Author(s) : S. Yasukawa, A. Farrel > Filename : draft-yasukawa-pce-p2mp-req-05.txt > Pages : 10 > Date : 2008-05-12 > > The Path Computation Element (PCE) provides path computation > functions in support of traffic engineering in Multi-Protocol Label > Switching (MPLS) and Generalized MPLS (GMPLS) networks. > > Extensions to the MPLS and GMPLS signaling and routing protocols have > been made in support of point-to-multipoint (P2MP) Traffic Engineered > (TE) Label Switched Paths (LSPs). The use of PCE in MPLS networks is > already established, and since P2MP TE LSP routes are sometimes > complex to compute, it is likely that PCE will be used for P2MP LSPs. > > Generic requirements for a communication protocol between Path > Computation Clients (PCCs) and PCEs are presented in "Path > Computation Element (PCE) Communication Protocol Generic > Requirements". This document complements the generic requirements and > presents a detailed set of PCC-PCE communication protocol > requirements for point-to-multipoint MPLS/GMPLS traffic engineering. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-yasukawa-pce-p2mp-req-05.txt _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Mon May 12 14:30:03 2008 Return-Path: <pce-bounces@ietf.org> X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E452A28C2B0; Mon, 12 May 2008 14:30:03 -0700 (PDT) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 340C028C28A; Mon, 12 May 2008 14:30:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080512213001.340C028C28A@core3.amsl.com> Date: Mon, 12 May 2008 14:30:01 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-path-key-03.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element <pce.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/pce> List-Post: <mailto:pce@ietf.org> List-Help: <mailto:pce-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe> Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --NextPart 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 : Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Key-Based Mechanism Author(s) : R. Bradford, J. Vasseur Filename : draft-ietf-pce-path-key-03.txt Pages : 19 Date : 2008-5-12 Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. However, in some cases (e.g., when ASes are administered by separate Service Providers), it would break confidentiality rules for a PCE to supply a path segment to a PCE in another domain, thus disclosing AS-internal topology information. This issue may be circumvented by returning a loose hop and by invoking a new path computation from the domain boundary Label Switching Router (LSR) during TE LSP setup as the signaling message enters the second domain, but this technique has several issues including the problem of maintaining path diversity. This document defines a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS). The CPS may be replaced by a path-key that can be conveyed in the PCE Communication Protocol (PCEP) and signaled within in a Resource Reservation Protocol TE (RSVP-TE) explicit route object. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-path-key-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-path-key-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-5-12142623.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@ietf.org Tue May 13 18:37:51 2008 Return-Path: <pce-bounces@ietf.org> X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B38028C2E8; Tue, 13 May 2008 18:37:51 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7661C28C2E8; Tue, 13 May 2008 18:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.989 X-Spam-Level: X-Spam-Status: No, score=0.989 tagged_above=-999 required=5 tests=[AWL=-0.779, BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4jbdcCFqz8r; Tue, 13 May 2008 18:37:46 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by core3.amsl.com (Postfix) with ESMTP id 9DA9C28C2E5; Tue, 13 May 2008 18:37:46 -0700 (PDT) Received: from mailgate3.nec.co.jp (mailgate54.nec.co.jp [10.7.69.197]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id m4E1bkOJ006702; Wed, 14 May 2008 10:37:46 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id m4E1bk827753; Wed, 14 May 2008 10:37:46 +0900 (JST) Received: from shoin.jp.nec.com (shoin.jp.nec.com [10.26.220.3]) by mailsv3.nec.co.jp (8.13.8/8.13.4) with ESMTP id m4E1bk3l013924; Wed, 14 May 2008 10:37:46 +0900 (JST) Received: from arakidsk ([10.56.131.136] [10.56.131.136]) by mail.jp.nec.com with ESMTP; Wed, 14 May 2008 10:37:45 +0900 From: "Soichiro Araki" <s-araki@cj.jp.nec.com> To: <ccamp@ops.ietf.org>, <pce@ietf.org>, <mpls@ietf.org>, <l1vpn@ietf.org> Date: Wed, 14 May 2008 10:37:53 +0900 Organization: NEC Corp. Message-Id: <002d01c8b563$20945180$8883380a@nsl.ad.nec.co.jp> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Aci0iuWQmOlMAus8TZGRvUr4IXtYTwA1s1jA Cc: ipop2008-CFP@pilab.jp Subject: [Pce] Call for PARTICIPATION - 4th InternationalConference on IP + Optical Network (iPOP 2008) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element <pce.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/pce> List-Post: <mailto:pce@ietf.org> List-Help: <mailto:pce-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe> Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ [Our apologies if you receive multiple copies of this message] ***************************************************************** * CALL FOR PARTICIPATION * * * * Conference on IP + Optical Network (iPOP208) * * http://www.ipop2008.com/ * * * * June 5-6, 2008 Tokyo, Japan * * * * Participation fee: free * * * * Please register through * * http://www.pilab.jp/ipop2008/registration/index.html * ***************************************************************** ----------------------------------------------------------------------------- Technical Sessions ----------------------------------------------------------------------------- Day 1 (June 5, 2008) ----------------------------------------------------------------------------- Tech. Session 1: ASON Chair: Kireeti Kompella, Juniper, USA o "Control Plane Resilience and Security in GMPLS Networks : Fact and Fiction," Adrian Farrel (Old Dog Consulting, UK) o "e2e GMPLS P&R with next generation interface for the green networking," Hidetsugu Sugiyama (Juniper Networks, Japan) o "Automated End-to-end Circuit Provisioning for high bandwidth demand applications: the challenges and our experiences in 3TNet," Weiqiang Sun, Guowu Xie, Yaohui Jin, Wei Guo and Weisheng Hu (Shanghai Jiao Tong University, P. R. China) ----------------------------------------------------------------------------- Tech. Session 2: WSON Chair: Wataru Imajuku, NTT, Japan o "GMPLS Extensions in Support of All-optical Networking," Hongxiang Guo, Takehiro Tsuritani, Noboru Yoshikane, Tomohiro Otani (KDDI R&D, Japan) o "Optical Reach Computation with GMPLS," Snigdho Bardalai, Richard Colter, Sugiya Hideaki, Fred Gruman, Mike White, Sanjay Gera (Fujitsu, USA) o "GMPLS perspectives to control WSON," Pierre Peloso, Benoit RONOT, Martin VIGOUREUX, Richard DOUVILLE (Alcatel-Lucent, France) o "Wavelength Switched Optical Networks with Distributed Control," Hiroaki Harai and Sugang Xu (NICT, Japan) ----------------------------------------------------------------------------- Day 2 (June 6, 2008) ----------------------------------------------------------------------------- Tech. Session 3: PCE Chair: Young Lee, Huawei, USA o "Inter-Carrier PCE-Based Path Computation in Keihanna Interoperablity Project" Tomonori Takeda, Eiji Oki (NTT, Japan), Yohei Iizawa, Itaru Nishioka (NEC, Japan), Machiko Asaie, Kazuhiro Kusama (Hitachi, Japan), Shuichi Okamoto, and Tomohiro Otani (KDDI R&D, Japan) o "End-to-End path routing with PCEs in multi-domain GMPLS networks" Itaru Nishioka, Shinya Ishida, Yohei Iizawa (NEC, Japan) o "Path Computation Issues and Solutions in Wavelength Switched Optical Networks (WSON)" Young Lee (Huawei, USA), Greg Bernstein (Grotto Networks, USA), Daniel King (Aria-Networks, UK) o "Deploying Advanced Path Computation Technologies for Optical Transport Networks," Daniel King (Aria Networks, UK), Takehiro Tsuritani (KDDI R&D, Japan) ----------------------------------------------------------------------------- Tech. Session 4: GELS Chair: Don Fedyk, Nortel, USA o "Experimenting with GMPLS to control a PBB-TE network" Benoit Tremblay, Attila Takacs, Howard Green (Ericsson Research, Canada) o "Employing GMPLS control for PBB-TE networks" Don Fedyk (Nortel, USA) o "Example of a GMPLS control plane interconnected with an Ethernet data plane in a rack-mounted prototype" A. Dupas, R. Boislaigue, C. Cosse-maniere, G.Post, M. Lorret (Alcatel-lucent Bell-labs, France) ----------------------------------------------------------------------------- Tech. Session 5: OAM Chair: Adrian Farrel, Old Dog Consulting, UK o "Design, implementation and validation within ADRENALINER testbed of a Path Computation Element for Wavelength Switched Optical Networks," Ramon Casellas, Ricardo Martinez, Raul Munoz (CTTC, Spain) o "GMPLS OAM Tool Kit" Zafar Ali, Roberto Cassata, (Cisco, USA), T. Otani, (KDDI R&D, Japan), Marco Anisetti, Valerio Bellandi, Ernesto Damiani, Francesco Diana, Umberto Raimondi (University of Milan, Italy) o "Lessons learned from operational experience on the JGN II GMPLS network test bed" S. Okamoto and T. Otani (KDDI R&D, Japan) o "Service and Architecture of GMPLS-Controlled Photonic Internet Exchange" Yoshiaki Sone, Wataru Imajuku, Ippei Shake, Kazuhiro Matsuda (NTT, Japan), Tomohiko Kurahashi, Junichi Shimagami, Toshiya Asaba, (IIJ, Japan), Yukiyasu Tarui, Nobuhisa Miyake, Katsuyasu Toyama (Internet Multifeed, Japan) ----------------------------------------------------------------------------- Tech. Session 6: MLN Chair: Tomohiro Otani, KDDI R&D, Japan o "Is SRLG Optimization a Business Case for GMPLS Deployment?" Stefan Schnitter, Martin Horneffer (Deutsche Telekom, Germany) o "GMPLS based Multi Layer Service Network Architecture and Layer 1 On Demand Service Resource Management" Ichiro Inoue, Kaori Shimizu, Rie Hayashi, Hisashi Kojima, Kohei Shiomoto, (NTT, Japan), Shigeo Urushidani (NII, Japan) o "Next Steps for Deploying Multi-layer Traffic Engineered Networks" Steve West (Cyan Optics, USA), Peter Willis (BT, UK), Daniel King (Aria Networks, UK) ----------------------------------------------------------------------------- Poster Session ----------------------------------------------------------------------------- Day 1 (June 5, 2008) ----------------------------------------------------------------------------- Poster Session Chair: Ernesto Damiani, University of Milan, Italy o "Optical Fast Reroute," Adrian Farrel (Old Dog Consulting, UK) o "GMPLS VLAN Path Establishment using Inter-domain VLAN Tag Swapping," Kou Kikuta, Masahiro Nishida, Daisuke Ishii, Satoru Okamoto, Naoaki Yamanaka (KEIO University, Japan) o "Chromatic Dispersion Compensation Control in Dynamically Reconfigurable All-Optical Networks," Eiichi Horiuchi, Misato Kamei, Shoichiro Seno, and Yoshimasa Baba (Mitsubishi Electric Corporation, Japan) o "IGP Extentension for RWA in WSON," Jianrui Han, Dan Li, Jianhua Gao, Young Lee (Huawei Technologies, P.R.China) o "Establishing Inter-domain services," Richard Douville, Helia Pouyllau (Alcatel-lucent Bell-labs, France) o "SShared Backup Mesh Protection in PCE-based WSON networks," Greg Bernstein (Grotto Networks, USA), Young Lee (Huawei, USA) o "P2MP Path Computation & Operation in MPLS & Optical Networks," Quintin Zhao (Huawei, USA), Daniel King (Aria Networks, UK), Fabien Verhaeghe (Marben, France), Tomonori Takeda (NTT, Japan) ----------------------------------------------------------------------------- Exhibition ----------------------------------------------------------------------------- o Exhibition participants Keio University KDDI Laboratories NTT NICT NEC Anritsu ISOCORE Tokyo University Juniper Networks OIF Infinera Tellabs o Showcase Participants Kei-han-na Open Lab Lambda UTILITY ------------------------------------------------------------------------------- Sponsors ------------------------------------------------------------------------------- o Sponsored by Photonic Internet Lab. (http://www.pilab.jp) ISOCORE (http://www.isocore.com$B!K(B o Supported by Photonic Internet Forum (http://www.scat.or.jp/photonic/$B!K(B Kei-han-na Open Lab (http://www.khn-openlab.jp/bunkakai-gw/kokino-net/sousetsu/index-j.html) Council for Info-Communication Promotions Month(http://www.jtgkn.com/) *iPOP2008 is an Event of Info-Communication Promotions Month ------------------------------------------------------------------------------- Best regards, -Soichiro Araki Organization Committee Co-Chair, iPOP 2008 http://www.ipop2008.com/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Soichiro ARAKI System Platforms Research Laboratories, NEC Corporation E-mail: s-araki@cj.jp.nec.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Fri May 16 15:16:01 2008 Return-Path: <pce-bounces@ietf.org> X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDEB83A6BC7; Fri, 16 May 2008 15:16:01 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 305B63A6BC7; Fri, 16 May 2008 15:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.404 X-Spam-Level: X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CWMGKhhs0JW; Fri, 16 May 2008 15:15:57 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 348543A6908; Fri, 16 May 2008 15:15:54 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m4GMFZfG027337; Fri, 16 May 2008 23:15:37 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m4GMFXU4027330; Fri, 16 May 2008 23:15:34 +0100 Message-ID: <01b101c8b7a2$599a5290$0200a8c0@your029b8cecfe> From: "Adrian Farrel" <adrian@olddog.co.uk> To: "Ross Callon" <rcallon@juniper.net> Date: Fri, 16 May 2008 23:15:25 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: iesg-secretary@iesg.org, pce@ietf.org, dward@cisco.com Subject: [Pce] Please publish draft-ietf-pce-path-key-03.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel <adrian@olddog.co.uk> List-Id: Path Computation Element <pce.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/pce> List-Post: <mailto:pce@ietf.org> List-Help: <mailto:pce-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Proto-write-up for draft-ietf-pce-path-key-03.txt Intended status : Standards Track > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? Adrian Farrel is the document shepherd. He has personally reviewed the I-D and believes it is ready for forwarding to the IESG for publication. Please note that the document shepherd is also an author of this I-D. Both PCE working group chairs are authors of this document although the editor is a third party. > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? I-D has had a good level of discussions and review in the PCE working group. The most debate took place with early revisions when there were some choices to be made. No concerns about the level of review. > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? No concerns. > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. The document is sound. An IPR disclosure can be found at https://datatracker.ietf.org/ipr/871/ This disclosure was made as soon as the I-D became a working group draft, and was brought to the attention of the working group at once. There was no objection made on the mailing list to continuing with the draft. > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? Consensus is good. WG last call issues were limited to editorial and minor functional nits. > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) No threats. No discontent. > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? All checks made. > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. References split. No downrefs. > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC2434]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? The document defines small protocol enhancements to PCEP. The PCEP specification is progressing through the IESG approval process and no IANA registry has yet been created. Nevertheless, this I-D requests further allocations from the PCEP registry that IANA will create and manage. The IANA section of this I-D uses the same language as the PCEP specification and, in particular, uses the same sub-registry names. Further, to help ensure consistent allocation of protocol codepoints, a temporary (non-definitive) registry is maintained at www.olddog.co.uk/pcep-codepoints.txt > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? No such formal language is used. The message formats are described in relatively simple BNF. No automated checker has been used. Note that the symbol "|" is used to denote an alternative whereas RFC 5234 specifies the use of "/". This choice was made deliberately as the "|" symbol is found in related RFCs (e.g. RFCs 2205, 3209, 3473) and the base PCEP specification. > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up. Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: > > Technical Summary > Relevant content can frequently be found in the abstract > and/or introduction of the document. If not, this may be > an indication that there are deficiencies in the abstract > or introduction. Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. However, in some cases (e.g., when ASes are administered by separate Service Providers), it would break confidentiality rules for one PCE to supply a path segment to a PCE in another domain, thus disclosing AS-internal topology information. This issue may be circumvented by returning a loose hop and by invoking a new path computation from the domain boundary Label Switching Router (LSR) during TE LSP setup as the signaling message enters the second domain, but this technique has several issues including the problem of maintaining path diversity. This document defines a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS). The CPS may be replaced by a path-key that can be conveyed in the PCE Communication Protocol (PCEP) and signaled within in a Resource Reservation Protocol TE (RSVP-TE) explicit route object. Note that a separate draft in the CCAMP working group (draft-ietf-ccamp- path-key-ero) describes the use of this feature in RSVP-TE. > Working Group Summary > Was there anything in WG process that is worth noting? For > example, was there controversy about particular points or > were there decisions where the consensus was particularly > rough? WG has good consensus with no disputes or disagreements. An IPR disclosure has been filed, but the WG has decided to proceed with this I-D. > Document Quality > Are there existing implementations of the protocol? Have a > significant number of vendors indicated their plan to > implement the specification? Are there any reviewers that > merit special mention as having done a thorough review, > e.g., one that resulted in important changes or a > conclusion that the document had no substantive issues? If > there was a MIB Doctor, Media Type or other expert review, > what was its course (briefly)? In the case of a Media Type > review, on what date was the request posted? An informal, private survey has revealed one implementation of the PCEP extensions defined in this document with two implementations in the pipe-line. Given how small the protocol extensions defined in this document are, it is considered that proceeding on the basis of one implementation is OK. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From taxrefund@4x4c.7xdb35d8.irs.gov Tue May 20 20:52:32 2008 Return-Path: <taxrefund@4x4c.7xdb35d8.irs.gov> X-Original-To: ietfarch-pce-archive@core3.amsl.com Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 439093A6F48 for <ietfarch-pce-archive@core3.amsl.com>; Tue, 20 May 2008 20:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -91.213 X-Spam-Level: X-Spam-Status: No, score=-91.213 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FORGED_MUA_OUTLOOK=3.116, HELO_EQ_DE=0.35, MSOE_MID_WRONG_CASE=0.82, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, SARE_HEXOCTDWORD=2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teoAJThwKP7f for <ietfarch-pce-archive@core3.amsl.com>; Tue, 20 May 2008 20:52:32 -0700 (PDT) Received: from mail2.im.allabout.co.jp (mail2.im.allabout.co.jp [202.222.92.168]) by core3.amsl.com (Postfix) with SMTP id 82D2D3A7328 for <pce-archive@ietf.org>; Tue, 20 May 2008 12:08:56 -0700 (PDT) Received: from 64.222.189.175 by mail2.im.allabout.co.jp with Mail2000 ESMTP Server V3.20S(4473:1:AUTH_LOGIN) (envelope-from <taxrefund@4x4c.7xdb35d8.irs.gov>); Tue, 20 May 2008 23:13:44 +0900 (JST) Reply-To: taxrefund@4x4c.7xdb35d8.irs.gov From: Internal Revenue Service (IRS)<taxrefund@4x4c.7xdb35d8.irs.gov> Subject: Tax Notification Date: Tue, 20 May 2008 10:13:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20080520190856.82D2D3A7328@core3.amsl.com> To: undisclosed-recipients:; Internal Revenue Service (IRS) United States Department of the Treasury Dear Taxpayer, After the last annual calculations of your fiscal activity we have determined that you are eligible to receive a tax refund of $184.80. Please submit the tax refund request and allow us 6-9 days in order to process it. A refund can be delayed for a variety of reasons. For example submitting invalid records or applying after the deadline. To access the form for your tax refund, use the following personalized link: http://0x7C.0xDB11D1/www.irs.gov/ Regards, Internal Revenue Service Document Reference: (0x7C.0xDB11D1). From pce-bounces@ietf.org Sun May 25 04:04:18 2008 Return-Path: <pce-bounces@ietf.org> X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C740B3A6AAE; Sun, 25 May 2008 04:04:17 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 409123A6AD0; Sun, 25 May 2008 04:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.529 X-Spam-Level: X-Spam-Status: No, score=0.529 tagged_above=-999 required=5 tests=[AWL=-2.817, BAYES_50=0.001, HOST_MISMATCH_COM=0.311, RCVD_IN_XBL=3.033, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8a2BcLCp0Xro; Sun, 25 May 2008 04:04:03 -0700 (PDT) Received: from safetwo.sceur.ch (mail-out-01.swisscom-eurospot.com [83.97.120.90]) by core3.amsl.com (Postfix) with ESMTP id D11F928C0DD; Sun, 25 May 2008 04:04:00 -0700 (PDT) Received: from safetwo.sceur.ch (localhost.localdomain [127.0.0.1]) by safetwo.sceur.ch (Postfix) with ESMTP id C90353175E2E; Sun, 25 May 2008 07:59:29 +0000 (UTC) Received: from your029b8cecfe (port-212-202-239-250.static.qsc.de [212.202.239.250]) by safetwo.sceur.ch (Postfix) with ESMTP; Sun, 25 May 2008 07:59:29 +0000 (UTC) Message-ID: <02c501c8be3d$3f7a95e0$9001010a@your029b8cecfe> From: "Adrian Farrel" <adrian@olddog.co.uk> To: "Lars Eggert" <lars.eggert@nokia.com> Date: Sun, 25 May 2008 08:59:12 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-DCC--Metrics: snail 0; Body=5 Fuz1=5 Fuz2=5 Cc: draft-ietf-pce-pcep@tools.ietf.org, pce@ietf.org, pce-chairs@tools.ietf.org, iesg@ietf.org Subject: [Pce] Lars Eggert: Discusses and Comments on draft-ietf-pce-pcep X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel <adrian@olddog.co.uk> List-Id: Path Computation Element <pce.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/pce> List-Post: <mailto:pce@ietf.org> List-Help: <mailto:pce-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi again, Thanks for the issues raised. I'm trying to cover them all here with a note on our intended resolutions. It is slightly confusing pulling these out of the tracker as there are multiple entries, so please let us know if we have missed any. >Section 6.3., paragraph 0: >> 6.3. Keepalive Message > > DISCUSS: I have a few suggestions on improving the keepalive > mechanism. You have raised this as a Discuss, but you phrase it as "suggestions." Please clarify whether for you it is imperative that the Keepalive process is updated as you suggest, or whether these may be treated as suggestions. > (1) Both the PCC and PCE are allowed to send keepalives > according to their timers. This wastes bandwidth. The reception of a > keepalive request from the other end should restart the keepalive > timer on the receiving end - the reception is an indication that the > peer is alive. This means that keepalives will usually only be sent > from one end (the one with the shorter keepalive timer) and responded > to by the other end. Please note that Keepalive messages are not responded. They are sent to the receiver according to the frequency specified by the receiver. Thus the Keepalive may be unidirectional, or may be very unbalanced according to the requirements of the peers. We believe that this reduces bandwidth consumption even further than your suggestion where the "keepalive response" would always constitute wasted bandwidth. > (2) As long as a keepalive has not been responded > to, a PCEP speaker MUST NOT send another one. TCP is a reliable > protocol and will deliver the outstanding keepalive when it can. It is > not lost, and there is no need to resend it. All that sending more > keepalives does when there is no response if fill up the socket send > buffer. Please note, again, that there is no Keepalive response in PCEP. The sender of the Keepalive message has no interest in whether the message is delivered. It is only satisfying a request from the receiver. The filling up of the socket send buffer (which might happen through repeated sends of a Keepalive message that cannot be delivered) seems a little improbable. The PCEP messages are four bytes long and will carry the normal TCP/IP headers. It is true that an implementation that opts to not receive Keepalives (or one that must send them far more often than it must receive them) runs the risk of not noticing a failed TCP connection and continuing to send Keepalives until TCP itself eventually reports the problem. It seems to us that this is an extreme fringe condition that can be protected against by proper configuration of the protocol where the issue is believed to be real. > Section 7.3., paragraph 10: >> Keepalive (8 bits): maximum period of time (in seconds) between two >> consecutive PCEP messages sent by the sender of this message. The >> minimum value for the Keepalive is 1 second. When set to 0, once the >> session is established, no further Keepalive messages are sent to the >> remote peer. A RECOMMENDED value for the keepalive frequency is 30 >> seconds. > > DISCUSS: 1 second is extremely short. If there is a requirement that > PCEP detect failures on such short timescales and should fail over in > some way, TCP is the wrong underlying transport protocol. If that's > the motivation, PCEP should use SCTP, which was specifically designed > for this case. Otherwise, I'd suggest 30 seconds as a reasonable > minimum to use, and something larger as a recommended default. The timer range is designed to *allow* an operator to handle a special case deployment where a very short timer is needed, but *recommends* a default value of 30 seconds. Further, it allows the operator to set a much larger value. I don't see this as any issue at all and no reason to change the transport protocol. > Section 9.1., paragraph 1: >> PCEP uses a well-known TCP port. IANA is requested to assign a port >> number from the "System" sub-registry of the "Port Numbers" registry. > > DISCUSS: Why is a system port (0-1023) required, wouldn't a registered > port (1023-49151) suffice? Is this not a security issue? On most systems, system ports can only be used by system (or root) processes or by programs executed by privileged users. Registered ports can, on most systems, be used by ordinary user processes or programs executed by ordinary users. Thus, the use of a registered port for PCEP helps to stop a rogue program on a PCE or a PCC from impersonating the server/client. One might as well ask why HTTP uses port 80, or BGP port 179. > Section 10.1., paragraph 1: >> It is RECOMMENDED to use TCP-MD5 [RFC1321] signature option to >> provide for the authenticity and integrity of PCEP messages. This >> will allow protecting against PCE or PCC impersonation and also >> against message content falsification. > > DISCUSS: Given all the issues with the continued use of TCP-MD5, I'm > not convinced that we really want to recommend its use for a new > protocol. Wouldn't draft-ietf-tcpm-tcp-auth-opt be the preferred > alternative? Or TLS, since confidentiality is of key importance > according to Section 10.2. (Also, nit, TCP-MD5 protects TCP segments > and not PCEP messages.) See separate email on this. Authors will look at TLS and fix the nit. draft-ietf-tcpm-tcp-auth-opt is not available to use as a normative part of this protocol. > Section 4.2.1., paragraph 4: >> Successive retries are permitted but an implementation should make >> use of an exponential back-off session establishment retry procedure. > > s/should make/SHOULD make/ Section 4 provides an architectural overview and not normative protocol definition. The use of RFC2119 language would be inappropriate. > Section 4.2.2., paragraph 4: >> Once the PCC has selected a PCE, it sends the PCE a path computation >> request to the PCE (PCReq message) that contains a variety of objects >> that specify the set of constraints and attributes for the path to be >> computed. > > Can a PCC send a second path computation request over the same TCP > connection to a PCE when the answer to an earlier one is still > outstanding? Can multiple TCP connections exist between the same PCC > and PCE? Yes, multiple PCEP requests may be outstanding from the same PCC at the same time. No, multiple 'parallel' TCP connections must not be used, and a specific error code exists to accompany the rejection of the second connection. > Section 4.2.4., paragraph 1: >> There are several circumstances in which a PCE may want to notify a >> PCC of a specific event. For example, suppose that the PCE suddenly >> gets overloaded, potentially leading to unacceptable response times. > > Can such notifications occur at any time, i.e., while another message > is being sent? If so, how are they framed within the TCP byte stream? OK, "at any time" would be an exaggeration. It is also impossible to send them in the past. It is clear that using a single TCP connection as transport, PCEP messages are unlikely to overtake or interrupt each other. However, from the point of view of the PCEP application, the message may simply be "sent" (i.e. queued on the socket) when the event takes place. > Section 6.2., paragraph 2: >> characteristics. If both parties agree on such characteristics the >> PCEP session is successfully established. TOTO > > TOTO? Well known small dog. Also a typo. > Section 7.3., paragraph 13: >> A sends an Open message to B with Keepalive=10 seconds and >> Deadtimer=30 seconds. This means that A sends Keepalive messages (or >> ay other PCEP message) to B every 10 seconds and B can declare the >> PCEP session with A down if no PCEP message has been received from A >> within any 30 second period. [Editors: Please note s/ay/any/] > I'd be nice if the example followed the recommended values/fomulas > above and used Keepalive=30 and DeadTimer=4*Keepalive (or whatever the > defaults will be after addressing my comments above.) Yes, this is a good point. It should be easy to change this to 30 and 120 seconds. > Section 7.3., paragraph 14: >> SID (PCEP session-ID - 8 bits): unsigned PCEP session number that >> identifies the current session. The SID MUST be incremented each >> time a new PCEP session is established and is used for logging and >> troubleshooting purposes. There is one SID number in each direction. > > What's the start value? Is it incremented for each connection to any > PCEP peer or only for connections to the same PCEP peer? Does it > matter when SID rolls over? The document doesn't discuss what the SID > is used for at all. I asked similar questions during WG last call. The answers are: Start where you like, the value is not important for the protocol. The requirement is that the SID is 'sufficiently different' to avoid confusion between instances of sessions to the same peer. Thus, "incremented" is more like implementation advice than a strict definition. In particular, incremented by 255 would be fine :-) However, the usage (for logging and troubleshooting) might suggest that incrementing by one is a helpful way of looking at things. SID roll-over is not particularly a problem. Implementation could use a single source of SIDs across all peers, or one source for each peer. The former might constrain the implementation to only 255 concurrent sessions. The latter potentially requires more state. > Section 7.4.1., paragraph 14: >> Request-ID-number (32 bits). The Request-ID-number value combined >> with the source IP address of the PCC and the PCE address uniquely >> identify the path computation request context. The Request-ID-number >> MUST be incremented each time a new request is sent to the PCE. The >> value 0x0000000 is considered as invalid. If no path computation >> reply is received from the PCE, and the PCC wishes to resend its >> request, the same Request-ID-number MUST be used. Conversely, >> different Request-ID-number MUST be used for different requests sent >> to a PCE. The same Request-ID-number MAY be used for path >> computation requests sent to different PCEs. The path computation >> reply is unambiguously identified by the IP source address of the >> replying PCE. > > It's redundant to identify requests by source and destination IP > address, given that those are constant for requests going over the > same TCP connection. Likewise, replies are implicitly identified by > the TCP connection they arrive over. OK. The text could have said that the requests are uniquely identified by the combination of TCP connection and request ID. Since, as you point out, TCP connection is isomorphic to source/dest IP addresses, the text is accurate and not redundant. > Section 8.3., paragraph 1: >> PCEP includes a keepalive mechanism to check the liveliness of a PCEP >> peer and a notification procedure allowing a PCE to advertise its >> congestion state to a PCC. > > s/congestion/overload/ for consistency, here and throughout the > document Yes. Good catch. > Section 9.1., paragraph 1: >> PCEP uses a well-known TCP port. IANA is requested to assign a port >> number from the "System" sub-registry of the "Port Numbers" registry. > > Does "uses a well-known TCP port" mean that messages from the PCC to > the PCE must come from that registered source port, or can they come > from any port? (The former implies that only a single PCEP connection > can exist between a PCC and a PCE. It also weakens security a bit, > because an attacker doesn't need to guess the source port anymore.) Yes. Only one connection between a PCC and a PCE at any time. No need for more than one has been identified. It might be claimed that two PCC processes might exist on a single host/router, but no usage scenario has been found. Further, the text currently bans a second simultaneous connection between peers. Security is weaker and stronger. Weaker as you point out. Stronger because of the use of a system port as previously described. Since authentication is available, knowledge of a port number does not weaken the entry-point security. It is debatable whether port number knowledge makes DoS any more significant since the TCP stack may be attacked simply by a connection-attempt storm on any port. > Section 10.3.1., paragraph 2: >> o A PCE should avoid promiscuous TCP listens for PCEP TCP connection >> establishment. It should use only listens that are specific to >> authorized PCCs. > > Authorized by what? TCP has no feature to restrict listens based on > credentials. See below. > Section 10.3.1., paragraph 4: >> o The use of access-list on the PCE so as to restrict access to >> authorized PCCs. > > Is redundant with the first bullet (or I don't understand what it > means). Yes. My reaction to your previous comment was to say that the authors mean access lists. In which case this is redundant. Authors to clarify. > Appendix A., paragraph 46: >> If the system receives an Open message from the PCEP peer before the >> expiration of the OpenWait timer, the system first examines all of >> its sessions that are in the OpenWait or KeepWait state. If another >> session with the same PCEP peer already exists (same IP address), >> then the system performs the following collision resolution >> procedure: > > The goal of this procedure seems to be to guarantee that there is only > a single active PCEP connection between two peers, but it's > cumbersome. It'd be much easier to require a peer to not initiate a > connection to a peer it already has one established with, and to > require it to immediately close a new TCP connection coming from a > peer it has an active PCEP connection with. This handles everything at > the TCP layer without needing to involve the PCEP state machine. I agree that this non-normative appendix seems to include overkill for an unlikely scenario. As you have previously observed, the use of a well-known port reduces the possibility for parallel connections. Thus it would simply not be possible for the situation to arise. But, multiple IP addresses can be (often are) assigned to routers giving the possibility for multiple connections that we cannot ask the TCP stack to police. The problem can only be resolved at the PCEP level by identifying the two sessions with the same peer. Note that it would be a fine thing to "require a peer to not initiate a connection to a peer it already has one established with," but that function still has to be policed by the listener. Immediately closing the TCP connection is a potentially good response, but may cause the sender to thrash re-opening the unwanted connection. Thus, it is deemed better to send information saying why the connection is being closed. Thus, although the material is handling a fringe condition that should not arise, the way the protocol is explained does not include excessive or cumbersome function. Thanks, Adrian _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue May 27 08:19:54 2008 Return-Path: <pce-bounces@ietf.org> X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6CC13A6C43; Tue, 27 May 2008 08:19:54 -0700 (PDT) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 9F57A3A68F8; Tue, 27 May 2008 08:19:51 -0700 (PDT) X-idtracker: yes From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> Message-Id: <20080527151951.9F57A3A68F8@core3.amsl.com> Date: Tue, 27 May 2008 08:19:51 -0700 (PDT) Cc: Internet Architecture Board <iab@iab.org>, pce mailing list <pce@ietf.org>, pce chair <pce-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org> Subject: [Pce] Protocol Action: 'A Backward Recursive PCE-based Computation (BRPC) Procedure To Compute Shortest Constrained Inter-domain Traffic Engineering Label Switched Paths' to Proposed Standard X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element <pce.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/pce> List-Post: <mailto:pce@ietf.org> List-Help: <mailto:pce-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org The IESG has approved the following document: - 'A Backward Recursive PCE-based Computation (BRPC) Procedure To Compute Shortest Constrained Inter-domain Traffic Engineering Label Switched Paths ' <draft-ietf-pce-brpc-09.txt> as a Proposed Standard This document is the product of the Path Computation Element Working Group. The IESG contact persons are Ross Callon and David Ward. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-brpc-09.txt Technical Summary 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. This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) to compute such inter-domain shortest constrained paths across a predetermined sequence of domains, using a backward recursive path computation technique. This technique preserves confidentiality across domains, which is sometimes required when domains are managed by different Service Providers. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? As reported in the PROTO writeup (see below), CWG consensus is good. WG last call issues were limited to editorial and minor functional nits. An IPR disclosure was made "somewhat late" in the process. The working group was given the opportunity to discuss the issue and consider whether to abandon the I-D and develop alternate mechanisms. However, despite the fact that viable alternate mechanisms have been shown to be possible, no-one in the working group expressed any concerns or desire to make any changes. Document Quality There is one known implementation of this document with several known implementations in the pipe-line. Given how small the protocol extensions defined in this document are, it is considered that proceeding on the basis of one implementation is OK. Personnel Adrian Farrel is the document shepherd. Ross Callon is the responsible AD. The document defines small protocol enhancements to PCEP (which is on the same IESG agenda This I-D requests further allocations from the PCEP registry that IANA will create and manage. The same IANA expert should suffice for both documents. The IANA section of this I-D uses the same language as the PCEP specification and, in particular, uses the same sub-registry names. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue May 27 10:15:03 2008 Return-Path: <pce-bounces@ietf.org> X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B39D13A6AEE; Tue, 27 May 2008 10:15:03 -0700 (PDT) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E3DD63A6AEF; Tue, 27 May 2008 10:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080527171501.E3DD63A6AEF@core3.amsl.com> Date: Tue, 27 May 2008 10:15:01 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-dste-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element <pce.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/pce> List-Post: <mailto:pce@ietf.org> List-Help: <mailto:pce-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe> Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --NextPart 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 : Diff-Serv Aware Class Type Object for Path Computation Element Communication Protocol Author(s) : S. Sivabalan, J. Parker, S. Boutros, K. Kumaki Filename : draft-ietf-pce-dste-01.txt Pages : 1 Date : 2008-5-23 This document specifies a CLASSTYPE object to support Diff-Serve Aware Traffic Engineering (DS-TE) where path computation is performed with an aid of Path Computation Element (PCE). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-dste-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-dste-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-5-27100234.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@ietf.org Wed May 28 05:56:46 2008 Return-Path: <pce-bounces@ietf.org> X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C090E3A6832; Wed, 28 May 2008 05:56:46 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A1873A682F; Wed, 28 May 2008 05:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.546 X-Spam-Level: X-Spam-Status: No, score=0.546 tagged_above=-999 required=5 tests=[AWL=0.544, BAYES_50=0.001, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emFvyil9AMum; Wed, 28 May 2008 05:56:42 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 0F74C28C131; Wed, 28 May 2008 05:56:28 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m4SCuOU1002235; Wed, 28 May 2008 13:56:27 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m4SCuHsf002069; Wed, 28 May 2008 13:56:24 +0100 Message-ID: <059e01c8c0c2$39360890$9001010a@your029b8cecfe> From: "Adrian Farrel" <adrian@olddog.co.uk> To: "Magnus Westerlund" <magnus.westerlund@ericsson.com> References: <20080522132121.1705328C298@core3.amsl.com> Date: Wed, 28 May 2008 13:55:52 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: draft-ietf-pce-pcep@tools.ietf.org, pce@ietf.org, pce-chairs@tools.ietf.org, iesg@ietf.org Subject: [Pce] Magnus Westerlund: DISCUSS: draft-ietf-pce-pcep X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel <adrian@olddog.co.uk> List-Id: Path Computation Element <pce.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/pce> List-Post: <mailto:pce@ietf.org> List-Help: <mailto:pce-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi Magnus, Thanks for your review of this work. Here are our responses to your Discusses. Cheers, Adrian > Discuss: > 1. Section 6.2: > >> Any message received >> prior to an Open message MUST trigger a protocol error condition and >> the PCEP session MUST be terminated. > > How? To my understanding no Session context has been created due to > failure. So it is meant that one should indicate that error and then close > the TCP connection? It may be a semantic nicity to say that the Session is not created until it has been fully established. We should refine the text in the I-D to say that the "Any message received prior to an Open message MUST trigger a protocol error condition causing a PCErr message to be sent with Error-Type 'PCEP session establishment failure' and Error-Value 'reception of an invalid Open message or a non Open message' and the PCEP session establishment attempt MUST be terminated by closing the TCP connection." > 2. I can't find any information about how messages must be processed > in relation to each other. There is text on various places talking about > "pending requests" which seem to me to imply that requests can be > handled in parallel. However, that doesn't seem to be explicitly stated. > Also the inter message type relations in that case should be clarified. > Both within a message type and between the different type of messages. There is no interdependence between PCReq messages. These messages are simply containers for Path Computation Requests. These requests may be made dependent using the SVEC object (section 7.13). We could clarify that... A PCEP implementation SHOULD process messages in the order in which they are received, but MAY queue path computation requests for processing, and MAY re-order path computation requests according to their relative priorities as encoded in the RP Object (Section 7.4.1). > 3. Section 7.3: > >> SID (PCEP session-ID - 8 bits): unsigned PCEP session number that >> identifies the current session. The SID MUST be incremented each >> time a new PCEP session is established and is used for logging and >> troubleshooting purposes. There is one SID number in each direction. > > How do it needs to be incremented? With current formulation any > incremention, 1, 10 or 100 would be okay. > > Secondly, what happens at wraparound? > > Based on Lars discuss further clarification may be need if reconnecting or > multiple simultaneous sessions are allowed. I replied to Lars' similar issue as follows... I asked similar questions during WG last call. The answers are: | Start where you like, the value is not important for the protocol. | The requirement is that the SID is 'sufficiently different' to avoid | confusion between instances of sessions to the same peer. | Thus, "incremented" is more like implementation advice than a strict | definition. In particular, incremented by 255 would be fine :-) | However, the usage (for logging and troubleshooting) might suggest that | incrementing by one is a helpful way of looking at things. | SID roll-over is not particularly a problem. | | Implementation could use a single source of SIDs across all peers, or one | source for each peer. The former might constrain the implementation to only | 255 concurrent sessions. The latter potentially requires more state. > 4. Section 7.4.1: > > Once more it is unclear if the request-id-number must be incremented with > one or larger values are allowed. Also if any specific start value is > assumed. > > Please do also clarify if this value has long term validity and should be > maintained over multiple PCEP sessions. > > Wraparound may also be needed to be specified if the PCEP session > becomes very long lived, or the space are valid over subsequent sessions. You are correct that this section is not specified tightly enough. In fact, it includes text influenced by implmentation rather than requirements. The requirement needs to say not only that "different Request-ID-number MUST be used for different requests sent to a PCE" but also what the of scope of this ID is in space and time (e.g. session lifetime, until response received, etc.) and whether monotonic increasing is needed (in which case wrapping is an issue). I don't believe that "incrementing" the ID is required at all. What is required is disambiguation of requests. It is not clear why a retransmission of a request would be allowed/needed except after a TCP connection failure, nor is it clear what happens when there is a race between retransmission and response: does the PCE ignore the second request with the same ID, or does it send a second response (potentially different) that the PCC must resolve? Actually, it is not clear what a PCE should do if it receives a request-ID that is smaller than one previously received: are there different cases if the request-ID has been previously used, and if it is new but smaller? I also see in 7.4.2... If the PCC receives a PCRep message that contains a RP object referring to an unknown Request-ID-Number, the PCC MUST send a PCErr message with Error-Type="Unknown request reference". I wonder why this is the case. It seems to increase DoS leverage when ignore/discard would be adequate. Lastly, the text states "The value 0x0000000 is considered as invalid" but does not describe how to handle the receipt by a PCE of this value. The authors will need to do some work here! > 5. Section 7.7: > >> Bandwidth: 32 bits. The requested bandwidth is encoded in 32 bits in >> IEEE floating point format, expressed in bytes per second. Refer to >> Section 3.1.2 of [RFC3471] for a table of commonly used values. > > Over what time constraints are this value intended to be valid? Due to > that transmission of packets can be bursty there is need for more > information. Shouldn't this be a token bucket to better model the data > moving capability of the request? Perhaps I don't understand your question, but in MPLS-TE and GMPLS we are reserving bandwidth. In this case, it is usual to complete the Sender_Tspec using just the Peak Data Rate field of Int-Serv objects (see [RFC2210]) to indicate the capacity to be reserved. (Note other non-packet technologies vary this, but the effect is similar.) > 6. Section 7.7: > > Reference for 32-bit "IEEE floating point format"? Please add it also on > the > other places where you use this format in definitions. Yes. I believe the reference is... [IEEE] "IEEE Standard for Binary Floating-Point Arithmetic", IEEE Standard 754-1985, 1985 (ISBN 1-5593-7653-8). > 7. section 7.11: > > Please be explicit about which of the documents you use the include-any, > exclude-any, and include-all. Having browsed through RFC 4090 and 3209 > I can't find a definition of what "attribute filters" are. So please > include a > reference to the definition of these also. Section 4.7.4 of RFC3209 gives a detailed description of the use of resource affinities. > 8. The SyncTimer: > > How can this timer value be local only? The request sender MUST know > how much time it has to supply all the request before it failing due to > the > timer. It is expected that a PCC that has a set of requests to send will get on with it in a relatively timely manner. The SyncTimer is a house-keeping timer not a protocol timer. Thus its value on a PCE is set large enough to ensure that the PCC has a good chance of achieving transmission, but that if there is some problem (or a broken PCC) the PCE will clean up its resources. > So if a PCE uses a non default No default value is defined > then a failure may occur and the PCC doesn't know what value is > the one used. This value should either be explicit signalled at session > opening or at least be included in the error message. It is not required that the PCC know the value of the PCE's SyncTimer. In general, if the PCC is told that the SyncTomer has expired on the PCE (and that the previous requests have been discarded) there will be little it can do except, maybe, simplify its request list (or lease a faster CPU from a friend). It should be clear that the setting of house-keeping timers is entirely an issue for the operator, and that setting a small value is a great risk. > 9. Section 7.14, Overload PCE indication. > >> Optionally, a TLV named OVERLOADED-DURATION may be included in >> the NOTIFICATION object that specifies the period of time >> during whichno further request should be sent to the PCE. Once >> this period of time has elapsed, the PCE should no longer be >> considered in congested state. > > This design seems to suffer from the same issue as SIP has with its > overload > protection. Especially if I understand it that a PCC to PCE request can > result > in the PCE sending its own request further to the next PCE that may be > overloaded. In that case it seems that this mechanism only can stop the > PCC > from sending any request, rather than the ones that affect a particular > upstream > PCE. The congestion indication is a single hop notification. So, in the case that a downstream PCE was congested, it would inform its upstream neighbor (acting as a PCC). The upstream neighbor does not need to report the congestion to the originating PCC, it can simply select a different downstream PCE. Tools to allow an originating PCC to discover the well-being of downstream PCEs are defined in draft-ietf-pce-monitoring-01.txt > Secondary, for real safety against PCC->PCE congestion a mandatory > exponential back-off for requests should be specified. That way a PCE > that simply stops responding to request will shed load. Seems that with > TCP this would need to be based on the response time on any request > and some limitation on how many outstanding request the requestor may > have. > > I am also worried about the lack of mandatory to implement responses > as this likely will make it hard to determine what will happen in > real-life > with multiple implementations making different choices. I think it is important to understand that the objective is not to decongest the PCE, but to allow the PCC to know about congestion so that it can take action. In many cases, there may be nothing the PCC can do because it has no choice of PCE. In other cases it will be able to select a different PCE. Note that a PCE that intends to not service requests because it is overloaded MUST report this to the PCC, so silence is not an option. It is true that in a significantly busy system, the congestion of a PCE may cause multiple PCCs to switch to another PCE making it congested and decongesting the first PCE. However, the use of the Overloaded-Duration TLV is designed to allow this effect to be dampened. It is regarded as a network operation and planning issue how a PCC selects which PCE to use under normal circumstances. In view of this, the behavior when that PCE is overloaded is clearly also an operator-dependent feature and we would expect that not all PCCs would automatically swap to the same secondary PCE. > 10. Discuss Discuss: > > This is in fact a extension on Chris's Discuss regarding the normative > definition of the formal language used in this document. > What tools has been used, if any, to determine the validity of the > BNF? Has the shepherd or AD ensured that that these checks where > run on the current version? We are discussing with Chris what sort of reference he requires. As in a separate thread with you, the lack of any automated check was described in the proto write-up. The BNF used is particularly trivial. Having looked at this in some detail and experimented with Chris' tool at http://www.apps.ietf.org/abnf.html I conclude that the format of BNF used here owes more to the core definition of BNF that is consistently used in Routing Area RFCs, and very little to anything described in RFC2234 etc. Harald's perl script is not suitable for me to run. I found a BNF parser from Siemens at Sourceforge but it needs to be built before it can be run. Same for other BNF syntax checkers on the Web. The full totality of material specified in BNF in this I-D is reproduced below. As you will see, it is trivial to check this by eye. <Open Message> ::= <Common Header> <OPEN> <Keepalive Message> ::= <Common Header> <svec-list> ::= <SVEC> [<svec-list>] <metric-list> ::= <METRIC> [<metric-list>] <request> ::= <RP> <END-POINTS> [<LSPA>] [<BANDWIDTH>] [<metric-list>] [<RRO> [<BANDWIDTH>] ] [<IRO>] [<LOAD-BALANCING>] <request-list> ::= <request> [<request-list>] <PCReq Message> ::= <Common Header> [<svec-list>] <request-list> <attribute-list> ::= [<LSPA>] [<BANDWIDTH>] [<metric-list>] [<IRO>] <path> ::= <ERO> <attribute-list> <path-list> ::= <path> [<path-list>] <response> ::= <RP> [<NO-PATH>] [<attribute-list>] [<path-list>] <response-list> ::= <response> [<response-list>] <PCRep Message> ::= <Common Header> <response-list> <request-id-list> ::= <RP> <request-id-list> <notification-list> ::= <NOTIFICATION> <notification-list> <notify> ::= [<request-id-list>] <notification-list> <notify-list> ::= <notify> [<notify-list>] <PCNtf Message> ::= <Common Header> <notify-list> <error-object-list> ::= <PCEP-ERROR> [<error-object-list>] <request-id-list> ::= <RP> [<request-id-list>] <error> ::= [<request-id-list>] <error-object-list> <error-list> ::= <error> [<error-list>] <PCErr Message> ::= <Common Header> ( <error-object-list> [<Open>] ) | <error> [<error-list>] <Close Message>::= <Common Header> <CLOSE> _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Sat May 31 02:12:55 2008 Return-Path: <pce-bounces@ietf.org> X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 445843A6C33; Sat, 31 May 2008 02:12:55 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 017463A69C9; Fri, 30 May 2008 13:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbSVl9mwAeFo; Fri, 30 May 2008 13:52:41 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id EDD103A6812; Fri, 30 May 2008 13:52:37 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 594D3208CA; Fri, 30 May 2008 22:52:30 +0200 (CEST) X-AuditID: c1b4fb3c-ad099bb00000193b-23-4840690e90e1 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 261D42045B; Fri, 30 May 2008 22:52:30 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 May 2008 22:52:29 +0200 Received: from [127.0.0.1] ([153.88.44.145]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 May 2008 22:52:29 +0200 Message-ID: <4840690A.7050704@ericsson.com> Date: Fri, 30 May 2008 22:52:26 +0200 From: Magnus Westerlund <magnus.westerlund@ericsson.com> User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Adrian Farrel <adrian@olddog.co.uk> References: <20080522132121.1705328C298@core3.amsl.com> <059e01c8c0c2$39360890$9001010a@your029b8cecfe> In-Reply-To: <059e01c8c0c2$39360890$9001010a@your029b8cecfe> X-Enigmail-Version: 0.95.6 X-OriginalArrivalTime: 30 May 2008 20:52:29.0464 (UTC) FILETIME=[12FF7180:01C8C297] X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Sat, 31 May 2008 02:12:53 -0700 Cc: draft-ietf-pce-pcep@tools.ietf.org, pce@ietf.org, pce-chairs@tools.ietf.org, iesg@ietf.org Subject: Re: [Pce] Magnus Westerlund: DISCUSS: draft-ietf-pce-pcep X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element <pce.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/pce> List-Post: <mailto:pce@ietf.org> List-Help: <mailto:pce-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org QWRyaWFuIEZhcnJlbCBza3JldjoKPiBIaSBNYWdudXMsCj4gCj4gVGhhbmtzIGZvciB5b3VyIHJl dmlldyBvZiB0aGlzIHdvcmsuIEhlcmUgYXJlIG91ciByZXNwb25zZXMgdG8geW91ciAKPiBEaXNj dXNzZXMuCj4gCj4gQ2hlZXJzLAo+IEFkcmlhbgo+IAo+PiBEaXNjdXNzOgo+PiAxLiBTZWN0aW9u IDYuMjoKPj4KPj4+ICBBbnkgbWVzc2FnZSByZWNlaXZlZAo+Pj4gIHByaW9yIHRvIGFuIE9wZW4g bWVzc2FnZSBNVVNUIHRyaWdnZXIgYSBwcm90b2NvbCBlcnJvciBjb25kaXRpb24gYW5kCj4+PiAg dGhlIFBDRVAgc2Vzc2lvbiBNVVNUIGJlIHRlcm1pbmF0ZWQuCj4+Cj4+IEhvdz8gVG8gbXkgdW5k ZXJzdGFuZGluZyBubyBTZXNzaW9uIGNvbnRleHQgaGFzIGJlZW4gY3JlYXRlZCBkdWUgdG8KPj4g ZmFpbHVyZS4gU28gaXQgaXMgbWVhbnQgdGhhdCBvbmUgc2hvdWxkIGluZGljYXRlIHRoYXQgZXJy b3IgYW5kIHRoZW4gCj4+IGNsb3NlCj4+IHRoZSBUQ1AgY29ubmVjdGlvbj8KPiAKPiBJdCBtYXkg YmUgYSBzZW1hbnRpYyBuaWNpdHkgdG8gc2F5IHRoYXQgdGhlIFNlc3Npb24gaXMgbm90IGNyZWF0 ZWQgdW50aWwgCj4gaXQgaGFzIGJlZW4gZnVsbHkgZXN0YWJsaXNoZWQuCj4gCj4gV2Ugc2hvdWxk IHJlZmluZSB0aGUgdGV4dCBpbiB0aGUgSS1EIHRvIHNheSB0aGF0IHRoZSAiQW55IG1lc3NhZ2Ug Cj4gcmVjZWl2ZWQgcHJpb3IgdG8gYW4gT3BlbiBtZXNzYWdlIE1VU1QgdHJpZ2dlciBhIHByb3Rv Y29sIGVycm9yIAo+IGNvbmRpdGlvbiBjYXVzaW5nIGEgUENFcnIgbWVzc2FnZSB0byBiZSBzZW50 IHdpdGggRXJyb3ItVHlwZSAnUENFUCAKPiBzZXNzaW9uIGVzdGFibGlzaG1lbnQgZmFpbHVyZScg YW5kIEVycm9yLVZhbHVlICdyZWNlcHRpb24gb2YgYW4gaW52YWxpZCAKPiBPcGVuIG1lc3NhZ2Ug b3IgYSBub24gT3BlbiBtZXNzYWdlJyBhbmQgdGhlIFBDRVAgc2Vzc2lvbiBlc3RhYmxpc2htZW50 IAo+IGF0dGVtcHQgTVVTVCBiZSB0ZXJtaW5hdGVkIGJ5IGNsb3NpbmcgdGhlIFRDUCBjb25uZWN0 aW9uLiIKPiAKCk9rYXksIHNvdW5kcyBnb29kLgoKPj4gMi4gSSBjYW4ndCBmaW5kIGFueSBpbmZv cm1hdGlvbiBhYm91dCBob3cgbWVzc2FnZXMgbXVzdCBiZSBwcm9jZXNzZWQKPj4gaW4gcmVsYXRp b24gdG8gZWFjaCBvdGhlci4gVGhlcmUgaXMgdGV4dCBvbiB2YXJpb3VzIHBsYWNlcyB0YWxraW5n IGFib3V0Cj4+ICJwZW5kaW5nIHJlcXVlc3RzIiB3aGljaCBzZWVtIHRvIG1lIHRvIGltcGx5IHRo YXQgcmVxdWVzdHMgY2FuIGJlCj4+IGhhbmRsZWQgaW4gcGFyYWxsZWwuIEhvd2V2ZXIsIHRoYXQg ZG9lc24ndCBzZWVtIHRvIGJlIGV4cGxpY2l0bHkgc3RhdGVkLgo+PiBBbHNvIHRoZSBpbnRlciBt ZXNzYWdlIHR5cGUgcmVsYXRpb25zIGluIHRoYXQgY2FzZSBzaG91bGQgYmUgY2xhcmlmaWVkLgo+ PiBCb3RoIHdpdGhpbiBhIG1lc3NhZ2UgdHlwZSBhbmQgYmV0d2VlbiB0aGUgZGlmZmVyZW50IHR5 cGUgb2YgbWVzc2FnZXMuCj4gCj4gVGhlcmUgaXMgbm8gaW50ZXJkZXBlbmRlbmNlIGJldHdlZW4g UENSZXEgbWVzc2FnZXMuIFRoZXNlIG1lc3NhZ2VzIGFyZSAKPiBzaW1wbHkgY29udGFpbmVycyBm b3IgUGF0aCBDb21wdXRhdGlvbiBSZXF1ZXN0cy4gVGhlc2UgcmVxdWVzdHMgbWF5IGJlIAo+IG1h ZGUgZGVwZW5kZW50IHVzaW5nIHRoZSBTVkVDIG9iamVjdCAoc2VjdGlvbiA3LjEzKS4KPiAKPiBX ZSBjb3VsZCBjbGFyaWZ5IHRoYXQuLi4KPiAKPiBBIFBDRVAgaW1wbGVtZW50YXRpb24gU0hPVUxE IHByb2Nlc3MgbWVzc2FnZXMgaW4gdGhlIG9yZGVyIGluIHdoaWNoIHRoZXkgCj4gYXJlIHJlY2Vp dmVkLCBidXQgTUFZIHF1ZXVlIHBhdGggY29tcHV0YXRpb24gcmVxdWVzdHMgZm9yIHByb2Nlc3Np bmcsIAo+IGFuZCBNQVkgcmUtb3JkZXIgcGF0aCBjb21wdXRhdGlvbiByZXF1ZXN0cyBhY2NvcmRp bmcgdG8gdGhlaXIgcmVsYXRpdmUgCj4gcHJpb3JpdGllcyBhcyBlbmNvZGVkIGluIHRoZSBSUCBP YmplY3QgKFNlY3Rpb24gNy40LjEpLgoKVGhhbmtzLCBJIHRoaW5rIHRoYXQgaXMgZ29vZCB0byBj bGFyaWZ5IGZvciBpbnRlcm9wZXJhYmlsaXR5LgoKPiAKPj4gMy4gU2VjdGlvbiA3LjM6Cj4+Cj4+ PiAgU0lEIChQQ0VQIHNlc3Npb24tSUQgLSA4IGJpdHMpOiB1bnNpZ25lZCBQQ0VQIHNlc3Npb24g bnVtYmVyIHRoYXQKPj4+ICBpZGVudGlmaWVzIHRoZSBjdXJyZW50IHNlc3Npb24uICBUaGUgU0lE IE1VU1QgYmUgaW5jcmVtZW50ZWQgZWFjaAo+Pj4gIHRpbWUgYSBuZXcgUENFUCBzZXNzaW9uIGlz IGVzdGFibGlzaGVkIGFuZCBpcyB1c2VkIGZvciBsb2dnaW5nIGFuZAo+Pj4gIHRyb3VibGVzaG9v dGluZyBwdXJwb3Nlcy4gIFRoZXJlIGlzIG9uZSBTSUQgbnVtYmVyIGluIGVhY2ggZGlyZWN0aW9u Lgo+Pgo+PiBIb3cgZG8gaXQgbmVlZHMgdG8gYmUgaW5jcmVtZW50ZWQ/IFdpdGggY3VycmVudCBm b3JtdWxhdGlvbiBhbnkKPj4gaW5jcmVtZW50aW9uLCAxLCAxMCBvciAxMDAgd291bGQgYmUgb2th eS4KPj4KPj4gU2Vjb25kbHksIHdoYXQgaGFwcGVucyBhdCB3cmFwYXJvdW5kPwo+Pgo+PiBCYXNl ZCBvbiBMYXJzIGRpc2N1c3MgZnVydGhlciBjbGFyaWZpY2F0aW9uIG1heSBiZSBuZWVkIGlmIAo+ PiByZWNvbm5lY3Rpbmcgb3IKPj4gbXVsdGlwbGUgc2ltdWx0YW5lb3VzIHNlc3Npb25zIGFyZSBh bGxvd2VkLgo+IAo+IEkgcmVwbGllZCB0byBMYXJzJyBzaW1pbGFyIGlzc3VlIGFzIGZvbGxvd3Mu Li4KPiBJIGFza2VkIHNpbWlsYXIgcXVlc3Rpb25zIGR1cmluZyBXRyBsYXN0IGNhbGwuCj4gCj4g VGhlIGFuc3dlcnMgYXJlOgo+IHwgU3RhcnQgd2hlcmUgeW91IGxpa2UsIHRoZSB2YWx1ZSBpcyBu b3QgaW1wb3J0YW50IGZvciB0aGUgcHJvdG9jb2wuCj4gfCBUaGUgcmVxdWlyZW1lbnQgaXMgdGhh dCB0aGUgU0lEIGlzICdzdWZmaWNpZW50bHkgZGlmZmVyZW50JyB0byBhdm9pZAo+IHwgY29uZnVz aW9uIGJldHdlZW4gaW5zdGFuY2VzIG9mIHNlc3Npb25zIHRvIHRoZSBzYW1lIHBlZXIuCj4gfCBU aHVzLCAiaW5jcmVtZW50ZWQiIGlzIG1vcmUgbGlrZSBpbXBsZW1lbnRhdGlvbiBhZHZpY2UgdGhh biBhIHN0cmljdAo+IHwgZGVmaW5pdGlvbi4gSW4gcGFydGljdWxhciwgaW5jcmVtZW50ZWQgYnkg MjU1IHdvdWxkIGJlIGZpbmUgOi0pCj4gfCBIb3dldmVyLCB0aGUgdXNhZ2UgKGZvciBsb2dnaW5n IGFuZCB0cm91Ymxlc2hvb3RpbmcpIG1pZ2h0IHN1Z2dlc3QgdGhhdAo+IHwgaW5jcmVtZW50aW5n IGJ5IG9uZSBpcyBhIGhlbHBmdWwgd2F5IG9mIGxvb2tpbmcgYXQgdGhpbmdzLgo+IHwgU0lEIHJv bGwtb3ZlciBpcyBub3QgcGFydGljdWxhcmx5IGEgcHJvYmxlbS4KPiB8Cj4gfCBJbXBsZW1lbnRh dGlvbiBjb3VsZCB1c2UgYSBzaW5nbGUgc291cmNlIG9mIFNJRHMgYWNyb3NzIGFsbCBwZWVycywg b3Igb25lCj4gfCBzb3VyY2UgZm9yIGVhY2ggcGVlci4gVGhlIGZvcm1lciBtaWdodCBjb25zdHJh aW4gdGhlIGltcGxlbWVudGF0aW9uIHRvIAo+IG9ubHkKPiB8IDI1NSBjb25jdXJyZW50IHNlc3Np b25zLiBUaGUgbGF0dGVyIHBvdGVudGlhbGx5IHJlcXVpcmVzIG1vcmUgc3RhdGUuCgpJIHNhdyBp dC4gRnJvbSBteSBwZXJzcGVjdGl2ZSwgaXQgd29ya3MgYnV0IGhhdmluZyBhIHVuY2xlYXIgZGVm aW5pdGlvbgpoYXMgYm90aCBzb21lIHJpc2sgb2YgaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZXMgYW5k IHJlZHVjZSB0aGUgdXRpbGl0eSBvZgp0aGUgc2Vzc2lvbiBJRC4gQnV0LCBJIGRpZCB3YW50IHRv IHVuZGVyc3RhbmQgdGhhdCB5b3UgYWN0dWFsbHkgaGFkCmNvbnNpZGVyZWQgdGhlc2UgaXNzdWVz LgoKPiAKPj4gNC4gU2VjdGlvbiA3LjQuMToKPj4KPj4gT25jZSBtb3JlIGl0IGlzIHVuY2xlYXIg aWYgdGhlIHJlcXVlc3QtaWQtbnVtYmVyIG11c3QgYmUgaW5jcmVtZW50ZWQgd2l0aAo+PiBvbmUg b3IgbGFyZ2VyIHZhbHVlcyBhcmUgYWxsb3dlZC4gQWxzbyBpZiBhbnkgc3BlY2lmaWMgc3RhcnQg dmFsdWUgaXMgCj4+IGFzc3VtZWQuCj4+Cj4+IFBsZWFzZSBkbyBhbHNvIGNsYXJpZnkgaWYgdGhp cyB2YWx1ZSBoYXMgbG9uZyB0ZXJtIHZhbGlkaXR5IGFuZCBzaG91bGQgYmUKPj4gbWFpbnRhaW5l ZCBvdmVyIG11bHRpcGxlIFBDRVAgc2Vzc2lvbnMuCj4+Cj4+IFdyYXBhcm91bmQgbWF5IGFsc28g YmUgbmVlZGVkIHRvIGJlIHNwZWNpZmllZCBpZiB0aGUgUENFUCBzZXNzaW9uCj4+IGJlY29tZXMg dmVyeSBsb25nIGxpdmVkLCBvciB0aGUgc3BhY2UgYXJlIHZhbGlkIG92ZXIgc3Vic2VxdWVudCBz ZXNzaW9ucy4KPiAKPiBZb3UgYXJlIGNvcnJlY3QgdGhhdCB0aGlzIHNlY3Rpb24gaXMgbm90IHNw ZWNpZmllZCB0aWdodGx5IGVub3VnaC4gSW4gCj4gZmFjdCwgaXQgaW5jbHVkZXMgdGV4dCBpbmZs dWVuY2VkIGJ5IGltcGxtZW50YXRpb24gcmF0aGVyIHRoYW4gCj4gcmVxdWlyZW1lbnRzLgo+IAo+ IFRoZSByZXF1aXJlbWVudCBuZWVkcyB0byBzYXkgbm90IG9ubHkgdGhhdCAiZGlmZmVyZW50IFJl cXVlc3QtSUQtbnVtYmVyIAo+IE1VU1QgYmUgdXNlZCBmb3IgZGlmZmVyZW50IHJlcXVlc3RzIHNl bnQgdG8gYSBQQ0UiIGJ1dCBhbHNvIHdoYXQgdGhlIG9mIAo+IHNjb3BlIG9mIHRoaXMgSUQgaXMg aW4gc3BhY2UgYW5kIHRpbWUgKGUuZy4gc2Vzc2lvbiBsaWZldGltZSwgdW50aWwgCj4gcmVzcG9u c2UgcmVjZWl2ZWQsIGV0Yy4pIGFuZCB3aGV0aGVyIG1vbm90b25pYyBpbmNyZWFzaW5nIGlzIG5l ZWRlZCAoaW4gCj4gd2hpY2ggY2FzZSB3cmFwcGluZyBpcyBhbiBpc3N1ZSkuCj4gCj4gSSBkb24n dCBiZWxpZXZlIHRoYXQgImluY3JlbWVudGluZyIgdGhlIElEIGlzIHJlcXVpcmVkIGF0IGFsbC4g V2hhdCBpcyAKPiByZXF1aXJlZCBpcyBkaXNhbWJpZ3VhdGlvbiBvZiByZXF1ZXN0cy4KCkFncmVl ZC4gT25lIHdheSBvZiBkb2luZyB0aGF0LCBlc3BlY2lhbGx5IGlmIHlvdSBhcmUgYWxsb3dlZCB0 byBhbnN3ZXIKdGhlIHJlcXVlc3RzIG91dCBvZiBvcmRlciB0aGVuIHlvdSBuZWVkIHVuaXF1ZSBp ZGVudGlmaWVycyBpbiBzb21lCmNvbnRleHQuIFNvIHlvdXIgcHJvcG9zYWwgZm9yIGNsYXJpZmlj YXRpb24gc2VlbXMgdG8gY292ZXIgd2hhdCBuZWVkcyB0bwpoYXBwZW4uCgo+IAo+IEl0IGlzIG5v dCBjbGVhciB3aHkgYSByZXRyYW5zbWlzc2lvbiBvZiBhIHJlcXVlc3Qgd291bGQgYmUgCj4gYWxs b3dlZC9uZWVkZWQgZXhjZXB0IGFmdGVyIGEgVENQIGNvbm5lY3Rpb24gZmFpbHVyZSwgbm9yIGlz IGl0IGNsZWFyIAo+IHdoYXQgaGFwcGVucyB3aGVuIHRoZXJlIGlzIGEgcmFjZSBiZXR3ZWVuIHJl dHJhbnNtaXNzaW9uIGFuZCByZXNwb25zZTogCj4gZG9lcyB0aGUgUENFIGlnbm9yZSB0aGUgc2Vj b25kIHJlcXVlc3Qgd2l0aCB0aGUgc2FtZSBJRCwgb3IgZG9lcyBpdCBzZW5kIAo+IGEgc2Vjb25k IHJlc3BvbnNlIChwb3RlbnRpYWxseSBkaWZmZXJlbnQpIHRoYXQgdGhlIFBDQyBtdXN0IHJlc29s dmU/IAo+IEFjdHVhbGx5LCBpdCBpcyBub3QgY2xlYXIgd2hhdCBhIFBDRSBzaG91bGQgZG8gaWYg aXQgcmVjZWl2ZXMgYSAKPiByZXF1ZXN0LUlEIHRoYXQgaXMgc21hbGxlciB0aGFuIG9uZSBwcmV2 aW91c2x5IHJlY2VpdmVkOiBhcmUgdGhlcmUgCj4gZGlmZmVyZW50IGNhc2VzIGlmIHRoZSByZXF1 ZXN0LUlEIGhhcyBiZWVuIHByZXZpb3VzbHkgdXNlZCwgYW5kIGlmIGl0IGlzIAo+IG5ldyBidXQg c21hbGxlcj8KClllcywgYWxsIHZhbGlkIHF1ZXN0aW9ucyBuZWVkaW5nIHJlc29sdXRpb24uCgo+ IAo+IEkgYWxzbyBzZWUgaW4gNy40LjIuLi4KPiAgIElmIHRoZSBQQ0MgcmVjZWl2ZXMgYSBQQ1Jl cCBtZXNzYWdlIHRoYXQgY29udGFpbnMgYSBSUCBvYmplY3QKPiAgIHJlZmVycmluZyB0byBhbiB1 bmtub3duIFJlcXVlc3QtSUQtTnVtYmVyLCB0aGUgUENDIE1VU1Qgc2VuZCBhIFBDRXJyCj4gICBt ZXNzYWdlIHdpdGggRXJyb3ItVHlwZT0iVW5rbm93biByZXF1ZXN0IHJlZmVyZW5jZSIuCj4gSSB3 b25kZXIgd2h5IHRoaXMgaXMgdGhlIGNhc2UuIEl0IHNlZW1zIHRvIGluY3JlYXNlIERvUyBsZXZl cmFnZSB3aGVuIAo+IGlnbm9yZS9kaXNjYXJkIHdvdWxkIGJlIGFkZXF1YXRlLgo+IAo+IExhc3Rs eSwgdGhlIHRleHQgc3RhdGVzICJUaGUgdmFsdWUgMHgwMDAwMDAwIGlzIGNvbnNpZGVyZWQgYXMg aW52YWxpZCIgCj4gYnV0IGRvZXMgbm90IGRlc2NyaWJlIGhvdyB0byBoYW5kbGUgdGhlIHJlY2Vp cHQgYnkgYSBQQ0Ugb2YgdGhpcyB2YWx1ZS4KPiAKPiBUaGUgYXV0aG9ycyB3aWxsIG5lZWQgdG8g ZG8gc29tZSB3b3JrIGhlcmUhCgpBZ3JlZWQsIGxvb2tpbmcgZm9yd2FyZCB0byB1cGRhdGVkIHRl eHQuCgo+IAo+PiA1LiBTZWN0aW9uIDcuNzoKPj4KPj4+ICBCYW5kd2lkdGg6IDMyIGJpdHMuICBU aGUgcmVxdWVzdGVkIGJhbmR3aWR0aCBpcyBlbmNvZGVkIGluIDMyIGJpdHMgaW4KPj4+ICBJRUVF IGZsb2F0aW5nIHBvaW50IGZvcm1hdCwgZXhwcmVzc2VkIGluIGJ5dGVzIHBlciBzZWNvbmQuICBS ZWZlciB0bwo+Pj4gIFNlY3Rpb24gMy4xLjIgb2YgW1JGQzM0NzFdIGZvciBhIHRhYmxlIG9mIGNv bW1vbmx5IHVzZWQgdmFsdWVzLgo+Pgo+PiBPdmVyIHdoYXQgdGltZSBjb25zdHJhaW50cyBhcmUg dGhpcyB2YWx1ZSBpbnRlbmRlZCB0byBiZSB2YWxpZD8gRHVlIHRvCj4+IHRoYXQgdHJhbnNtaXNz aW9uIG9mIHBhY2tldHMgY2FuIGJlIGJ1cnN0eSB0aGVyZSBpcyBuZWVkIGZvciBtb3JlCj4+IGlu Zm9ybWF0aW9uLiBTaG91bGRuJ3QgdGhpcyBiZSBhIHRva2VuIGJ1Y2tldCB0byBiZXR0ZXIgbW9k ZWwgdGhlIGRhdGEKPj4gbW92aW5nIGNhcGFiaWxpdHkgb2YgdGhlIHJlcXVlc3Q/Cj4gCj4gUGVy aGFwcyBJIGRvbid0IHVuZGVyc3RhbmQgeW91ciBxdWVzdGlvbiwgYnV0IGluIE1QTFMtVEUgYW5k IEdNUExTIHdlIAo+IGFyZSByZXNlcnZpbmcgYmFuZHdpZHRoLiBJbiB0aGlzIGNhc2UsIGl0IGlz IHVzdWFsIHRvIGNvbXBsZXRlIHRoZSAKPiBTZW5kZXJfVHNwZWMgdXNpbmcganVzdCB0aGUgUGVh ayBEYXRhIFJhdGUgZmllbGQgb2YgSW50LVNlcnYgb2JqZWN0cyAKPiAoc2VlIFtSRkMyMjEwXSkg dG8gaW5kaWNhdGUgdGhlIGNhcGFjaXR5IHRvIGJlIHJlc2VydmVkLiAoTm90ZSBvdGhlciAKPiBu b24tcGFja2V0IHRlY2hub2xvZ2llcyB2YXJ5IHRoaXMsIGJ1dCB0aGUgZWZmZWN0IGlzIHNpbWls YXIuKQoKSSBoYXZlIHdvcmtlZCBhIGJpdCB3aXRoIHNwZWNpZnlpbmcgYmFuZHdpZHRoIGxpbWl0 cyBmb3IgYXBwbGljYXRpb25zLgpBcyBwYWNrZXRzIGFyZSBkaXNjcmV0ZSBhbmQgbG93ZXIgbGF5 ZXJzIGhhdmUgc29tZSBiZWhhdmlvciByZWdhcmRpbmcgdG8KaG93IHRoZXkgc2VuZCB0aGVtLiBU aHVzLCB0aGVyZSBhcmUgc29tZSB0ZW1wb3JhbCBhZmZlY3RzIG9uIGJpdC1yYXRlLgpUaGF0IGlz IHdoeSB5b3UgbmVlZCB0byBzYXkgc29tZXRoaW5nIGFib3V0IG92ZXIgd2hhdCB0aW1lIGludGVy dmFsIHRoZQpiaXQtcmF0ZSBpcyB2YWxpZC4gSSB0aGluayB3aGF0IHlvdSBhcmUgdGFsa2luZyBh Ym91dCB3aXRoIGJhbmR3aWR0aCBpcwpzb21ldGhpbmcgdGhhdCBkZWxpdmVycyBhbiBhdmVyYWdl IG92ZXIgc29tZSByZWFzb25hYmxlIGxvbmcgdGltZSBzY2FsZQo+IDEwMCBtcykgaW4gcmVsYXRp b24gdG8gdGhlIGxpbmsgbGF5ZXJzIGJlaW5nIHVzZWQuIFRoYXQgaXMgd2h5IEkgCndvdWxkIGxp a2UgdG8gc2VlIGEgY2xlYXJlciBkZWZpbml0aW9uIG9mIHdoYXQgaXMgbWVhbnQgd2l0aCBiYW5k d2lkdGguCkkgaGF2ZSB0byByZWZsZWN0IHRoYXQgZXZlbiBSRkMgMjIxMCBkZWZpbml0aW9uIGlz IG5vdCBzdXBlciBjbGVhci4KRXNwZWNpYWxseSB3aGVuIG9uZSBhcmUgdGFsa2luZyBhYm91dCBz b21ldGhpbmcgdGhhdCBhcmUgdHJ5aW5nIHRvCnNwZWNpZnkgYSBmbG93IHRoYXQgYXJlIGEgc21h bGxlciBmcmFjdGlvbiBvZiB0aGUgdG90YWwgZGF0YSBtb3ZpbmcKY2FwYWJpbGl0eSBvZiB0aGUg cGF0aC4gSW4gdGhlc2UgY2FzZXMgdGhlIHRva2VuIGJ1Y2tldCByYXRlIGlzIHdoYXQgeW91CmFy ZSBhbGxvd2VkIHNlbmQgb24gYXZlcmFnZSBhcyBsb25nIHlvdSB0cnlpbmcgdG8gdXRpbGl6ZSBp dCB0byAxMDAlLAp0aGUgYnVja2V0IHNpemUgdGhlIGJ1cnN0aW5lc3MgYWxsb3dlZCBhbmQgdGhl IFBlYWsgREF0YSByYXRlIGlzIGxpbWl0ZWQKYnkgdGhlIGxpbmsgaW50ZXJmYWNlLiBFdmVuIHRo YXQgaXMgbm90IGNsZWFyIG9ubHkgaW4gYml0cy9zIGluc3RlYWQgaXQKaGFzIHRpbWluZyB0aGF0 IGRlcGVuZHMgb24gdGhlIGFjdHVhbCBpbnRlcmZhY2UgdGVjaG5vbG9neSBhbmQgaG93IHRoYXQK d29ya3MuCgpUaGF0IGlzIHdoeSBJIHdvdWxkIHByZWZlciB0aGF0IG9uZSBhdCBsZWFzdCByZWZl cmVuY2Ugd2hhdCBkZWZpbml0aW9uCm9uZSBpcyB1c2luZy4gU2VjdGlvbiAzLjEuMiBpbiBSRkMg MzQ3MSBpcyBhbHNvIG5vdCBwcm92aWRpbmcgYSBkZWZpbml0aW9uLgoKPiAKPj4gNi4gU2VjdGlv biA3Ljc6Cj4+Cj4+IFJlZmVyZW5jZSBmb3IgMzItYml0ICJJRUVFIGZsb2F0aW5nIHBvaW50IGZv cm1hdCI/IFBsZWFzZSBhZGQgaXQgYWxzbyAKPj4gb24gdGhlCj4+IG90aGVyIHBsYWNlcyB3aGVy ZSB5b3UgdXNlIHRoaXMgZm9ybWF0IGluIGRlZmluaXRpb25zLgo+IAo+IFllcy4KPiBJIGJlbGll dmUgdGhlIHJlZmVyZW5jZSBpcy4uLgo+IFtJRUVFXSAgICAgICJJRUVFIFN0YW5kYXJkIGZvciBC aW5hcnkgRmxvYXRpbmctUG9pbnQKPiAgICAgICAgICAgICAgICBBcml0aG1ldGljIiwgSUVFRSBT dGFuZGFyZCA3NTQtMTk4NSwgMTk4NQo+ICAgICAgICAgICAgICAgIChJU0JOIDEtNTU5My03NjUz LTgpLgo+IAoKR3JlYXQuCgo+PiA3LiBzZWN0aW9uIDcuMTE6Cj4+Cj4+IFBsZWFzZSBiZSBleHBs aWNpdCBhYm91dCB3aGljaCBvZiB0aGUgZG9jdW1lbnRzIHlvdSB1c2UgdGhlIGluY2x1ZGUtYW55 LAo+PiBleGNsdWRlLWFueSwgYW5kIGluY2x1ZGUtYWxsLiBIYXZpbmcgYnJvd3NlZCB0aHJvdWdo IFJGQyA0MDkwIGFuZCAzMjA5Cj4+IEkgY2FuJ3QgZmluZCBhIGRlZmluaXRpb24gb2Ygd2hhdCAi YXR0cmlidXRlIGZpbHRlcnMiIGFyZS4gU28gcGxlYXNlIAo+PiBpbmNsdWRlIGEKPj4gcmVmZXJl bmNlIHRvIHRoZSBkZWZpbml0aW9uIG9mIHRoZXNlIGFsc28uCj4gCj4gU2VjdGlvbiA0LjcuNCBv ZiBSRkMzMjA5IGdpdmVzIGEgZGV0YWlsZWQgZGVzY3JpcHRpb24gb2YgdGhlIHVzZSBvZiAKPiBy ZXNvdXJjZSBhZmZpbml0aWVzLgoKVGhhbmtzLCBteSBsYWNrIG9mIFJTVlAtVEUga25vd2xlZGdl IGlzIHNob3dpbmcuIEJ1dCBJIHN0aWxsIHRoaW5rIGEgcmVmCndvdWxkIGJlIGdvb2QgaW4gdGhl IGRvY3VtZW50LgoKPiAKPj4gOC4gVGhlIFN5bmNUaW1lcjoKPj4KPj4gSG93IGNhbiB0aGlzIHRp bWVyIHZhbHVlIGJlIGxvY2FsIG9ubHk/IFRoZSByZXF1ZXN0IHNlbmRlciBNVVNUIGtub3cKPj4g aG93IG11Y2ggdGltZSBpdCBoYXMgdG8gc3VwcGx5IGFsbCB0aGUgcmVxdWVzdCBiZWZvcmUgaXQg ZmFpbGluZyBkdWUgCj4+IHRvIHRoZQo+PiB0aW1lci4KPiAKPiBJdCBpcyBleHBlY3RlZCB0aGF0 IGEgUENDIHRoYXQgaGFzIGEgc2V0IG9mIHJlcXVlc3RzIHRvIHNlbmQgd2lsbCBnZXQgb24gCj4g d2l0aCBpdCBpbiBhIHJlbGF0aXZlbHkgdGltZWx5IG1hbm5lci4gVGhlIFN5bmNUaW1lciBpcyBh IGhvdXNlLWtlZXBpbmcgCj4gdGltZXIgbm90IGEgcHJvdG9jb2wgdGltZXIuIFRodXMgaXRzIHZh bHVlIG9uIGEgUENFIGlzIHNldCBsYXJnZSBlbm91Z2ggCj4gdG8gZW5zdXJlIHRoYXQgdGhlIFBD QyBoYXMgYSBnb29kIGNoYW5jZSBvZiBhY2hpZXZpbmcgdHJhbnNtaXNzaW9uLCBidXQgCj4gdGhh dCBpZiB0aGVyZSBpcyBzb21lIHByb2JsZW0gKG9yIGEgYnJva2VuIFBDQykgdGhlIFBDRSB3aWxs IGNsZWFuIHVwIAo+IGl0cyByZXNvdXJjZXMuCgpPa2F5LCBtYXliZSBzb21lIGV4cGxhbmF0aW9u IG9mIHRoYXQgaXMgbmVlZGVkLiBCb3RoIGluIHJlZ2FyZHMgdG8Kc2V0dGluZyB0aGlzIHRpbWVy IGFuZCB3aGF0IHJlc3BvbnNlIHRpbWVzIHRoYXQgeW91IHJlYWxseSBhcmUgZXhwZWN0aW5nLgoK PiAKPj4gU28gaWYgYSBQQ0UgdXNlcyBhIG5vbiBkZWZhdWx0Cj4gCj4gTm8gZGVmYXVsdCB2YWx1 ZSBpcyBkZWZpbmVkCj4gCj4+IHRoZW4gYSBmYWlsdXJlIG1heSBvY2N1ciBhbmQgdGhlIFBDQyBk b2Vzbid0IGtub3cgd2hhdCB2YWx1ZSBpcwo+PiB0aGUgb25lIHVzZWQuIFRoaXMgdmFsdWUgc2hv dWxkIGVpdGhlciBiZSBleHBsaWNpdCBzaWduYWxsZWQgYXQgc2Vzc2lvbgo+PiBvcGVuaW5nIG9y IGF0IGxlYXN0IGJlIGluY2x1ZGVkIGluIHRoZSBlcnJvciBtZXNzYWdlLgo+IAo+IEl0IGlzIG5v dCByZXF1aXJlZCB0aGF0IHRoZSBQQ0Mga25vdyB0aGUgdmFsdWUgb2YgdGhlIFBDRSdzIFN5bmNU aW1lci4gCj4gSW4gZ2VuZXJhbCwgaWYgdGhlIFBDQyBpcyB0b2xkIHRoYXQgdGhlIFN5bmNUb21l ciBoYXMgZXhwaXJlZCBvbiB0aGUgUENFIAo+IChhbmQgdGhhdCB0aGUgcHJldmlvdXMgcmVxdWVz dHMgaGF2ZSBiZWVuIGRpc2NhcmRlZCkgdGhlcmUgd2lsbCBiZSAKPiBsaXR0bGUgaXQgY2FuIGRv IGV4Y2VwdCwgbWF5YmUsIHNpbXBsaWZ5IGl0cyByZXF1ZXN0IGxpc3QgKG9yIGxlYXNlIGEgCj4g ZmFzdGVyIENQVSBmcm9tIGEgZnJpZW5kKS4KPiAKPiBJdCBzaG91bGQgYmUgY2xlYXIgdGhhdCB0 aGUgc2V0dGluZyBvZiBob3VzZS1rZWVwaW5nIHRpbWVycyBpcyBlbnRpcmVseSAKPiBhbiBpc3N1 ZSBmb3IgdGhlIG9wZXJhdG9yLCBhbmQgdGhhdCBzZXR0aW5nIGEgc21hbGwgdmFsdWUgaXMgYSBn cmVhdCByaXNrLgoKR29vZCwgdGhhdCBzaG91bGQgZml4IHRoaXMuCgo+IAo+PiA5LiBTZWN0aW9u IDcuMTQsIE92ZXJsb2FkIFBDRSBpbmRpY2F0aW9uLgo+Pgo+Pj4gICAgICAgIE9wdGlvbmFsbHks IGEgVExWIG5hbWVkIE9WRVJMT0FERUQtRFVSQVRJT04gbWF5IGJlIGluY2x1ZGVkIGluCj4+PiAg ICAgICAgdGhlIE5PVElGSUNBVElPTiBvYmplY3QgdGhhdCBzcGVjaWZpZXMgdGhlIHBlcmlvZCBv ZiB0aW1lCj4+PiAgICAgICAgZHVyaW5nIHdoaWNobm8gZnVydGhlciByZXF1ZXN0IHNob3VsZCBi ZSBzZW50IHRvIHRoZSBQQ0UuIE9uY2UKPj4+ICAgICAgICB0aGlzIHBlcmlvZCBvZiB0aW1lIGhh cyBlbGFwc2VkLCB0aGUgUENFIHNob3VsZCBubyBsb25nZXIgYmUKPj4+ICAgICAgICBjb25zaWRl cmVkIGluIGNvbmdlc3RlZCBzdGF0ZS4KPj4KPj4gVGhpcyBkZXNpZ24gc2VlbXMgdG8gc3VmZmVy IGZyb20gdGhlIHNhbWUgaXNzdWUgYXMgU0lQIGhhcyB3aXRoIGl0cyAKPj4gb3ZlcmxvYWQKPj4g cHJvdGVjdGlvbi4gRXNwZWNpYWxseSBpZiBJIHVuZGVyc3RhbmQgaXQgdGhhdCBhIFBDQyB0byBQ Q0UgcmVxdWVzdCAKPj4gY2FuIHJlc3VsdAo+PiBpbiB0aGUgUENFIHNlbmRpbmcgaXRzIG93biBy ZXF1ZXN0IGZ1cnRoZXIgdG8gdGhlIG5leHQgUENFIHRoYXQgbWF5IGJlCj4+IG92ZXJsb2FkZWQu IEluIHRoYXQgY2FzZSBpdCBzZWVtcyB0aGF0IHRoaXMgbWVjaGFuaXNtIG9ubHkgY2FuIHN0b3Ag Cj4+IHRoZSBQQ0MKPj4gZnJvbSBzZW5kaW5nIGFueSByZXF1ZXN0LCByYXRoZXIgdGhhbiB0aGUg b25lcyB0aGF0IGFmZmVjdCBhIAo+PiBwYXJ0aWN1bGFyIHVwc3RyZWFtCj4+IFBDRS4KPiAKPiBU aGUgY29uZ2VzdGlvbiBpbmRpY2F0aW9uIGlzIGEgc2luZ2xlIGhvcCBub3RpZmljYXRpb24uIFNv LCBpbiB0aGUgY2FzZSAKPiB0aGF0IGEgZG93bnN0cmVhbSBQQ0Ugd2FzIGNvbmdlc3RlZCwgaXQg d291bGQgaW5mb3JtIGl0cyB1cHN0cmVhbSAKPiBuZWlnaGJvciAoYWN0aW5nIGFzIGEgUENDKS4g VGhlIHVwc3RyZWFtIG5laWdoYm9yIGRvZXMgbm90IG5lZWQgdG8gCj4gcmVwb3J0IHRoZSBjb25n ZXN0aW9uIHRvIHRoZSBvcmlnaW5hdGluZyBQQ0MsIGl0IGNhbiBzaW1wbHkgc2VsZWN0IGEgCj4g ZGlmZmVyZW50IGRvd25zdHJlYW0gUENFLgo+IAo+IFRvb2xzIHRvIGFsbG93IGFuIG9yaWdpbmF0 aW5nIFBDQyB0byBkaXNjb3ZlciB0aGUgd2VsbC1iZWluZyBvZiAKPiBkb3duc3RyZWFtIFBDRXMg YXJlIGRlZmluZWQgaW4gZHJhZnQtaWV0Zi1wY2UtbW9uaXRvcmluZy0wMS50eHQKPiAKPj4gU2Vj b25kYXJ5LCBmb3IgcmVhbCBzYWZldHkgYWdhaW5zdCBQQ0MtPlBDRSBjb25nZXN0aW9uIGEgbWFu ZGF0b3J5Cj4+IGV4cG9uZW50aWFsIGJhY2stb2ZmIGZvciByZXF1ZXN0cyBzaG91bGQgYmUgc3Bl Y2lmaWVkLiBUaGF0IHdheSBhIFBDRQo+PiB0aGF0IHNpbXBseSBzdG9wcyByZXNwb25kaW5nIHRv IHJlcXVlc3Qgd2lsbCBzaGVkIGxvYWQuIFNlZW1zIHRoYXQgd2l0aAo+PiBUQ1AgdGhpcyB3b3Vs ZCBuZWVkIHRvIGJlIGJhc2VkIG9uIHRoZSByZXNwb25zZSB0aW1lIG9uIGFueSByZXF1ZXN0Cj4+ IGFuZCBzb21lIGxpbWl0YXRpb24gb24gaG93IG1hbnkgb3V0c3RhbmRpbmcgcmVxdWVzdCB0aGUg cmVxdWVzdG9yIG1heQo+PiBoYXZlLgo+Pgo+PiBJIGFtIGFsc28gd29ycmllZCBhYm91dCB0aGUg bGFjayBvZiBtYW5kYXRvcnkgdG8gaW1wbGVtZW50IHJlc3BvbnNlcwo+PiBhcyB0aGlzIGxpa2Vs eSB3aWxsIG1ha2UgaXQgaGFyZCB0byBkZXRlcm1pbmUgd2hhdCB3aWxsIGhhcHBlbiBpbiAKPj4g cmVhbC1saWZlCj4+IHdpdGggbXVsdGlwbGUgaW1wbGVtZW50YXRpb25zIG1ha2luZyBkaWZmZXJl bnQgY2hvaWNlcy4KPiAKPiBJIHRoaW5rIGl0IGlzIGltcG9ydGFudCB0byB1bmRlcnN0YW5kIHRo YXQgdGhlIG9iamVjdGl2ZSBpcyBub3QgdG8gCj4gZGVjb25nZXN0IHRoZSBQQ0UsIGJ1dCB0byBh bGxvdyB0aGUgUENDIHRvIGtub3cgYWJvdXQgY29uZ2VzdGlvbiBzbyB0aGF0IAo+IGl0IGNhbiB0 YWtlIGFjdGlvbi4gSW4gbWFueSBjYXNlcywgdGhlcmUgbWF5IGJlIG5vdGhpbmcgdGhlIFBDQyBj YW4gZG8gCj4gYmVjYXVzZSBpdCBoYXMgbm8gY2hvaWNlIG9mIFBDRS4gSW4gb3RoZXIgY2FzZXMg aXQgd2lsbCBiZSBhYmxlIHRvIAo+IHNlbGVjdCBhIGRpZmZlcmVudCBQQ0UuCj4gCj4gTm90ZSB0 aGF0IGEgUENFIHRoYXQgaW50ZW5kcyB0byBub3Qgc2VydmljZSByZXF1ZXN0cyBiZWNhdXNlIGl0 IGlzIAo+IG92ZXJsb2FkZWQgTVVTVCByZXBvcnQgdGhpcyB0byB0aGUgUENDLCBzbyBzaWxlbmNl IGlzIG5vdCBhbiBvcHRpb24uCgpZb3UgbWVhbiBmb3IgYWNjZXB0ZWQgcmVxdWVzdHMuIEJ1dCBm b3IgYW55IGhlYXZpbHkgbG9hZGVkIFBDRSBpdCBjb3VsZAppbiBmYWN0IHJlZnVzZSB0byByZWNl aXZlIGRhdGEuCgo+IAo+IEl0IGlzIHRydWUgdGhhdCBpbiBhIHNpZ25pZmljYW50bHkgYnVzeSBz eXN0ZW0sIHRoZSBjb25nZXN0aW9uIG9mIGEgUENFIAo+IG1heSBjYXVzZSBtdWx0aXBsZSBQQ0Nz IHRvIHN3aXRjaCB0byBhbm90aGVyIFBDRSBtYWtpbmcgaXQgY29uZ2VzdGVkIGFuZCAKPiBkZWNv bmdlc3RpbmcgdGhlIGZpcnN0IFBDRS4gSG93ZXZlciwgdGhlIHVzZSBvZiB0aGUgT3ZlcmxvYWRl ZC1EdXJhdGlvbiAKPiBUTFYgaXMgZGVzaWduZWQgdG8gYWxsb3cgdGhpcyBlZmZlY3QgdG8gYmUg ZGFtcGVuZWQuIEl0IGlzIHJlZ2FyZGVkIGFzIGEgCj4gbmV0d29yayBvcGVyYXRpb24gYW5kIHBs YW5uaW5nIGlzc3VlIGhvdyBhIFBDQyBzZWxlY3RzIHdoaWNoIFBDRSB0byB1c2UgCj4gdW5kZXIg bm9ybWFsIGNpcmN1bXN0YW5jZXMuIEluIHZpZXcgb2YgdGhpcywgdGhlIGJlaGF2aW9yIHdoZW4g dGhhdCBQQ0UgCj4gaXMgb3ZlcmxvYWRlZCBpcyBjbGVhcmx5IGFsc28gYW4gb3BlcmF0b3ItZGVw ZW5kZW50IGZlYXR1cmUgYW5kIHdlIHdvdWxkIAo+IGV4cGVjdCB0aGF0IG5vdCBhbGwgUENDcyB3 b3VsZCBhdXRvbWF0aWNhbGx5IHN3YXAgdG8gdGhlIHNhbWUgc2Vjb25kYXJ5IAo+IFBDRS4KClRo YW5rcywgdGhpcyBjbGFyaWZpZXMgYSBsb3Qgb24gaG93IHlvdSB3aGVyZSBjb25zaWRlcmluZyB0 aGlzIGdvaW5nIHRvCndvcmsuIFRvLCBtZSBpdCBzZWVtcyB0aGF0IGl0IHN0aWxsIGEgc3lzdGVt IHRoYXQgb25seSBpcyBpbnRlbmRlZCB0bwp3b3JrIGJ5IGdvb2QgY2FwYWNpdHkgZW5naW5lZXJp bmcgYW5kIHRoZSBwb3RlbnRpYWwgZm9yIGNvbXBsZXRlIApjb2xsYXBzZSBpbiBmYWlsdXJlIG9y IGhpZ2ggbG9hZCBjYXNlcyBkb2VzIHN0aWxsIGV4aXN0LiBJIGRvbid0IHF1aXRlIApmaW5kIHRo YXQgYWNjZXB0YWJsZSwgYXJlIHlvdSB3aWxsaW5nIHdpdGggbGl2aW5nIHdpdGggc3VjaCBhIHN0 YXRlPwoKPiAKPj4gMTAuIERpc2N1c3MgRGlzY3VzczoKPj4KPj4gVGhpcyBpcyBpbiBmYWN0IGEg ZXh0ZW5zaW9uIG9uIENocmlzJ3MgRGlzY3VzcyByZWdhcmRpbmcgdGhlIG5vcm1hdGl2ZQo+PiBk ZWZpbml0aW9uIG9mIHRoZSBmb3JtYWwgbGFuZ3VhZ2UgdXNlZCBpbiB0aGlzIGRvY3VtZW50Lgo+ PiBXaGF0IHRvb2xzIGhhcyBiZWVuIHVzZWQsIGlmIGFueSwgdG8gZGV0ZXJtaW5lIHRoZSB2YWxp ZGl0eSBvZiB0aGUKPj4gQk5GPyBIYXMgdGhlIHNoZXBoZXJkIG9yIEFEIGVuc3VyZWQgdGhhdCB0 aGF0IHRoZXNlIGNoZWNrcyB3aGVyZQo+PiBydW4gb24gdGhlIGN1cnJlbnQgdmVyc2lvbj8KPiAK PiBXZSBhcmUgZGlzY3Vzc2luZyB3aXRoIENocmlzIHdoYXQgc29ydCBvZiByZWZlcmVuY2UgaGUg cmVxdWlyZXMuCj4gCj4gQXMgaW4gYSBzZXBhcmF0ZSB0aHJlYWQgd2l0aCB5b3UsIHRoZSBsYWNr IG9mIGFueSBhdXRvbWF0ZWQgY2hlY2sgd2FzIAo+IGRlc2NyaWJlZCBpbiB0aGUgcHJvdG8gd3Jp dGUtdXAuIFRoZSBCTkYgdXNlZCBpcyBwYXJ0aWN1bGFybHkgdHJpdmlhbC4KPiAKPiBIYXZpbmcg bG9va2VkIGF0IHRoaXMgaW4gc29tZSBkZXRhaWwgYW5kIGV4cGVyaW1lbnRlZCB3aXRoIENocmlz JyB0b29sIAo+IGF0IGh0dHA6Ly93d3cuYXBwcy5pZXRmLm9yZy9hYm5mLmh0bWwgSSBjb25jbHVk ZSB0aGF0IHRoZSBmb3JtYXQgb2YgQk5GIAo+IHVzZWQgaGVyZSBvd2VzIG1vcmUgdG8gdGhlIGNv cmUgZGVmaW5pdGlvbiBvZiBCTkYgdGhhdCBpcyBjb25zaXN0ZW50bHkgCj4gdXNlZCBpbiBSb3V0 aW5nIEFyZWEgUkZDcywgYW5kIHZlcnkgbGl0dGxlIHRvIGFueXRoaW5nIGRlc2NyaWJlZCBpbiAK PiBSRkMyMjM0IGV0Yy4KCkdvb2QgdGhhdCB5b3UgYXJlIHdvcmtpbmcgb24gdGhhdC4gSSBhbSB1 c2luZyBCaWxsJ3Mgd2ViIHBhcnNlciB0aGF0IGlzCnF1aXRlIGdvb2QgZm9yIGNoZWNraW5nIFJG QyAyMjM0IEFCTkYuCgpodHRwOi8vd3d3LmZlbnJvbi5jb20vfmZlbm5lci9hYm5mLmNnaQoKCj4g Cj4gSGFyYWxkJ3MgcGVybCBzY3JpcHQgaXMgbm90IHN1aXRhYmxlIGZvciBtZSB0byBydW4uCj4g Cj4gSSBmb3VuZCBhIEJORiBwYXJzZXIgZnJvbSBTaWVtZW5zIGF0IFNvdXJjZWZvcmdlIGJ1dCBp dCBuZWVkcyB0byBiZSAKPiBidWlsdCBiZWZvcmUgaXQgY2FuIGJlIHJ1bi4gU2FtZSBmb3Igb3Ro ZXIgQk5GIHN5bnRheCBjaGVja2VycyBvbiB0aGUgV2ViLgo+IAo+IFRoZSBmdWxsIHRvdGFsaXR5 IG9mIG1hdGVyaWFsIHNwZWNpZmllZCBpbiBCTkYgaW4gdGhpcyBJLUQgaXMgcmVwcm9kdWNlZCAK PiBiZWxvdy4gQXMgeW91IHdpbGwgc2VlLCBpdCBpcyB0cml2aWFsIHRvIGNoZWNrIHRoaXMgYnkg ZXllLgoKSSBkb24ndCBhZ3JlZSB0aGF0IGl0IGlzIHRyaXZpYWwsIGJ1dCBJIGFncmVlIHRoYXQg aXQgaXMgcG9zc2libGUuCkhvd2V2ZXIsIHRoYXQgZG9lc24ndCBoZWxwIG1lIGlmIEkgZG9uJ3Qg a25vdyB0aGUgcnVsZXMuIFdoaWNoIGlzIHdoeQp5b3UgbmVlZCBhIGRlZmluaXRpb24gb2YgdGhl IGxhbmd1YWdlLgoKPiAKPiAKPiA8T3BlbiBNZXNzYWdlPiA6Oj0gPENvbW1vbiBIZWFkZXI+Cj4g ICAgICAgICAgICAgICAgICAgPE9QRU4+Cj4gCj4gPEtlZXBhbGl2ZSBNZXNzYWdlPiA6Oj0gPENv bW1vbiBIZWFkZXI+Cj4gCj4gPHN2ZWMtbGlzdD4gOjo9IDxTVkVDPiBbPHN2ZWMtbGlzdD5dCj4g Cj4gPG1ldHJpYy1saXN0PiA6Oj0gPE1FVFJJQz4gWzxtZXRyaWMtbGlzdD5dCj4gCj4gPHJlcXVl c3Q+IDo6PSA8UlA+Cj4gICAgICAgICAgICAgIDxFTkQtUE9JTlRTPgo+ICAgICAgICAgICAgICBb PExTUEE+XQo+ICAgICAgICAgICAgICBbPEJBTkRXSURUSD5dCj4gICAgICAgICAgICAgIFs8bWV0 cmljLWxpc3Q+XQo+ICAgICAgICAgICAgICBbPFJSTz4gWzxCQU5EV0lEVEg+XSBdCj4gICAgICAg ICAgICAgIFs8SVJPPl0KPiAgICAgICAgICAgICAgWzxMT0FELUJBTEFOQ0lORz5dCj4gCj4gPHJl cXVlc3QtbGlzdD4gOjo9IDxyZXF1ZXN0PiBbPHJlcXVlc3QtbGlzdD5dCj4gCj4gPFBDUmVxIE1l c3NhZ2U+IDo6PSA8Q29tbW9uIEhlYWRlcj4KPiAgICAgICAgICAgICAgICAgICAgWzxzdmVjLWxp c3Q+XQo+ICAgICAgICAgICAgICAgICAgICA8cmVxdWVzdC1saXN0Pgo+IAo+IDxhdHRyaWJ1dGUt bGlzdD4gOjo9IFs8TFNQQT5dCj4gICAgICAgICAgICAgICAgICAgICBbPEJBTkRXSURUSD5dCj4g ICAgICAgICAgICAgICAgICAgICBbPG1ldHJpYy1saXN0Pl0KPiAgICAgICAgICAgICAgICAgICAg IFs8SVJPPl0KPiAKPiA8cGF0aD4gOjo9IDxFUk8+IDxhdHRyaWJ1dGUtbGlzdD4KPiAKPiA8cGF0 aC1saXN0PiA6Oj0gPHBhdGg+IFs8cGF0aC1saXN0Pl0KPiAKPiA8cmVzcG9uc2U+IDo6PSA8UlA+ Cj4gICAgICAgICAgICAgICBbPE5PLVBBVEg+XQo+ICAgICAgICAgICAgICAgWzxhdHRyaWJ1dGUt bGlzdD5dCj4gICAgICAgICAgICAgICBbPHBhdGgtbGlzdD5dCj4gCj4gPHJlc3BvbnNlLWxpc3Q+ IDo6PSA8cmVzcG9uc2U+IFs8cmVzcG9uc2UtbGlzdD5dCj4gCj4gPFBDUmVwIE1lc3NhZ2U+IDo6 PSA8Q29tbW9uIEhlYWRlcj4KPiAgICAgICAgICAgICAgICAgICAgPHJlc3BvbnNlLWxpc3Q+Cj4g Cj4gPHJlcXVlc3QtaWQtbGlzdD4gOjo9IDxSUD4gPHJlcXVlc3QtaWQtbGlzdD4KPiAKPiA8bm90 aWZpY2F0aW9uLWxpc3Q+IDo6PSA8Tk9USUZJQ0FUSU9OPiA8bm90aWZpY2F0aW9uLWxpc3Q+Cj4g Cj4gPG5vdGlmeT4gOjo9IFs8cmVxdWVzdC1pZC1saXN0Pl0KPiAgICAgICAgICAgICA8bm90aWZp Y2F0aW9uLWxpc3Q+Cj4gCj4gPG5vdGlmeS1saXN0PiA6Oj0gPG5vdGlmeT4gWzxub3RpZnktbGlz dD5dCj4gCj4gPFBDTnRmIE1lc3NhZ2U+IDo6PSA8Q29tbW9uIEhlYWRlcj4KPiAgICAgICAgICAg ICAgICAgICAgPG5vdGlmeS1saXN0Pgo+IAo+IDxlcnJvci1vYmplY3QtbGlzdD4gOjo9IDxQQ0VQ LUVSUk9SPiBbPGVycm9yLW9iamVjdC1saXN0Pl0KPiAKPiA8cmVxdWVzdC1pZC1saXN0PiA6Oj0g PFJQPiBbPHJlcXVlc3QtaWQtbGlzdD5dCj4gCj4gPGVycm9yPiA6Oj0gWzxyZXF1ZXN0LWlkLWxp c3Q+XQo+ICAgICAgICAgICAgPGVycm9yLW9iamVjdC1saXN0Pgo+IAo+IDxlcnJvci1saXN0PiA6 Oj0gPGVycm9yPiBbPGVycm9yLWxpc3Q+XQo+IAo+IDxQQ0VyciBNZXNzYWdlPiA6Oj0gPENvbW1v biBIZWFkZXI+Cj4gICAgICAgICAgICAgICAgICAgICggPGVycm9yLW9iamVjdC1saXN0PiBbPE9w ZW4+XSApIHwgPGVycm9yPgo+ICAgICAgICAgICAgICAgICAgICBbPGVycm9yLWxpc3Q+XQo+IAo+ IDxDbG9zZSBNZXNzYWdlPjo6PSA8Q29tbW9uIEhlYWRlcj4KPiAgICAgICAgICAgICAgICAgICA8 Q0xPU0U+Cj4gCj4gCj4gCgoKQ2hlZXJzCgpNYWdudXMgV2VzdGVybHVuZAoKSUVURiBUcmFuc3Bv cnQgQXJlYSBEaXJlY3RvciAmIFRTVldHIENoYWlyCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KTXVsdGltZWRpYSBU ZWNobm9sb2dpZXMsIEVyaWNzc29uIFJlc2VhcmNoIEVBQi9UVk0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpFcmlj c3NvbiBBQiAgICAgICAgICAgICAgICB8IFBob25lICs0NiA4IDQwNDgyODcKRsOkcsO2Z2F0YW4g NiAgICAgICAgICAgICAgICB8IEZheCAgICs0NiA4IDc1NzU1NTAKUy0xNjQgODAgU3RvY2tob2xt LCBTd2VkZW4gfCBtYWlsdG86IG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K UGNlIG1haWxpbmcgbGlzdApQY2VAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9wY2UK