<= br>

On Nov 23, 2010, at 10:06 PM, Daniel King wrote:

Hi All,

I have uploaded the draft = minutes for IETF 79.

Please email me, and CC co-chairs, if you have a correction = requests by Sunday, 5^th December.
Br, Dan.
Date: Sat, 04 Dec 2010 06:15:01 -0800 Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-inter-layer-req-15.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: Sat, 04 Dec 2010 14:15: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 : PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering Author(s) : E. Oki, et al. Filename : draft-ietf-pce-inter-layer-req-15.txt Pages : 13 Date : 2010-12-04 The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) controlled networks. MPLS and GMPLS networks may be constructed from layered client/server networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers. PCE is a candidate solution for such requirements. Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in RFC 4657, "PCE Communication Protocol Generic Requirements". Generic requirements for a PCE discovery protocol are presented in RFC 4674, "Requirements for Path Computation Element (PCE) Discovery". This document complements the generic requirements and presents detailed sets of PCC-PCE communication protocol requirements and PCE discovery protocol requirements for inter-layer traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-req-15.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-inter-layer-req-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-12-04060543.I-D@ietf.org> --NextPart-- From adrian@olddog.co.uk Sat Dec 4 06:21:47 2010 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4D3E28C0DD for ; Sat, 4 Dec 2010 06:21:47 -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 sKg92KlwUrW2 for ; Sat, 4 Dec 2010 06:21:46 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by core3.amsl.com (Postfix) with ESMTP id 9932C28C0E1 for ; Sat, 4 Dec 2010 06:21:46 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id oB4EN4eD003367 for ; Sat, 4 Dec 2010 14:23:05 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id oB4EN3YS003361 for ; Sat, 4 Dec 2010 14:23:04 GMT From: "Adrian Farrel" To: References: <20101204141501.31794.34082.idtracker@localhost> In-Reply-To: <20101204141501.31794.34082.idtracker@localhost> Date: Sat, 4 Dec 2010 14:23:07 -0000 Message-ID: <0c2201cb93be$c5dac7f0$519057d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGYx9iPkmZIthuoP+7lbR50TAZVUpP17Y4w Content-Language: en-gb Subject: Re: [Pce] I-D Action:draft-ietf-pce-inter-layer-req-15.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 14:21:48 -0000 Hi PCE WG, This revision just adds RFC numbers to the Abstract to address a review comment from our AD. No toher changes. Cheers, Adrian > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: 04 December 2010 14:15 > To: i-d-announce@ietf.org > Cc: pce@ietf.org > Subject: [Pce] I-D Action:draft-ietf-pce-inter-layer-req-15.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 and PCE Discovery Requirements for > Inter-Layer Traffic Engineering > Author(s) : E. Oki, et al. > Filename : draft-ietf-pce-inter-layer-req-15.txt > Pages : 13 > Date : 2010-12-04 > > The Path Computation Element (PCE) provides functions of path > computation in support of traffic engineering in Multi-Protocol Label > Switching (MPLS) and Generalized MPLS (GMPLS) controlled networks. > > MPLS and GMPLS networks may be constructed from layered client/server > networks. It is advantageous for overall network efficiency to > provide end-to-end traffic engineering across multiple network > layers. PCE is a candidate solution for such requirements. > > Generic requirements for a communication protocol between Path > Computation Clients (PCCs) and PCEs are presented in RFC 4657, "PCE > Communication Protocol Generic Requirements". Generic requirements > for a PCE discovery protocol are presented in RFC 4674, "Requirements > for Path Computation Element (PCE) Discovery". > > This document complements the generic requirements and presents > detailed sets of PCC-PCE communication protocol requirements and PCE > discovery protocol requirements for inter-layer traffic engineering. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-req-15.txt From iesg-secretary@ietf.org Fri Dec 10 09:46:44 2010 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D87A28C105; Fri, 10 Dec 2010 09:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 BstKXXGnpDuO; Fri, 10 Dec 2010 09:46:43 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 979E128C0EA; Fri, 10 Dec 2010 09:46:43 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20101210174643.2175.5825.idtracker@localhost> Date: Fri, 10 Dec 2010 09:46:43 -0800 Cc: pce@ietf.org Subject: [Pce] Last Call: draft-ietf-pce-inter-layer-req (PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering) to Informational RFC 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, 10 Dec 2010 17:46:44 -0000 The IESG has received a request from the Path Computation Element WG (pce) to consider the following document: - 'PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-01-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-req-15.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14050&rfc_flag=0 No IPR declarations have been submitted directly on this I-D. From cyril.margaria@nsn.com Wed Dec 15 06:13:10 2010 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E176A28C147 for ; Wed, 15 Dec 2010 06:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 gsMgqOtVcr0U for ; Wed, 15 Dec 2010 06:13:10 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 9CE8028C0DF for ; Wed, 15 Dec 2010 06:13:09 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id oBFEEltb005437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Dec 2010 15:14:47 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id oBFEEhYf019766; Wed, 15 Dec 2010 15:14:47 +0100 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Dec 2010 15:14:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Dec 2010 15:14:41 +0100 Message-ID: In-Reply-To: <4CE7F124.8070706@orange-ftgroup.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Status of draft-dhody-pce-pcep-pathkey-mib-00 Thread-Index: AcuI03nWBKXrpI3XRkut0Q3TjKXxMATiJEtA References: <4CE7F124.8070706@orange-ftgroup.com> From: "Margaria, Cyril (NSN - DE/Munich)" To: X-OriginalArrivalTime: 15 Dec 2010 14:14:42.0720 (UTC) FILETIME=[6B111200:01CB9C62] Cc: Udayasreepalle@huawei.com, qzhao@huawei.com Subject: Re: [Pce] Status of draft-dhody-pce-pcep-pathkey-mib-00 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, 15 Dec 2010 14:13:11 -0000 Hi Pcers, authors I have the following technical comments to the draft: - in current MIB described EROs or RROs (rfc3812, rfc4802) there is no representation of PKS, this should be added I believe. - Several timers are defined in the draft, all of them use minutes,=20 I think that using a textual convention for those (like the LmpInterval in RFC4631) would make the MIB more consistent.=20 In addition I would think that protocol timers are usually using milliseconds as unit, Is there a specific reason to use minutes? - pcePcepPathKeyReUseTimer : the minimum reuse time is equivalent to 30 minutes (RFC5520, section 2.1.), unit (I would propose ms) should be added. - pcePcepPathKeyConfig :=20 - I believe MAX-ACCESS read-create make only sense for tables, not scalar. - the comment state that this is the configuration for inter-domain, is there a particular reason to restrict the PKS to inter domain?, if not remove the inter-domain reference would be more generic. - pcePcepPathKeyPath : this is currently a string, to be consistent with exiting ERO representation I believe this should be a pointer to a HopTable, like the one in rfc3812 : mpls tunnel mib, mplsTunnelHopTable and rfc4802 : gmpls tunnel MIB gmplsTunnelHopTable. =20 - pcePcepPathKeyRetrieveSource : only one entry here, but according to RFC5520, section 2.1. :=20 " A local policy SHOULD be used to determine for how long to retain such stored information, and whether to discard the information after it has been queried using the procedures described below. It is RECOMMENDED for a PCE to store the PKS for a period of 10 minutes" As retention is allowed, more than one PCC (for diversity/route exclusion purpose for instance) could request a given PKS, so this should be a pointer to a table listing all the nodes that retrieved the PKS. - pcePcepPathKeyReuseTime : - pcePcepPathKeyDiscardTime : is it a time, an absolute or relative time? Why are those object read-only, one could expect that the pcePcepPathKeyReUseTimer is the policy, but it could be overwritten on a individual PKS based - a pcePcepPathKeyCreationTime TimeStamp, would also be usefull I believe. - I am missing a row status, I think it should be possible to manually delete PKS, =20 =20 Best Regards > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of > ext Julien Meuric > Sent: Saturday, November 20, 2010 5:03 PM > To: pce@ietf.org > Subject: [Pce] Status of draft-dhody-pce-pcep-pathkey-mib-00 >=20 > Hi all. >=20 > During our meeting in Beijing, draft-dhody-pce-pcep-pathkey-mib was > presented. Not only defines this I-D a MIB module that is useful for > the path key mechanism, but also it adresses a requirement explicitly > stated in our standard track RFCs (RFC 5520), which means the item has > already been through IETF consensus. All the same, as said during the > meeting, if you have good reasons to be opposed to take it as WG item, > you still have a few days to speak before we move forward. >=20 > As usual, technical discussion about the content of the I-D is still > very welcome. >=20 > Regards, >=20 > JP & Julien >=20 > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From dhruvd@huawei.com Wed Dec 15 13:40:51 2010 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A0FB28C123 for ; Wed, 15 Dec 2010 13:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.494 X-Spam-Level: X-Spam-Status: No, score=-4.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, RCVD_IN_DNSWL_MED=-4, 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 xSuuDXgZo6zY for ; Wed, 15 Dec 2010 13:40:41 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 989B728C126 for ; Wed, 15 Dec 2010 13:40:37 -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 <0LDH0076COA9HI@szxga03-in.huawei.com> for pce@ietf.org; Thu, 16 Dec 2010 05:42:09 +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 <0LDH00DM3OA9BT@szxga03-in.huawei.com> for pce@ietf.org; Thu, 16 Dec 2010 05:42:09 +0800 (CST) Received: from Htiplqw12q ([10.193.34.207]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LDH00H2LOA11X@szxml04-in.huawei.com> for pce@ietf.org; Thu, 16 Dec 2010 05:42:09 +0800 (CST) Date: Wed, 15 Dec 2010 13:42:00 -0800 From: Dhruv Dhody In-reply-to: To: "'Margaria, Cyril (NSN - DE/Munich)'" , pce@ietf.org Message-id: <002101cb9ca0$e9cae600$cf22c10a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_lnUCSOD4u6pC7B+BLB3esA)" Thread-index: AcuI03nWBKXrpI3XRkut0Q3TjKXxMATiJEtAAAwPMxA= Cc: qzhao@huawei.com Subject: Re: [Pce] Status of draft-dhody-pce-pcep-pathkey-mib-00 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, 15 Dec 2010 21:40:51 -0000 This is a multi-part message in MIME format. --Boundary_(ID_lnUCSOD4u6pC7B+BLB3esA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear Cyril, Thanks for your detailed review. Please find my comments inline. Regards, Dhruv Dhruv Dhody Senior Technical Leader Huawei-Santa Clara, CA Work: (408) 330 4940 Cell: (408) 667 8127 This email and its 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 here 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 email in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: Margaria, Cyril (NSN - DE/Munich) [mailto:cyril.margaria@nsn.com] Sent: Wednesday, December 15, 2010 6:15 AM To: pce@ietf.org Cc: dhruvd@huawei.com; udayasreepalle@huawei.com; qzhao@huawei.com; daniel@olddog.co.uk; Sprecher, Nurit (NSN - IL/Hod HaSharon) Subject: RE: [Pce] Status of draft-dhody-pce-pcep-pathkey-mib-00 Hi Pcers, authors I have the following technical comments to the draft: - in current MIB described EROs or RROs (rfc3812, rfc4802) there is no representation of PKS, this should be added I believe. >>>>> I agree there is a need for PKS; but though this MIB will not directly use this object, is it correct to add in this document? We can discuss on this. - Several timers are defined in the draft, all of them use minutes, I think that using a textual convention for those (like the LmpInterval in RFC4631) would make the MIB more consistent. In addition I would think that protocol timers are usually using milliseconds as unit, Is there a specific reason to use minutes? >>>>> This is kept consistent with other PCEP MIB drafts. It can be taken up along with other PCEP MIB drafts. PCEP MIB draft uses "seconds"; we kept minutes to keep more readable and consistent with RFC. Once PCEP main MIB would follow a standard the same can be applied here. - pcePcepPathKeyReUseTimer : the minimum reuse time is equivalent to 30 minutes (RFC5520, section 2.1.), unit (I would propose ms) should be added. >>>>> Same as above. - pcePcepPathKeyConfig : - I believe MAX-ACCESS read-create make only sense for tables, not scalar. - the comment state that this is the configuration for inter-domain, is there a particular reason to restrict the PKS to inter domain?, if not remove the inter-domain reference would be more generic. >>>>> This is kept it consistent with PCEP MIB draft. Regarding use of "inter-domain"; path-key is applied only when we are sending path outside the domain. There is no impact on MIB either way. We can make it generic if needed. - pcePcepPathKeyPath : this is currently a string, to be consistent with exiting ERO representation I believe this should be a pointer to a HopTable, like the one in rfc3812 : mpls tunnel mib, mplsTunnelHopTable and rfc4802 : gmpls tunnel MIB gmplsTunnelHopTable. >>>>> We thought that use of HopTable is more useful in MPLS-TE MIB, where the Table exist in Ingress, Egress as well as on Transit Router Node. We wanted to have a simpler implementation like that of explicit path "mplsPathExplicitRoute" followed by some MIBs. Having HopTable would unnecessarily complicate the implementation. - pcePcepPathKeyRetrieveSource : only one entry here, but according to RFC5520, section 2.1. : " A local policy SHOULD be used to determine for how long to retain such stored information, and whether to discard the information after it has been queried using the procedures described below. It is RECOMMENDED for a PCE to store the PKS for a period of 10 minutes" As retention is allowed, more than one PCC (for diversity/route exclusion purpose for instance) could request a given PKS, so this should be a pointer to a table listing all the nodes that retrieved the PKS. >>>>> PathKey would be retrieved from a particular PCC which is the starting hop of the confidential path (CPS); we don't think a retrieval of the exact same path key would happen from multiple PCC, there would be different path-keys in that case. - pcePcepPathKeyReuseTime : - pcePcepPathKeyDiscardTime : is it a time, an absolute or relative time? Why are those object read-only, one could expect that the pcePcepPathKeyReUseTimer is the policy, but it could be overwritten on a individual PKS based >>>>> This is value based on the time the pathkey was generated; and overall time when a path-key can be reused "pcePcepPathKeyReUseTimer"; so we believe we cannot directly modify pcePcepPathKeyReuseTime values via MIB; this value can change based on the change on the above two parameters. - a pcePcepPathKeyCreationTime TimeStamp, would also be usefull I believe. >>>>> I agree, thanks, I will add this. - I am missing a row status, I think it should be possible to manually delete PKS, >>>>> I don't think we would have a case where path-key is either generated or deleted via MIB operation. What do others in WG think? Best Regards >>>>> I again thank you for the detailed reviews!!! > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of > ext Julien Meuric > Sent: Saturday, November 20, 2010 5:03 PM > To: pce@ietf.org > Subject: [Pce] Status of draft-dhody-pce-pcep-pathkey-mib-00 > > Hi all. > > During our meeting in Beijing, draft-dhody-pce-pcep-pathkey-mib was > presented. Not only defines this I-D a MIB module that is useful for > the path key mechanism, but also it adresses a requirement explicitly > stated in our standard track RFCs (RFC 5520), which means the item has > already been through IETF consensus. All the same, as said during the > meeting, if you have good reasons to be opposed to take it as WG item, > you still have a few days to speak before we move forward. > > As usual, technical discussion about the content of the I-D is still > very welcome. > > Regards, > > JP & Julien > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce --Boundary_(ID_lnUCSOD4u6pC7B+BLB3esA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Dear Cyril,

