From nobody Fri Aug 1 02:02:24 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F921A03E9 for ; Fri, 1 Aug 2014 02:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.285 X-Spam-Level: X-Spam-Status: No, score=-0.285 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtSCaJipXEMf for ; Fri, 1 Aug 2014 02:02:18 -0700 (PDT) Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id B46381A03DF for ; Fri, 1 Aug 2014 02:02:17 -0700 (PDT) Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 376DBDE4004; Fri, 1 Aug 2014 11:02:16 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.orange.com (Postfix) with ESMTP id 246E0DE4002; Fri, 1 Aug 2014 11:02:16 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Aug 2014 11:02:16 +0200 Received: from [10.193.71.122] ([10.193.71.122]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Aug 2014 11:02:15 +0200 Message-ID: <53DB5796.8080502@orange.com> Date: Fri, 01 Aug 2014 11:02:14 +0200 From: Julien Meuric Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Leeyoung , "draft-ietf-pce-wson-routing-wavelength@tools.ietf.org" References: <7AEB3D6833318045B4AE71C2C87E8E1729BE1B9D@dfweml706-chm.china.huawei.com> <53DA322B.1070702@orange.com> <7AEB3D6833318045B4AE71C2C87E8E1729C07A7A@dfweml706-chm.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C07A7A@dfweml706-chm.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Aug 2014 09:02:15.0452 (UTC) FILETIME=[4A29BDC0:01CFAD67] Archived-At: http://mailarchive.ietf.org/arch/msg/pce/JLs2L5d5Eaj4zQdIchGVIPRguJ0 Cc: "pce@ietf.org" Subject: Re: [Pce] FW: I-D Action: draft-ietf-pce-wson-routing-wavelength-12.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 09:02:22 -0000 Hi Young. Thank you for the update. I think I can live with the "Re-optimize" phrase as it is. Just a few remaining nits: - still some double spacing - s/PCE-based Architecture/PCE-based architecture/ - s/network.The PCE/network. The PCE/ - s/constraining the path to have/constraining the paths to have/ [my mistake!] It looks like version 13 will be ready to move forward. Thanks Julien Jul. 31, 2014 - Leeyoung: > Hi Julien, > > All your comments have been reflected in the revision except: > > Section 3.4. > --- > - The phrase "b. Re-optimize wavelength(s)" reads odd, what about rephrasing into "b. Re-consider wavelength(s) allocation"? > > I think Re-optimize is meant to include wavelength(s) re-allocation as well as path changes. I would leave the phrase as is. > > Attached are the idnits report and the working version (v.13). Let me know if this version satisfies you and if I should publish this. > > Thanks, > Young > > -----Original Message----- > From: Julien Meuric [mailto:julien.meuric@orange.com] > Sent: Thursday, July 31, 2014 7:10 AM > > Hi Young and WSON co-authors. > > As part of the shepherding of the WSON requirement draft, please find below some comments to address before sending to the IESG. > > Regards, > > Julien > > > ---------- > Globally, the way the top-level section titles are indented creates troubles to IETF tools, including idnits. Please remove spacing before these section header, from 1. to 8. > --- > Along the document, unnecessary double spacing happens multiple times, especially after periods. Please clean them up. > --------- > In the header, could you compact the author list by removing blank lines? > --------- > s/described in RFC-2119 0./described in [RFC2119]./ > --------- > Abstract > --- > It is better when the abstract appears on the 1st page: please move it before "Status of this Memo". > --- > s/for Optical impairments/for optical impairments/ > --------- > Section 1. > --- > - s/PCE based Architecture/PCE-based architecture/ > - s/Generalized MPLS (GMPLS) networks/Generalized MPLS (GMPLS)-controlled networks/ > - s/Optical Switching Element/optical switching element/ > - s/communications Protocol/communication Protocol/ > - s/WDM based optical networks/WDM-based optical networks/ > - A paragraph break right before "A transparent optical network" would be appreciated. > - s/its route from/its path from/ > - s/due to their relatively high cost/for cost reasons/ > - s/all lightpath computation/all lightpath computations/ > - s/for Optical impairments/for optical impairments/ > --------- > Section 2. > --- > - s/in 0./in Figure 1./ > - At the end of Figure 1's title, I would remove the period, to be consistent with Figure 2. > - The DWA case is actually a sub-case of "separate processes", replacing > (c) by (b') would to the trick. > - To glue the text to the figure, 1./2./3. before paragraphs should be replaced by (a)/(b)/(b'). > - NEW last sentence in (b'): "This alternative is a particular case of > R+WA, it should be covered by GMPLS PCEP extensions and does not present > new WSON-specific requirements" [beware of the hyphen] > - s/PCE based implementation/PCE-based implementation/ > --------- > Section 3.1. > --- > - Starting with "1." leads to look for "2.", which does not exist: it would ease reading to drop "1." and start directly with "A PCEP request..." > - I would remove the "or" at the end of the line (i). > - Trailing text of (i) and (ii) should be aligned. > --------- > Section 3.2. > --- > - Trailing text of (i) and (ii) should be aligned. > - s/in R+WA or DWA/in R+WA or R+DWA/ > - s/assigned to the route/assigned to the path/ > - s/Label Sets/label set/ > - s/no route/no path/ > --------- > Section 3.3. > --- > - Before the 2 listed requirements, I suggest to add this NEW text: > "Sending simultaneous path requests for "routing only" computation is supported by PCEP specification [RFC 5440]. To remain consistent, the following requirements are added." > - s/the route and wavelength assigned to the route for each/the path and the assigned wavelength for each/ > --------- > Section 3.4. > --- > - The phrase "b. Re-optimize wavelength(s)" reads odd, what about rephrasing into "b. Re-consider wavelength(s) allocation"? > - s/both wavelength and the path/both the wavelength and the path/ > - s/no route/no path/ > - s/both route and wavelength/both path and wavelength/ > --------- > Section 3.5. > --- > - s/assigned wavelenght/assigned wavelength/ > - s/Explicit Label or Label Sets/explicit label or label set/ > - s/is NOT required/is not required/ > - The "3.6." string and paragraph break has scrambled the last lines of the section > - s/or an policy based/or a policy-based/ > --------- > Section 3.6. > --- > - Fix the section header (as mentioned above) > - s/for (E.g., random assignment, descending order, ascending order, etc.)/for, e.g., random assignment, descending order, ascending order, etc./ > --- > OLD: > " 2. A request for 2 or more paths (e.g., 1+1 link disjoint paths) MUST > be able to specify an option constraining the path to have the > same wavelength(s) assigned. > > Note that this is extremely useful in the case of protection with > single transponder." > NEW: > "2. A request for two or more paths MUST be able to include an option constraining the path to have the same wavelength(s) assigned. This is useful in the case of protection with single transponder (e.g., 1+1 link-disjoint paths)." > --- > - s/contiguous wavelength/continuous wavelength/ > - s/to constrain the wavelength continuity/to specify the precedence of wavelength continuity/ > --------- > Section 3.7. > --- > - s/or any given links/or on any given links/ > --------- > Section 4.5. > --- > Not clear if it is a misplaced requirement or a nice-to-have idea. I suggest replacing the sentence by the following NEW text: > "If PCE discovery mechanisms ([RFC5089] and [RFC5088]) were to be extended for technology-specific capabilities, advertising WSON RWA path computation capability should be considered." > --------- > Section 8. > --- > - RFCs 3471, 3473 and 6566 are note mentioned in the body of the I-D and should be dropped. > - RFC 4003 is missing and should be added to informative documents. > - RFC 4657 and PCEP-MIB should be moved from normative to informative (no need to read them to understand your I-D). > ----THE END----- > > > > Apr. 28, 2014 - Leeyoung: >> Hi Julien, >> >> This update reflects all the comments received from Cyril and Ramon as part of the WG LC. >> >> Cyril, please let the WG know if this update satisfies your comment. >> >> Best Regards, >> Young >> >> -----Original Message----- >> From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: Monday, April 28, 2014 11:29 AM >> >> 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 : PCEP Requirements for WSON Routing and Wavelength Assignment >> Authors : Young Lee >> Greg Bernstein >> Jonas Martensson >> Tomonori Takeda >> Takehiro Tsuritani >> Oscar Gonzalez de Dios >> Filename : draft-ietf-pce-wson-routing-wavelength-12.txt >> Pages : 14 >> Date : 2014-04-28 >> >> Abstract: >> This memo provides application-specific requirements for the Path >> Computation Element communication Protocol (PCEP) for the support of >> Wavelength Switched Optical Networks (WSON). Lightpath provisioning >> in WSONs requires a routing and wavelength assignment (RWA) process. >> From a path computation perspective, wavelength assignment is the >> process of determining which wavelength can be used on each hop of a >> path and forms an additional routing constraint to optical light >> path computation. Requirements for Optical impairments will be >> addressed in a separate document. >> >> >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-pce-wson-routing-wavelengt >> h/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-pce-wson-routing-wavelength-12 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-wson-routing-wavelengt >> h-12 >> >> >> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> Pce mailing list >> Pce@ietf.org >> https://www.ietf.org/mailman/listinfo/pce >> From nobody Fri Aug 1 07:18:59 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57BD11A0067 for ; Fri, 1 Aug 2014 07:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.885 X-Spam-Level: X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbLTbnX6YpQZ for ; Fri, 1 Aug 2014 07:18:56 -0700 (PDT) Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6BB1B27A0 for ; Fri, 1 Aug 2014 07:18:54 -0700 (PDT) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 64A5C5D8BA6; Fri, 1 Aug 2014 16:18:52 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.orange.com (Postfix) with ESMTP id 59EF95D8B0E; Fri, 1 Aug 2014 16:18:52 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Aug 2014 16:18:52 +0200 Received: from [10.193.71.122] ([10.193.71.122]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Aug 2014 16:18:52 +0200 Message-ID: <53DBA1CB.9080109@orange.com> Date: Fri, 01 Aug 2014 16:18:51 +0200 From: Julien Meuric Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Dhruv Dhody References: <23CE718903A838468A8B325B80962F9B865B4669@szxeml556-mbs.china.huawei.com> In-Reply-To: <23CE718903A838468A8B325B80962F9B865B4669@szxeml556-mbs.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Aug 2014 14:18:52.0238 (UTC) FILETIME=[85213EE0:01CFAD93] Archived-At: http://mailarchive.ietf.org/arch/msg/pce/8xydkchJMPLSExwQUGd4srWR2EI Cc: "pce@ietf.org" Subject: Re: [Pce] Regarding draft-ietf-pce-pcep-mib-09 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 14:18:58 -0000 Hi Dhruv. Just to be sure we're on the same page: the WG LC on this I-D ended on March, 31! All the same, your comments can be taken into account "before or alongside" the IETF LC (it's up to the editors). Thanks for your review, Julien Jul. 31, 2014 - Dhruv Dhody: > Hi Authors, > > I re-read the MIB document in preparation for the last call. > You may consider these comments/nits before or alongside the WG last call. > > - General > ~ Expand PCReq, PCRep, PCNtf, SVEC, RP etc on first use, using terminology > Section may also be useful. > ~ PCEP speaker and PCEP entity are used interchangeably, perhaps we can > unify? > ~ a new object for corrupted messages (note that corrupted messages are > different from unknown messages and this cannot be derived from number of > error messages sent either). > > - Abstract > Add MIB as the abbreviation > > - Introduction > Add TE as the abbreviation for Traffic Engineering > > - Shouldn't Section 3 'Requirements Language' about RFC2119 keywords > be part of the introduction itself? > > - Section 5.1 > pcePcepEntityEntry OBJECT-TYPE > SYNTAX PcePcepEntityEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An entry in this table represents a PCEP entity." > INDEX { pcePcepEntityIndex } > ::= { pcePcepEntityTable 1 } > > ~ I think the description should not say 'this table' while describing > an entry. Also true for pcePcepSessEntry. > > pcePcepEntityIndex OBJECT-TYPE > SYNTAX Unsigned32 (1..2147483647) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This index is used to uniquely identify the PCEP entity." > ::= { pcePcepEntityEntry 1 } > > ~ Wouldnt Integer32 (1..2147483647) be a better fit? > > Suggest to reorder pcePcepEntityMaxKeepAliveTimer, > pcePcepEntityMaxDeadTimer, pcePcepEntityAllowNegotiation, > pcePcepEntityMinKeepAliveTimer, pcePcepEntityMinDeadTimer > > ~ by moving the pcePcepEntityAllowNegotiation first, you can use it in > the description for both max and min timers. > > pcePcepEntitySyncTimer OBJECT-TYPE > SYNTAX Unsigned32 (1..65535) > UNITS "seconds" > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value of SYNC timer is used in the case of synchronized > path computation request using the SVEC object... > > ~ Use SyncTimer (as used in 5440) instead of SYNC timer. > > pcePcepPeerNumSessSetupFail OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of PCEP sessions with the peer that have been > attempted but failed before being fully estbalished. > This counter is incremented each time a session with this > peer fails before reaching session state pceSessionUp." > ::= { pcePcepPeerEntry 8 } > > ~ the state is called sessionUp (refer pcePcepSessState) and not > pceSessionUp > > - Security Considerations > You might think of removing the text about SET operation, as this > MIB is read-only. > > You might also add reference to SNMPv3 security like USM with AES as > well to use of secure transport like SSH or TLS/DTLS. > > Thank You! > > Dhruv > > > > > > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > From nobody Fri Aug 1 08:27:57 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C0D1B27C3 for ; Fri, 1 Aug 2014 08:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, J_CHICKENPOX_12=0.6, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JitQtAZ0lelH for ; Fri, 1 Aug 2014 08:27:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 975F91B27C6 for ; Fri, 1 Aug 2014 08:27:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKU30058; Fri, 01 Aug 2014 15:27:50 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 1 Aug 2014 16:27:49 +0100 Received: from DFWEML706-CHM.china.huawei.com ([169.254.8.145]) by dfweml702-chm.china.huawei.com ([169.254.4.217]) with mapi id 14.03.0158.001; Fri, 1 Aug 2014 08:27:48 -0700 From: Leeyoung To: Julien Meuric , "draft-ietf-pce-wson-routing-wavelength@tools.ietf.org" Thread-Topic: FW: [Pce] I-D Action: draft-ietf-pce-wson-routing-wavelength-12.txt Thread-Index: AQHPrLh1kRsocOEwpkCLJW3NAlAntpu6o7awgAFGxAD///XcoA== Date: Fri, 1 Aug 2014 15:27:47 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C07DCB@dfweml706-chm.china.huawei.com> References: <7AEB3D6833318045B4AE71C2C87E8E1729BE1B9D@dfweml706-chm.china.huawei.com> <53DA322B.1070702@orange.com> <7AEB3D6833318045B4AE71C2C87E8E1729C07A7A@dfweml706-chm.china.huawei.com> <53DB5796.8080502@orange.com> In-Reply-To: <53DB5796.8080502@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.220] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pce/x6FPWzIjz7GokmP22CvhWzSZdN0 Cc: "pce@ietf.org" Subject: Re: [Pce] FW: I-D Action: draft-ietf-pce-wson-routing-wavelength-12.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 15:27:55 -0000 Hi Julien, Thanks for your quick review on the update. I made all the changes you indi= cated below as well as the double spacing for a few places.=20 I will publish in a minute v.13.=20 Thanks, Young -----Original Message----- From: Julien Meuric [mailto:julien.meuric@orange.com]=20 Sent: Friday, August 01, 2014 4:02 AM To: Leeyoung; draft-ietf-pce-wson-routing-wavelength@tools.ietf.org Cc: pce@ietf.org Subject: Re: FW: [Pce] I-D Action: draft-ietf-pce-wson-routing-wavelength-1= 2.txt Hi Young. Thank you for the update. I think I can live with the "Re-optimize"=20 phrase as it is. Just a few remaining nits: - still some double spacing - s/PCE-based Architecture/PCE-based architecture/ - s/network.The PCE/network. The PCE/ - s/constraining the path to have/constraining the paths to have/ [my mista= ke!] It looks like version 13 will be ready to move forward. Thanks Julien Jul. 31, 2014 - Leeyoung: > Hi Julien, > > All your comments have been reflected in the revision except: > > Section 3.4. > --- > - The phrase "b. Re-optimize wavelength(s)" reads odd, what about rephras= ing into "b. Re-consider wavelength(s) allocation"? > > I think Re-optimize is meant to include wavelength(s) re-allocation as we= ll as path changes. I would leave the phrase as is. > > Attached are the idnits report and the working version (v.13). Let me kno= w if this version satisfies you and if I should publish this. > > Thanks, > Young > > -----Original Message----- > From: Julien Meuric [mailto:julien.meuric@orange.com] > Sent: Thursday, July 31, 2014 7:10 AM > > Hi Young and WSON co-authors. > > As part of the shepherding of the WSON requirement draft, please find bel= ow some comments to address before sending to the IESG. > > Regards, > > Julien > > > ---------- > Globally, the way the top-level section titles are indented creates troub= les to IETF tools, including idnits. Please remove spacing before these sec= tion header, from 1. to 8. > --- > Along the document, unnecessary double spacing happens multiple times, es= pecially after periods. Please clean them up. > --------- > In the header, could you compact the author list by removing blank lines? > --------- > s/described in RFC-2119 0./described in [RFC2119]./ > --------- > Abstract > --- > It is better when the abstract appears on the 1st page: please move it be= fore "Status of this Memo". > --- > s/for Optical impairments/for optical impairments/ > --------- > Section 1. > --- > - s/PCE based Architecture/PCE-based architecture/ > - s/Generalized MPLS (GMPLS) networks/Generalized MPLS=20 > (GMPLS)-controlled networks/ > - s/Optical Switching Element/optical switching element/ > - s/communications Protocol/communication Protocol/ > - s/WDM based optical networks/WDM-based optical networks/ > - A paragraph break right before "A transparent optical network" would be= appreciated. > - s/its route from/its path from/ > - s/due to their relatively high cost/for cost reasons/ > - s/all lightpath computation/all lightpath computations/ > - s/for Optical impairments/for optical impairments/ > --------- > Section 2. > --- > - s/in 0./in Figure 1./ > - At the end of Figure 1's title, I would remove the period, to be consis= tent with Figure 2. > - The DWA case is actually a sub-case of "separate processes",=20 > replacing > (c) by (b') would to the trick. > - To glue the text to the figure, 1./2./3. before paragraphs should be re= placed by (a)/(b)/(b'). > - NEW last sentence in (b'): "This alternative is a particular case of > R+WA, it should be covered by GMPLS PCEP extensions and does not=20 > R+present > new WSON-specific requirements" [beware of the hyphen] > - s/PCE based implementation/PCE-based implementation/ > --------- > Section 3.1. > --- > - Starting with "1." leads to look for "2.", which does not exist: it wou= ld ease reading to drop "1." and start directly with "A PCEP request..." > - I would remove the "or" at the end of the line (i). > - Trailing text of (i) and (ii) should be aligned. > --------- > Section 3.2. > --- > - Trailing text of (i) and (ii) should be aligned. > - s/in R+WA or DWA/in R+WA or R+DWA/ > - s/assigned to the route/assigned to the path/ > - s/Label Sets/label set/ > - s/no route/no path/ > --------- > Section 3.3. > --- > - Before the 2 listed requirements, I suggest to add this NEW text: > "Sending simultaneous path requests for "routing only" computation is sup= ported by PCEP specification [RFC 5440]. To remain consistent, the followin= g requirements are added." > - s/the route and wavelength assigned to the route for each/the path=20 > and the assigned wavelength for each/ > --------- > Section 3.4. > --- > - The phrase "b. Re-optimize wavelength(s)" reads odd, what about rephras= ing into "b. Re-consider wavelength(s) allocation"? > - s/both wavelength and the path/both the wavelength and the path/ > - s/no route/no path/ > - s/both route and wavelength/both path and wavelength/ > --------- > Section 3.5. > --- > - s/assigned wavelenght/assigned wavelength/ > - s/Explicit Label or Label Sets/explicit label or label set/ > - s/is NOT required/is not required/ > - The "3.6." string and paragraph break has scrambled the last lines=20 > of the section > - s/or an policy based/or a policy-based/ > --------- > Section 3.6. > --- > - Fix the section header (as mentioned above) > - s/for (E.g., random assignment, descending order, ascending order,=20 > etc.)/for, e.g., random assignment, descending order, ascending order,=20 > etc./ > --- > OLD: > " 2. A request for 2 or more paths (e.g., 1+1 link disjoint paths) MUST > be able to specify an option constraining the path to have the > same wavelength(s) assigned. > > Note that this is extremely useful in the case of protection with > single transponder." > NEW: > "2. A request for two or more paths MUST be able to include an option con= straining the path to have the same wavelength(s) assigned. This is useful = in the case of protection with single transponder (e.g., 1+1 link-disjoint = paths)." > --- > - s/contiguous wavelength/continuous wavelength/ > - s/to constrain the wavelength continuity/to specify the precedence=20 > of wavelength continuity/ > --------- > Section 3.7. > --- > - s/or any given links/or on any given links/ > --------- > Section 4.5. > --- > Not clear if it is a misplaced requirement or a nice-to-have idea. I sugg= est replacing the sentence by the following NEW text: > "If PCE discovery mechanisms ([RFC5089] and [RFC5088]) were to be extende= d for technology-specific capabilities, advertising WSON RWA path computati= on capability should be considered." > --------- > Section 8. > --- > - RFCs 3471, 3473 and 6566 are note mentioned in the body of the I-D and = should be dropped. > - RFC 4003 is missing and should be added to informative documents. > - RFC 4657 and PCEP-MIB should be moved from normative to informative (no= need to read them to understand your I-D). > ----THE END----- > > > > Apr. 28, 2014 - Leeyoung: >> Hi Julien, >> >> This update reflects all the comments received from Cyril and Ramon as p= art of the WG LC. >> >> Cyril, please let the WG know if this update satisfies your comment. >> >> Best Regards, >> Young >> >> -----Original Message----- >> From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of=20 >> internet-drafts@ietf.org >> Sent: Monday, April 28, 2014 11:29 AM >> >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Path Computation Element Working Gro= up of the IETF. >> >> Title : PCEP Requirements for WSON Routing and Wavel= ength Assignment >> Authors : Young Lee >> Greg Bernstein >> Jonas Martensson >> Tomonori Takeda >> Takehiro Tsuritani >> Oscar Gonzalez de Dios >> Filename : draft-ietf-pce-wson-routing-wavelength-12.txt >> Pages : 14 >> Date : 2014-04-28 >> >> Abstract: >> This memo provides application-specific requirements for the Path >> Computation Element communication Protocol (PCEP) for the support o= f >> Wavelength Switched Optical Networks (WSON). Lightpath provisioning >> in WSONs requires a routing and wavelength assignment (RWA) process= . >> From a path computation perspective, wavelength assignment is the >> process of determining which wavelength can be used on each hop of = a >> path and forms an additional routing constraint to optical light >> path computation. Requirements for Optical impairments will be >> addressed in a separate document. >> >> >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-pce-wson-routing-waveleng >> t >> h/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-pce-wson-routing-wavelength-12 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-wson-routing-waveleng >> t >> h-12 >> >> >> Please note that it may take a couple of minutes from the time of submis= sion until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> Pce mailing list >> Pce@ietf.org >> https://www.ietf.org/mailman/listinfo/pce >> From nobody Fri Aug 1 08:29:14 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A531B27E5; Fri, 1 Aug 2014 08:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SfOEpQ8jjuu; Fri, 1 Aug 2014 08:29:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 965B11B27DF; Fri, 1 Aug 2014 08:29:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140801152905.30471.43674.idtracker@ietfa.amsl.com> Date: Fri, 01 Aug 2014 08:29:05 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/oNfi5fTH6wlq8ZM--JoxWT4h3jI Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-wson-routing-wavelength-13.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 15:29:12 -0000 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 : PCEP Requirements for WSON Routing and Wavelength Assignment Authors : Young Lee Greg Bernstein Jonas Martensson Tomonori Takeda Takehiro Tsuritani Oscar Gonzalez de Dios Filename : draft-ietf-pce-wson-routing-wavelength-13.txt Pages : 13 Date : 2014-08-01 Abstract: This memo provides application-specific requirements for the Path Computation Element communication Protocol (PCEP) for the support of Wavelength Switched Optical Networks (WSON). Lightpath provisioning in WSONs requires a routing and wavelength assignment (RWA) process. From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical light path computation. Requirements for optical impairments will be addressed in a separate document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-wson-routing-wavelength/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-wson-routing-wavelength-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-wson-routing-wavelength-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 1 08:30:56 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2761B27EC for ; Fri, 1 Aug 2014 08:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raIoQzJo-jen for ; Fri, 1 Aug 2014 08:30:52 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B1851B2791 for ; Fri, 1 Aug 2014 08:30:52 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id at20so5937064iec.8 for ; Fri, 01 Aug 2014 08:30:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xtYc86g/im6WPdA82fxldvEkUyui3SoggVayaMPprWw=; b=mvdcrSOZ5tZa0mSl4pBkLrcq+qsCqcNDuxO79bCDWhmBGg1Plv/03l+BJJBuI0jFlu xp6IRo3+eoBWkKQgnwEqe2wBs7QdsmyGD5RJ3jcIPsU5ysNzQM29xxU7F/Jan49Czonr UFXlF3TbKueGDB3gbBB9y1tiswfu4IJcT3CH8iGvkYscoU9yCu3EdtIhE5QDz2O/E2sI cJPAQWRJqK1qoHRb3DRK5QbgwVR4E/0El/aSVmsJ5+q5WXZ1HguBFpS9mEXGk3kdzF3c BRjqWnf5YUklQDaoi7e3zA0f2GLdA1mcPwc/J+fE5Vu4UCIegQ12WXXHKc5CPwg7g0r2 Mubw== MIME-Version: 1.0 X-Received: by 10.50.128.234 with SMTP id nr10mr8795236igb.3.1406907052086; Fri, 01 Aug 2014 08:30:52 -0700 (PDT) Received: by 10.50.26.74 with HTTP; Fri, 1 Aug 2014 08:30:52 -0700 (PDT) Received: by 10.50.26.74 with HTTP; Fri, 1 Aug 2014 08:30:52 -0700 (PDT) In-Reply-To: <53DBA1CB.9080109@orange.com> References: <23CE718903A838468A8B325B80962F9B865B4669@szxeml556-mbs.china.huawei.com> <53DBA1CB.9080109@orange.com> Date: Fri, 1 Aug 2014 21:00:52 +0530 Message-ID: From: Dhruv Dhody To: Julien Meuric Content-Type: multipart/alternative; boundary=047d7b10d13112869704ff93136f Archived-At: http://mailarchive.ietf.org/arch/msg/pce/7WNT4FIqOSKy1FwikXK0qVM5pUk Cc: "pce@ietf.org" Subject: Re: [Pce] Regarding draft-ietf-pce-pcep-mib-09 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 15:30:55 -0000 --047d7b10d13112869704ff93136f Content-Type: text/plain; charset=UTF-8 Hi julien, I meant IETF LC. Sorry for the confusion. Dhruv On Aug 1, 2014 7:49 PM, "Julien Meuric" wrote: > Hi Dhruv. > > Just to be sure we're on the same page: the WG LC on this I-D ended on > March, 31! All the same, your comments can be taken into account "before or > alongside" the IETF LC (it's up to the editors). > > Thanks for your review, > > Julien > > > Jul. 31, 2014 - Dhruv Dhody: > >> Hi Authors, >> >> I re-read the MIB document in preparation for the last call. >> You may consider these comments/nits before or alongside the WG last call. >> >> - General >> ~ Expand PCReq, PCRep, PCNtf, SVEC, RP etc on first use, using >> terminology >> Section may also be useful. >> ~ PCEP speaker and PCEP entity are used interchangeably, perhaps we can >> unify? >> ~ a new object for corrupted messages (note that corrupted messages are >> different from unknown messages and this cannot be derived from >> number of >> error messages sent either). >> >> - Abstract >> Add MIB as the abbreviation >> >> - Introduction >> Add TE as the abbreviation for Traffic Engineering >> >> - Shouldn't Section 3 'Requirements Language' about RFC2119 keywords >> be part of the introduction itself? >> >> - Section 5.1 >> pcePcepEntityEntry OBJECT-TYPE >> SYNTAX PcePcepEntityEntry >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "An entry in this table represents a PCEP entity." >> INDEX { pcePcepEntityIndex } >> ::= { pcePcepEntityTable 1 } >> >> ~ I think the description should not say 'this table' while describing >> an entry. Also true for pcePcepSessEntry. >> >> pcePcepEntityIndex OBJECT-TYPE >> SYNTAX Unsigned32 (1..2147483647) >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "This index is used to uniquely identify the PCEP entity." >> ::= { pcePcepEntityEntry 1 } >> >> ~ Wouldnt Integer32 (1..2147483647) be a better fit? >> >> Suggest to reorder pcePcepEntityMaxKeepAliveTimer, >> pcePcepEntityMaxDeadTimer, pcePcepEntityAllowNegotiation, >> pcePcepEntityMinKeepAliveTimer, pcePcepEntityMinDeadTimer >> >> ~ by moving the pcePcepEntityAllowNegotiation first, you can use it in >> the description for both max and min timers. >> >> pcePcepEntitySyncTimer OBJECT-TYPE >> SYNTAX Unsigned32 (1..65535) >> UNITS "seconds" >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The value of SYNC timer is used in the case of synchronized >> path computation request using the SVEC object... >> >> ~ Use SyncTimer (as used in 5440) instead of SYNC timer. >> >> pcePcepPeerNumSessSetupFail OBJECT-TYPE >> SYNTAX Counter32 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The number of PCEP sessions with the peer that have been >> attempted but failed before being fully estbalished. >> This counter is incremented each time a session with this >> peer fails before reaching session state pceSessionUp." >> ::= { pcePcepPeerEntry 8 } >> >> ~ the state is called sessionUp (refer pcePcepSessState) and not >> pceSessionUp >> >> - Security Considerations >> You might think of removing the text about SET operation, as this >> MIB is read-only. >> >> You might also add reference to SNMPv3 security like USM with AES as >> well to use of secure transport like SSH or TLS/DTLS. >> >> Thank You! >> >> Dhruv >> >> >> >> >> >> >> >> _______________________________________________ >> Pce mailing list >> Pce@ietf.org >> https://www.ietf.org/mailman/listinfo/pce >> >> > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --047d7b10d13112869704ff93136f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi julien,

I meant IETF LC. Sorry for the confusion.=C2=A0

Dhruv

On Aug 1, 2014 7:49 PM, "Julien Meuric"= ; <julien.meuric@orange.com<= /a>> wrote:
Hi Dhruv.

Just to be sure we're on the same page: the WG LC on this I-D ended on = March, 31! All the same, your comments can be taken into account "befo= re or alongside" the IETF LC (it's up to the editors).

