From root@core3.amsl.com Fri Dec 4 05:00:02 2009 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 11C303A68ED; Fri, 4 Dec 2009 05:00:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091204130002.11C303A68ED@core3.amsl.com> Date: Fri, 4 Dec 2009 05:00:02 -0800 (PST) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-p2mp-req-04.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 13:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : PCC-PCE Communication Requirements for Point to Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE) Author(s) : S. Yasukawa, A. Farrel Filename : draft-ietf-pce-p2mp-req-04.txt Pages : 11 Date : 2009-12-04 The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs). The use of PCE in MPLS networks is already established, and since P2MP TE LSP routes are sometimes complex to compute, it is likely that PCE will be used for P2MP LSPs. Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in "Path Computation Element (PCE) Communication Protocol Generic Requirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements for point-to-multipoint MPLS/GMPLS traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-p2mp-req-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-p2mp-req-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-04045244.I-D@ietf.org> --NextPart-- From adrian@olddog.co.uk Fri Dec 4 05:31:36 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 E967B28C0E8 for ; Fri, 4 Dec 2009 05:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.655 X-Spam-Level: X-Spam-Status: No, score=-1.655 tagged_above=-999 required=5 tests=[AWL=0.943, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXuyCcuuLFGQ for ; Fri, 4 Dec 2009 05:31:34 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id C82C128C0E6 for ; Fri, 4 Dec 2009 05:31:33 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id nB4DV5VP015404; Fri, 4 Dec 2009 13:31:06 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id nB4DV0LX015359; Fri, 4 Dec 2009 13:31:02 GMT Message-ID: From: "Adrian Farrel" To: References: <20091204130002.11C303A68ED@core3.amsl.com> Date: Fri, 4 Dec 2009 13:30:53 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: Seisho Yasukawa Subject: Re: [Pce] I-D Action:draft-ietf-pce-p2mp-req-04.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 13:31:36 -0000 Hi PCE, This update is to change the use of "compacted tree" to "compressed tree" to be consistent with RFC 4875. No other change. As mentioned for the -03 version, the authors now believe that this document is complete and would be happy to see it last called whenever that fits into the WG schedule. Thanks, Adrian ----- Original Message ----- From: To: Cc: Sent: Friday, December 04, 2009 1:00 PM Subject: [Pce] I-D Action:draft-ietf-pce-p2mp-req-04.txt >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Path Computation Element Working Group of > the IETF. > > Title : PCC-PCE Communication Requirements for Point to > Multipoint Multiprotocol Label Switching Traffic > Engineering (MPLS-TE) > Author(s) : S. Yasukawa, A. Farrel > Filename : draft-ietf-pce-p2mp-req-04.txt > Pages : 11 > Date : 2009-12-04 > > The Path Computation Element (PCE) provides path computation > functions in support of traffic engineering in Multi-Protocol Label > Switching (MPLS) and Generalized MPLS (GMPLS) networks. > > Extensions to the MPLS and GMPLS signaling and routing protocols have > been made in support of point-to-multipoint (P2MP) Traffic Engineered > (TE) Label Switched Paths (LSPs). The use of PCE in MPLS networks is > already established, and since P2MP TE LSP routes are sometimes > complex to compute, it is likely that PCE will be used for P2MP LSPs. > > Generic requirements for a communication protocol between Path > Computation Clients (PCCs) and PCEs are presented in "Path > Computation Element (PCE) Communication Protocol Generic > Requirements". This document complements the generic requirements and > presents a detailed set of PCC-PCE communication protocol > requirements for point-to-multipoint MPLS/GMPLS traffic engineering. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-p2mp-req-04.txt From jvasseur@cisco.com Mon Dec 7 11:08: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 8A3553A68CB for ; Mon, 7 Dec 2009 11:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.394 X-Spam-Level: X-Spam-Status: No, score=-5.394 tagged_above=-999 required=5 tests=[AWL=-2.796, 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 N6v1Nm6TDxi6 for ; Mon, 7 Dec 2009 11:08:11 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 652AC3A6817 for ; Mon, 7 Dec 2009 11:08:11 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYAAJvhHEuQ/uCWiWdsb2JhbACbUQEBAQoLERMGqA+WKIQzBA X-IronPort-AV: E=Sophos;i="4.47,356,1257120000"; d="scan'208,217";a="777646" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 07 Dec 2009 18:41:50 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nB7J80P7008514 for ; Mon, 7 Dec 2009 19:08:00 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 20:08:00 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 20:07:59 +0100 Message-Id: From: JP Vasseur To: pce@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-21-585321547 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 7 Dec 2009 20:07:59 +0100 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 07 Dec 2009 19:08:00.0028 (UTC) FILETIME=[97CC6DC0:01CA7770] Subject: [Pce] WG Last Call on I-D Action:draft-ietf-pce-p2mp-req-04.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 19:08:12 -0000 --Apple-Mail-21-585321547 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear WG, Although the discussion on this ID has been relatively moderate, the document has been stable for a while and discussed at several WG meetings. This starts a 2-week WG Last Call on I-D Action:draft-ietf-pce-p2mp- req-04.txt. Please send your comment to the authors and copy the list by Dec 15, noon ET. Thanks. JP and Julien. --Apple-Mail-21-585321547 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Dear WG,

Although the discussion on this ID has been relatively moderate, the document has been stable for a while and discussed at several WG meetings. 

This starts a 2-week WG Last Call on I-D Action:draft-ietf-pce-p2mp-req-04.txt.

Please send your comment to the authors and copy the list by Dec 15, noon ET.

Thanks.

JP and Julien.
--Apple-Mail-21-585321547-- From jvasseur@cisco.com Mon Dec 7 11:16:33 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 91D913A692F for ; Mon, 7 Dec 2009 11:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.287 X-Spam-Level: X-Spam-Status: No, score=-5.287 tagged_above=-999 required=5 tests=[AWL=-2.688, 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 wrb23OcrsyHj for ; Mon, 7 Dec 2009 11:16:31 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id B7E773A690F for ; Mon, 7 Dec 2009 11:16:30 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYAAMfiHEuQ/uCWiWdsb2JhbACbUQEBAQoLERMGqAqWKIQzBA X-IronPort-AV: E=Sophos;i="4.47,356,1257120000"; d="scan'208";a="777922" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 07 Dec 2009 18:50:10 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nB7JGJ7C009529 for ; Mon, 7 Dec 2009 19:16:19 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 20:16:19 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 20:16:19 +0100 Message-Id: From: JP Vasseur To: pce@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 7 Dec 2009 20:16:18 +0100 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 07 Dec 2009 19:16:19.0371 (UTC) FILETIME=[C16E1FB0:01CA7771] Subject: [Pce] Implementation of draft-ietf-pce-pcep-svec-list-03.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 19:16:33 -0000 Dear WG, Before requesting the publication of draft-ietf-pce-pcep-svec- list-03.txt, we would appreciate any feed-back on existing implementations ? Many Thanks. JP. From zhang.fei3@zte.com.cn Mon Dec 7 18:42:24 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 286E228B56A for ; Mon, 7 Dec 2009 18:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.538 X-Spam-Level: X-Spam-Status: No, score=-100.538 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001, 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 7QQ2g42SUMsK for ; Mon, 7 Dec 2009 18:42:23 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id B52663A6970 for ; Mon, 7 Dec 2009 18:42:22 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111641441414862; Tue, 8 Dec 2009 10:11:57 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.100] with StormMail ESMTP id 83949.3523444265; Tue, 8 Dec 2009 10:41:09 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id nB82gBmb067926; Tue, 8 Dec 2009 10:42:11 +0800 (CST) (envelope-from zhang.fei3@zte.com.cn) To: ylee@huawei.com, gregb@grotto-networking.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: zhang.fei3@zte.com.cn Date: Tue, 8 Dec 2009 10:42:06 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-12-08 10:42:07, Serialize complete at 2009-12-08 10:42:07 Content-Type: multipart/alternative; boundary="=_alternative 000F537C48257686_=" X-MAIL: mse1.zte.com.cn nB82gBmb067926 Cc: pce@ietf.org Subject: [Pce] some question about draft-lee-pce-wson-signal-compatibility-00.txt :) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 02:42:24 -0000 This is a multipart message in MIME format. --=_alternative 000F537C48257686_= Content-Type: text/plain; charset="US-ASCII" Hi Dr.Lee and Dr. Bernstein, you specifiy two flags in the Modulation Type List sub-TLV, that is S and I, in draft-lee-pce-wson-signal-compatibility-00.txt, see section 3.1.2. When PCC requests a path, according to the "I" flag, there are two scenarios: I=1, indicates that PCC requests a path for the input signal, I=0, indicates that PCC requests a path for the output signal See the picture below. +-+-+-+ Input signal + PCC + Output signal +-+-+-+ I think there is a little different from OSPF-TE flooding, which needs to flood the input and output modulation type. But for the PCE architecture, PCC should not request a path for the output signal. So maybe you can clarify this in the document. Another question, PCE returns the Regeneration Point TLV to PCC, see section 3.2.3, why? I think the PCC just needs to know every hop's input and output parameters, and that is enough. It should not care whether or not the LSP passes through a regeneration point. The last one, GPID Type Sub-TLV should be a general requirement in PCEP, not just limited to WSON compatibility, right? B.R. :) Fei --=_alternative 000F537C48257686_= Content-Type: text/html; charset="US-ASCII"
Hi Dr.Lee and Dr. Bernstein,

you  specifiy two flags in the Modulation Type List sub-TLV, that is S and I, in draft-lee-pce-wson-signal-compatibility-00.txt, see section 3.1.2.

When PCC requests a path, according to the "I" flag, there are two scenarios:
 I=1, indicates that PCC requests a path for the input signal,
 I=0, indicates that PCC requests a path for the output signal

 See the picture below.

                            +-+-+-+
               Input signal + PCC + Output signal                        
                            +-+-+-+
                                                       
I think there is a little different from OSPF-TE flooding, which needs to flood the input and output
modulation type. But for the PCE architecture, PCC should not request a path for the output signal. So maybe you can clarify this in the document.
                                                       
Another question, PCE returns the Regeneration Point TLV to PCC, see section 3.2.3, why?
I think the PCC just needs to know every hop's input and output parameters, and that is enough.
It should not care whether or not the LSP passes through a regeneration point.

The last one,  GPID Type Sub-TLV should be a general requirement in PCEP, not just limited to WSON compatibility, right?

B.R.

:)

Fei --=_alternative 000F537C48257686_=-- From zhang.fei3@zte.com.cn Mon Dec 7 23:16:00 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 1888A3A6920 for ; Mon, 7 Dec 2009 23:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.188 X-Spam-Level: X-Spam-Status: No, score=-101.188 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 nieA4AzeoIjX for ; Mon, 7 Dec 2009 23:15:58 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id C0B803A67F8 for ; Mon, 7 Dec 2009 23:15:41 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 111641441414862; Tue, 8 Dec 2009 14:45:07 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.99] with StormMail ESMTP id 89005.3523444265; Tue, 8 Dec 2009 15:14:19 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id nB87EwNe010102; Tue, 8 Dec 2009 15:14:58 +0800 (CST) (envelope-from zhang.fei3@zte.com.cn) To: ylee@huawei.com, gregb@grotto-networking.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: zhang.fei3@zte.com.cn Date: Tue, 8 Dec 2009 15:14:47 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-12-08 15:14:49, Serialize complete at 2009-12-08 15:14:49 Content-Type: multipart/alternative; boundary="=_alternative 00284A3A48257686_=" X-MAIL: mse2.zte.com.cn nB87EwNe010102 Cc: pce@ietf.org Subject: [Pce] PCEP Requirements for WSON Impairments 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, 08 Dec 2009 07:16:00 -0000 This is a multipart message in MIME format. --=_alternative 00284A3A48257686_= Content-Type: text/plain; charset="US-ASCII" Hi Dr.Lee and Dr. Bernstein You update a new RWA path request/reply in your presentation about draft-lee-pce-wson-impairments-00.txt The PCReq Message MAY include some specific measure of optical signal quality to which all feasible paths should conform: The BER limit Q factor OSNR + Margin PMD I think the BER limit is composed of required BER value (determined by signal's modulation type )+ OSNR+PMD+margin, and Q factor is equivalent to BER. So the four items listed above should not be in parallel, what do you think? Another thing needs to be taken care is that the BER value, is it pre-FEC/ after-FEC or should be both included? If the LSP across some opaque NE (e.g. regenerator/OEO/wavelength converter ), then BER value of LSP consists of several segments. And in this situation, the reply message should return the maximum BER value or every segment's? B.R. :) Fei --=_alternative 00284A3A48257686_= Content-Type: text/html; charset="US-ASCII"
Hi Dr.Lee and Dr. Bernstein

You update a new RWA path request/reply in your presentation about draft-lee-pce-wson-impairments-00.txt

The PCReq Message MAY include some specific measure of optical signal quality to which all feasible paths should conform:
        The BER limit
        Q factor
        OSNR + Margin
        PMD

I think the BER limit is composed of required BER value (determined by signal's modulation type )+ OSNR+PMD+margin, and Q factor is equivalent to BER.
So the four items listed above should not be in parallel, what do you think?

Another  thing needs to be taken care is that the BER value,  is it pre-FEC/ after-FEC or should be both included?

If the LSP across some opaque NE (e.g. regenerator/OEO/wavelength converter ), then BER value of LSP consists of several segments. And in this situation,
the reply message should return the maximum BER value or every segment's?

B.R.

:)

Fei --=_alternative 00284A3A48257686_=-- From dhruvd@huawei.com Tue Dec 8 02:25: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 D6BBC28C0EF for ; Tue, 8 Dec 2009 02:25:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 yNIk1G5YQD5h for ; Tue, 8 Dec 2009 02:25:12 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 267433A6983 for ; Tue, 8 Dec 2009 02:25:12 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUB00CPUWTKBI@szxga03-in.huawei.com> for pce@ietf.org; Tue, 08 Dec 2009 18:22:32 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUB001WBWTKV7@szxga03-in.huawei.com> for pce@ietf.org; Tue, 08 Dec 2009 18:22:32 +0800 (CST) Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUB0010RWTI5J@szxml06-in.huawei.com> for pce@ietf.org; Tue, 08 Dec 2009 18:22:32 +0800 (CST) Date: Tue, 08 Dec 2009 15:52:30 +0530 From: dhruv dhody In-reply-to: To: yasukawa.seisho@lab.ntt.co.jp, adrian@olddog.co.uk, qzhao@huawei.com, fabien.verhaeghe@gmail.com, takeda.tomonori@lab.ntt.co.jp, zali@cisco.com, julien.meuric@orange-ftgroup.com Message-id: <002601ca77f0$59f56030$1f01120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_11REgwUCYnaT0/C4lYJOaw)" Thread-index: Acp3cKMb53uPvjwNSlii3S+HrsD72QAfga4g References: Cc: pce@ietf.org Subject: Re: [Pce] WG Last Call on I-D Action:draft-ietf-pce-p2mp-req-04.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 10:25:16 -0000 This is a multi-part message in MIME format. --Boundary_(ID_11REgwUCYnaT0/C4lYJOaw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear Authors, I found one inconsistency between the draft "draft-ietf-pce-p2mp-req-04" and "draft-ietf-pce-pcep-p2mp-extensions-05". draft-ietf-pce-p2mp-req-04 [Section 2.1.6] R7: By default, the path returned by the PCE SHOULD use the compressed format. The request from the PCC MAY allow the PCC to express a preference for receiving a compressed or non-compressed P2MP path in the response. draft-ietf-pce-pcep-p2mp-extensions-05 [Section 3.3.1 o E ( ERO-compression bit - 1 bit): 0: This indicates that the route is not in the compressed format. 1: This indicates that the route is in the compressed format. The default value 0 should be compressed; bit set 1 should be not-compressed. Kindly resolve and confirm the final decision. Thanks & Regards, Dhruv Dhody Huawei Technologies Co.,Ltd. Bangalore, India **************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _____ From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Tuesday, December 08, 2009 12:38 AM To: pce@ietf.org Subject: [Pce] WG Last Call on I-D Action:draft-ietf-pce-p2mp-req-04.txt Dear WG, Although the discussion on this ID has been relatively moderate, the document has been stable for a while and discussed at several WG meetings. This starts a 2-week WG Last Call on I-D Action:draft-ietf-pce-p2mp-req-04.txt. Please send your comment to the authors and copy the list by Dec 15, noon ET. Thanks. JP and Julien. --Boundary_(ID_11REgwUCYnaT0/C4lYJOaw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Dear Authors,

 

