From web-usrn@ISI.EDU Tue May 5 00:50:21 2009 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 F2B7B3A6CDA for ; Tue, 5 May 2009 00:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.218 X-Spam-Level: X-Spam-Status: No, score=-17.218 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] 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 vBIDMl2L+y3Y for ; Tue, 5 May 2009 00:50:19 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id C6E133A6CCB for ; Tue, 5 May 2009 00:50:19 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n457neqw000837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 May 2009 00:49:41 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n457nbfN000812; Tue, 5 May 2009 00:49:37 -0700 (PDT) Date: Tue, 5 May 2009 00:49:37 -0700 (PDT) Message-Id: <200905050749.n457nbfN000812@boreas.isi.edu> To: oki@ice.uec.ac.jp, takeda.tomonori@lab.ntt.co.jp, adrian@olddog.co.uk, rcallon@juniper.net, adrian.farrel@huawei.com, jpv@cisco.com, julien.meuric@orange-ftgroup.com From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu X-Mailman-Approved-At: Tue, 05 May 2009 04:31:10 -0700 Cc: ah@TR-Sys.de, pce@ietf.org, rfc-editor@rfc-editor.org Subject: [Pce] [Technical Errata Reported] RFC5521 (1775) 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, 05 May 2009 07:50:21 -0000 The following errata report has been submitted for RFC5521, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5521&eid=1775 -------------------------------------- Type: Technical Reported by: Alfred Hoenes Section: 2.1.1, pg. 6 Original Text ------------- Type The type of the subobject. The following subobject types are defined. Type Subobject -------------+------------------------------- 1 IPv4 prefix 2 IPv6 prefix 4 Unnumbered Interface ID 32 Autonomous system number 34 SRLG Length [...] Prefix Length [...] Attribute The Attribute field indicates how the exclusion subobject is to be interpreted. 0 Interface The subobject is to be interpreted as an interface or set of interfaces. All interfaces identified by the subobject are to be excluded from the computed path according to the setting of the | X-bit. This value is valid only for subobject types 1, 2, and 3. 1 Node The subobject is to be interpreted as a node or set of nodes. All nodes identified by the subobject are to be excluded from the computed path according to the setting of the X-bit. This value | is valid only for subobject types 1, 2, 3, and 4. 2 SRLG The subobject identifies an SRLG explicitly or indicates all of the SRLGs associated with the resource or resources identified by the subobject. Resources that share any SRLG with those identified are to be excluded from the computed path according to the setting of the X-bit. This value is valid for all subobjects. Corrected Text -------------- Attribute The Attribute field indicates how the exclusion subobject is to be interpreted. Type [...] Length [...] Prefix Length [...] Attribute The Attribute field indicates how the exclusion subobject is to be interpreted. 0 Interface The subobject is to be interpreted as an interface or set of interfaces. All interfaces identified by the subobject are to be excluded from the computed path according to the setting of the X-bit. This value is valid only for subobject types 1, 2, | and 4. ^ 1 Node The subobject is to be interpreted as a node or set of nodes. All nodes identified by the subobject are to be excluded from the computed path according to the setting of the X-bit. This | value is valid only for subobject types 1, 2, 4, and 32. ^ ^^ 2 SRLG The subobject identifies an SRLG explicitly or indicates all of the SRLGs associated with the resource or resources identified by the subobject. Resources that share any SRLG with those identified are to be excluded from the computed path according to the setting of the X-bit. This value is valid for all subobjects. Notes ----- Rationale: a) Technical: The enumeration of subobject types for Attribute '0 Interface' and '1 Node' is out of sync with the table at the top of the page and the IANA registry (cf. Section 4.1 of this RFC, on page 13). The Corrected Text proposed above is based on the assumption that the figures given originally refer to the position of the subobjects in the table, i.e. that the subobjects in the table once had been assigned sequential type numbers, 1 through 5; this change seems to be technically reasonable. b) Editorial: For clarity, the details for the Attribute field values should have been indented one more step, making them visually subordinate to 'Attribute' and not appearing like additional common fields. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5521 (draft-ietf-pce-pcep-xro-06) -------------------------------------- Title : Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions Publication Date : April 2009 Author(s) : E. Oki, T. Takeda, A. Farrel Category : PROPOSED STANDARD Source : Path Computation Element Area : Routing Stream : IETF Verifying Party : IESG From web-usrn@ISI.EDU Tue May 5 04:11:43 2009 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 378653A6DED for ; Tue, 5 May 2009 04:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.22 X-Spam-Level: X-Spam-Status: No, score=-17.22 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] 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-NjABAyC4t8 for ; Tue, 5 May 2009 04:11:42 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id EE1FC28C0E3 for ; Tue, 5 May 2009 04:11:39 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n45BCBHA001781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 May 2009 04:12:11 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n45BC92p001777; Tue, 5 May 2009 04:12:10 -0700 (PDT) Date: Tue, 5 May 2009 04:12:10 -0700 (PDT) Message-Id: <200905051112.n45BC92p001777@boreas.isi.edu> To: rbradfor@cisco.com, jpv@cisco.com, adrian@olddog.co.uk, rcallon@juniper.net, adrian.farrel@huawei.com, jpv@cisco.com, julien.meuric@orange-ftgroup.com From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu X-Mailman-Approved-At: Tue, 05 May 2009 04:31:10 -0700 Cc: ah@TR-Sys.de, pce@ietf.org, rfc-editor@rfc-editor.org Subject: [Pce] [Editorial Errata Reported] RFC5520 (1776) 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, 05 May 2009 11:11:43 -0000 The following errata report has been submitted for RFC5520, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5520&eid=1776 -------------------------------------- Type: Editorial Reported by: Alfred Hoenes Section: 8.2, pg. 18 Original Text ------------- | [RBNF] Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used | in Various Protocol Specifications", Work in Progress, | November 2008. Corrected Text -------------- | [RBNF] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used | in Various Protocol Specifications", RFC 5511, April 2009. Notes ----- Rationale: [[ may be deleted on approval of this erratum ]] a) The referenced document has been published as RFC 5511 shortly *before* this RFC. b) The expansion of "RBNF" in general, and in particular the title of that document, have been changed before IESG approval, with the -09 draft version submitted to the RFC Editor. "RBNF" officially stands for "Routing BNF". Also, the clarifying colon is missing in the citation. It could have been expected that the RFC Editor better coordinate between the documents in his Queue. Hint: b) also affects other RFCs published since the draft of RFC 5511 has entered the RFC Editor Queue, e.g. RFC 5440 ff. and RFC 5455. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5520 (draft-ietf-pce-path-key-05) -------------------------------------- Title : Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism Publication Date : April 2009 Author(s) : R. Bradford, Ed., JP. Vasseur, A. Farrel Category : PROPOSED STANDARD Source : Path Computation Element Area : Routing Stream : IETF Verifying Party : IESG From web-usrn@ISI.EDU Tue May 5 05:11:28 2009 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 943733A6C65 for ; Tue, 5 May 2009 05:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.221 X-Spam-Level: X-Spam-Status: No, score=-17.221 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] 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 fBYuJtXHUrsF for ; Tue, 5 May 2009 05:11:27 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id D0B2B3A6A4A for ; Tue, 5 May 2009 05:10:55 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n45CBkaf028782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 May 2009 05:11:46 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n45CBkSl028781; Tue, 5 May 2009 05:11:46 -0700 (PDT) Date: Tue, 5 May 2009 05:11:46 -0700 (PDT) Message-Id: <200905051211.n45CBkSl028781@boreas.isi.edu> To: rbradfor@cisco.com, jpv@cisco.com, adrian@olddog.co.uk, rcallon@juniper.net, adrian.farrel@huawei.com, jpv@cisco.com, julien.meuric@orange-ftgroup.com From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu X-Mailman-Approved-At: Tue, 05 May 2009 08:33:17 -0700 Cc: ah@TR-Sys.de, pce@ietf.org, rfc-editor@rfc-editor.org Subject: [Pce] [Technical Errata Reported] RFC5520 (1777) 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, 05 May 2009 12:11:28 -0000 The following errata report has been submitted for RFC5520, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5520&eid=1777 -------------------------------------- Type: Technical Reported by: Alfred Hoenes Section: 7.3, pg. 17 Original Text ------------- IANA maintains a registry of bit flags carried in the PCEP RP object as defined in [RFC5440]. IANA assigned a new bit flag as follows: | Bit Number Hex Name Reference | 23 0x000017 Path-Key (P-bit) [RFC5520] Corrected Text -------------- IANA maintains a registry of bit flags carried in the PCEP RP object as defined in [RFC5440]. IANA assigned a new bit flag as follows: | Bit Number Name Reference | 23 Path-Key (P-bit) [RFC5520] Notes ----- Rationale: 'translating' the decimal bit number into a 6-digit (!) hexadecimal value does not add specific insight and might even be considered confusing; at most a hexadecimal bit mask might have some additional value -- but it should be specified as an /8/-digit mask in this case (the RP Flags field is 32 bits wide). Because the definition of the addressed sub-registry (Section 9.6 of RFC 5440) did not specify a 'Hex' item and the IANA Registry consequentially does not contain such column, the 'Hex' column should have been dropped from Section 7.3 of RFC 5520 as well. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5520 (draft-ietf-pce-path-key-05) -------------------------------------- Title : Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism Publication Date : April 2009 Author(s) : R. Bradford, Ed., JP. Vasseur, A. Farrel Category : PROPOSED STANDARD Source : Path Computation Element Area : Routing Stream : IETF Verifying Party : IESG From ylee@huawei.com Tue May 5 14:47:53 2009 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 57F713A6E1D for ; Tue, 5 May 2009 14:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, 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 1LTDSn-68LUf for ; Tue, 5 May 2009 14:47:47 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 1ADD03A6E5E for ; Tue, 5 May 2009 14:47:41 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJ600M6PXXU1F@usaga02-in.huawei.com> for pce@ietf.org; Tue, 05 May 2009 14:49:07 -0700 (PDT) Received: from L73682 ([10.124.12.80]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJ600IGOXXUMG@usaga02-in.huawei.com> for pce@ietf.org; Tue, 05 May 2009 14:49:06 -0700 (PDT) Date: Tue, 05 May 2009 16:49:06 -0500 From: Young Lee To: pce@ietf.org Message-id: <004f01c9cdcb$5035ad40$500c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_BVUtnax79wHUx9Y55cor9g)" Thread-index: AcnNy0/1V1U7RYD3QSi9pSf2VIP2HA== Subject: [Pce] PCE TED alternatives 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, 05 May 2009 21:47:53 -0000 This is a multi-part message in MIME format. --Boundary_(ID_BVUtnax79wHUx9Y55cor9g) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Pcers, The revision of the PCE TED alternatives (draft-lee-pce-ted-alternatives-02.txt) is now available: http://www.ietf.org/internet-drafts/draft-lee-pce-ted-alternatives-02.txt Please note the following changes made in the revision based on inputs from many folks. * Global change: IGP -> IGP-TE (per Igor) * Section 1.1 We corrected a statement as follows (per Igor): In OSPF the information directly related to IP connectivity (and hence the control communications plane for all three technologies) and non-IP advertisements are kept in the link state database (LSDB), while information related to traffic engineering used by MPLS and GMPLS is kept in a (conceptually) separate TED which can be considered a subset of the LSDB. * Section 2 (per Igor) We have added a few new paragraphs that discuss cooperation between IGP-TE and an alternative method and some advantages/disadvantages of both models. * Section 2.1 (Per Fabien) Architecture Option 3 has changed to: "Nodes send local information to at least one PCE" from "Nodes send local information to one PCE." This is to avoid a single point of failure. Section 2.1.3 below elaborates two possible ways to implement this option. * Section 2.1.1 (per Fabien) We added a comment on scaling issue to clarify that scaling issue associated with option 1 may be of a real concern if there are only a few PCEs (e.g., two to three PCEs) in the networks. * Section 2.1.3 (per Fabien) We have added a new paragraph: "A number of approaches can be used to ensure control plane resilience in this architecture. (1) Each node can be configured with a primary and a secondary PCE to send its information to; In case of failure of communications with the primary PCE the node would send its information to a secondary PCE (warm standby). (2) Each node could be configured to send its information to two different PCEs (hot standby)." * Section 2.4 (Per Peng He) We elaborated PCE TED maintenance procedure: The PCE is responsible for creating and maintaining the TED that it will use. Key functions include: 1. Establishing and authenticating communications between the PCE and sources of TED information. 2. Timely updates of the TED with information received from nodes, peers or other entities. 3. Verifying the validity of information in the TED,i.e., ensure that the network information obtained from nodes or elsewhere is relatively timely, or not stale. By analogy with similar functionality provided by IGPs this can be done via a process where discrete "chunks" of TED information are "aged" and discard when expired. This combined with nodes periodically resending their local TE information leads to a timely TED. * Section 3.2 and Appendix We deleted Section 3.2 and the appendix that discuss the protocol and implementation details. Thus this draft stays as the framework/requirement draft. We will address protocol enhancements as separate drafts once this work is accepted as the WG draft. (Per Dan King) * We have added a few contributors. We'd appreciate your comments and further discussion on this draft. Best Regards, Young & Greg --Boundary_(ID_BVUtnax79wHUx9Y55cor9g) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Pcers,

 