Thanks for your review,

Julien


Jul. 31, 2014 - Dhruv Dhody:
Hi Authors,

I re-read the MIB document in preparation for the last call.
You may consider these comments/nits before or alongside the WG last call.<= br>
- General
=C2=A0 =C2=A0~ Expand PCReq, PCRep, PCNtf, SVEC, RP etc on first use, using= terminology
=C2=A0 =C2=A0 =C2=A0Section may also be useful.
=C2=A0 =C2=A0~ PCEP speaker and PCEP entity are used interchangeably, perha= ps we can
=C2=A0 =C2=A0 =C2=A0unify?
=C2=A0 =C2=A0~ a new object for corrupted messages (note that corrupted mes= sages are
=C2=A0 =C2=A0 =C2=A0different from unknown messages and this cannot be deri= ved from number of
=C2=A0 =C2=A0 =C2=A0error messages sent either). =C2=A0 =C2=A0 =C2=A0

- Abstract
=C2=A0 =C2=A0Add MIB as the abbreviation

- Introduction
=C2=A0 =C2=A0Add TE as the abbreviation for Traffic Engineering

- Shouldn't Section 3 'Requirements Language' about RFC2119 key= words
=C2=A0 =C2=A0be part of the introduction itself?

- Section 5.1
=C2=A0 =C2=A0 pcePcepEntityEntry OBJECT-TYPE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SYNTAX =C2=A0 =C2=A0 =C2=A0PcePcepEntityEntry =C2=A0 =C2=A0 =C2=A0 =C2=A0 MAX-ACCESS =C2=A0not-accessible
=C2=A0 =C2=A0 =C2=A0 =C2=A0 STATUS =C2=A0 =C2=A0 =C2=A0current
=C2=A0 =C2=A0 =C2=A0 =C2=A0 DESCRIPTION
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "An entry in this table repr= esents a PCEP entity."
=C2=A0 =C2=A0 =C2=A0 =C2=A0 INDEX =C2=A0 =C2=A0 =C2=A0 { =C2=A0pcePcepEntit= yIndex =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ::=3D { pcePcepEntityTable 1 }

=C2=A0 =C2=A0~ I think the description should not say 'this table' = while describing
=C2=A0 =C2=A0 =C2=A0an entry. Also true for pcePcepSessEntry.

=C2=A0 =C2=A0 pcePcepEntityIndex OBJECT-TYPE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SYNTAX =C2=A0 =C2=A0 =C2=A0Unsigned32 (1..21474= 83647)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 MAX-ACCESS =C2=A0not-accessible
=C2=A0 =C2=A0 =C2=A0 =C2=A0 STATUS =C2=A0 =C2=A0 =C2=A0current
=C2=A0 =C2=A0 =C2=A0 =C2=A0 DESCRIPTION
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "This index is used to uniqu= ely identify the PCEP entity."
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ::=3D { pcePcepEntityEntry 1 }

=C2=A0 =C2=A0~ Wouldnt Integer32 (1..2147483647) be a better fit?

=C2=A0 =C2=A0Suggest to reorder pcePcepEntityMaxKeepAliveTimer,
=C2=A0 =C2=A0pcePcepEntityMaxDeadTimer, pcePcepEntityAllowNegotiation,
=C2=A0 =C2=A0pcePcepEntityMinKeepAliveTimer, pcePcepEntityMinDeadTim= er

=C2=A0 =C2=A0~ by moving the pcePcepEntityAllowNegotiation first, you can u= se it in
=C2=A0 =C2=A0 =C2=A0the description for both max and min timers.

=C2=A0 =C2=A0 pcePcepEntitySyncTimer OBJECT-TYPE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SYNTAX =C2=A0 =C2=A0 =C2=A0Unsigned32 (1..65535= )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 UNITS =C2=A0 =C2=A0 =C2=A0 "seconds"<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 MAX-ACCESS =C2=A0read-only
=C2=A0 =C2=A0 =C2=A0 =C2=A0 STATUS =C2=A0 =C2=A0 =C2=A0current
=C2=A0 =C2=A0 =C2=A0 =C2=A0 DESCRIPTION
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "The value of SYNC timer is = used in the case of synchronized
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0path computation request us= ing the SVEC object...

=C2=A0 =C2=A0~ Use SyncTimer (as used in 5440) instead of SYNC timer.

=C2=A0 =C2=A0 pcePcepPeerNumSessSetupFail OBJECT-TYPE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SYNTAX =C2=A0 =C2=A0 =C2=A0Counter32
=C2=A0 =C2=A0 =C2=A0 =C2=A0 MAX-ACCESS =C2=A0read-only
=C2=A0 =C2=A0 =C2=A0 =C2=A0 STATUS =C2=A0 =C2=A0 =C2=A0current
=C2=A0 =C2=A0 =C2=A0 =C2=A0 DESCRIPTION
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "The number of PCEP sessions= with the peer that have been
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0attempted but failed before= being fully estbalished.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This counter is incremented= each time a session with this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0peer fails before reaching = session state pceSessionUp."
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ::=3D { pcePcepPeerEntry 8 }

=C2=A0 =C2=A0~ =C2=A0the state is called sessionUp (refer pcePcepSessState)= and not
=C2=A0 =C2=A0 =C2=A0 pceSessionUp

- Security Considerations
=C2=A0 =C2=A0You might think of removing the text about SET operation, as t= his
=C2=A0 =C2=A0MIB is read-only.

=C2=A0 =C2=A0You might also add reference to SNMPv3 security like USM with = AES as
=C2=A0 =C2=A0well to use of secure transport like SSH or TLS/DTLS.

Thank You!

Dhruv







_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce


_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce
--047d7b10d13112869704ff93136f-- From nobody Mon Aug 4 13:05:23 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D6F1A010A for ; Mon, 4 Aug 2014 13:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tv5L-SCc2Amm for ; Mon, 4 Aug 2014 13:05:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97CE21A026A for ; Mon, 4 Aug 2014 13:05:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHX19450; Mon, 04 Aug 2014 20:05:17 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 4 Aug 2014 21:05:17 +0100 Received: from DFWEML706-CHM.china.huawei.com ([169.254.8.145]) by dfweml704-chm.china.huawei.com ([169.254.6.218]) with mapi id 14.03.0158.001; Mon, 4 Aug 2014 13:05:07 -0700 From: Leeyoung To: Julien Meuric , "draft-ietf-pce-gmpls-pcep-extensions@tools.ietf.org" Thread-Topic: [Pce] Last IPR Check on draft-ietf-pce-gmpls-pcep-extensions Thread-Index: AQHPpcGOEnf3YCHU60CM/uBDazcmyJvA8zEQ Date: Mon, 4 Aug 2014 20:05:07 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C08660@dfweml706-chm.china.huawei.com> References: <53CE82F9.3060707@orange.com> In-Reply-To: <53CE82F9.3060707@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.102] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pce/AgNciMuNSDp37URSkCWXLoiq95A Cc: "pce@ietf.org" Subject: Re: [Pce] Last IPR Check on draft-ietf-pce-gmpls-pcep-extensions X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 20:05:21 -0000 I am not aware of any IPR that applies. Thanks, Young=20 -----Original Message----- From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Julien Meuric Sent: Tuesday, July 22, 2014 10:28 AM To: draft-ietf-pce-gmpls-pcep-extensions@tools.ietf.org Cc: pce@ietf.org Subject: [Pce] Last IPR Check on draft-ietf-pce-gmpls-pcep-extensions Dear authors of the aforementioned document, Has all IPR that applies to draft-ietf-pce-gmpls-pcep-extensions been discl= osed in compliance with IETF IPR rules? (see RFCs 3979, 4879, 3669 and 5378= for more details) A response from each of you is expected. Regards, JP & Julien _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From nobody Thu Aug 7 15:27:34 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F421B2A7E for ; Thu, 7 Aug 2014 15:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ply6CCAYGJx3 for ; Thu, 7 Aug 2014 15:27:31 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EC4C1B2A67 for ; Thu, 7 Aug 2014 15:27:23 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s77MRL59025675; Thu, 7 Aug 2014 23:27:22 +0100 Received: from 950129200 (host86-142-10-20.range86-142.btcentralplus.com [86.142.10.20]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s77MRKkQ025666 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Aug 2014 23:27:21 +0100 From: "Adrian Farrel" To: References: <20140730132051.14034.99328.idtracker@ietfa.amsl.com> In-Reply-To: <20140730132051.14034.99328.idtracker@ietfa.amsl.com> Date: Thu, 7 Aug 2014 23:27:19 +0100 Message-ID: <027f01cfb28e$c104ef60$430ece20$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQICBjAeidb8jCSm1J1xCQ2iewWFAZthEOHQ Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20866.002 X-TM-AS-Result: No--15.589-10.0-31-10 X-imss-scan-details: No--15.589-10.0-31-10 X-TMASE-MatchedRID: kNb5oX97tjhDsA41QLYxFNjpv424W/L69l9p8mNlkgmObf10apLcScLm p4jPUF8tAWMdzSV1Iwb2mhGQByUXXiWvhQBtQUwTU+OjsPhIWDiz4D778GcgEQuKAULAAChWJnl MXh1WVm7W80oaMg413XLEXBbQP/X3HHJU/MR+nmH+OTCJja0mcmv34qCfZeB4oiJSjMEHzGtjaJ HsrxZyzBQuH8hDcY4SHwaymvSWaz+vm45G9DOBJH1UZSPvDstZUAjrAJWsTe/JYIv7y0tu9iFIx 6lzyENtgEBR2HjnXiv27vlZQBKDdDcpdZ3fQiLdgxsfzkNRlfJeqSmMX0XSKdRnEQCUU+jzjocz muoPCq3Bp/pHGeq8ZtZyU8Ms4MWRpLX/8+FfhOn61U/QnnOfCQPmrAFteHIP Archived-At: http://mailarchive.ietf.org/arch/msg/pce/b7HhgcOLhtjZFTfIRuLyxIrju0g Cc: pce@ietf.org Subject: [Pce] FW: New Version Notification for draft-ietf-pce-rfc7150bis-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 07 Aug 2014 22:27:33 -0000 Hi chairs, Are we going to go ahead with this? Do we need any further confirmation from the WG about vendor constraints = implementation? Thanks, Adrian > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 30 July 2014 14:21 > To: Adrian Farrel; Fatai Zhang; Adrian Farrel; Fatai Zhang > Subject: New Version Notification for draft-ietf-pce-rfc7150bis-01.txt >=20 >=20 > A new version of I-D, draft-ietf-pce-rfc7150bis-01.txt > has been successfully submitted by Adrian Farrel and posted to the > IETF repository. >=20 > Name: draft-ietf-pce-rfc7150bis > Revision: 01 > Title: Conveying Vendor-Specific Constraints in the Path Computation > Element communication Protocol > Document date: 2014-07-30 > Group: pce > Pages: 12 > URL: = http://www.ietf.org/internet-drafts/draft-ietf-pce-rfc7150bis-01.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-pce-rfc7150bis/ > Htmlized: = http://tools.ietf.org/html/draft-ietf-pce-rfc7150bis-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-rfc7150bis-01 >=20 > Abstract: > The Path Computation Element communication Protocol (PCEP) is used = to > convey path computation requests and responses both between Path > Computation Clients (PCCs) and Path Computation Elements (PCEs) and > between cooperating PCEs. In PCEP, the path computation requests > carry details of the constraints and objective functions that the = PCC > wishes the PCE to apply in its computation. >=20 > This document defines a facility to carry vendor-specific = information > in PCEP using a dedicated object and a new Type-Length-Value (TLV) > that can be carried in any PCEP object that supports TLVs. >=20 > This document obsoletes RFC 7150. The only changes from that > document are a clarification of the use of the new = Type-Length-Value > and the allocation of a different code point for the VENDOR- > INFORMATION object. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat From nobody Fri Aug 8 03:10:13 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249521B2A14 for ; Fri, 8 Aug 2014 03:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.885 X-Spam-Level: X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9zJadyiTWJ7 for ; Fri, 8 Aug 2014 03:10:07 -0700 (PDT) Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id C42551B2A13 for ; Fri, 8 Aug 2014 03:10:06 -0700 (PDT) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 216F75D861A; Fri, 8 Aug 2014 12:10:05 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.orange.com (Postfix) with ESMTP id 161085D85EE; Fri, 8 Aug 2014 12:10:05 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Aug 2014 12:10:04 +0200 Received: from [10.193.71.122] ([10.193.71.122]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Aug 2014 12:10:03 +0200 Message-ID: <53E4A1FB.9080403@orange.com> Date: Fri, 08 Aug 2014 12:10:03 +0200 From: Julien Meuric Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <20140730132051.14034.99328.idtracker@ietfa.amsl.com> <027f01cfb28e$c104ef60$430ece20$@olddog.co.uk> In-Reply-To: <027f01cfb28e$c104ef60$430ece20$@olddog.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Aug 2014 10:10:03.0975 (UTC) FILETIME=[EC155570:01CFB2F0] Archived-At: http://mailarchive.ietf.org/arch/msg/pce/hELhAZzpL_a57-1Bn8tTtPw0P8g Cc: pce@ietf.org Subject: Re: [Pce] FW: New Version Notification for draft-ietf-pce-rfc7150bis-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 10:10:11 -0000 Hi Adrian. So far, we have received little feedback from implementers of RFC 7150. At this stage, even if the consensus is that the change should have been avoided, the _expressed_ impact is limited. We will thus proceed to WG last call. JP & Julien Aug. 08, 2014 - Adrian Farrel: > Hi chairs, > > Are we going to go ahead with this? > Do we need any further confirmation from the WG about vendor constraints implementation? > > Thanks, > Adrian > >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: 30 July 2014 14:21 >> >> A new version of I-D, draft-ietf-pce-rfc7150bis-01.txt >> has been successfully submitted by Adrian Farrel and posted to the >> IETF repository. >> >> Name: draft-ietf-pce-rfc7150bis >> Revision: 01 >> Title: Conveying Vendor-Specific Constraints in the Path Computation >> Element communication Protocol >> Document date: 2014-07-30 >> Group: pce >> Pages: 12 >> URL: http://www.ietf.org/internet-drafts/draft-ietf-pce-rfc7150bis-01.txt >> Status: https://datatracker.ietf.org/doc/draft-ietf-pce-rfc7150bis/ >> Htmlized: http://tools.ietf.org/html/draft-ietf-pce-rfc7150bis-01 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-rfc7150bis-01 >> >> Abstract: >> The Path Computation Element communication Protocol (PCEP) is used to >> convey path computation requests and responses both between Path >> Computation Clients (PCCs) and Path Computation Elements (PCEs) and >> between cooperating PCEs. In PCEP, the path computation requests >> carry details of the constraints and objective functions that the PCC >> wishes the PCE to apply in its computation. >> >> This document defines a facility to carry vendor-specific information >> in PCEP using a dedicated object and a new Type-Length-Value (TLV) >> that can be carried in any PCEP object that supports TLVs. >> >> This document obsoletes RFC 7150. The only changes from that >> document are a clarification of the use of the new Type-Length-Value >> and the allocation of a different code point for the VENDOR- >> INFORMATION object. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat > From nobody Fri Aug 8 03:16:17 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB001B2A04 for ; Fri, 8 Aug 2014 03:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.885 X-Spam-Level: X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfr1a5f78eFc for ; Fri, 8 Aug 2014 03:16:14 -0700 (PDT) Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 5667F1B29F7 for ; Fri, 8 Aug 2014 03:16:14 -0700 (PDT) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 51EB6410223 for ; Fri, 8 Aug 2014 12:16:13 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.orange.com (Postfix) with ESMTP id 4BB6141021F for ; Fri, 8 Aug 2014 12:16:13 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Aug 2014 12:16:13 +0200 Received: from [10.193.71.122] ([10.193.71.122]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Aug 2014 12:16:12 +0200 Message-ID: <53E4A36B.606@orange.com> Date: Fri, 08 Aug 2014 12:16:11 +0200 From: Julien Meuric Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "pce@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Aug 2014 10:16:12.0158 (UTC) FILETIME=[C78999E0:01CFB2F1] Archived-At: http://mailarchive.ietf.org/arch/msg/pce/5wknaz7AU6DFTnXwMmvbZPGT--I Subject: [Pce] WG Last Call on draft-ietf-pce-rfc7150bis-01 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 10:16:15 -0000 Dear PCE WG, Following the discussion in Toronto, this message ignites a WG last call on draft-ietf-pce-rfc7150bis-01. Since it is mainly a codepoint change while the specification remains the same, this last call will only last *one week* and will end on Friday August 15 at 11:59 PM, HST. Comments should be sent to the PCE mailing list. Regards, JP & Julien From nobody Fri Aug 8 10:35:34 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A021B2C50 for ; Fri, 8 Aug 2014 10:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xvqT9hqrlcW for ; Fri, 8 Aug 2014 10:35:32 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BACAD1B2BF9 for ; Fri, 8 Aug 2014 10:35:31 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id z12so5983244wgg.24 for ; Fri, 08 Aug 2014 10:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=8Z2HQ3XJ5P4yDxsmmdYXqCs8fbcsj0Y8TtlIdni3Uc8=; b=SH86ys0+kLNGXZSp1LHjqC1cqksGUgoj02GuCvfotYKTUVTYlnGhYyFB19ztwPUYmk 6FLt9DmBrzFs6MDCAfiPN7PugcrRgGqarC0ne3N0uJQf83uSlryFwY6DAjP/WwfoAY7A r7LnjvVvVNibqgCuA04lLN1ZQPBms+lTYJPlAwU2TsUBPF1R7won6yr/AWuNyBBo5xPV VJ4iAFH/DVS1szyNumAGTXIdYGUzdLO9nO2JIv08w8J8BvihpuDgPp1MaI+efMkfA0Tt WGx9IXyfl34LE6GnCEvIEdvkdPY9S+h4W5TEaXdV12I2EB9bmX2zOnhJsrofN3CLVacv y2Lg== MIME-Version: 1.0 X-Received: by 10.180.11.206 with SMTP id s14mr5591020wib.27.1407519330297; Fri, 08 Aug 2014 10:35:30 -0700 (PDT) Received: by 10.194.190.227 with HTTP; Fri, 8 Aug 2014 10:35:30 -0700 (PDT) Date: Fri, 8 Aug 2014 13:35:30 -0400 Message-ID: From: Samjhana Pokhrel To: pce@ietf.org Content-Type: multipart/alternative; boundary=001a11c2443cb26e94050021a190 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/puHvEiGyVP8CZHWfR6ngDwT4nKQ Subject: [Pce] SDN/MPLS 2014 Conference Information X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 17:35:33 -0000 --001a11c2443cb26e94050021a190 Content-Type: text/plain; charset=UTF-8 The SDN/MPLS 2014 Conference program has already been posted. It is available at http://www.isocore.com/sdn-mpls/ or specifically at: *Tutorials (Sunday)*: http://www.isocore.com/sdn-mpls/tutorials.htm *Technical sessions (Mon- Wed):* http://www.isocore.com/sdn-mpls/technical_sessions.htm The conference will take place November 2-5 in Washington DC and will include an extensive four day program consisting of tutorials, technical sessions, panels, and exhibits. The key topics to be discussed at this year's conference include: Virtualization, SDN, Cloud and Data Centers, NFV, PCE, Mobility, Traffic Engineering Transport SDN, Orchestration, multi-play applications across common infrastructure and other Emerging Technologies. The conference hotel is the Marriott Wardman Park in Washington DC. Please note that there are only a limited number of rooms available this year at a reduced rate. Please make reservations at: https://resweb.passkey.com/Resweb.do?mode=welcome_gi_new&groupID=25088120 --001a11c2443cb26e94050021a190 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The SDN/MPLS 2014 Conference program has already been posted. It is available
=C2=A0at http://www.isocore.co= m/sdn-mpls/=C2=A0=C2=A0 or specifically at:

Tutorials (Sunday): http://www.isocore.com/sdn-mpls/tutorials.htm
Technical sessions (Mon- Wed): http://www.isocore.com/sdn-mpls/technical_ses= sions.htm

The conference will take place November 2-5 in Washington DC and will
include an extensive four day program consisting of tutorials, technical sessions, panels, and exhibits. The key topics to be discussed at this
year's conference include: Virtualization, SDN, Cloud and Data Centers,= NFV,
PCE, Mobility, Traffic Engineering Transport SDN, Orchestration,
multi-play applications across common infrastructure and other Emerging Technologies.

The conference hotel is the Marriott Wardman Park in Washington DC. Please<= br> note that there are only a limited number of rooms available this year at a=
reduced rate. Please make reservations at:
https://resweb.passkey.com/Resweb.do?mode=3Dwelcome_gi_n= ew&groupID=3D25088120

--001a11c2443cb26e94050021a190-- From nobody Sun Aug 10 04:44:23 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C96D1A06EA for ; Sun, 10 Aug 2014 04:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.2 X-Spam-Level: X-Spam-Status: No, score=-99.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hqn7uNg_pWKY for ; Sun, 10 Aug 2014 04:44:19 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D53FC1A06E8 for ; Sun, 10 Aug 2014 04:44:18 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7ABiGkU002302; Sun, 10 Aug 2014 12:44:16 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7ABiFMS002292 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 10 Aug 2014 12:44:16 +0100 From: "Adrian Farrel" To: Date: Sun, 10 Aug 2014 12:44:13 +0100 Message-ID: <000301cfb490$68af4140$3a0dc3c0$@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: Ac+0kGZWlNyMwNUoRsOh1m8y7uUVSQ== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20870.007 X-TM-AS-Result: No--20.725-10.0-31-10 X-imss-scan-details: No--20.725-10.0-31-10 X-TMASE-MatchedRID: J1szhq7AkrGpJiEaGyB61h/XcAla9LsVGSqdEmeD/nVXopZjyO6CZSA+ gzCkg5nYuEF/Bj7JRlYePAnhvVMNg9/VfsVgOrakypeMiaCPnxsjo8c0NkYYIsizgKND8Lm5kl0 fPYWeWR3fDmszfYdZarbbaNdsYdLm06P6nK44odAUEm127/0kJmpNfTqTMeuXU2MsggOb48BfyJ 6rJB+UQkGzhVxBHJRBXulhb9SxPH2Fg8+5j8XdKbrbxxduc6FPee/Ukvma+A8Nht78/JfyBJRSl 0PP7a2/8stBm6NU8UJly/zeenqavhecrkyt1I25wIytSiYJZzqSeMExjuIoErX6F9f5JEkS2WLv Fdeh0LvDg0jDRaMTvV4RqcpXvMbLAxYKB0LOn5ri3aa5wOREEYGMvMvh2j5WAOrNpiFyN5CNU2y loY38wa8bkkrwKc43f3syr/WbAuVdFN0T1voiz8AmcZEx8XHJPNzEhPDkO0nJ3ZBgZbM1b4Cuqg hmtWfX3azpvimRudUynBGcgKw95EIjaJSsaV6qw69AIwXJn0aWesyrtKuK7cj0Eew4TN42iXKbJ K4FbCmjkoEn/gUJLe6XwEh2B4vPhd8nEZR/hIPHQ8MHM33wroHSaqO6kWzl6i5zlFx/UHQHam+X wtBHJSnlRN2uq0TLEevkLUFjxqYEW9SZtilh+7uafOcb44DphQaFqMRElgkWoS+vMj3A2yYcyAt uUMml2aGC8HFeR+h9PWvwgq1I9LqO765EzZu1XpVEIlJTuP17NIjco1DV8tkklpbUyGXmPi49rm NmX1/z+cGaEZD4boPgOMg8SmUiDc5IfPgQIoieAiCmPx4NwLTrdaH1ZWqCHOI0tZ7A+B36C0ePs 7A07QKmARN5PTKc Archived-At: http://mailarchive.ietf.org/arch/msg/pce/PaWQ5DQwwYqVIwZGy6V4gijlDDQ Cc: pce@ietf.org Subject: [Pce] AD review of draft-ietf-pce-pcep-mib X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 10 Aug 2014 11:44:22 -0000 Hello authors, This is very substantial and detailed piece of work. Many thanks for the considerable effort it represents. I have done my usual AD review of this document in order to process the publication request. The purpose of the review is to catch any issues that might otherwise show up in IETF last call or IESG review, and to ensure that I can fully support the document. I'm glad to hear that there are implementations underlying this work and that should be used as a moderating influence on my comments and questions. For many of the points I raise it may be OK to answer "We have thought about it, but this is how we chose to implement it." Please look through the comments and let me know your thoughts either by providing a new revision, or by answering via email. Thanks for the work, Adrian ===== Section 1 para 2 The PCE communication protocol (PCEP) The convention these days seems to be "Path Computation Element Communications Protocol" or "Path Computation Element communications Protocol". You might apply that to the document title as well. --- Section 1 The PCE communication protocol (PCEP) is the communication protocol between a PCC and PCE for point-to-point (P2P) path computations and is defined in [RFC5440]. That reference to P2P seemed odd to me. Any reason to include it? In particular, nothing in this module appears to be specific to whether P2P or P2MP request are being supported. --- That previous point does cause me to wonder about "PCE capabilities". I can see that you have tried to limit this module to describing the features that are core to 5440, but I wonder whether that is wise. For example, RFCs 5088 and 5089 define a set of PCE capabilities that may be advertised in the IGPs and are surely relevant to the model of a PCE that speaks PCEP. That information might usefully be seen in the module at the PCE, and also at the PCC so that an operator can check "why does that PCC keep sending these requests to the wrong PCE?" Similarly, the Open Object can carry TLVs that indicate further capabilities. Obviously you can't just include all future capabilities TLVs since you don't know what they are (well, you know some, but that have already been defined, but you can't know the undefined ones). But you might want to to look at how those capabilities will be hooked in for future accessibility. Of particular interest will be the OF-list TLV of RFC 5541. --- Convention has it that you have written a "MIB module" which is part of "the MIB", so can you look through the document and mainly change "MIB" to "MIB module". --- I'm wondering under what circumstances the pcepEntityTable has more than one entry. You might describe that in 4.1 and also in the Description clause for the table. That would tie in with explaining why you have an index of Unsigned32 (1..2147483647) which allows for quite a lot of entities! For a moment I thought that maybe there would be one entry when acting as PCE and one when acting as PCC (i.e., a max of 2 < 2147483647) but there is no mode field in the entityTable, only the peerTable. Actually, I'm a bit confused about the indexing of the three tables. I think you think that every PCE and PCC in the network shows in the entityTable. But that isn't how you have set up the entityTable to contain information that is about the local PCEP entity/entities. So my confusion... Now, looking at the indexes to pcePcepPeerTable. There are two questions. 1. Why do you use pcePcepEntityIndex as an index? It points back into entityTable which we have established is basically the local PCEP speaker or which there is probably just one. The text in 4.2 says... The pcePcepPeerTable contains one row for each PCEP peer that the PCEP entity (PCE or PCC) knows about. I think your intention is that pcePcepEntityIndex is different for each peer. But pcePcepEntityIndex is the index to PcePcepEntityTable which is full of local PCEP entity information and (I suspect) will only ever have one entry. Shouldn't the peerTable have its own unique index for each peer? 2. Making pcePcepPeerAddrType and pcePcepPeerAddr indexes as well would appear to allow two or more entries for the same peer with different addresses. Is that the intention? If so, you might make it clear in section 4.2. And you would also need to make clear that there is an expectation that an implementation will assign the same value of pcePcepEntityIndex (or the new per-peer index) to each table entry that represents the same peer. OTOH, if a peer has multiple addresses, will this allow you to have multiple sessions to the same peer. Is that what you intended? Alternatively, it seems unlikely that two different peers will have the same address. So why is any additional index (i.e., pcePcepEntityIndex) needed? The same questions apply to the indexing of pcePcepSessTable although pcePcepSessInitiator is understandable. The solution to all this will be: - Decide how many entries you really expect in entityTable. - Decide whether entries in peerTable and sessTable should be indexed from entityTable, or with an index from peerTable. --- A small worked example would be cool (either between Sections 4 and 5, or in an Appendix). I would draw a figure such as: PCE1---PCE2 PCE3 | / | / | | / | / | PCCa/ PCCb PCCc ...and give an example of the module as read at PCE2 and PCCb. --- The OID structure is unusual. I'm not saying it is wrong, but it is different around pcePcepObjects. It would probably help to include a diagrammatic representation. I think you have something like the following. (BTW, the "unusual" is the additional indirection between pcePcepObjects and the various tables.) mib-2 | |--- XXX pcePcepMIB | |--- 0 pcePcepNotifications | | | |--- 1 pcePcepSessUp | : : | |--- 1 pcePcepObjects | | | |--- 1 pcePcepEntityObjects | | | | | |--- 1 pcePcepEntityTable | | | |--- 2 pcePcepPeerObjects | | | | | |--- 1 pcePcepPeerTable | | | |--- 3 pcePcepSessObjects | | | |--- 1 pcePcepSessTable | |--- 2 pcePcepConformance | |--- 1 pcePcepCompliances |--- 2 pcePcepGroups --- I'd also like to see a short section (probably just containing a figure) that shows the relationship between the three tables in this module. It can't be complex (there are only three tables!), but a figure that shows which objects in which tables lead you to find rows in other tables would be a help. And where the relationship is shared indexes or augmentation that can be called out. --- I am quite happy that this module is entirely read-only. But it makes some of the "usual" objects a little odd without additional information in their Description clauses. For example, pcePcepEntityAdminStatus says "The administrative status of this PCEP Entity." That is fine, but what does it mean? You could probably add: "... This is the desired operational status as currently set by an operator or by default in the implementation. The value of pcePcepEntityOperStatus represents the current status of an attempt to reach this desired status." --- I like the values you have offered in pcePcepEntityOperStatus A common accompaniment to the failure cases (and maybe the inactive / deactivating cases) is an unformatted reason string. Did you consider adding one of these? --- Do you support values of pcePcepEntityAddrType other than ipv4(1) and ipv6(2)? Maybe unknown(0) is used when pcePcepEntityAddr has not been set up? If there is some limit on the full range of values from the Syntax InetAddressType you should: - say so in the Description clause - say so in the Conformance statement. That will make the text in pcePcepEntityAddr easier to cope with unchanged. --- Just asking... Is there a value of pcePcepEntityConnectTimer that means "never give up"? You could use zero if you wanted to, but you don't have to. (18 hours is probably long enough.) --- Similar for pcePcepEntityConnectMaxRetry Is there a value that means continue indefinitely? Although 2^32 attempts sounds like quite a few. The Description for this object says "...before going back to the Idle state." Could you reference that back to an object (presumably in the peerTable since the entry in the sessTable does not exist in idle state) and the associated value. --- pcePcepEntityOpenWaitTimer same question about "wait forever". Also, perhaps clarify that this is the time after the TCP connection has come up. I know the protocol spec makes this clear, but "...aborts the session setup attempt" could be enhanced with "...terminates the TCP connection and removes the associate entry from the sessTable" --- pcePcepEntityDeadTimer is recommended to be 4 times the pcePcepEntityKeepAliveTimer value. I don't think that giving this advice is helpful since this object is read-only and can only report the configured (through other means) value. --- pcePcepEntityMaxDeadTimer DESCRIPTION "The maximum value that this PCEP entity will accept from a peer for the Dead timer. Zero means that the PCEP entity will allow not running a Dead timer. A Dead timer will not be accepted unless it is both greater than the session Keepalive timer and less than this field." Are you sure? Where does a zero Dead timer fit with that statement? --- pcePcepEntityAllowNegotiation seems out of order in amidst the various timer objects. Not important, but odd. --- pcePcepEntityMinDeadTimer OBJECT-TYPE DESCRIPTION "In PCEP session parameter negotiation, the minimum value that this PCEP entity will accept for the Dead timer. Zero means that the PCEP entity insists on not running a Dead timer. A Dead timer will not be accepted unless it is both greater than the session Keepalive timer and greater than this field." Again, the second paragraph seems to conflict with the use of zero. --- pcePcepEntitySyncTimer needs to clarify that this object only has meaning if the entity is a PCE. So you should give a value that a PCC can return in this object, or say that a PCC should not return this object. Furthermore, the syncTimer is only recommended in RFC 5440. How should an implementation that does not implement a syncTimer return this object? --- The backoff timer objects (pcePcepEntityInitBackoffTimer and pcePcepEntityMaxBackoffTimer) might be better grouped next to the other session-related timers (especially the OpenTimer). --- pcePcepEntityMaxUnknownReqs OBJECT-TYPE DESCRIPTION "The maximum number of unrecognized requests and replies that any session on this PCEP entity is willing to accept per minute. pcePcepEntityMaxUnknownMsgs OBJECT-TYPE DESCRIPTION "The maximum number of unknown messages that any session on this PCEP entity is willing to accept per minute." ...before doing what? --- Same issue wrt pcePcepPeerAddrType as for pcePcepEntityAddrType --- In pcePcepPeerRole it might be more usual to have unknown(0). --- It is not clear (to me) whether pcePcepPeerNumSessSetupFail is incremented each time a retry fails or only each time a session set-up attempt is abandoned. --- pcePcepPeerSessionFailTime DESCRIPTION "The value of sysUpTime the last time a session with this peer failed to be established. This is consistent with other fields, but does not record a session that was up, but then failed. --- Now, I'll grant that pcePcepEntityMaxUnknownMsgs allows for a remarkably high rate of receipt of unknown messages with... SYNTAX Unsigned32 DESCRIPTION "The maximum number of unknown messages that any session on this PCEP entity is willing to accept per minute." But, given that rate, it seems that pcePcepPeerNumUnknownRcvd could overflow within just one minute. SYNTAX Counter32 DESCRIPTION "The number of unknown messages received from this peer." The same is going to apply to pcePcepEntityMaxUnknownReqs and pcePcepPeerNumReqRcvdUnknown. Also, of course, the same applies to the counters in the sessTable. --- Many of the same comments apply to the objects in the sessEntry as applied to the peerEntry and entityEntry, and I won't repeat them here. --- I don't think pcePcepSessOverloadTime and pcePcepSessPeerOverloadTime are very useful. The values are presumably stored from sent or received OVERLOADED-DURATION TLVs in PCNtf messages that indicate 'Overloaded'. However, if I come and look at the object some time later I have no idea how much longer the overloaded state may last. I think you need (I use the peer as an example) pcePcepSessPeerOverload TruthValue Whether or not this peer is overloaded. pcePcepSessPeerLastOverloaded Timestamp Time at which last overload event occurred for this peer. Not cleared when pcePcepSessPeerOverload becomes false. pcePcepSessPeerLastOverloadTime Unsigned32 Duration of last overload event for this peer. Not cleared when pcePcepSessPeerOverload becomes false. --- Although this is carefully a read-only MIB module, I wonder whether you need a way to quiesce the Notifications issued by an implementation. Something like... pcePcepNotificationsMaxRate OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This variable indicates the maximum number of notifications issued per second. If events occur more rapidly, the implementation may simply fail to emit these notifications during that period, or may queue them until an appropriate time. A value of 0 means no notifications are emitted and all should be discarded (i.e., not queued)." ...or... pcePcepNotificationsEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "If this object is true, then it enables the generation of notifications." Without one of these, your management station will be bombed with Notifications from the PCCs in the network. From nobody Sun Aug 10 20:53:27 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4DF41A02CB; Sun, 10 Aug 2014 20:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAEm8y3hox1w; Sun, 10 Aug 2014 20:53:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1F31A02BC; Sun, 10 Aug 2014 20:53:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140811035318.657.72376.idtracker@ietfa.amsl.com> Date: Sun, 10 Aug 2014 20:53:18 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/wKWmehGj2Z7H5H5ZQfWGVKgrTGI Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-pcep-service-aware-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 03:53:21 -0000 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) to compute service aware Label Switched Path (LSP). Authors : Dhruv Dhody Vishwas Manral Zafar Ali George Swallow Kenji Kumaki Filename : draft-ietf-pce-pcep-service-aware-05.txt Pages : 19 Date : 2014-08-10 Abstract: In certain networks like financial information network (stock/ commodity trading) and enterprises using cloud based applications, Latency (delay), Latency-Variation (jitter) and Packet Loss is becoming a key requirement for path computation along with other constraints and metrics. Latency, Latency-Variation and Packet Loss is associated with the Service Level Agreement (SLA) between customers and service providers. IGP Traffic Engineering (TE) Metric extensions describes mechanisms with which network performance information is distributed via OSPF and IS-IS respectively. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. This document describes the extension to PCEP to carry Latency, Latency-Variation and Packet Loss as constraints for end to end path computation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-service-aware/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-pcep-service-aware-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-service-aware-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Aug 10 21:05:46 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51A31A02C1 for ; Sun, 10 Aug 2014 21:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTqHG1eDmS3K for ; Sun, 10 Aug 2014 21:05:43 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B48131A02BD for ; Sun, 10 Aug 2014 21:05:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLC14307; Mon, 11 Aug 2014 04:05:41 +0000 (GMT) Received: from SZXEML451-HUB.china.huawei.com (10.82.67.194) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 11 Aug 2014 05:05:40 +0100 Received: from szxeml556-mbs.china.huawei.com ([169.254.4.229]) by szxeml451-hub.china.huawei.com ([10.82.67.194]) with mapi id 14.03.0158.001; Mon, 11 Aug 2014 12:05:31 +0800 From: Dhruv Dhody To: "pce@ietf.org" Thread-Topic: [Pce] I-D Action: draft-ietf-pce-pcep-service-aware-05.txt Thread-Index: AQHPtRflth1s7WxEvEW2NrDpwNeyU5vKxbmg Date: Mon, 11 Aug 2014 04:05:30 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B865CDA4B@szxeml556-mbs.china.huawei.com> References: <20140811035318.657.72376.idtracker@ietfa.amsl.com> In-Reply-To: <20140811035318.657.72376.idtracker@ietfa.amsl.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.146.248] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pce/Zg3a9wVh_XYrLKWVbrJYZk53VRg Subject: Re: [Pce] I-D Action: draft-ietf-pce-pcep-service-aware-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 04:05:44 -0000 Hi All,=20 With this update in the I.D., we have -=20 ~ Removed any code points from the I.D. TBA by IANA and corresponding updat= e in the IANA section. ~ Objective Function: Adding a new objective function to minimize packet lo= ss called MPLP (Minimum Packet Loss Path).=20 As this is the only technical change, I am listing it right here for a qu= ick look: o A network comprises a set of N links {Li, (i=3D1...N)}. o A path P is a list of K links {Lpi,(i=3D1...K)}. o Packet loss of link L is denoted PL(L) in percentage. o Packet loss in fraction of link L is denoted FPL(L) =3D PL(L) / 100. o The Packet loss of a path P (in percentage) is denoted PL(P), where PL(P) =3D (1 - ((1-FPL(Lp1)) * (1-FPL(Lp2)) * .. * (1-FPL(LpK))) * 100. Objective Function Code: (TBA - IANA) Name: Minimum Packet Loss Path (MPLP) Description: Find a path P such that PL(P) is minimized. =20 ~ Editorial Changes: Removing reference from abstract; changing reference n= ames; etc Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-pcep-service-aware-= 05 We currently have no open issues in the draft. On behalf of the co-authors and contributors, we request WG to look at the = document and provide us with any comments/suggestion to help progress the d= raft. Regards, Dhruv =20 > -----Original Message----- > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org > Sent: 11 August 2014 09:23 > To: i-d-announce@ietf.org > Cc: pce@ietf.org > Subject: [Pce] I-D Action: draft-ietf-pce-pcep-service-aware-05.txt >=20 >=20 > 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. >=20 > Title : Extensions to the Path Computation Element > Communication Protocol (PCEP) to compute service aware Label Switched Pat= h > (LSP). > Authors : Dhruv Dhody > Vishwas Manral > Zafar Ali > George Swallow > Kenji Kumaki > Filename : draft-ietf-pce-pcep-service-aware-05.txt > Pages : 19 > Date : 2014-08-10 >=20 > Abstract: > In certain networks like financial information network (stock/ > commodity trading) and enterprises using cloud based applications, > Latency (delay), Latency-Variation (jitter) and Packet Loss is > becoming a key requirement for path computation along with other > constraints and metrics. Latency, Latency-Variation and Packet Loss > is associated with the Service Level Agreement (SLA) between > customers and service providers. >=20 > IGP Traffic Engineering (TE) Metric extensions describes mechanisms > with which network performance information is distributed via OSPF > and IS-IS respectively. The Path Computation Element Communication > Protocol (PCEP) provides mechanisms for Path Computation Elements > (PCEs) to perform path computations in response to Path Computation > Clients (PCCs) requests. This document describes the extension to > PCEP to carry Latency, Latency-Variation and Packet Loss as > constraints for end to end path computation. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-service-aware/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-pce-pcep-service-aware-05 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-pcep-service-aware-05 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From nobody Mon Aug 11 08:59:12 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACAE31A0696; Mon, 11 Aug 2014 08:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDQnuVhwaB6O; Mon, 11 Aug 2014 08:59:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C67601A0689; Mon, 11 Aug 2014 08:59:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liaison Statement Management Tool To: JP Vasseur , Julien Meuric X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140811155908.3937.65072.idtracker@ietfa.amsl.com> Date: Mon, 11 Aug 2014 08:59:08 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/eQkckJDkflEv-MvixMnYffv5c9E Cc: pce@ietf.org Subject: [Pce] New Liaison Statement, "Liaison from IEEE 802.1 to IETF PCE WG " X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 15:59:10 -0000 Title: Liaison from IEEE 802.1 to IETF PCE WG Submission Date: 2014-08-11 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1344/ From: IEEE 802.1 (Glenn Parsons ) To: Path Computation Element (JP Vasseur , Julien Meuric ) Cc: Adrian Farrel ,Alia Atlas ,pce@ietf.org,Eric Gray Response Contact: Technical Contact: Purpose: For information Body: Attachments: Liaison from IEEE 802.1 to IETF PCE WG https://datatracker.ietf.org/documents/LIAISON/liaison-2014-08-11-ieee-8021-pce-liaison-from-ieee-8021-to-ietf-pce-wg-attachment-1.zip From nobody Mon Aug 11 09:23:46 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC5D1A06A4; Mon, 11 Aug 2014 09:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSUdoneiaPnU; Mon, 11 Aug 2014 09:23:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 466DC1A069A; Mon, 11 Aug 2014 09:23:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liaison Statement Management Tool To: The IETF Chair X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140811162343.19896.27284.idtracker@ietfa.amsl.com> Date: Mon, 11 Aug 2014 09:23:43 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/tCIrF2xcDBGGcfFcfB7Go_x5cGw Cc: chopps@rawdofmt.org, isis-wg@ietf.org, jpv@cisco.com, pce@ietf.org, The IESG , hannes@juniper.net Subject: [Pce] New Liaison Statement, "Liaison to the IETF from IEEE 802.1 on P802.1Qca" X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 16:23:44 -0000 Title: Liaison to the IETF from IEEE 802.1 on P802.1Qca Submission Date: 2014-08-11 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1345/ From: IEEE 802.1 (Glenn Parsons ) To: The IETF (The IETF Chair ) Cc: The IESG ,Eric Gray ,hannes@juniper.net,chopps@rawdofmt.org,jpv@cisco.com,julien.meuric@orange.com,pce@ietf.org,isis-wg@ietf.org Response Contact: Technical Contact: Purpose: For information Body: Attachments: Liaison to the IETF from IEEE 802.1 on P802.1Qca https://datatracker.ietf.org/documents/LIAISON/liaison-2014-08-11-ieee-8021-the-ietf-liaison-to-the-ietf-from-ieee-8021-on-p8021qca-attachment-1.zip From nobody Mon Aug 11 19:13:47 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891FF1A00AB for ; Mon, 11 Aug 2014 19:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OBQJsRA3M8N for ; Mon, 11 Aug 2014 19:13:45 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0687B1A00A5 for ; Mon, 11 Aug 2014 19:13:44 -0700 (PDT) Received: by mail-ig0-f170.google.com with SMTP id h3so6620938igd.1 for ; Mon, 11 Aug 2014 19:13:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=tahWcglMmh5Evj3Ew67DaVPZW2dvtR+X7SkotJIbidI=; b=QVSqf5snUOFUO+YuENiP1PzPPKk5BKc3QKoM2/S0WFPKfGrvnAXDEMPgommK/FgBIg x07BXgIvGY6c4MqmgJZZ3s5iYCsRlbwqCDgpCcgLfqhJnGu003d4WgJi/Mvkd0ArO8D0 0AWCi4RNRjzfByHF5yXDzgkCfShjgaa+j2NxWsSI8v+bEzdRxKE+oeKVIguLze/kqIIi 5zdQNc9Hwu9qSKKWp2g4BgOr8y/h+xDuI8320RR70melxqHmTG3nm9jI6424orXXi1IK +xVJi6vtQm2JBVaNEqlDtKinzShCuM78sscesyDMrpjR4E5DcEpokx9HLBjIgs7zn4v9 8q+Q== MIME-Version: 1.0 X-Received: by 10.42.101.77 with SMTP id d13mr38684906ico.53.1407809624397; Mon, 11 Aug 2014 19:13:44 -0700 (PDT) Received: by 10.50.26.74 with HTTP; Mon, 11 Aug 2014 19:13:44 -0700 (PDT) In-Reply-To: <20140811071648.11509.38896.idtracker@ietfa.amsl.com> References: <20140811071648.11509.38896.idtracker@ietfa.amsl.com> Date: Tue, 12 Aug 2014 07:43:44 +0530 Message-ID: From: Dhruv Dhody To: "pce@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/JOUXuemjxBvEadzHntecH1i_4eg Subject: [Pce] Fwd: New Version Notification for draft-dhody-pce-recv-srlg-02.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 02:13:46 -0000 Hi WG, We have updated the draft about receiving SRLG information of a path in PCRep during path computation process. The main change is to align it to the latest version of draft-ietf-ccamp-rsvp-te-srlg-collect. Regards, Dhruv ---------- Forwarded message ---------- From: Date: Mon, Aug 11, 2014 at 12:46 PM Subject: New Version Notification for draft-dhody-pce-recv-srlg-02.txt To: Oscar Gonzalez de Dios , Fatai Zhang , Dhruv Dhody , Xian Zhang , Victor Lopezalvarez A new version of I-D, draft-dhody-pce-recv-srlg-02.txt has been successfully submitted by Dhruv Dhody and posted to the IETF repository. Name: draft-dhody-pce-recv-srlg Revision: 02 Title: PCEP Extensions for Receiving SRLG Information Document date: 2014-08-11 Group: Individual Submission Pages: 11 URL: http://www.ietf.org/internet-drafts/draft-dhody-pce-recv-srlg-02.txt Status: https://datatracker.ietf.org/doc/draft-dhody-pce-recv-srlg/ Htmlized: http://tools.ietf.org/html/draft-dhody-pce-recv-srlg-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-dhody-pce-recv-srlg-02 Abstract: The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering (TE) in networks controlled by Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS). This document provides extensions for the Path Computation Element Protocol (PCEP) to receive Shared Risk Link Group (SRLG) information during path computation via encoding this information in the path computation reply message. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Thu Aug 14 03:58:56 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7CC71A0765 for ; Thu, 14 Aug 2014 03:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.169 X-Spam-Level: X-Spam-Status: No, score=-1.169 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KADJYN-khAZp for ; Thu, 14 Aug 2014 03:58:46 -0700 (PDT) Received: from ENFIRHETS1.metaswitch.com (enfirhets1.metaswitch.com [192.91.191.166]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F36ED1A068E for ; Thu, 14 Aug 2014 03:58:44 -0700 (PDT) Received: from ENFIRHCAS1.datcon.co.uk (172.18.209.38) by ENFIRHETS1.metaswitch.com (172.18.209.22) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 14 Aug 2014 11:58:39 +0100 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHCAS1.datcon.co.uk ([fe80::85a7:aa4e:2516:c2ad%11]) with mapi id 14.03.0195.001; Thu, 14 Aug 2014 11:58:43 +0100 From: Jonathan Hardwick To: "adrian@olddog.co.uk" Thread-Topic: [Pce] AD review of draft-ietf-pce-pcep-mib Thread-Index: Ac+0kGZWlNyMwNUoRsOh1m8y7uUVSQDCBy3A Date: Thu, 14 Aug 2014 10:58:43 +0000 Message-ID: <09CE6C3BE5E1EA40B987BF5F25D8DDBAF4E68BE5@ENFICSMBX1.datcon.co.uk> References: <000301cfb490$68af4140$3a0dc3c0$@olddog.co.uk> In-Reply-To: <000301cfb490$68af4140$3a0dc3c0$@olddog.co.uk> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.72.23] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/hFU2RFQ9mFMvgBYWXeIb-dUDhvo Cc: "draft-ietf-pce-pcep-mib.all@tools.ietf.org" , "pce@ietf.org" Subject: Re: [Pce] AD review of draft-ietf-pce-pcep-mib X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 10:58:51 -0000 Hi Adrian Many thanks for your detailed review and comments. The authors discussed y= our comments on a conference call on Wednesday. I have provided our consol= idated replies below as >> ... <<. We will produce a new version of the draft to address your comments. Thanks again Jon + authors -----Original Message----- From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: 10 August 2014 12:44 To: draft-ietf-pce-pcep-mib.all@tools.ietf.org Cc: pce@ietf.org Subject: [Pce] AD review of draft-ietf-pce-pcep-mib =3D=3D=3D=3D=3D Section 1 para 2 The PCE communication protocol (PCEP) The convention these days seems to be "Path Computation Element Communications Protocol" or "Path Computation Element communications Protocol". You might apply that to the document title as well. >> Agree. We will update as necessary. << --- Section 1 The PCE communication protocol (PCEP) is the communication protocol between a PCC and PCE for point-to-point (P2P) path computations and is defined in [RFC5440]. That reference to P2P seemed odd to me. Any reason to include it? In particular, nothing in this module appears to be specific to whether P2P or P2MP request are being supported. >> Agree. We will update as necessary. << --- That previous point does cause me to wonder about "PCE capabilities". I can see that you have tried to limit this module to describing the features that are core to 5440, but I wonder whether that is wise. For example, RFCs 5088 and 5089 define a set of PCE capabilities that may be advertised in the IGPs and are surely relevant to the model of a PCE that speaks PCEP. That information might usefully be seen in the module at the PCE, and also at the PCC so that an operator can check "why does that PCC keep sending these requests to the wrong PCE?" Similarly, the Open Object can carry TLVs that indicate further capabilities. Obviously you can't just include all future capabilities TLVs since you don't know what they are (well, you know some, but that have already been defined, but you can't know the undefined ones). But you might want to to look at how those capabilities will be hooked in for future accessibility. Of particular interest will be the OF-list TLV of RFC 5541. >> The scope of the PCEP MIB is currently limited to objects that are core = to RFC 5440 only. - The capabilities from RFC 5088/5089 belong in the PCE discovery MIB. - The OFs in the OF-list TLV deserve their own MIB table, which could be d= efined in a separate MIB if anyone wants it. - There are lots of other PCEP RFCs that we could bring into the scope of = this document, but it is already quite large. Our preference is to clarify the scope of this document, provide an informa= tional reference to the discovery MIB, and allow other documents to augment= / supplement the tables we have defined. << --- Convention has it that you have written a "MIB module" which is part of "the MIB", so can you look through the document and mainly change "MIB" to "MIB module". >> Agree. We will update accordingly. << --- I'm wondering under what circumstances the pcepEntityTable has more than one entry. You might describe that in 4.1 and also in the Description clause for the table. That would tie in with explaining why you have an index of Unsigned32 (1..2147483647) which allows for quite a lot of entities! >> There is one row in this table for each local PCEP entity, of which ther= e may be multiple. One scenario is partitioning a physical router into multiple virtual router= s, each with its own PCC. Another scenario is managing a device which front= -ends multiple PCE compute resources, each with a different set of capabili= ties that are accessed via different IP addresses. Although there clearly won't be billions, we feel there's no point in placi= ng an arbitrary upper limit on the number of local PCEP entities. Our propo= sal, therefore, is to remove the artificial restriction on the entity index= range. << For a moment I thought that maybe there would be one entry when acting as PCE and one when acting as PCC (i.e., a max of 2 < 2147483647) but there is no mode field in the entityTable, only the peerTable. >> A single entity can be both PCC and PCE. << Actually, I'm a bit confused about the indexing of the three tables. I think you think that every PCE and PCC in the network shows in the entityTable. But that isn't how you have set up the entityTable to contain information that is about the local PCEP entity/entities. So my confusion... Now, looking at the indexes to pcePcepPeerTable. There are two questions. 1. Why do you use pcePcepEntityIndex as an index? It points back into entityTable which we have established is basically the local PCEP speaker or which there is probably just one. >> Each local PCEP entity has its own set of peers. A given remote PCEP sp= eaker may be a peer of more than one of the local PCEP entities in the pcep= EntityTable, so the pcePcepEntityIndex is needed to differentiate the infor= mation that is recorded for the remote PCEP speaker by each of the local PC= EP entities. << The text in 4.2 says... The pcePcepPeerTable contains one row for each PCEP peer that the PCEP entity (PCE or PCC) knows about. I think your intention is that pcePcepEntityIndex is different for each peer. But pcePcepEntityIndex is the index to PcePcepEntityTable which is full of local PCEP entity information and (I suspect) will only ever have one entry. >> No, pcePcepEntityIndex is the same for each peer that is a peer of a giv= en local PCEP entity. << Shouldn't the peerTable have its own unique index for each peer? >> It does - see below. << 2. Making pcePcepPeerAddrType and pcePcepPeerAddr indexes as well would appear to allow two or more entries for the same peer with different addresses. Is that the intention? If so, you might make it clear in section 4.2. And you would also need to make clear that there is an expectation that an implementation will assign the same value of pcePcepEntityIndex (or the new per-peer index) to each table entry that represents the same peer. >> Yes, that's the intention. To be clear, we believe that a PCEP speaker = is identified in the network by its IP address. The rationale is as follows. If you have a single box that is speaking PCE= P using two different IP addresses then that box looks like two distinct pe= ers to the other PCEP speakers in the network. RFC 5440 gives no way to de= tect that this is in fact a single box, and it gives no mechanism to preven= t you from connecting to that box on both of its IP addresses. << OTOH, if a peer has multiple addresses, will this allow you to have multiple sessions to the same peer. Is that what you intended? >> Yes << Alternatively, it seems unlikely that two different peers will have the same address. So why is any additional index (i.e., pcePcepEntityIndex) needed? >> If there are two local PCEP entities connected to the same PCEP speaker = then there will be two rows in peerTable (and sessTable) with the same pceP= cepPeerAddrType and pcePcepPeerAddr indexes. << The same questions apply to the indexing of pcePcepSessTable although pcePcepSessInitiator is understandable. The solution to all this will be: - Decide how many entries you really expect in entityTable. >> Multiple << - Decide whether entries in peerTable and sessTable should be indexed from entityTable, or with an index from peerTable. >> Indexed first by local entity index, then by remote peer IP address << --- A small worked example would be cool (either between Sections 4 and 5, or in an Appendix). I would draw a figure such as: PCE1---PCE2 PCE3 | / | / | | / | / | PCCa/ PCCb PCCc ...and give an example of the module as read at PCE2 and PCCb. >> Agreed, we will include the example in the Appendix. << --- The OID structure is unusual. I'm not saying it is wrong, but it is different around pcePcepObjects. It would probably help to include a diagrammatic representation. I think you have something like the following. (BTW, the "unusual" is the additional indirection between pcePcepObjects and the various tables.) mib-2 | |--- XXX pcePcepMIB | |--- 0 pcePcepNotifications | | | |--- 1 pcePcepSessUp | : : | |--- 1 pcePcepObjects | | | |--- 1 pcePcepEntityObjects | | | | | |--- 1 pcePcepEntityTable | | | |--- 2 pcePcepPeerObjects | | | | | |--- 1 pcePcepPeerTable | | | |--- 3 pcePcepSessObjects | | | |--- 1 pcePcepSessTable | |--- 2 pcePcepConformance | |--- 1 pcePcepCompliances |--- 2 pcePcepGroups >> Agreed, the extra indirection serves no purpose. We will update by remo= ving pcePcepEntityObjects, pcePcepPeerObjects and pcePcepSessObjects so tha= t pcePcepEntityTable, pcePcepPeerTable and pcePcepSessTable are grouped dir= ectly under pcePcepObjects. << --- I'd also like to see a short section (probably just containing a figure) that shows the relationship between the three tables in this module. It can't be complex (there are only three tables!), but a figure that shows which objects in which tables lead you to find rows in other tables would be a help. And where the relationship is shared indexes or augmentation that can be called out. >> We will provide an example with ASCII illustration. This will be inserte= d in Section 4 - PCEP MIB Module Architecture. << --- I am quite happy that this module is entirely read-only. But it makes some of the "usual" objects a little odd without additional information in their Description clauses. For example, pcePcepEntityAdminStatus says "The administrative status of this PCEP Entity." That is fine, but what does it mean? You could probably add: "... This is the desired operational status as currently set by an operator or by default in the implementation. The value of pcePcepEntityOperStatus represents the current status of an attempt to reach this desired status." >> Agree. We'll include the suggested text and review the other fields to c= lean up any other instances. << --- I like the values you have offered in pcePcepEntityOperStatus A common accompaniment to the failure cases (and maybe the inactive / deactivating cases) is an unformatted reason string. Did you consider adding one of these? >> This is an interesting idea. We would prefer to use SNMP for reporting = status and to use other available interfaces to provide more detailed loggi= ng / reason strings. << --- Do you support values of pcePcepEntityAddrType other than ipv4(1) and ipv6(2)? Maybe unknown(0) is used when pcePcepEntityAddr has not been set up? If there is some limit on the full range of values from the Syntax InetAddressType you should: - say so in the Description clause - say so in the Conformance statement. That will make the text in pcePcepEntityAddr easier to cope with unchanged. >> Agree to this. There is a similar case in RFC 6825 that we can base this= on. << --- Just asking... Is there a value of pcePcepEntityConnectTimer that means "never give up"? You could use zero if you wanted to, but you don't have to. (18 hours is probably long enough.) >> After discussion the implementers feel they would not want to use a "nev= er give up" option. Same for the similar comments below. << --- Similar for pcePcepEntityConnectMaxRetry Is there a value that means continue indefinitely? Although 2^32 attempts sounds like quite a few. >> Again no - as above. << The Description for this object says "...before going back to the Idle state." Could you reference that back to an object (presumably in the peerTable since the entry in the sessTable does not exist in idle state) and the associated value. >> Agree, we will update the text. << --- pcePcepEntityOpenWaitTimer same question about "wait forever". >> Again no - as above. << Also, perhaps clarify that this is the time after the TCP connection has come up. I know the protocol spec makes this clear, but "...aborts the session setup attempt" could be enhanced with "...terminates the TCP connection and removes the associate entry from the sessTable" >> Agree, we will update the text. << --- pcePcepEntityDeadTimer is recommended to be 4 times the pcePcepEntityKeepAliveTimer value. I don't think that giving this advice is helpful since this object is read-only and can only report the configured (through other means) value. >> Agree, no point in stating this. We will update. << --- pcePcepEntityMaxDeadTimer DESCRIPTION "The maximum value that this PCEP entity will accept from a peer for the Dead timer. Zero means that the PCEP entity will allow not running a Dead timer. A Dead timer will not be accepted unless it is both greater than the session Keepalive timer and less than this field." Are you sure? Where does a zero Dead timer fit with that statement? >> Agree that zero is not covered by the final sentence. We'll delete the = final sentence as it adds nothing. << --- pcePcepEntityAllowNegotiation seems out of order in amidst the various timer objects. Not important, but odd. >> Agree, we will reorder so pcePcepEntityAllowNegotiation appears before p= cePcepEntityMaxKeepAliveTimer. << --- pcePcepEntityMinDeadTimer OBJECT-TYPE DESCRIPTION "In PCEP session parameter negotiation, the minimum value that this PCEP entity will accept for the Dead timer. Zero means that the PCEP entity insists on not running a Dead timer. A Dead timer will not be accepted unless it is both greater than the session Keepalive timer and greater than this field." Again, the second paragraph seems to conflict with the use of zero. >> Agree that zero is not covered by the final sentence. We'll delete the = final sentence as it adds nothing. << --- pcePcepEntitySyncTimer needs to clarify that this object only has meaning if the entity is a PCE. >> Agree << So you should give a value that a PCC can return in this object, or say that a PCC should not return this object. Furthermore, the syncTimer is only recommended in RFC 5440. How should an implementation that does not implement a syncTimer return this object? >> We will extend the allowed range for this field to include zero, and sta= te that zero must be returned if and only if the entity does not use the sy= ncTimer. << --- The backoff timer objects (pcePcepEntityInitBackoffTimer and pcePcepEntityMaxBackoffTimer) might be better grouped next to the other session-related timers (especially the OpenTimer). >> Agree, we will update accordingly << --- pcePcepEntityMaxUnknownReqs OBJECT-TYPE DESCRIPTION "The maximum number of unrecognized requests and replies that any session on this PCEP entity is willing to accept per minute. pcePcepEntityMaxUnknownMsgs OBJECT-TYPE DESCRIPTION "The maximum number of unknown messages that any session on this PCEP entity is willing to accept per minute." ...before doing what? >> Before terminating the session. We will clarify the text. << --- Same issue wrt pcePcepPeerAddrType as for pcePcepEntityAddrType >> Agree. We will update accordingly << --- In pcePcepPeerRole it might be more usual to have unknown(0). >> Agree. We will update accordingly << --- It is not clear (to me) whether pcePcepPeerNumSessSetupFail is incremented each time a retry fails or only each time a session set-up attempt is abandoned. >> It's the former - each time a retry fails. We'll clarify this. << --- pcePcepPeerSessionFailTime DESCRIPTION "The value of sysUpTime the last time a session with this peer failed to be established. This is consistent with other fields, but does not record a session that was up, but then failed. >> Agree, this is a gap. We will add a new object to cover this case, reco= rding the last time a session failed from active. << --- Now, I'll grant that pcePcepEntityMaxUnknownMsgs allows for a remarkably high rate of receipt of unknown messages with... SYNTAX Unsigned32 DESCRIPTION "The maximum number of unknown messages that any session on this PCEP entity is willing to accept per minute." But, given that rate, it seems that pcePcepPeerNumUnknownRcvd could overflow within just one minute. SYNTAX Counter32 DESCRIPTION "The number of unknown messages received from this peer." The same is going to apply to pcePcepEntityMaxUnknownReqs and pcePcepPeerNumReqRcvdUnknown. Also, of course, the same applies to the counters in the sessTable. >> We prefer no change here. Regardless of whether we impose a limit on Ma= xUnknownMsgs etc. we don't think there is a realistic prospect that these c= ounters will wrap on a timescale of less than months. Although configuring= 2^32 for MaxUnknownMsgs is clearly not meaningful, we don't think it's imp= ortant in practice to limit it to some arbitrary number. << --- Many of the same comments apply to the objects in the sessEntry as applied to the peerEntry and entityEntry, and I won't repeat them here. >> OK << --- I don't think pcePcepSessOverloadTime and pcePcepSessPeerOverloadTime are very useful. The values are presumably stored from sent or received OVERLOADED-DURATION TLVs in PCNtf messages that indicate 'Overloaded'. However, if I come and look at the object some time later I have no idea how much longer the overloaded state may last. I think you need (I use the peer as an example) pcePcepSessPeerOverload TruthValue Whether or not this peer is overloaded. pcePcepSessPeerLastOverloaded Timestamp Time at which last overload event occurred for this peer. Not cleared when pcePcepSessPeerOverload becomes false. pcePcepSessPeerLastOverloadTime Unsigned32 Duration of last overload event for this peer. Not cleared when pcePcepSessPeerOverload becomes false. >> Actually, pcePcepSessOverloadTime and pcePcepSessPeerOverloadTime are bo= th supposed to give the remaining interval of time until the overload clear= s. The MIB does not currently report the original value that was received = in the TLV. We will make the meaning of these fields clearer. We feel it = is not important to report the original value from the TLV, but please let = us know if you disagree. << --- Although this is carefully a read-only MIB module, I wonder whether you need a way to quiesce the Notifications issued by an implementation. Something like... pcePcepNotificationsMaxRate OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This variable indicates the maximum number of notifications issued per second. If events occur more rapidly, the implementation may simply fail to emit these notifications during that period, or may queue them until an appropriate time. A value of 0 means no notifications are emitted and all should be discarded (i.e., not queued)." ...or... pcePcepNotificationsEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "If this object is true, then it enables the generation of notifications." Without one of these, your management station will be bombed with Notifications from the PCCs in the network. >> Agreed. We will go for the max-rate option, for consistency with RFC 682= 5. << _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From nobody Thu Aug 14 04:28:03 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0A61A0A77 for ; Thu, 14 Aug 2014 04:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mT2tMcuplPgR for ; Thu, 14 Aug 2014 04:27:57 -0700 (PDT) Received: from ENFIRHETS1.metaswitch.com (enfirhets1.metaswitch.com [192.91.191.166]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 788F61A0A76 for ; Thu, 14 Aug 2014 04:27:57 -0700 (PDT) Received: from ENFIRHMBX1.datcon.co.uk (172.18.74.36) by ENFIRHETS1.metaswitch.com (172.18.209.22) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 14 Aug 2014 12:27:51 +0100 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHMBX1.datcon.co.uk ([fe80::b06d:4d13:5f63:3715%18]) with mapi id 14.03.0195.001; Thu, 14 Aug 2014 12:27:52 +0100 From: Jonathan Hardwick To: Dhruv Dhody Thread-Topic: Regarding draft-ietf-pce-pcep-mib-09 Thread-Index: AQHPq9afzHVhKP50lkqOvlKKCIpV55vQBmjQ Date: Thu, 14 Aug 2014 11:27:50 +0000 Message-ID: <09CE6C3BE5E1EA40B987BF5F25D8DDBAF4E68C88@ENFICSMBX1.datcon.co.uk> References: <23CE718903A838468A8B325B80962F9B865B4669@szxeml556-mbs.china.huawei.com> In-Reply-To: <23CE718903A838468A8B325B80962F9B865B4669@szxeml556-mbs.china.huawei.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.72.23] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/Wdt1LEyJGIdiguJRDc76O0A3pq4 Cc: "draft-ietf-pce-pcep-mib@tools.ietf.org" , "pce@ietf.org" Subject: Re: [Pce] Regarding draft-ietf-pce-pcep-mib-09 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 11:28:02 -0000 Hi Dhruv Thanks for the comments - see replies below (Jon> ...). I'll make sure the= se are addressed in the next revision. Cheers Jon -----Original Message----- From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Dhruv Dhody Sent: 31 July 2014 19:30 To: draft-ietf-pce-pcep-mib@tools.ietf.org Cc: pce@ietf.org Subject: [Pce] Regarding draft-ietf-pce-pcep-mib-09 Hi Authors,=20 I re-read the MIB document in preparation for the last call.=20 You may consider these comments/nits before or alongside the WG last call.= =20 - General=20 ~ Expand PCReq, PCRep, PCNtf, SVEC, RP etc on first use, using terminolog= y Section may also be useful.=20 Jon> OK.=20 ~ PCEP speaker and PCEP entity are used interchangeably, perhaps we can=20 unify? Jon> The aim is to use PCEP entity when referring specifically to a local e= ntity (that is, one that appears in the pcePcepEntityTable) and PCEP speake= r to refer more generally to any device that is speaking PCEP. I'll re-rev= iew and make sure there is consistency here. ~ a new object for corrupted messages (note that corrupted messages are=20 different from unknown messages and this cannot be derived from number = of error messages sent either). =09 Jon> Happy to have this - please could you propose some text? - Abstract Add MIB as the abbreviation Jon> OK =20 - Introduction Add TE as the abbreviation for Traffic Engineering =20 Jon> OK - Shouldn't Section 3 'Requirements Language' about RFC2119 keywords=20 be part of the introduction itself?=20 Jon> This boilerplate text is usually in its own section in my experience. =20 - Section 5.1 pcePcepEntityEntry OBJECT-TYPE SYNTAX PcePcepEntityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents a PCEP entity." INDEX { pcePcepEntityIndex } ::=3D { pcePcepEntityTable 1 } =20 ~ I think the description should not say 'this table' while describing=20 an entry. Also true for pcePcepSessEntry. Jon> Not sure I understand - why? =20 pcePcepEntityIndex OBJECT-TYPE SYNTAX Unsigned32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This index is used to uniquely identify the PCEP entity." ::=3D { pcePcepEntityEntry 1 } ~ Wouldnt Integer32 (1..2147483647) be a better fit? =20 Jon> We are removing the range restriction instead. Suggest to reorder pcePcepEntityMaxKeepAliveTimer,=20 pcePcepEntityMaxDeadTimer, pcePcepEntityAllowNegotiation, pcePcepEntityMinKeepAliveTimer, pcePcepEntityMinDeadTimer=20 =20 ~ by moving the pcePcepEntityAllowNegotiation first, you can use it in=20 the description for both max and min timers.=20 Jon> OK. =20 pcePcepEntitySyncTimer OBJECT-TYPE SYNTAX Unsigned32 (1..65535) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of SYNC timer is used in the case of synchronized path computation request using the SVEC object... ~ Use SyncTimer (as used in 5440) instead of SYNC timer. Jon> OK =20 pcePcepPeerNumSessSetupFail OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of PCEP sessions with the peer that have been attempted but failed before being fully estbalished. This counter is incremented each time a session with this peer fails before reaching session state pceSessionUp." ::=3D { pcePcepPeerEntry 8 } =20 ~ the state is called sessionUp (refer pcePcepSessState) and not=20 pceSessionUp Jon> OK =20 - Security Considerations You might think of removing the text about SET operation, as this=20 MIB is read-only.=20 You might also add reference to SNMPv3 security like USM with AES as=20 well to use of secure transport like SSH or TLS/DTLS.=20 Jon> How about the following change (plagiarising text from RFC 6825): OLD It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). NEW Implementations MUST provide the security features described by the SNMPv3 framework (see [RFC3410]), including full support for authentication and privacy via the User-based Security Model (USM) [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations MAY also provide support for the Transport Security Model (TSM) [RFC5591] in combination with a secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353]. Thank You!=20 Dhruv =20 =20 =20 =20 =20 =20 =20 _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From nobody Thu Aug 14 05:24:51 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CCE1A0AD2 for ; Thu, 14 Aug 2014 05:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USArgYB_oNXm for ; Thu, 14 Aug 2014 05:24:47 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C40521A0ACA for ; Thu, 14 Aug 2014 05:24:47 -0700 (PDT) Received: by mail-ig0-f177.google.com with SMTP id hn18so4777411igb.4 for ; Thu, 14 Aug 2014 05:24:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fHcM2vis7Gk8xKqK93duOzWRF8vUvh12rxdEQuYc1pA=; b=wj8SCvqCgzcioqf2CoAx9rGV3H2Eyynauf9xZ2xlGuBWZ1sdAd+Uzti+2MrwPOunXX tE8XqNiT9KbcXBNcQXHBmwCfHzmnLKkRVKSoQakrO7uVU/Jrxl0+BU9DVYvjheMEZSzC V72Xo+ECjBKSJR9xzHXRNcpc94FMv8YM5j7MmNvswjBuhzZs17jLSDmdmjZL8jXmMn8b +j4J9csZpycU1mKBxmqxs10cg9+xnPVLFHO30WDOHhsCgt2QXcRV6fhfu2j7tlCQQhIt ZdfXzR9aXy+gHEsyBr5hqmth8tDp+KaNjE/t1xafD8d3AQQ1ycCz4J2wEivNpjht+/RQ ZXgg== MIME-Version: 1.0 X-Received: by 10.50.136.167 with SMTP id qb7mr16695722igb.31.1408019087044; Thu, 14 Aug 2014 05:24:47 -0700 (PDT) Received: by 10.50.26.74 with HTTP; Thu, 14 Aug 2014 05:24:46 -0700 (PDT) In-Reply-To: <09CE6C3BE5E1EA40B987BF5F25D8DDBAF4E68C88@ENFICSMBX1.datcon.co.uk> References: <23CE718903A838468A8B325B80962F9B865B4669@szxeml556-mbs.china.huawei.com> <09CE6C3BE5E1EA40B987BF5F25D8DDBAF4E68C88@ENFICSMBX1.datcon.co.uk> Date: Thu, 14 Aug 2014 17:54:46 +0530 Message-ID: From: Dhruv Dhody To: Jonathan Hardwick Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/nVtI8DqVoPRtvDK5qD-Qri1Ru60 Cc: "draft-ietf-pce-pcep-mib@tools.ietf.org" , "pce@ietf.org" Subject: Re: [Pce] Regarding draft-ietf-pce-pcep-mib-09 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 12:24:49 -0000 Hi Jon, Trimming the mail to the points which need commenting... > ~ a new object for corrupted messages (note that corrupted messages are > different from unknown messages and this cannot be derived from number of > error messages sent either). > Jon> Happy to have this - please could you propose some text? pcePcepPeerNumCorruptRcvd OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of corrupted PCEP message received from this peer. " ::= { pcePcepPeerEntry xx } pcePcepSessNumCorruptRcvd OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of corrupted PCEP message received on this session. " ::= { pcePcepSessEntry yy } > - Section 5.1 > pcePcepEntityEntry OBJECT-TYPE > SYNTAX PcePcepEntityEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An entry in this table represents a PCEP entity." > INDEX { pcePcepEntityIndex } > ::= { pcePcepEntityTable 1 } > > ~ I think the description should not say 'this table' while describing > an entry. Also true for pcePcepSessEntry. > > Jon> Not sure I understand - why? OLD: "An entry in this table represents a PCEP entity." NEW: "This entry represents a PCEP entity." Just my preference, entirely up to you if you would like to change. (snip) Thanks! Dhruv From nobody Fri Aug 15 04:33:55 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFDFE1A09F4 for ; Fri, 15 Aug 2014 04:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDTQjFjBT0VO for ; Fri, 15 Aug 2014 04:33:51 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lrp0075.outbound.protection.outlook.com [213.199.154.75]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 423E31A09F2 for ; Fri, 15 Aug 2014 04:33:50 -0700 (PDT) Received: from DB3PR07MB058.eurprd07.prod.outlook.com (10.242.137.148) by DB3PR07MB220.eurprd07.prod.outlook.com (10.242.133.18) with Microsoft SMTP Server (TLS) id 15.0.1010.18; Fri, 15 Aug 2014 11:33:49 +0000 Received: from pc6 (109.147.210.26) by DB3PR07MB058.eurprd07.prod.outlook.com (10.242.137.148) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Fri, 15 Aug 2014 11:33:48 +0000 Message-ID: <026001cfb87c$aab0c240$4001a8c0@gateway.2wire.net> From: t.petch To: Jonathan Hardwick References: <23CE718903A838468A8B325B80962F9B865B4669@szxeml556-mbs.china.huawei.com> <09CE6C3BE5E1EA40B987BF5F25D8DDBAF4E68C88@ENFICSMBX1.datcon.co.uk> Date: Fri, 15 Aug 2014 12:32:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [109.147.210.26] X-ClientProxiedBy: DB4PR03CA0012.eurprd03.prod.outlook.com (25.160.39.150) To DB3PR07MB058.eurprd07.prod.outlook.com (10.242.137.148) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:;UriScan:; X-Forefront-PRVS: 0304E36CA3 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(51704005)(377454003)(199003)(51914003)(189002)(13464003)(47776003)(62966002)(21056001)(85852003)(15975445006)(66066001)(81686999)(95666004)(83322001)(101416001)(4396001)(102836001)(81816999)(87976001)(20776003)(87286001)(89996001)(230783001)(84392001)(83072002)(61296003)(62236002)(77096002)(19580405001)(88136002)(92726001)(31966008)(92566001)(110136001)(85306004)(14496001)(76482001)(81542001)(81342001)(99396002)(50466002)(44716002)(77156001)(93916002)(74502001)(77982001)(79102001)(23756003)(33646002)(86362001)(104166001)(42186005)(74662001)(50986999)(19580395003)(106356001)(50226001)(76176999)(105586002)(44736004)(116806002)(80022001)(107046002)(64706001)(46102001)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR07MB058; H:pc6; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/pce/0D8anMkG-RA7S4KY7DmI-YsqZ3E Cc: draft-ietf-pce-pcep-mib@tools.ietf.org, pce@ietf.org Subject: Re: [Pce] Regarding draft-ietf-pce-pcep-mib-09 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 11:33:54 -0000 Jon Picking up two of Adrian's points: - I would never have known the idea was to have multiple entities in a single 'box' modelled in the one MIB module - I think this unusual and while fine to do it, I would like to see it spelt out in s.4.1. It is often a source of confusion what an instance of an 'object class' actually is, which I think confused Adrian as well as me - on the question of how many supported protocols, there used to be an enumeration " ipV4: PceRoutingDomainID is an InetAddressIPv4 .. ipV6: PceRoutingDomainID is an InetAddressIPv6 nsap: PceRoutingDomainID type is OCTET STRING (SIZE (0..20)), corresponding to the name of an ISIS area asNumber: PceRoutingDomainID type is OCTET STRING (SIZE (2)) corresponding to the name of an Autonomous System." but I assume that such concepts are long gone. A trivial point of my own s/estbalished./established./ And does pcePcepSessState need to reflect the various contortions a shutdown can go through, or all the various wait states of no interest? A sometime practice with other models of sessions is to keep information around for a while so that it is possible to tell what caused the shutdown. Tom Petch ----- Original Message ----- From: "Jonathan Hardwick" To: "Dhruv Dhody" Cc: ; Sent: Thursday, August 14, 2014 12:27 PM Subject: Re: [Pce] Regarding draft-ietf-pce-pcep-mib-09 > Hi Dhruv > > Thanks for the comments - see replies below (Jon> ...). I'll make sure these are addressed in the next revision. > > Cheers > Jon > > -----Original Message----- > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Dhruv Dhody > Sent: 31 July 2014 19:30 > To: draft-ietf-pce-pcep-mib@tools.ietf.org > Cc: pce@ietf.org > Subject: [Pce] Regarding draft-ietf-pce-pcep-mib-09 > > Hi Authors, > > I re-read the MIB document in preparation for the last call. > You may consider these comments/nits before or alongside the WG last call. > > - General > ~ Expand PCReq, PCRep, PCNtf, SVEC, RP etc on first use, using terminology > Section may also be useful. > Jon> OK. > > ~ PCEP speaker and PCEP entity are used interchangeably, perhaps we can > unify? > Jon> The aim is to use PCEP entity when referring specifically to a local entity (that is, one that appears in the pcePcepEntityTable) and PCEP speaker to refer more generally to any device that is speaking PCEP. I'll re-review and make sure there is consistency here. > > ~ a new object for corrupted messages (note that corrupted messages are > different from unknown messages and this cannot be derived from number of > error messages sent either). > Jon> Happy to have this - please could you propose some text? > > - Abstract > Add MIB as the abbreviation > Jon> OK > > - Introduction > Add TE as the abbreviation for Traffic Engineering > Jon> OK > > - Shouldn't Section 3 'Requirements Language' about RFC2119 keywords > be part of the introduction itself? > Jon> This boilerplate text is usually in its own section in my experience. > > - Section 5.1 > pcePcepEntityEntry OBJECT-TYPE > SYNTAX PcePcepEntityEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An entry in this table represents a PCEP entity." > INDEX { pcePcepEntityIndex } > ::= { pcePcepEntityTable 1 } > > ~ I think the description should not say 'this table' while describing > an entry. Also true for pcePcepSessEntry. > > Jon> Not sure I understand - why? > > pcePcepEntityIndex OBJECT-TYPE > SYNTAX Unsigned32 (1..2147483647) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This index is used to uniquely identify the PCEP entity." > ::= { pcePcepEntityEntry 1 } > > ~ Wouldnt Integer32 (1..2147483647) be a better fit? > > Jon> We are removing the range restriction instead. > > Suggest to reorder pcePcepEntityMaxKeepAliveTimer, > pcePcepEntityMaxDeadTimer, pcePcepEntityAllowNegotiation, > pcePcepEntityMinKeepAliveTimer, pcePcepEntityMinDeadTimer > > ~ by moving the pcePcepEntityAllowNegotiation first, you can use it in > the description for both max and min timers. > > Jon> OK. > > pcePcepEntitySyncTimer OBJECT-TYPE > SYNTAX Unsigned32 (1..65535) > UNITS "seconds" > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value of SYNC timer is used in the case of synchronized > path computation request using the SVEC object... > > ~ Use SyncTimer (as used in 5440) instead of SYNC timer. > > Jon> OK > > > pcePcepPeerNumSessSetupFail OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of PCEP sessions with the peer that have been > attempted but failed before being fully estbalished. > This counter is incremented each time a session with this > peer fails before reaching session state pceSessionUp." > ::= { pcePcepPeerEntry 8 } > > ~ the state is called sessionUp (refer pcePcepSessState) and not > pceSessionUp > > Jon> OK > > - Security Considerations > You might think of removing the text about SET operation, as this > MIB is read-only. > > You might also add reference to SNMPv3 security like USM with AES as > well to use of secure transport like SSH or TLS/DTLS. > > Jon> How about the following change (plagiarising text from RFC 6825): > > OLD > > It is RECOMMENDED that implementers consider the security features as > provided by the SNMPv3 framework (see [RFC3410], section 8), > including full support for the SNMPv3 cryptographic mechanisms (for > authentication and privacy). > > NEW > > Implementations MUST provide the security features described by the > SNMPv3 framework (see [RFC3410]), including full support for > authentication and privacy via the User-based Security Model (USM) > [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations > MAY also provide support for the Transport Security Model (TSM) > [RFC5591] in combination with a secure transport such as SSH > [RFC5592] or TLS/DTLS [RFC6353]. > > > Thank You! > > Dhruv > > > > > > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From nobody Mon Aug 18 07:36:35 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEE01A0343 for ; Mon, 18 Aug 2014 07:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpdT5cta3vVz for ; Mon, 18 Aug 2014 07:36:24 -0700 (PDT) Received: from ENFIRHETS1.metaswitch.com (enfirhets1.metaswitch.com [192.91.191.166]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21DD21A045E for ; Mon, 18 Aug 2014 07:36:10 -0700 (PDT) Received: from ENFIRHMBX1.datcon.co.uk (172.18.74.36) by ENFIRHETS1.metaswitch.com (172.18.209.22) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 18 Aug 2014 15:36:03 +0100 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHMBX1.datcon.co.uk ([fe80::b06d:4d13:5f63:3715%18]) with mapi id 14.03.0195.001; Mon, 18 Aug 2014 15:36:08 +0100 From: Jonathan Hardwick To: t.petch Thread-Topic: [Pce] Regarding draft-ietf-pce-pcep-mib-09 Thread-Index: AQHPq9afzHVhKP50lkqOvlKKCIpV55vQBmjQgAGbfEyABN8m8A== Date: Mon, 18 Aug 2014 14:36:08 +0000 Message-ID: <09CE6C3BE5E1EA40B987BF5F25D8DDBAF4E78085@ENFICSMBX1.datcon.co.uk> References: <23CE718903A838468A8B325B80962F9B865B4669@szxeml556-mbs.china.huawei.com> <09CE6C3BE5E1EA40B987BF5F25D8DDBAF4E68C88@ENFICSMBX1.datcon.co.uk> <026001cfb87c$aab0c240$4001a8c0@gateway.2wire.net> In-Reply-To: <026001cfb87c$aab0c240$4001a8c0@gateway.2wire.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.34.171] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/upENZadng1ToJw9jxwwc0r8iTsQ Cc: "draft-ietf-pce-pcep-mib@tools.ietf.org" , "pce@ietf.org" Subject: Re: [Pce] Regarding draft-ietf-pce-pcep-mib-09 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 14:36:28 -0000 Tom, many thanks for your comments. See [jon]... [/jon] inline below. Cheers Jon -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com]=20 Sent: 15 August 2014 12:33 To: Jonathan Hardwick Cc: draft-ietf-pce-pcep-mib@tools.ietf.org; pce@ietf.org Subject: Re: [Pce] Regarding draft-ietf-pce-pcep-mib-09 Jon Picking up two of Adrian's points: - I would never have known the idea was to have multiple entities in a single 'box' modelled in the one MIB module - I think this unusual and while fine to do it, I would like to see it spelt out in s.4.1. It is often a source of confusion what an instance of an 'object class' actually is, which I think confused Adrian as well as me [jon] Agreed, I will spell it out more clearly as this has obviously caused= some confusion. [/jon] - on the question of how many supported protocols, there used to be an enumeration " ipV4: PceRoutingDomainID is an InetAddressIPv4 .. ipV6: PceRoutingDomainID is an InetAddressIPv6 nsap: PceRoutingDomainID type is OCTET STRING (SIZE (0..20)), corresponding to the name of an ISIS area asNumber: PceRoutingDomainID type is OCTET STRING (SIZE (2)) corresponding to the name of an Autonomous System." but I assume that such concepts are long gone. [jon] Yes, the TC MIB has expired and is not needed by the current MIB. I = don't think this TC was ever used by the PCEP MIB. [/jon] A trivial point of my own s/estbalished./established./ [jon] Thanks - will fix. [/jon] And does pcePcepSessState need to reflect the various contortions a shutdown can go through [jon] We decided to keep the states in line with RFC 5440 which does not sp= ecify any additional states during shutdown (the FSM goes straight to "idle= "). It is possible that implementations may use intermediate shutdown stat= es such as "quiescing" but I think these are probably best done in an imple= mentation-specific field which modifies the "sessionUp" state. [/jon]=20 , or all the various wait states of no interest? [jon] I think the wait states are useful. If a session is stuck not coming = up, the operator will find it helpful to know if this is because the sessio= n is stuck in tcpPending, openWait or keepWait. [/jon] A sometime practice with other models of sessions is to keep information around for a while so that it is possible to tell what caused the shutdown. [jon] I think that the relevant information (which may be quite detailed) s= hould be available in logs, and that logging interfaces would be better sui= ted to it. Is it common to provide this type of thing in MIBs - can you po= int me to any examples? [/jon] Tom Petch ----- Original Message ----- From: "Jonathan Hardwick" To: "Dhruv Dhody" Cc: ; Sent: Thursday, August 14, 2014 12:27 PM Subject: Re: [Pce] Regarding draft-ietf-pce-pcep-mib-09 > Hi Dhruv > > Thanks for the comments - see replies below (Jon> ...). I'll make sure these are addressed in the next revision. > > Cheers > Jon > > -----Original Message----- > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Dhruv Dhody > Sent: 31 July 2014 19:30 > To: draft-ietf-pce-pcep-mib@tools.ietf.org > Cc: pce@ietf.org > Subject: [Pce] Regarding draft-ietf-pce-pcep-mib-09 > > Hi Authors, > > I re-read the MIB document in preparation for the last call. > You may consider these comments/nits before or alongside the WG last call. > > - General > ~ Expand PCReq, PCRep, PCNtf, SVEC, RP etc on first use, using terminology > Section may also be useful. > Jon> OK. > > ~ PCEP speaker and PCEP entity are used interchangeably, perhaps we can > unify? > Jon> The aim is to use PCEP entity when referring specifically to a local entity (that is, one that appears in the pcePcepEntityTable) and PCEP speaker to refer more generally to any device that is speaking PCEP. I'll re-review and make sure there is consistency here. > > ~ a new object for corrupted messages (note that corrupted messages are > different from unknown messages and this cannot be derived from number of > error messages sent either). > Jon> Happy to have this - please could you propose some text? > > - Abstract > Add MIB as the abbreviation > Jon> OK > > - Introduction > Add TE as the abbreviation for Traffic Engineering > Jon> OK > > - Shouldn't Section 3 'Requirements Language' about RFC2119 keywords > be part of the introduction itself? > Jon> This boilerplate text is usually in its own section in my experience. > > - Section 5.1 > pcePcepEntityEntry OBJECT-TYPE > SYNTAX PcePcepEntityEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An entry in this table represents a PCEP entity." > INDEX { pcePcepEntityIndex } > ::=3D { pcePcepEntityTable 1 } > > ~ I think the description should not say 'this table' while describing > an entry. Also true for pcePcepSessEntry. > > Jon> Not sure I understand - why? > > pcePcepEntityIndex OBJECT-TYPE > SYNTAX Unsigned32 (1..2147483647) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This index is used to uniquely identify the PCEP entity." > ::=3D { pcePcepEntityEntry 1 } > > ~ Wouldnt Integer32 (1..2147483647) be a better fit? > > Jon> We are removing the range restriction instead. > > Suggest to reorder pcePcepEntityMaxKeepAliveTimer, > pcePcepEntityMaxDeadTimer, pcePcepEntityAllowNegotiation, > pcePcepEntityMinKeepAliveTimer, pcePcepEntityMinDeadTimer > > ~ by moving the pcePcepEntityAllowNegotiation first, you can use it in > the description for both max and min timers. > > Jon> OK. > > pcePcepEntitySyncTimer OBJECT-TYPE > SYNTAX Unsigned32 (1..65535) > UNITS "seconds" > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value of SYNC timer is used in the case of synchronized > path computation request using the SVEC object... > > ~ Use SyncTimer (as used in 5440) instead of SYNC timer. > > Jon> OK > > > pcePcepPeerNumSessSetupFail OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of PCEP sessions with the peer that have been > attempted but failed before being fully estbalished. > This counter is incremented each time a session with this > peer fails before reaching session state pceSessionUp." > ::=3D { pcePcepPeerEntry 8 } > > ~ the state is called sessionUp (refer pcePcepSessState) and not > pceSessionUp > > Jon> OK > > - Security Considerations > You might think of removing the text about SET operation, as this > MIB is read-only. > > You might also add reference to SNMPv3 security like USM with AES as > well to use of secure transport like SSH or TLS/DTLS. > > Jon> How about the following change (plagiarising text from RFC 6825): > > OLD > > It is RECOMMENDED that implementers consider the security features as > provided by the SNMPv3 framework (see [RFC3410], section 8), > including full support for the SNMPv3 cryptographic mechanisms (for > authentication and privacy). > > NEW > > Implementations MUST provide the security features described by the > SNMPv3 framework (see [RFC3410]), including full support for > authentication and privacy via the User-based Security Model (USM) > [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations > MAY also provide support for the Transport Security Model (TSM) > [RFC5591] in combination with a secure transport such as SSH > [RFC5592] or TLS/DTLS [RFC6353]. > > > Thank You! > > Dhruv > > > > > > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From nobody Mon Aug 18 09:44:29 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BD41A06DD for ; Mon, 18 Aug 2014 09:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aa7FxGrxKqEz for ; Mon, 18 Aug 2014 09:44:25 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lrp0017.outbound.protection.outlook.com [213.199.154.17]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51D5B1A06D1 for ; Mon, 18 Aug 2014 09:44:25 -0700 (PDT) Received: from pc6 (109.147.210.26) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Mon, 18 Aug 2014 16:44:22 +0000 Message-ID: <00d301cfbb03$8a7a4a80$4001a8c0@gateway.2wire.net> From: t.petch To: Jonathan Hardwick References: <23CE718903A838468A8B325B80962F9B865B4669@szxeml556-mbs.china.huawei.com> <09CE6C3BE5E1EA40B987BF5F25D8DDBAF4E68C88@ENFICSMBX1.datcon.co.uk> <026001cfb87c$aab0c240$4001a8c0@gateway.2wire.net> <09CE6C3BE5E1EA40B987BF5F25D8DDBAF4E78085@ENFICSMBX1.datcon.co.uk> Date: Mon, 18 Aug 2014 17:38:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [109.147.210.26] X-ClientProxiedBy: AM3PR01CA039.eurprd01.prod.exchangelabs.com (10.141.191.29) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-Forefront-PRVS: 03077579FF X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019005)(6009001)(377454003)(13464003)(66654002)(199003)(189002)(4396001)(62966002)(101416001)(95666004)(21056001)(74502001)(76176999)(76482001)(44736004)(99396002)(23756003)(116806002)(46102001)(104166001)(86362001)(84392001)(93916002)(50226001)(81342001)(92566001)(89996001)(20776003)(102836001)(92726001)(47776003)(50466002)(42186005)(64706001)(85306004)(87286001)(83072002)(87976001)(85852003)(77156001)(93886004)(88136002)(19580395003)(61296003)(81542001)(105586002)(66066001)(107046002)(230783001)(50986999)(62236002)(31966008)(19580405001)(81686999)(80022001)(14496001)(74662001)(83322001)(81816999)(33646002)(77982001)(106356001)(44716002)(110136001)(79102001)(77096002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB060; H:pc6; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/pce/DL78ABKWIM6FSO8ZAVtIlgUM-1k Cc: draft-ietf-pce-pcep-mib@tools.ietf.org, pce@ietf.org Subject: Re: [Pce] Regarding draft-ietf-pce-pcep-mib-09 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 16:44:28 -0000 At the end ... ----- Original Message ----- From: "Jonathan Hardwick" To: "t.petch" Cc: ; Sent: Monday, August 18, 2014 3:36 PM Subject: RE: [Pce] Regarding draft-ietf-pce-pcep-mib-09 Tom, many thanks for your comments. See [jon]... [/jon] inline below. Cheers Jon -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com] Sent: 15 August 2014 12:33 To: Jonathan Hardwick Cc: draft-ietf-pce-pcep-mib@tools.ietf.org; pce@ietf.org Subject: Re: [Pce] Regarding draft-ietf-pce-pcep-mib-09 Jon Picking up two of Adrian's points: - I would never have known the idea was to have multiple entities in a single 'box' modelled in the one MIB module - I think this unusual and while fine to do it, I would like to see it spelt out in s.4.1. It is often a source of confusion what an instance of an 'object class' actually is, which I think confused Adrian as well as me [jon] Agreed, I will spell it out more clearly as this has obviously caused some confusion. [/jon] - on the question of how many supported protocols, there used to be an enumeration " ipV4: PceRoutingDomainID is an InetAddressIPv4 .. ipV6: PceRoutingDomainID is an InetAddressIPv6 nsap: PceRoutingDomainID type is OCTET STRING (SIZE (0..20)), corresponding to the name of an ISIS area asNumber: PceRoutingDomainID type is OCTET STRING (SIZE (2)) corresponding to the name of an Autonomous System." but I assume that such concepts are long gone. [jon] Yes, the TC MIB has expired and is not needed by the current MIB. I don't think this TC was ever used by the PCEP MIB. [/jon] A trivial point of my own s/estbalished./established./ [jon] Thanks - will fix. [/jon] And does pcePcepSessState need to reflect the various contortions a shutdown can go through [jon] We decided to keep the states in line with RFC 5440 which does not specify any additional states during shutdown (the FSM goes straight to "idle"). It is possible that implementations may use intermediate shutdown states such as "quiescing" but I think these are probably best done in an implementation-specific field which modifies the "sessionUp" state. [/jon] , or all the various wait states of no interest? [jon] I think the wait states are useful. If a session is stuck not coming up, the operator will find it helpful to know if this is because the session is stuck in tcpPending, openWait or keepWait. [/jon] A sometime practice with other models of sessions is to keep information around for a while so that it is possible to tell what caused the shutdown. [jon] I think that the relevant information (which may be quite detailed) should be available in logs, and that logging interfaces would be better suited to it. Is it common to provide this type of thing in MIBs - can you point me to any examples? [/jon] Jon There are not that many session protocols to choose from in the IETF but TCP is richly endowed with information about its sessions, as in RFC4898 and RFC4022, but more humble protocols also tend to follow the practice, such as draft-ietf-forces-mib or RFC7331 (bfd). In the current climate, I expect that we should be grateful for anything in a MIB module:-( Tom Petch ----- Original Message ----- From: "Jonathan Hardwick" To: "Dhruv Dhody" Cc: ; Sent: Thursday, August 14, 2014 12:27 PM Subject: Re: [Pce] Regarding draft-ietf-pce-pcep-mib-09 From nobody Wed Aug 20 01:12:57 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D651A00AB for ; Wed, 20 Aug 2014 01:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.132 X-Spam-Level: X-Spam-Status: No, score=0.132 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MlLIMqb8Js0 for ; Wed, 20 Aug 2014 01:12:51 -0700 (PDT) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 968FC1A00AA for ; Wed, 20 Aug 2014 01:12:50 -0700 (PDT) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4D8F4880BA for ; Wed, 20 Aug 2014 10:12:47 +0200 (CEST) Received: from ESTGVMSP104.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id 33ADA880B2 for ; Wed, 20 Aug 2014 10:12:47 +0200 (CEST) Received: from emea01-am1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.50) with Microsoft SMTP Server (TLS) id 14.3.146.2; Wed, 20 Aug 2014 10:12:46 +0200 Received: from AMSPR06MB104.eurprd06.prod.outlook.com (10.242.90.155) by AMSPR06MB101.eurprd06.prod.outlook.com (10.242.90.146) with Microsoft SMTP Server (TLS) id 15.0.1010.18; Wed, 20 Aug 2014 08:12:45 +0000 Received: from AMSPR06MB104.eurprd06.prod.outlook.com ([169.254.8.114]) by AMSPR06MB104.eurprd06.prod.outlook.com ([169.254.8.114]) with mapi id 15.00.1005.008; Wed, 20 Aug 2014 08:12:45 +0000 From: OSCAR GONZALEZ DE DIOS To: "pce@ietf.org" Thread-Topic: CFP Special Issue on Advances in Path Computation Element: Optical Switching and Networking (OSN) Thread-Index: AQHPvE6FAoWSZYiU70q+/JRKobjnvg== Date: Wed, 20 Aug 2014 08:12:45 +0000 Message-ID: Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [195.235.92.26] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03094A4065 x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199003)(95666004)(105586002)(74502001)(74662001)(2656002)(107886001)(85306004)(81542001)(36756003)(101416001)(106356001)(106116001)(80022001)(15202345003)(2351001)(4396001)(107046002)(110136001)(99396002)(229853001)(31966008)(83506001)(77096002)(87936001)(83072002)(15975445006)(85852003)(92726001)(19580395003)(86362001)(16236675004)(21056001)(19300405004)(19273905006)(19580405001)(83322001)(54356999)(46102001)(19617315012)(66066001)(81342001)(92566001)(20776003)(76482001)(64706001)(77982001)(79102001)(50986999)(2501001); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR06MB101; H:AMSPR06MB104.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_D01A251A5E23Aoscargonzalezdediostelefonicacom_" MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/pce/l0kwwnsRbtaXUyKXvxS2pl53hp8 Subject: [Pce] CFP Special Issue on Advances in Path Computation Element: Optical Switching and Networking (OSN) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 08:12:54 -0000 --_000_D01A251A5E23Aoscargonzalezdediostelefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable **************************************************** * Our apologies for multiple and cross-postings * **************************************************** Call for Papers Special Issue on Advances in Path Computation Element Optical Switching and Networking (OSN), Elsevier http://www.journals.elsevier.com/optical-switching-and-networking/call-for-= papers/special-issue-on-advances-in-path-computation-element/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Full article submission: December 31st, 2014 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Aim and scope --------------------------------- The Path Computation Element (PCE) was originally designed as the de-facto= solution for constraint-based path computation across multiple domain as w= ell as multiple layer networks. However, aligned to the novel concepts link= ed to virtualization and functions decoupling, the PCE is becoming an impor= tant piece of the Software Defined Networking (SDN) paradigm and presents t= he most relevant architectures. Open Source Industry initiatives such asOpe= nDaylight include the PCE within its component list. The inherent capacity embedded in the PCE concept to outsource network func= tionalities to external network devices is paving the way to extend the mai= n PCE concept to different network scenarios, ranging from traditional tele= com networks to new smart paradigms such as sensor networks, Internet of Th= ings or Intelligent Transport Systems. Indeed, the role of PCE has widened = from a mere path computation function to an entity able to control and opti= mize any kind of network. In fact, the IETF PCE is evolving into a powerful= and flexible platform that can be applied to a variety of technology areas This special issue aims at collecting advances related to the use of path = computation element in different network environments. Research articles a= re solicited in (but not limited to) the following topics: 1) Use of path computation in the context of: * Optical Transport Networks * Flexi-grid networks * Multi-domain networks * Software Defined Networks (ABNO architecture) * Data-centers * Interconnection of Data Centers * Sensor networks * Internet of Things * Novel Internet Architectures and innovative network paradigms 2) Topics such as * Algorithms for path computation * Convergence of PCE and SDN * Stateful PCE * Protocol Extensions * PCE Software architecture and Open-Source Efforts * Traffic Engineering Database Modeling, * Optical transport Network abstraction * Packet Optical Convergence and Integration * Standardization * Role of PCE in Software Defined Optical Transport Networks. * PCE applicability to novel Internet architectures Submission instructions: --------------------------------- All submissions must be original work not previously published or current= ly under review by any other journal. Partial overlap with previously publ= ished conference or workshop papers is acceptable, but must be disclosed at= the time of submission. Submission, review, and decision process will use= the usual Elsevier OSN portal, accessible through http://ees.elsevier.com/= osn/admin/default.asp. During submission, please make sure to select 'SI: P= ath Computation Element ' when you reach the "Article Type" step. More deta= ils about the journal in general, and author guidelines, can be found from = http://ees.elsevier.com/osn/ Timeline --------------------------------- Full article submission: December 31st, 2014 Acceptance/rejection/revision: April 30, 2015 Revised manuscripts: June 30, 2015 Final manuscripts due: July 31st, 2015 Publication date: First Quarter of 2016 Guest Editors Oscar Gonzalez de Dios oscar.gonzalezdedios@telefonica.com Xavi Masip xmasip@ac.upc.edu Young Lee Leeyoung@huawei.com ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci= =C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida en virtud de = la legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le roga= mos que nos lo comunique inmediatamente por esta misma v=C3=ADa y proceda a= su destrucci=C3=B3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura= , utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza= =C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o vigent= e. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imedi= atamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o --_000_D01A251A5E23Aoscargonzalezdediostelefonicacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: quoted-printable
****************************************************
* Our apologies for multiple and cross-postings *
****************************************************

Call for Papers

Special Issue on Advances in Path Computation Element
Optical Switching and Networking (OSN), Elsevier

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Full article submission: December 31st, 2014
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


Aim and scope
--------------------------------- 

 The Path Computation Element (PCE) was originally designed as the = de-facto solution for constraint-based path computation across multiple dom= ain as well as multiple layer networks. However, aligned to the novel conce= pts linked to virtualization and functions decoupling, the PCE is becoming an important piece of the Software Defined= Networking (SDN) paradigm and presents the most relevant architectures. Op= en Source Industry initiatives such asOpenDaylight include the PCE within i= ts component list.

The inherent capacity embedded in the PCE concept to outsource network f= unctionalities to external network devices is paving the way to extend the = main PCE concept to different network scenarios, ranging from traditional t= elecom networks to new smart paradigms such as sensor networks, Internet of Things or Intelligent Transport Syste= ms. Indeed, the role of PCE has widened from a mere path computation functi= on to an entity able to control and optimize any kind of network. In fact, = the IETF PCE is evolving into a powerful and flexible platform that can be applied to a variety of technol= ogy areas

This special issue aims at collecting advances related to the use of&nbs= p; path computation element in different network environments.  Resear= ch articles are solicited in (but not limited to) the following topics:

  1) Use of path computation in the context of:

  • Optical Transport Networks
  • Flexi-grid networks
  • Multi-do= main networks
  • Software Defined Networks (ABNO architecture)
    • Data-centers
  • Interconnection of Data Centers
  • Sensor networ= ks
  • Internet of Things
  • Novel Internet Architectures and inno= vative network paradigms