Thanks for your detailed review.

Please find my comments inline.

Regards,

Dhruv

Dhruv Dhody

Senior Technical Leader

Huawei-Santa Clara, CA

Work: (408) 330 4940

Cell: (408) 667 8127

This email and its 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 here 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 email in error, please notify the sender by phone or email immediately and delete it!

-----Original Message-----
From: Margaria, Cyril (NSN - DE/Munich) [mailto:cyril.margaria@nsn.com]
Sent: Wednesday, December 15, 2010 6:15 AM
To: pce@ietf.org
Cc: dhruvd@huawei.com; udayasreepalle@huawei.com; qzhao@huawei.com; daniel@olddog.co.uk; Sprecher, Nurit (NSN - IL/Hod HaSharon)
Subject: RE: [Pce] Status of draft-dhody-pce-pcep-pathkey-mib-00

Hi Pcers, authors

I have the following technical comments to the draft:

- in current MIB described EROs or RROs (rfc3812, rfc4802) there is no

representation of PKS, this should be added I believe.

>>>>> I agree there is a need for PKS; but though this MIB will not directly use this object, is it correct to add in this document? We can discuss on this.

- Several timers are defined in the draft, all of them use minutes,

I think that using a textual convention for those (like the

LmpInterval in RFC4631) would make the MIB more consistent.