I found one inconsistency between the draft = “draft-ietf-pce-p2mp-req-04” and “draft-ietf-pce-pcep-p2mp-extensions-05”. =  

 

draft-ietf-pce-p2mp-req-04 = [Section 2.1.6]

   R7:  By default, the path = returned by the PCE SHOULD use the

        compressed format.

 

        = The request from the PCC MAY allow the PCC to express = a

        preference for receiving a compressed or non-compressed = P2MP

        = path in the response.

 

draft-ietf-pce-pcep-p2mp-extensions-05= [Section 3.3.1

   o  E ( ERO-compression bit = - 1 bit):

 

         0: This indicates that the route is not in the = compressed

         format.

 

         1: This indicates that the route is in the compressed = format.

 

The default value 0 should be compressed; bit set 1 = should be not-compressed.

 

Kindly resolve and confirm the final decision. =

 

 

Thanks & Regards,

Dhruv = Dhody

Huawei Technologies = Co.,Ltd.

Bangalore, India<= /p>

 

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

From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of JP Vasseur
Sent: Tuesday, December = 08, 2009 12:38 AM
To: pce@ietf.org
Subject: [Pce] WG Last = Call on I-D Action:draft-ietf-pce-p2mp-req-04.txt

 

Dear WG,

 

Although the discussion on this ID has been relatively moderate, = the document has been stable for a while and discussed at several WG meetings. 

 

This starts a 2-week WG Last Call on I-D = Action:draft-ietf-pce-p2mp-req-04.txt.

 

Please send your comment to the authors and copy the list by Dec = 15, noon ET.

 

Thanks.

 

JP and Julien.

--Boundary_(ID_11REgwUCYnaT0/C4lYJOaw)-- From dk@danielking.net Tue Dec 8 02:51:19 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 C40A23A69DD for ; Tue, 8 Dec 2009 02:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 7F3-FFUuFjlm for ; Tue, 8 Dec 2009 02:51:17 -0800 (PST) Received: from mail-ew0-f209.google.com (mail-ew0-f209.google.com [209.85.219.209]) by core3.amsl.com (Postfix) with ESMTP id 81E603A69D8 for ; Tue, 8 Dec 2009 02:51:17 -0800 (PST) Received: by ewy1 with SMTP id 1so2546205ewy.28 for ; Tue, 08 Dec 2009 02:51:02 -0800 (PST) Received: by 10.216.89.202 with SMTP id c52mr2746089wef.215.1260269461658; Tue, 08 Dec 2009 02:51:01 -0800 (PST) Received: from Firefly (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by mx.google.com with ESMTPS id 28sm4195503eye.1.2009.12.08.02.50.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 08 Dec 2009 02:51:00 -0800 (PST) Sender: Daniel King From: "Daniel King" To: "'dhruv dhody'" , , , , , , , References: <002601ca77f0$59f56030$1f01120a@china.huawei.com> In-Reply-To: <002601ca77f0$59f56030$1f01120a@china.huawei.com> Date: Tue, 8 Dec 2009 10:50:52 -0000 Message-ID: <009901ca77f4$50dc4960$f294dc20$@co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acp3cKMb53uPvjwNSlii3S+HrsD72QAfga4gAAFAVUA= Content-Language: en-us Cc: pce@ietf.org Subject: Re: [Pce] draft-ietf-pce-pcep-p2mp-extensions (was WG Last Call on I-D Action:draft-ietf-pce-p2mp-req-04.txt) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 10:51:19 -0000 Hello Dhruv, Thank you for your comment. I agree that the bit should be swapped so = the PCE sends a compressed format by default. We will update the text accordingly during our next revision.=20 Br, Dan.=20 From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of = dhruv dhody Sent: Tuesday, December 08, 2009 10:22 AM To: yasukawa.seisho@lab.ntt.co.jp; adrian@olddog.co.uk; = qzhao@huawei.com; fabien.verhaeghe@gmail.com; takeda.tomonori@lab.ntt.co.jp; = zali@cisco.com; julien.meuric@orange-ftgroup.com Cc: pce@ietf.org Subject: Re: [Pce] WG Last Call on I-D = Action:draft-ietf-pce-p2mp-req-04.txt Dear Authors,=20 I found one inconsistency between the draft = =93draft-ietf-pce-p2mp-req-04=94 and =93draft-ietf-pce-pcep-p2mp-extensions-05=94. =A0 draft-ietf-pce-p2mp-req-04 [Section 2.1.6] =A0=A0 R7:=A0 By default, the path returned by the PCE SHOULD use the =A0=A0=A0=A0=A0=A0=A0 compressed format. =A0=A0=A0=A0=A0=A0=A0 The request from the PCC MAY allow the PCC to = express a =A0=A0=A0=A0=A0=A0=A0 preference for receiving a compressed or = non-compressed P2MP =A0=A0=A0=A0=A0=A0=A0 path in the response. draft-ietf-pce-pcep-p2mp-extensions-05 [Section 3.3.1 =A0=A0 o=A0 E ( ERO-compression bit - 1 bit): =A0=A0=A0=A0=A0=A0=A0=A0 0: This indicates that the route is not in the = compressed =A0=A0=A0=A0=A0=A0=A0=A0 format. =A0=A0=A0=A0=A0=A0=A0=A0 1: This indicates that the route is in the = compressed format. The default value 0 should be compressed; bit set 1 should be not-compressed.=20 Kindly resolve and confirm the final decision.=20 Thanks & Regards, Dhruv Dhody Huawei Technologies Co.,Ltd. Bangalore, India *************************************************************************= *** *********** This e-mail and attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way = (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the = sender by phone or email immediately and delete it! ________________________________________ From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Tuesday, December 08, 2009 12:38 AM To: pce@ietf.org Subject: [Pce] WG Last Call on I-D Action:draft-ietf-pce-p2mp-req-04.txt Dear WG, Although the discussion on this ID has been relatively moderate, the document has been stable for a while and discussed at several WG = meetings.=A0 This starts a 2-week WG Last Call on=A0I-D Action:draft-ietf-pce-p2mp-req-04.txt. Please send your comment to the authors and copy the list by Dec 15, = noon ET. Thanks. JP and Julien. From i-nishioka@cb.jp.nec.com Tue Dec 8 17:33: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 9B5673A6A0F for ; Tue, 8 Dec 2009 17:33:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.399 X-Spam-Level: * X-Spam-Status: No, score=1.399 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsKlyZfxF7Q7 for ; Tue, 8 Dec 2009 17:33:27 -0800 (PST) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by core3.amsl.com (Postfix) with ESMTP id AC7B53A6A8A for ; Tue, 8 Dec 2009 17:33:27 -0800 (PST) Received: from mailgate3.nec.co.jp ([10.7.69.161]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id nB91X9PU013554; Wed, 9 Dec 2009 10:33:09 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id nB91X9b02962; Wed, 9 Dec 2009 10:33:09 +0900 (JST) Received: from mail03.kamome.nec.co.jp (mail03.kamome.nec.co.jp [10.25.43.7]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id nB91VlZX004753; Wed, 9 Dec 2009 10:33:08 +0900 (JST) Received: from shoin.jp.nec.com ([10.26.220.3] [10.26.220.3]) by mail02.kamome.nec.co.jp with ESMTP id BT-MMP-269309; Wed, 9 Dec 2009 10:32:50 +0900 Received: from C08AUG00201 ([10.56.131.165] [10.56.131.165]) by mail.jp.nec.com with ESMTP; Wed, 9 Dec 2009 10:32:50 +0900 From: "Itaru Nishioka" To: "'JP Vasseur'" , References: In-Reply-To: Date: Wed, 9 Dec 2009 10:32:50 +0900 Organization: NEC Message-ID: <9EBF7158FAA44A918FC4BC9BBCBDB4C1@nsl.ad.nec.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acp3ccVhhHMNXQ2JRW+uG5V5IFQ86gA/BFWw X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: Re: [Pce] Implementation of draft-ietf-pce-pcep-svec-list-03.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: i-nishioka@cb.jp.nec.com List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 01:33:28 -0000 Hi Feedback as one of co-author. We have an implementation of draft-ietf-pce-pcep-svec- list-03, and it is working with existing PCEP [RFC5440], BRPC [RFC5441], Path-key[RF5520] and so forth. Thanks, Itaru > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On > Behalf Of JP Vasseur > Sent: Tuesday, December 08, 2009 4:16 AM > To: pce@ietf.org > Subject: [Pce] Implementation of draft-ietf-pce-pcep-svec-list-03.txt > > Dear WG, > > Before requesting the publication of > draft-ietf-pce-pcep-svec- list-03.txt, we would appreciate > any feed-back on existing implementations ? > > Many Thanks. > > JP. > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From jvasseur@cisco.com Wed Dec 9 03:58:05 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 C01103A6898 for ; Wed, 9 Dec 2009 03:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.095 X-Spam-Level: X-Spam-Status: No, score=-5.095 tagged_above=-999 required=5 tests=[AWL=-2.496, 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 O0tkPu0I5nUK for ; Wed, 9 Dec 2009 03:58:05 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 90F2A3A67CC for ; Wed, 9 Dec 2009 03:58:04 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMAANMfH0uQ/uCWiWdsb2JhbACbYgEBAQoLERMGonKXHYQsBA X-IronPort-AV: E=Sophos;i="4.47,368,1257120000"; d="scan'208";a="917102" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 09 Dec 2009 11:31:35 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nB9BvqYg021061; Wed, 9 Dec 2009 11:57:52 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 12:57:52 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 12:57:52 +0100 Message-Id: From: JP Vasseur To: In-Reply-To: <9EBF7158FAA44A918FC4BC9BBCBDB4C1@nsl.ad.nec.co.jp> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 9 Dec 2009 12:57:50 +0100 References: <9EBF7158FAA44A918FC4BC9BBCBDB4C1@nsl.ad.nec.co.jp> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 09 Dec 2009 11:57:52.0457 (UTC) FILETIME=[D61D1B90:01CA78C6] Cc: pce@ietf.org Subject: Re: [Pce] Implementation of draft-ietf-pce-pcep-svec-list-03.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 11:58:05 -0000 Thanks Itaru, this is a useful information. JP, On Dec 9, 2009, at 2:32 AM, Itaru Nishioka wrote: > Hi > > Feedback as one of co-author. > > We have an implementation of draft-ietf-pce-pcep-svec- list-03, and > it is working with existing PCEP > [RFC5440], BRPC [RFC5441], Path-key[RF5520] and so forth. > > Thanks, > Itaru > >> -----Original Message----- >> From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On >> Behalf Of JP Vasseur >> Sent: Tuesday, December 08, 2009 4:16 AM >> To: pce@ietf.org >> Subject: [Pce] Implementation of draft-ietf-pce-pcep-svec-list-03.txt >> >> Dear WG, >> >> Before requesting the publication of >> draft-ietf-pce-pcep-svec- list-03.txt, we would appreciate >> any feed-back on existing implementations ? >> >> Many Thanks. >> >> JP. >> _______________________________________________ >> Pce mailing list >> Pce@ietf.org >> https://www.ietf.org/mailman/listinfo/pce > From ylee@huawei.com Mon Dec 14 09:28: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 13E373A68F1 for ; Mon, 14 Dec 2009 09:28:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.12 X-Spam-Level: X-Spam-Status: No, score=-0.12 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] 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 3HeV1-p5VMy8 for ; Mon, 14 Dec 2009 09:28:19 -0800 (PST) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 1D6B63A67E2 for ; Mon, 14 Dec 2009 09:28:19 -0800 (PST) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUN00L42KITMQ@usaga03-in.huawei.com> for pce@ietf.org; Mon, 14 Dec 2009 11:28:06 -0600 (CST) Received: from L73682 (h-74-3-11-130.phlapafg.static.covad.net [74.3.11.130]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUN000NSKIPNT@usaga03-in.huawei.com> for pce@ietf.org; Mon, 14 Dec 2009 11:28:05 -0600 (CST) Date: Mon, 14 Dec 2009 11:28:03 -0600 From: Young Lee In-reply-to: To: zhang.fei3@zte.com.cn, gregb@grotto-networking.com Message-id: <000b01ca7ce2$cae663b0$4063a8c0@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_a3dmOSAOJwLy/tqN24qZlA)" Thread-index: Acp31jzJygoiusM5SsSoeGKSyzMplgFCi8XA References: Cc: pce@ietf.org Subject: Re: [Pce] PCEP Requirements for WSON Impairments 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, 14 Dec 2009 17:28:20 -0000 This is a multi-part message in MIME format. --Boundary_(ID_a3dmOSAOJwLy/tqN24qZlA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Fei, Please see my comments below. Thanks. Young _____ From: zhang.fei3@zte.com.cn [mailto:zhang.fei3@zte.com.cn] Sent: Tuesday, December 08, 2009 1:15 AM To: ylee@huawei.com; gregb@grotto-networking.com Cc: pce@ietf.org Subject: PCEP Requirements for WSON Impairments Hi Dr.Lee and Dr. Bernstein You update a new RWA path request/reply in your presentation about draft-lee-pce-wson-impairments-00.txt The PCReq Message MAY include some specific measure of optical signal quality to which all feasible paths should conform: The BER limit Q factor OSNR + Margin PMD I think the BER limit is composed of required BER value (determined by signal's modulation type )+ OSNR+PMD+margin, and Q factor is equivalent to BER. So the four items listed above should not be in parallel, what do you think? Young>> Here the list does not mean to be mutually exclusive. There are cases where the path needs to be optimized in a particular impairment data such as OSNR or PMD, etc. This requirement comes from a carrier. Another thing needs to be taken care is that the BER value, is it pre-FEC/ after-FEC or should be both included? Young>> Per-FEC is assumed here. If the LSP across some opaque NE (e.g. regenerator/OEO/wavelength converter ), then BER value of LSP consists of several segments. And in this situation, the reply message should return the maximum BER value or every segment's? Young>> The end-to-end BER value is sufficient, I think. B.R. :) Fei --Boundary_(ID_a3dmOSAOJwLy/tqN24qZlA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi = Fei,

 

Please see my comments below. = Thanks.

 

Young

 

From: zhang.fei3@zte.com.cn [mailto:zhang.fei3@zte.com.cn]
Sent: Tuesday, December = 08, 2009 1:15 AM
To: ylee@huawei.com; gregb@grotto-networking.com
Cc: pce@ietf.org
Subject: PCEP = Requirements for WSON Impairments

 


Hi Dr.Lee and Dr. Bernstein

You update a new RWA path request/reply in your presentation about draft-lee-pce-wson-impairments-00.txt

The PCReq Message MAY include some specific measure of optical signal = quality to which all feasible paths should conform:
        The BER limit
        Q factor
        OSNR + Margin
        PMD

I think the BER limit is composed of required BER value (determined by = signal's modulation type )+ OSNR+PMD+margin, and Q factor is equivalent to = BER.
So the four items listed above should not be in parallel, what do you = think?

 

Young>> Here the list does = not mean to be mutually exclusive. There are cases where the path needs to be = optimized in a particular impairment data such as OSNR or PMD, etc. This = requirement comes from a carrier.



Another  thing needs to be taken care is that the BER value,  is it pre-FEC/ after-FEC or should be both included? =

 

Young>> Per-FEC is assumed = here.



If the LSP across some opaque NE (e.g. regenerator/OEO/wavelength converter ), then BER value of LSP consists of several segments. And in = this situation,
the reply message should return the maximum BER value or every = segment's?

 

Young>>  The end-to-end = BER value is sufficient, I think.



B.R.

:)

Fei=

--Boundary_(ID_a3dmOSAOJwLy/tqN24qZlA)-- From qzhao@huawei.com Mon Dec 14 13:15:57 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 6D4D73A68C4 for ; Mon, 14 Dec 2009 13:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 ZoW5KeXkN2xp for ; Mon, 14 Dec 2009 13:15:56 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id B64C03A6875 for ; Mon, 14 Dec 2009 13:15:56 -0800 (PST) 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 <0KUN00579V27VR@usaga02-in.huawei.com> for pce@ietf.org; Mon, 14 Dec 2009 13:15:43 -0800 (PST) Received: from Z73671a ([10.192.21.57]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUN00DZQV264E@usaga02-in.huawei.com> for pce@ietf.org; Mon, 14 Dec 2009 13:15:42 -0800 (PST) Date: Mon, 14 Dec 2009 16:15:42 -0500 From: Quintin Zhao To: pce@ietf.org Message-id: <000101ca7d02$98346e60$3915c00a@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=US-ASCII Content-transfer-encoding: 7BIT Thread-index: Acp8+qKwkutDiABZRTC5FlPE49IX+QAA049wAAB346AAAJqsIA== Subject: [Pce] Inter-domain-p2mp-procedures 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, 14 Dec 2009 21:15:57 -0000 Hello PCE'rs, I would like to follow-up on some discussions from our PCE WG session last month. Specifically regarding Dajiang's failure and recomputation observations on our draft. We are very interested to hear comments regarding the need for computing secondary paths in the event of failure. Currently our thinking is to recompute the sub-tree based in the domain where the failure has occurred. In this case we would not need to perform a recalculation of the entire tree. We could also recompute the entire tree, and avoid the failed areas, as long as the TED has the updated topology. Realistically one might have a backup core tree pre-computed so you can switch over in the event of failure. There are also other considerations. Would a partial recomputation provide a "worse" SPT or MCT tree, or would a full tree recomputation provide a "better" SPT or MCT? I can think of scenarios for both a partial and full recomputation, so perhaps we need to implement both but allow the PCC to decide when to issue a partial or full recomputation based on some criterion. Thanks, Quintin From dhruvd@huawei.com Mon Dec 14 22:39:49 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 F37C03A6856 for ; Mon, 14 Dec 2009 22:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.736 X-Spam-Level: X-Spam-Status: No, score=0.736 tagged_above=-999 required=5 tests=[AWL=-1.230, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RDNS_NONE=0.1] 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 EZ51AWUXD-IX for ; Mon, 14 Dec 2009 22:39:47 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id B693B3A6810 for ; Mon, 14 Dec 2009 22:39:31 -0800 (PST) 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 <0KUO0097LL4UMU@szxga04-in.huawei.com> for pce@ietf.org; Tue, 15 Dec 2009 14:38:54 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUO003XYL4U5G@szxga04-in.huawei.com> for pce@ietf.org; Tue, 15 Dec 2009 14:38:54 +0800 (CST) Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUO00HVDL4SC8@szxml06-in.huawei.com> for pce@ietf.org; Tue, 15 Dec 2009 14:38:53 +0800 (CST) Date: Tue, 15 Dec 2009 12:08:52 +0530 From: dhruv dhody In-reply-to: <000101ca7d02$98346e60$3915c00a@china.huawei.com> To: 'Quintin Zhao' , pce@ietf.org Message-id: <000a01ca7d51$44bb50b0$1f01120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_+IlsHvx77OB/cDSjruTiYg)" Thread-index: Acp8+qKwkutDiABZRTC5FlPE49IX+QAA049wAAB346AAAJqsIAATgpEg References: <000101ca7d02$98346e60$3915c00a@china.huawei.com> Subject: Re: [Pce] Inter-domain-p2mp-procedures 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, 15 Dec 2009 06:39:49 -0000 This is a multi-part message in MIME format. --Boundary_(ID_+IlsHvx77OB/cDSjruTiYg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hello Quintin, I have following comments - For Pre-computed Backup Core Tree 1) Is the Backup tree, the next Best core-tree [MCT or SPT]? 2) How path-diverse should the Backup tree be? We may need to support all re-optimization scenarios similar to P2MP Intra-domain cases [explained in draft-ietf-pce-pcep-p2mp-extensions]. Thanks & Regards, Dhruv Huawei Technologies Co.,Ltd. Bangalore, India **************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Quintin Zhao Sent: Tuesday, December 15, 2009 2:46 AM To: pce@ietf.org Subject: [Pce] Inter-domain-p2mp-procedures Hello PCE'rs, I would like to follow-up on some discussions from our PCE WG session last month. Specifically regarding Dajiang's failure and recomputation observations on our draft. We are very interested to hear comments regarding the need for computing secondary paths in the event of failure. Currently our thinking is to recompute the sub-tree based in the domain where the failure has occurred. In this case we would not need to perform a recalculation of the entire tree. We could also recompute the entire tree, and avoid the failed areas, as long as the TED has the updated topology. Realistically one might have a backup core tree pre-computed so you can switch over in the event of failure. There are also other considerations. Would a partial recomputation provide a "worse" SPT or MCT tree, or would a full tree recomputation provide a "better" SPT or MCT? I can think of scenarios for both a partial and full recomputation, so perhaps we need to implement both but allow the PCC to decide when to issue a partial or full recomputation based on some criterion. Thanks, Quintin _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --Boundary_(ID_+IlsHvx77OB/cDSjruTiYg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hello Quintin,

 

I have following comments -

 

For Pre-computed Backup Core Tree

1) Is the Backup tree, the next Best core-tree [MCT or SPT]?

2) How path-diverse should the Backup tree be?

 

We may need to support all re-optimization scenarios similar to P2MP Intra-domain cases [explained in draft-ietf-pce-pcep-p2mp-extensions].

 

Thanks & Regards,

Dhruv

Huawei Technologies Co.,Ltd.

Bangalore, India

 

***************************************************************************************

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

 

 

-----Original Message-----
From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Quintin Zhao
Sent: Tuesday, December 15, 2009 2:46 AM
To: pce@ietf.org
Subject: [Pce] Inter-domain-p2mp-procedures

 

 

Hello PCE'rs,

 

I would like to follow-up on some discussions from our PCE WG session last

month. Specifically regarding Dajiang's failure and recomputation

observations on our draft. We are very interested to hear comments regarding

the need for computing secondary paths in the event of failure. Currently

our thinking is to recompute the sub-tree based in the domain where the

failure has occurred. In this case we would not need to perform a

recalculation of the entire tree. We could also recompute the entire tree,

and avoid the failed areas, as long as the TED has the updated topology.

Realistically one might have a backup core tree pre-computed so you can

switch over in the event of failure. There are also other considerations.

Would a partial recomputation provide a "worse" SPT or MCT tree, or would a

full tree recomputation provide a "better" SPT or MCT? I can think of

scenarios for both a partial and full recomputation, so perhaps we need to

implement both but allow the PCC to decide when to issue a partial or full

recomputation based on some criterion.  

 

Thanks,

 

Quintin

 

_______________________________________________

Pce mailing list

Pce@ietf.org

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

--Boundary_(ID_+IlsHvx77OB/cDSjruTiYg)-- From daniel@olddog.co.uk Tue Dec 15 08:52:14 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 D3B293A6A99 for ; Tue, 15 Dec 2009 08:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.229 X-Spam-Level: X-Spam-Status: No, score=-1.229 tagged_above=-999 required=5 tests=[AWL=1.369, 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 NiHSZRtY4TNn for ; Tue, 15 Dec 2009 08:52:09 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.193.159]) by core3.amsl.com (Postfix) with ESMTP id 7C2A03A6AAE for ; Tue, 15 Dec 2009 08:52:08 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id nBFGpasM018797; Tue, 15 Dec 2009 16:51:42 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id nBFGpZLg018789; Tue, 15 Dec 2009 16:51:36 GMT From: "Daniel King" To: "'JP Vasseur'" , References: In-Reply-To: Date: Tue, 15 Dec 2009 16:51:37 -0000 Message-ID: <018101ca7da6$de1435b0$9a3ca110$@co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0182_01CA7DA6.DE1435B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-index: Acp3cJv0zpupeVx4QUu7EXVk0uA7HAGNfudA Content-Language: en-gb Subject: Re: [Pce] WG Last Call on I-D Action:draft-ietf-pce-p2mp-req-04.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 16:52:14 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0182_01CA7DA6.DE1435B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi JP, All, As a co-editor of the P2MP Solutions (draft-ietf-pce-pcep-p2mp-extensions-05) I would like to state that the authors of the P2MP Requirements (draft-ietf-pce-p2mp-req-04) added all the additional requirements that we identified during the development of the P2MP solutions document. So I believe that the P2MP Requirements document is in fairly good shape. We do however have one outstanding issue regarding the solutions document. I do not believe this directly impacts the P2MP Requirements document itself, but it's certainly worth discussing the issue on the list. The P2MP Requirements draft mentions the requirement for reoptimization of P2MP TE LSPs: >> 2.1.10. Reoptimization of P2MP TE LSPs R11: Reoptimization MUST be supported for P2MP TE LSPs as described for P2P LSPs in [RFC4657]. << There is a further request in this section that states "that a P2MP Path Computation Request SHOULD contain a parameter that allows the PCC to express a cost-benefit reoptimization threshold for the whole LSP as well as per destination". This seems like a sensible request. After all, why switch to a new path if the reoptimization request returns a path that's no better, or even worse, than the existing path? We support Objective Functions [RFC5541] in the P2MP Solutions document, and our solutions allows a path to be computed using a Shortest Path Tree (SPT) or Minimum Cost Tree (MCT), these will be processed according to the rules defined in RFC5541, but we do not currently have a "reoptimization threshold" function. Some of the authors of the P2MP Solution draft think the reoptimization threshold function is relevant to both P2P and P2MP, and threshold solution should be applicable to both P2P and P2MP. Therefore the current P2MP Solutions would state that this requirement will be resolved in a future document. We would really like to hear comments or suggestions regarding the threshold reoptimization function. Both from the perspective of a future solution that supports both P2P and P2MP, and/or this feature should be specifically part of the existing P2MP Solutions draft. Br, Dan/P2MP Solutions Authors. From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of JP Vasseur Sent: 07 December 2009 19:08 To: pce@ietf.org Subject: [Pce] WG Last Call on I-D Action:draft-ietf-pce-p2mp-req-04.txt Dear WG, Although the discussion on this ID has been relatively moderate, the document has been stable for a while and discussed at several WG meetings. This starts a 2-week WG Last Call on I-D Action:draft-ietf-pce-p2mp-req-04.txt. Please send your comment to the authors and copy the list by Dec 15, noon ET. Thanks. JP and Julien. ------=_NextPart_000_0182_01CA7DA6.DE1435B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi JP, All,

 

As a co-editor of the P2MP Solutions = (draft-ietf-pce-pcep-p2mp-extensions-05) I would like to state that the authors of the P2MP Requirements = (draft-ietf-pce-p2mp-req-04) added all the additional requirements that we identified during the = development of the P2MP solutions document. So I believe that the P2MP Requirements document is in fairly good shape.

 

We do however have one outstanding issue = regarding the solutions document. I do not believe this directly impacts the P2MP Requirements document itself, but it’s certainly worth discussing = the issue on the list. The P2MP Requirements draft mentions the requirement for = reoptimization of P2MP TE LSPs:

 

>> 

2.1.10. Reoptimization of P2MP TE = LSPs

 

R11: Reoptimization MUST be supported for P2MP = TE LSPs as described for P2P LSPs in [RFC4657].

<< 

 

There is a further request in this section that = states "that a P2MP Path Computation Request SHOULD contain a parameter that allows = the PCC to express a cost-benefit reoptimization threshold for the whole LSP as = well as per destination". This seems like a sensible request. After all, = why switch to a new path if the reoptimization request returns a path that's = no better, or even worse, than the existing path?  

 

We support Objective Functions [RFC5541] in the = P2MP Solutions document, and our solutions allows a path to be computed using a = Shortest Path Tree (SPT) or Minimum Cost Tree (MCT), these will be processed according = to the rules defined in RFC5541, but we do not currently have a = "reoptimization threshold" function. Some of the authors of the P2MP Solution draft = think the reoptimization threshold function is relevant to both P2P and P2MP, = and threshold solution should be applicable to both P2P and P2MP. Therefore the = current P2MP Solutions would state that this requirement will be resolved in a future document.

 

We would really like to hear comments or = suggestions regarding the threshold reoptimization function. Both from the = perspective of a future solution that supports both P2P and P2MP, and/or this feature = should be specifically part of the existing P2MP Solutions draft.

 

Br, Dan/P2MP Solutions Authors. =    

 

 

From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of JP Vasseur
Sent: 07 December 2009 19:08
To: pce@ietf.org
Subject: [Pce] WG Last Call on I-D = Action:draft-ietf-pce-p2mp-req-04.txt

 

Dear WG,

 

Although the discussion on this ID has been = relatively moderate, the document has been stable for a while and discussed at = several WG meetings. 

 

This starts a 2-week WG Last Call on I-D Action:draft-ietf-pce-p2mp-req-04.txt.

 

Please send your comment to the authors and copy = the list by Dec 15, noon ET.

 

Thanks.

 

JP and Julien.

------=_NextPart_000_0182_01CA7DA6.DE1435B0-- From root@core3.amsl.com Tue Dec 15 11:45:02 2009 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 28DF03A6AF3; Tue, 15 Dec 2009 11:45:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091215194502.28DF03A6AF3@core3.amsl.com> Date: Tue, 15 Dec 2009 11:45:02 -0800 (PST) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-monitoring-06.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 19:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : A set of monitoring tools for Path Computation Element based Architecture Author(s) : J. Vasseur, et al. Filename : draft-ietf-pce-monitoring-06.txt Pages : 25 Date : 2009-12-15 A Path Computation Element (PCE) based architecture has been specified for the computation of Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks in the context of single or multiple domains (where a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems). Path Computation Clients (PCCs) send computation requests to PCEs, and these may forward the requests to and cooperate with other PCEs forming a "path computation chain". In PCE-based environments, it is thus critical to monitor the state of the path computation chain for troubleshooting and performance monitoring purposes: liveness of each element (PCE) involved in the PCE chain, detection of potential resource contention states and statistics in term of path computation times are examples of such metrics of interest. This document specifies procedures and extensions to the Path Computation Element Protocol (PCEP) in order to gather such information. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 17, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-monitoring-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-monitoring-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-15113939.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Wed Dec 16 08:00:02 2009 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2CC9E3A67E6; Wed, 16 Dec 2009 08:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091216160002.2CC9E3A67E6@core3.amsl.com> Date: Wed, 16 Dec 2009 08:00:02 -0800 (PST) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-monitoring-07.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 16:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : A set of monitoring tools for Path Computation Element based Architecture Author(s) : J. Vasseur, et al. Filename : draft-ietf-pce-monitoring-07.txt Pages : 25 Date : 2009-12-16 A Path Computation Element (PCE) based architecture has been specified for the computation of Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks in the context of single or multiple domains (where a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems). Path Computation Clients (PCCs) send computation requests to PCEs, and these may forward the requests to and cooperate with other PCEs forming a "path computation chain". In PCE-based environments, it is thus critical to monitor the state of the path computation chain for troubleshooting and performance monitoring purposes: liveness of each element (PCE) involved in the PCE chain, detection of potential resource contention states and statistics in term of path computation times are examples of such metrics of interest. This document specifies procedures and extensions to the Path Computation Element Protocol (PCEP) in order to gather such information. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 19, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-monitoring-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-monitoring-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-16075251.I-D@ietf.org> --NextPart-- From jvasseur@cisco.com Wed Dec 16 08:09:56 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 373623A69F3 for ; Wed, 16 Dec 2009 08:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, 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 HvoFJ-qWJ1yJ for ; Wed, 16 Dec 2009 08:09:55 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 186633A69D4 for ; Wed, 16 Dec 2009 08:09:54 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: None : None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswEALSUKEtAZnwN/2dsb2JhbACCKL0klwqEKwQ X-IronPort-AV: E=Sophos;i="4.47,406,1257120000"; d="scan'208,217";a="74644930" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 16 Dec 2009 16:09:36 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nBGG9ax3018419 for ; Wed, 16 Dec 2009 16:09:36 GMT Received: from xfe-rtp-212.amer.cisco.com ([64.102.31.100]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 11:09:36 -0500 Received: from [192.168.50.29] ([10.55.92.224]) by xfe-rtp-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 11:09:35 -0500 Message-Id: From: JP Vasseur To: pce@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-359--795267245 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 16 Dec 2009 17:09:34 +0100 References: <20091216160002.2CC9E3A67E6@core3.amsl.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 16 Dec 2009 16:09:35.0619 (UTC) FILETIME=[2930FD30:01CA7E6A] Subject: [Pce] Fwd: I-D Action:draft-ietf-pce-monitoring-07.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 16:09:56 -0000 --Apple-Mail-359--795267245 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear all, This new revision is purely editorial and addresses comments received during IETF LC. Thanks. JP. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: December 16, 2009 5:00:02 PM CEST > To: i-d-announce@ietf.org > Cc: pce@ietf.org > Subject: [Pce] I-D Action:draft-ietf-pce-monitoring-07.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Path Computation Element Working > Group of the IETF. > > > Title : A set of monitoring tools for Path Computation > Element based Architecture > Author(s) : J. Vasseur, et al. > Filename : draft-ietf-pce-monitoring-07.txt > Pages : 25 > Date : 2009-12-16 > > A Path Computation Element (PCE) based architecture has been > specified for the computation of Traffic Engineering (TE) Label > Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and > Generalized MPLS (GMPLS) networks in the context of single or > multiple domains (where a domain refers to a collection of network > elements within a common sphere of address management or path > computational responsibility such as IGP areas and Autonomous > Systems). Path Computation Clients (PCCs) send computation requests > to PCEs, and these may forward the requests to and cooperate with > other PCEs forming a "path computation chain". > > In PCE-based environments, it is thus critical to monitor the state > of the path computation chain for troubleshooting and performance > monitoring purposes: liveness of each element (PCE) involved in the > PCE chain, detection of potential resource contention states and > statistics in term of path computation times are examples of such > metrics of interest. This document specifies procedures and > extensions to the Path Computation Element Protocol (PCEP) in order > to gather such information. > > Status of this Memo > > This Internet-Draft is submitted to IETF in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on June 19, 2010. > > Copyright Notice > > Copyright (c) 2009 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the BSD License. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-monitoring-07.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce --Apple-Mail-359--795267245 Content-Type: multipart/mixed; boundary=Apple-Mail-360--795267245 --Apple-Mail-360--795267245 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear = all,

This new revision is purely editorial and = addresses comments received during IETF = LC.

Thanks.

JP.
=
Begin forwarded message:

Date: December 16, 2009 5:00:02 PM = CEST
To: i-d-announce@ietf.org
Subject: = [Pce] I-D = Action:draft-ietf-pce-monitoring-07.txt

A New = Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the Path Computation = Element Working Group of the IETF.


Title =           : A set of = monitoring tools for Path Computation Element based = Architecture
= Author(s)       : J. Vasseur, et = al.
= Filename        : = draft-ietf-pce-monitoring-07.txt
Pages =           : = 25
= Date =            : = 2009-12-16

A Path Computation Element (PCE) based architecture = has been
specified for the computation of Traffic Engineering (TE) = Label
Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) = and
Generalized MPLS (GMPLS) networks in the context of single = or
multiple domains (where a domain refers to a collection of = network
elements within a common sphere of address management or = path
computational responsibility such as IGP areas and = Autonomous
Systems).  Path Computation Clients (PCCs) send = computation requests
to PCEs, and these may forward the requests to = and cooperate with
other PCEs forming a "path computation = chain".

In PCE-based environments, it is thus critical to monitor = the state
of the path computation chain for troubleshooting and = performance
monitoring purposes: liveness of each element (PCE) = involved in the
PCE chain, detection of potential resource contention = states and
statistics in term of path computation times are examples = of such
metrics of interest.  This document specifies procedures = and
extensions to the Path Computation Element Protocol (PCEP) in = order
to gather such information.

Status of this = Memo

This Internet-Draft is submitted to IETF in full conformance = with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are = working documents of the Internet Engineering
Task Force (IETF), its = areas, and its working groups.  Note that
other groups may also = distribute working documents as = Internet-
Drafts.

Internet-Drafts are draft documents valid = for a maximum of six months
and may be updated, replaced, or = obsoleted by other documents at any
time.  It is inappropriate = to use Internet-Drafts as reference
material or to cite them other = than as "work in progress."

The list of current Internet-Drafts = can be accessed at
http://www.ietf.org/ie= tf/1id-abstracts.txt.

The list of Internet-Draft Shadow = Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on June 19, = 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and = the persons identified as the
document authors.  All rights = reserved.

This document is subject to BCP 78 and the IETF Trust's = Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/lice= nse-info) in effect on the date of
publication of this document. =  Please review these documents
carefully, as they describe your = rights and restrictions with respect
to this document.  Code = Components extracted from this document must
include Simplified BSD = License text as described in Section 4.e of
the Trust Legal = Provisions and are provided without warranty as
described in the BSD = License.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pce-monitoring-07.txt

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

Below is the data = which will enable a MIME compliant mail reader
implementation to = automatically retrieve the ASCII version of = the
Internet-Draft.
= --Apple-Mail-360--795267245 Content-Disposition: attachment; filename=mime-attachment Content-Type: message/external-body; x-unix-mode=0666; name="mime-attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2009-12-16075251.I-D@ietf.org>

--Apple-Mail-360--795267245 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

--Apple-Mail-360--795267245-- --Apple-Mail-359--795267245-- From vishwas.ietf@gmail.com Wed Dec 16 12:12:29 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 494DC3A68B6 for ; Wed, 16 Dec 2009 12:12:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 Ud6C6QU6Uvwh for ; Wed, 16 Dec 2009 12:12:24 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id B73163A69C0 for ; Wed, 16 Dec 2009 12:12:23 -0800 (PST) Received: by yxe30 with SMTP id 30so1486784yxe.29 for ; Wed, 16 Dec 2009 12:12:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=jz9/1lXoV9eKD3YgCAlGEf80PGT6zchyQWIKECOSxBI=; b=STx/NKzOD5NBCyWj/pKB0UFc2AOr2t2XnA9mgErCLZ2eZEW85r+kxqPsrCy5d6Pfr7 V/DtksUxMmfTCZR3dJ1OVdaDqNnP4xj9vixtX7yNfA7ympg3vVKvu0iDG05o5Ejt5Xhv 2kRsr6qqV86iY0UdChBqyLtYkpIq4CLTI1rxM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=gmjbcOnc2LXycmtM+sl26COLinzpXkX/WOmgeKaexQ6BrfmM3w8xFXMU2dOty6b5eo L3cgxXODadZzC1NazSptAsqPwYT2kli8r8YfiYNbHDtJ6avvFfYcou+bBqu7y0im2AiK 1TkHfFJ2jCVw9QYmKe8UfeMLFMPFfXQlVZukk= MIME-Version: 1.0 Received: by 10.150.27.6 with SMTP id a6mr2503700yba.74.1260994326843; Wed, 16 Dec 2009 12:12:06 -0800 (PST) Date: Wed, 16 Dec 2009 12:12:06 -0800 Message-ID: <77ead0ec0912161212x63f2494cw65d818e523b1cbe8@mail.gmail.com> From: Vishwas Manral To: pce@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Pce] draft-zhao-pce-pcep-inter-domain-p2mp-procedures 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, 16 Dec 2009 20:12:29 -0000 Hi Quintin, I was seeing the "PCE Sequence Object", why can a sequence not have either IPv4 and IPv6 identifiers for PCE in the same object? We shouls allow a sequence of PCE's with IPv4 or IPv6 addresses. It can easily be done by adding a type field before every time we add he address. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Object-Class | OT |Res|P|I| Object Length (bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address for root PCE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thanks, Vishwas From daniel@olddog.co.uk Wed Dec 16 14:50:07 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 1C58B3A6840 for ; Wed, 16 Dec 2009 14:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.572 X-Spam-Level: X-Spam-Status: No, score=-1.572 tagged_above=-999 required=5 tests=[AWL=1.027, 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 4HZ5V+uwPX-Z for ; Wed, 16 Dec 2009 14:50:06 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 223DC3A6A9F for ; Wed, 16 Dec 2009 14:50:02 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id nBGMnXNh026399; Wed, 16 Dec 2009 22:49:33 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id nBGMnUHR026384; Wed, 16 Dec 2009 22:49:32 GMT From: "Daniel King" To: "'Vishwas Manral'" References: <77ead0ec0912161212x63f2494cw65d818e523b1cbe8@mail.gmail.com> In-Reply-To: <77ead0ec0912161212x63f2494cw65d818e523b1cbe8@mail.gmail.com> Date: Wed, 16 Dec 2009 22:49:31 -0000 Message-ID: <003501ca7ea2$09eed810$1dcc8830$@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: Acp+jBQGf/YslqOfQaushpaHxKMqCgAESRFA Content-Language: en-gb Cc: pce@ietf.org Subject: Re: [Pce] draft-zhao-pce-pcep-inter-domain-p2mp-procedures 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, 16 Dec 2009 22:50:07 -0000 Hi Vishwas, Good point. This is mentioned in http://tools.ietf.org/html/draft-ietf-pce-monitoring-05. Specifically, where a sequence of PCE IDs is required: a. put each PCE ID in a separate object b. allow a sequence of objects So, if we have to have a sequence of PCEs it would be better to define the sequences to go in the messages. I completely agree that we should be able to freely mix IPv4 and IPv6 on an end-to-end path. The addresses will not be mixed within a domain, but successive domains might use different address formats. I'd think that the message format we planned to have: ... Should now be: ( ...) ... Br, Dan. -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Vishwas Manral Sent: 16 December 2009 20:12 To: pce@ietf.org Subject: [Pce] draft-zhao-pce-pcep-inter-domain-p2mp-procedures Hi Quintin, I was seeing the "PCE Sequence Object", why can a sequence not have either IPv4 and IPv6 identifiers for PCE in the same object? We shouls allow a sequence of PCE's with IPv4 or IPv6 addresses. It can easily be done by adding a type field before every time we add he address. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Object-Class | OT |Res|P|I| Object Length (bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address for root PCE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thanks, Vishwas _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From dhruvd@huawei.com Wed Dec 16 22:10: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 9B5A03A6B22 for ; Wed, 16 Dec 2009 22:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.121 X-Spam-Level: X-Spam-Status: No, score=0.121 tagged_above=-999 required=5 tests=[AWL=0.615, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 7mrTQD9JtJ37 for ; Wed, 16 Dec 2009 22:10:43 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 68D643A6B15 for ; Wed, 16 Dec 2009 22:10:31 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUS001N994A0L@szxga03-in.huawei.com> for pce@ietf.org; Thu, 17 Dec 2009 14:09:46 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUS001LK94AJS@szxga03-in.huawei.com> for pce@ietf.org; Thu, 17 Dec 2009 14:09:46 +0800 (CST) Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUS002R4945CJ@szxml06-in.huawei.com> for pce@ietf.org; Thu, 17 Dec 2009 14:09:46 +0800 (CST) Date: Thu, 17 Dec 2009 11:39:40 +0530 From: dhruv dhody To: qzhao@huawei.com, daniel@olddog.co.uk, tsaad@cisco.com Message-id: <001c01ca7edf$874d5740$1f01120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_usGP3QlRoEbpGuPaYtLHmA)" Thread-index: Acp+34Ta0pk+EypgS5eVJgYt43IDLw== Cc: pce@ietf.org Subject: [Pce] Domain Sequence 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, 17 Dec 2009 06:10:51 -0000 This is a multi-part message in MIME format. --Boundary_(ID_usGP3QlRoEbpGuPaYtLHmA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear Authors, In "draft-king-pce-hierarchy-fwk-02", section 5.6.2 [Hierarchical PCE End-to-End Path Computation Procedure]: Domain paths are denoted as (S-BN11-BN21-D2-BN23-BN31-D, S-BN11-BN21-D2-BN24-BN32-D, and S-BN13-BN41-D4-BN42-BN33-D). i.e. Parent PCE must know about the BNs and there interconnections. What is the need for this? Why can't the domain sequence be represented just by a sequence of domains i.e. [S-D2-D and S-D4-D]? BRPC procedure can take domain sequence as input and figure out the appropriate BNs and there interconnection while applying the VSPT algorithm. Also note that, Child PCE can use the PCED-discovery [NEIG-PCE-DOMAIN Sub-TLV] to specify the neighbor PCE-Domain(s) to Parent PCE, without mentioning any BNs link-interconnection information. Background: P2P inter-domain as in RFC 5441 [Section 4.1] The PCC MAY indicate the sequence of domains to be traversed using the Include Route Object (IRO) defined in [RFC5440] so that it is available to all PCEs. Here domains sequence can be carried as SUB-OBJECTS [defined in RFC 3209], Type = 32 for AS; a new Type = 5 for Area-id can be defined. There is no need to carry BNs. That decision should be taken while applying the BRPC procedures based on all the constraints. This works when domain sequence is administratively predetermined or discovered. P2MP inter-domain as in "draft-zhao-pce-pcep-inter-domain-p2mp-procedures-02" [Section 8.2.2] The PCE Sequence Object is added to the existing PCE protocol. Instead of PCE sequence, domain sequence works much better. - Existing IRO and sub-objects can be used, similar to P2P BRPC (backward compatible) - PCE(i) for a particular domain (i) is selected dynamically by PCE(i-1) based on the domain information in the domain-sequence. For PCE Sequence, PCC/PCE in domain (1), should know about all the PCEs before the start of procedure, and cannot be changed on the fly. In summary: 1) Domain sequence should carry only the domain-information and not the BNs. [H-PCE] 2) Domain sequence can be used instead of PCE-Sequence [P2MP-BRPC] Kindly give any comments/suggestions. Regards, Dhruv Dhody Huawei Technologies Co.,Ltd. Bangalore, India **************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! --Boundary_(ID_usGP3QlRoEbpGuPaYtLHmA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Dear Authors,

 

In “draft-king-pce-hierarchy-fwk-02”, = section 5.6.2 [Hierarchical PCE End-to-End Path Computation Procedure]: =

Domain paths are denoted as = (S-BN11-BN21-D2-BN23-BN31-D, S-BN11-BN21-D2-BN24-BN32-D, and S-BN13-BN41-D4-BN42-BN33-D). =

i.e. Parent PCE must know about the BNs and there interconnections.

 

What is the need for this? =

 

Why can’t the domain sequence be represented = just by a sequence of domains i.e. [S-D2-D and S-D4-D]? =

BRPC procedure can take domain sequence as input = and figure out the appropriate BNs and there interconnection while applying = the VSPT algorithm.

Also note that, Child PCE can use the = PCED-discovery [NEIG-PCE-DOMAIN Sub-TLV] to specify the neighbor PCE-Domain(s) to = Parent PCE, without mentioning any BNs link-interconnection information. =  

 

Background:

P2P inter-domain as in RFC 5441 [Section = 4.1]

The PCC MAY indicate the sequence of domains =
to be traversed using the Include =
Route Object (IRO) defined in [RFC5440] so =
that it is available to all PCEs. =

 
Here domains sequence can =
be carried as SUB-OBJECTS [defined in RFC 3209], Type =3D 32 for AS; a =
new Type =3D 5 for Area-id can be defined. There is no need to carry =
BNs. That decision should be taken while applying the BRPC procedures =
based on all the constraints. 
This works when domain =
sequence is administratively predetermined or discovered. =

 
P2MP inter-domain as in =
“draft-zhao-pce-pcep-inter-domain-p2mp-procedures-02” =
[Section 8.2.2]

The PCE Sequence Object is added = to the existing PCE protocol.

 

Instead of PCE sequence, domain sequence works much better.

-         Existing IRO and = sub-objects can be used, similar to P2P BRPC (backward = compatible)

-         PCE(i) for a particular = domain (i) is selected dynamically by PCE(i-1) based on the domain information in = the domain-sequence. For PCE Sequence, PCC/PCE in domain (1), should know = about all the PCEs before the start of procedure, and cannot be changed on the = fly.

 

In summary:

1) Domain sequence should carry only the domain-information and not the BNs. [H-PCE]

2) Domain sequence can be used instead of = PCE-Sequence [P2MP-BRPC]

 