2) Topics such as

  • Algorithms for path computation
  • Convergence of PCE and SDN
    • =
  • Stateful PCE
  • Protocol Extensions
  • PCE Software architect= ure and Open-Source Efforts
  • Traffic Engineering Database Modeling,<= /li>
  • Optical transport Network abstraction
  • Packet Optical Conver= gence and Integration
  • Standardization
  • Role of PCE in Softwa= re Defined Optical Transport Networks.
  • PCE applicability to novel I= nternet architectures

Submission instructions:
---------------------------------
  All submissions must be original work not previously published = or currently under review by any other journal.  Partial overlap = with previously published conference or workshop papers is acceptable,= but must be disclosed at the time of submission.  Submission, review, and decision process will use the usual Elsevier OSN portal, = accessible through http://ees.elsevier.com/osn/admin/default.asp= . During submission, please make sure to select 'SI: Path Computation Element ' when you reach = the "Article Type" step. More details about the journal in g= eneral, and author guidelines, can be found from http://ees.elsevier.com/osn/

Timeline

---------------------------------

Full article submission: December 31st, 2014
Acceptance/rejection/revision: April 30, 2015
Revised manuscripts: June 30, 2015
Final manuscripts due: July 31st, 2015
Publication date: First Quarter of 2016

Guest Editors