The revision of the PCE TED alternatives (draft-lee-pce-ted-alternatives-02.txt) is now available:

 

http://www.ietf.org/internet-drafts/draft-lee-pce-ted-alternatives-02.txt

 

Please note the following changes made in the revision based on inputs from many folks.

·         Global change: IGP -> IGP-TE (per Igor)

 

·         Section 1.1

 

We corrected a statement as follows (per Igor):

 

In OSPF the information directly related to IP connectivity (and hence the control communications plane for all three technologies) and non-IP advertisements are kept in the link state database (LSDB), while information related to traffic engineering used by MPLS and GMPLS is kept in a (conceptually) separate TED which can be considered a subset of the LSDB.

 

·         Section 2 (per Igor)

 

We have added a few new paragraphs that discuss cooperation between IGP-TE and an alternative method and some advantages/disadvantages of both models.

 

·         Section 2.1 (Per Fabien)

 

Architecture Option 3 has changed to: “Nodes send local information to at least one PCE” from “Nodes send local information to one PCE.” This is to avoid a single point of failure. Section 2.1.3 below elaborates two possible ways to implement this option.

 

·         Section 2.1.1 (per Fabien)

 

We added a comment on scaling issue to clarify that scaling issue associated with option 1 may be of a real concern if there are only a few PCEs (e.g., two to three PCEs) in the networks.

 

·         Section 2.1.3 (per Fabien)

 

We have added a new paragraph: “A number of approaches can be used to ensure control plane resilience in this architecture. (1) Each node can be configured with a primary and a secondary PCE to send its information to; In case of failure of communications with the primary PCE the node would send its information to a secondary PCE (warm standby). (2) Each node could be configured to send its information to two different PCEs (hot standby).”

 

·         Section 2.4 (Per Peng He)

 

We elaborated PCE TED maintenance procedure:

 

The PCE is responsible for creating and maintaining the TED that it will use. Key functions include:

 

1.         Establishing and authenticating communications between the PCE and sources of TED information.

2.         Timely updates of the TED with information received from nodes, peers or other entities.

3.         Verifying the validity of information in the TED,i.e., ensure that the network information obtained from nodes or elsewhere is relatively timely, or not stale. By analogy with similar functionality provided by IGPs this can be done via a process where discrete "chunks" of TED information are "aged" and discard when expired. This combined with nodes periodically resending their local TE information leads to a timely TED.

·         Section 3.2 and Appendix

 

We deleted Section 3.2 and the appendix that discuss the protocol and implementation details. Thus this draft stays as the framework/requirement draft. We will address protocol enhancements as separate drafts once this work is accepted as the WG draft. (Per Dan King)

 

·         We have added a few contributors.

 

We’d appreciate your comments and further discussion on this draft.

 

Best Regards,

Young & Greg

 

--Boundary_(ID_BVUtnax79wHUx9Y55cor9g)-- From i_bryskin@yahoo.com Wed May 6 06:56:15 2009 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 0146F3A6F01 for ; Wed, 6 May 2009 06:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=0.658, BAYES_00=-2.599, 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 vB7acqmLhOwm for ; Wed, 6 May 2009 06:56:07 -0700 (PDT) Received: from web36807.mail.mud.yahoo.com (web36807.mail.mud.yahoo.com [209.191.85.58]) by core3.amsl.com (Postfix) with SMTP id 835CE3A6A0C for ; Wed, 6 May 2009 06:55:37 -0700 (PDT) Received: (qmail 70847 invoked by uid 60001); 6 May 2009 13:57:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1241618222; bh=IHB88cJTZAaBFLItGTnVQBMa83XGIAKv9KTDUTtWtRw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ZgjCC8vD9yN7Jepg9e3vCExutDmxj9R9elaIwZzeBuywpFhgZCZkIn3X8a8af6hPJdLCKZ2w2i65cy/5gxsvKjsjbqHqevFCSTUW/AZ3vLfOKwW4uMSavl0gkWdQVX3cuHwtAhWmeNN7Qw3csg0yaICHUlKEOjcVvH6PzECCg1k= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ZkNWSVfTs8wVIC4bsNzKydy/VJozt/yzMJFYSluoB+P3fmxeGDuIVq3TuV+JumSSv1UuC5jEzMmcXRy2i1tFef7y94+PZJSNUE6a9FcklLonQCNfZeXy9dDxbQIjQG4nNfkeWzhlANrw6xyR8wJ9h7J+W838uX9qEuy48L5g4AU=; Message-ID: <714490.69262.qm@web36807.mail.mud.yahoo.com> X-YMail-OSG: J6JOCP8VM1mWVtgbckn1rbHmC1bhPEST1Ff2buWaWFygI83k1IK6.OWnJyJ53ZaU87PZS5I7L5F_bINYTYte.tk1_0BLPP.nsNUx4bgZhIC5H.ceWcKgFJTe16VRJi66otRY6CcGM.Z3Ux0vTAdKiYnBdA05uwyWWtYGlnYInmgbVyGO3c8k7oj.RJCR2Lk9iM8ZCQXtJtJXXcPJem1JHbvVsM8zeeTy8Nk2H5HIm4n9nyFB6K_NMCkBc7QpKRnr8PgUC13u0gEQjFH4Tu7rHXRI31AKgK6c0FJqAd22NYZdT99X_9hFdkkv2XBmsjcuq0KFcZawJOC9FZI_DSCNcdq2 Received: from [67.102.145.11] by web36807.mail.mud.yahoo.com via HTTP; Wed, 06 May 2009 06:57:02 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <004f01c9cdcb$5035ad40$500c7c0a@china.huawei.com> Date: Wed, 6 May 2009 06:57:02 -0700 (PDT) From: Igor Bryskin To: Young Lee , pce@ietf.org In-Reply-To: <004f01c9cdcb$5035ad40$500c7c0a@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1452453129-1241618222=:69262" Subject: Re: [Pce] PCE TED alternatives 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, 06 May 2009 13:56:15 -0000 --0-1452453129-1241618222=:69262 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Young,=0A=0AI am afraid you misunderstood one of my comments. Please, see i= n line.=0A=0ACheers,=0AIgor=0A=0A=0A=0A=0A________________________________= =0AFrom: Young Lee =0ATo: pce@ietf.org=0ASent: Tuesday, Ma= y 5, 2009 5:49:06 PM=0ASubject: [Pce] PCE TED alternatives=0A=0A =0AHi Pcer= s, =0A =0AThe revision of the PCE TED alternatives=0A(draft-lee-pce-ted-alt= ernatives-02.txt) is now available: =0A =0Ahttp://www.ietf.org/internet-dra= fts/draft-lee-pce-ted-alternatives-02.txt=0A =0APlease note=0Athe following= changes made in the revision based on inputs from many folks. =0A=C2=B7 = Global change: IGP -> IGP-TE (per=0AIgor) =0A =0A=C2=B7 Secti= on 1.1 =0A =0AWe corrected a statement as follows (per Igor): =0A =0AIn OSP= F the information directly related to IP connectivity=0A(and hence the cont= rol communications plane for all three technologies) and=0Anon-IP advertise= ments are kept in the link state database (LSDB), while=0Ainformation relat= ed to traffic engineering used by MPLS and GMPLS is kept in a=0A(conceptual= ly) separate TED which can be considered a subset of the LSDB.=0A=0AIB>> LS= DB contains *all* LSAs (that is, including TE LSAs) exactly the way they we= re originated or received from the network, This is required by the OSPF fl= ooding/data base synchronization process. However, it is extreamely awkward= to use "raw" TE LSAs for the path computation. Indeed, it would be very na= ive to browse entire TE Link LSA for every link attribute (such as link swi= tching capability) because the corresponding sub-TLV could be placed anywhe= re in the LSA. Therefore, TE application implementations (at least, I am aw= are of) normaly keep the TE link and node attributes in a separate structur= e in a path computation friendly form, which means that TE information is s= tored twice - raw form within LSDB and "pre-cooked" form in TED. My point i= s that if one uses a PCE-TED alternative (e.g. extended PCEP), it would be = possible to store the TE updates only in the latter (path computation frie= ndly) form. Which means that not only it will be not necessary to keep TED on the nodes where it is not used, but even where it= is used (PCEs), it will take half as much of the memory space compared to= the OSPF-TE method.=0A=0ACheers,=0AIgor=0A=0A =0A=C2=B7 Section 2 = (per Igor) =0A =0AWe have added a few new paragraphs that discuss cooperati= on=0Abetween IGP-TE and an alternative method and some advantages/disadvant= ages of=0Aboth models.=0A =0A=C2=B7 Section 2.1 (Per Fabien)=0A =0A= Architecture Option 3 has changed to: =E2=80=9CNodes send=0Alocal informati= on to at least one PCE=E2=80=9D from =E2=80=9CNodes send local=0Ainformatio= n to one PCE.=E2=80=9D This is to avoid a single point of failure.=0ASectio= n 2.1.3 below elaborates two possible ways to implement this option. =0A = =0A=C2=B7 Section 2.1.1 (per Fabien)=0A =0AWe added a comment on sc= aling issue to clarify that scaling=0Aissue associated with option 1 may be= of a real concern if there are only a few=0APCEs (e.g., two to three PCEs)= in the networks. =0A =0A=C2=B7 Section 2.1.3 (per Fabien) =0A =0AW= e have added a new paragraph: =E2=80=9CA number of approaches=0Acan be used= to ensure control plane resilience in this architecture. (1) Each=0Anode c= an be configured with a primary and a secondary PCE to send its=0Ainformati= on to; In case of failure of communications with the primary PCE the=0Anode= would send its information to a secondary PCE (warm standby). (2) Each=0An= ode could be configured to send its information to two different PCEs (hot= =0Astandby).=E2=80=9D =0A =0A=C2=B7 Section 2.4 (Per Peng He)=0A = =0AWe elaborated PCE TED maintenance procedure: =0A =0AThe PCE is responsib= le for creating and maintaining the TED=0Athat it will use. Key functions i= nclude: =0A =0A1. Establishing and authenticating=0Acommunications = between the PCE and sources of TED information. =0A2. Timely update= s of the TED with=0Ainformation received from nodes, peers or other entitie= s. =0A3. Verifying the validity of=0Ainformation in the TED,i.e., e= nsure that the network information obtained from=0Anodes or elsewhere is re= latively timely, or not stale. By analogy with similar=0Afunctionality prov= ided by IGPs this can be done via a process where discrete=0A"chunks" of TE= D information are "aged" and discard when=0Aexpired. This combined with nod= es periodically resending their local TE=0Ainformation leads to a timely TE= D. =0A=C2=B7 Section 3.2 and Appendix=0A =0AWe deleted Section 3.2 = and the appendix that discuss the=0Aprotocol and implementation details. Th= us this draft stays as the=0Aframework/requirement draft. We will address p= rotocol enhancements as separate=0Adrafts once this work is accepted as the= WG draft. (Per Dan King)=0A =0A=C2=B7 We have added a few contribu= tors. =0A =0AWe=E2=80=99d appreciate your comments and further discussion= =0Aon this draft. =0A =0ABest Regards,=0AYoung & Greg=0A=0A=0A --0-1452453129-1241618222=:69262 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Young,

I am afraid you misunderstood one of my com= ments. Please, see in line.

Cheers,
Igor

From: Young Lee <ylee@huawei.com>
To: pce@ietf.org
Sent: Tuesday, May 5, 2009 5:49:06 PM=
Subject: [Pce] PCE TED= alternatives

=0A=0A=0A=0A =0A =0A=0A=0A=0A=0A
=0A=0AHi Pcers,

=0A=0A

 

=0A=0A

The revision of the PCE TED alternatives=0A(draft-lee-pce-te= d-alternatives-02.txt) is now available:

=0A=0A

 

=0A=0A

h= ttp://www.ietf.org/internet-drafts/draft-lee-pce-ted-alternatives-02.txt

=0A=0A

 

=0A=0A

Please note=0Athe fol= lowing changes made in the revision based on inputs from many folks.

=0A=0A

=C2=B7=         =0AGlobal change: IGP -> IGP-TE (per=0AIgor) <= /font>

=0A=0A

 

= =0A=0A

=C2=B7 &nbs= p;      =0ASection 1.1

=0A=0A

 

=0A=0A

We c= orrected a statement as follows (per Igor):

=0A=0A

 

=0A=0A