Kindly give any comments/suggestions. =

 

Regards,

Dhruv Dhody

Huawei Technologies = Co.,Ltd.

Bangalore, India<= /p>

 

 

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

 

--Boundary_(ID_usGP3QlRoEbpGuPaYtLHmA)-- From jvasseur@cisco.com Thu Dec 17 11:39:56 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 42D6328C150 for ; Thu, 17 Dec 2009 11:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.699 X-Spam-Level: X-Spam-Status: No, score=-6.699 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 LH654t2h-wW7 for ; Thu, 17 Dec 2009 11:39:55 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 017ED28C129 for ; Thu, 17 Dec 2009 11:39:55 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswEADYXKkurRN+K/2dsb2JhbACCKL0Ply2ELQQ X-IronPort-AV: E=Sophos;i="4.47,414,1257120000"; d="scan'208,217";a="64322124" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 17 Dec 2009 19:39:40 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nBHJdd0v019584; Thu, 17 Dec 2009 19:39:39 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 20:39:38 +0100 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 20:39:37 +0100 Message-Id: <28361E9D-2D43-42B8-BD82-8B6169A487C8@cisco.com> From: JP Vasseur To: Daniel King In-Reply-To: <018101ca7da6$de1435b0$9a3ca110$@co.uk> Content-Type: multipart/alternative; boundary=Apple-Mail-9--701198742 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 17 Dec 2009 19:17:22 +0100 References: <018101ca7da6$de1435b0$9a3ca110$@co.uk> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 17 Dec 2009 19:39:38.0253 (UTC) FILETIME=[AB5C13D0:01CA7F50] Cc: pce@ietf.org Subject: Re: [Pce] WG Last Call on I-D Action:draft-ietf-pce-p2mp-req-04.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 19:39:56 -0000 --Apple-Mail-9--701198742 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Dan, On Dec 15, 2009, at 5:51 PM, Daniel King wrote: > Hi JP, All, > > As a co-editor of the P2MP Solutions (draft-ietf-pce-pcep-p2mp-=20 > extensions-05) I would like to state that the authors of the P2MP =20 > Requirements (draft-ietf-pce-p2mp-req-04) added all the additional =20 > requirements that we identified during the development of the P2MP =20 > solutions document. So I believe that the P2MP Requirements document =20= > is in fairly good shape. > > We do however have one outstanding issue regarding the solutions =20 > document. I do not believe this directly impacts the P2MP =20 > Requirements document itself, but it=92s certainly worth discussing =20= > the issue on the list. The P2MP Requirements draft mentions the =20 > requirement for reoptimization of P2MP TE LSPs: > > >> > 2.1.10. Reoptimization of P2MP TE LSPs > > R11: Reoptimization MUST be supported for P2MP TE LSPs as described =20= > for P2P LSPs in [RFC4657]. > << > > There is a further request in this section that states "that a P2MP =20= > Path Computation Request SHOULD contain a parameter that allows the =20= > PCC to express a cost-benefit reoptimization threshold for the whole =20= > LSP as well as per destination". This seems like a sensible request. =20= > After all, why switch to a new path if the reoptimization request =20 > returns a path that's no better, or even worse, than the existing =20 > path? > > We support Objective Functions [RFC5541] in the P2MP Solutions =20 > document, and our solutions allows a path to be computed using a =20 > Shortest Path Tree (SPT) or Minimum Cost Tree (MCT), these will be =20 > processed according to the rules defined in RFC5541, but we do not =20 > currently have a "reoptimization threshold" function. Some of the =20 > authors of the P2MP Solution draft think the reoptimization =20 > threshold function is relevant to both P2P and P2MP, and threshold =20 > solution should be applicable to both P2P and P2MP. Therefore the =20 > current P2MP Solutions would state that this requirement will be =20 > resolved in a future document. > > We would really like to hear comments or suggestions regarding the =20 > threshold reoptimization function. Both from the perspective of a =20 > future solution that supports both P2P and P2MP, and/or this feature =20= > should be specifically part of the existing P2MP Solutions draft. Good question and for people having long memories, this was discussed =20= almost 5 years ago (!). I had personally advocated for such a solution =20= so I'm clearly in favor of it and I also believe that the same =20 mechanism should apply to both P2P and P2MP. Of course, there might be =20= a need for specific threshold in light of the OF. For example, if we =20 end up defining an OF for P2MP according which the objective is to =20 minimize the path cost difference between each leaf and the head-end =20 (to guaranty fairness delivery for mcast traffic for example), we may =20= need a P2MP specific threshold. So let's try to make the threshold =20 mechanisms as generic and modular as possible. Back to your question I would suggest to leave it out from the P2MP =20 solution draft and have a separate ID covering both the P2P and P2MP =20 threshold solutions. Thanks. JP. > > Br, Dan/P2MP Solutions Authors. > > > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf =20 > Of JP Vasseur > Sent: 07 December 2009 19:08 > To: pce@ietf.org > Subject: [Pce] WG Last Call on I-D Action:draft-ietf-pce-p2mp-=20 > req-04.txt > > Dear WG, > > Although the discussion on this ID has been relatively moderate, the =20= > document has been stable for a while and discussed at several WG =20 > meetings. > > This starts a 2-week WG Last Call on I-D Action:draft-ietf-pce-p2mp-=20= > req-04.txt. > > Please send your comment to the authors and copy the list by Dec 15, =20= > noon ET. > > Thanks. > > JP and Julien. --Apple-Mail-9--701198742 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi Dan,