In addition I would think that protocol timers are usually using

milliseconds as unit, Is there a specific reason to use minutes?

>>>>> This is kept consistent with other PCEP MIB drafts. It can be taken up along with other PCEP MIB drafts. PCEP MIB draft uses “seconds”; we kept minutes to keep more readable and consistent with RFC. Once PCEP main MIB would follow a standard the same can be applied here.

- pcePcepPathKeyReUseTimer : the minimum reuse time is equivalent to

30 minutes (RFC5520, section 2.1.), unit (I would propose ms) should be

added.

>>>>> Same as above.

- pcePcepPathKeyConfig :

      - I believe MAX-ACCESS read-create make only sense for tables,

not scalar.

      - the comment state that this is the configuration for

inter-domain, is there a particular reason to restrict the PKS to inter

domain?, if not remove the inter-domain reference would be more generic.

>>>>> This is kept it consistent with PCEP MIB draft. Regarding use of “inter-domain”; path-key is applied only when we are sending path outside the domain. There is no impact on MIB either way. We can make it generic if needed.

- pcePcepPathKeyPath : this is currently a string, to be consistent with

exiting ERO representation I believe this should be a pointer to a

HopTable, like the one in rfc3812 : mpls tunnel mib, mplsTunnelHopTable

and rfc4802 : gmpls tunnel MIB gmplsTunnelHopTable.

>>>>> We thought that use of HopTable is more useful in MPLS-TE MIB, where the Table exist in Ingress, Egress as well as on Transit Router Node. We wanted to have a simpler implementation like that of explicit path “mplsPathExplicitRoute” followed by some MIBs. Having HopTable would unnecessarily complicate the implementation.

- pcePcepPathKeyRetrieveSource : only one entry here, but according to

RFC5520, section 2.1. :

" A local policy SHOULD be used to determine for how long

to retain such stored information, and whether to discard the

information after it has been

queried using the procedures described below. It is RECOMMENDED for

a PCE to store the PKS for a period of 10 minutes"

As retention is allowed, more than one PCC (for diversity/route

exclusion purpose for instance) could request a given PKS, so this

should be a pointer to a table listing all the nodes that retrieved the

PKS.

>>>>> PathKey would be retrieved from a particular PCC which is the starting hop of the confidential path (CPS); we don’t think a retrieval of the exact same path key would happen from multiple PCC, there would be different path-keys in that case.