In OSPF the information directly related to IP connectivit= y=0A(and hence the control communications plane for all three technologies)= and=0Anon-IP advertisements are kept in the link state database (LSDB), wh= ile=0Ainformation related to traffic engineering used by MPLS and GMPLS is = kept in a=0A(conceptually) separate TED which can be considered a subset of= the LSDB.


IB>> LSDB contains *all* LS= As (that is, including TE LSAs) exactly the way they were originated or rec= eived from the network, This is required by the OSPF flooding/data base syn= chronization process. However, it is extreamely awkward to use "raw" TE LSA= s for the path computation. Indeed, it would be very naive to browse entire= TE Link LSA for every link attribute (such as link switching capability) b= ecause the corresponding sub-TLV could be placed anywhere in the LSA. There= fore, TE application implementations (at least, I am aware of) normaly keep= the TE link and node attributes in a separate structure in a path computat= ion friendly form, which means that TE information is stored twice - raw form within LSDB and= "pre-cooked" form in TED. My point is that if one uses a PCE-TED alternati= ve (e.g. extended PCEP), it would be possible to store the TE updates = only in the latter (path computation friendly) form. Which means that not = only it will be not necessary to keep TED on the nodes where it is not used= , but even where it is used (PCEs), it will take half as  much of the = memory space compared to the OSPF-TE method.


= Cheers,

Igor

=0A=0A

 

= =0A=0A

=C2=B7 &nbs= p;      =0ASection 2 (per Igor)

=0A=0A

 

=0A=0A

We have added a few new paragraphs that discuss cooperation=0Abetween = IGP-TE and an alternative method and some advantages/disadvantages of=0Abot= h models.

=0A=0A

 <= /span>

=0A=0A

=C2=B7        =0ASection 2.1 (Per Fabien)

=0A= =0A

 

=0A=0A

Architecture Option 3 has changed to: =E2=80=9CNo= des send=0Alocal information to at least one PCE=E2=80=9D from =E2=80=9CNod= es send local=0Ainformation to one PCE.=E2=80=9D This is to avoid a single = point of failure.=0ASection 2.1.3 below elaborates two possible ways to imp= lement this option.

=0A=0A

 

=0A=0A

=C2=B7        =0A= Section 2.1.1 (per Fabien)

=0A=0A

 

= =0A=0A

We added a comment on scaling issue = to clarify that scaling=0Aissue associated with option 1 may be of a real c= oncern if there are only a few=0APCEs (e.g., two to three PCEs) in the netw= orks.

=0A=0A

 

=0A=0A

= =C2=B7        =0A= Section 2.1.3 (per Fabien)

=0A= =0A

 

=0A=0A

We have added a new paragraph: =E2=80=9CA number = of approaches=0Acan be used to ensure control plane resilience in this arch= itecture. (1) Each=0Anode can be configured with a primary and a secondary = PCE to send its=0Ainformation to; In case of failure of communications with= the primary PCE the=0Anode would send its information to a secondary PCE (= warm standby). (2) Each=0Anode could be configured to send its information = to two different PCEs (hot=0Astandby).=E2=80=9D

=0A=0A  

=0A=0A

= =C2= =B7     = ;   =0ASection = 2.4 (Per Peng He)

=0A=0A

=  

=0A=0A

We elabora= ted PCE TED maintenance procedure:

=0A=0A

 

=0A=0A

The PCE is responsible for creating and maintaining the TED=0Athat = it will use. Key functions include:

=0A=0A

 

=0A=0A

1.Establishing and authenticating=0Acommunications bet= ween the PCE and sources of TED information.

=0A=0A

2.        =0ATimely updates of the TED with= =0Ainformation received from nodes, peers or other entities. =

=0A=0A

 

=0A=0A

We= =E2=80=99d appreciate your comments and further discussion=0Aon this draft.=

=0A=0A

 

=0A=0A

Best Regards,

=0A=0A

Young & Greg=

=0A=0A

 

=0A= =0A

3.      &n= bsp; =0AVerifying the val= idity of=0Ainformation in the TED,i.e., ensure that the network information= obtained from=0Anodes or elsewhere is relatively timely, or not stale. By = analogy with similar=0Afunctionality provided by IGPs this can be done via = a process where discrete=0A"chunks" of TED information are "aged" and disca= rd when=0Aexpired. This combined with nodes periodically resending their lo= cal TE=0Ainformation leads to a timely TED.

=0A=0A

=C2=B7    = ;    =0A= Section 3.2 and Appendix

=0A=0A

 

=0A=0A

We = deleted Section 3.2 and the appendix that discuss the=0Aprotocol and implem= entation details. Thus this draft stays as the=0Aframework/requirement draf= t. We will address protocol enhancements as separate=0Adrafts once this wor= k is accepted as the WG draft. (Per Dan King)

=0A=0A

 

=0A=0A

=C2=B7<= font size=3D"1" face=3D"Times New Roman">     &nb= sp;  =0AWe have add= ed a few contributors.

=0A=0A
=0A=0A

