From jpv@cisco.com Fri May 21 23:46:35 2010 Return-Path: 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 16D7C3A6BBA for ; Fri, 21 May 2010 23:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.27 X-Spam-Level: X-Spam-Status: No, score=-9.27 tagged_above=-999 required=5 tests=[AWL=1.328, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 2ag9qJuALghB for ; Fri, 21 May 2010 23:46:34 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 52FB73A6BB8 for ; Fri, 21 May 2010 23:46:34 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkGAP4a90urR7Hu/2dsb2JhbACBP5BBjBVxpGaZLIUSBA X-IronPort-AV: E=Sophos;i="4.53,282,1272844800"; d="scan'208,217";a="133358993" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 22 May 2010 06:46:28 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o4M6kRBO006531 for ; Sat, 22 May 2010 06:46:27 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 22 May 2010 08:46:26 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 22 May 2010 08:46:26 +0200 Message-Id: From: JP Vasseur To: pce@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-219--149157583 Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 22 May 2010 08:46:25 +0200 References: <20100521205455.GA4425@amsl.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 22 May 2010 06:46:26.0534 (UTC) FILETIME=[802E8860:01CAF97A] Subject: [Pce] Fwd: Mail Flood Last Night Resolved 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: , X-List-Received-Date: Sat, 22 May 2010 06:46:35 -0000 --Apple-Mail-219--149157583 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Begin forwarded message: > From: "Glen Barney (AMS)" > Date: May 21, 2010 10:54:55 PM CEDT > To: ietf-announce@ietf.org, ietf@ietf.org > Subject: Mail Flood Last Night Resolved > > All - > > The previously-announced flood of email has been resolved and > cleared, and > all mail has been delivered. Mail flow now appears to be back to > normal, > and we will continue to monitor to ensure that this remains the case. > > Thank you for your patience. > > Glen Barney > IT Director > AMS (IETF Secretariat) --Apple-Mail-219--149157583 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

Begin = forwarded message:

From: = "Glen Barney (AMS)" <glen@amsl.com>
Date: = May 21, 2010 10:54:55 PM CEDT
Subject: = Mail Flood Last Night Resolved

All = -

The previously-announced flood of email has been resolved and = cleared, and
all mail has been delivered.  Mail flow now appears = to be back to normal,
and we will continue to monitor to ensure that = this remains the case.

Thank you for your patience.

Glen = Barney
IT Director
AMS (IETF = Secretariat)

= --Apple-Mail-219--149157583-- From root@core3.amsl.com Tue May 25 12:15:14 2010 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 391C83A69FA; Tue, 25 May 2010 12:15:07 -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: <20100525191514.391C83A69FA@core3.amsl.com> Date: Tue, 25 May 2010 12:15:04 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-pcep-p2mp-extensions-11.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: , X-List-Received-Date: Tue, 25 May 2010 19:15:26 -0000 --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 : Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths Author(s) : Q. Zhao, et al. Filename : draft-ietf-pce-pcep-p2mp-extensions-11.txt Pages : 31 Date : 2010-05-25 Point-to-point Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of P2MP TE LSPs. This document describes extensions to the PCE communication Protocol (PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-p2mp-extensions-11.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-pcep-p2mp-extensions-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-25120451.I-D@ietf.org> --NextPart-- From daniel@olddog.co.uk Tue May 25 13:32:17 2010 Return-Path: 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 B6B5A3A6A82 for ; Tue, 25 May 2010 13:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.728 X-Spam-Level: X-Spam-Status: No, score=-0.728 tagged_above=-999 required=5 tests=[AWL=1.271, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] 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 9oXcFg3x10Xp for ; Tue, 25 May 2010 13:32:16 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 5D5BA3A6A48 for ; Tue, 25 May 2010 13:32:16 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id o4PKVmB7031220 for ; Tue, 25 May 2010 21:31:53 +0100 Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id o4PKVl21031214 for ; Tue, 25 May 2010 21:31:48 +0100 From: "Daniel King" To: References: <20100525191514.391C83A69FA@core3.amsl.com> In-Reply-To: <20100525191514.391C83A69FA@core3.amsl.com> Date: Tue, 25 May 2010 21:31:48 +0100 Message-ID: <005c01cafc49$4d7d9b50$e878d1f0$@co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: Acr8PqWa1rIHG8+xSECx2G+HmXlrUgACli0w Content-Language: en-gb Subject: Re: [Pce] I-D Action:draft-ietf-pce-pcep-p2mp-extensions-11.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: , X-List-Received-Date: Tue, 25 May 2010 20:32:17 -0000 Hi PCE'rs, The authors of pcep-p2mp just submitted a new version of our document to address 4 discusses and some IANA clarifications: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-p2mp-extensions/ Thanks, pcep-p2mp co-authors. -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: 25 May 2010 20:15 To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: I-D Action:draft-ietf-pce-pcep-p2mp-extensions-11.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths Author(s) : Q. Zhao, et al. Filename : draft-ietf-pce-pcep-p2mp-extensions-11.txt Pages : 31 Date : 2010-05-25 Point-to-point Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of P2MP TE LSPs. This document describes extensions to the PCE communication Protocol (PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-p2mp-extensions-11.t xt 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. From ogondio@tid.es Wed May 26 08:29:16 2010 Return-Path: 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 3070C3A6961 for ; Wed, 26 May 2010 08:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.544 X-Spam-Level: X-Spam-Status: No, score=-1.544 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 gfI473nkGiV5 for ; Wed, 26 May 2010 08:29:11 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by core3.amsl.com (Postfix) with ESMTP id 1AD1A3A6944 for ; Wed, 26 May 2010 08:29:10 -0700 (PDT) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0L3100CRS9OC2R@tid.hi.inet> for pce@ietf.org; Wed, 26 May 2010 17:29:00 +0200 (MEST) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad1.hi.inet ([192.168.0.1]) with mapi; Wed, 26 May 2010 17:29:00 +0200 Date: Wed, 26 May 2010 17:28:56 +0200 From: =?iso-8859-1?Q?Oscar_Gonz=E1lez_de_Dios?= To: "pce@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_MoHOSVmy2KbWckUsHrmwjQ)" Content-language: es-ES Accept-Language: es-ES, en-US Thread-topic: question about draft-king-pce-hierarchy-fwk-03 Thread-index: Acr86CeTn10UtEuVR96ieW+iDzG8rw== acceptlanguage: es-ES, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [Pce] question about draft-king-pce-hierarchy-fwk-03 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: , X-List-Received-Date: Wed, 26 May 2010 15:29:16 -0000 --Boundary_(ID_MoHOSVmy2KbWckUsHrmwjQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Dear authors/all I have a few comments about draft-king-pce-hierarchy-fwk-03= . It this draft, it is specified in section 3.1 the applicability of BRPC w= hen the Domain Path is Not Known. Bellow are my comments with regards to th= e text in the draft: - "When the ingress PCE has received a VSPT from each of its neigh= boring domains it is able to select the optimum path": Comment #1: Some of = the neighboring domains may not send a VSPT (they may not be connected to a= ny other domain, or just cannot reach the domain of the destination LSP). T= hus, the ingress PCE should not expect an answer from each of the neighbori= ng domain, but only from some. In that case, should there be a timer set wh= en the first answer (VSPT) arrives, and when either the timer is over or al= l the neighboring domains have answered, then select the path? - "Each PCE in turn constructs a VSPT and passes it on to all of i= ts neighboring PCEs". Comment #2: Clearly, the set of domains that are alre= ady part of the VSPT should be excluded when passing the VSPT. Comment #3: = A intermediate PCE could receive VPSTs from different domains. What should= it do then? Complete all the VPST it receives and send them? Send just the= first? And in case the PCE send multiple VSPTS (each would be a different = sequence of domains), then the ingress PCE should receive all of them befor= e selecting the optimum path. In such case, the timer mechanism could fit..= .. - "The ingress PCE sends the path computation request direct to th= e PCE responsible for the domain containing the destination node (the egre= ss PCE)". Comment #4: Do you assume that the PCEs knows how to reach all th= e other PCEs? I assume that, at least a PCE must know how to reach its neig= hboring PCEs. If the PCE only knows that information, the request should be= flooded until it reaches the egress PCE. Best Regards, =D3scar --Boundary_(ID_MoHOSVmy2KbWckUsHrmwjQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

Dear authors/all<= /p>

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 I have a few comments about draft-king-pce-hierarchy-fwk-03. It this draft, it is specified in section = 3.1 the applicability of BRPC when the Domain Path is Not Known. Bellow are my comments with regards to the text in the draft:

 

-&nb= sp;         “When the ingress P= CE has received a VSPT from each of its neighboring domains it is able to select t= he optimum path”: Comment #1: Some of the neighboring domains may not se= nd a VSPT (they may not be connected to any other domain, or just cannot reach t= he domain of the destination LSP). Thus, the ingress PCE should not expect an answer = from each of the neighboring domain, but only from some. In that case, should th= ere be a timer set when the first answer (VSPT) arrives, and when either the ti= mer is over or all the neighboring domains have answered, then select the path?=

-&nb= sp;         “Each PCE in turn constructs a VSPT and passes it on to all of its neighboring PCEs”. C= omment #2: Clearly, the set of domains that are already part of the VSPT should be excluded when passing the VSPT. Comment #3:=A0 A intermediate PCE could rec= eive VPSTs from different domains. What should it do then? Complete all the VPST it receives and send them? Send just the first? And in case the PCE send multi= ple VSPTS (each would be a different sequence of domains), then the ingress PCE should receive all of them before selecting the optimum path. In such case,= the timer mechanism could fit….

-&nb= sp;         “The ingress PCE se= nds the path computation request direct to the =A0PCE responsible for the domai= n containing the destination node (the egress PCE)”. Comment #4: Do you assume that the PCEs knows how to reach all the other PCEs? I assume that, = at least a PCE must know how to reach its neighboring PCEs. If the PCE only kn= ows that information, the request should be flooded until it reaches the egress PCE.

 

Best = Regards,

=  

=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =D3scar

--Boundary_(ID_MoHOSVmy2KbWckUsHrmwjQ)-- From adrian@olddog.co.uk Thu May 27 04:42:33 2010 Return-Path: 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 AB1A53A6AC3 for ; Thu, 27 May 2010 04:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.56 X-Spam-Level: **** X-Spam-Status: No, score=4.56 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, FRT_BELOW2=2.154, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1, 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 MISsHtzQO6ul for ; Thu, 27 May 2010 04:42:32 -0700 (PDT) Received: from asmtp3.iomartmail.com (unknown [62.128.193.159]) by core3.amsl.com (Postfix) with ESMTP id 664D13A6A91 for ; Thu, 27 May 2010 04:42:32 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id o4RBg6Rf024979; Thu, 27 May 2010 12:42:11 +0100 Received: from your029b8cecfe ([207.59.110.215]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id o4RBg4sw024973; Thu, 27 May 2010 12:42:05 +0100 Message-ID: <91E2B308E7EC4C05945E57BF42A60D83@your029b8cecfe> From: "Adrian Farrel" To: =?iso-8859-1?Q?Oscar_Gonz=E1lez_de_Dios?= References: Date: Thu, 27 May 2010 12:41:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Cc: pce@ietf.org Subject: Re: [Pce] question about draft-king-pce-hierarchy-fwk-03 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: , X-List-Received-Date: Thu, 27 May 2010 11:42:33 -0000 Hello Oscar, Thanks for reading. > I have a few comments about draft-king-pce-hierarchy-fwk-03. It this > draft, > it is specified in section 3.1 the applicability of BRPC when the Domain > Path > is Not Known. Bellow are my comments with regards to the text in the > draft: > > - "When the ingress PCE has received a VSPT from each of its neighboring > domains it is able to select the optimum path": Comment #1: Some of the > neighboring domains may not send a VSPT (they may not be connected > to any other domain, or just cannot reach the domain of the destination > LSP). Thus, the ingress PCE should not expect an answer from each of > the neighboring domain, but only from some. In that case, should there > be a timer set when the first answer (VSPT) arrives, and when either > the > timer is over or all the neighboring domains have answered, then select > the path? Good catch. Yes, we only described the positive case. We should add two other cases: 1. The PCE in the neighboring domain cannot find a path to the egress (for whatever reason) and returns an error for the PCReq. 2. The PCE in the neighboring domain fails to respond (a timeout pops). We should add a sentnce to cover this. > - "Each PCE in turn constructs a VSPT and passes it on to all of its > neighboring PCEs". > Comment #2: Clearly, the set of domains that are already part of the > VSPT should be excluded when passing the VSPT. Well, indeed. There are two ways of excluding. 1. If a PCE knows the domain is already in the path, it does not send a VPST to a neighboring PCE for that domain. 2. If a PCE receives a VPST and finds its own domain already in the path it can exclude the received VPST. Although the first of these looks cleaner, the second works better in cases where one (neighbor) PCE may act for multiple domains. I think we need to explore this a little. > Comment #3: A intermediate PCE could receive VPSTs from > different domains. What should it do then? Complete all the VPST > it receives and send them? Send just the first? And in case the PCE > send multiple VSPTS (each would be a different sequence of > domains), then the ingress PCE should receive all of them before > selecting the optimum path. In such case, the timer mechanism > could fit.... Yes. I think you are exposing some of the big issues with using BRPC in this way. The more "meshy" the network of domains, the harder it is to run this process. Comments 2 and 3 show up problems of impracticallity. A timer could certainly be used to address this issue. Each PCE, in turn, would run such a timer meaning that the PCEs that have more PCEs down stream need to run longer timers. This gets quite messy because a PCE might have two domain paths to the egress domain. If one path has a small number of domains, the PCE will receive the VPST a long time before it receives the second. How does it know how long to wait? We should try to add some discussion of this, but I note that we are not (in section 3.1) trying to show that BRPC can be used in any arbitrary domain mesh when the domain path is not known. In fact, we are trying to explain why it may be very inappropriate. > - "The ingress PCE sends the path computation request direct to the PCE > responsible for the domain containing the destination node (the egress > PCE)". > Comment #4: Do you assume that the PCEs knows how to reach all the > other PCEs? I assume that, at least a PCE must know how to reach its > neighboring PCEs. If the PCE only knows that information, the request > should be flooded until it reaches the egress PCE. When you say "know how to reach" I presume you mean "know the identity and address of". And, yes, this is exactly one of the problems. In small domain meshes, this is not unreasonable, but some mechnism (config or flooding) would be needed. In large domain meshes, this would be less reasonable. You highlight yet another reason why BRPC would not be so appropriate. It is clear to me that we need to expand on the final paragraph of 3.1 that currently says: Clearly this mechanism (which could be called path computation flooding) has significant scaling issues. It could be improved by the application of policy and filtering, but such mechanisms are not simple and would still leave scaling concerns. It seems to me that we should also add a section on "Forward Recursive Path Computation" in this case. This form of "flooding" VPSTs helps "discover" the destination domain since each PCE only needs to know its neighbors, but pruning the VPST during the process is harder, so there is more overhead. Anyway, as I say, the purpose of section 3 is to highlight that BRPC is not a viable solution in the case where the domain path is unknown and the domains are arranged in a mesh. Cheers, Adrian From becky.vandorn@computerforensicshow.com Thu May 27 14:44:36 2010 Return-Path: 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 AAA723A6950 for ; Thu, 27 May 2010 14:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.903 X-Spam-Level: X-Spam-Status: No, score=0.903 tagged_above=-999 required=5 tests=[AWL=-0.598, BAYES_99=3.5, GB_I_LETTER=-2, 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 5uGgj74h-Kmb for ; Thu, 27 May 2010 14:44:34 -0700 (PDT) Received: from computerforensicshow.com (computerforensicshow.com [198.171.167.178]) by core3.amsl.com (Postfix) with ESMTP id E7CF23A6983 for ; Thu, 27 May 2010 14:44:33 -0700 (PDT) Received: from p2e90gwm (ool-44c631e5.dyn.optonline.net [68.198.49.229]) (authenticated bits=0) by computerforensicshow.com (8.14.4/8.14.4) with ESMTP id o4RL8cIP005278; Thu, 27 May 2010 21:08:41 GMT Message-ID: <933D605A9F6342669880D2C51C8A5D4C@p2e90gwm> From: "Becky Vandorn" To: "Becky Vandorn" Date: Thu, 27 May 2010 17:07:31 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_018F_01CAFDBF.183E08E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Mailman-Approved-At: Fri, 28 May 2010 08:04:14 -0700 Subject: [Pce] Call for Papers/ San Francisco, CA 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: , X-List-Received-Date: Thu, 27 May 2010 21:44:36 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_018F_01CAFDBF.183E08E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable CALL FOR PAPERS: The Computer Forensics ShowCALL FOR PAPERS: The = Computer Forensics Show =20 November 1-2, 2010 . Fort Mason Convention Center . San Francisco, CA =20 IMAGINE THE ABILITY TO VIEW ANYTHING THAT EVER APPEARED ON ALMOST ANY = COMPUTER THE COMPUTER FORENSICS SHOW IS THE "DON'T MISS" EVENT OF THE YEAR FOR = ALL =20 LEGAL, ACCOUNTING, IT SECURITY, RISK MANAGEMENT, AND LAW ENFORCEMENT = PROFESSIONALS =20 Forensic Trade Shows, LLC is proud to announce The Computer Forensics = Show, November 1st and 2nd, 2010 at the Fort Mason Convention Center, = San Francisco, CA. =20 The Computer Forensics Show is geared to meet the needs of industry = professionals by providing detailed information regarding the changes = and advancements in the IT security marketplace. =20 The event will highlight exhibits from some of the leading companies in = the industry, complemented by a comprehensive conference program to = provide attendees with important information about the latest = technological advancement, ideas and practical information available = today. =20 The Computer Forensics Show offers its speakers tremendous opportunities = for exposure and recognition as industry leader. Your session will = attract many technical professionals interested in learning from your = example, expertise and experience. In appreciation of your contributions = as a conference speaker, we provide the following benefits: =20 . Complementary speaker registration to the exhibition and full = conference pass; . Complementary session passes for your colleagues to attend your = session (upon request); . Presenters will receive three promotional conference passes to = promote their session. =20 Please visit our speaker page from this year's show at = http://www.computerforensicshow.com/speakers_panels.htm.=20 =20 There are 6 main tracks in the conference=20 =20 Forensic Accounting - Fraud, Financial Investigations, Compliance, Best = Practices, Litigation. Forensic accounting is the number one growing = field in accounting today. Legal (A) - EDD, including Litigation and Best Practice Issues. Legal (B) - Emerging Technologies/Litigation, Data/Records Management, = Reporting, and Privacy. IT Security - For organizations that are just beginning to encounter = security issues and deals with more broad issues effecting organizations = today. IT Security Advanced Track - Encompasses more complex and in-depth = issues and can highlight the need for additional training. Cyber-crime, Terrorism, and Information Warfare Track - Cyber crime and = terrorism as it relates to Homeland Security, public and corporate = policy, risk management, and the protection of our nation's critical = infrastructures. =20 The first and last sessions of each track on both days will be vendor = only and will be open to all attendees at no charge. =20 The Show's Conference Department is asking industry executives to submit = brief abstracts on some current topics to be presented to attendees in a = solo presentation or as part of a conference panel. If you are = interested, please review the following guidelines and contact = information, and note the submission deadlines for the conference. =20 =20 Guidelines =20 Formatting: . Paper size - letter/8.5" width X 11.0" height. . Margins - top/bottom/left/right - 1". . Font - Times New Roman 11 point. . Paragraph Spacing - single spaced.=20 . The submission should be sent in Microsoft Word. =20 The submission must include: . The Presentation Title . Author Name(s) . Title . Company . Speaker Contact Information: Address . Phone Number . E-mail = Address . Keywords (4-8 words) . ABSTRACT* The presentation abstract should outline your = presentation and what attendees would learn. Please remember that all = the content must be strictly educational and marketing oriented papers = will not be accepted. The presentation has to be oriented for: = Accounting, Legal, IT Security, Risk Management, and Law Enforcement = professionals. . BIOGRAPHY* The speakers biography should be 60 to 100 words in = paragraph form. These may include present position, titles, areas of = professional expertise, experience, research interests, major = publications, degrees, etc. =20 * Abstract and Biography information should not extend more than one = page and will be used for our Show Guide and Website if speaking. =20 Please do not hesitate to include additional material regarding your = presentation(s) for better evaluation. =20 The total presentation length is 75 minutes: speech ~ 50-60min; Q&A ~ = 15-20min. =20 SUBMISSION DEADLINE: July 20th, 2010.=20 =20 Submissions will be evaluated for originality, significance of the work, = technical content, and interest to a wide audience. Speakers may also be = grouped into panels when there are overlapping topics of interest. =20 Submissions should be in Microsoft Word and sent to Natalia Manley at = nmanley@computerforensicshow.com. Please note that due to the expected = volume of submissions, Forensic Trade Shows, LLC will only contact = speakers who are selected.=20 =20 By agreeing to speak, you grant one-time permission to Forensic Trade = Shows, LLC to retain and publish a copy of your presentation. The = copyright and all other rights to the presentation remain with the = author(s). All rights to and use of The Computer Forensics Show name and = logos are retained exclusively by its respective party. =20 A copy of the presentation materials should be submitted to us no later = than August 20th, 2010. It should be sent in Microsoft PowerPoint (.ppt) = format on the Computer Forensics Show template that will be provided to = you prior to the conference. If you use any animation or active content, = please include that as well. For reliability and security purposes, all = presentations will be preloaded onto the presentation computers at the = conference. =20 Note: Substitutions for speakers are only allowed under emergency = circumstances, and tradeshow management must be immediately notified of = any changes. All participants are selected at the discretion of show = management. =20 Suggested topics include Accountant Malpractice Claims=20 Anonymity and Proxies Authentication and Access Control=20 Civil Litigation=20 Class Action Disputes=20 Computer Crime and Information Warfare Construction Solutions=20 Corporate Governance=20 Corporate Information=20 Corporate Risk and Security=20 Criminal Fraud and Deception Cases Cyberbullying Cyber Forensics=20 Damage Assessment=20 Digital Forensic Case Studies=20 Digital Forensic Processes and Workflow Models=20 Digital Forensics and Internet Digital Law=20 =20 Digital Rights Management (DRM) Digital Signatures=20 E-Discovery=20 Employee Internet Abuse=20 Employment and Family Law Cases=20 Encryption and Decryption Environmental Litigation=20 Financial Investigations and Forensic Accounting=20 Forensics Accounting and the Internet Fraud Investigation=20 General Commercial Disputes=20 Identity Theft Industrial Espionage=20 Insurance Claims and Digital Forensics Integrity of Archival Data=20 Intellectual Property Claims=20 International Risk and Investigations Intrusion Detection=20 IT Security and Compliance=20 Legal, Ethical and Policy Issues=20 Mobile Forensics=20 More General Criminal Cases=20 Network Forensics=20 New Firewall Technologies=20 Portable Electronic Device Forensics=20 Post-Acquisition Disputes=20 Privacy and Data Mining=20 Privacy issues in digital forensics Privacy Leakage Case Studies=20 Privacy Policy Enforcement=20 Security Education and Training=20 Smart Card Applications=20 Stealth Data=20 Steganography Stylometrics and Author Attribution Terrorist Use of the Internet=20 Unauthorized Disclosure of Corporate Information =20 Additional classes will also be available to attendees such as:=20 Computer Forensics - CCFE Boot Camp - 5 Days Advanced Computer Forensics - 5 Days Cell Phone Forensics - 2 Days Live Memory Forensics - 2 Days Linux Forensics - 3 Days Mac Forensics - 3 Days Reverse Engineering Malware - CREA Boot Camp - 5 Days Ethical Hacking - CPT/CEH Boot Camp - 5 Days =20 If you have any questions about The Computer Forensics Conferences, = please send us an e-mail to info@computerforensicshow.com.=20 =20 # # # =20 To be removed from the mailing list please send us an e-mail to: = remove@computerforensicshow.com. ------=_NextPart_000_018F_01CAFDBF.183E08E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable CALL FOR = PAPERS: The Computer Forensics Show
CALL=20 FOR PAPERS: The Computer Forensics = Show

 

November=20 1-2, 2010=20 =95 Fort=20 Mason=20 Convention=20 Center=20 =95 San=20 Francisco,=20 CA

 

IMAGINE=20 THE ABILITY TO VIEW ANYTHING THAT EVER APPEARED ON ALMOST ANY=20 COMPUTER

THE=20 COMPUTER FORENSICS SHOW IS THE "DON'T MISS" EVENT OF THE YEAR FOR=20 ALL

 

LEGAL,=20 ACCOUNTING, IT SECURITY, RISK MANAGEMENT, AND LAW ENFORCEMENT=20 PROFESSIONALS

 

Forensic=20 Trade Shows, LLC is proud to announce The Computer Forensics Show,=20 November=20 1st and 2nd, 2010=20 at the Fort=20 Mason=20 Convention=20 Center,=20 San=20 Francisco,=20 CA.

 

The=20 Computer Forensics Show is geared to meet the needs of industry = professionals by=20 providing detailed information regarding the changes and advancements in = the IT=20 security marketplace.

 

The=20 event will highlight exhibits from some of the leading companies in the=20 industry, complemented by a comprehensive conference program to provide=20 attendees with important information about the latest technological = advancement,=20 ideas and practical information available = today.

 

The=20 Computer Forensics Show offers its speakers tremendous opportunities for = exposure and recognition as industry leader. Your session will attract = many=20 technical professionals interested in learning from your example, = expertise and=20 experience. In appreciation of your contributions as a conference = speaker, we=20 provide the following benefits:

 

   =95 Complementary = speaker=20 registration to the exhibition and full conference=20 pass;

   =95 Complementary = session passes for=20 your colleagues to attend your session (upon=20 request);

   =95 Presenters will = receive three=20 promotional conference passes to promote their=20 session.

 

Please=20 visit our speaker page from this year's show at http://w= ww.computerforensicshow.com/speakers_panels.htm.=20

 

There=20 are 6 main tracks in the conference =

 

Forensic=20 Accounting =96=20 Fraud, Financial Investigations, Compliance, Best Practices, Litigation. = Forensic accounting is the number one growing field in accounting=20 today.

Legal=20 (A) =96=20 EDD, including Litigation and Best Practice = Issues.

Legal=20 (B) =96=20 Emerging Technologies/Litigation, Data/Records Management, Reporting, = and=20 Privacy.

IT=20 Security =96=20 For organizations that are just beginning to encounter security issues = and deals=20 with more broad issues effecting organizations=20 today.

IT=20 Security Advanced Track=20 =96=20 Encompasses more complex and in-depth issues and can highlight the need = for=20 additional training.

Cyber-crime,=20 Terrorism, and Information Warfare Track =96=20 Cyber crime and terrorism as it relates to Homeland Security, public and = corporate policy, risk management, and the protection of our nation=92s = critical=20 infrastructures.

 

The=20 first and last sessions of each track on both days will be vendor = only=20 and will be open to all attendees at no = charge.

 

The=20 Show=92s Conference Department is asking industry executives to submit = brief=20 abstracts on some current topics to be presented to attendees in a solo=20 presentation or as part of a conference panel. If you are interested, = please=20 review the following guidelines and contact information, and note the = submission=20 deadlines for the conference. 

 

Guidelines

 

Formatting:

  =20 =95 Paper size - letter/8.5" width X 11.0"=20 height.

   =95 Margins - = top/bottom/left/right=20 =96 1".

   =95 Font - Times New = Roman 11=20 point.

   =95 Paragraph Spacing - = single=20 spaced.

   =95 The submission = should be sent in=20 Microsoft Word.

 

The=20 submission must include:

   =95 The Presentation=20 Title

   =95 Author Name(s) =95 = Title =95=20 Company

   =95 Speaker Contact = Information:=20 Address =95 Phone Number =95 E-mail Address

   =95 Keywords (4-8=20 words)

   =95 ABSTRACT* The=20 presentation abstract should outline your presentation and what = attendees would=20 learn. Please    remember=20 that all the content must be strictly educational and marketing oriented = papers=20 will not be accepted. The presentation has to be oriented for: = Accounting,=20 Legal, IT Security, Risk Management, and Law Enforcement=20 professionals.

   =95 BIOGRAPHY*=20 The speakers biography should be 60 to 100 words in paragraph form. = These may=20 include present position, titles, areas of professional expertise, = experience,=20 research interests, major publications, degrees,=20 etc.

 

*=20 Abstract=20 and Biography information should not extend more than one page and will = be used=20 for our Show Guide and Website if = speaking.

 

Please=20 do not hesitate to include additional material regarding your = presentation(s)=20 for better evaluation.

 

The=20 total presentation length is 75 minutes: speech ~ 50-60min; = Q&A ~=20 15-20min.

 

SUBMISSION=20 DEADLINE:=20 July=20 20th, 2010.=20

 

Submissions=20 will be evaluated for originality, significance of the work, technical = content,=20 and interest to a wide audience. Speakers may also be grouped into = panels when=20 there are overlapping topics of interest.

 

Submissions=20 should be in Microsoft Word and sent to Natalia Manley=20 at nmanley@computerforensic= show.com.  Please note that due to the = expected=20 volume of submissions, Forensic Trade Shows, LLC will only contact = speakers who=20 are selected.

 

By=20 agreeing to speak, you grant one-time permission to Forensic Trade = Shows, LLC to=20 retain and publish a copy of your presentation. The copyright and all = other=20 rights to the presentation remain with the author(s). All rights to and = use of=20 The Computer Forensics Show name and logos are retained exclusively by = its=20 respective party.

 

A=20 copy of the presentation materials should be submitted to us no later = than=20 August=20 20th, 2010.=20 It should be sent in Microsoft PowerPoint (.ppt) format on the Computer=20 Forensics Show template that will be provided to you prior to the = conference. If=20 you use any animation or active content, please include that as well. = For=20 reliability and security purposes, all presentations will be preloaded = onto the=20 presentation computers at the conference.

 

Note:=20 Substitutions=20 for speakers are only allowed under emergency circumstances, and = tradeshow=20 management must be immediately notified of any changes.  All participants are selected = at the=20 discretion of show management.

 

Suggested=20 topics include

Accountant=20 Malpractice Claims

Anonymity=20 and Proxies

Authentication=20 and Access Control

Civil=20 Litigation

Class=20 Action Disputes

Computer=20 Crime and Information Warfare

Construction=20 Solutions

Corporate=20 Governance

Corporate=20 Information

Corporate=20 Risk and Security

Criminal=20 Fraud and Deception Cases

Cyberbullying

Cyber=20 Forensics

Damage=20 Assessment

Digital=20 Forensic Case Studies

Digital=20 Forensic Processes and Workflow Models =

Digital=20 Forensics and Internet

Digital=20 Law

 

Digital=20 Rights Management (DRM)

Digital=20 Signatures

E-Discovery=20

Employee=20 Internet Abuse

Employment=20 and Family Law Cases

Encryption=20 and Decryption

Environmental=20 Litigation

Financial=20 Investigations and Forensic Accounting =

Forensics=20 Accounting and the Internet

Fraud=20 Investigation

General=20 Commercial Disputes

Identity=20 Theft

Industrial=20 Espionage

Insurance=20 Claims and Digital Forensics

Integrity=20 of Archival Data

Intellectual=20 Property Claims

International=20 Risk and Investigations

Intrusion=20 Detection

IT=20 Security and Compliance

Legal,=20 Ethical and Policy Issues

Mobile=20 Forensics

More=20 General Criminal Cases

Network=20 Forensics

New=20 Firewall Technologies

Portable=20 Electronic Device Forensics

Post-Acquisition=20 Disputes

Privacy=20 and Data Mining

Privacy=20 issues in digital forensics

Privacy=20 Leakage Case Studies

Privacy=20 Policy Enforcement

Security=20 Education and Training

Smart=20 Card Applications

Stealth=20 Data

Steganography

Stylometrics=20 and Author Attribution

Terrorist=20 Use of the Internet

Unauthorized=20 Disclosure of Corporate Information

Additional=20 classes will also be available to attendees such as:=20

Computer=20 Forensics - CCFE Boot Camp - 5 Days

Advanced=20 Computer Forensics - 5 Days

Cell=20 Phone Forensics - 2 Days

Live=20 Memory Forensics - 2 Days

Linux=20 Forensics - 3 Days

Mac=20 Forensics - 3 Days

Reverse=20 Engineering Malware - CREA Boot Camp - 5 = Days

Ethical=20 Hacking - CPT/CEH Boot Camp - 5 Days

 

If=20 you have any questions about The Computer Forensics Conferences, please = send us=20 an e-mail to info@computerforensicshow.c= om.=20

 

#=20 # #

 

To=20 be removed from the mailing list please send us an e-mail to:=20 remove@computerforensicsh= ow.com.

------=_NextPart_000_018F_01CAFDBF.183E08E0--