- pcePcepPathKeyReuseTime :

- pcePcepPathKeyDiscardTime : is it a time, an absolute or relative

time?

Why are those object read-only, one could expect that the

pcePcepPathKeyReUseTimer is the policy, but it could be overwritten on a

individual PKS based

>>>>> This is value based on the time the pathkey was generated; and overall time when a path-key can be reused “pcePcepPathKeyReUseTimer”; so we believe we cannot directly modify pcePcepPathKeyReuseTime values via MIB; this value can change based on the change on the above two parameters.

- a pcePcepPathKeyCreationTime TimeStamp, would also be usefull I

believe.

>>>>> I agree, thanks, I will add this.

- I am missing a row status, I think it should be possible to manually

delete PKS,

>>>>> I don’t think we would have a case where path-key is either generated or deleted via MIB operation. What do others in WG think?

Best Regards

>>>>> I again thank you for the detailed reviews!!!

> -----Original Message-----

> From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of

> ext Julien Meuric

> Sent: Saturday, November 20, 2010 5:03 PM

> To: pce@ietf.org

> Subject: [Pce] Status of draft-dhody-pce-pcep-pathkey-mib-00

>

> Hi all.

>

> During our meeting in Beijing, draft-dhody-pce-pcep-pathkey-mib was

> presented. Not only defines this I-D a MIB module that is useful for

> the path key mechanism, but also it adresses a requirement explicitly

> stated in our standard track RFCs (RFC 5520), which means the item has

> already been through IETF consensus. All the same, as said during the

> meeting, if you have good reasons to be opposed to take it as WG item,

> you still have a few days to speak before we move forward.

>

> As usual, technical discussion about the content of the I-D is still

> very welcome.

>

> Regards,

>

> JP & Julien

>

> _______________________________________________

> Pce mailing list

> Pce@ietf.org

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