=0A=0A --0-1452453129-1241618222=:69262-- From zhang.fei3@zte.com.cn Thu May 7 01:02:44 2009 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 1D7D728C2AA for ; Thu, 7 May 2009 01:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.485 X-Spam-Level: X-Spam-Status: No, score=-99.485 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, 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 8gJdtHzxoPq8 for ; Thu, 7 May 2009 01:02:43 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 8F94528C2A6 for ; Thu, 7 May 2009 01:02:41 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111641441414862; Thu, 7 May 2009 15:52:16 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.100] with StormMail ESMTP id 30761.1441414862; Thu, 7 May 2009 15:43:22 +0800 (CST) Received: from notes_svr7_1.zte.com.cn ([10.30.1.248]) by mse1.zte.com.cn with ESMTP id n477e6GL068299 for ; Thu, 7 May 2009 15:46:02 +0800 (CST) (envelope-from zhang.fei3@zte.com.cn) To: pce@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: zhang.fei3@zte.com.cn Date: Thu, 7 May 2009 15:35:37 +0800 X-MIMETrack: Serialize by Router on notes_svr7_1/zte_ltd(Release 6.5.5|November 30, 2005) at 2009-05-07 15:45:51, Serialize complete at 2009-05-07 15:45:51 Content-Type: multipart/alternative; boundary="=_alternative 0029B85A482575AF_=" X-MAIL: mse1.zte.com.cn n477e6GL068299 Subject: [Pce] some question about domain sequence in PCE-based architecture 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, 07 May 2009 08:02:59 -0000 This is a multipart message in MIME format. --=_alternative 0029B85A482575AF_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgUGNlcqOsDQoNCkl0IGlzIG5lY2Vzc2FyeSB0byBrbm93IHRoZSBzZXF1ZW5jZSBvZiBkb21h aW5zIHdoZW4gQlJQQyAoUkZDNTQ0MSkgaXMgDQp1c2VkIHRvIGNvbXB1dGUgdGhlIFRFLUxTUCBh Y3Jvc3MgbXVsdGktZG9tYWlucywgYW5kIHRoZSBzYW1lIHF1ZXN0aW9uIA0KZXhpc3RzIGluIHBh dGgta2V5IHNjaGVtZSAoUkZDNTUwKS4gDQoNCkFzIHdlIGtub3csIHRoZXJlIGFyZSBkaWZmZXJl bnQgd2F5cyB0byBzb2x2ZSB0aGlzIHByb2JsZW0uIFRoZSBmaXJzdCBvbmUgDQppcyBhZG1pbmlz dHJhdGl2ZWx5IHByZWRldGVybWluZWQsIGFuZCB0aGlzIG1ldGhvZCBzZWVtcyB0b28gaW5lZmZp Y2llbnQgDQp0byBmaW5kIHRoZSBvcHRpbWFsIGVuZC10by1lbmQgVEUtTFNQcyBvbmNlIHRoZXJl IGFyZSBhIGxvdCBvZiBkb21haW5zLiANClRoZSBzZWNvbmQgb25lLCB1dGlsaXplIHRoZSBCR1Ag cm91dGluZyB0YWJsZXMgdG8gZmluZCB0aGUgc2VxdWVuY2UgaWYgUENFIA0KZnVuY3Rpb24gaXMg aW5zZXJ0ZWQgaW4gQVNCUjsgYnV0IHdoYXQgaWYgdGhlIGVxdWlwbWVudHMgZG8gbm90IGtub3cg d2hhdA0Koa9zIEJHUCBpbiBvcHRpY2FsIGRvbWFpbnM/IFRoZSB0aGlyZCBzb2x1dGlvbiwgdGhh bmtzIHRvIEZhcnJlbKGvcyB3b3JrLCANCmlzIHRoZSBjb25jZXB0IG9mIGEgaGllcmFyY2hpY2Fs IFBDRSBhcmNoaXRlY3R1cmUgdG8gY29vcmRpbmF0ZSBQQ0VzIGluIA0KcGVlciBkb21haW5zIHRv IGRlcml2ZSBhbiBvcHRpbWFsIGVuZC10by1lbmQgcGF0aCwgd2hpY2ggZml0cyB3ZWxsIHdpdGgg DQp0aGUgQVNPTiByb3V0aW5nIGFyY2hpdGVjdHVyZS4NCg0KSG93IGFib3V0IGEgdW5pZm9ybSBz b2x1dGlvbiBhcHBsaWNhYmxlIHRvIGJvdGggdGhlIGRhdGEgYW5kIG9wdGljYWwgDQplbnZpcm9u bWVudD8gSXMgaXQgd2VsbCB0byBhZGQgYSBzaW1wbGlmaWVkIHVwZGF0ZSBtZXNzYWdlIGluIFBD RVA/IFRoZSANCnVwZGF0ZSBvYmplY3QgYm9keSBjb25zaXN0cyBvZiByb3V0aW5nIHByZWZpeC9k b21haW4gbnVtYmVyL1BDRSBhZGRyZXNzLCANCmp1c3QgYXMgZmVsbG93LiBFdmVyeSBQQ0UgdGhh dCBoYXMgdGhlIGFiaWxpdHkgdG8gY29tcHV0ZSB0aGUgVEUtTFNQIA0KdG93YXJkcyBuZWlnaGJv ciBkb21haW4gYW5ub3VuY2VzIHRoZSB1cGRhdGUgbWVzc2FnZSB0byBlYWNoIG90aGVyLCB0aGVu IA0KaXQgc3RvcmVzIG9uZSBvciBtb3JlIFBDRSBzZXF1ZW5jZXMgYWNjb3JkaW5nIHRvIGRvbWFp biBhY2NvdW50cy4gVGhlIFBDRSANCmxvb2t1cHMgdGhlIGVuZC1wb2ludCBvYmplY3QgaWYgYSBw YXRoIGNvbXB1dGluZyByZXF1ZXN0IGNvbWVzLCBhbmQgZmluZCANCnRoZSBQQ0Ugc2VxdWVuY2Vz KG9uZSBvciBtb3JlKSByZXNwb25zaWJsZSBmb3IgdGhpcyBURS1MU1AgY29tcHV0aW5nLiANCg0K SXQgaXMgZWFzeSB0byBnZXQgdGhlIFBDRSBzZXF1ZW5jZXMgdW5kZXIgdGhlIGhlbHAgb2YgdGhp cyBtZXRob2QsIGFuZCANCmV2ZW4gaWYgdGhlcmUgYXJlIHNldmVyYWwgaHVuZHJlZHMgb2YgZG9t YWlucywgaXQgd2lsbCBjb252ZXJnZSBxdWlja2x5IA0KYWxzby4gDQoNCldoYXQgYXJlIHlvdXIg b3BpbmlvbnM/IElzIGl0IHN1aXRhYmxlIHRvIHB1dCBmb3J3YXJkIHRoaXMgcHJvcG9zYWwgaW4g UENFIA0KZ3JvdXA/IEFueSBjb21tZW50cz8NCiANCiAgICAgICAgICBCZXN0IHJlZ2FyZHMgDQoN CiAgICAgICAgICAgICAgICAgRmVpIFpoYW5nDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2Vj dXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBz b2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNv bW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBv YmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlz Y2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlz IGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFs IGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50 aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3Nh Z2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUg aW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3Igdmly dXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 0029B85A482575AF_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+SGkgUGNlcjwvZm9udD48 Zm9udCBzaXplPTI+o6w8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+SXQgaXMgbmVjZXNzYXJ5IHRvIGtub3cgdGhlIHNlcXVlbmNlDQpvZiBkb21h aW5zIHdoZW4gQlJQQyAoUkZDNTQ0MSkgaXMgdXNlZCB0byBjb21wdXRlIHRoZSBURS1MU1AgYWNy b3NzIG11bHRpLWRvbWFpbnMsDQphbmQgdGhlIHNhbWUgcXVlc3Rpb24gZXhpc3RzIGluIHBhdGgt a2V5IHNjaGVtZSAoUkZDNTUwKS4gPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPkFzIHdlIGtub3csIHRoZXJlIGFyZSBkaWZmZXJlbnQNCndheXMg dG8gc29sdmUgdGhpcyBwcm9ibGVtLiBUaGUgZmlyc3Qgb25lIGlzIGFkbWluaXN0cmF0aXZlbHkg cHJlZGV0ZXJtaW5lZCwNCmFuZCB0aGlzIG1ldGhvZCBzZWVtcyB0b28gaW5lZmZpY2llbnQgdG8g ZmluZCB0aGUgb3B0aW1hbCBlbmQtdG8tZW5kIFRFLUxTUHMNCm9uY2UgdGhlcmUgYXJlIGEgbG90 IG9mIGRvbWFpbnMuIFRoZSBzZWNvbmQgb25lLCB1dGlsaXplIHRoZSBCR1Agcm91dGluZw0KdGFi bGVzIHRvIGZpbmQgdGhlIHNlcXVlbmNlIGlmIFBDRSBmdW5jdGlvbiBpcyBpbnNlcnRlZCBpbiBB U0JSOyBidXQgd2hhdA0KaWYgdGhlIGVxdWlwbWVudHMgZG8gbm90IGtub3cgd2hhdKGvcyBCR1Ag aW4gb3B0aWNhbCBkb21haW5zPyBUaGUgdGhpcmQNCnNvbHV0aW9uLCB0aGFua3MgdG8gRmFycmVs oa9zIHdvcmssIGlzIHRoZSBjb25jZXB0IG9mIGEgaGllcmFyY2hpY2FsIFBDRQ0KYXJjaGl0ZWN0 dXJlIHRvIGNvb3JkaW5hdGUgUENFcyBpbiBwZWVyIGRvbWFpbnMgdG8gZGVyaXZlIGFuIG9wdGlt YWwgZW5kLXRvLWVuZA0KcGF0aCwgd2hpY2ggZml0cyB3ZWxsIHdpdGggdGhlIEFTT04gcm91dGlu ZyBhcmNoaXRlY3R1cmUuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPkhvdyBhYm91dCBhIHVuaWZvcm0gc29sdXRpb24gYXBwbGljYWJsZQ0KdG8g Ym90aCB0aGUgZGF0YSBhbmQgb3B0aWNhbCBlbnZpcm9ubWVudD8gSXMgaXQgd2VsbCB0byBhZGQg YSBzaW1wbGlmaWVkDQp1cGRhdGUgbWVzc2FnZSBpbiBQQ0VQPyBUaGUgdXBkYXRlIG9iamVjdCBi b2R5IGNvbnNpc3RzIG9mIHJvdXRpbmcgcHJlZml4L2RvbWFpbg0KbnVtYmVyL1BDRSBhZGRyZXNz LCBqdXN0IGFzIGZlbGxvdy4gRXZlcnkgUENFIHRoYXQgaGFzIHRoZSBhYmlsaXR5IHRvIGNvbXB1 dGUNCnRoZSBURS1MU1AgdG93YXJkcyBuZWlnaGJvciBkb21haW4gYW5ub3VuY2VzIHRoZSB1cGRh dGUgbWVzc2FnZSB0byBlYWNoDQpvdGhlciwgdGhlbiBpdCBzdG9yZXMgb25lIG9yIG1vcmUgUENF IHNlcXVlbmNlcyBhY2NvcmRpbmcgdG8gZG9tYWluIGFjY291bnRzLg0KVGhlIFBDRSBsb29rdXBz IHRoZSBlbmQtcG9pbnQgb2JqZWN0IGlmIGEgcGF0aCBjb21wdXRpbmcgcmVxdWVzdCBjb21lcywN CmFuZCBmaW5kIHRoZSBQQ0Ugc2VxdWVuY2VzKG9uZSBvciBtb3JlKSByZXNwb25zaWJsZSBmb3Ig dGhpcyBURS1MU1AgY29tcHV0aW5nLg0KJm5ic3A7PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkl0IGlzIGVhc3kgdG8gZ2V0IHRoZSBQQ0Ugc2Vx dWVuY2VzDQp1bmRlciB0aGUgaGVscCBvZiB0aGlzIG1ldGhvZCwgYW5kIGV2ZW4gaWYgdGhlcmUg YXJlIHNldmVyYWwgaHVuZHJlZHMgb2YNCmRvbWFpbnMsIGl0IHdpbGwgY29udmVyZ2UgcXVpY2ts eSBhbHNvLiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+V2hhdCBhcmUgeW91ciBvcGluaW9ucz8gSXMgaXQgc3VpdGFibGUNCnRvIHB1dCBmb3J3 YXJkIHRoaXMgcHJvcG9zYWwgaW4gUENFIGdyb3VwPyBBbnkgY29tbWVudHM/PC9mb250Pg0KPGRp dj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDsgJm5ic3A7 IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpCZXN0IHJlZ2FyZHMgJm5ic3A7PC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0ZlaSBa aGFuZzwvZm9udD4NCjxicj4NCjxicj48L2Rpdj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9y bWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRp b24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJz cDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJz cDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5i c3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7 YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7 c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3Rv Jm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZu YnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZu YnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5i c3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZu YnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5i c3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7 dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUm bmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJz cDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJz cDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5i c3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2Ym bmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2Um bmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJz cDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0 ZW0uDQo8L3ByZT4= --=_alternative 0029B85A482575AF_=-- From zhangfatai@huawei.com Thu May 14 02:40:16 2009 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 787923A6EA7 for ; Thu, 14 May 2009 02:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[AWL=0.709, BAYES_05=-1.11, 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 e2TMahrkZhp2 for ; Thu, 14 May 2009 02:40:15 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 6EDDD3A6CD8 for ; Thu, 14 May 2009 02:40:15 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJM00EIKO9LTZ@szxga04-in.huawei.com> for pce@ietf.org; Thu, 14 May 2009 17:41:46 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJM00H2YO9LKE@szxga04-in.huawei.com> for pce@ietf.org; Thu, 14 May 2009 17:41:45 +0800 (CST) Received: from z41162b ([10.70.76.103]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJM00IHZO9LQW@szxml06-in.huawei.com> for pce@ietf.org; Thu, 14 May 2009 17:41:45 +0800 (CST) Date: Thu, 14 May 2009 17:41:45 +0800 From: Fatai Zhang To: pce@ietf.org Message-id: <055101c9d478$31cca8f0$674c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_ByJtF4qYGq9mPsMISZHF4g)" X-Priority: 3 X-MSMail-priority: Normal Subject: [Pce] Discussions on PCE requirements for GMPLS 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, 14 May 2009 09:40:16 -0000 This is a multi-part message in MIME format. --Boundary_(ID_ByJtF4qYGq9mPsMISZHF4g) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi PCEers We have a draft (draft-zhang-pce-reqs-for-tdm-00.txt) in the process. This draft describes some requirements for applying Path Computation Element (PCE) in Time-Division Multiplexing (TDM) networks. I think GMPLS-based TDM networks can be regarded as sub-set of GMPLS networks (for example, GMPLS-based SDH networks), so the requirements described in this draft (PCE for TDM) are sub-set of the requirments for PCE applied in GMPLS networks. Therefore, It seems that there may be something overlapped with another draft (draft-ietf-pce-gmpls-aps-req-00.txt), but there is no discription on these requirements in draft-ietf-pce-gmpls-aps-req-00.txt. In addition, I think it is not a good solution to keep PCE requirements for GMPLS in a few separate documents, so I think it is natural to incorporate the requirements into draft-ietf-pce-gmpls-aps-req-00.txt. Any comments or suggestions are welcome and helpful. Thanks Fatai Advanced Technology Department Wireline Networking Business Unit Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Tel: +86-755-28972912 Fax: +86-755-28972935 --Boundary_(ID_ByJtF4qYGq9mPsMISZHF4g) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi PCEers
 
We have a draft (draft-zhang-pce-reqs-for-tdm-00.txt) in the process. This draft describes some requirements for applying Path Computation Element (PCE) in Time-Division Multiplexing (TDM) networks.
 
I think GMPLS-based TDM networks can be regarded as sub-set of GMPLS networks (for example, GMPLS-based SDH networks), so the requirements described in this draft (PCE for TDM) are sub-set of the requirments for PCE applied in GMPLS networks.
 
Therefore, It seems that there may be something overlapped with another draft (draft-ietf-pce-gmpls-aps-req-00.txt), but there is no discription on these requirements in draft-ietf-pce-gmpls-aps-req-00.txt.
 
In addition, I think it is not a good solution to keep PCE requirements for  GMPLS in a few separate documents, so I think it is natural to incorporate the requirements into draft-ietf-pce-gmpls-aps-req-00.txt.
 
Any comments or suggestions are welcome and helpful.

 
Thanks
 
Fatai
 
Advanced Technology Department
Wireline Networking Business Unit
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935
 
 
--Boundary_(ID_ByJtF4qYGq9mPsMISZHF4g)-- From julien.meuric@orange-ftgroup.com Mon May 18 10:03:20 2009 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 7121F28C0F8 for ; Mon, 18 May 2009 10:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_EQ_FR=0.35] 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 H3DmcO940vg0 for ; Mon, 18 May 2009 10:03:19 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 44E0128C13A for ; Mon, 18 May 2009 10:03:19 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.192.128.41]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 May 2009 19:04:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 May 2009 19:04:53 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02606716A8F@ftrdmel2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Discussions on PCE requirements for GMPLS Thread-Index: AcnUeDZxicLvrP0+RmaIhm4fmHuk1QDXw7RA From: To: X-OriginalArrivalTime: 18 May 2009 17:04:53.0969 (UTC) FILETIME=[C3820410:01C9D7DA] Cc: pce@ietf.org Subject: [Pce] FW: Discussions on PCE requirements for GMPLS 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: Mon, 18 May 2009 17:03:20 -0000 Hello CCAMP. As described by Fatai below, 2 documents are on the table in the PCE WG = to tackle PCE requirements for GMPLS networks. Any feedback that the = group may have would be appreciated. Thanks, Julien ________________________________ From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of = Fatai Zhang Hi PCEers =20 We have a draft (draft-zhang-pce-reqs-for-tdm-00.txt) in the process. = This draft describes some requirements for applying Path Computation = Element (PCE) in Time-Division Multiplexing (TDM) networks.=20 =20 I think GMPLS-based TDM networks can be regarded as sub-set of GMPLS = networks (for example, GMPLS-based SDH networks), so the requirements = described in this draft (PCE for TDM) are sub-set of the requirments for = PCE applied in GMPLS networks. =20 Therefore, It seems that there may be something overlapped with another = draft (draft-ietf-pce-gmpls-aps-req-00.txt), but there is no discription = on these requirements in draft-ietf-pce-gmpls-aps-req-00.txt. =20 In addition, I think it is not a good solution to keep PCE requirements = for GMPLS in a few separate documents, so I think it is natural to = incorporate the requirements into draft-ietf-pce-gmpls-aps-req-00.txt. =20 Any comments or suggestions are welcome and helpful. =20 Thanks =20 Fatai =20 Advanced Technology Department Wireline Networking Business Unit Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Tel: +86-755-28972912 Fax: +86-755-28972935 =20 From diego.caviglia@ericsson.com Mon May 18 23:35:12 2009 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 419683A68B5 for ; Mon, 18 May 2009 23:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.221 X-Spam-Level: X-Spam-Status: No, score=-6.221 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, 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 mrmfz2Z671nc for ; Mon, 18 May 2009 23:35:11 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 0648E3A6B5E for ; Mon, 18 May 2009 23:35:10 -0700 (PDT) X-AuditID: c1b4fb3c-b7bc6ae0000009e3-e9-4a12537dce4d Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id E5.5A.02531.D73521A4; Tue, 19 May 2009 08:36:45 +0200 (CEST) Received: from esealmw110.eemea.ericsson.se ([153.88.200.78]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 May 2009 08:36:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 May 2009 08:36:46 +0200 Message-ID: In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB02606716A8F@ftrdmel2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Discussions on PCE requirements for GMPLS thread-index: AcnUeDZxicLvrP0+RmaIhm4fmHuk1QDXw7RAAB0ziCA= References: <7DBAFEC6A76F3E42817DF1EBE64CB02606716A8F@ftrdmel2> From: "Diego Caviglia" To: , X-OriginalArrivalTime: 19 May 2009 06:36:45.0635 (UTC) FILETIME=[2DEC6130:01C9D84C] X-Brightmail-Tracker: AAAAAA== Cc: pce@ietf.org Subject: Re: [Pce] Discussions on PCE requirements for GMPLS 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, 19 May 2009 06:35:12 -0000 Hi Julien, hi all, I think would be a good idea to merge the document and = not scatter all the GMPLS relevant info among several documents. Thanks Diego > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf > Of julien.meuric@orange-ftgroup.com > Sent: luned=EC 18 maggio 2009 19.05 > To: ccamp@ops.ietf.org > Cc: pce@ietf.org > Subject: FW: [Pce] Discussions on PCE requirements for GMPLS >=20 > Hello CCAMP. >=20 > As described by Fatai below, 2 documents are on the table in the PCE = WG to > tackle PCE requirements for GMPLS networks. Any feedback that the = group > may have would be appreciated. >=20 > Thanks, >=20 > Julien >=20 > ________________________________ >=20 > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of > Fatai Zhang >=20 > Hi PCEers >=20 > We have a draft (draft-zhang-pce-reqs-for-tdm-00.txt) in the process. = This > draft describes some requirements for applying Path Computation = Element > (PCE) in Time-Division Multiplexing (TDM) networks. >=20 > I think GMPLS-based TDM networks can be regarded as sub-set of GMPLS > networks (for example, GMPLS-based SDH networks), so the requirements > described in this draft (PCE for TDM) are sub-set of the requirments = for > PCE applied in GMPLS networks. >=20 > Therefore, It seems that there may be something overlapped with = another > draft (draft-ietf-pce-gmpls-aps-req-00.txt), but there is no = discription > on these requirements in draft-ietf-pce-gmpls-aps-req-00.txt. >=20 > In addition, I think it is not a good solution to keep PCE = requirements > for GMPLS in a few separate documents, so I think it is natural to > incorporate the requirements into draft-ietf-pce-gmpls-aps-req-00.txt. >=20 > Any comments or suggestions are welcome and helpful. >=20 >=20 >=20 > Thanks >=20 > Fatai >=20 > Advanced Technology Department > Wireline Networking Business Unit > Huawei Technologies Co., LTD. > Huawei Base, Bantian, Longgang, > Shenzhen 518129 P.R.China > Tel: +86-755-28972912 > Fax: +86-755-28972935 >=20 From daniel@olddog.co.uk Tue May 19 10:41:27 2009 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 3B64A3A6F23 for ; Tue, 19 May 2009 10:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[AWL=0.502, 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 uTaqln--mZ5C for ; Tue, 19 May 2009 10:41:26 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 965DC3A6ECC for ; Tue, 19 May 2009 10:41:03 -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 n4JHgX6s027957 for ; Tue, 19 May 2009 18:42:33 +0100 Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n4JHgWvS027944 for ; Tue, 19 May 2009 18:42:33 +0100 From: "Daniel King" To: Date: Tue, 19 May 2009 18:42:34 +0100 Message-ID: <005101c9d8a9$31c53450$954f9cf0$@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: AcnYqS+Oz89q4r30TeOLrodF54uxSg== Content-Language: en-gb x-cr-hashedpuzzle: 5ow= Azr+ C8zx DhgM DneR FsQz GA88 GXV+ Ga2j HkGK IuDx KU+C KahS KdFp Lbax MVfc; 1; cABjAGUAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {0D6AAD35-C8E9-49E5-9A87-DE87DA21D6E6}; ZABhAG4AaQBlAGwAQABvAGwAZABkAG8AZwAuAGMAbwAuAHUAawA=; Tue, 19 May 2009 17:42:31 GMT; UABDAEUAIABIAGkAZQByAGEAcgBjAGgAeQAgAEYAcgBhAG0AZQB3AG8AcgBrACAARABvAGMAdQBtAGUAbgB0AA== x-cr-puzzleid: {0D6AAD35-C8E9-49E5-9A87-DE87DA21D6E6} Subject: [Pce] PCE Hierarchy Framework Document 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, 19 May 2009 17:41:27 -0000 Hello PCE'rs, I recently submitted a document to the WG: draft-king-pce-hierarchy-fwk http://tools.ietf.org/id/draft-king-pce-hierarchy-fwk-00.txt The document actually replaces: draft-king-pce-brpc-app http://tools.ietf.org/id/draft-king-pce-brpc-app-00.txt The document examines techniques to establish the optimum path across a series of domains, when the sequence of domains is not known in advance. The work builds on earlier thoughts and suggestions by Adrian and highlights how a hierarchical PCE architecture might be used in order to derive an optimal end-to-end path. As always, your feedback and suggestions are always welcome. Br, Dan. From bao.yuanlin@zte.com.cn Tue May 19 23:41:41 2009 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 398EC3A6E16; Tue, 19 May 2009 23:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.19 X-Spam-Level: X-Spam-Status: No, score=-92.19 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 HV6RlOtxHG+w; Tue, 19 May 2009 23:41:40 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id CDEE53A6B91; Tue, 19 May 2009 23:41:38 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 91103280467362; Wed, 20 May 2009 14:33:54 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.99] with StormMail ESMTP id 59620.5379649218; Wed, 20 May 2009 14:38:17 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n4K5xcmv000421; Wed, 20 May 2009 14:06:50 +0800 (CST) (envelope-from Bao.Yuanlin@zte.com.cn) In-Reply-To: <005101c9d8a9$31c53450$954f9cf0$@co.uk> To: "Daniel King" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Bao.Yuanlin@zte.com.cn Date: Wed, 20 May 2009 14:03:40 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-05-20 14:06:42, Serialize complete at 2009-05-20 14:06:42 Content-Type: multipart/alternative; boundary="=_alternative 002155A5482575BC_=" X-MAIL: mse2.zte.com.cn n4K5xcmv000421 Cc: pce-bounces@ietf.org, pce@ietf.org Subject: [Pce] =?gb2312?b?tPC4tDogIFBDRSBIaWVyYXJjaHkgRnJhbWV3b3JrIERvY3Vt?= =?gb2312?b?ZW50?= 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, 20 May 2009 06:41:41 -0000 This is a multipart message in MIME format. --=_alternative 002155A5482575BC_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgRGFuaWVsOg0KDQogICBJbiB0aGUgc2VjdGlvbiA1LjMsICJQQ0UgRGlzY292ZXJ5IiwgeW91 IHNhaWQgIk1lY2hhbmlzbXMgdGhhdCByZWx5IG9uIA0KYWR2ZXJ0aXNpbmcgDQoNCiAgIG9yIHF1 ZXJ5aW5nIFBDRSBsb2NhdGlvbnMgYWNyb3NzIGRvbWFpbnMgb3IgcHJvdmlkZXIgYm91bmRhcmll cyBhcmUgDQp1bmRlc2lyYWJsZS4iLg0KDQogICBJIHdhbnQgdG8ga25vdyB3aHkgaXQgaXMgYW4g InVuZGVzaXJhYmxlIiB3YXkuDQoNCiAgIENhbiB5b3UgZWxhYm9yYXRlIG9uIHlvdXIgcG9pbnQg b2Ygdmlldz8NCg0KDQpUaGFua3MNCiANCll1YW5saW4NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KcGNlLWJvdW5j ZXNAaWV0Zi5vcmcg0LTT2iAyMDA5LTA1LTIwIDAxOjQyOjM0Og0KDQo+IEhlbGxvIFBDRSdycywg DQo+IA0KPiBJIHJlY2VudGx5IHN1Ym1pdHRlZCBhIGRvY3VtZW50IHRvIHRoZSBXRzogDQo+IA0K PiBkcmFmdC1raW5nLXBjZS1oaWVyYXJjaHktZndrDQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9p ZC9kcmFmdC1raW5nLXBjZS1oaWVyYXJjaHktZndrLTAwLnR4dA0KPiANCj4gVGhlIGRvY3VtZW50 IGFjdHVhbGx5IHJlcGxhY2VzOg0KPiANCj4gZHJhZnQta2luZy1wY2UtYnJwYy1hcHANCj4gaHR0 cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWtpbmctcGNlLWJycGMtYXBwLTAwLnR4dA0KPiAN Cj4gVGhlIGRvY3VtZW50IGV4YW1pbmVzIHRlY2huaXF1ZXMgdG8gZXN0YWJsaXNoIHRoZSBvcHRp bXVtIHBhdGggYWNyb3NzIGENCj4gc2VyaWVzIG9mIGRvbWFpbnMsIHdoZW4gdGhlIHNlcXVlbmNl IG9mIGRvbWFpbnMgaXMgbm90IGtub3duIGluIGFkdmFuY2UuIA0KVGhlDQo+IHdvcmsgYnVpbGRz IG9uIGVhcmxpZXIgdGhvdWdodHMgYW5kIHN1Z2dlc3Rpb25zIGJ5IEFkcmlhbiBhbmQgaGlnaGxp Z2h0cyANCmhvdw0KPiBhIGhpZXJhcmNoaWNhbCBQQ0UgYXJjaGl0ZWN0dXJlIG1pZ2h0IGJlIHVz ZWQgaW4gb3JkZXIgdG8gZGVyaXZlIGFuIA0Kb3B0aW1hbA0KPiBlbmQtdG8tZW5kIHBhdGguIA0K PiANCj4gQXMgYWx3YXlzLCB5b3VyIGZlZWRiYWNrIGFuZCBzdWdnZXN0aW9ucyBhcmUgYWx3YXlz IHdlbGNvbWUuIA0KPiANCj4gQnIsIERhbi4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBQY2UgbWFpbGluZyBsaXN0DQo+IFBjZUBpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjZQ0KDQo= --=_alternative 002155A5482575BC_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIERhbmllbDo8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDs8L2Zv bnQ+PGZvbnQgc2l6ZT0yPjx0dD5Jbg0KdGhlIHNlY3Rpb24gNS4zLCAmcXVvdDtQQ0UgRGlzY292 ZXJ5JnF1b3Q7LCB5b3UgPC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IlZlcmRhbmEiPnNh aWQ8L2ZvbnQ+PGZvbnQgc2l6ZT0yPg0KPC9mb250Pjxmb250IHNpemU9Mj48dHQ+JnF1b3Q7TWVj aGFuaXNtcyB0aGF0IHJlbHkgb24gYWR2ZXJ0aXNpbmcgPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yPjx0dD4mbmJzcDsgJm5ic3A7b3IgcXVlcnlpbmcgUENFIGxvY2F0aW9ucyBh Y3Jvc3MgZG9tYWlucw0Kb3IgcHJvdmlkZXIgYm91bmRhcmllcyBhcmUgdW5kZXNpcmFibGUuJnF1 b3Q7LjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jm5ic3A7ICZuYnNw O0kgd2FudCB0byBrbm93IHdoeSBpdCBpcyBhbiAmcXVvdDt1bmRlc2lyYWJsZSZxdW90Ow0Kd2F5 LjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jm5ic3A7ICZuYnNwO0Nh biB5b3UgZWxhYm9yYXRlIG9uIHlvdXIgcG9pbnQgb2Ygdmlldz88YnI+DQo8L3R0PjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0PlRoYW5rczxicj4NCiA8YnI+DQpZdWFubGluPGJy Pg0KPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4N Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0PnBjZS1ib3VuY2VzQGll dGYub3JnINC009ogMjAwOS0wNS0yMCAwMTo0MjozNDo8YnI+DQo8YnI+DQomZ3Q7IEhlbGxvIFBD RSdycywgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgcmVjZW50bHkgc3VibWl0dGVkIGEgZG9jdW1l bnQgdG8gdGhlIFdHOiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgZHJhZnQta2luZy1wY2UtaGllcmFy Y2h5LWZ3azxicj4NCiZndDsgaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWtpbmctcGNl LWhpZXJhcmNoeS1md2stMDAudHh0PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBkb2N1bWVudCBh Y3R1YWxseSByZXBsYWNlczo8YnI+DQomZ3Q7IDxicj4NCiZndDsgZHJhZnQta2luZy1wY2UtYnJw Yy1hcHA8YnI+DQomZ3Q7IGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1raW5nLXBjZS1i cnBjLWFwcC0wMC50eHQ8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIGRvY3VtZW50IGV4YW1pbmVz IHRlY2huaXF1ZXMgdG8gZXN0YWJsaXNoIHRoZSBvcHRpbXVtIHBhdGggYWNyb3NzDQphPGJyPg0K Jmd0OyBzZXJpZXMgb2YgZG9tYWlucywgd2hlbiB0aGUgc2VxdWVuY2Ugb2YgZG9tYWlucyBpcyBu b3Qga25vd24gaW4gYWR2YW5jZS4NClRoZTxicj4NCiZndDsgd29yayBidWlsZHMgb24gZWFybGll ciB0aG91Z2h0cyBhbmQgc3VnZ2VzdGlvbnMgYnkgQWRyaWFuIGFuZCBoaWdobGlnaHRzDQpob3c8 YnI+DQomZ3Q7IGEgaGllcmFyY2hpY2FsIFBDRSBhcmNoaXRlY3R1cmUgbWlnaHQgYmUgdXNlZCBp biBvcmRlciB0byBkZXJpdmUgYW4NCm9wdGltYWw8YnI+DQomZ3Q7IGVuZC10by1lbmQgcGF0aC4g PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFzIGFsd2F5cywgeW91ciBmZWVkYmFjayBhbmQgc3VnZ2Vz dGlvbnMgYXJlIGFsd2F5cyB3ZWxjb21lLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgQnIsIERhbi4g PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KJmd0OyBQY2UgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBQY2VAaWV0 Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNl PGJyPg0KPC90dD48L2ZvbnQ+DQo= --=_alternative 002155A5482575BC_=-- From jvasseur@cisco.com Wed May 20 00:58:42 2009 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 5BFEE3A6BF2; Wed, 20 May 2009 00:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.279 X-Spam-Level: X-Spam-Status: No, score=-4.279 tagged_above=-999 required=5 tests=[AWL=-5.576, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 XxC47JI3ANv7; Wed, 20 May 2009 00:58:41 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 4736E3A6818; Wed, 20 May 2009 00:58:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,220,1241395200"; d="scan'208,217";a="187907022" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-1.cisco.com with ESMTP; 20 May 2009 07:38:13 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n4K7cCe0017996; Wed, 20 May 2009 09:38:12 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4K7cCn4007364; Wed, 20 May 2009 07:38:12 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 May 2009 09:38:12 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 May 2009 09:38:11 +0200 Message-Id: <9BC6D003-8DC0-42E6-A402-0195D44EC90F@cisco.com> From: JP Vasseur To: Bao.Yuanlin@zte.com.cn In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-69-357400878 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 20 May 2009 09:38:09 +0200 References: X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 20 May 2009 07:38:11.0936 (UTC) FILETIME=[ED8B0600:01C9D91D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5615; t=1242805092; x=1243669092; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20=3D?GB2312?Q?Re=3A_[Pce]_=3DB4=3DF0=3DB8=3DB4=3 A__PCE_Hierarchy_Framework_Docu?=3D=0A=20=3D?GB2312?Q?ment?= 3D |Sender:=20; bh=f51TWOTbu4AtbMghf9N8wKA1m4JBZO6iNqIdxBxjKl4=; b=H4K/alefxYM+GxJGBEvirj/M5B3q9hnqDFqH6ICDyArtVvWVM3u95e+tI0 UMC+BVptLwgqLNzbXL0Cxi4mhGjpRrsrexTCx+RJb/d1Yu2RkI4tqCoCd5Fv kF5iZv2bIz; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: pce-bounces@ietf.org, pce@ietf.org Subject: Re: [Pce] =?gb2312?b?tPC4tDogIFBDRSBIaWVyYXJjaHkgRnJhbWV3b3JrIERvY3Vt?= =?gb2312?b?ZW50?= 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, 20 May 2009 07:58:42 -0000 --Apple-Mail-69-357400878 Content-Type: text/plain; charset=GB2312; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On May 20, 2009, at 8:03 AM, Bao.Yuanlin@zte.com.cn wrote: > > Hi Daniel: > > In the section 5.3, "PCE Discovery", you said "Mechanisms that =20 > rely on advertising > > or querying PCE locations across domains or provider boundaries =20 > are undesirable.". > > I want to know why it is an "undesirable" way. > For the record, we has in the WG, long discussion on whether we should =20= advertise PCE across domains using for example BGP for that matter. =20 There was a good consensus not to, considering the limited number of =20 interconnected domains. The advantage was limited and introduces other =20= issues (security) ... Thanks. JP. > Can you elaborate on your point of view? > > > Thanks > > Yuanlin > > > --------------------------------------------------------------- > > pce-bounces@ietf.org =D0=B4=D3=DA 2009-05-20 01:42:34: > > > Hello PCE'rs, > > > > I recently submitted a document to the WG: > > > > draft-king-pce-hierarchy-fwk > > http://tools.ietf.org/id/draft-king-pce-hierarchy-fwk-00.txt > > > > The document actually replaces: > > > > draft-king-pce-brpc-app > > http://tools.ietf.org/id/draft-king-pce-brpc-app-00.txt > > > > The document examines techniques to establish the optimum path =20 > across a > > series of domains, when the sequence of domains is not known in =20 > advance. The > > work builds on earlier thoughts and suggestions by Adrian and =20 > highlights how > > a hierarchical PCE architecture might be used in order to derive =20 > an optimal > > end-to-end path. > > > > As always, your feedback and suggestions are always welcome. > > > > Br, Dan. > > > > _______________________________________________ > > Pce mailing list > > Pce@ietf.org > > https://www.ietf.org/mailman/listinfo/pce > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce --Apple-Mail-69-357400878 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
On May 20, 2009, = at 8:03 AM, Bao.Yuanlin@zte.com.cn = wrote:


Hi Daniel: =

   In the section 5.3, "PCE Discovery", you = said= "Mechanisms that rely on advertising =

   or querying PCE = locations across domains or provider boundaries are = undesirable.".

   I = want to know why it is an "undesirable" way.
=

For the record, we has in the WG, = long discussion on whether we should advertise = PCE across domains using for example BGP for that matter. = There was a good consensus not to, considering the limited number of = interconnected domains. The advantage was limited and introduces other = issues (security) = ...

Thanks.

JP.
   Can you = elaborate on your point of view?

Thanks

Yuanlin

= --------------------------------------------------------------- =

pce-bounces@ietf.org =D0=B4=D3=DA= 2009-05-20 01:42:34:

> Hello PCE'rs,
>
> I = recently submitted a document to the WG:
>
> = draft-king-pce-hierarchy-fwk
> http= ://tools.ietf.org/id/draft-king-pce-hierarchy-fwk-00.txt
> =
> The document actually replaces:
>
> = draft-king-pce-brpc-app
> http://to= ols.ietf.org/id/draft-king-pce-brpc-app-00.txt
>
> = The document examines techniques to establish the optimum path across = a
> series of domains, when the sequence of domains is not known = in advance. The
> work builds on earlier thoughts and suggestions = by Adrian and highlights how
> a hierarchical PCE architecture = might be used in order to derive an optimal
> end-to-end path. =
>
> As always, your feedback and suggestions are always = welcome.
>
> Br, Dan.
>
> = _______________________________________________
> Pce mailing = list
> Pce@ietf.org
> = https://www.ietf.org/ma= ilman/listinfo/pce
 = _______________________________________________
Pce mailing = list
Pce@ietf.org
https://www.ietf.org/mail= man/listinfo/pce

= --Apple-Mail-69-357400878-- From adrian@olddog.co.uk Wed May 20 01:18:09 2009 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 43DB03A6C0B for ; Wed, 20 May 2009 01:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.835 X-Spam-Level: X-Spam-Status: No, score=-0.835 tagged_above=-999 required=5 tests=[AWL=-0.837, 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 UU2qAFKev+bm for ; Wed, 20 May 2009 01:18:07 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 94C073A6B83 for ; Wed, 20 May 2009 01:18:05 -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 n4K8JfPE028461 for ; Wed, 20 May 2009 09:19:41 +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 n4K8JKtJ028069 for ; Wed, 20 May 2009 09:19:40 +0100 Message-ID: From: "Adrian Farrel" To: References: <9BC6D003-8DC0-42E6-A402-0195D44EC90F@cisco.com> Date: Wed, 20 May 2009 09:19:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="gb2312"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Pce] : PCE Hierarchy Framework Document 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: Wed, 20 May 2009 08:18:09 -0000 [As an individual and co-author] >> In the section 5.3, "PCE Discovery", you said "Mechanisms >> that rely on advertising or querying PCE locations across >> domains or provider boundaries are undesirable.". >> >> I want to know why it is an "undesirable" way. >> > > For the record, we has in the WG, long discussion on whether > we should advertise PCE across domains using for example BGP > for that matter. > There was a good consensus not to, considering the limited > number of interconnected domains. The advantage was limited > and introduces other issues (security) ... Right. I recall that discussion. And the situation with hierarchical PCE is worse. Consider, a child PCE in domain-A does not know where the Parent PCE is. It could be in *any* domain. In order to make contact with the parent PCE, the child must either know where the parent is (configuration as recommended in the I-D), or advertise itself across *all* domains. That is, for child-advertisement to work, every PCE in the network must broadcast an advertisement to every other node in every other domain in the whole network. This is "undesirable". Alternatively, consider a parent PCE that wants to contact the PCEs in each of domain-A, B, ..., Z. It could be configured (as recommended in this I-D) or it must send a broadcast query message to every node in each domain. Since there is no domain address aggregation(CIDR being just a dream) the parent PCE must broadcast to every node in the entire network. This is "undesirable". That is, both approaches to discovery are simply not scalable, and would probably be filtered out at domain boundaries anyway. With hierarchical PCE, we are looking at a peering relationship that is certainly administrative and probably commercial. Such relationships involve a lot of configuration and negotiation. Adding the configuration of parent/child PCE locations is an almost trivial addition. Cheers, Adrian From bao.yuanlin@zte.com.cn Wed May 20 02:18:41 2009 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 549983A6C1E; Wed, 20 May 2009 02:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.635 X-Spam-Level: X-Spam-Status: No, score=-97.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, 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 GgfhIpO2MrbF; Wed, 20 May 2009 02:18:40 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id A56453A6C2A; Wed, 20 May 2009 02:18:38 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111643280467362; Wed, 20 May 2009 17:07:21 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.100] with StormMail ESMTP id 30761.3390365658; Wed, 20 May 2009 17:12:32 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n4K937rd038786; Wed, 20 May 2009 17:03:08 +0800 (CST) (envelope-from Bao.Yuanlin@zte.com.cn) In-Reply-To: To: Adrian Farrel MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Bao.Yuanlin@zte.com.cn Date: Wed, 20 May 2009 17:00:42 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-05-20 17:02:58, Serialize complete at 2009-05-20 17:02:58 Content-Type: multipart/alternative; boundary="=_alternative 00318AF1482575BC_=" X-MAIL: mse1.zte.com.cn n4K937rd038786 Cc: pce-bounces@ietf.org, pce@ietf.org Subject: Re: [Pce] : PCE Hierarchy Framework Document 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, 20 May 2009 09:18:41 -0000 This is a multipart message in MIME format. --=_alternative 00318AF1482575BC_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SSBnb3QgaXQuIFRoYW5rcyBmb3IgeW91ciBleHBsYW5hdGlvbi4NCg0KDQoNClRoYW5rcw0KDQpZ dWFubGluDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KcGNlLWJvdW5jZXNAaWV0Zi5vcmcg0LTT2iAyMDA5 LTA1LTIwIDE2OjE5OjE3Og0KDQo+IFtBcyBhbiBpbmRpdmlkdWFsIGFuZCBjby1hdXRob3JdDQo+ IA0KPiA+PiBJbiB0aGUgc2VjdGlvbiA1LjMsICJQQ0UgRGlzY292ZXJ5IiwgeW91IHNhaWQgIk1l Y2hhbmlzbXMNCj4gPj4gdGhhdCByZWx5IG9uIGFkdmVydGlzaW5nIG9yIHF1ZXJ5aW5nIFBDRSBs b2NhdGlvbnMgYWNyb3NzDQo+ID4+IGRvbWFpbnMgb3IgcHJvdmlkZXIgYm91bmRhcmllcyBhcmUg dW5kZXNpcmFibGUuIi4NCj4gPj4NCj4gPj4gSSB3YW50IHRvIGtub3cgd2h5IGl0IGlzIGFuICJ1 bmRlc2lyYWJsZSIgd2F5Lg0KPiA+Pg0KPiA+DQo+ID4gRm9yIHRoZSByZWNvcmQsIHdlIGhhcyBp biB0aGUgV0csIGxvbmcgZGlzY3Vzc2lvbiBvbiB3aGV0aGVyDQo+ID4gd2Ugc2hvdWxkIGFkdmVy dGlzZSBQQ0UgYWNyb3NzIGRvbWFpbnMgdXNpbmcgZm9yIGV4YW1wbGUgQkdQDQo+ID4gZm9yIHRo YXQgbWF0dGVyLg0KPiA+IFRoZXJlIHdhcyBhIGdvb2QgY29uc2Vuc3VzIG5vdCB0bywgY29uc2lk ZXJpbmcgdGhlIGxpbWl0ZWQNCj4gPiBudW1iZXIgb2YgaW50ZXJjb25uZWN0ZWQgZG9tYWlucy4g VGhlIGFkdmFudGFnZSB3YXMgbGltaXRlZA0KPiA+IGFuZCBpbnRyb2R1Y2VzIG90aGVyIGlzc3Vl cyAoc2VjdXJpdHkpIC4uLg0KPiANCj4gUmlnaHQuIEkgcmVjYWxsIHRoYXQgZGlzY3Vzc2lvbi4N Cj4gDQo+IEFuZCB0aGUgc2l0dWF0aW9uIHdpdGggaGllcmFyY2hpY2FsIFBDRSBpcyB3b3JzZS4N Cj4gDQo+IENvbnNpZGVyLCBhIGNoaWxkIFBDRSBpbiBkb21haW4tQSBkb2VzIG5vdCBrbm93IHdo ZXJlIHRoZSBQYXJlbnQgUENFIGlzLiANCkl0IA0KPiBjb3VsZCBiZSBpbiAqYW55KiBkb21haW4u IEluIG9yZGVyIHRvIG1ha2UgY29udGFjdCB3aXRoIHRoZSBwYXJlbnQgUENFLCANCnRoZSANCj4g Y2hpbGQgbXVzdCBlaXRoZXIga25vdyB3aGVyZSB0aGUgcGFyZW50IGlzIChjb25maWd1cmF0aW9u IGFzIHJlY29tbWVuZGVkIA0KaW4gDQo+IHRoZSBJLUQpLCBvciBhZHZlcnRpc2UgaXRzZWxmIGFj cm9zcyAqYWxsKiBkb21haW5zLiBUaGF0IGlzLCBmb3IgDQo+IGNoaWxkLWFkdmVydGlzZW1lbnQg dG8gd29yaywgZXZlcnkgUENFIGluIHRoZSBuZXR3b3JrIG11c3QgYnJvYWRjYXN0IGFuIA0KPiBh ZHZlcnRpc2VtZW50IHRvIGV2ZXJ5IG90aGVyIG5vZGUgaW4gZXZlcnkgb3RoZXIgZG9tYWluIGlu IHRoZSB3aG9sZSANCj4gbmV0d29yay4gVGhpcyBpcyAidW5kZXNpcmFibGUiLg0KPiANCj4gQWx0 ZXJuYXRpdmVseSwgY29uc2lkZXIgYSBwYXJlbnQgUENFIHRoYXQgd2FudHMgdG8gY29udGFjdCB0 aGUgUENFcyBpbiANCmVhY2ggDQo+IG9mIGRvbWFpbi1BLCBCLCAuLi4sIFouIEl0IGNvdWxkIGJl IGNvbmZpZ3VyZWQgKGFzIHJlY29tbWVuZGVkIGluIHRoaXMgDQpJLUQpIA0KPiBvciBpdCBtdXN0 IHNlbmQgYSBicm9hZGNhc3QgcXVlcnkgbWVzc2FnZSB0byBldmVyeSBub2RlIGluIGVhY2ggZG9t YWluLiANCj4gU2luY2UgdGhlcmUgaXMgbm8gZG9tYWluIGFkZHJlc3MgYWdncmVnYXRpb24oQ0lE UiBiZWluZyBqdXN0IGEgZHJlYW0pIA0KdGhlIA0KPiBwYXJlbnQgUENFIG11c3QgYnJvYWRjYXN0 IHRvIGV2ZXJ5IG5vZGUgaW4gdGhlIGVudGlyZSBuZXR3b3JrLiBUaGlzIGlzIA0KPiAidW5kZXNp cmFibGUiLg0KPiANCj4gVGhhdCBpcywgYm90aCBhcHByb2FjaGVzIHRvIGRpc2NvdmVyeSBhcmUg c2ltcGx5IG5vdCBzY2FsYWJsZSwgYW5kIHdvdWxkIA0KDQo+IHByb2JhYmx5IGJlIGZpbHRlcmVk IG91dCBhdCBkb21haW4gYm91bmRhcmllcyBhbnl3YXkuDQo+IA0KPiBXaXRoIGhpZXJhcmNoaWNh bCBQQ0UsIHdlIGFyZSBsb29raW5nIGF0IGEgcGVlcmluZyByZWxhdGlvbnNoaXAgdGhhdCBpcyAN Cj4gY2VydGFpbmx5IGFkbWluaXN0cmF0aXZlIGFuZCBwcm9iYWJseSBjb21tZXJjaWFsLiBTdWNo IHJlbGF0aW9uc2hpcHMgDQppbnZvbHZlIA0KPiBhIGxvdCBvZiBjb25maWd1cmF0aW9uIGFuZCBu ZWdvdGlhdGlvbi4gQWRkaW5nIHRoZSBjb25maWd1cmF0aW9uIG9mIA0KPiBwYXJlbnQvY2hpbGQg UENFIGxvY2F0aW9ucyBpcyBhbiBhbG1vc3QgdHJpdmlhbCBhZGRpdGlvbi4NCj4gDQo+IENoZWVy cywNCj4gQWRyaWFuDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gUGNlIG1haWxpbmcgbGlzdA0KPiBQY2VAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY2UNCg0K --=_alternative 00318AF1482575BC_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgZ290IGl0LiBUaGFua3MgZm9y IHlvdXI8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250 IHNpemU9Mj5leHBsYW5hdGlvbjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ LjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0PlRoYW5rczxi cj4NCjxicj4NCll1YW5saW48L3R0PjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+PGJyPg0KPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0PnBjZS1ib3Vu Y2VzQGlldGYub3JnINC009ogMjAwOS0wNS0yMCAxNjoxOToxNzo8YnI+DQo8YnI+DQomZ3Q7IFtB cyBhbiBpbmRpdmlkdWFsIGFuZCBjby1hdXRob3JdPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsm Z3Q7IEluIHRoZSBzZWN0aW9uIDUuMywgJnF1b3Q7UENFIERpc2NvdmVyeSZxdW90OywgeW91IHNh aWQgJnF1b3Q7TWVjaGFuaXNtczxicj4NCiZndDsgJmd0OyZndDsgdGhhdCByZWx5IG9uIGFkdmVy dGlzaW5nIG9yIHF1ZXJ5aW5nIFBDRSBsb2NhdGlvbnMgYWNyb3NzPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyBkb21haW5zIG9yIHByb3ZpZGVyIGJvdW5kYXJpZXMgYXJlIHVuZGVzaXJhYmxlLiZxdW90Oy48 YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBJIHdhbnQgdG8ga25vdyB3aHkg aXQgaXMgYW4gJnF1b3Q7dW5kZXNpcmFibGUmcXVvdDsgd2F5Ljxicj4NCiZndDsgJmd0OyZndDs8 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgRm9yIHRoZSByZWNvcmQsIHdlIGhhcyBpbiB0 aGUgV0csIGxvbmcgZGlzY3Vzc2lvbiBvbiB3aGV0aGVyPGJyPg0KJmd0OyAmZ3Q7IHdlIHNob3Vs ZCBhZHZlcnRpc2UgUENFIGFjcm9zcyBkb21haW5zIHVzaW5nIGZvciBleGFtcGxlIEJHUDxicj4N CiZndDsgJmd0OyBmb3IgdGhhdCBtYXR0ZXIuPGJyPg0KJmd0OyAmZ3Q7IFRoZXJlIHdhcyBhIGdv b2QgY29uc2Vuc3VzIG5vdCB0bywgY29uc2lkZXJpbmcgdGhlIGxpbWl0ZWQ8YnI+DQomZ3Q7ICZn dDsgbnVtYmVyIG9mIGludGVyY29ubmVjdGVkIGRvbWFpbnMuIFRoZSBhZHZhbnRhZ2Ugd2FzIGxp bWl0ZWQ8YnI+DQomZ3Q7ICZndDsgYW5kIGludHJvZHVjZXMgb3RoZXIgaXNzdWVzIChzZWN1cml0 eSkgLi4uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJpZ2h0LiBJIHJlY2FsbCB0aGF0IGRpc2N1c3Np b24uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFuZCB0aGUgc2l0dWF0aW9uIHdpdGggaGllcmFyY2hp Y2FsIFBDRSBpcyB3b3JzZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgQ29uc2lkZXIsIGEgY2hpbGQg UENFIGluIGRvbWFpbi1BIGRvZXMgbm90IGtub3cgd2hlcmUgdGhlIFBhcmVudCBQQ0UNCmlzLiBJ dCA8YnI+DQomZ3Q7IGNvdWxkIGJlIGluICphbnkqIGRvbWFpbi4gSW4gb3JkZXIgdG8gbWFrZSBj b250YWN0IHdpdGggdGhlIHBhcmVudA0KUENFLCB0aGUgPGJyPg0KJmd0OyBjaGlsZCBtdXN0IGVp dGhlciBrbm93IHdoZXJlIHRoZSBwYXJlbnQgaXMgKGNvbmZpZ3VyYXRpb24gYXMgcmVjb21tZW5k ZWQNCmluIDxicj4NCiZndDsgdGhlIEktRCksIG9yIGFkdmVydGlzZSBpdHNlbGYgYWNyb3NzICph bGwqIGRvbWFpbnMuIFRoYXQgaXMsIGZvciA8YnI+DQomZ3Q7IGNoaWxkLWFkdmVydGlzZW1lbnQg dG8gd29yaywgZXZlcnkgUENFIGluIHRoZSBuZXR3b3JrIG11c3QgYnJvYWRjYXN0DQphbiA8YnI+ DQomZ3Q7IGFkdmVydGlzZW1lbnQgdG8gZXZlcnkgb3RoZXIgbm9kZSBpbiBldmVyeSBvdGhlciBk b21haW4gaW4gdGhlIHdob2xlDQo8YnI+DQomZ3Q7IG5ldHdvcmsuIFRoaXMgaXMgJnF1b3Q7dW5k ZXNpcmFibGUmcXVvdDsuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFsdGVybmF0aXZlbHksIGNvbnNp ZGVyIGEgcGFyZW50IFBDRSB0aGF0IHdhbnRzIHRvIGNvbnRhY3QgdGhlIFBDRXMNCmluIGVhY2gg PGJyPg0KJmd0OyBvZiBkb21haW4tQSwgQiwgLi4uLCBaLiBJdCBjb3VsZCBiZSBjb25maWd1cmVk IChhcyByZWNvbW1lbmRlZCBpbg0KdGhpcyBJLUQpIDxicj4NCiZndDsgb3IgaXQgbXVzdCBzZW5k IGEgYnJvYWRjYXN0IHF1ZXJ5IG1lc3NhZ2UgdG8gZXZlcnkgbm9kZSBpbiBlYWNoIGRvbWFpbi4N Cjxicj4NCiZndDsgU2luY2UgdGhlcmUgaXMgbm8gZG9tYWluIGFkZHJlc3MgYWdncmVnYXRpb24o Q0lEUiBiZWluZyBqdXN0IGEgZHJlYW0pDQp0aGUgPGJyPg0KJmd0OyBwYXJlbnQgUENFIG11c3Qg YnJvYWRjYXN0IHRvIGV2ZXJ5IG5vZGUgaW4gdGhlIGVudGlyZSBuZXR3b3JrLiBUaGlzDQppcyA8 YnI+DQomZ3Q7ICZxdW90O3VuZGVzaXJhYmxlJnF1b3Q7Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBU aGF0IGlzLCBib3RoIGFwcHJvYWNoZXMgdG8gZGlzY292ZXJ5IGFyZSBzaW1wbHkgbm90IHNjYWxh YmxlLCBhbmQNCndvdWxkIDxicj4NCiZndDsgcHJvYmFibHkgYmUgZmlsdGVyZWQgb3V0IGF0IGRv bWFpbiBib3VuZGFyaWVzIGFueXdheS48YnI+DQomZ3Q7IDxicj4NCiZndDsgV2l0aCBoaWVyYXJj aGljYWwgUENFLCB3ZSBhcmUgbG9va2luZyBhdCBhIHBlZXJpbmcgcmVsYXRpb25zaGlwIHRoYXQN CmlzIDxicj4NCiZndDsgY2VydGFpbmx5IGFkbWluaXN0cmF0aXZlIGFuZCBwcm9iYWJseSBjb21t ZXJjaWFsLiBTdWNoIHJlbGF0aW9uc2hpcHMNCmludm9sdmUgPGJyPg0KJmd0OyBhIGxvdCBvZiBj b25maWd1cmF0aW9uIGFuZCBuZWdvdGlhdGlvbi4gQWRkaW5nIHRoZSBjb25maWd1cmF0aW9uIG9m DQo8YnI+DQomZ3Q7IHBhcmVudC9jaGlsZCBQQ0UgbG9jYXRpb25zIGlzIGFuIGFsbW9zdCB0cml2 aWFsIGFkZGl0aW9uLjxicj4NCiZndDsgPGJyPg0KJmd0OyBDaGVlcnMsPGJyPg0KJmd0OyBBZHJp YW48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgUGNlIG1haWxpbmcgbGlzdDxicj4N CiZndDsgUGNlQGlldGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3BjZTxicj4NCjwvdHQ+PC9mb250Pg0K --=_alternative 00318AF1482575BC_=-- From gregb@grotto-networking.com Wed May 20 13:35:30 2009 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 1CDE23A6ED1 for ; Wed, 20 May 2009 13:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 DICN6w5jQWdo for ; Wed, 20 May 2009 13:35:29 -0700 (PDT) Received: from pro46.abac.com (pro46.abac.com [66.226.64.47]) by core3.amsl.com (Postfix) with ESMTP id 4B7DA3A689A for ; Wed, 20 May 2009 13:35:29 -0700 (PDT) Received: from [192.168.0.131] (c-71-202-41-42.hsd1.ca.comcast.net [71.202.41.42] (may be forged)) (authenticated bits=0) by pro46.abac.com (8.14.3/8.14.3) with ESMTP id n4KKawPG048392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 May 2009 13:37:02 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <4A1469EA.4000205@grotto-networking.com> Date: Wed, 20 May 2009 13:36:58 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: julien.meuric@orange-ftgroup.com References: <7DBAFEC6A76F3E42817DF1EBE64CB02606716A8F@ftrdmel2> In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB02606716A8F@ftrdmel2> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ccamp@ops.ietf.org, pce@ietf.org Subject: Re: [Pce] FW: Discussions on PCE requirements for GMPLS 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, 20 May 2009 20:35:30 -0000 Merging sounds like a good idea to me. Cheers Greg julien.meuric@orange-ftgroup.com wrote: > Hello CCAMP. > > As described by Fatai below, 2 documents are on the table in the PCE WG to tackle PCE requirements for GMPLS networks. Any feedback that the group may have would be appreciated. > > Thanks, > > Julien > > ________________________________ > > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Fatai Zhang > > Hi PCEers > > We have a draft (draft-zhang-pce-reqs-for-tdm-00.txt) in the process. This draft describes some requirements for applying Path Computation Element (PCE) in Time-Division Multiplexing (TDM) networks. > > I think GMPLS-based TDM networks can be regarded as sub-set of GMPLS networks (for example, GMPLS-based SDH networks), so the requirements described in this draft (PCE for TDM) are sub-set of the requirments for PCE applied in GMPLS networks. > > Therefore, It seems that there may be something overlapped with another draft (draft-ietf-pce-gmpls-aps-req-00.txt), but there is no discription on these requirements in draft-ietf-pce-gmpls-aps-req-00.txt. > > In addition, I think it is not a good solution to keep PCE requirements for GMPLS in a few separate documents, so I think it is natural to incorporate the requirements into draft-ietf-pce-gmpls-aps-req-00.txt. > > Any comments or suggestions are welcome and helpful. > > > > Thanks > > Fatai > > Advanced Technology Department > Wireline Networking Business Unit > Huawei Technologies Co., LTD. > Huawei Base, Bantian, Longgang, > Shenzhen 518129 P.R.China > Tel: +86-755-28972912 > Fax: +86-755-28972935 > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From gregb@grotto-networking.com Wed May 20 14:28:38 2009 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 C3AAD3A6A15 for ; Wed, 20 May 2009 14:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, 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 ayuusOyHftpq for ; Wed, 20 May 2009 14:28:38 -0700 (PDT) Received: from pro46.abac.com (pro46.abac.com [66.226.64.47]) by core3.amsl.com (Postfix) with ESMTP id 187643A67A1 for ; Wed, 20 May 2009 14:28:38 -0700 (PDT) Received: from [192.168.0.131] (c-71-202-41-42.hsd1.ca.comcast.net [71.202.41.42] (may be forged)) (authenticated bits=0) by pro46.abac.com (8.14.3/8.14.3) with ESMTP id n4KLU7Db028415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 May 2009 14:30:09 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <4A14765F.2010907@grotto-networking.com> Date: Wed, 20 May 2009 14:30:07 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Daniel King References: <005101c9d8a9$31c53450$954f9cf0$@co.uk> In-Reply-To: <005101c9d8a9$31c53450$954f9cf0$@co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pce@ietf.org Subject: Re: [Pce] PCE Hierarchy Framework Document 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, 20 May 2009 21:28:38 -0000 Hi Daniel, nice draft. This sounds very reasonable. As one who worked on G.7715, the use PCE in this context seem very natural. Cheers Greg Daniel King wrote: > Hello PCE'rs, > > I recently submitted a document to the WG: > > draft-king-pce-hierarchy-fwk > http://tools.ietf.org/id/draft-king-pce-hierarchy-fwk-00.txt > > The document actually replaces: > > draft-king-pce-brpc-app > http://tools.ietf.org/id/draft-king-pce-brpc-app-00.txt > > The document examines techniques to establish the optimum path across a > series of domains, when the sequence of domains is not known in advance. The > work builds on earlier thoughts and suggestions by Adrian and highlights how > a hierarchical PCE architecture might be used in order to derive an optimal > end-to-end path. > > As always, your feedback and suggestions are always welcome. > > Br, Dan. > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From ylee@huawei.com Wed May 20 15:52:51 2009 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 61B223A6C6C for ; Wed, 20 May 2009 15:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 9rrR+pM9jbXc for ; Wed, 20 May 2009 15:52:45 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 839EB3A6829 for ; Wed, 20 May 2009 15:52:45 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJY003NFSYM89@usaga04-in.huawei.com> for pce@ietf.org; Wed, 20 May 2009 17:54:23 -0500 (CDT) Received: from L73682 ([10.124.12.80]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJY002D8SYLT6@usaga04-in.huawei.com> for pce@ietf.org; Wed, 20 May 2009 17:54:22 -0500 (CDT) Date: Wed, 20 May 2009 17:54:21 -0500 From: Young Lee In-reply-to: To: 'Diego Caviglia' , julien.meuric@orange-ftgroup.com, ccamp@ops.ietf.org Message-id: <000701c9d99d$ea730870$500c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AcnUeDZxicLvrP0+RmaIhm4fmHuk1QDXw7RAAB0ziCAAVGKZgA== References: <7DBAFEC6A76F3E42817DF1EBE64CB02606716A8F@ftrdmel2> Cc: pce@ietf.org Subject: Re: [Pce] Discussions on PCE requirements for GMPLS 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, 20 May 2009 22:52:51 -0000 Hi Julien, Diego and Fatai,=20 I support the idea of merging PCE requirements for GMPLS.=20 I also have a few general requirements from WSON PCEP application in the area of computing same wavelength (labels) for primary and secondary = path computation. Lou indicated that this may be general enough to be general GMPLS requirement that can be applied to TDM timeslots, Ethernet labels = and other labels including wavelength.=20 Another requirement is bi-directional path and its label (wavelength assignment) for each direction. We should have ability to assign the = same label or not in PCEP. I think this can be applied to TDM labels or = others.=20 Regards, Young -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of Diego Caviglia Sent: Tuesday, May 19, 2009 1:37 AM To: julien.meuric@orange-ftgroup.com; ccamp@ops.ietf.org Cc: pce@ietf.org Subject: RE: [Pce] Discussions on PCE requirements for GMPLS Hi Julien, hi all, I think would be a good idea to merge the document and = not scatter all the GMPLS relevant info among several documents. Thanks Diego > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf > Of julien.meuric@orange-ftgroup.com > Sent: luned=EC 18 maggio 2009 19.05 > To: ccamp@ops.ietf.org > Cc: pce@ietf.org > Subject: FW: [Pce] Discussions on PCE requirements for GMPLS >=20 > Hello CCAMP. >=20 > As described by Fatai below, 2 documents are on the table in the PCE = WG to > tackle PCE requirements for GMPLS networks. Any feedback that the = group > may have would be appreciated. >=20 > Thanks, >=20 > Julien >=20 > ________________________________ >=20 > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of > Fatai Zhang >=20 > Hi PCEers >=20 > We have a draft (draft-zhang-pce-reqs-for-tdm-00.txt) in the process. = This > draft describes some requirements for applying Path Computation = Element > (PCE) in Time-Division Multiplexing (TDM) networks. >=20 > I think GMPLS-based TDM networks can be regarded as sub-set of GMPLS > networks (for example, GMPLS-based SDH networks), so the requirements > described in this draft (PCE for TDM) are sub-set of the requirments = for > PCE applied in GMPLS networks. >=20 > Therefore, It seems that there may be something overlapped with = another > draft (draft-ietf-pce-gmpls-aps-req-00.txt), but there is no = discription > on these requirements in draft-ietf-pce-gmpls-aps-req-00.txt. >=20 > In addition, I think it is not a good solution to keep PCE = requirements > for GMPLS in a few separate documents, so I think it is natural to > incorporate the requirements into draft-ietf-pce-gmpls-aps-req-00.txt. >=20 > Any comments or suggestions are welcome and helpful. >=20 >=20 >=20 > Thanks >=20 > Fatai >=20 > Advanced Technology Department > Wireline Networking Business Unit > Huawei Technologies Co., LTD. > Huawei Base, Bantian, Longgang, > Shenzhen 518129 P.R.China > Tel: +86-755-28972912 > Fax: +86-755-28972935 >=20 From julien.meuric@orange-ftgroup.com Mon May 25 00:56:37 2009 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 045F93A6841 for ; Mon, 25 May 2009 00:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.516 X-Spam-Level: X-Spam-Status: No, score=-0.516 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_50=0.001, HELO_EQ_FR=0.35] 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 zYHf27E26dzm for ; Mon, 25 May 2009 00:56:31 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 2C1243A69C2 for ; Mon, 25 May 2009 00:56:30 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.192.128.41]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 May 2009 09:58:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 May 2009 09:58:09 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02606754625@ftrdmel2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Discussions on PCE requirements for GMPLS Thread-Index: AcndDotR4FrSqgjoQj+z/9K1oznR8g== From: To: X-OriginalArrivalTime: 25 May 2009 07:58:10.0527 (UTC) FILETIME=[8C063EF0:01C9DD0E] Subject: [Pce] FW: Discussions on PCE requirements for GMPLS 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: Mon, 25 May 2009 07:56:37 -0000 Hi. It seems that Tomohiro's comment has only reached CCAMP. Julien -----Original Message----- From: Tomohiro Otani [mailto:tm-otani@kddi.com]=20 Hi, The point is that our draft is now the WG document and tries to summarize the general GMPLS requirements. In that sense, if another contribution suggests something be updated in the WG document,=20 we should relfect it in a next version. I think that within WG, there should be a single requirement-draft about one topics and the next step is not to merge but to update. Regards, Tomo <000701c9d99d$ea730870$500c7c0a@china.huawei.com> ?? "RE: [Pce] Discussions on PCE requirements for GMPLS" ????? "Young Lee "????????: Hi Julien, Diego and Fatai,=20 I support the idea of merging PCE requirements for GMPLS.=20 I also have a few general requirements from WSON PCEP application in the area of computing same wavelength (labels) for primary and secondary = path computation. Lou indicated that this may be general enough to be general GMPLS requirement that can be applied to TDM timeslots, Ethernet labels = and other labels including wavelength.=20 Another requirement is bi-directional path and its label (wavelength assignment) for each direction. We should have ability to assign the = same label or not in PCEP. I think this can be applied to TDM labels or = others.=20 Regards, Young -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of Diego Caviglia Sent: Tuesday, May 19, 2009 1:37 AM To: julien.meuric@orange-ftgroup.com; ccamp@ops.ietf.org Cc: pce@ietf.org Subject: RE: [Pce] Discussions on PCE requirements for GMPLS Hi Julien, hi all, I think would be a good idea to merge the document and = not scatter all the GMPLS relevant info among several documents. Thanks Diego > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf > Of julien.meuric@orange-ftgroup.com > Sent: luned?18 maggio 2009 19.05 > To: ccamp@ops.ietf.org > Cc: pce@ietf.org > Subject: FW: [Pce] Discussions on PCE requirements for GMPLS >=20 > Hello CCAMP. >=20 > As described by Fatai below, 2 documents are on the table in the PCE = WG to > tackle PCE requirements for GMPLS networks. Any feedback that the = group > may have would be appreciated. >=20 > Thanks, >=20 > Julien >=20 > ________________________________ >=20 > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of > Fatai Zhang >=20 > Hi PCEers >=20 > We have a draft (draft-zhang-pce-reqs-for-tdm-00.txt) in the process. = This > draft describes some requirements for applying Path Computation = Element > (PCE) in Time-Division Multiplexing (TDM) networks. >=20 > I think GMPLS-based TDM networks can be regarded as sub-set of GMPLS > networks (for example, GMPLS-based SDH networks), so the requirements > described in this draft (PCE for TDM) are sub-set of the requirments = for > PCE applied in GMPLS networks. >=20 > Therefore, It seems that there may be something overlapped with = another > draft (draft-ietf-pce-gmpls-aps-req-00.txt), but there is no = discription > on these requirements in draft-ietf-pce-gmpls-aps-req-00.txt. >=20 > In addition, I think it is not a good solution to keep PCE = requirements > for GMPLS in a few separate documents, so I think it is natural to > incorporate the requirements into draft-ietf-pce-gmpls-aps-req-00.txt. >=20 > Any comments or suggestions are welcome and helpful. >=20 >=20 >=20 > Thanks >=20 > Fatai >=20 > Advanced Technology Department > Wireline Networking Business Unit > Huawei Technologies Co., LTD. > Huawei Base, Bantian, Longgang, > Shenzhen 518129 P.R.China > Tel: +86-755-28972912 > Fax: +86-755-28972935 >=20