On = Dec 15, 2009, at 5:51 PM, Daniel King wrote:

Hi JP, All,
As a co-editor of the P2MP Solutions = (draft-ietf-pce-pcep-p2mp-extensions-05) I would like to state that the = authors of the P2MP Requirements (draft-ietf-pce-p2mp-req-04) added all = the additional requirements that we identified during the development of = the P2MP solutions document. So I believe that the P2MP Requirements = document is in fairly good shape.
We do however have one outstanding issue = regarding the solutions document. I do not believe this directly impacts = the P2MP Requirements document itself, but it=92s certainly worth = discussing the issue on the list. The P2MP Requirements draft mentions = the requirement for reoptimization of P2MP TE LSPs:
>> 
2.1.10. = Reoptimization of P2MP TE LSPs
 
R11: = Reoptimization MUST be supported for P2MP TE LSPs as described for P2P = LSPs in [RFC4657].
<< 
There is a further request in this section that = states "that a P2MP Path Computation Request SHOULD contain a parameter = that allows the PCC to express a cost-benefit reoptimization threshold = for the whole LSP as well as per destination". This seems like a = sensible request. After all, why switch to a new path if the = reoptimization request returns a path that's no better, or even worse, = than the existing path?  
 
We support = Objective Functions [RFC5541] in the P2MP Solutions document, and our = solutions allows a path to be computed using a Shortest Path Tree (SPT) = or Minimum Cost Tree (MCT), these will be processed according to the = rules defined in RFC5541, but we do not currently have a "reoptimization = threshold" function. Some of the authors of the P2MP Solution draft = think the reoptimization threshold function is relevant to both P2P and = P2MP, and threshold solution should be applicable to both P2P and P2MP. = Therefore the current P2MP Solutions would state that this requirement = will be resolved in a future document.
We would really like to hear comments or = suggestions regarding the threshold reoptimization function. Both from = the perspective of a future solution that supports both P2P and P2MP, = and/or this feature should be specifically part of the existing P2MP = Solutions = draft.