--Boundary_(ID_lnUCSOD4u6pC7B+BLB3esA)-- From cyril.margaria@nsn.com Thu Dec 16 01:19:02 2010 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81C8A3A70BE for ; Thu, 16 Dec 2010 01:19:02 -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 9euT+CmquVYA for ; Thu, 16 Dec 2010 01:19:01 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id C233F3A70AA for ; Thu, 16 Dec 2010 01:19:00 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id oBG9G3hw010463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Dec 2010 10:20:41 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id oBG9DsZS016946; Thu, 16 Dec 2010 10:13:57 +0100 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Dec 2010 10:13:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Dec 2010 10:13:48 +0100 Message-ID: In-Reply-To: <002101cb9ca0$e9cae600$cf22c10a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Status of draft-dhody-pce-pcep-pathkey-mib-00 Thread-Index: AcuI03nWBKXrpI3XRkut0Q3TjKXxMATiJEtAAAwPMxAAHBQ0kA== References: <002101cb9ca0$e9cae600$cf22c10a@china.huawei.com> From: "Margaria, Cyril (NSN - DE/Munich)" To: "ext Dhruv Dhody" , X-OriginalArrivalTime: 16 Dec 2010 09:13:50.0668 (UTC) FILETIME=[8D9E48C0:01CB9D01] Cc: qzhao@huawei.com Subject: Re: [Pce] Status of draft-dhody-pce-pcep-pathkey-mib-00 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, 16 Dec 2010 09:19:02 -0000 Hi Dhruv,=20 Thanks for your prompt reply,=20 Please see inline > -----Original Message----- > From: ext Dhruv Dhody [mailto:dhruvd@huawei.com] > Sent: Wednesday, December 15, 2010 10:42 PM > To: Margaria, Cyril (NSN - DE/Munich); pce@ietf.org > Cc: udayasreepalle@huawei.com; qzhao@huawei.com; daniel@olddog.co.uk; > Sprecher, Nurit (NSN - IL/Hod HaSharon) > Subject: RE: [Pce] Status of draft-dhody-pce-pcep-pathkey-mib-00 >=20 > Dear Cyril, >=20 > Thanks for your detailed review. > Please find my comments inline. >=20 > Regards, > Dhruv >=20 > Dhruv Dhody > Senior Technical Leader > Huawei-Santa Clara, CA > Work: (408) 330 4940 > Cell: (408) 667 8127 >=20 > This email and its 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 here 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 email in error, please > notify the sender by phone or email immediately and delete it! >=20 > -----Original Message----- > From: Margaria, Cyril (NSN - DE/Munich) [mailto:cyril.margaria@nsn.com] > Sent: Wednesday, December 15, 2010 6:15 AM > To: pce@ietf.org > Cc: dhruvd@huawei.com; udayasreepalle@huawei.com; qzhao@huawei.com; > daniel@olddog.co.uk; Sprecher, Nurit (NSN - IL/Hod HaSharon) > Subject: RE: [Pce] Status of draft-dhody-pce-pcep-pathkey-mib-00 >=20 > Hi Pcers, authors >=20 > I have the following technical comments to the draft: >=20 > - in current MIB described EROs or RROs (rfc3812, rfc4802) there is no > representation of PKS, this should be added I believe. >=20 > >>>>> I agree there is a need for PKS; but though this MIB will not > directly use this object, is it correct to add in this document? We can > discuss on this. >=20 I think it should be added in another document, the GMPLS-TE-STD-MIB does not cover several objects, PKS being one of them (lsp attribute is also not covered). =20 >=20 > - pcePcepPathKeyConfig : > - I believe MAX-ACCESS read-create make only sense for tables, > not scalar. > - the comment state that this is the configuration for inter- > domain, is there a particular reason to restrict the PKS to inter > domain?, if not remove the inter-domain reference would be more > generic. >=20 > >>>>> This is kept it consistent with PCEP MIB draft. Regarding use of > "inter-domain"; path-key is applied only when we are sending path > outside the domain. There is no impact on MIB either way. We can make > it generic if needed. The intent of the PKS object is so, but strickly speaking it based on a policy, so non-inter domain is not forbidden. >=20 > - pcePcepPathKeyPath : this is currently a string, to be consistent > with exiting ERO representation I believe this should be a pointer to a > HopTable, like the one in rfc3812 : mpls tunnel mib, > mplsTunnelHopTable > and rfc4802 : gmpls tunnel MIB gmplsTunnelHopTable. >=20 > >>>>> We thought that use of HopTable is more useful in MPLS-TE MIB, > where the Table exist in Ingress, Egress as well as on Transit Router > Node. We wanted to have a simpler implementation like that of explicit > path "mplsPathExplicitRoute" followed by some MIBs. Having HopTable > would unnecessarily complicate the implementation. >=20 I think having a string open to the following problem: - arbitrary limit on the path=20 - what is the format?, per RFC5440 it can contain any object represented in a RSVP ERO, which can be: Unnumbered interface (lets say ip address in dotted format and a 0x%08x format) and forward and reverse label (max size:63*4)=20 printed in Hex -> string size is already 1035 : it cannot be represented in the existing string=20 - string parsing without well defined format is prone to have different representation and create parsing problem (already you can represent an Ipv4 address in dotted, hex, decimal, ... format) Its quite likely to have a control plane together with PCE for inter-domain provisioning, so an implementation for ARHop table on the agent and manager side is known. =20 > - pcePcepPathKeyRetrieveSource : only one entry here, but according to > RFC5520, section 2.1. : > " A local policy SHOULD be used to determine for how long > to retain such stored information, and whether to discard the > information after it has been > queried using the procedures described below. It is RECOMMENDED for > a PCE to store the PKS for a period of 10 minutes" >=20 > As retention is allowed, more than one PCC (for diversity/route > exclusion purpose for instance) could request a given PKS, so this > should be a pointer to a table listing all the nodes that retrieved the > PKS. >=20 > >>>>> PathKey would be retrieved from a particular PCC which is the > starting hop of the confidential path (CPS); we don't think a retrieval > of the exact same path key would happen from multiple PCC, there would > be different path-keys in that case. I would see the following scenario : a protecting LSP is starting in another domain, excluding the PKS of the working LSP, in that case you might have another client. This is conceptually not excluded. >=20 > - pcePcepPathKeyReuseTime : > - pcePcepPathKeyDiscardTime : is it a time, an absolute or relative > time? > Why are those object read-only, one could expect that the > pcePcepPathKeyReUseTimer is the policy, but it could be overwritten on > a individual PKS based >=20 > >>>>> This is value based on the time the pathkey was generated; and > overall time when a path-key can be reused "pcePcepPathKeyReUseTimer"; > so we believe we cannot directly modify pcePcepPathKeyReuseTime values > via MIB; this value can change based on the change on the above two > parameters. I understand a difference between the time the PKS is discarded and it can be reused, for instance it can be discarded after 10 minutes but cannot be reused before 30 minutes as stated in the PKS RFC. This indicate that they could be configured separately >=20 > - a pcePcepPathKeyCreationTime TimeStamp, would also be usefull I > believe. >=20 > >>>>> I agree, thanks, I will add this. >=20 > - I am missing a row status, I think it should be possible to manually > delete PKS, >=20 > >>>>> I don't think we would have a case where path-key is either > generated or deleted via MIB operation. What do others in WG think? >=20 >=20 > Best Regards >=20 > >>>>> I again thank you for the detailed reviews!!! >=20 > > -----Original Message----- > > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of > > ext Julien Meuric > > Sent: Saturday, November 20, 2010 5:03 PM > > To: pce@ietf.org > > Subject: [Pce] Status of draft-dhody-pce-pcep-pathkey-mib-00 > > > > Hi all. > > > > During our meeting in Beijing, draft-dhody-pce-pcep-pathkey-mib was > > presented. Not only defines this I-D a MIB module that is useful for > > the path key mechanism, but also it adresses a requirement explicitly > > stated in our standard track RFCs (RFC 5520), which means the item > has > > already been through IETF consensus. All the same, as said during the > > meeting, if you have good reasons to be opposed to take it as WG > item, > > you still have a few days to speak before we move forward. > > > > As usual, technical discussion about the content of the I-D is still > > very welcome. > > > > Regards, > > > > JP & Julien > > > > _______________________________________________ > > Pce mailing list > > Pce@ietf.org > > https://www.ietf.org/mailman/listinfo/pce > From dhruvd@huawei.com Thu Dec 16 11:13:14 2010 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE6493A69AF for ; Thu, 16 Dec 2010 11:13:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.494 X-Spam-Level: X-Spam-Status: No, score=-4.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, RCVD_IN_DNSWL_MED=-4, 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 sa95UpPuoFoK for ; Thu, 16 Dec 2010 11:13:02 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 1CC283A69A7 for ; Thu, 16 Dec 2010 11:13:02 -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 <0LDJ00GWPC4C1A@szxga04-in.huawei.com> for pce@ietf.org; Fri, 17 Dec 2010 03:14:37 +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 <0LDJ00E2YC4CBM@szxga04-in.huawei.com> for pce@ietf.org; Fri, 17 Dec 2010 03:14:36 +0800 (CST) Received: from Htiplqw12q ([10.193.34.207]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LDJ008ZZC43LO@szxml06-in.huawei.com> for pce@ietf.org; Fri, 17 Dec 2010 03:14:36 +0800 (CST) Date: Thu, 16 Dec 2010 11:14:26 -0800 From: Dhruv Dhody In-reply-to: To: "'Margaria, Cyril (NSN - DE/Munich)'" , pce@ietf.org Message-id: <000701cb9d55$76f1a500$cf22c10a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_sM8BJbBlP8B/qJ6x6Dvrvg)" Thread-index: AcuI03nWBKXrpI3XRkut0Q3TjKXxMATiJEtAAAwPMxAAHBQ0kAAU1Hgw Cc: qzhao@huawei.com Subject: Re: [Pce] Status of draft-dhody-pce-pcep-pathkey-mib-00 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, 16 Dec 2010 19:13:14 -0000 This is a multi-part message in MIME format. --Boundary_(ID_sM8BJbBlP8B/qJ6x6Dvrvg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear Cyril, It's great that we are having a discussion on this. See my replies inline, look for # Dhruv #. Regards, Dhruv Dhruv Dhody Senior Technical Leader Huawei-Santa Clara, CA Work: (408) 330 4940 Cell: (408) 667 8127 This email and its 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 here 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 email in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: Margaria, Cyril (NSN - DE/Munich) [mailto:cyril.margaria@nsn.com] Sent: Thursday, December 16, 2010 1:14 AM To: ext Dhruv Dhody; pce@ietf.org Cc: udayasreepalle@huawei.com; qzhao@huawei.com; daniel@olddog.co.uk; Sprecher, Nurit (NSN - IL/Hod HaSharon) Subject: RE: [Pce] Status of draft-dhody-pce-pcep-pathkey-mib-00 Hi Dhruv, Thanks for your prompt reply, Please see inline > -----Original Message----- > From: ext Dhruv Dhody [mailto:dhruvd@huawei.com] > Sent: Wednesday, December 15, 2010 10:42 PM > To: Margaria, Cyril (NSN - DE/Munich); pce@ietf.org > Cc: udayasreepalle@huawei.com; qzhao@huawei.com; daniel@olddog.co.uk; > Sprecher, Nurit (NSN - IL/Hod HaSharon) > Subject: RE: [Pce] Status of draft-dhody-pce-pcep-pathkey-mib-00 > > Dear Cyril, > > Thanks for your detailed review. > Please find my comments inline. > > Regards, > Dhruv > > Dhruv Dhody > Senior Technical Leader > Huawei-Santa Clara, CA > Work: (408) 330 4940 > Cell: (408) 667 8127 > > This email and its 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 here 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 email in error, please > notify the sender by phone or email immediately and delete it! > > -----Original Message----- > From: Margaria, Cyril (NSN - DE/Munich) [mailto:cyril.margaria@nsn.com] > Sent: Wednesday, December 15, 2010 6:15 AM > To: pce@ietf.org > Cc: dhruvd@huawei.com; udayasreepalle@huawei.com; qzhao@huawei.com; > daniel@olddog.co.uk; Sprecher, Nurit (NSN - IL/Hod HaSharon) > Subject: RE: [Pce] Status of draft-dhody-pce-pcep-pathkey-mib-00 > > Hi Pcers, authors > > I have the following technical comments to the draft: > > - in current MIB described EROs or RROs (rfc3812, rfc4802) there is no > representation of PKS, this should be added I believe. > > >>>>> I agree there is a need for PKS; but though this MIB will not > directly use this object, is it correct to add in this document? We can > discuss on this. > I think it should be added in another document, the GMPLS-TE-STD-MIB does not cover several objects, PKS being one of them (lsp attribute is also not covered). > > - pcePcepPathKeyConfig : > - I believe MAX-ACCESS read-create make only sense for tables, > not scalar. > - the comment state that this is the configuration for inter- > domain, is there a particular reason to restrict the PKS to inter > domain?, if not remove the inter-domain reference would be more > generic. > > >>>>> This is kept it consistent with PCEP MIB draft. Regarding use of > "inter-domain"; path-key is applied only when we are sending path > outside the domain. There is no impact on MIB either way. We can make > it generic if needed. The intent of the PKS object is so, but strickly speaking it based on a policy, so non-inter domain is not forbidden. > > - pcePcepPathKeyPath : this is currently a string, to be consistent > with exiting ERO representation I believe this should be a pointer to a > HopTable, like the one in rfc3812 : mpls tunnel mib, > mplsTunnelHopTable > and rfc4802 : gmpls tunnel MIB gmplsTunnelHopTable. > > >>>>> We thought that use of HopTable is more useful in MPLS-TE MIB, > where the Table exist in Ingress, Egress as well as on Transit Router > Node. We wanted to have a simpler implementation like that of explicit > path "mplsPathExplicitRoute" followed by some MIBs. Having HopTable > would unnecessarily complicate the implementation. > I think having a string open to the following problem: - arbitrary limit on the path - what is the format?, per RFC5440 it can contain any object represented in a RSVP ERO, which can be: Unnumbered interface (lets say ip address in dotted format and a 0x%08x format) and forward and reverse label (max size:63*4) printed in Hex -> string size is already 1035 : it cannot be represented in the existing string - string parsing without well defined format is prone to have different representation and create parsing problem (already you can represent an Ipv4 address in dotted, hex, decimal, ... format) Its quite likely to have a control plane together with PCE for inter-domain provisioning, so an implementation for ARHop table on the agent and manager side is known. # Dhruv # : We have two option, (1) Keep string but define parsing rules for all possible cases; (2) follow the MIB design for HopTable followed by MPLS-TE. But we should keep in mind the use-case of these two MIBs are different. For PathKey once a PathKey and Confidential Path Segment are generated the Hops will not be modified at all, which is not the case for MPLS-TE-MIB. What is the opinion of others in WG on this? > - pcePcepPathKeyRetrieveSource : only one entry here, but according to > RFC5520, section 2.1. : > " A local policy SHOULD be used to determine for how long > to retain such stored information, and whether to discard the > information after it has been > queried using the procedures described below. It is RECOMMENDED for > a PCE to store the PKS for a period of 10 minutes" > > As retention is allowed, more than one PCC (for diversity/route > exclusion purpose for instance) could request a given PKS, so this > should be a pointer to a table listing all the nodes that retrieved the > PKS. > > >>>>> PathKey would be retrieved from a particular PCC which is the > starting hop of the confidential path (CPS); we don't think a retrieval > of the exact same path key would happen from multiple PCC, there would > be different path-keys in that case. I would see the following scenario : a protecting LSP is starting in another domain, excluding the PKS of the working LSP, in that case you might have another client. This is conceptually not excluded. # Dhruv # : I am working under the assumption that PathKey will be expanded only during the signaling (RSVP); so in case of primary or backup, PathKey will always be expanded by the Boundary Node which is also the starting point of the CPS. Can others in WG comment on this. MIB can be extended if there is a use-case for the scenario mentioned by Cyril. > > - pcePcepPathKeyReuseTime : > - pcePcepPathKeyDiscardTime : is it a time, an absolute or relative > time? > Why are those object read-only, one could expect that the > pcePcepPathKeyReUseTimer is the policy, but it could be overwritten on > a individual PKS based > > >>>>> This is value based on the time the pathkey was generated; and > overall time when a path-key can be reused "pcePcepPathKeyReUseTimer"; > so we believe we cannot directly modify pcePcepPathKeyReuseTime values > via MIB; this value can change based on the change on the above two > parameters. I understand a difference between the time the PKS is discarded and it can be reused, for instance it can be discarded after 10 minutes but cannot be reused before 30 minutes as stated in the PKS RFC. This indicate that they could be configured separately # Dhruv # : The global Timers pcePcepPathKeyDiscardTimer (10) pcePcepPathKeyReUseTimer (30) can be modified and are not read-only in the MIB. But the objects which are in the PathKey table [PKS - CPS] - pcePcepPathKeyReuseTime are the value at real-time based on when the PathKey was generated and what is the value of the global timers and thus is always read only. > > - a pcePcepPathKeyCreationTime TimeStamp, would also be usefull I > believe. > > >>>>> I agree, thanks, I will add this. > > - I am missing a row status, I think it should be possible to manually > delete PKS, > > >>>>> I don't think we would have a case where path-key is either > generated or deleted via MIB operation. What do others in WG think? > > > Best Regards > > >>>>> I again thank you for the detailed reviews!!! > > > -----Original Message----- > > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of > > ext Julien Meuric > > Sent: Saturday, November 20, 2010 5:03 PM > > To: pce@ietf.org > > Subject: [Pce] Status of draft-dhody-pce-pcep-pathkey-mib-00 > > > > Hi all. > > > > During our meeting in Beijing, draft-dhody-pce-pcep-pathkey-mib was > > presented. Not only defines this I-D a MIB module that is useful for > > the path key mechanism, but also it adresses a requirement explicitly > > stated in our standard track RFCs (RFC 5520), which means the item > has > > already been through IETF consensus. All the same, as said during the > > meeting, if you have good reasons to be opposed to take it as WG > item, > > you still have a few days to speak before we move forward. > > > > As usual, technical discussion about the content of the I-D is still > > very welcome. > > > > Regards, > > > > JP & Julien > > > > _______________________________________________ > > Pce mailing list > > Pce@ietf.org > > https://www.ietf.org/mailman/listinfo/pce > --Boundary_(ID_sM8BJbBlP8B/qJ6x6Dvrvg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Dear Cyril,