Oscar Gonzalez de Dios
os= car.gonzalezdedios@telefonica.com

Xavi Masip
xmasip@ac.upc.edu

Young Lee
Leeyoung@huawei.co= m



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3= n puede estar prohibida en virtud de la legislaci=C3=B3n vigente. Si ha rec= ibido este mensaje por error, le rogamos que nos lo comunique inmediatament= e por esta misma v=C3=ADa y proceda a su destrucci=C3=B3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem au= toriza=C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o = vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique= imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o
 --_000_D01A251A5E23Aoscargonzalezdediostelefonicacom_-- From nobody Wed Aug 20 02:09:29 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 636BD1A0118 for ; Wed, 20 Aug 2014 02:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.2 X-Spam-Level: X-Spam-Status: No, score=-99.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQ6GoZl2Y4pP for ; Wed, 20 Aug 2014 02:09:26 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53A621A0115 for ; Wed, 20 Aug 2014 02:09:26 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7K99Lbb009575; Wed, 20 Aug 2014 10:09:21 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7K99Kqb009568 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Aug 2014 10:09:20 +0100 From: "Adrian Farrel" To: "'t.petch'" , "'Jonathan Hardwick'" References: <23CE718903A838468A8B325B80962F9B865B4669@szxeml556-mbs.china.huawei.com> <09CE6C3BE5E1EA40B987BF5F25D8DDBAF4E68C88@ENFICSMBX1.datcon.co.uk> <026001cfb87c$aab0c240$4001a8c0@gateway.2wire.net> <09CE6C3BE5E1EA40B987BF5F25D8DDBAF4E78085@ENFICSMBX1.datcon.co.uk> <00d301cfbb03$8a7a4a80$4001a8c0@gateway.2wire.net> In-Reply-To: <00d301cfbb03$8a7a4a80$4001a8c0@gateway.2wire.net> Date: Wed, 20 Aug 2014 10:09:18 +0100 Message-ID: <045801cfbc56$6c663280$45329780$@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: AQF3tpyta5NrUv0qAgekiTetjarjXAJIXMKJAh8AZWwCN01PCwHYV1L5nEWHIZA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20894.006 X-TM-AS-Result: No-4.388-10.0-31-10 X-imss-scan-details: No-4.388-10.0-31-10 X-TMASE-MatchedRID: lORh06tOiKg4HKI/yaqRm5JEUO2qIzlL4xR0DKBHPxpGMe+tDjQ3Fml5 M4viC1cF5ByIn8WCIK0l3o8by3NxB+6ZQKaxFztDvR08UROkEAd9LQinZ4QefL6qvLNjDYTwfyj BJDnutUhQSFbL1bvQAVgXepbcl7r7IMdKxtMnS/Hh0hBDfPjXE7UB37uA/cxTOKIcmt4+NTIIlt whr6UD152ZW4GA3ZgJ6OHEajq43Gce84cryFYbzShFiu37K04b6Hq9RCTLxvsstHmcXeW1eBVSG W4LjW40FYnPSoXfG8fYYdbMBRKwKH7cGd19dSFd Archived-At: http://mailarchive.ietf.org/arch/msg/pce/jkNJbGL5gDSOafOVdFaR1o6AVfU Cc: draft-ietf-pce-pcep-mib@tools.ietf.org, pce@ietf.org Subject: Re: [Pce] Regarding draft-ietf-pce-pcep-mib-09 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 20 Aug 2014 09:09:28 -0000 > A sometime practice with other models of sessions is to keep information > around for a while so that it is possible to tell what caused the > shutdown. > > [jon] I think that the relevant information (which may be quite > detailed) should be available in logs, and that logging interfaces would > be better suited to it. Is it common to provide this type of thing in > MIBs - can you point me to any examples? [/jon] A way to handle this is that the peerEntry (which can persist) can have objects that say "lastFailureTime" and "lastFailureReason" A From nobody Wed Aug 20 02:42:18 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B681D1A0149 for ; Wed, 20 Aug 2014 02:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.2 X-Spam-Level: X-Spam-Status: No, score=-99.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvuJx1wmTtet for ; Wed, 20 Aug 2014 02:42:11 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 927951A0130 for ; Wed, 20 Aug 2014 02:42:10 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7K9g9ii006847; Wed, 20 Aug 2014 10:42:09 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7K9g7of006819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Aug 2014 10:42:08 +0100 From: "Adrian Farrel" To: "'Jonathan Hardwick'" References: <000301cfb490$68af4140$3a0dc3c0$@olddog.co.uk> <09CE6C3BE5E1EA40B987BF5F25D8DDBAF4E68BE5@ENFICSMBX1.datcon.co.uk> In-Reply-To: <09CE6C3BE5E1EA40B987BF5F25D8DDBAF4E68BE5@ENFICSMBX1.datcon.co.uk> Date: Wed, 20 Aug 2014 10:42:05 +0100 Message-ID: <045f01cfbc5b$016f9750$044ec5f0$@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: AQJ7NPi7/TdXggDzWdlKjjGa/BHziQKL0PAPmm3kbPA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20894.006 X-TM-AS-Result: No--24.419-10.0-31-10 X-imss-scan-details: No--24.419-10.0-31-10 X-TMASE-MatchedRID: HLMPCFyIyBOnykMun0J1wlu4M/xm4KZeC/ExpXrHizwhvFjBsLEZNPhi 4LNMsvHZkyeevgS86MheEanKV7zGy92ykolHu1ZuSHCU59h5KrGBjLzL4do+VgDqzaYhcjeQjVN spaGN/MGvG5JK8CnON397Mq/1mwLlXRTdE9b6Is/BVprK8rvWX9MGD8JuBXZPf7FDYGpyXq16YV qRbpywi0yUJeFviHRqEIcbU2IJuqq7JfBr9Xl5Crrbxxduc6FPbv16+gil4jdp3/r/gb/Q5U1Dt 1c2KkZqwUtcXnfoCJlzlxk+amVX10q+i9GrWzgs8jbzfqNu/QQhpWQUitAWG+hRlIANR+BQYYeS cmM7WX/oQtCrGVdA0SvjloRZsXkgpHn0l5P4rnUD2WXLXdz+Aa6lKKQMji/xnPZnKmPE5JihuUh Elt2sPZ+4S6AnDN0hqiMcz9Yi4r0O5TlHtZKxbUg5Iem1vm3HKiVsyS+TJgeQ2TbICkFOdjcoKT 4beMG5IXuvUou2O0IX+T5/+efOjS4vJgF90VN+bMGKOuLn5FUpWss5kPUFdE2M/fhW4yS6S3rCf IMyHrHWBN2EiASEqfRpvA6+ECKDK0OC3/GwncG+dJWHbg4ITtF/wImPfa5N4KKCbqX/Ma8VjAea OyL90hKxKex4hpP+kEBULBETeomiT190luQ/K8AmcZEx8XHJXfZY2uc9ofbbHIduc3gt1RFlwJh VcSVOAWbLGmc+xKKQDsoz/7qfjGGN6M1vhJ4HXP5rFAucBUF9LQinZ4QefL6qvLNjDYTwzz3jeh zeneyrusVRy4an8bxAi7jPoeEQftwZ3X11IV0= Archived-At: http://mailarchive.ietf.org/arch/msg/pce/OPH8pSRIjdzyeutJqs3Qq5bpMs4 Cc: draft-ietf-pce-pcep-mib.all@tools.ietf.org, pce@ietf.org Subject: Re: [Pce] AD review of draft-ietf-pce-pcep-mib X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 20 Aug 2014 09:42:13 -0000 Jon, Thanks for the work. Very few responses from me. > That previous point does cause me to wonder about "PCE capabilities". > I can see that you have tried to limit this module to describing the > features that are core to 5440, but I wonder whether that is wise. > > For example, RFCs 5088 and 5089 define a set of PCE capabilities that > may be advertised in the IGPs and are surely relevant to the model of > a PCE that speaks PCEP. That information might usefully be seen in the > module at the PCE, and also at the PCC so that an operator can check > "why does that PCC keep sending these requests to the wrong PCE?" > > Similarly, the Open Object can carry TLVs that indicate further > capabilities. Obviously you can't just include all future capabilities > TLVs since you don't know what they are (well, you know some, but that > have already been defined, but you can't know the undefined ones). But > you might want to to look at how those capabilities will be hooked in > for future accessibility. > > Of particular interest will be the OF-list TLV of RFC 5541. > > >> The scope of the PCEP MIB is currently limited to objects that are core to RFC > 5440 only. > - The capabilities from RFC 5088/5089 belong in the PCE discovery MIB. > - The OFs in the OF-list TLV deserve their own MIB table, which could be defined > in a separate MIB if anyone wants it. > - There are lots of other PCEP RFCs that we could bring into the scope of this > document, but it is already quite large. > > Our preference is to clarify the scope of this document, provide an informational > reference to the discovery MIB, and allow other documents to augment / > supplement the tables we have defined. << OK. Sure. So make sure you have the cross-pointer to the disco MIB module, and think about how future modules might be able to extend/augment without high price. For example, a TC that is the bit flags for capability is easily extended (if it is in a separate module). > --- > > I'm wondering under what circumstances the pcepEntityTable has more than > one entry. You might describe that in 4.1 and also in the Description > clause for the table. > > That would tie in with explaining why you have an index of > Unsigned32 (1..2147483647) which allows for quite a lot of entities! > > >> There is one row in this table for each local PCEP entity, of which there may be > multiple. > > One scenario is partitioning a physical router into multiple virtual routers, each > with its own PCC. Another scenario is managing a device which front-ends > multiple PCE compute resources, each with a different set of capabilities that are > accessed via different IP addresses. > > Although there clearly won't be billions, we feel there's no point in placing an > arbitrary upper limit on the number of local PCEP entities. Our proposal, > therefore, is to remove the artificial restriction on the entity index range. << OK, I have a bit of a hope that you are doing this because you have a need, not because it looks like a cool idea! If your text above is just you scraping around for reasons that might justify the structure you have documented, well, then you know what you should do :-) I am trying to compare the case of six physically diverse nodes each with their own instance of the MIB module, and one physical node hosting 6 virtual pcepEntities each as a separate entry in the pcepEntityTable. In the first case, SNMP would use a different IP address to Get each entry in each pcepEntityTable. In the second case you are suggesting, I think, that there is one SNMP agent on the physical node that maintains one copy of the pcepEntityTable, but that each entry in the table is a separate virtual node. This, I suppose, saves you from having to run a separate SNMP agent on each virtual node even though those virtual nodes are separately addressable. I have no experience of building virtual nodes in this way. I went back to 4750 to see how this is modelled in OSPF and found that it looks to me that in that case you would run a separate agent for each router instance (of course how you manage the code and executables -- and even the data -- is up to you, but the structure of the MIB module is for a single agent per router instance). That is clearly shown by the fact that ospfRouterId is a member of ospfGeneralGroup (what you might call a global variable). Because I have no experience in this, I am not going to require you to change this structure, but I will ask you to explain how "One scenario is partitioning a physical router into multiple virtual routers, each with its own PCC" integrates with 4750. Bottom line: if you intend that multiple local PC* instantiations can appear in the same table, please make this a bit clearer in the text. Anyway, I still think that Unsigned32 (1..2147483647) may be generous. > Actually, I'm a bit confused about the indexing of the three tables. OK, we can snip here. Given your use of the pcepEntityTable, the remaining indexing makes sense. You will, however, need to add text to explain it. Cheerio, Adrian From nobody Wed Aug 20 08:27:31 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28C11A0024 for ; Fri, 8 Aug 2014 10:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFhJ_UxQ0d7a for ; Fri, 8 Aug 2014 10:25:32 -0700 (PDT) Received: from server.isocore.com (server.isocore.com [192.163.204.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5973A1A0002 for ; Fri, 8 Aug 2014 10:25:29 -0700 (PDT) Received: from [65.213.193.106] (port=52362 helo=adminPCR) by server.isocore.com with esmtpa (Exim 4.82) (envelope-from ) id 1XFnuu-0002HE-Hw for Pce@ietf.org; Fri, 08 Aug 2014 17:25:24 +0000 From: "Shamjhana" To: Date: Fri, 8 Aug 2014 13:25:21 -0400 Message-ID: <002901cfb32d$bc4d5a80$34e80f80$@isocore.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002A_01CFB30C.353CCBF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+zLbsGTvyKbml2Twyg7Sxtp+KDtw== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.isocore.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Get-Message-Sender-Via: server.isocore.com: authenticated_id: spokharel@isocore.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/pce/RC2ApD9Qe5sjAHFl7j1ZdZsIoXA X-Mailman-Approved-At: Wed, 20 Aug 2014 08:27:30 -0700 Subject: [Pce] SDN/MPLS 2014 Conference Information X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 17:25:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002A_01CFB30C.353CCBF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The SDN/MPLS 2014 Conference program has already been posted. It is available at http://www.isocore.com/sdn-mpls/ or specifically at: Tutorials (Sunday): http://www.isocore.com/sdn-mpls/tutorials.htm Technical sessions (Mon- Wed): http://www.isocore.com/sdn-mpls/technical_sessions.htm The conference will take place November 2-5 in Washington DC and will include an extensive four day program consisting of tutorials, technical sessions, panels, and exhibits. The key topics to be discussed at this year's conference include: Virtualization, SDN, Cloud and Data Centers, NFV, PCE, Mobility, Traffic Engineering Transport SDN, Orchestration, multi-play applications across common infrastructure and other Emerging Technologies. The conference hotel is the Marriott Wardman Park in Washington DC. Please note that there are only a limited number of rooms available this year at a reduced rate. Please make reservations at: https://resweb.passkey.com/Resweb.do?mode=welcome_gi_new &groupID=25088120 ------=_NextPart_000_002A_01CFB30C.353CCBF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The = SDN/MPLS 2014 Conference program has already been posted. It is = available
 at http://www.isocore.com/sdn-mpls= /   or specifically at:

Tutorials (Sunday): = http://www.isocore= .com/sdn-mpls/tutorials.htm
Technical sessions (Mon- Wed): = http://ww= w.isocore.com/sdn-mpls/technical_sessions.htm

The conference = will take place November 2-5 in Washington DC and will
include an = extensive four day program consisting of tutorials, = technical
sessions, panels, and exhibits. The key topics to be = discussed at this
year's conference include: Virtualization, SDN, = Cloud and Data Centers, NFV,
PCE, Mobility, Traffic Engineering = Transport SDN, Orchestration,
multi-play applications across common = infrastructure and other Emerging Technologies.

The conference = hotel is the Marriott Wardman Park in Washington DC. Please
note that = there are only a limited number of rooms available this year at = a
reduced rate. Please make reservations at:
https://resweb.passkey.com/Resweb.do?mode=3Dwelcome_gi_= new&groupID=3D25088120

------=_NextPart_000_002A_01CFB30C.353CCBF0-- From nobody Wed Aug 20 08:30:12 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574E61A069D for ; Wed, 20 Aug 2014 08:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.152 X-Spam-Level: X-Spam-Status: No, score=-0.152 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.668, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAEvNCMEhpB0 for ; Wed, 20 Aug 2014 08:30:10 -0700 (PDT) Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id E085C1A0680 for ; Wed, 20 Aug 2014 08:30:09 -0700 (PDT) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 00C4441022C for ; Wed, 20 Aug 2014 17:30:09 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.orange.com (Postfix) with ESMTP id EE1CB410223 for ; Wed, 20 Aug 2014 17:30:08 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Aug 2014 17:30:08 +0200 Received: from [10.193.116.62] ([10.193.116.62]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Aug 2014 17:30:08 +0200 Message-ID: <53F4BEFF.9050606@orange.com> Date: Wed, 20 Aug 2014 17:30:07 +0200 From: Julien Meuric Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: pce@ietf.org References: <53E4A36B.606@orange.com> In-Reply-To: <53E4A36B.606@orange.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Aug 2014 15:30:08.0508 (UTC) FILETIME=[9FD583C0:01CFBC8B] Archived-At: http://mailarchive.ietf.org/arch/msg/pce/WVGm4SNdutA9gbdCH-vX3lAc7VI Subject: Re: [Pce] WG Last Call on draft-ietf-pce-rfc7150bis-01 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 15:30:11 -0000 Hi all. This LC ended without further comment. RFC 7150 bis will thus move forward. Thanks, JP & Julien Aug. 08, 2014 - Julien Meuric: > Dear PCE WG, > > Following the discussion in Toronto, this message ignites a WG last > call on draft-ietf-pce-rfc7150bis-01. Since it is mainly a codepoint > change while the specification remains the same, this last call will > only last *one week* and will end on Friday August 15 at 11:59 PM, HST. > > Comments should be sent to the PCE mailing list. > > Regards, > > JP & Julien > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > From nobody Fri Aug 22 04:57:20 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532581A00EB for ; Fri, 22 Aug 2014 04:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWKZCjd_BSOt for ; Fri, 22 Aug 2014 04:57:17 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5719B1A02A3 for ; Fri, 22 Aug 2014 04:57:16 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7MBvEjN028056 for ; Fri, 22 Aug 2014 12:57:14 +0100 Received: from 950129200 (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 s7MBvDXO028044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 22 Aug 2014 12:57:13 +0100 From: "Adrian Farrel" To: Date: Fri, 22 Aug 2014 12:57:13 +0100 Message-ID: <010d01cfbe00$365fd000$a31f7000$@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: Ac++ADRqoc+aFlssThWIhc0wuV1ZQA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20898.007 X-TM-AS-Result: No--9.990-10.0-31-10 X-imss-scan-details: No--9.990-10.0-31-10 X-TMASE-MatchedRID: AbNM65KDsZ3oyJCZV0+mCEhEDfw/93BuH181YDtIVarM7zpEspqG/6TY tf9nwiNjbF7poigH+cPdI1esLkY9RBylAWhTn8gdtT4jIeGRd/VBldmDYjwlpoNDCN4yZuhAXvb V/VnUv0pQ4kDgHrtrTx9l1zPMOb+6TX7PJ/OU3vL+xOhjarOnHmrz/G/ZSbVq+gtHj7OwNO31Kz k40dEY9S2qeeSuHgxPx1/2jmZp+d/GPmGwetpap+go4tiVoVwo Archived-At: http://mailarchive.ietf.org/arch/msg/pce/sPqalYVMVZ4INTScnnZ0YfU-l9M Subject: [Pce] Discussion of tuning Routing Area working groups X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 22 Aug 2014 11:57:18 -0000 Hi, Just wanted to bring to your attention that there is a discussion on the Routing Discussion mailing list about possible ways to restructure a few of the working groups in the Routing Area. This concerns PCE as the discussion relates to where to put work concerning TE Architecture. You can subscribe to the list and see the message archive at https://www.ietf.org/mailman/listinfo/routing-discussion Please join in if you have an opinion. Thanks, Adrian From nobody Wed Aug 27 03:09:56 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617671A04B1 for ; Wed, 27 Aug 2014 03:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgqU9frfGfj9 for ; Wed, 27 Aug 2014 03:09:43 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98B021A04A9 for ; Wed, 27 Aug 2014 03:09:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIU09362; Wed, 27 Aug 2014 10:09:40 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 Aug 2014 11:09:38 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.209]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Wed, 27 Aug 2014 18:09:31 +0800 From: Qin Wu To: "pce@ietf.org" Thread-Topic: I-D Action: draft-wu-pce-discovery-pceps-support-01.txt Thread-Index: AQHPt34VeZpZpUDEXk+lwdwtWfp7gZvkTWGg Date: Wed, 27 Aug 2014 10:09:31 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pce/bYkgaRYK3kphw6MKQ-bQh7-B8zQ Subject: Re: [Pce] I-D Action: draft-wu-pce-discovery-pceps-support-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 10:09:47 -0000 SGksDQpIZXJlIGlzIHRoZSB1cGRhdGUgdG8gZHJhZnQtd3UtcGNlLWRpc2NvdmVyeS1wY2Vwcy1z dXBwb3J0LTAxLiBUaGUgbW9zdCBjaGFuZ2VzIGFyZSBlZGl0b3JpYWwgY2hhbmdlcy4NClRoZSBk aWZmIGlzOg0KaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtd3UtcGNlLWRp c2NvdmVyeS1wY2Vwcy1zdXBwb3J0LTAxDQoNClRoaXMgZHJhZnQgcHJvdmlkZXMgYSBtZWNoYW5p c20gZm9yIFBDQyB0byBkaXNjb3ZlciBQQ0Ugd2l0aCBUTFMgc3VwcG9ydC4NCkluIGFkZGl0aW9u LCB0aGUgZHJhZnQgYWxzbyBzdXBwb3J0IGRpc2NvdmVyeSBvZiBQQ0Ugc2VydmVyIHdpdGggTUQg c3VwcG9ydCwgVENQLUFPIHN1cHBvcnQgcmVzcGVjdGl2ZWx5Lg0KQXV0aG9ycyBmZWVsIGl0IHdp bGwgYmUgYSBnb29kIHRvIGhhdmUgdGhpcyBkcmFmdCBzZXBhcmF0ZWx5IHJhdGhlciB0aGFuIHNp bXBseSBtZXJnaW5nIGludG8gZHJhZnQtaWV0Zi1wY2UtcGNlcHMuDQpBbnkgb3BpbmlvbnMgb3Ig b2JqZWN0aW9uPw0KDQpSZWdhcmRzIQ0KLVFpbg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6 IEktRC1Bbm5vdW5jZSBbbWFpbHRvOmktZC1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnXSC0+rHt IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0Kt6LLzcqxvOQ6IDIwMTTE6jjUwjE0yNUgMTM6MTAN CsrVvP7IyzogaS1kLWFubm91bmNlQGlldGYub3JnDQrW98ziOiBJLUQgQWN0aW9uOiBkcmFmdC13 dS1wY2UtZGlzY292ZXJ5LXBjZXBzLXN1cHBvcnQtMDEudHh0DQoNCg0KQSBOZXcgSW50ZXJuZXQt RHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVj dG9yaWVzLg0KDQoNCiAgICAgICAgVGl0bGUgICAgICAgICAgIDogSUdQIGV4dGVuc2lvbiBmb3Ig UENFUCBzZWN1cml0eSBjYXBhYmlsaXR5IHN1cHBvcnQgaW4gdGhlIFBDRSBkaXNjb3ZlcnkNCiAg ICAgICAgQXV0aG9ycyAgICAgICAgIDogRGllZ28gUi4gTG9wZXoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgUWluIFd1DQogICAgICAgICAgICAgICAgICAgICAgICAgIERocnV2IERob2R5DQog ICAgICAgICAgICAgICAgICAgICAgICAgIERhbmllbCBLaW5nDQoJRmlsZW5hbWUgICAgICAgIDog ZHJhZnQtd3UtcGNlLWRpc2NvdmVyeS1wY2Vwcy1zdXBwb3J0LTAxLnR4dA0KCVBhZ2VzICAgICAg ICAgICA6IDYNCglEYXRlICAgICAgICAgICAgOiAyMDE0LTA4LTEzDQoNCkFic3RyYWN0Og0KICAg V2hlbiBhIFBhdGggQ29tcHV0YXRpb24gRWxlbWVudCAoUENFKSBpcyBhIExhYmVsIFN3aXRjaGlu ZyBSb3V0ZXINCiAgIChMU1IpIHBhcnRpY2lwYXRpbmcgaW4gdGhlIEludGVyaW9yIEdhdGV3YXkg UHJvdG9jb2wgKElHUCksIG9yIGV2ZW4gYQ0KICAgc2VydmVyIHBhcnRpY2lwYXRpbmcgaW4gSUdQ LCBpdHMgcHJlc2VuY2UgYW5kIHBhdGggY29tcHV0YXRpb24NCiAgIGNhcGFiaWxpdGllcyBjYW4g YmUgYWR2ZXJ0aXNlZCB1c2luZyBJR1AgZmxvb2RpbmcuICBUaGUgSUdQDQogICBleHRlbnNpb25z IGZvciBQQ0UgZGlzY292ZXJ5IChSRkMgNTA4OCBhbmQgUkZDIDUwODkpIGRlZmluZSBhIG1ldGhv ZA0KICAgdG8gYWR2ZXJ0aXNlIHBhdGggY29tcHV0YXRpb24gY2FwYWJpbGl0aWVzIHVzaW5nIElH UCBmbG9vZGluZyBmb3INCiAgIE9TUEYgYW5kIElTLUlTIHJlc3BlY3RpdmVseS4gIEhvd2V2ZXIg dGhlc2Ugc3BlY2lmaWNhdGlvbnMgbGFjayBhDQogICBtZXRob2QgdG8gYWR2ZXJ0aXNlIFBDRVAg c2VjdXJpdHkgKGUuZy4sIFRyYW5zcG9ydCBMYXllcg0KICAgU2VjdXJpdHkoVExTKSkgc3VwcG9y dCBjYXBhYmlsaXR5Lg0KDQogICBUaGlzIGRvY3VtZW50IHByb3Bvc2VzIG5ldyBjYXBhYmlsaXR5 IGZsYWcgYml0IGZvciBQQ0UtQ0FQLUZMQUdTIHN1Yi0NCiAgIFRMViB0aGF0IGNhbiBiZSBhbm5v dW5jZWQgYXMgYXR0cmlidXRlIGluIHRoZSBJR1AgYWR2ZXJ0aXNlbWVudCB0bw0KICAgZGlzdHJp YnV0ZSBQQ0VQIHNlY3VyaXR5IHN1cHBvcnQgaW5mb3JtYXRpb24uDQoNCg0KVGhlIElFVEYgZGF0 YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC13dS1wY2UtZGlzY292ZXJ5LXBjZXBzLXN1cHBvcnQvDQoN ClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd3UtcGNlLWRpc2NvdmVyeS1wY2Vwcy1zdXBwb3J0LTAx DQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0 dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXd1LXBjZS1kaXNjb3ZlcnktcGNl cHMtc3VwcG9ydC0wMQ0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KSW50 ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRw Oi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCkkt RC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3Lmll dGYub3JnL3NoYWRvdy5odG1sIG9yIGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0 ZXMudHh0DQo= From nobody Wed Aug 27 08:40:50 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE771A883D; Tue, 26 Aug 2014 13:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7rUovC09t3S; Tue, 26 Aug 2014 13:32:35 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99E701A02BC; Tue, 26 Aug 2014 13:32:31 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7QKWS4c019201; Tue, 26 Aug 2014 21:32:28 +0100 Received: from 950129200 ([66.129.246.4]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7QKWP2C019100 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Aug 2014 21:32:27 +0100 From: "Adrian Farrel" To: Date: Tue, 26 Aug 2014 21:32:25 +0100 Message-ID: <080001cfc16c$da8b1350$8fa139f0$@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: Ac/BbNYNTPSbs7mmTiC8qEhRq5l5uw== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20908.000 X-TM-AS-Result: No--17.976-10.0-31-10 X-imss-scan-details: No--17.976-10.0-31-10 X-TMASE-MatchedRID: Mj3NuCQGYzKBHLccdfPpxmzBijri5+RVEtdrY/Wb3fPa+IH8mvgPVDzA K7q1A+Iip4greFLbomXiKbEoKAv3hZe/bF1ays2SJmbrB1j4Xwqgo7yEQ1t1y8JuW1juhakm35d D76rzBff94EKC68/eHVIfAqDjzY8QZaaZcM4sp6NbuDP8ZuCmXr7xhVTyv5qoY0DjZWmXtn6jxY yRBa/qJX3mXSdV7KK4OubYLCVnBVG8QIu4z6HhEH7cGd19dSFd Archived-At: http://mailarchive.ietf.org/arch/msg/pce/rffanI4bNQ9sQxtnuStA-SUv87Q X-Mailman-Approved-At: Wed, 27 Aug 2014 08:40:49 -0700 Subject: [Pce] Routing Area Tuning - What I heard X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 26 Aug 2014 20:32:38 -0000 Hi, [Please respond on routing-discussion@ietf.org even though I am spamming several lists] Thanks for the input on this topic. I heard a number of opinions about whether to split TE architecture away from RSVP-TE. I think this leads to some roughish consensus as follows: TEAS - core RSVP-TE - RSVP-TE for generic cases - IGP-TE extensions in coordination with IGP WGs - TE architecture - including the applicability of PCE for TE in association with PCE WG - relationships with - OSPF and ISIS as above - PCE as above - MPLS for generalisation of packet-specific protocol extensions - CCAMP for generalisation of non-packet-specific protocol extensions CCAMP - non-packet technology-specific RSVP-TE - non-packet technology-specific IGP-TE in association with IGP WGs - consideration to generalise all protocol extensions via TEAS That leaves... MPLS as it is today, except: - All RSVP-TE work that is not technology-specific for packet goes to TEAS - Any TE architecture work goes to TEAS PCE as it is today, except: - Architectural application of PCE for TE goes to TEAS with coord back to PCE Can you please let me know whether I misheard you badly. Is this a split you can live with? Are there show-stopper issues? Thanks, Adrian From nobody Wed Aug 27 14:12:42 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16AF1A0054 for ; Wed, 27 Aug 2014 14:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHhZEJXW4xuV for ; Wed, 27 Aug 2014 14:12:38 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC0C11A0294 for ; Wed, 27 Aug 2014 14:12:37 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7RLCZNe013633; Wed, 27 Aug 2014 22:12:35 +0100 Received: from 950129200 ([66.129.246.4]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7RLCX5G013592 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Aug 2014 22:12:35 +0100 From: "Adrian Farrel" To: Date: Wed, 27 Aug 2014 22:12:32 +0100 Message-ID: <0a9401cfc23b$9f30aca0$dd9205e0$@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: Ac/CO1pCKz3VVmv3SaKYYrrPXRPehQ== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20912.002 X-TM-AS-Result: No--29.284-10.0-31-10 X-imss-scan-details: No--29.284-10.0-31-10 X-TMASE-MatchedRID: J1szhq7AkrEmMPeO88gK4Jmug812qIbzbv16+gil4jesafcFLFlU1Ej8 AtVpDcmg4Oz5l8gIfJHCdMY5Im9oQW3eoo1RGXewF6z9HGHKwNviZyLfY10wsleilmPI7oJlB5/ kWgq1QbMIT+/jqQ4Natxbv71VBzsaEdh6trsrQ4sOrlBkQa9qFiPclXBzQ1O2fWkSuxNcZl5nkE suGK0jPy7lrRrmADI7MSC0Ai2ahYG/VDG+xJ1b6EfhraIl1XgxRtu4vtjjtzS/ORE7Uoeo3YQ/A 1DgnqjlCx9hjl6HeCqFhdqmgsowUCv2N27ucWqc98sqn8kK3uEIgWIk/VdnUqiUVkU7XsEvPSaw iBLK6ff0xpGjudmzDOVuDguZiI3fUJc+88wC0T62FK5J1KhC+9Iv4RV84lHTzAdJD7JeNMOTgBJ RkV6RTcCzDGl+ASOWF9+CTpd27/CmWOD8X0TFhEhEDfw/93BufkuZtv/FS5piR2FEQ45Mllc2Mh W5zImv9C9CMIwENALFpZ4uKMTUkF0U3RPW+iLPtLDu9qtqKeHRfRfl2l4F3sRd6VScTqyl0YKl9 bej0iyhhm/Bufx2wpL8a7Xm7BLQUwjR4eCx1COjFYHTfcPkwsnlJe2gk8vIzaa9uKDkuMYQYkJr +hPCWZCUZ3ZKMZlejf+14eONGvvDBNgbKIiiTEKcYi5Qw/RVBsHfMFGPbjP9nZJIPtHyFKlTKKi cvsCzLwu64e2+ZvwGPl+qU8AbmB6YoU144tJOaDCzqDR7DPaIESYy7I2v0ueU0qFv58B+v/iJF3 PfFSpxrJSuFVs5TB0ym++vIXCRg2rxO3RTOO+eAiCmPx4NwLTrdaH1ZWqCHOI0tZ7A+B36C0ePs 7A07QKmARN5PTKc Archived-At: http://mailarchive.ietf.org/arch/msg/pce/my1G4xFik3Ul2Icz_nCN5VdkwyQ Cc: pce@ietf.org Subject: [Pce] AD review of draft-ietf-pce-wson-routing-wavelength X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 27 Aug 2014 21:12:40 -0000 Hi authors, I have done my usual AD review of your document in response to the publication request from the working group. The purpose of my review is to iron out any issues in the document and make sure I can support it through IETF last call and IESG evaluation. Many of my comments below are editorial, but a lot of them are questions of clarification or intended function. I would like to discuss these with you and the working group before update the draft. Thanks for the work, Adrian === Abstract Requirements for optical impairments will be addressed in a separate document. I guess you mean Requirements for PCEP extensions in support of optical impairments will be addressed in a separate document. --- A couple of abbreviations are used without expansion... WA DWA I think an intro para in section 2 to break out the terminology of R, WA, and DWA --- 3.1 A PCEP request MUST include the path computation type. I don't understand how a PCC knows whether it needs to know the wavelength or not. Suppose the PCC is an ingress: how does it know whether the network comprises all nodes that cannot perform wavelength conversion, all nodes with limited wavelength conversion, all nodes with full wavelength conversion abilities, or some mixture. In the case of the mixture, the choice of path will determine whether the wavelength must be known or not. In fact, isn't it the PCE that knows whether or not to supply the wavelength based on its knowledge of the network capabilities and possibly based on the path it chose? The PCC, on the other hand, is always happy to have the labels supplied in the ERO, or not. Furthermore, depending on the hops in the selected path, the wavelength assignment may come from the PCE for some hops (path segments) and may be distributed for other hops. It doesn't seem to be as black and white in the dimensions you have painted, but I would suggest that this does not matter because you can push the whole problem to PCE without PCC having to make any choice. --- 3.2 (i) Explicit Label Control (ELC) [RFC4003] Is this the right reference? It doesn't look like it to me! ELC is section 5 of RFC 3473. --- 3.2 (ii) A set of recommended labels. The PCC can select the label based on local policy. Are you talking about a set of suggested labels for each hop? Or a set of potential e2e labels to use (from which the PCC can select just one to use)? --- 3.2 (c) In the case where a valid path is not found, the response MUST include why the path is not found (e.g., no path, wavelength not found, optical quality check failed, etc.) There is no explanation of "optical quality check" in this document. I am concerned that "no path found" and "wavelength not found" are artefacts of the implementation of RWA. Certainly, in the case of R+WA you might fail to find a path before asking for a wavelength, but even in that case, can you be sure that there is no path available because the network is disconnected or because all of the bandwidth (i.e. all of the labels) on some of the links has been used? In that case, how can you choose between "no path" and "no wavelength"? In more general cases, the failure to compute a path is simply the failure to find a path that meets the constraints. This sort of failure is no different to the general PCE computation failures - you can't simply state which single constraint caused the computation failure even if you know that relaxing one of the constraints would have allowed you to find a path because relaxing some other constraint(s) might also have resulted in a path being found. But anyway, how do you anticipate a PCC will react differently to these two different return codes? Can a PCC do anything different in the two cases? Can it vary the request? Can it trigger something in the network? --- 3.3 For consistency with the terminology in 5440, shouldn't you use "synchronized" instead of "simultaneous"? --- 3.3 (a) A PCEP request MUST be able to specify an option for bulk RWA path request. Bulk path request is an ability to request a number of simultaneous RWA path requests. Are you adding a requirement here, or are you saying that any solution must not break existing function? If the latter, why are you singling out this specific function as being special to not break? (b) The PCEP response MUST include the path and the assigned wavelength assigned for each RWA path request specified in the original bulk request. Are you changing SVEC behavior here? Are you making any change to 5440 and 6007? --- 3.4 2. The corresponding response to the re-optimized request MUST provide the re-optimized path and wavelengths. I think you should add: ...even when the request asked for the path or the wavelength to remain unchanged. --- 3.4 3. In case that the path is not found, the response MUST include why the path is not found (e.g., no path, wavelength not found, both path and wavelength not found, etc.) Interesting. Not only do my comments from 3.2 (c) apply, but I have to wonder what it means to be unable to find a path during reoptimization. Isn't the current path always a legitimate reply to a reoptimization request? --- 3.5 or an policy-based restriction s/an/a/ --- Your use of RFC 2119 words is somewhat inconsistent. Sometimes you are setting expectations for the protocol solution Section 3.6 A request for two or more paths MUST be able to include an option and sometimes you are saying what an implementation might do Section 3.5 For any RWA computation type request, the requester (PCC) MAY specify a restriction on the wavelengths to be used While I can derive a protocol requirement from the second type of usage of 2119 language, I think I end up with something ambiguous. For example, in the quoted text it is possible to interpret: - The solution MUST allow the requester to specify a restriction or - The solution MAY allow the requester to specify a restriction I think you need to be clearer. --- s/requestor/requester/ --- 3.6 In a network with wavelength conversion capabilities (e.g. sparse 3R regenerators), a request SHOULD be able to indicate whether a single, continuous wavelength should be allocated or not. In other words, the requesting PCC SHOULD be able to specify the precedence of wavelength continuity even if wavelength conversion is available. I don't object to the PCC being able to have input on this issue, but it isn't clear to me how the PCC is about to know about the network in this way. --- 3.7 I believe this requirement, but not how it is worded. Isn't the actual requirement to allow the PCC to specify the signal type at source, at destination, and state whether transit modification is acceptable? Maybe this section is also lacking a little background information? --- 4.6 Mechanisms defined in this document do not imply any new network operation requirements in addition to those already listed in section 8.6 of [RFC5440]. Are you sure? Are there no assumptions about the distribution of wavelength availability information, and wavelength conversion ability, etc.? -- I think you have an excess of boilerplate at the end of your draft. You can safely delete everything after the Authors' Addresses. (I suspect your Word template thing is out of date.) From nobody Wed Aug 27 14:14:24 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F5A1A0303 for ; Wed, 27 Aug 2014 14:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHn4EmHwMPqI for ; Wed, 27 Aug 2014 14:14:22 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D3B11A0294 for ; Wed, 27 Aug 2014 14:14:22 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7RLEKAp014048; Wed, 27 Aug 2014 22:14:20 +0100 Received: from 950129200 ([66.129.246.4]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7RLEEr4014005 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Aug 2014 22:14:16 +0100 From: "Adrian Farrel" To: References: In-Reply-To: Date: Wed, 27 Aug 2014 22:14:13 +0100 Message-ID: <0aa101cfc23b$dd4688c0$97d39a40$@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: Ac/CO1pCKz3VVmv3SaKYYrrPXRPehQAAGfDg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20912.002 X-TM-AS-Result: No--30.750-10.0-31-10 X-imss-scan-details: No--30.750-10.0-31-10 X-TMASE-MatchedRID: mIMb8eDo9tUuJxpWC5Xkt/HkpkyUphL9Ud7Bjfo+5jTirZszUtFz11iq Ayk7LkbkMIZH9N34VaGVixzznKUbog7WYEeNmTZnuZH4LSX2+NXUZrYvzuo9Asi9AjK6C8p1XxR tKfVFN8MLynERgCJXkkgEM42JoyIBrOGW1uviJ4R+7IhLVmN+u4EcpMn6x9cZnQqircTOm4fLw0 KhHW39TRfEgI1pmTZ8IHnstSOpwtDRhEyb9f1sji4uTw19Klh6rTtVtsxU7BguaIC/E9/9wb/fO LqBOG2pVRPeG5whhcJhxoUsdF3iFVd9anLxZbwb98dQaeX+e7fomPrNi98UBCCsGR9kaG/jpMBU wgqWxUdf54/+QxdWsMgB9NMsd1f7ji7+NEoa90lRYMpsl4IDLeDVpDnEiruU+1u9Dk/9zq+WXGR G0jfp/ZwCAg0q+xEsbNs5EGr8soL+BikoAvJRQRMxKDqgAFSzQxhbwXgdp1zAOWCpvHcDOlGlFT XGAqhNvd5MFbeW3agm7bpJ6BgDVYToZqUCO9J5F0vYDRID+cqd2Wz0X3OaLUYx760ONDcWzX+ry wixZYz9LIvwjzyIrHNDvX+VVWbWsTYmRRlwUwo05OiRm60IbtxWLypmYlZz2e73tJcoE9jxnkTs W1NE9pbceSR3BCkofylF9exmNptH7d1W4nLs8mlHv4vQHqYTVo4lwLFUdisY0A95tjAn+5nnN8Z 0fyTfsVRFSc9P2mhy9aD85oOCm01fsoLovwOe7BI2Kjvg8mgrvS9y1NIABwv5ehI/zNJaWDIiZ4 Fn8Gslt3ERkatgM2RRobfpK1ecnY4buaRVSKeeAiCmPx4NwLTrdaH1ZWqCpvI8UZOf47jUZxEAl FPo846HM5rqDwqtlExlQIQeRG0= Archived-At: http://mailarchive.ietf.org/arch/msg/pce/-d0tuDCsgUzREHJFIERLmfxVYbg Cc: pce@ietf.org Subject: [Pce] FW: AD review of draft-ietf-pce-wson-routing-wavelength X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 27 Aug 2014 21:14:24 -0000 Re-send with correct draft alias address. Adrian > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: 27 August 2014 22:13 > To: 'draft-ietf-pce-wson-routing-wavelength.all@ietf.org' > Cc: 'pce@ietf.org' > Subject: AD review of draft-ietf-pce-wson-routing-wavelength > > Hi authors, > > I have done my usual AD review of your document in response to the > publication request from the working group. The purpose of my review is > to iron out any issues in the document and make sure I can support it > through IETF last call and IESG evaluation. > > Many of my comments below are editorial, but a lot of them are questions > of clarification or intended function. I would like to discuss these > with you and the working group before update the draft. > > Thanks for the work, > Adrian > > === > > Abstract > Requirements for optical impairments will be > addressed in a separate document. > I guess you mean > Requirements for PCEP extensions in support of optical impairments > will be addressed in a separate document. > > --- > > A couple of abbreviations are used without expansion... > WA > DWA > > I think an intro para in section 2 to break out the terminology of > R, WA, and DWA > > --- > > 3.1 > A PCEP request MUST include the path computation type. > > I don't understand how a PCC knows whether it needs to know the > wavelength or not. Suppose the PCC is an ingress: how does it know > whether the network comprises all nodes that cannot perform wavelength > conversion, all nodes with limited wavelength conversion, all nodes > with full wavelength conversion abilities, or some mixture. In the > case of the mixture, the choice of path will determine whether the > wavelength must be known or not. > > In fact, isn't it the PCE that knows whether or not to supply the > wavelength based on its knowledge of the network capabilities and > possibly based on the path it chose? The PCC, on the other hand, is > always happy to have the labels supplied in the ERO, or not. > > Furthermore, depending on the hops in the selected path, the wavelength > assignment may come from the PCE for some hops (path segments) and may > be distributed for other hops. It doesn't seem to be as black and white > in the dimensions you have painted, but I would suggest that this does > not matter because you can push the whole problem to PCE without PCC > having to make any choice. > > --- > > 3.2 > (i) Explicit Label Control (ELC) [RFC4003] > > Is this the right reference? It doesn't look like it to me! > ELC is section 5 of RFC 3473. > > --- > > 3.2 > (ii) A set of recommended labels. The PCC can select the > label based on local policy. > > Are you talking about a set of suggested labels for each hop? > Or a set of potential e2e labels to use (from which the PCC > can select just one to use)? > > --- > > 3.2 > (c) In the case where a valid path is not found, the response MUST > include why the path is not found (e.g., no path, wavelength not > found, optical quality check failed, etc.) > > There is no explanation of "optical quality check" in this document. > > I am concerned that "no path found" and "wavelength not found" are > artefacts of the implementation of RWA. Certainly, in the case of R+WA > you might fail to find a path before asking for a wavelength, but even > in that case, can you be sure that there is no path available because > the network is disconnected or because all of the bandwidth (i.e. all > of the labels) on some of the links has been used? In that case, how > can you choose between "no path" and "no wavelength"? > > In more general cases, the failure to compute a path is simply the > failure to find a path that meets the constraints. This sort of failure > is no different to the general PCE computation failures - you can't > simply state which single constraint caused the computation failure even > if you know that relaxing one of the constraints would have allowed you > to find a path because relaxing some other constraint(s) might also have > resulted in a path being found. > > But anyway, how do you anticipate a PCC will react differently to these > two different return codes? Can a PCC do anything different in the two > cases? Can it vary the request? Can it trigger something in the network? > > --- > > 3.3 > > For consistency with the terminology in 5440, shouldn't you use > "synchronized" instead of "simultaneous"? > > --- > > 3.3 > > (a) A PCEP request MUST be able to specify an option for bulk RWA > path request. Bulk path request is an ability to request a number > of simultaneous RWA path requests. > > Are you adding a requirement here, or are you saying that any solution > must not break existing function? If the latter, why are you singling > out this specific function as being special to not break? > > (b) The PCEP response MUST include the path and the assigned > wavelength assigned for each RWA path request specified in the > original bulk request. > > Are you changing SVEC behavior here? Are you making any change to > 5440 and 6007? > > --- > > 3.4 > 2. The corresponding response to the re-optimized request MUST > provide the re-optimized path and wavelengths. > > I think you should add: > > ...even when the request asked for the path or the wavelength to > remain unchanged. > > --- > > 3.4 > 3. In case that the path is not found, the response MUST include why > the path is not found (e.g., no path, wavelength not found, both > path and wavelength not found, etc.) > > Interesting. Not only do my comments from 3.2 (c) apply, but I have to > wonder what it means to be unable to find a path during reoptimization. > Isn't the current path always a legitimate reply to a reoptimization > request? > > --- > > 3.5 > or an > policy-based restriction > > s/an/a/ > > --- > > Your use of RFC 2119 words is somewhat inconsistent. Sometimes you are > setting expectations for the protocol solution > > Section 3.6 > A request for two or more paths MUST be able to include an option > > and sometimes you are saying what an implementation might do > > Section 3.5 > For any RWA computation type request, the requester (PCC) MAY > specify a restriction on the wavelengths to be used > > While I can derive a protocol requirement from the second type of usage > of 2119 language, I think I end up with something ambiguous. For > example, in the quoted text it is possible to interpret: > > - The solution MUST allow the requester to specify a restriction > or > - The solution MAY allow the requester to specify a restriction > > I think you need to be clearer. > > --- > > s/requestor/requester/ > > --- > > 3.6 > In a network with wavelength conversion capabilities (e.g. sparse 3R > regenerators), a request SHOULD be able to indicate whether a > single, continuous wavelength should be allocated or not. In other > words, the requesting PCC SHOULD be able to specify the precedence > of wavelength continuity even if wavelength conversion is available. > > I don't object to the PCC being able to have input on this issue, but > it isn't clear to me how the PCC is about to know about the network in > this way. > > --- > > 3.7 > > I believe this requirement, but not how it is worded. Isn't the actual > requirement to allow the PCC to specify the signal type at source, at > destination, and state whether transit modification is acceptable? > > Maybe this section is also lacking a little background information? > > --- > > 4.6 > > Mechanisms defined in this document do not imply any new network > operation requirements in addition to those already listed in > section 8.6 of [RFC5440]. > > Are you sure? Are there no assumptions about the distribution of > wavelength availability information, and wavelength conversion ability, > etc.? > > -- > > I think you have an excess of boilerplate at the end of your draft. > You can safely delete everything after the Authors' Addresses. (I > suspect your Word template thing is out of date.) From nobody Thu Aug 28 12:02:37 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101B91A0BEC for ; Thu, 28 Aug 2014 12:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GD9xtjgK7VZm for ; Thu, 28 Aug 2014 12:02:32 -0700 (PDT) Received: from ENFIRHETS1.metaswitch.com (enfirhets1.metaswitch.com [192.91.191.166]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00F481A8991 for ; Thu, 28 Aug 2014 12:02:29 -0700 (PDT) Received: from ENFICSCAS1.datcon.co.uk (172.18.4.13) by ENFIRHETS1.metaswitch.com (172.18.209.22) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 28 Aug 2014 20:02:26 +0100 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFICSCAS1.datcon.co.uk ([fe80::3d12:12a9:26af:c7%11]) with mapi id 14.03.0195.001; Thu, 28 Aug 2014 20:02:28 +0100 From: Jonathan Hardwick To: "adrian@olddog.co.uk" Thread-Topic: [Pce] AD review of draft-ietf-pce-pcep-mib Thread-Index: Ac+0kGZWlNyMwNUoRsOh1m8y7uUVSQDCBy3AAS6G34ABkq/RMA== Date: Thu, 28 Aug 2014 19:02:27 +0000 Message-ID: <09CE6C3BE5E1EA40B987BF5F25D8DDBAF4E96F2F@ENFICSMBX1.datcon.co.uk> References: <000301cfb490$68af4140$3a0dc3c0$@olddog.co.uk> <09CE6C3BE5E1EA40B987BF5F25D8DDBAF4E68BE5@ENFICSMBX1.datcon.co.uk> <045f01cfbc5b$016f9750$044ec5f0$@olddog.co.uk> In-Reply-To: <045f01cfbc5b$016f9750$044ec5f0$@olddog.co.uk> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.10.155] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/Mz43uU7irQCem9ce3t_vS7-ngts Cc: "draft-ietf-pce-pcep-mib.all@tools.ietf.org" , "pce@ietf.org" Subject: Re: [Pce] AD review of draft-ietf-pce-pcep-mib X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 19:02:35 -0000 Hi Adrian I owe you a reply on the requirement for the entity table - my apologies fo= r the delay. The entity table was a feature of the PCEP MIB before I took over editorshi= p of it, so I will defer to the original authors for their motivation in in= cluding it. However, speaking purely for my own implementation, we do need= it for the reasons I gave below and it is used in practice. I don't think this MIB structure is inconsistent with RFC 4750 as it does n= ot prevent an implementation from having one SNMP subagent per routing inst= ance, as RFC 4750 would seem to require. (I am not sure I understand the R= FC 4750 model though. As it stands, wouldn't you need one subagent per PE/= CE routing instance, or per network layer routing instance in a multi-layer= router? Is that really the normal case?) I'm currently in the process of clarifying the text regarding the entity ta= ble and will get back to you on that. Best regards Jon -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: 20 August 2014 10:42 To: Jonathan Hardwick Cc: pce@ietf.org; draft-ietf-pce-pcep-mib.all@tools.ietf.org Subject: RE: [Pce] AD review of draft-ietf-pce-pcep-mib Jon, Thanks for the work. Very few responses from me. > That previous point does cause me to wonder about "PCE capabilities". > I can see that you have tried to limit this module to describing the > features that are core to 5440, but I wonder whether that is wise. >=20 > For example, RFCs 5088 and 5089 define a set of PCE capabilities that > may be advertised in the IGPs and are surely relevant to the model of > a PCE that speaks PCEP. That information might usefully be seen in the > module at the PCE, and also at the PCC so that an operator can check > "why does that PCC keep sending these requests to the wrong PCE?" >=20 > Similarly, the Open Object can carry TLVs that indicate further > capabilities. Obviously you can't just include all future capabilities > TLVs since you don't know what they are (well, you know some, but that > have already been defined, but you can't know the undefined ones). But > you might want to to look at how those capabilities will be hooked in > for future accessibility. >=20 > Of particular interest will be the OF-list TLV of RFC 5541. >=20 > >> The scope of the PCEP MIB is currently limited to objects that are cor= e to RFC > 5440 only. > - The capabilities from RFC 5088/5089 belong in the PCE discovery MIB. > - The OFs in the OF-list TLV deserve their own MIB table, which could be defined > in a separate MIB if anyone wants it. > - There are lots of other PCEP RFCs that we could bring into the scope o= f this > document, but it is already quite large. >=20 > Our preference is to clarify the scope of this document, provide an informational > reference to the discovery MIB, and allow other documents to augment / > supplement the tables we have defined. << OK. Sure. So make sure you have the cross-pointer to the disco MIB module, and think = about how future modules might be able to extend/augment without high price. For example, a TC that is the bit flags for capability is easily extended (= if it is in a separate module). > --- > > I'm wondering under what circumstances the pcepEntityTable has more than > one entry. You might describe that in 4.1 and also in the Description > clause for the table. >=20 > That would tie in with explaining why you have an index of > Unsigned32 (1..2147483647) which allows for quite a lot of entities! >=20 > >> There is one row in this table for each local PCEP entity, of which th= ere may be > multiple. >=20 > One scenario is partitioning a physical router into multiple virtual rout= ers, each > with its own PCC. Another scenario is managing a device which front-ends > multiple PCE compute resources, each with a different set of capabilities= that are > accessed via different IP addresses. >=20 > Although there clearly won't be billions, we feel there's no point in pla= cing an > arbitrary upper limit on the number of local PCEP entities. Our proposal, > therefore, is to remove the artificial restriction on the entity index ra= nge. << OK, I have a bit of a hope that you are doing this because you have a need,= not because it looks like a cool idea! If your text above is just you scraping around for reasons that might justify the structure you have documented, we= ll, then you know what you should do :-) I am trying to compare the case of six physically diverse nodes each with t= heir own instance of the MIB module, and one physical node hosting 6 virtual pcepEntities each as a separate entry in the pcepEntityTable. In the first case, SNMP would use a different IP address to Get each entry = in each pcepEntityTable. In the second case you are suggesting, I think, that there is one SNMP agen= t on the physical node that maintains one copy of the pcepEntityTable, but that = each entry in the table is a separate virtual node. This, I suppose, saves you f= rom having to run a separate SNMP agent on each virtual node even though those virtual nodes are separately addressable. I have no experience of building virtual nodes in this way. I went back to = 4750 to see how this is modelled in OSPF and found that it looks to me that in t= hat case you would run a separate agent for each router instance (of course how= you manage the code and executables -- and even the data -- is up to you, but t= he structure of the MIB module is for a single agent per router instance). Tha= t is clearly shown by the fact that ospfRouterId is a member of ospfGeneralGroup (what you might call a global variable). Because I have no experience in this, I am not going to require you to chan= ge this structure, but I will ask you to explain how "One scenario is partitio= ning a physical router into multiple virtual routers, each with its own PCC" integrates with 4750. Bottom line: if you intend that multiple local PC* instantiations can appea= r in the same table, please make this a bit clearer in the text. Anyway, I still think that Unsigned32 (1..2147483647) may be generous. > Actually, I'm a bit confused about the indexing of the three tables. OK, we can snip here. Given your use of the pcepEntityTable, the remaining indexing makes sense. You will, however, need to add text to explain it. Cheerio, Adrian From nobody Thu Aug 28 13:57:39 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B5C1A01C5 for ; Thu, 28 Aug 2014 13:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.267 X-Spam-Level: X-Spam-Status: No, score=-4.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULfXeGnMP8hk for ; Thu, 28 Aug 2014 13:57:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 535131A01BD for ; Thu, 28 Aug 2014 13:57:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIV55983; Thu, 28 Aug 2014 20:57:29 +0000 (GMT) Received: from DFWEML701-CHM.china.huawei.com (10.193.5.50) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 28 Aug 2014 21:57:29 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml701-chm ([10.193.5.50]) with mapi id 14.03.0158.001; Thu, 28 Aug 2014 13:57:26 -0700 From: Leeyoung To: "adrian@olddog.co.uk" , "draft-ietf-pce-wson-routing-wavelength.all@tools.ietf.org" Thread-Topic: [Pce] FW: AD review of draft-ietf-pce-wson-routing-wavelength Thread-Index: AQHPwjvpQQpyy+jzNkWrJZpZibfdDJvk9N2g Date: Thu, 28 Aug 2014 20:57:25 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C2CA8C@dfweml706-chm> References: <0aa101cfc23b$dd4688c0$97d39a40$@olddog.co.uk> In-Reply-To: <0aa101cfc23b$dd4688c0$97d39a40$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.131.92] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pce/O8k6uj6h2ZDgve3JNkYKQ3OE988 Cc: "pce@ietf.org" Subject: Re: [Pce] FW: AD review of draft-ietf-pce-wson-routing-wavelength X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 20:57:37 -0000 Hi Adrian, Thanks for providing your timely review and valuable comments/suggestions o= f this draft.=20 Please see inline for my comment.=20 Regards, Young=20 -----Original Message----- From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Wednesday, August 27, 2014 4:14 PM To: draft-ietf-pce-wson-routing-wavelength.all@tools.ietf.org Cc: pce@ietf.org Subject: [Pce] FW: AD review of draft-ietf-pce-wson-routing-wavelength Re-send with correct draft alias address. Adrian > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: 27 August 2014 22:13 > To: 'draft-ietf-pce-wson-routing-wavelength.all@ietf.org' > Cc: 'pce@ietf.org' > Subject: AD review of draft-ietf-pce-wson-routing-wavelength >=20 > Hi authors, >=20 > I have done my usual AD review of your document in response to the=20 > publication request from the working group. The purpose of my review=20 > is to iron out any issues in the document and make sure I can support=20 > it through IETF last call and IESG evaluation. >=20 > Many of my comments below are editorial, but a lot of them are=20 > questions of clarification or intended function. I would like to=20 > discuss these with you and the working group before update the draft. >=20 > Thanks for the work, > Adrian >=20 > =3D=3D=3D >=20 > Abstract > Requirements for optical impairments will be > addressed in a separate document. > I guess you mean > Requirements for PCEP extensions in support of optical impairments > will be addressed in a separate document. >=20 [Young] Thanks. Yes. Will change per your clarification.=20 > --- >=20 > A couple of abbreviations are used without expansion... > WA > DWA >=20 > I think an intro para in section 2 to break out the terminology of R,=20 > WA, and DWA >=20 [Young] Added in the first paragraph in Section 2 before the figure:=20 "R stands for Routing, WA for Wavelength Assignment, and DWA for Distribute= d Wavelength Assignment."=20 > --- >=20 > 3.1 > A PCEP request MUST include the path computation type. >=20 > I don't understand how a PCC knows whether it needs to know the=20 > wavelength or not. Suppose the PCC is an ingress: how does it know=20 > whether the network comprises all nodes that cannot perform wavelength=20 > conversion, all nodes with limited wavelength conversion, all nodes=20 > with full wavelength conversion abilities, or some mixture. In the=20 > case of the mixture, the choice of path will determine whether the=20 > wavelength must be known or not. [YOUNG] The PCC does not know which ones have wavelength conversion capabil= ity, etc. That is the reason the PCC to inquire PCE of the wavelength assig= nment including some conversion (as the PCE has all these info.). But, I th= ink you are saying this in the next paragraph. Only thing PCC knows that it= needs an optical path computation from PCE that comprises not only R (rout= ing), but also WA (wavelength assignment) in most cases. Why then Routing o= nly option? We assume that PCC has some prior knowledge about its policy/ca= pability (e.g., distributed WA at each node).=20 >=20 > In fact, isn't it the PCE that knows whether or not to supply the=20 > wavelength based on its knowledge of the network capabilities and=20 > possibly based on the path it chose? The PCC, on the other hand, is=20 > always happy to have the labels supplied in the ERO, or not. [Young] Yes. The PCC is passive here. Whatever the PCE sends back, the PCC = is happy.=20 >=20 > Furthermore, depending on the hops in the selected path, the=20 > wavelength assignment may come from the PCE for some hops (path=20 > segments) and may be distributed for other hops. It doesn't seem to be=20 > as black and white in the dimensions you have painted, but I would=20 > suggest that this does not matter because you can push the whole=20 > problem to PCE without PCC having to make any choice. [Young] Absolutely.=20 >=20 > --- >=20 > 3.2 > (i) Explicit Label Control (ELC) [RFC4003] >=20 > Is this the right reference? It doesn't look like it to me! > ELC is section 5 of RFC 3473. >=20 [Young] You're correct. Will change. Replaced RFC4003 with RFC 3473 in Sect= ion 8.2 as well. > --- >=20 > 3.2 > (ii) A set of recommended labels. The PCC can select the > label based on local policy. >=20 > Are you talking about a set of suggested labels for each hop? > Or a set of potential e2e labels to use (from which the PCC can select=20 > just one to use)? [Young] Good question. The intention here is the former. As each node/pcc p= rocesses and selects it own label, then the signaling will carry the rest o= f the labels available for the next hop (minus the one selected), etc.=20 >=20 > --- >=20 > 3.2 > (c) In the case where a valid path is not found, the response MUST > include why the path is not found (e.g., no path, wavelength not > found, optical quality check failed, etc.) >=20 > There is no explanation of "optical quality check" in this document. [Young] It was an illustrative example. I will delete that phrase.=20 >=20 > I am concerned that "no path found" and "wavelength not found" are=20 > artefacts of the implementation of RWA. Certainly, in the case of R+WA=20 > you might fail to find a path before asking for a wavelength, but even=20 > in that case, can you be sure that there is no path available because=20 > the network is disconnected or because all of the bandwidth (i.e. all=20 > of the labels) on some of the links has been used? In that case, how=20 > can you choose between "no path" and "no wavelength"? [Young] Yah, there is some subtlety here. "No path" available is primarily = to indicate that the network is disconnected for the requested path for a S= -D pair. Of course, this also implies "no wavelength" situation. However, t= here are cases where there is path (b/w) but it fails to meet wavelength co= ntinuity constraint. For instance a node has wavelength x available toward = the next hop. But the next hop does not have wavelength x (say it has wavel= ength y) and it has no conversion capability. "No Wavelength" indicates thi= s situation.=20 >=20 > In more general cases, the failure to compute a path is simply the=20 > failure to find a path that meets the constraints. This sort of=20 > failure is no different to the general PCE computation failures - you=20 > can't simply state which single constraint caused the computation=20 > failure even if you know that relaxing one of the constraints would=20 > have allowed you to find a path because relaxing some other=20 > constraint(s) might also have resulted in a path being found. >=20 > But anyway, how do you anticipate a PCC will react differently to=20 > these two different return codes? Can a PCC do anything different in=20 > the two cases? Can it vary the request? Can it trigger something in the n= etwork? [Young] In general cases, a PCC may not react differently. On the other han= d, I can envision in advanced cases where the PCC may react differently for= the case of a "No Wavelength" error. Upon receipt of "no wavelength" indic= ator from the PCE, the PCC may trigger a "Re-optimization" request (as expl= ained in Section 3.4) of some existing path in an hope to release the confl= icted wavelength. But this sounds like a bit wacky. :) >=20 > --- >=20 > 3.3 >=20 > For consistency with the terminology in 5440, shouldn't you use=20 > "synchronized" instead of "simultaneous"? [Young] No problem. We can use "synchronized" in place of "simultaneous."=20 >=20 > --- >=20 > 3.3 >=20 > (a) A PCEP request MUST be able to specify an option for bulk RWA > path request. Bulk path request is an ability to request a number > of simultaneous RWA path requests. >=20 > Are you adding a requirement here, or are you saying that any solution=20 > must not break existing function? If the latter, why are you singling=20 > out this specific function as being special to not break? [Young] I am adding a new requirement to be able to specify a bulk "RWA" re= quest indication analogous to section 3.1 for a single "RWA" request.=20 >=20 > (b) The PCEP response MUST include the path and the assigned > wavelength assigned for each RWA path request specified in the > original bulk request. >=20 > Are you changing SVEC behavior here? Are you making any change to 5440=20 > and 6007? [Young] I think the encoding for SVEC can potentially include "WA" portion = or some other ways to indicate the path result (which is yet to be determin= ed). But, I don't think we are changing SVEC behavior. =20 >=20 > --- >=20 > 3.4 > 2. The corresponding response to the re-optimized request MUST > provide the re-optimized path and wavelengths. >=20 > I think you should add: >=20 > ...even when the request asked for the path or the wavelength to > remain unchanged. [Young] OK. No problem! >=20 > --- >=20 > 3.4 > 3. In case that the path is not found, the response MUST include why > the path is not found (e.g., no path, wavelength not found, both > path and wavelength not found, etc.) >=20 > Interesting. Not only do my comments from 3.2 (c) apply, but I have to=20 > wonder what it means to be unable to find a path during reoptimization. > Isn't the current path always a legitimate reply to a reoptimization=20 > request? [Young] Not able to find a path during reoptimization means there is no alt= ernative path available than the current path. Here perhaps I can add some = phrase to clarify this: OLD: In case that the path is not found NEW: In case that the new path (i.e., other than the current path) is not f= ound >=20 > --- >=20 > 3.5 > or an > policy-based restriction >=20 > s/an/a/ >=20 [Young] Yes. Thanks. > --- >=20 > Your use of RFC 2119 words is somewhat inconsistent. Sometimes you are=20 > setting expectations for the protocol solution >=20 > Section 3.6 > A request for two or more paths MUST be able to include an option >=20 > and sometimes you are saying what an implementation might do >=20 > Section 3.5 > For any RWA computation type request, the requester (PCC) MAY > specify a restriction on the wavelengths to be used >=20 > While I can derive a protocol requirement from the second type of=20 > usage of 2119 language, I think I end up with something ambiguous. For=20 > example, in the quoted text it is possible to interpret: >=20 > - The solution MUST allow the requester to specify a restriction > or > - The solution MAY allow the requester to specify a restriction >=20 > I think you need to be clearer. [Young] Good point. I think it "MUST allow" is what is intended.=20 How about: Section 3.6 OLD: A request for two or more paths MUST be able to include an option NEW: A request for two or more paths MUST allow the requester to include an= option Section 3.5 OLD: For any RWA computation type request, the requester (PCC) MAY specify = a restriction on the wavelengths to be used NEW: For any RWA computation type request, the requester (PCC) MUST be allo= wed to specify a restriction on the wavelengths to be used >=20 > --- >=20 > s/requestor/requester/ [Young] OK. Thanks.=20 >=20 > --- >=20 > 3.6 > In a network with wavelength conversion capabilities (e.g. sparse 3R > regenerators), a request SHOULD be able to indicate whether a > single, continuous wavelength should be allocated or not. In other > words, the requesting PCC SHOULD be able to specify the precedence > of wavelength continuity even if wavelength conversion is available. >=20 > I don't object to the PCC being able to have input on this issue, but=20 > it isn't clear to me how the PCC is about to know about the network in=20 > this way. [Young] Do you think how the PCC know about the network is in scope of disc= ussion in this particular draft? I didn't think so. The PCC can be an NMS o= r network planner that knows some networks via policy or some other support= ing systems. Even in the case that the PCC is a node, this knowledge may be= inferred from its local database or some other ways. Is this a reasonable = assumption?=20 >=20 > --- >=20 > 3.7 >=20 > I believe this requirement, but not how it is worded. Isn't the actual=20 > requirement to allow the PCC to specify the signal type at source, at=20 > destination, and state whether transit modification is acceptable? >=20 > Maybe this section is also lacking a little background information? [Young] Yes, it is not clear as is. How about the following for Section 3.7= : NEW:=20 Signal processing compatibility is an important constraint for optical path= computation. The signal type for an end-to-end optical path must match at = source and at destination.=20 The PCC MUST be allowed to specify the signal type at the endpoints (i.e., = at source and at destination). The following signal processing capabilities= should be supported at a minimum: o Modulation Type List o FEC Type List The PCC MUST also be allowed to state whether transit modification is accep= table for the above signal processing capabilities.=20 End of NEW =20 >=20 > --- >=20 > 4.6 >=20 > Mechanisms defined in this document do not imply any new network > operation requirements in addition to those already listed in > section 8.6 of [RFC5440]. >=20 > Are you sure? Are there no assumptions about the distribution of=20 > wavelength availability information, and wavelength conversion=20 > ability, etc.? >=20 [Young] Network Operation Impacts in 8.6 of RFC 5440 deal with primarily PC= EP speaker sessions and how to limit it in case of operational impacts or o= f this nature. The distribution of optical information you mentioned in a P= CEP context is simple adding more info just like other PCEP extensions, isn= 't it?=20 =20 > -- >=20 > I think you have an excess of boilerplate at the end of your draft. > You can safely delete everything after the Authors' Addresses. (I=20 > suspect your Word template thing is out of date.) [Young] deleted. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From nobody Fri Aug 29 05:09:39 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9F41A0173 for ; Fri, 29 Aug 2014 05:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.188 X-Spam-Level: X-Spam-Status: No, score=0.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bc1RgQISvoDt for ; Fri, 29 Aug 2014 05:09:34 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 538A71A0176 for ; Fri, 29 Aug 2014 05:09:34 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-38-5400189fed9c Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 83.54.05330.F9810045; Fri, 29 Aug 2014 08:07:28 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Fri, 29 Aug 2014 08:09:32 -0400 From: Uma Chunduri To: Qin Wu , "pce@ietf.org" Thread-Topic: I-D Action: draft-wu-pce-discovery-pceps-support-01.txt Thread-Index: AQHPt34VeZpZpUDEXk+lwdwtWfp7gZvkTWGggANFqOA= Date: Fri, 29 Aug 2014 12:09:32 +0000 Message-ID: <1B502206DFA0C544B7A60469152008633F36931A@eusaamb105.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyuXSPn+4CCYYQg6Un2C0ez13AatF0/wa7 A5NHy5G3rB5LlvxkCmCK4rJJSc3JLEst0rdL4MpY1JVV0KNZcWSjaQNji0YXIyeHhICJxM+9 y5ggbDGJC/fWs3UxcnEICRxllOhevIMJwlnOKPFvdj8rSBWbgJ7Ex6k/2UFsEQE7iUX7ZzGC 2MICLhI7Fmxigoi7SuyadowFwraSaLk2gRnEZhFQlei8/AFsDq+Ar0T/8lNgvUICoRK31x0H q+cUCJO4t3YvWD0j0EXfT60Bm8ksIC5x68l8qEsFJJbsOc8MYYtKvHz8jxXCVpTY1z+dHaJe S2Jew2+oXkWJKd0P2SH2CkqcnPmEZQKj6CwkY2chaZmFpGUWkpYFjCyrGDlKi1PLctONDDYx AmPhmASb7g7GPS8tDzEKcDAq8fAmLPsfLMSaWFZcmXuIUZqDRUmcd1btvGAhgfTEktTs1NSC 1KL4otKc1OJDjEwcnFINjMJ8IvovHC5NT1/ydTbP4twlbTIcG5s2LuPVXHDUWCQqjz/pKc+l V622z+eq+vC+Pcr5KYhTLUz3+LJPkyu1Qu0WOmvuXG65PDzT8f+T0KPR7taStjaeb/pWxITs /qtQ8+mht8zzkwp28Re9p6VpaPJsafvOcXCzwk/DF5P8Gasn3PxptdHxsBJLcUaioRZzUXEi AH3ztShmAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/pce/WaU76kq1QHgWK87xGY7qmwHf8rc Subject: Re: [Pce] I-D Action: draft-wu-pce-discovery-pceps-support-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 12:09:36 -0000 PkF1dGhvcnMgZmVlbCBpdCB3aWxsIGJlIGEgZ29vZCB0byBoYXZlIHRoaXMgZHJhZnQgc2VwYXJh dGVseSByYXRoZXIgdGhhbiBzaW1wbHkgbWVyZ2luZyBpbnRvIGRyYWZ0LWlldGYtcGNlLXBjZXBz Lg0KPkFueSBvcGluaW9ucyBvciBvYmplY3Rpb24/DQoNCklNTywga2VlcGluZyBzZXBhcmF0ZSBp cyBnb29kIGFzIHNjb3BlIGlzIGRpZmZlcmVudCBpbiBib3RoLg0KDQpJIGFuZCBEaWVnbyBoYWQg Y2hhdCBvZmZsaW5lIG9uIHRoaXMgYnV0IGhvdyB0aGlzIGRpc2NvdmVyeSBpcyBiZW5lZmljaWFs IGFzIHlvdSBzdGlsbCBvcGVyYXRvciBoYXZlIHRvIGNvbmZpZ3VyZSBBVVRIL1NlY3VyaXR5IGNy ZWRlbnRpYWxzIG9uIHRoZSBub2Rlcy4NCkkgYW0gYXNraW5nIHRoaXMgaW4gcGFydGljdWxhciBh cyBzY29wZSBpcyBNRCwgQU8gYW5kIFRMUy4NCg0KQWxzbyBJIHNlZSBQQ0UgaGFzIHRvIGJlIHBh cnQgb2YgdGhlIElHUCBoZXJlLCB3aGVyZWFzIEkgc2VlIGRyYWZ0LWlldGYtcGNlLXBjZXBzIGRv ZXNuJ3QgbWFuZGF0ZSB0aGlzIChkb2VzIGl0Pz8pIA0KDQpNb3JlIGxhdGVyLg0KLS0NClVtYSBD Lg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBQY2UgW21haWx0bzpwY2Ut Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFFpbiBXdQ0KU2VudDogV2VkbmVzZGF5LCBB dWd1c3QgMjcsIDIwMTQgMzoxMCBBTQ0KVG86IHBjZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtQ Y2VdIEktRCBBY3Rpb246IGRyYWZ0LXd1LXBjZS1kaXNjb3ZlcnktcGNlcHMtc3VwcG9ydC0wMS50 eHQNCg0KSGksDQpIZXJlIGlzIHRoZSB1cGRhdGUgdG8gZHJhZnQtd3UtcGNlLWRpc2NvdmVyeS1w Y2Vwcy1zdXBwb3J0LTAxLiBUaGUgbW9zdCBjaGFuZ2VzIGFyZSBlZGl0b3JpYWwgY2hhbmdlcy4N ClRoZSBkaWZmIGlzOg0KaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtd3Ut cGNlLWRpc2NvdmVyeS1wY2Vwcy1zdXBwb3J0LTAxDQoNClRoaXMgZHJhZnQgcHJvdmlkZXMgYSBt ZWNoYW5pc20gZm9yIFBDQyB0byBkaXNjb3ZlciBQQ0Ugd2l0aCBUTFMgc3VwcG9ydC4NCkluIGFk ZGl0aW9uLCB0aGUgZHJhZnQgYWxzbyBzdXBwb3J0IGRpc2NvdmVyeSBvZiBQQ0Ugc2VydmVyIHdp dGggTUQgc3VwcG9ydCwgVENQLUFPIHN1cHBvcnQgcmVzcGVjdGl2ZWx5Lg0KQXV0aG9ycyBmZWVs IGl0IHdpbGwgYmUgYSBnb29kIHRvIGhhdmUgdGhpcyBkcmFmdCBzZXBhcmF0ZWx5IHJhdGhlciB0 aGFuIHNpbXBseSBtZXJnaW5nIGludG8gZHJhZnQtaWV0Zi1wY2UtcGNlcHMuDQpBbnkgb3Bpbmlv bnMgb3Igb2JqZWN0aW9uPw0KDQpSZWdhcmRzIQ0KLVFpbg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3 orz+yMs6IEktRC1Bbm5vdW5jZSBbbWFpbHRvOmktZC1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3Jn XSC0+rHtIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0Kt6LLzcqxvOQ6IDIwMTTE6jjUwjE0yNUg MTM6MTANCsrVvP7IyzogaS1kLWFubm91bmNlQGlldGYub3JnDQrW98ziOiBJLUQgQWN0aW9uOiBk cmFmdC13dS1wY2UtZGlzY292ZXJ5LXBjZXBzLXN1cHBvcnQtMDEudHh0DQoNCg0KQSBOZXcgSW50 ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRz IGRpcmVjdG9yaWVzLg0KDQoNCiAgICAgICAgVGl0bGUgICAgICAgICAgIDogSUdQIGV4dGVuc2lv biBmb3IgUENFUCBzZWN1cml0eSBjYXBhYmlsaXR5IHN1cHBvcnQgaW4gdGhlIFBDRSBkaXNjb3Zl cnkNCiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogRGllZ28gUi4gTG9wZXoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgUWluIFd1DQogICAgICAgICAgICAgICAgICAgICAgICAgIERocnV2IERo b2R5DQogICAgICAgICAgICAgICAgICAgICAgICAgIERhbmllbCBLaW5nDQoJRmlsZW5hbWUgICAg ICAgIDogZHJhZnQtd3UtcGNlLWRpc2NvdmVyeS1wY2Vwcy1zdXBwb3J0LTAxLnR4dA0KCVBhZ2Vz ICAgICAgICAgICA6IDYNCglEYXRlICAgICAgICAgICAgOiAyMDE0LTA4LTEzDQoNCkFic3RyYWN0 Og0KICAgV2hlbiBhIFBhdGggQ29tcHV0YXRpb24gRWxlbWVudCAoUENFKSBpcyBhIExhYmVsIFN3 aXRjaGluZyBSb3V0ZXINCiAgIChMU1IpIHBhcnRpY2lwYXRpbmcgaW4gdGhlIEludGVyaW9yIEdh dGV3YXkgUHJvdG9jb2wgKElHUCksIG9yIGV2ZW4gYQ0KICAgc2VydmVyIHBhcnRpY2lwYXRpbmcg aW4gSUdQLCBpdHMgcHJlc2VuY2UgYW5kIHBhdGggY29tcHV0YXRpb24NCiAgIGNhcGFiaWxpdGll cyBjYW4gYmUgYWR2ZXJ0aXNlZCB1c2luZyBJR1AgZmxvb2RpbmcuICBUaGUgSUdQDQogICBleHRl bnNpb25zIGZvciBQQ0UgZGlzY292ZXJ5IChSRkMgNTA4OCBhbmQgUkZDIDUwODkpIGRlZmluZSBh IG1ldGhvZA0KICAgdG8gYWR2ZXJ0aXNlIHBhdGggY29tcHV0YXRpb24gY2FwYWJpbGl0aWVzIHVz aW5nIElHUCBmbG9vZGluZyBmb3INCiAgIE9TUEYgYW5kIElTLUlTIHJlc3BlY3RpdmVseS4gIEhv d2V2ZXIgdGhlc2Ugc3BlY2lmaWNhdGlvbnMgbGFjayBhDQogICBtZXRob2QgdG8gYWR2ZXJ0aXNl IFBDRVAgc2VjdXJpdHkgKGUuZy4sIFRyYW5zcG9ydCBMYXllcg0KICAgU2VjdXJpdHkoVExTKSkg c3VwcG9ydCBjYXBhYmlsaXR5Lg0KDQogICBUaGlzIGRvY3VtZW50IHByb3Bvc2VzIG5ldyBjYXBh YmlsaXR5IGZsYWcgYml0IGZvciBQQ0UtQ0FQLUZMQUdTIHN1Yi0NCiAgIFRMViB0aGF0IGNhbiBi ZSBhbm5vdW5jZWQgYXMgYXR0cmlidXRlIGluIHRoZSBJR1AgYWR2ZXJ0aXNlbWVudCB0bw0KICAg ZGlzdHJpYnV0ZSBQQ0VQIHNlY3VyaXR5IHN1cHBvcnQgaW5mb3JtYXRpb24uDQoNCg0KVGhlIElF VEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13dS1wY2UtZGlzY292ZXJ5LXBjZXBzLXN1cHBv cnQvDQoNClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd3UtcGNlLWRpc2NvdmVyeS1wY2Vwcy1zdXBw b3J0LTAxDQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBh dDoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXd1LXBjZS1kaXNjb3Zl cnktcGNlcHMtc3VwcG9ydC0wMQ0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4N Cg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0 Og0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5vdW5jZSBtYWlsaW5nIGxp c3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8v d3d3LmlldGYub3JnL3NoYWRvdy5odG1sIG9yIGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFk b3ctc2l0ZXMudHh0DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KUGNlIG1haWxpbmcgbGlzdA0KUGNlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3BjZQ0K From nobody Fri Aug 29 05:59:45 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 588381A02DB for ; Fri, 29 Aug 2014 05:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fevJe9z61vXk for ; Fri, 29 Aug 2014 05:59:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4B371A0278 for ; Fri, 29 Aug 2014 05:59:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIW18974; Fri, 29 Aug 2014 12:59:30 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 29 Aug 2014 13:59:29 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.209]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Fri, 29 Aug 2014 20:59:24 +0800 From: Qin Wu To: Uma Chunduri , "pce@ietf.org" Thread-Topic: I-D Action: draft-wu-pce-discovery-pceps-support-01.txt Thread-Index: AQHPt34VeZpZpUDEXk+lwdwtWfp7gZvkTWGggANFqOCAAA1fsA== Date: Fri, 29 Aug 2014 12:59:22 +0000 Message-ID: References: <1B502206DFA0C544B7A60469152008633F36931A@eusaamb105.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A60469152008633F36931A@eusaamb105.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pce/OP5BMUO1HVZjC-xGB1h8rJMGyoE Subject: Re: [Pce] I-D Action: draft-wu-pce-discovery-pceps-support-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 12:59:37 -0000 SGksIFVtYToNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cywgc2VlIG15IHJlbHkgaW5saW5lIGJl bG93Lg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IFVtYSBDaHVuZHVyaSBbbWFpbHRvOnVt YS5jaHVuZHVyaUBlcmljc3Nvbi5jb21dIA0Kt6LLzcqxvOQ6IDIwMTTE6jjUwjI5yNUgMjA6MTAN CsrVvP7IyzogUWluIFd1OyBwY2VAaWV0Zi5vcmcNCtb3zOI6IFJFOiBJLUQgQWN0aW9uOiBkcmFm dC13dS1wY2UtZGlzY292ZXJ5LXBjZXBzLXN1cHBvcnQtMDEudHh0DQoNCj4+QXV0aG9ycyBmZWVs IGl0IHdpbGwgYmUgYSBnb29kIHRvIGhhdmUgdGhpcyBkcmFmdCBzZXBhcmF0ZWx5IHJhdGhlciB0 aGFuIHNpbXBseSBtZXJnaW5nIGludG8gZHJhZnQtaWV0Zi1wY2UtcGNlcHMuDQo+PkFueSBvcGlu aW9ucyBvciBvYmplY3Rpb24/DQoNCj5JTU8sIGtlZXBpbmcgc2VwYXJhdGUgaXMgZ29vZCBhcyBz Y29wZSBpcyBkaWZmZXJlbnQgaW4gYm90aC4NCg0KPkkgYW5kIERpZWdvIGhhZCBjaGF0IG9mZmxp bmUgb24gdGhpcyBidXQgaG93IHRoaXMgZGlzY292ZXJ5IGlzIGJlbmVmaWNpYWwgYXMgeW91IHN0 aWxsIG9wZXJhdG9yIGhhdmUgdG8gY29uZmlndXJlIEFVVEgvU2VjdXJpdHkgY3JlZGVudGlhbHMg b24gdGhlIG5vZGVzLg0KDQpbUWluXTogSSB0aGluayB0aGUgaW1wb3J0YW5jZSBvZiB0aGlzIGRp c2NvdmVyeSBpcyBpbiB0aGUgZGVwbG95bWVudHMgd2hpY2ggYWxsb3cgbXVsdGlwbGUgY2hvaWNl cyBmb3Igc2VjdXJpdHkgY3JlZGVudGlhbHMuDQp3aXRob3V0IHN1Y2ggZGlzY292ZXJ5LCBpdCBs ZWFkcyB0byB1bmV4cGVjdGVkIGZhaWx1cmUgb3IgYWRkaXRpb25hbCBtZXNzYWdlIGV4Y2hhbmdl IGlzIG5lZWRlZCB0byBpbmRpY2F0ZSBlcnJvciB0byBQQ0MgdXNpbmcgUENFcnIgbWVzc2FnZS4N Cg0KPkkgYW0gYXNraW5nIHRoaXMgaW4gcGFydGljdWxhciBhcyBzY29wZSBpcyBNRCwgQU8gYW5k IFRMUy4NCg0KPkFsc28gSSBzZWUgUENFIGhhcyB0byBiZSBwYXJ0IG9mIHRoZSBJR1AgaGVyZSwg d2hlcmVhcyBJIHNlZSBkcmFmdC1pZXRmLXBjZS1wY2VwcyBkb2Vzbid0IG1hbmRhdGUgdGhpcyAo ZG9lcyBpdD8/KSANCg0KW1Fpbl06IFRoYXQgaXMgY29ycmVjdCwgZHJhZnQtaWV0Zi1wY2UtcGNl cHMgZG9lc24ndCBuZWVkIHRvIGNvdXBsZSB3aXRoIElHUCBkaXNjb3ZlcnksIGRyYWZ0LWlldGYt cGNlLXBjZXBzIG1heSBsZXZlcmFnZSBvdGhlciBkaXNjb3ZlcnkgbWVjaGFuaXNtLCBlLmcuLA0K RE5TIGJhc2VkIFBDRSBkaXNjb3ZlcnkgbWVjaGFuaXNtLg0KDQpNb3JlIGxhdGVyLg0KLS0NClVt YSBDLg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBQY2UgW21haWx0bzpw Y2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFFpbiBXdQ0KU2VudDogV2VkbmVzZGF5 LCBBdWd1c3QgMjcsIDIwMTQgMzoxMCBBTQ0KVG86IHBjZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtQY2VdIEktRCBBY3Rpb246IGRyYWZ0LXd1LXBjZS1kaXNjb3ZlcnktcGNlcHMtc3VwcG9ydC0w MS50eHQNCg0KSGksDQpIZXJlIGlzIHRoZSB1cGRhdGUgdG8gZHJhZnQtd3UtcGNlLWRpc2NvdmVy eS1wY2Vwcy1zdXBwb3J0LTAxLiBUaGUgbW9zdCBjaGFuZ2VzIGFyZSBlZGl0b3JpYWwgY2hhbmdl cy4NClRoZSBkaWZmIGlzOg0KaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt d3UtcGNlLWRpc2NvdmVyeS1wY2Vwcy1zdXBwb3J0LTAxDQoNClRoaXMgZHJhZnQgcHJvdmlkZXMg YSBtZWNoYW5pc20gZm9yIFBDQyB0byBkaXNjb3ZlciBQQ0Ugd2l0aCBUTFMgc3VwcG9ydC4NCklu IGFkZGl0aW9uLCB0aGUgZHJhZnQgYWxzbyBzdXBwb3J0IGRpc2NvdmVyeSBvZiBQQ0Ugc2VydmVy IHdpdGggTUQgc3VwcG9ydCwgVENQLUFPIHN1cHBvcnQgcmVzcGVjdGl2ZWx5Lg0KQXV0aG9ycyBm ZWVsIGl0IHdpbGwgYmUgYSBnb29kIHRvIGhhdmUgdGhpcyBkcmFmdCBzZXBhcmF0ZWx5IHJhdGhl ciB0aGFuIHNpbXBseSBtZXJnaW5nIGludG8gZHJhZnQtaWV0Zi1wY2UtcGNlcHMuDQpBbnkgb3Bp bmlvbnMgb3Igb2JqZWN0aW9uPw0KDQpSZWdhcmRzIQ0KLVFpbg0KLS0tLS3Tyrz+1K28/i0tLS0t DQq3orz+yMs6IEktRC1Bbm5vdW5jZSBbbWFpbHRvOmktZC1hbm5vdW5jZS1ib3VuY2VzQGlldGYu b3JnXSC0+rHtIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0Kt6LLzcqxvOQ6IDIwMTTE6jjUwjE0 yNUgMTM6MTANCsrVvP7IyzogaS1kLWFubm91bmNlQGlldGYub3JnDQrW98ziOiBJLUQgQWN0aW9u OiBkcmFmdC13dS1wY2UtZGlzY292ZXJ5LXBjZXBzLXN1cHBvcnQtMDEudHh0DQoNCg0KQSBOZXcg SW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJh ZnRzIGRpcmVjdG9yaWVzLg0KDQoNCiAgICAgICAgVGl0bGUgICAgICAgICAgIDogSUdQIGV4dGVu c2lvbiBmb3IgUENFUCBzZWN1cml0eSBjYXBhYmlsaXR5IHN1cHBvcnQgaW4gdGhlIFBDRSBkaXNj b3ZlcnkNCiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogRGllZ28gUi4gTG9wZXoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgUWluIFd1DQogICAgICAgICAgICAgICAgICAgICAgICAgIERocnV2 IERob2R5DQogICAgICAgICAgICAgICAgICAgICAgICAgIERhbmllbCBLaW5nDQoJRmlsZW5hbWUg ICAgICAgIDogZHJhZnQtd3UtcGNlLWRpc2NvdmVyeS1wY2Vwcy1zdXBwb3J0LTAxLnR4dA0KCVBh Z2VzICAgICAgICAgICA6IDYNCglEYXRlICAgICAgICAgICAgOiAyMDE0LTA4LTEzDQoNCkFic3Ry YWN0Og0KICAgV2hlbiBhIFBhdGggQ29tcHV0YXRpb24gRWxlbWVudCAoUENFKSBpcyBhIExhYmVs IFN3aXRjaGluZyBSb3V0ZXINCiAgIChMU1IpIHBhcnRpY2lwYXRpbmcgaW4gdGhlIEludGVyaW9y IEdhdGV3YXkgUHJvdG9jb2wgKElHUCksIG9yIGV2ZW4gYQ0KICAgc2VydmVyIHBhcnRpY2lwYXRp bmcgaW4gSUdQLCBpdHMgcHJlc2VuY2UgYW5kIHBhdGggY29tcHV0YXRpb24NCiAgIGNhcGFiaWxp dGllcyBjYW4gYmUgYWR2ZXJ0aXNlZCB1c2luZyBJR1AgZmxvb2RpbmcuICBUaGUgSUdQDQogICBl eHRlbnNpb25zIGZvciBQQ0UgZGlzY292ZXJ5IChSRkMgNTA4OCBhbmQgUkZDIDUwODkpIGRlZmlu ZSBhIG1ldGhvZA0KICAgdG8gYWR2ZXJ0aXNlIHBhdGggY29tcHV0YXRpb24gY2FwYWJpbGl0aWVz IHVzaW5nIElHUCBmbG9vZGluZyBmb3INCiAgIE9TUEYgYW5kIElTLUlTIHJlc3BlY3RpdmVseS4g IEhvd2V2ZXIgdGhlc2Ugc3BlY2lmaWNhdGlvbnMgbGFjayBhDQogICBtZXRob2QgdG8gYWR2ZXJ0 aXNlIFBDRVAgc2VjdXJpdHkgKGUuZy4sIFRyYW5zcG9ydCBMYXllcg0KICAgU2VjdXJpdHkoVExT KSkgc3VwcG9ydCBjYXBhYmlsaXR5Lg0KDQogICBUaGlzIGRvY3VtZW50IHByb3Bvc2VzIG5ldyBj YXBhYmlsaXR5IGZsYWcgYml0IGZvciBQQ0UtQ0FQLUZMQUdTIHN1Yi0NCiAgIFRMViB0aGF0IGNh biBiZSBhbm5vdW5jZWQgYXMgYXR0cmlidXRlIGluIHRoZSBJR1AgYWR2ZXJ0aXNlbWVudCB0bw0K ICAgZGlzdHJpYnV0ZSBQQ0VQIHNlY3VyaXR5IHN1cHBvcnQgaW5mb3JtYXRpb24uDQoNCg0KVGhl IElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQpodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13dS1wY2UtZGlzY292ZXJ5LXBjZXBzLXN1 cHBvcnQvDQoNClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0K aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd3UtcGNlLWRpc2NvdmVyeS1wY2Vwcy1z dXBwb3J0LTAxDQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJs ZSBhdDoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXd1LXBjZS1kaXNj b3ZlcnktcGNlcHMtc3VwcG9ydC0wMQ0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9y Zy4NCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQ IGF0Og0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5vdW5jZSBtYWlsaW5n IGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRw Oi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sIG9yIGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFz aGFkb3ctc2l0ZXMudHh0DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KUGNlIG1haWxpbmcgbGlzdA0KUGNlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjZQ0K From nobody Fri Aug 29 07:48:14 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2B11A0458 for ; Fri, 29 Aug 2014 07:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZmB4kioW-Ws for ; Fri, 29 Aug 2014 07:48:10 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ADF31A0444 for ; Fri, 29 Aug 2014 07:48:10 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-68-54003dc82cab Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 66.9C.05330.8CD30045; Fri, 29 Aug 2014 10:46:01 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Fri, 29 Aug 2014 10:48:07 -0400 From: Uma Chunduri To: Qin Wu , "pce@ietf.org" Thread-Topic: I-D Action: draft-wu-pce-discovery-pceps-support-01.txt Thread-Index: AQHPt34VeZpZpUDEXk+lwdwtWfp7gZvkTWGggANFqOCAAA1fsIAAHSNA Date: Fri, 29 Aug 2014 14:48:07 +0000 Message-ID: <1B502206DFA0C544B7A60469152008633F3693C8@eusaamb105.ericsson.se> References: <1B502206DFA0C544B7A60469152008633F36931A@eusaamb105.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyuXRPrO5JW4YQgxnnBC0ez13AatF0/wa7 A5NHy5G3rB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4cOQtc8Fe7ormA51MDYzTObsYOTkkBEwk GufdYIOwxSQu3FsPZHNxCAkcZZSYf+I9M4SznFFizbGzzCBVbAJ6Eh+n/mQHsUUE7CQW7Z/F CGILC7hI7FiwiQki7iqxa9oxFgjbTaJv70ywXhYBVYkz61eC9fIK+ErM/9zMCLHgKaPEqsOt YA2cAmESq2dvAbMZgU76fmoN2FBmAXGJW0/mM0GcKiCxZM95ZghbVOLl43+sELaSxKSl51gh 6nUkFuz+xAZha0ssW/iaGWKxoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKkaO0OLUsN93I YBMjMCKOSbDp7mDc89LyEKMAB6MSD2/Csv/BQqyJZcWVuYcYpTlYlMR5Z9XOCxYSSE8sSc1O TS1ILYovKs1JLT7EyMTBKQWMiL3JD3l1Hj5jvrbMcYumu0/O4q0P5zw7YS+Z9PV1yaYO9z2p US5iFfkHZ4WEHftrc188cufc3BtXnzsqPVli+DbKNOCLUN8998PqW4zd8rd3TKnOlZSd096m uTTnzXnpifWHtrCvPHBOnm2ZZaSf4/K7S6173fUYROLn+52J05tpvDyhdyOnEktxRqKhFnNR cSIA3lbM62kCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/pce/hy0ekvL79YZ7egieoQ2Z0Ry4lDY Subject: Re: [Pce] I-D Action: draft-wu-pce-discovery-pceps-support-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 14:48:12 -0000 Hi Qin, In-line=20 =3D=3D=3D >>IMO, keeping separate is good as scope is different in both. >>I and Diego had chat offline on this but how this discovery is beneficia= l as you still operator >>have to configure AUTH/Security credentials on the nodes. >[Qin]: I think the importance of this discovery is in the deployments= which allow multiple > choices for security credentials. without such discovery, it leads= to unexpected failure or=20 >additional message exchange is needed to indicate error to PCC using = PCErr message. I can't really imagine nodes will have multiple security credential provisi= oned by operator across all PCCs around for different protocols; for e.g.,= TLS itself "can" be heavy in terms of auth-config. However, I see one good possibility of no credentials with both AO and TLS= and then the mechanisms described in draft-wu-pce-discovery-pceps-support= -01.txt can be useful. We have one unfinished work in KARP http://tools.ietf.org/html/draft-chundu= ri-karp-kmp-router-fingerprints-05 where we precisely address this with fin= ger prints based authentication for TCP-AO/KMP and these procedures can be extendable and applicable to TLS eas= ily for PCEP (as MD is theoretically obsolete!), discussed offline few mont= hs ago. Auto discovery mechanisms eventually will be really helpful only when we ha= ve these mechanisms in place perhaps. -- Uma C. From nobody Fri Aug 29 17:56:32 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2991A802A for ; Fri, 29 Aug 2014 17:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.48 X-Spam-Level: X-Spam-Status: No, score=-1.48 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, J_CHICKENPOX_22=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5erCj8KHd72Z for ; Fri, 29 Aug 2014 17:56:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F5771A8028 for ; Fri, 29 Aug 2014 17:56:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLX73993; Sat, 30 Aug 2014 00:56:27 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 30 Aug 2014 01:56:25 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.209]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Sat, 30 Aug 2014 08:56:18 +0800 From: Qin Wu To: Uma Chunduri , "pce@ietf.org" Thread-Topic: I-D Action: draft-wu-pce-discovery-pceps-support-01.txt Thread-Index: AQHPt34VeZpZpUDEXk+lwdwtWfp7gZvkTWGggANFqOCAAA1fsIAAHSNAgACpGzA= Date: Sat, 30 Aug 2014 00:56:17 +0000 Message-ID: References: <1B502206DFA0C544B7A60469152008633F36931A@eusaamb105.ericsson.se> <1B502206DFA0C544B7A60469152008633F3693C8@eusaamb105.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A60469152008633F3693C8@eusaamb105.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pce/TbmVfBz1IUwINjn8W0Li3QL12fY Subject: Re: [Pce] I-D Action: draft-wu-pce-discovery-pceps-support-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2014 00:56:31 -0000 LS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IFVtYSBDaHVuZHVyaSBbbWFpbHRvOnVtYS5jaHVu ZHVyaUBlcmljc3Nvbi5jb21dIA0Kt6LLzcqxvOQ6IDIwMTTE6jjUwjI5yNUgMjI6NDgNCsrVvP7I yzogUWluIFd1OyBwY2VAaWV0Zi5vcmcNCtb3zOI6IFJFOiBJLUQgQWN0aW9uOiBkcmFmdC13dS1w Y2UtZGlzY292ZXJ5LXBjZXBzLXN1cHBvcnQtMDEudHh0DQoNCkhpIFFpbiwNCkluLWxpbmUgDQoN Cj09PQ0KDQoJPj5JTU8sIGtlZXBpbmcgc2VwYXJhdGUgaXMgZ29vZCBhcyBzY29wZSBpcyBkaWZm ZXJlbnQgaW4gYm90aC4NCgk+PkkgYW5kIERpZWdvIGhhZCBjaGF0IG9mZmxpbmUgb24gdGhpcyBi dXQgaG93IHRoaXMgZGlzY292ZXJ5IGlzIGJlbmVmaWNpYWwgYXMgeW91IHN0aWxsIG9wZXJhdG9y DQogICAgICAgICAgICAgID4+aGF2ZSB0byBjb25maWd1cmUgQVVUSC9TZWN1cml0eSBjcmVkZW50 aWFscyBvbiB0aGUgbm9kZXMuDQoNCiAgICAgPltRaW5dOiBJIHRoaW5rIHRoZSBpbXBvcnRhbmNl IG9mIHRoaXMgZGlzY292ZXJ5IGlzIGluIHRoZSBkZXBsb3ltZW50cyB3aGljaCBhbGxvdyBtdWx0 aXBsZQ0KICAgICA+IGNob2ljZXMgZm9yIHNlY3VyaXR5IGNyZWRlbnRpYWxzLiAgIHdpdGhvdXQg c3VjaCBkaXNjb3ZlcnksIGl0IGxlYWRzIHRvIHVuZXhwZWN0ZWQgZmFpbHVyZSBvciANCiAgICAg PmFkZGl0aW9uYWwgbWVzc2FnZSBleGNoYW5nZSBpcyBuZWVkZWQgdG8gaW5kaWNhdGUgZXJyb3Ig dG8gUENDIHVzaW5nIFBDRXJyIG1lc3NhZ2UuDQoNCkkgY2FuJ3QgcmVhbGx5IGltYWdpbmUgbm9k ZXMgd2lsbCBoYXZlIG11bHRpcGxlIHNlY3VyaXR5IGNyZWRlbnRpYWwgcHJvdmlzaW9uZWQgYnkg b3BlcmF0b3IgYWNyb3NzIGFsbCBQQ0NzIGFyb3VuZCBmb3IgZGlmZmVyZW50IHByb3RvY29sczsg IGZvciBlLmcuLCBUTFMgaXRzZWxmICJjYW4iIGJlIGhlYXZ5IGluIHRlcm1zIG9mIGF1dGgtY29u ZmlnLg0KDQpbUWluXTogd2hhdCBJIGFtIHNheWluZyBpcyBpbiBzb21lIGNhc2VzIFBDRSBzZXJ2 ZXIgbWF5IHN1cHBvcnQgbXVsdGkgc2VjdXJpdHkgbWVjaGFuaXNtcywgZS5nLiwgTUQsQU8sIFRM UywgYW5kIFBDQyB3YW50IHRvIGRpc2NvdmVyIFBDRSB3aXRoIGVhY2ggc2VjdXJpdHkgbWVjaGFu aXNtIG9yIGNvbWJpbmF0aW9uIG9mIGFueSB0d28gc2VjdXJpdHkgbWVjaGFuaXNtcy4NCg0KSG93 ZXZlciwgSSBzZWUgb25lIGdvb2QgcG9zc2liaWxpdHkgb2YgIG5vIGNyZWRlbnRpYWxzIHdpdGgg Ym90aCBBTyBhbmQgVExTIGFuZCB0aGVuICB0aGUgbWVjaGFuaXNtcyBkZXNjcmliZWQgaW4gZHJh ZnQtd3UtcGNlLWRpc2NvdmVyeS1wY2Vwcy1zdXBwb3J0LTAxLnR4dCBjYW4gYmUgdXNlZnVsLg0K DQpbUWluXTogRXhhY3RseS4NCg0KV2UgaGF2ZSBvbmUgdW5maW5pc2hlZCB3b3JrIGluIEtBUlAg aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2h1bmR1cmkta2FycC1rbXAtcm91dGVy LWZpbmdlcnByaW50cy0wNSB3aGVyZSB3ZSBwcmVjaXNlbHkgYWRkcmVzcyB0aGlzIHdpdGggZmlu Z2VyIHByaW50cyBiYXNlZCBhdXRoZW50aWNhdGlvbiBmb3IgVENQLUFPL0tNUCBhbmQgdGhlc2Ug cHJvY2VkdXJlcyBjYW4gYmUgZXh0ZW5kYWJsZSBhbmQgYXBwbGljYWJsZSB0byBUTFMgZWFzaWx5 IGZvciBQQ0VQIChhcyBNRCBpcyB0aGVvcmV0aWNhbGx5IG9ic29sZXRlISksIGRpc2N1c3NlZCBv ZmZsaW5lIGZldyBtb250aHMgYWdvLg0KQXV0byBkaXNjb3ZlcnkgbWVjaGFuaXNtcyBldmVudHVh bGx5IHdpbGwgYmUgcmVhbGx5IGhlbHBmdWwgb25seSB3aGVuIHdlIGhhdmUgdGhlc2UgbWVjaGFu aXNtcyBpbiBwbGFjZSBwZXJoYXBzLg0KDQpbUWluXTogSW50ZXJlc3RpbmcuIFRoYW5rcyBmb3Ig dmFsdWFibGUgaW5mb3JtYXRpb24uIA0KDQotLQ0KVW1hIEMuDQoNCg==