Good = question and for people having long memories, this was discussed almost = 5 years ago (!). I had personally advocated for such a solution so I'm = clearly in favor of it and I also believe that the same mechanism should = apply to both P2P and P2MP. Of course, there might be a need for = specific threshold in light of the OF. For example, if we end up = defining an OF for P2MP according which the objective is to minimize the = path cost difference between each leaf and the head-end (to guaranty = fairness delivery for mcast traffic for example), we may need a P2MP = specific threshold. So let's try to make the threshold mechanisms as = generic and modular as possible.

Back to your = question I would suggest to leave it out from the P2MP solution draft = and have a separate ID covering both the P2P and P2MP threshold = solutions.

Thanks.

JP.
 
Br, = Dan/P2MP Solutions Authors.    
From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of JP = Vasseur
Sent: 07 December 2009 = 19:08
To: pce@ietf.org
Subject: [Pce] WG Last Call on I-D = Action:draft-ietf-pce-p2mp-req-04.txt
<= div style=3D"margin-top: 0cm; margin-right: 0cm; margin-bottom: = 0.0001pt; margin-left: 0cm; font-size: 12pt; font-family: 'Times New = Roman', serif; "> 
Dear = WG,
Although the discussion = on this ID has been relatively moderate, the document has been stable = for a while and discussed at several WG = meetings. 
This starts a 2-week WG = Last Call on I-D = Action:draft-ietf-pce-p2mp-req-04.txt.
<= /div>
 
Please send your comment to the authors and copy the list by = Dec 15, noon ET.
JP and = Julien.

= --Apple-Mail-9--701198742-- From jvasseur@cisco.com Thu Dec 17 11:39:57 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 4A15228C158 for ; Thu, 17 Dec 2009 11:39:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.397 X-Spam-Level: X-Spam-Status: No, score=-4.397 tagged_above=-999 required=5 tests=[AWL=-2.398, 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 nJJJHL+AQh7u for ; Thu, 17 Dec 2009 11:39:56 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 037C728C0F5 for ; Thu, 17 Dec 2009 11:39:55 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwAAN8XKkuQ/uCWiWdsb2JhbACbYgEBAQoLERMGoxKXLYQtBA X-IronPort-AV: E=Sophos;i="4.47,414,1257120000"; d="scan'208";a="1437803" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 17 Dec 2009 19:12:45 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nBHJde1L016646; Thu, 17 Dec 2009 19:39:40 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 20:39:40 +0100 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 20:39:39 +0100 Message-Id: <68A4A4A0-0C67-407D-A32E-4CF0D2B81F8D@cisco.com> From: JP Vasseur To: Quintin Zhao In-Reply-To: <000101ca7d02$98346e60$3915c00a@china.huawei.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 17 Dec 2009 19:25:52 +0100 References: <000101ca7d02$98346e60$3915c00a@china.huawei.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 17 Dec 2009 19:39:39.0925 (UTC) FILETIME=[AC5B3450:01CA7F50] Cc: pce@ietf.org Subject: Re: [Pce] Inter-domain-p2mp-procedures 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, 17 Dec 2009 19:39:57 -0000 Hi, Note that this is a fairly well-known issue. The aim of local repair has always been to quickly recover from the failure. The degree of resources guarantees and optimality depends on the amount of resources dedicated to backup, several assumptions with regards to potential simultaneous failures, the algorithms used to pre-compute backup tunnels, etc ... The approach taken by P2P FRR has been to first locally reroute and trigger a head-end reoptimization using a make before break. I do not think that you can draw any conclusion on the potentially level of sub-optimality of performing local reroute as opposed to global reoptimization. It depends on a number of factors. JP. On Dec 14, 2009, at 10:15 PM, Quintin Zhao wrote: > > Hello PCE'rs, > > I would like to follow-up on some discussions from our PCE WG > session last > month. Specifically regarding Dajiang's failure and recomputation > observations on our draft. We are very interested to hear comments > regarding > the need for computing secondary paths in the event of failure. > Currently > our thinking is to recompute the sub-tree based in the domain where > the > failure has occurred. In this case we would not need to perform a > recalculation of the entire tree. We could also recompute the entire > tree, > and avoid the failed areas, as long as the TED has the updated > topology. > Realistically one might have a backup core tree pre-computed so you > can > switch over in the event of failure. There are also other > considerations. > Would a partial recomputation provide a "worse" SPT or MCT tree, or > would a > full tree recomputation provide a "better" SPT or MCT? I can think of > scenarios for both a partial and full recomputation, so perhaps we > need to > implement both but allow the PCC to decide when to issue a partial > or full > recomputation based on some criterion. > > Thanks, > > Quintin > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From qzhao@huawei.com Fri Dec 18 12:41:13 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 2D62A3A69F8 for ; Fri, 18 Dec 2009 12:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 94J7xCAJmtVQ for ; Fri, 18 Dec 2009 12:41:11 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 475B13A679C for ; Fri, 18 Dec 2009 12:41:07 -0800 (PST) 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 <0KUV00CRP843U6@usaga04-in.huawei.com> for pce@ietf.org; Fri, 18 Dec 2009 14:40:51 -0600 (CST) Received: from Z73671a ([10.192.21.57]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUV001GS840KG@usaga04-in.huawei.com> for pce@ietf.org; Fri, 18 Dec 2009 14:40:51 -0600 (CST) Date: Fri, 18 Dec 2009 15:40:48 -0500 From: Quintin Zhao To: dhruvd@huawei.com Message-id: <002101ca8022$6246c910$3915c00a@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_E3zp0uPKajbM+OUTthZPCQ)" Thread-index: AcqAImEa6NFDJOiVSne6l2Kmi0yq+g== Cc: pce@ietf.org Subject: Re: [Pce] Inter-domain-p2mp-procedures 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: Fri, 18 Dec 2009 20:41:13 -0000 This is a multi-part message in MIME format. --Boundary_(ID_E3zp0uPKajbM+OUTthZPCQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dhruv, Thanks for your comments and suggestions. For the pre-computed backup tree, I think that it should be best tree available during the computation time period while satisfying the link/node/path diversity constrains. For the backup tree's Path-diversity, this might be depending on the failures we are trying to protect. If we only want to protect the link failures, then the backup tree may only need the link diversity from the primary tree. For the node failures, then we may need the backup tree which has the node diversity from the primary tree. We also may need the link direction diversity backup tree from the primary backup tree for certain scenarios. We will add a paragraph in the draft to specify all the path diversity level we should support when we compute the backup tree. Yes, the inter-domain p2mp procedure need to support all re-optimization scenarios specified in draft-ietf-pce-pcep-p2mp-extensions in the procedure draft. We will specify this in the new version of the draft. Thanks, Quintin -----Original Message----- From: Quintin Zhao [mailto:qzhao@huawei.com] ------------------------------ Message: 2 Date: Tue, 15 Dec 2009 12:08:52 +0530 From: dhruv dhody Subject: Re: [Pce] Inter-domain-p2mp-procedures To: 'Quintin Zhao' , pce@ietf.org Message-ID: <000a01ca7d51$44bb50b0$1f01120a@china.huawei.com> Content-Type: text/plain; charset="us-ascii" Hello Quintin, I have following comments - For Pre-computed Backup Core Tree 1) Is the Backup tree, the next Best core-tree [MCT or SPT]? 2) How path-diverse should the Backup tree be? We may need to support all re-optimization scenarios similar to P2MP Intra-domain cases [explained in draft-ietf-pce-pcep-p2mp-extensions]. Thanks & Regards, Dhruv Huawei Technologies Co.,Ltd. Bangalore, India **************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! On Dec 14, 2009, at 10:15 PM, Quintin Zhao wrote: > > Hello PCE'rs, > > I would like to follow-up on some discussions from our PCE WG > session last > month. Specifically regarding Dajiang's failure and recomputation > observations on our draft. We are very interested to hear comments > regarding > the need for computing secondary paths in the event of failure. > Currently > our thinking is to recompute the sub-tree based in the domain where > the > failure has occurred. In this case we would not need to perform a > recalculation of the entire tree. We could also recompute the entire > tree, > and avoid the failed areas, as long as the TED has the updated > topology. > Realistically one might have a backup core tree pre-computed so you > can > switch over in the event of failure. There are also other > considerations. > Would a partial recomputation provide a "worse" SPT or MCT tree, or > would a > full tree recomputation provide a "better" SPT or MCT? I can think of > scenarios for both a partial and full recomputation, so perhaps we > need to > implement both but allow the PCC to decide when to issue a partial > or full > recomputation based on some criterion. > > Thanks, > > Quintin > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce --Boundary_(ID_E3zp0uPKajbM+OUTthZPCQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Dhruv,

 

Thanks for your comments and = suggestions.

 

For the pre-computed backup tree, I think that it should be = best tree available during the computation time period while satisfying the link/node/path diversity constrains.

 

For the backup tree's Path-diversity, this might be = depending on the failures we are trying to protect. If we only want to protect the = link failures, then the backup tree may only need the link diversity from the primary tree.  For the node failures, then we may need the backup = tree which has the node diversity from the primary tree. We also may need the = link direction diversity backup tree from the primary backup tree for certain scenarios. We will add a paragraph in the draft to specify all the path diversity level we should support when we compute the backup = tree.

 

Yes, the inter-domain p2mp procedure need to support all re-optimization scenarios specified in = draft-ietf-pce-pcep-p2mp-extensions in the procedure draft. We will specify this in the new version of the = draft.

 

Thanks,

Quintin

 

 

-----Original = Message-----

From: Quintin Zhao = [mailto:qzhao@huawei.com] =

 

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

 

Message: = 2

Date: Tue, 15 Dec 2009 12:08:52 = +0530

From: dhruv = dhody <dhruvd@huawei.com>

Subject: Re: [Pce] = Inter-domain-p2mp-procedures

To: 'Quintin Zhao' <qzhao@huawei.com>, pce@ietf.org

Message-ID: <000a01ca7d51$44bb50b0$1f01120a@china.huawei.com>=

Content-Type: text/plain; = charset=3D"us-ascii"

 

Hello Quintin,

 

 

 

I have following comments -

 

 

 

For Pre-computed Backup Core = Tree

 

1) Is the Backup tree, the next Best core-tree [MCT or = SPT]?

 

2) How path-diverse should the Backup tree be? =

 

 

 

We may need to support all re-optimization scenarios = similar to P2MP

Intra-domain cases [explained in draft-ietf-pce-pcep-p2mp-extensions].

 

 

 

Thanks & Regards,

 

Dhruv

 

Huawei Technologies Co.,Ltd.

 

Bangalore, India

 

 

 

************************************************************= ****************

***********

 

This e-mail and attachments contain confidential = information from HUAWEI,

which is intended only for the person or entity whose = address is listed

above. Any use of the information contained herein in any = way (including,

but not limited to, total or partial disclosure, = reproduction, or

dissemination) by persons other than the intended = recipient's) is

prohibited. If you receive this e-mail in error, please = notify the sender by

phone or email immediately and delete = it!

 

 

 

 

On Dec 14, 2009, at 10:15 PM, Quintin Zhao = wrote:

 

> 

> Hello PCE'rs,

> 

> I would like to follow-up on some discussions from our PCE WG 

> session last

> month. Specifically regarding Dajiang's failure and = recomputation

> observations on our draft. We are very interested to hear comments 

> regarding

> the need for computing secondary paths in the event of failure. 

> Currently

> our thinking is to recompute the sub-tree based in the = domain where 

> the

> failure has occurred. In this case we would not need to = perform a

> recalculation of the entire tree. We could also recompute = the entire 

> tree,

> and avoid the failed areas, as long as the TED has the updated 

> topology.

> Realistically one might have a backup core tree = pre-computed so you 

> can

> switch over in the event of failure. There are also = other 

> considerations.

> Would a partial recomputation provide a "worse" = SPT or MCT tree, or 

> would a

> full tree recomputation provide a "better" SPT or = MCT? I can think of

> scenarios for both a partial and full recomputation, so = perhaps we 

> need to

> implement both but allow the PCC to decide when to issue a partial 

> or full

> recomputation based on some = criterion.

> 

> Thanks,

> 

> Quintin

> 

> = _______________________________________________<= /p>

> Pce mailing list

> Pce@ietf.org

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

 