It’s great that we are having a discussion on this.

See my replies inline, look for # Dhruv #.

Regards,

Dhruv

Dhruv Dhody

Senior Technical Leader

Huawei-Santa Clara, CA

Work: (408) 330 4940

Cell: (408) 667 8127

This email and its 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 here 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 email in error, please notify the sender by phone or email immediately and delete it!

-----Original Message-----
From: Margaria, Cyril (NSN - DE/Munich) [mailto:cyril.margaria@nsn.com]
Sent: Thursday, December 16, 2010 1:14 AM
To: ext Dhruv Dhody; pce@ietf.org
Cc: udayasreepalle@huawei.com; qzhao@huawei.com; daniel@olddog.co.uk; Sprecher, Nurit (NSN - IL/Hod HaSharon)
Subject: RE: [Pce] Status of draft-dhody-pce-pcep-pathkey-mib-00

Hi Dhruv,

Thanks for your prompt reply,

Please see inline

> -----Original Message-----

> From: ext Dhruv Dhody [mailto:dhruvd@huawei.com]

> Sent: Wednesday, December 15, 2010 10:42 PM

> To: Margaria, Cyril (NSN - DE/Munich); pce@ietf.org

> Cc: udayasreepalle@huawei.com; qzhao@huawei.com; daniel@olddog.co.uk;

> Sprecher, Nurit (NSN - IL/Hod HaSharon)

> Subject: RE: [Pce] Status of draft-dhody-pce-pcep-pathkey-mib-00

>

> Dear Cyril,

>

> Thanks for your detailed review.

> Please find my comments inline.

>

> Regards,

> Dhruv

>

> Dhruv Dhody

> Senior Technical Leader

> Huawei-Santa Clara, CA

> Work: (408) 330 4940

> Cell: (408) 667 8127

>

> This email and its 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 here 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 email in error, please

> notify the sender by phone or email immediately and delete it!

>

> -----Original Message-----

> From: Margaria, Cyril (NSN - DE/Munich)

[mailto:cyril.margaria@nsn.com]

> Sent: Wednesday, December 15, 2010 6:15 AM

> To: pce@ietf.org

> Cc: dhruvd@huawei.com; udayasreepalle@huawei.com; qzhao@huawei.com;

> daniel@olddog.co.uk; Sprecher, Nurit (NSN - IL/Hod HaSharon)

> Subject: RE: [Pce] Status of draft-dhody-pce-pcep-pathkey-mib-00

>

> Hi Pcers, authors

>

> I have the following technical comments to the draft:

>

> - in current MIB described EROs or RROs (rfc3812, rfc4802) there is no

> representation of PKS, this should be added I believe.

>

> >>>>> I agree there is a need for PKS; but though this MIB will not

> directly use this object, is it correct to add in this document? We

can

> discuss on this.

>

I think it should be added in another document, the GMPLS-TE-STD-MIB

does not cover several objects, PKS being one of them (lsp attribute is

also not covered).

<cut timers>

>

> - pcePcepPathKeyConfig :

>       - I believe MAX-ACCESS read-create make only sense for tables,

> not scalar.

>       - the comment state that this is the configuration for inter-

> domain, is there a particular reason to restrict the PKS to inter

> domain?, if not remove the inter-domain reference would be more

> generic.

>

> >>>>> This is kept it consistent with PCEP MIB draft. Regarding use of

> "inter-domain"; path-key is applied only when we are sending path

> outside the domain. There is no impact on MIB either way. We can make

> it generic if needed.

The intent of the PKS object is so, but strickly speaking it based on a

policy, so non-inter domain is not forbidden.

>

> - pcePcepPathKeyPath : this is currently a string, to be consistent

> with exiting ERO representation I believe this should be a pointer to

a

> HopTable, like the one in rfc3812 : mpls tunnel mib,

> mplsTunnelHopTable

> and rfc4802 : gmpls tunnel MIB gmplsTunnelHopTable.

>

> >>>>> We thought that use of HopTable is more useful in MPLS-TE MIB,

> where the Table exist in Ingress, Egress as well as on Transit Router

> Node. We wanted to have a simpler implementation like that of explicit

> path "mplsPathExplicitRoute" followed by some MIBs. Having HopTable

> would unnecessarily complicate the implementation.

>

I think having a string open to the following problem:

      - arbitrary limit on the path

      - what is the format?, per RFC5440 it can contain any object

represented in a RSVP ERO, which can be:

            Unnumbered interface (lets say ip address in dotted

format and a 0x%08x format) and forward and reverse label (max

size:63*4)

             printed in Hex -> string size is already 1035 : it cannot

be represented in the existing string

      - string parsing without well defined format is prone to have

different representation and create parsing problem (already you can

represent an Ipv4 address in dotted, hex, decimal, ... format)

Its quite likely to have a control plane together with PCE for

inter-domain provisioning, so an implementation for ARHop table on the

agent and manager side is known.