--Boundary_(ID_E3zp0uPKajbM+OUTthZPCQ)-- From qzhao@huawei.com Fri Dec 18 12:41:54 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 381233A6AC8 for ; Fri, 18 Dec 2009 12:41:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[AWL=0.650, 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 BbQbpsIwxmzC for ; Fri, 18 Dec 2009 12:41:53 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 671553A68DF for ; Fri, 18 Dec 2009 12:41:53 -0800 (PST) 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 <0KUV00CVQ85EU6@usaga04-in.huawei.com> for pce@ietf.org; Fri, 18 Dec 2009 14:41:38 -0600 (CST) Received: from Z73671a ([10.192.21.57]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUV001KW85DKG@usaga04-in.huawei.com> for pce@ietf.org; Fri, 18 Dec 2009 14:41:38 -0600 (CST) Date: Fri, 18 Dec 2009 15:41:36 -0500 From: Quintin Zhao To: 'JP Vasseur' Message-id: <002601ca8022$7ebcdb70$3915c00a@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=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acp/UNrkTVZ8DEo9TbKT/ceHuNx4/gAAvbWwACAwhDAAChgRcA== Cc: pce@ietf.org Subject: Re: [Pce] Inter-domain-p2mp-procedures 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: Fri, 18 Dec 2009 20:41:54 -0000 JP, Thanks for your comments and suggestions. I agree with you that for a quickly recovery, FRR is a good choice. For = the p2mp TE LSP, if the failures are about link failures, FRR can be used = for the recovery. If the failures are about the p2mp nodes which can be the root/branch/bud/leaf nodes, FRR might not be an easy way to cover these cases.=A1=A1This may lead to other possible solutions and the = pre-computed backup sub-tree or the whole backup tree might be needed for the = possible solutions. As you mentioned, using the FRR itself will eventually need = the head end reoptimization using a make before break. The pre-computed backup p2mp path/sub-path or the new computed path = during reoptimization process using make before breaks are the optimal path = subject to the OF and all other current constrains when the path is computed by = the PCE. I agree with you that we can not draw the conclusion on the = potentially level of sub-optimality of performing local reroute as opposed to global reoptimization. Also we can not draw the conclusion if these backup path or optimized = path after the failure is better or worse than the primary path. These pre-computed backup paths/sub-paths or the optimized paths under the = failure condition are the best path which can be used for the recovery of the failure while satisfying all the conditions. =20 Regards, Quintin -----Original Message----- From: JP Vasseur [mailto:jvasseur@cisco.com]=20 Sent: Thursday, December 17, 2009 1:26 PM To: Quintin Zhao Cc: pce@ietf.org Subject: Re: [Pce] Inter-domain-p2mp-procedures Hi, Note that this is a fairly well-known issue. The aim of local repair =20 has always been to quickly recover from the failure. The degree of =20 resources guarantees and optimality depends on the amount of resources =20 dedicated to backup, several assumptions with regards to potential =20 simultaneous failures, the algorithms used to pre-compute backup =20 tunnels, etc ... The approach taken by P2P FRR has been to first =20 locally reroute and trigger a head-end reoptimization using a make =20 before break. I do not think that you can draw any conclusion on the =20 potentially level of sub-optimality of performing local reroute as =20 opposed to global reoptimization. It depends on a number of factors. JP. On Dec 14, 2009, at 10:15 PM, Quintin Zhao wrote: > > Hello PCE'rs, > > I would like to follow-up on some discussions from our PCE WG =20 > session last > month. Specifically regarding Dajiang's failure and recomputation > observations on our draft. We are very interested to hear comments =20 > regarding > the need for computing secondary paths in the event of failure. =20 > Currently > our thinking is to recompute the sub-tree based in the domain where =20 > the > failure has occurred. In this case we would not need to perform a > recalculation of the entire tree. We could also recompute the entire =20 > tree, > and avoid the failed areas, as long as the TED has the updated =20 > topology. > Realistically one might have a backup core tree pre-computed so you =20 > can > switch over in the event of failure. There are also other =20 > considerations. > Would a partial recomputation provide a "worse" SPT or MCT tree, or =20 > would a > full tree recomputation provide a "better" SPT or MCT? I can think of > scenarios for both a partial and full recomputation, so perhaps we =20 > need to > implement both but allow the PCC to decide when to issue a partial =20 > or full > recomputation based on some criterion. > > Thanks, > > Quintin > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From jvasseur@cisco.com Sat Dec 19 01:51:46 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 6175228C12B for ; Sat, 19 Dec 2009 01:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.288 X-Spam-Level: X-Spam-Status: No, score=-4.288 tagged_above=-999 required=5 tests=[AWL=-2.289, 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 RrRNS4ZhfXJv for ; Sat, 19 Dec 2009 01:51:45 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 105EF3A6835 for ; Sat, 19 Dec 2009 01:51:44 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAAANMwLEuQ/uCWiWdsb2JhbACECpdOAQEKCxETBqBfhnoIj1+BK4ItVgSCbQ X-IronPort-AV: E=Sophos;i="4.47,423,1257120000"; d="scan'208";a="1533644" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 19 Dec 2009 09:24:26 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nBJ9pSEn018024; Sat, 19 Dec 2009 09:51:28 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 19 Dec 2009 10:51:28 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 19 Dec 2009 10:51:28 +0100 Message-Id: <2147DC77-13A5-44A3-B914-8678E747BC83@cisco.com> From: JP Vasseur To: Quintin Zhao In-Reply-To: <002601ca8022$7ebcdb70$3915c00a@china.huawei.com> Content-Type: text/plain; charset=GB2312; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 19 Dec 2009 10:51:27 +0100 References: <002601ca8022$7ebcdb70$3915c00a@china.huawei.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Dec 2009 09:51:28.0107 (UTC) FILETIME=[D59EA3B0:01CA8090] Cc: pce@ietf.org Subject: Re: [Pce] Inter-domain-p2mp-procedures X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 09:51:46 -0000 Hi, On Dec 18, 2009, at 9:41 PM, Quintin Zhao wrote: > > JP, > > Thanks for your comments and suggestions. > > I agree with you that for a quickly recovery, FRR is a good choice. =20= > For the > p2mp TE LSP, if the failures are about link failures, FRR can be =20 > used for > the recovery. If the failures are about the p2mp nodes which can be =20= > the > root/branch/bud/leaf nodes, FRR might not be an easy way to cover =20 > these > cases.=A1=A1 What makes you think that the use of FRR is less applicable to node =20 failures ? (for which you could either use a set of P2P backup or a single P2MP =20 backup) Thanks JP. > This may lead to other possible solutions and the pre-computed > backup sub-tree or the whole backup tree might be needed for the =20 > possible > solutions. As you mentioned, using the FRR itself will eventually =20 > need the > head end reoptimization using a make before break. > > The pre-computed backup p2mp path/sub-path or the new computed path =20= > during > reoptimization process using make before breaks are the optimal path =20= > subject > to the OF and all other current constrains when the path is computed =20= > by the > PCE. I agree with you that we can not draw the conclusion on the =20 > potentially > level of sub-optimality of performing local reroute as opposed to =20 > global > reoptimization. > > Also we can not draw the conclusion if these backup path or =20 > optimized path > after the failure is better or worse than the primary path. These > pre-computed backup paths/sub-paths or the optimized paths under the =20= > failure > condition are the best path which can be used for the recovery of the > failure while satisfying all the conditions. > > Regards, > Quintin > > > -----Original Message----- > From: JP Vasseur [mailto:jvasseur@cisco.com] > Sent: Thursday, December 17, 2009 1:26 PM > To: Quintin Zhao > Cc: pce@ietf.org > Subject: Re: [Pce] Inter-domain-p2mp-procedures > > Hi, > > Note that this is a fairly well-known issue. The aim of local repair > has always been to quickly recover from the failure. The degree of > resources guarantees and optimality depends on the amount of resources > dedicated to backup, several assumptions with regards to potential > simultaneous failures, the algorithms used to pre-compute backup > tunnels, etc ... The approach taken by P2P FRR has been to first > locally reroute and trigger a head-end reoptimization using a make > before break. I do not think that you can draw any conclusion on the > potentially level of sub-optimality of performing local reroute as > opposed to global reoptimization. It depends on a number of factors. > > JP. > > On Dec 14, 2009, at 10:15 PM, Quintin Zhao wrote: > >> >> Hello PCE'rs, >> >> I would like to follow-up on some discussions from our PCE WG >> session last >> month. Specifically regarding Dajiang's failure and recomputation >> observations on our draft. We are very interested to hear comments >> regarding >> the need for computing secondary paths in the event of failure. >> Currently >> our thinking is to recompute the sub-tree based in the domain where >> the >> failure has occurred. In this case we would not need to perform a >> recalculation of the entire tree. We could also recompute the entire >> tree, >> and avoid the failed areas, as long as the TED has the updated >> topology. >> Realistically one might have a backup core tree pre-computed so you >> can >> switch over in the event of failure. There are also other >> considerations. >> Would a partial recomputation provide a "worse" SPT or MCT tree, or >> would a >> full tree recomputation provide a "better" SPT or MCT? I can think of >> scenarios for both a partial and full recomputation, so perhaps we >> need to >> implement both but allow the PCC to decide when to issue a partial >> or full >> recomputation based on some criterion. >> >> Thanks, >> >> Quintin >> >> _______________________________________________ >> Pce mailing list >> Pce@ietf.org >> https://www.ietf.org/mailman/listinfo/pce > > From qzhao@huawei.com Sun Dec 20 18:50:03 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 229CD3A6822 for ; Sun, 20 Dec 2009 18:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 sen2Rte1Idwc for ; Sun, 20 Dec 2009 18:50:02 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 2527A3A67F7 for ; Sun, 20 Dec 2009 18:50:02 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUZ00M4QEIXJO@usaga01-in.huawei.com> for pce@ietf.org; Sun, 20 Dec 2009 18:49:46 -0800 (PST) Received: from Z73671a (c-24-63-225-158.hsd1.ma.comcast.net [24.63.225.158]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUZ007JQEIVC6@usaga01-in.huawei.com> for pce@ietf.org; Sun, 20 Dec 2009 18:49:45 -0800 (PST) Date: Sun, 20 Dec 2009 21:49:40 -0500 From: Quintin Zhao To: jvasseur@cisco.com Message-id: <001801ca81e8$3f3dc910$0702a8c0@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=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcqAkNuE9kWNKnOwRFqHo6D8OQo0DgBGvwkA Cc: pce@ietf.org Subject: [Pce] FW: Inter-domain-p2mp-procedures 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, 21 Dec 2009 02:50:03 -0000 JP, Good question! I guess that I should use "more complex to be = implemented" instead of "less applicable" in my previous email when I refer to using = FRR for P2MP node protection. What I was trying to mean is that p2p backup is easily to be used for = the link protection for p2mp. To use FRR for the node protection in p2mp, it = is not that straight forward comparing to p2p node protection, especially = from the point view of bandwidth cost and label allocation. For example, to = use the p2p tunnel to backup the branch node, we need multiple p2p tunnels = to protect a single branch node. If the p2mp backup tunnel is used for the branch node protection, then the upstream label allocation might be = needed.=20 Regards, Quintin -----Original Message----- From: JP Vasseur [mailto:jvasseur@cisco.com]=20 Sent: Saturday, December 19, 2009 4:51 AM To: Quintin Zhao Cc: pce@ietf.org Subject: Re: [Pce] Inter-domain-p2mp-procedures Hi, On Dec 18, 2009, at 9:41 PM, Quintin Zhao wrote: > > JP, > > Thanks for your comments and suggestions. > > I agree with you that for a quickly recovery, FRR is a good choice. =20 > For the > p2mp TE LSP, if the failures are about link failures, FRR can be =20 > used for > the recovery. If the failures are about the p2mp nodes which can be =20 > the > root/branch/bud/leaf nodes, FRR might not be an easy way to cover =20 > these > cases.=A1=A1 What makes you think that the use of FRR is less applicable to node =20 failures ? (for which you could either use a set of P2P backup or a single P2MP =20 backup) Thanks JP. > This may lead to other possible solutions and the pre-computed > backup sub-tree or the whole backup tree might be needed for the =20 > possible > solutions. As you mentioned, using the FRR itself will eventually =20 > need the > head end reoptimization using a make before break. > > The pre-computed backup p2mp path/sub-path or the new computed path =20 > during > reoptimization process using make before breaks are the optimal path =20 > subject > to the OF and all other current constrains when the path is computed =20 > by the > PCE. I agree with you that we can not draw the conclusion on the =20 > potentially > level of sub-optimality of performing local reroute as opposed to =20 > global > reoptimization. > > Also we can not draw the conclusion if these backup path or =20 > optimized path > after the failure is better or worse than the primary path. These > pre-computed backup paths/sub-paths or the optimized paths under the =20 > failure > condition are the best path which can be used for the recovery of the > failure while satisfying all the conditions. > > Regards, > Quintin > > > -----Original Message----- > From: JP Vasseur [mailto:jvasseur@cisco.com] > Sent: Thursday, December 17, 2009 1:26 PM > To: Quintin Zhao > Cc: pce@ietf.org > Subject: Re: [Pce] Inter-domain-p2mp-procedures > > Hi, > > Note that this is a fairly well-known issue. The aim of local repair > has always been to quickly recover from the failure. The degree of > resources guarantees and optimality depends on the amount of resources > dedicated to backup, several assumptions with regards to potential > simultaneous failures, the algorithms used to pre-compute backup > tunnels, etc ... The approach taken by P2P FRR has been to first > locally reroute and trigger a head-end reoptimization using a make > before break. I do not think that you can draw any conclusion on the > potentially level of sub-optimality of performing local reroute as > opposed to global reoptimization. It depends on a number of factors. > > JP. > > On Dec 14, 2009, at 10:15 PM, Quintin Zhao wrote: > >> >> Hello PCE'rs, >> >> I would like to follow-up on some discussions from our PCE WG >> session last >> month. Specifically regarding Dajiang's failure and recomputation >> observations on our draft. We are very interested to hear comments >> regarding >> the need for computing secondary paths in the event of failure. >> Currently >> our thinking is to recompute the sub-tree based in the domain where >> the >> failure has occurred. In this case we would not need to perform a >> recalculation of the entire tree. We could also recompute the entire >> tree, >> and avoid the failed areas, as long as the TED has the updated >> topology. >> Realistically one might have a backup core tree pre-computed so you >> can >> switch over in the event of failure. There are also other >> considerations. >> Would a partial recomputation provide a "worse" SPT or MCT tree, or >> would a >> full tree recomputation provide a "better" SPT or MCT? I can think of >> scenarios for both a partial and full recomputation, so perhaps we >> need to >> implement both but allow the PCC to decide when to issue a partial >> or full >> recomputation based on some criterion. >> >> Thanks, >> >> Quintin >> >> _______________________________________________ >> Pce mailing list >> Pce@ietf.org >> https://www.ietf.org/mailman/listinfo/pce > > From qzhao@huawei.com Sun Dec 20 19:01: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 EC7133A697A for ; Sun, 20 Dec 2009 19:01:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kTjoGpg-txm for ; Sun, 20 Dec 2009 19:01:09 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 25AF33A6977 for ; Sun, 20 Dec 2009 19:01:09 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUZ00MMSF1HJO@usaga01-in.huawei.com> for pce@ietf.org; Sun, 20 Dec 2009 19:00:53 -0800 (PST) Received: from Z73671a (c-24-63-225-158.hsd1.ma.comcast.net [24.63.225.158]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUZ007ZAF1FC6@usaga01-in.huawei.com> for pce@ietf.org; Sun, 20 Dec 2009 19:00:53 -0800 (PST) Date: Sun, 20 Dec 2009 22:00:47 -0500 From: Quintin Zhao To: jvasseur@cisco.com, julien.meuric@orange-ftgroup.com Message-id: <001901ca81e9$cbdea690$0702a8c0@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_zZxebPAEUqrwYNye3G3wZw)" Thread-index: AcqB6cs8TiSNSOV7SDKQ0LgQicHNug== Cc: pce@ietf.org Subject: [Pce] Request WG Adoption of draft-zhao-pce-pcep-inter-domain-p2mp-procedures 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, 21 Dec 2009 03:01:10 -0000 This is a multi-part message in MIME format. --Boundary_(ID_zZxebPAEUqrwYNye3G3wZw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Co-Chairs and PCE WG, Different parties have been working on solutions for computing P2MP paths across multi-domain networks. At IETF 75 we were requested by JP, to formulate a plan and resolve any issues in order to move the work forward. After calls and emails between draft-ali-pce-brpc-p2mp-ext and draft-zhao-pce-pcep-inter-domain-p2mp-procedure authors, we felt there was concurrence to merge the solutions and work together on a unified solution. At IETF 76 we presented our initial/combined PCE-based Shortest Constrained P2MP Inter-domain TE-LSP solution (draft-zhao-pce-pcep-inter-domain-p2mp-procedures-02). We would like to know if the co-chairs and WG would be in favor of the document becoming a WG draft? Regards, Quintin --Boundary_(ID_zZxebPAEUqrwYNye3G3wZw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi Co-Chairs and PCE = WG,

 

Different parties have been = working on solutions for computing P2MP paths across multi-domain networks. At = IETF 75 we were requested by JP, to formulate a plan and resolve any issues in = order to move the work forward. After calls and emails between = draft-ali-pce-brpc-p2mp-ext and draft-zhao-pce-pcep-inter-domain-p2mp-procedure authors, we felt = there was concurrence to merge the solutions and work together on a unified = solution. At IETF 76 we presented our initial/combined PCE-based Shortest Constrained = P2MP Inter-domain TE-LSP solution (draft-zhao-pce-pcep-inter-domain-p2mp-procedures-02). =

 

We would like to know if = the co-chairs and WG would be in favor of the document becoming a WG = draft?

 

Regards,

Quintin

--Boundary_(ID_zZxebPAEUqrwYNye3G3wZw)-- From jvasseur@cisco.com Wed Dec 23 04:49:00 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 01FA23A6A81 for ; Wed, 23 Dec 2009 04:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.191 X-Spam-Level: X-Spam-Status: No, score=-4.191 tagged_above=-999 required=5 tests=[AWL=-2.192, 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 5Y62GbE84PhQ for ; Wed, 23 Dec 2009 04:48:59 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 7A10D3A69D9 for ; Wed, 23 Dec 2009 04:48:58 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQAAOCfMUuQ/uCWiWdsb2JhbACDbZdiAQEBCgsREwakaYZ6CI98gSuCLloEgm0 X-IronPort-AV: E=Sophos;i="4.47,442,1257120000"; d="scan'208";a="1821620" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 23 Dec 2009 12:21:19 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nBNCmeOe027722; Wed, 23 Dec 2009 12:48:40 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Dec 2009 13:48:40 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Dec 2009 13:48:39 +0100 Message-Id: <4E30AC53-5DCA-4220-80DA-200F90BE955D@cisco.com> From: JP Vasseur To: Quintin Zhao In-Reply-To: <001801ca81e8$3f3dc910$0702a8c0@china.huawei.com> Content-Type: text/plain; charset=GB2312; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 23 Dec 2009 13:48:39 +0100 References: <001801ca81e8$3f3dc910$0702a8c0@china.huawei.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 23 Dec 2009 12:48:39.0849 (UTC) FILETIME=[4048B990:01CA83CE] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17086.007 X-TM-AS-Result: No--22.355600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: pce@ietf.org Subject: Re: [Pce] Inter-domain-p2mp-procedures 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, 23 Dec 2009 12:49:00 -0000 Hi, On Dec 21, 2009, at 3:49 AM, Quintin Zhao wrote: > JP, > > Good question! I guess that I should use "more complex to be =20 > implemented" > instead of "less applicable" in my previous email when I refer to =20 > using FRR > for P2MP node protection. > Well this is arguable though .. > What I was trying to mean is that p2p backup is easily to be used =20 > for the > link protection for p2mp. To use FRR for the node protection in =20 > p2mp, it is > not that straight forward comparing to p2p node protection, =20 > especially from > the point view of bandwidth cost and label allocation. Well it all depends on how you compute your P2P backup, and this may =20 be used for a very short period of time. There are excellent off-line =20 algorithms to achieve some good level of efficiency. > For example, to use > the p2p tunnel to backup the branch node, we need multiple p2p =20 > tunnels to > protect a single branch node. If the p2mp backup tunnel is used for =20= > the > branch node protection, then the upstream label allocation might be =20= > needed. Which is not a major issue. See long discussions on the list some time =20= ago on the subject matter. Thanks. JP. > > > Regards, > Quintin > > -----Original Message----- > From: JP Vasseur [mailto:jvasseur@cisco.com] > Sent: Saturday, December 19, 2009 4:51 AM > To: Quintin Zhao > Cc: pce@ietf.org > Subject: Re: [Pce] Inter-domain-p2mp-procedures > > Hi, > > On Dec 18, 2009, at 9:41 PM, Quintin Zhao wrote: > >> >> JP, >> >> Thanks for your comments and suggestions. >> >> I agree with you that for a quickly recovery, FRR is a good choice. >> For the >> p2mp TE LSP, if the failures are about link failures, FRR can be >> used for >> the recovery. If the failures are about the p2mp nodes which can be >> the >> root/branch/bud/leaf nodes, FRR might not be an easy way to cover >> these >> cases.=A1=A1 > > What makes you think that the use of FRR is less applicable to node > failures ? > (for which you could either use a set of P2P backup or a single P2MP > backup) > > Thanks > > JP. > >> This may lead to other possible solutions and the pre-computed >> backup sub-tree or the whole backup tree might be needed for the >> possible >> solutions. As you mentioned, using the FRR itself will eventually >> need the >> head end reoptimization using a make before break. >> >> The pre-computed backup p2mp path/sub-path or the new computed path >> during >> reoptimization process using make before breaks are the optimal path >> subject >> to the OF and all other current constrains when the path is computed >> by the >> PCE. I agree with you that we can not draw the conclusion on the >> potentially >> level of sub-optimality of performing local reroute as opposed to >> global >> reoptimization. >> >> Also we can not draw the conclusion if these backup path or >> optimized path >> after the failure is better or worse than the primary path. These >> pre-computed backup paths/sub-paths or the optimized paths under the >> failure >> condition are the best path which can be used for the recovery of the >> failure while satisfying all the conditions. >> >> Regards, >> Quintin >> >> >> -----Original Message----- >> From: JP Vasseur [mailto:jvasseur@cisco.com] >> Sent: Thursday, December 17, 2009 1:26 PM >> To: Quintin Zhao >> Cc: pce@ietf.org >> Subject: Re: [Pce] Inter-domain-p2mp-procedures >> >> Hi, >> >> Note that this is a fairly well-known issue. The aim of local repair >> has always been to quickly recover from the failure. The degree of >> resources guarantees and optimality depends on the amount of =20 >> resources >> dedicated to backup, several assumptions with regards to potential >> simultaneous failures, the algorithms used to pre-compute backup >> tunnels, etc ... The approach taken by P2P FRR has been to first >> locally reroute and trigger a head-end reoptimization using a make >> before break. I do not think that you can draw any conclusion on the >> potentially level of sub-optimality of performing local reroute as >> opposed to global reoptimization. It depends on a number of factors. >> >> JP. >> >> On Dec 14, 2009, at 10:15 PM, Quintin Zhao wrote: >> >>> >>> Hello PCE'rs, >>> >>> I would like to follow-up on some discussions from our PCE WG >>> session last >>> month. Specifically regarding Dajiang's failure and recomputation >>> observations on our draft. We are very interested to hear comments >>> regarding >>> the need for computing secondary paths in the event of failure. >>> Currently >>> our thinking is to recompute the sub-tree based in the domain where >>> the >>> failure has occurred. In this case we would not need to perform a >>> recalculation of the entire tree. We could also recompute the entire >>> tree, >>> and avoid the failed areas, as long as the TED has the updated >>> topology. >>> Realistically one might have a backup core tree pre-computed so you >>> can >>> switch over in the event of failure. There are also other >>> considerations. >>> Would a partial recomputation provide a "worse" SPT or MCT tree, or >>> would a >>> full tree recomputation provide a "better" SPT or MCT? I can think =20= >>> of >>> scenarios for both a partial and full recomputation, so perhaps we >>> need to >>> implement both but allow the PCC to decide when to issue a partial >>> or full >>> recomputation based on some criterion. >>> >>> Thanks, >>> >>> Quintin >>> >>> _______________________________________________ >>> Pce mailing list >>> Pce@ietf.org >>> https://www.ietf.org/mailman/listinfo/pce >> >> > From adrian@olddog.co.uk Tue Dec 29 09:44:18 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 ED1803A68CC for ; Tue, 29 Dec 2009 09:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.657 X-Spam-Level: X-Spam-Status: No, score=0.657 tagged_above=-999 required=5 tests=[AWL=-1.479, BAYES_50=0.001, STOX_REPLY_TYPE=0.001, TVD_FINGER_02=2.134] 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 y7gtoLb4eEM4 for ; Tue, 29 Dec 2009 09:44:18 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 677953A635F for ; Tue, 29 Dec 2009 09:44:16 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id nBTHhaBa002564; Tue, 29 Dec 2009 17:43:36 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id nBTHhZx8002560; Tue, 29 Dec 2009 17:43:35 GMT Message-ID: From: "Adrian Farrel" To: References: <018101ca7da6$de1435b0$9a3ca110$@co.uk> <28361E9D-2D43-42B8-BD82-8B6169A487C8@cisco.com> Date: Tue, 29 Dec 2009 17:43:31 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by asmtp2.iomartmail.com id nBTHhZx8002560 Subject: Re: [Pce] WG Last Call on I-D Action:draft-ietf-pce-p2mp-req-04.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2009 17:44:19 -0000 Hi, As I understand this discussion, the resolution is that there is no chang= e=20 needed to the P2MP Requirements draft. So WG last call completed without any changes needed. Ready to move on? Cheers, Adrian ----- Original Message -----=20 From: "JP Vasseur" To: "Daniel King" Cc: Sent: Thursday, December 17, 2009 6:17 PM Subject: Re: [Pce] WG Last Call on I-D Action:draft-ietf-pce-p2mp-req-04.= txt Hi Dan, On Dec 15, 2009, at 5:51 PM, Daniel King wrote: > Hi JP, All, > > As a co-editor of the P2MP Solutions (draft-ietf-pce-pcep-p2mp- > extensions-05) I would like to state that the authors of the P2MP > Requirements (draft-ietf-pce-p2mp-req-04) added all the additional > requirements that we identified during the development of the P2MP > solutions document. So I believe that the P2MP Requirements document > is in fairly good shape. > > We do however have one outstanding issue regarding the solutions > document. I do not believe this directly impacts the P2MP > Requirements document itself, but it=92s certainly worth discussing > the issue on the list. The P2MP Requirements draft mentions the > requirement for reoptimization of P2MP TE LSPs: > > >> > 2.1.10. Reoptimization of P2MP TE LSPs > > R11: Reoptimization MUST be supported for P2MP TE LSPs as described > for P2P LSPs in [RFC4657]. > << > > There is a further request in this section that states "that a P2MP > Path Computation Request SHOULD contain a parameter that allows the > PCC to express a cost-benefit reoptimization threshold for the whole > LSP as well as per destination". This seems like a sensible request. > After all, why switch to a new path if the reoptimization request > returns a path that's no better, or even worse, than the existing > path? > > We support Objective Functions [RFC5541] in the P2MP Solutions > document, and our solutions allows a path to be computed using a > Shortest Path Tree (SPT) or Minimum Cost Tree (MCT), these will be > processed according to the rules defined in RFC5541, but we do not > currently have a "reoptimization threshold" function. Some of the > authors of the P2MP Solution draft think the reoptimization > threshold function is relevant to both P2P and P2MP, and threshold > solution should be applicable to both P2P and P2MP. Therefore the > current P2MP Solutions would state that this requirement will be > resolved in a future document. > > We would really like to hear comments or suggestions regarding the > threshold reoptimization function. Both from the perspective of a > future solution that supports both P2P and P2MP, and/or this feature > should be specifically part of the existing P2MP Solutions draft. Good question and for people having long memories, this was discussed almost 5 years ago (!). I had personally advocated for such a solution so I'm clearly in favor of it and I also believe that the same mechanism should apply to both P2P and P2MP. Of course, there might be a need for specific threshold in light of the OF. For example, if we end up defining an OF for P2MP according which the objective is to minimize the path cost difference between each leaf and the head-end (to guaranty fairness delivery for mcast traffic for example), we may need a P2MP specific threshold. So let's try to make the threshold mechanisms as generic and modular as possible. Back to your question I would suggest to leave it out from the P2MP solution draft and have a separate ID covering both the P2P and P2MP threshold solutions. Thanks. JP. > > Br, Dan/P2MP Solutions Authors. > > > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf > Of JP Vasseur > Sent: 07 December 2009 19:08 > To: pce@ietf.org > Subject: [Pce] WG Last Call on I-D Action:draft-ietf-pce-p2mp- > req-04.txt > > Dear WG, > > Although the discussion on this ID has been relatively moderate, the > document has been stable for a while and discussed at several WG > meetings. > > This starts a 2-week WG Last Call on I-D Action:draft-ietf-pce-p2mp- > req-04.txt. > > Please send your comment to the authors and copy the list by Dec 15, > noon ET. > > Thanks. > > JP and Julien. -------------------------------------------------------------------------= ------- > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce >=20 From daniel@olddog.co.uk Tue Dec 29 14:26:00 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 8A82E3A69EA for ; Tue, 29 Dec 2009 14:26:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.477 X-Spam-Level: X-Spam-Status: No, score=-0.477 tagged_above=-999 required=5 tests=[AWL=-0.478, BAYES_50=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 fCBD4P+vwmxP for ; Tue, 29 Dec 2009 14:25:59 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.193.159]) by core3.amsl.com (Postfix) with ESMTP id 40D883A69B7 for ; Tue, 29 Dec 2009 14:25:59 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id nBTMPLmU004700; Tue, 29 Dec 2009 22:25:26 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id nBTMPKUl004695; Tue, 29 Dec 2009 22:25:21 GMT From: "Daniel King" To: "'JP Vasseur'" References: <018101ca7da6$de1435b0$9a3ca110$@co.uk> <28361E9D-2D43-42B8-BD82-8B6169A487C8@cisco.com> In-Reply-To: <28361E9D-2D43-42B8-BD82-8B6169A487C8@cisco.com> Date: Tue, 29 Dec 2009 22:25:22 -0000 Message-ID: <014101ca88d5$d0292750$707b75f0$@co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-index: Acp/UK9hR6M7/WgiRMW7r2O0iBPnAgJhQVoA Content-Language: en-gb Cc: pce@ietf.org Subject: Re: [Pce] WG Last Call on I-D Action:draft-ietf-pce-p2mp-req-04.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2009 22:26:00 -0000 Hi JP, thanks for the clarifications and suggestions! Br, Dan.=20 From: JP Vasseur [mailto:jvasseur@cisco.com]=20 Sent: 17 December 2009 18:17 To: Daniel King Cc: pce@ietf.org Subject: Re: [Pce] WG Last Call on I-D = Action:draft-ietf-pce-p2mp-req-04.txt Hi Dan, On Dec 15, 2009, at 5:51 PM, Daniel King wrote: Hi JP, All, =A0 As a co-editor of the P2MP Solutions (draft-ietf-pce-pcep-p2mp-extensions-05) I would like to state that the authors of the P2MP Requirements (draft-ietf-pce-p2mp-req-04) added all = the additional requirements that we identified during the development of the P2MP solutions document. So I believe that the P2MP Requirements = document is in fairly good shape. =A0 We do however have one outstanding issue regarding the solutions = document. I do not believe this directly impacts the P2MP Requirements document = itself, but it=92s certainly worth discussing the issue on the list. The P2MP Requirements draft mentions the requirement for reoptimization of P2MP = TE LSPs: =A0 >>=A0 2.1.10. Reoptimization of P2MP TE LSPs =A0 R11: Reoptimization MUST be supported for P2MP TE LSPs as described for = P2P LSPs in [RFC4657]. <<=A0 =A0 There is a further request in this section that states "that a P2MP Path Computation Request SHOULD contain a parameter that allows the PCC to express a cost-benefit reoptimization threshold for the whole LSP as = well as per destination". This seems like a sensible request. After all, why = switch to a new path if the reoptimization request returns a path that's no = better, or even worse, than the existing path? =A0 =A0 We support Objective Functions [RFC5541] in the P2MP Solutions document, = and our solutions allows a path to be computed using a Shortest Path Tree = (SPT) or Minimum Cost Tree (MCT), these will be processed according to the = rules defined in RFC5541, but we do not currently have a "reoptimization threshold" function. Some of the authors of the P2MP Solution draft = think the reoptimization threshold function is relevant to both P2P and P2MP, = and threshold solution should be applicable to both P2P and P2MP. Therefore = the current P2MP Solutions would state that this requirement will be = resolved in a future document. =A0 We would really like to hear comments or suggestions regarding the = threshold reoptimization function. Both from the perspective of a future solution = that supports both P2P and P2MP, and/or this feature should be specifically = part of the existing P2MP Solutions draft. Good question and for people having long memories, this was discussed = almost 5 years ago (!). I had personally advocated for such a solution so I'm clearly in favor of it and I also believe that the same mechanism should apply to both P2P and P2MP. Of course, there might be a need for = specific threshold in light of the OF. For example, if we end up defining an OF = for P2MP according which the objective is to minimize the path cost = difference between each leaf and the head-end (to guaranty fairness delivery for = mcast traffic for example), we may need a P2MP specific threshold. So let's = try to make the threshold mechanisms as generic and modular as possible. Back to your question I would suggest to leave it out from the P2MP = solution draft and have a separate ID covering both the P2P and P2MP threshold solutions. Thanks. JP. =A0 Br, Dan/P2MP Solutions Authors. =A0=A0=A0 =A0 =A0 From:=A0pce-bounces@ietf.org=A0[mailto:pce-bounces@ietf.org]=A0On Behalf = Of=A0JP Vasseur Sent:=A007 December 2009 19:08 To:=A0pce@ietf.org Subject:=A0[Pce] WG Last Call on I-D = Action:draft-ietf-pce-p2mp-req-04.txt =A0 Dear WG, =A0 Although the discussion on this ID has been relatively moderate, the document has been stable for a while and discussed at several WG = meetings.=A0 =A0 This starts a 2-week WG Last Call on=A0I-D Action:draft-ietf-pce-p2mp-req-04.txt. =A0 Please send your comment to the authors and copy the list by Dec 15, = noon ET. =A0 Thanks. =A0 JP and Julien. From root@core3.amsl.com Wed Dec 30 07:30:09 2009 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8C0783A68AE; Wed, 30 Dec 2009 07:30:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091230153008.8C0783A68AE@core3.amsl.com> Date: Wed, 30 Dec 2009 07:30:02 -0800 (PST) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-pcep-p2mp-extensions-06.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 15:30:09 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths Author(s) : Q. Zhao, et al. Filename : draft-ietf-pce-pcep-p2mp-extensions-06.txt Pages : 31 Date : 2009-12-30 Point-to-point Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of P2MP TE LSPs. This document describes extensions to the PCE communication Protocol (PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 1, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-p2mp-extensions-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-pcep-p2mp-extensions-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-30072043.I-D@ietf.org> --NextPart-- From daniel@olddog.co.uk Wed Dec 30 08:47:33 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 63C0B3A6A5C for ; Wed, 30 Dec 2009 08:47:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[AWL=0.902, 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 6bF-4-SBCpv8 for ; Wed, 30 Dec 2009 08:47:32 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 1E0DC3A68CB for ; Wed, 30 Dec 2009 08:47:30 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id nBUGkpNM032568 for ; Wed, 30 Dec 2009 16:46:56 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id nBUGkoES032560 for ; Wed, 30 Dec 2009 16:46:50 GMT From: "Daniel King" To: References: <20091230153008.8C0783A68AE@core3.amsl.com> In-Reply-To: <20091230153008.8C0783A68AE@core3.amsl.com> Date: Wed, 30 Dec 2009 16:46:51 -0000 Message-ID: <002901ca896f$b0446d10$10cd4730$@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: AcqJZPE1bDoWW2prSS2J4vwK1Q6EvwACgBXw Content-Language: en-gb Subject: Re: [Pce] I-D Action:draft-ietf-pce-pcep-p2mp-extensions-06.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 16:47:33 -0000 Hello all, We recently uploaded a new version of: Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths http://tools.ietf.org/html/draft-ietf-pce-pcep-p2mp-extensions-06 Changes include: - Based on feedback from JP we clarified our position on the "threshold" function. We added text stating that this feature will be addressed in a future document. - By default, the path returned by the PCE will use the compressed format. - Numerous grammar, minor textual clarification and readability edits. Thanks, Dan -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: 30 December 2009 15:30 To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-pcep-p2mp-extensions-06.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths Author(s) : Q. Zhao, et al. Filename : draft-ietf-pce-pcep-p2mp-extensions-06.txt Pages : 31 Date : 2009-12-30 Point-to-point Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of P2MP TE LSPs. This document describes extensions to the PCE communication Protocol (PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 1, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-p2mp-extensions-06.t xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From adrian@olddog.co.uk Wed Dec 30 11:20:59 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 F25633A68E1 for ; Wed, 30 Dec 2009 11:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.286 X-Spam-Level: X-Spam-Status: No, score=-0.286 tagged_above=-999 required=5 tests=[AWL=-0.288, 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 5X8qTupb+nB1 for ; Wed, 30 Dec 2009 11:20:48 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id E46213A68DF for ; Wed, 30 Dec 2009 11:20:47 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id nBUJK3Xk015609; Wed, 30 Dec 2009 19:20:08 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id nBUJK1RN015604; Wed, 30 Dec 2009 19:20:02 GMT Message-ID: From: "Adrian Farrel" To: "dhruv dhody" , , , References: <001c01ca7edf$874d5740$1f01120a@china.huawei.com> Date: Wed, 30 Dec 2009 19:18:45 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: pce@ietf.org Subject: Re: [Pce] Domain Sequence 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, 30 Dec 2009 19:20:59 -0000 Hi Dhruv, > In "draft-king-pce-hierarchy-fwk-02", section 5.6.2 [Hierarchical PCE > End-to-End Path Computation Procedure]: > > Domain paths are denoted as (S-BN11-BN21-D2-BN23-BN31-D, > S-BN11-BN21-D2-BN24-BN32-D, and S-BN13-BN41-D4-BN42-BN33-D). > > i.e. Parent PCE must know about the BNs and there interconnections. > > What is the need for this? I think you are refering to a specific example of the potential paths determined in a parent PCE that will give rise to computation requests sent to child PCEs to compute specific segments of the potential paths. Nothing here says that there is a specific representation of domain paths. But note that there is no need to represent the domain path to anyone by anyone in this model unless one of - the ingress PCC has some restriction it wants to apply - the path computation will be hybrid using some elements of BRPC - the resulting path is a hybrid that will require some elements of PDPC Thus, the question simply does not arrise. > Why can't the domain sequence be represented just by a sequence of domains > i.e. [S-D2-D and S-D4-D]? > > BRPC procedure can take domain sequence as input and figure out the > appropriate BNs and there interconnection while applying the VSPT > algorithm. Thanks, yes, that is how BRPC works. > Also note that, Child PCE can use the PCED-discovery [NEIG-PCE-DOMAIN > Sub-TLV] to specify the neighbor PCE-Domain(s) to Parent PCE, without > mentioning any BNs link-interconnection information. That is true. However, in a complex mesh of domains, knowledge of the inter-domain links can help the parent PCE to reduce the potential domain paths and so reduce the processing that the child PCEs have to do. Cheers, Adrian From daniel@olddog.co.uk Wed Dec 30 12:39:59 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 7321A3A68F7 for ; Wed, 30 Dec 2009 12:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.526 X-Spam-Level: X-Spam-Status: No, score=-1.526 tagged_above=-999 required=5 tests=[AWL=0.473, 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 porOmKe3ssA7 for ; Wed, 30 Dec 2009 12:39:58 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 731263A6829 for ; Wed, 30 Dec 2009 12:39:58 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id nBUKdLup017211 for ; Wed, 30 Dec 2009 20:39:26 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id nBUKdKOv017207 for ; Wed, 30 Dec 2009 20:39:21 GMT From: "Daniel King" To: Date: Wed, 30 Dec 2009 20:39:22 -0000 Message-ID: <004a01ca8990$2b843120$828c9360$@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: AcqJkCseP3EIbTHfQ+2qSNv3Fj82ig== Content-Language: en-gb Subject: [Pce] A new version of draft-king-pce-hierarchy-fwk 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, 30 Dec 2009 20:39:59 -0000 Hi PCE'rs, I hope everyone is enjoying the holidays. If you're looking for some reading material we recently submitted a new version (03) of the H-PCE draft: http://www.ietf.org/id/draft-king-pce-hierarchy-fwk-03.txt Notable updates include: - Assumptions and Requirements This section sets out the primary objectives and requirements to be satisfied by a PCE solution to multi-domain path computation. - Hierarchical PCE Applicability This section sets out the applicability of hierarchical PCE to MPLS (multi-AS), GMPLS (ASON) and MPLS (multi-IGP). We still have some gaps, comments or text is always welcome. - ASON Architecture We have added a significant amount of text addressing the applicability of H-PCE to ASON. Including: a) Implicit Consistency Between Hierarchical PCE and G.7715.2 b) Benefits of Hierarchical PCEs in ASON We have also clarified some of the section names for constancy and edited text for readability. Again, any comments and suggestions are always welcome. Br, Dan.