# Dhruv # : We have two option, (1) Keep string but define parsing rules for all possible cases; (2) follow the MIB design for HopTable followed by MPLS-TE. But we should keep in mind the use-case of these two MIBs are different. For PathKey once a PathKey and Confidential Path Segment are generated the Hops will not be modified at all, which is not the case for MPLS-TE-MIB. What is the opinion of others in WG on this?

> - pcePcepPathKeyRetrieveSource : only one entry here, but according to

> RFC5520, section 2.1. :

> " A local policy SHOULD be used to determine for how long

>   to retain such stored information, and whether to discard the

> information after it has been

>   queried using the procedures described below. It is RECOMMENDED for

>   a PCE to store the PKS for a period of 10 minutes"

>

> As retention is allowed, more than one PCC (for diversity/route

> exclusion purpose for instance) could request a given PKS, so this

> should be a pointer to a table listing all the nodes that retrieved

the

> PKS.

>

> >>>>> PathKey would be retrieved from a particular PCC which is the

> starting hop of the confidential path (CPS); we don't think a

retrieval

> of the exact same path key would happen from multiple PCC, there would

> be different path-keys in that case.

I would see the following scenario : a protecting LSP is starting in

another domain, excluding the PKS of the working LSP, in that case you

might have another client. This is conceptually not excluded.

# Dhruv # : I am working under the assumption that PathKey will be expanded only during the signaling (RSVP); so in case of primary or backup, PathKey will always be expanded by the Boundary Node which is also the starting point of the CPS. Can others in WG comment on this. MIB can be extended if there is a use-case for the scenario mentioned by Cyril.

>

> - pcePcepPathKeyReuseTime :

> - pcePcepPathKeyDiscardTime : is it a time, an absolute or relative

> time?

> Why are those object read-only, one could expect that the

> pcePcepPathKeyReUseTimer is the policy, but it could be overwritten on

> a individual PKS based

>

> >>>>> This is value based on the time the pathkey was generated; and

> overall time when a path-key can be reused "pcePcepPathKeyReUseTimer";

> so we believe we cannot directly modify pcePcepPathKeyReuseTime values

> via MIB; this value can change based on the change on the above two

> parameters.

I understand a difference between the time the PKS is discarded and it

can be reused, for instance it can be discarded after 10 minutes but

cannot be reused before 30 minutes as stated in the PKS RFC. This

indicate that they could be configured separately

# Dhruv # : The global Timers pcePcepPathKeyDiscardTimer (10) pcePcepPathKeyReUseTimer (30) can be modified and are not read-only in the MIB. But the objects which are in the PathKey table [PKS - CPS] – pcePcepPathKeyReuseTime are the value at real-time based on when the PathKey was generated and what is the value of the global timers and thus is always read only.

>

> - a pcePcepPathKeyCreationTime TimeStamp, would also be usefull I

> believe.

>

> >>>>> I agree, thanks, I will add this.

>

> - I am missing a row status, I think it should be possible to manually

> delete PKS,

>

> >>>>> I don't think we would have a case where path-key is either

> generated or deleted via MIB operation. What do others in WG think?

>

>

> Best Regards

>

> >>>>> I again thank you for the detailed reviews!!!

>

> > -----Original Message-----

> > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf

Of

> > ext Julien Meuric

> > Sent: Saturday, November 20, 2010 5:03 PM

> > To: pce@ietf.org

> > Subject: [Pce] Status of draft-dhody-pce-pcep-pathkey-mib-00

> >

> > Hi all.

> >

> > During our meeting in Beijing, draft-dhody-pce-pcep-pathkey-mib was

> > presented. Not only defines this I-D a MIB module that is useful for

> > the path key mechanism, but also it adresses a requirement

explicitly

> > stated in our standard track RFCs (RFC 5520), which means the item

> has

> > already been through IETF consensus. All the same, as said during

the

> > meeting, if you have good reasons to be opposed to take it as WG

> item,

> > you still have a few days to speak before we move forward.

> >

> > As usual, technical discussion about the content of the I-D is still

> > very welcome.

> >

> > Regards,

> >

> > JP & Julien

> >

> > _______________________________________________

> > Pce mailing list

> > Pce@ietf.org

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

>

--Boundary_(ID_sM8BJbBlP8B/qJ6x6Dvrvg)-- From lberger@labn.net Thu Dec 23 10:47:00 2010 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F131F3A685E for ; Thu, 23 Dec 2010 10:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.072 X-Spam-Level: X-Spam-Status: No, score=-102.072 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 f8yuVO1d8WKo for ; Thu, 23 Dec 2010 10:46:59 -0800 (PST) Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by core3.amsl.com (Postfix) with SMTP id 9E4113A683C for ; Thu, 23 Dec 2010 10:46:59 -0800 (PST) Received: (qmail 14013 invoked by uid 0); 23 Dec 2010 18:49:00 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy2.bluehost.com with SMTP; 23 Dec 2010 18:49:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=L15xOHDp6Rapi/YkAi/R9iO/AvAXA8kUFN5pL9HUFYd3desa47h7Oy8zkvR5u0guYQ/LRPUwCDFU2rVwcE3O1nzI58Zt5d8i1ukaDBWLKt/jMXRCmcj/P9kAeLH6O7Xk; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1PVqDk-0007G7-G1 for pce@ietf.org; Thu, 23 Dec 2010 11:49:00 -0700 Message-ID: <4D13999D.2020806@labn.net> Date: Thu, 23 Dec 2010 13:49:01 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: pce@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [Pce] Fwd: [CCAMP] 2nd WG LC on draft-ietf-ccamp-rwa-wson-framework 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, 23 Dec 2010 18:47:01 -0000 FYI - some of the consistency changes may be of interest to those working on PCE(P) for WSON. Note LC call comments should go to the ccamp list. Lou -------- Original Message -------- Subject: [CCAMP] 2nd WG LC on draft-ietf-ccamp-rwa-wson-framework Date: Thu, 23 Dec 2010 09:58:29 -0500 From: Lou Berger To: CCAMP All, This mail begins a second working group last call on: http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-framework-08. The last call ends on January 7th (slight extension due to holidays.) Note this second last call is being held due to the changes in the draft since it was (1st) last called. The authors have provided a summary of changes in: http://www.ietf.org/mail-archive/web/ccamp/current/msg11765.html LC reviews/comments should focus on the modified text. Please send your comments to the CCAMP mailing list. Lou (and Deborah) _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp