From julien.meuric@orange-ftgroup.com Fri Jun 4 03:01:52 2010 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1D3028C0DB for ; Fri, 4 Jun 2010 03:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.649 X-Spam-Level: X-Spam-Status: No, score=-4.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_INVITATION=-2, GB_I_LETTER=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyY8HEPj7-2C for ; Fri, 4 Jun 2010 03:01:51 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id AFF1028C0F4 for ; Fri, 4 Jun 2010 03:01:50 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B8C538B801F for ; Fri, 4 Jun 2010 12:01:02 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 068F48B8028 for ; Fri, 4 Jun 2010 12:00:16 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Jun 2010 11:59:59 +0200 Received: from [10.193.71.77] ([10.193.71.77]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Jun 2010 11:59:58 +0200 Message-ID: <4C08CE9E.8020108@orange-ftgroup.com> Date: Fri, 04 Jun 2010 11:59:58 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: pce@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 04 Jun 2010 09:59:58.0887 (UTC) FILETIME=[B10DBB70:01CB03CC] Subject: [Pce] Fwd: IETF 78 - Meeting and Sponsorship Information X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 10:01:52 -0000 FYI ========================================== 78th IETF Meeting Maastricht, Netherlands July 25-30, 2010 1. Sponsorship Opportunities 2. Registration Types 3. Visas and Letters of Invitation 4. Accommodations& Breakfast Information 5. IETF 79 (Beijing) Visa Information 1) Sponsorship Opportunities There are still sponsorship opportunities and benefits for high profile company/organizational exposure at the upcoming IETF meeting in Maastricht, Netherlands from July 25-30, 2010. All sponsorship fees go directly to fund the operations of the IETF. See the options at: http://www.ietf.org/meeting/78/index.html “Sponsorship Opportunities” under “General”. Each of the sponsorship options provide extended and repeat exposure at this weeklong meeting. Please contact Drew Dvorshak, dvorshak@isoc.org, with any questions and/or to reserve your organizationÂ’s spot. Thanks in advance for supporting the critical work of the IETF! 2) Register online at: http://www.ietf.org/meetings/78/ 3) Letters of Invitation and Visas Letters of Invitation After you complete the meeting registration process, you will be given the option to request a letter of invitation. You can request the Letter of Invitation as soon as you finish registration, or at a later time by following the link provided in the confirmation email. Visas Please check the Netherlands Ministry of Foreign Affairs site (http://www.minbuza.nl/en/Services/Consular_Services/Visa) for list of countries with visa exemptions. We recommend you give yourself at least one month to complete the visa process. 4) Accommodations& Breakfast Information http://www.ietf.org/meeting/78/hotel.html 5) If you want to start planning for your trip to IETF 79 in Beijing, we have visa information online here: http://www.ietf.org/meeting/79/visa.html Only 52 days until IETF 78! From ogondio@tid.es Fri Jun 4 03:57:52 2010 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 163EB3A6992 for ; Fri, 4 Jun 2010 03:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.455 X-Spam-Level: X-Spam-Status: No, score=0.455 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_50=0.001, FRT_BELOW2=2.154, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2MlZs63MTSx for ; Fri, 4 Jun 2010 03:57:51 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by core3.amsl.com (Postfix) with ESMTP id 9995C3A6889 for ; Fri, 4 Jun 2010 03:57:50 -0700 (PDT) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0L3H00GOGL3ZHH@tid.hi.inet> for pce@ietf.org; Fri, 04 Jun 2010 12:57:35 +0200 (MEST) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad2.hi.inet ([192.168.0.2]) with mapi; Fri, 04 Jun 2010 12:57:35 +0200 Date: Fri, 04 Jun 2010 12:57:31 +0200 From: =?iso-8859-1?Q?Oscar_Gonz=E1lez_de_Dios?= In-reply-to: <91E2B308E7EC4C05945E57BF42A60D83@your029b8cecfe> To: Adrian Farrel Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: es-ES Content-transfer-encoding: quoted-printable Accept-Language: es-ES, en-US Thread-topic: [Pce] question about draft-king-pce-hierarchy-fwk-03 Thread-index: Acr9ka6Kp1283tDLTCKwqKufdow/IQAKVVNQ acceptlanguage: es-ES, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <91E2B308E7EC4C05945E57BF42A60D83@your029b8cecfe> Cc: "pce@ietf.org" Subject: Re: [Pce] question about draft-king-pce-hierarchy-fwk-03 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 10:57:52 -0000 Hi Adrian, Lots of thanks for the very complete response. Further comments inline. At = the end, I continue with more sections of the document. >-----Mensaje original----- >De: Adrian Farrel [mailto:adrian@olddog.co.uk] >Enviado el: jueves, 27 de mayo de 2010 13:42 >Para: Oscar Gonz=E1lez de Dios >CC: pce@ietf.org >Asunto: Re: [Pce] question about draft-king-pce-hierarchy-fwk-03 > >Hello Oscar, > >Thanks for reading. > >> I have a few comments about draft-king-pce-hierarchy-fwk-03. It this >> draft, >> it is specified in section 3.1 the applicability of BRPC when the >Domain >> Path >> is Not Known. Bellow are my comments with regards to the text in the >> draft: >> >> - "When the ingress PCE has received a VSPT from each of its >neighboring >> domains it is able to select the optimum path": Comment #1: Some of >the >> neighboring domains may not send a VSPT (they may not be connected >> to any other domain, or just cannot reach the domain of the >destination >> LSP). Thus, the ingress PCE should not expect an answer from each >of >> the neighboring domain, but only from some. In that case, should >there >> be a timer set when the first answer (VSPT) arrives, and when >either >> the >> timer is over or all the neighboring domains have answered, then >select >> the path? > >Good catch. >Yes, we only described the positive case. We should add two other cases: >1. The PCE in the neighboring domain cannot find a path to the egress > (for whatever reason) and returns an error for the PCReq. >2. The PCE in the neighboring domain fails to respond (a timeout pops). > >We should add a sentnce to cover this. OK!=20 Then note that the same cases apply to the hierarchical PCE approach in sec= tion 4, so they should be added there equally. =20 "When a multi-domain path is needed, the ingress PCE sends a request to the= parent PCE (using the path computation element protocol)" Comment#1: If the child PCE cannot find a path to the egress and returns an= d error (or it does not respond and the timeout pops)... then, the parent P= CE should try again with a different sequence of domains? Or should it just= leave it open, and let the implementation of the parent PCE decide what to= do, if either return a error to the PCC that initiated the request or try = again. Comment#2 The child PCE of some domain could not respond (maybe it's down, = or overflowed, or whatever). This leads to a question... RFC4655 in section= 6.5. refers to Detecting PCE Liveness. Must it be stated that PCE child t= o PCE parent communications should implement mechanisms to detect the PCE l= iveleness as stated in RFC 4655? > >> - "Each PCE in turn constructs a VSPT and passes it on to all of its >> neighboring PCEs". >> Comment #2: Clearly, the set of domains that are already part of the >> VSPT should be excluded when passing the VSPT. > >Well, indeed. >There are two ways of excluding. >1. If a PCE knows the domain is already in the path, it does not send > a VPST to a neighboring PCE for that domain. >2. If a PCE receives a VPST and finds its own domain already in the > path it can exclude the received VPST. > >Although the first of these looks cleaner, the second works better in >cases >where one (neighbor) PCE may act for multiple domains. > >I think we need to explore this a little. > OK! >> Comment #3: A intermediate PCE could receive VPSTs from >> different domains. What should it do then? Complete all the VPST >> it receives and send them? Send just the first? And in case the PCE >> send multiple VSPTS (each would be a different sequence of >> domains), then the ingress PCE should receive all of them before >> selecting the optimum path. In such case, the timer mechanism >> could fit.... > >Yes. I think you are exposing some of the big issues with using BRPC in >this >way. The more "meshy" the network of domains, the harder it is to run >this >process. Comments 2 and 3 show up problems of impracticallity. > >A timer could certainly be used to address this issue. Each PCE, in >turn, >would run such a timer meaning that the PCEs that have more PCEs down >stream >need to run longer timers. This gets quite messy because a PCE might >have >two domain paths to the egress domain. If one path has a small number of >domains, the PCE will receive the VPST a long time before it receives >the >second. How does it know how long to wait? > Good question.... >We should try to add some discussion of this, but I note that we are not >(in >section 3.1) trying to show that BRPC can be used in any arbitrary >domain >mesh when the domain path is not known. In fact, we are trying to >explain >why it may be very inappropriate. > True... Comment#3 The Hierarchical PCE is a better approach (although you n= eed another PCE to rule them all). In case of multiple domains belonging to= the same operator (I am thinking in a GMPLS network subdivided in several = administrative domains with different vendors, or the different domains of = its MPLS network), the Hierarchical PCE approach makes sense. However, for = bigger number of domains... But as you say in the draft, the aim is at solv= ing the problem in reasonable sized number of domains. >> - "The ingress PCE sends the path computation request direct to the >PCE >> responsible for the domain containing the destination node (the >egress >> PCE)". >> Comment #4: Do you assume that the PCEs knows how to reach all the >> other PCEs? I assume that, at least a PCE must know how to reach its >> neighboring PCEs. If the PCE only knows that information, the >request >> should be flooded until it reaches the egress PCE. > >When you say "know how to reach" I presume you mean "know the identity >and >address of". YES > >And, yes, this is exactly one of the problems. In small domain meshes, >this >is not unreasonable, but some mechnism (config or flooding) would be >needed. >In large domain meshes, this would be less reasonable. > >You highlight yet another reason why BRPC would not be so appropriate. > >It is clear to me that we need to expand on the final paragraph of 3.1 >that >currently says: > > Clearly this mechanism (which could be called path computation > flooding) has significant scaling issues. It could be improved by > the application of policy and filtering, but such mechanisms are not > simple and would still leave scaling concerns. > >It seems to me that we should also add a section on "Forward Recursive >Path >Computation" in this case. This form of "flooding" VPSTs helps >"discover" >the destination domain since each PCE only needs to know its neighbors, >but >pruning the VPST during the process is harder, so there is more >overhead. > OK! >Anyway, as I say, the purpose of section 3 is to highlight that BRPC is >not >a viable solution in the case where the domain path is unknown and the >domains are arranged in a mesh. > >Cheers, >Adrian Finally a few comments about the relation with ASON. In chapter 6.2, you ta= lk about the ASON Architecture. You mention that the Routing Controller is = synonymous with a PCE. In 6.2.1 you mention that PCE can be seen as a reali= zation of a RC. So.... just to clarify, you mean the second, that if you wa= nt to implement a RC, use the Hierarchical PCE and its associated protocols= (PCEP)?=20 Regarding this relation with ASON, the OIF standardized in 2007 the OIF-ENN= I-OSPF-01.0 interface. So, in analogy to the RC-PCE, can it be mentioned th= at some sort of OSPF extension will be a realization of the E-NNI 1.0 and c= an be used to fill in the TEDs that the Hierarchical PCE would use?=20 You mention something in the draft about how to fill in the TEDs (in sectio= n 5.4 there is something),but I guess this is far from the scope of the doc= ument...=20 Best Regards, =D3scar From daniel@olddog.co.uk Mon Jun 7 09:04:54 2010 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AF1728C7DA for ; Mon, 7 Jun 2010 09:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.558 X-Spam-Level: **** X-Spam-Status: No, score=4.558 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, FRT_BELOW2=2.154, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0uqgDv3ndzW for ; Mon, 7 Jun 2010 09:04:53 -0700 (PDT) Received: from asmtp3.iomartmail.com (unknown [62.128.193.159]) by core3.amsl.com (Postfix) with ESMTP id 467243A7D5F for ; Mon, 7 Jun 2010 05:48:19 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id o57Cm2H4017407; Mon, 7 Jun 2010 13:48:07 +0100 Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id o57Clwr9017390; Mon, 7 Jun 2010 13:47:59 +0100 From: "Daniel King" To: "=?iso-8859-1?Q?'Oscar_Gonz=E1lez_de_Dios'?=" References: <91E2B308E7EC4C05945E57BF42A60D83@your029b8cecfe> In-Reply-To: Date: Mon, 7 Jun 2010 13:48:01 +0100 Message-ID: <002001cb063f$aad2d040$007870c0$@co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr9ka6Kp1283tDLTCKwqKufdow/IQAKVVNQAYbSjpA= Content-Language: en-gb Cc: pce@ietf.org Subject: Re: [Pce] question about draft-king-pce-hierarchy-fwk-03 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 16:04:54 -0000 Hi Oscar,=20 Thanks for review and comments. I have provided some additional thoughts in-line.=20 -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of = Oscar Gonz=E1lez de Dios Sent: 04 June 2010 11:58 To: Adrian Farrel Cc: pce@ietf.org Subject: Re: [Pce] question about draft-king-pce-hierarchy-fwk-03 Hi Adrian, Lots of thanks for the very complete response. Further comments inline. = At the end, I continue with more sections of the document. >-----Mensaje original----- >De: Adrian Farrel [mailto:adrian@olddog.co.uk] >Enviado el: jueves, 27 de mayo de 2010 13:42 >Para: Oscar Gonz=E1lez de Dios >CC: pce@ietf.org >Asunto: Re: [Pce] question about draft-king-pce-hierarchy-fwk-03 > >Hello Oscar, > >Thanks for reading. > >> I have a few comments about draft-king-pce-hierarchy-fwk-03. It this >> draft, >> it is specified in section 3.1 the applicability of BRPC when the >Domain >> Path >> is Not Known. Bellow are my comments with regards to the text in the >> draft: >> >> - "When the ingress PCE has received a VSPT from each of its >neighboring >> domains it is able to select the optimum path": Comment #1: Some = of >the >> neighboring domains may not send a VSPT (they may not be connected >> to any other domain, or just cannot reach the domain of the >destination >> LSP). Thus, the ingress PCE should not expect an answer from each >of >> the neighboring domain, but only from some. In that case, should >there >> be a timer set when the first answer (VSPT) arrives, and when >either >> the >> timer is over or all the neighboring domains have answered, then >select >> the path? > >Good catch. >Yes, we only described the positive case. We should add two other = cases: >1. The PCE in the neighboring domain cannot find a path to the egress > (for whatever reason) and returns an error for the PCReq. >2. The PCE in the neighboring domain fails to respond (a timeout pops). > >We should add a sentnce to cover this. DK>> Indeed. I have prepared two new scenarios and text to cover these = cases in the next version of our draft.=20 OK!=20 Then note that the same cases apply to the hierarchical PCE approach in section 4, so they should be added there equally. =20 "When a multi-domain path is needed, the ingress PCE sends a request to = the parent PCE (using the path computation element protocol)" Comment#1: If the child PCE cannot find a path to the egress and returns = and error (or it does not respond and the timeout pops)... then, the parent = PCE should try again with a different sequence of domains? Or should it just leave it open, and let the implementation of the parent PCE decide what = to do, if either return a error to the PCC that initiated the request or = try again. DK>> It's possible that multiple child PCE's exist within a domain so = the parent PCE could: 1. Send a request to the child PCE 1 in (Domain 1) and then if no route = is found by that PCE or no response is received for a path1, then the = Parent PCE can send the same path request to another PCE say child PCE2 (Domain = 1). Bear in mind that the second request would be based on the error type received back from PCE1, if PCE1 says there is no path available (versus = I cannot find a path) then the parent PCE should not send a second = request, but should send a request to a child PCE in a different transit domain.=20 2. Send two requests to simultaneously to PCE1 and PCE2 in (Domain 1).=20 =20 Actually these type of scenarios and specific procedures could be = covered in our draft.=20 Comment#2 The child PCE of some domain could not respond (maybe it's = down, or overflowed, or whatever). This leads to a question... RFC4655 in = section 6.5. refers to Detecting PCE Liveness. Must it be stated that PCE child = to PCE parent communications should implement mechanisms to detect the PCE liveleness as stated in RFC 4655? DK>> Again, we could use a mechanism that polls another child pce or = chooses a new transit domain. I do think we need to expand on Liveness Detection = and Monitoring, as well as Verifying Correct Operation in more detail on our draft. > >> - "Each PCE in turn constructs a VSPT and passes it on to all of its >> neighboring PCEs". >> Comment #2: Clearly, the set of domains that are already part of = the >> VSPT should be excluded when passing the VSPT. > >Well, indeed. >There are two ways of excluding. >1. If a PCE knows the domain is already in the path, it does not send > a VPST to a neighboring PCE for that domain. >2. If a PCE receives a VPST and finds its own domain already in the > path it can exclude the received VPST. > >Although the first of these looks cleaner, the second works better in >cases >where one (neighbor) PCE may act for multiple domains. > >I think we need to explore this a little. > OK! >> Comment #3: A intermediate PCE could receive VPSTs from >> different domains. What should it do then? Complete all the VPST >> it receives and send them? Send just the first? And in case the PCE >> send multiple VSPTS (each would be a different sequence of >> domains), then the ingress PCE should receive all of them before >> selecting the optimum path. In such case, the timer mechanism >> could fit.... > >Yes. I think you are exposing some of the big issues with using BRPC in >this >way. The more "meshy" the network of domains, the harder it is to run >this >process. Comments 2 and 3 show up problems of impracticallity. > >A timer could certainly be used to address this issue. Each PCE, in >turn, >would run such a timer meaning that the PCEs that have more PCEs down >stream >need to run longer timers. This gets quite messy because a PCE might >have >two domain paths to the egress domain. If one path has a small number = of >domains, the PCE will receive the VPST a long time before it receives >the >second. How does it know how long to wait? > Good question.... >We should try to add some discussion of this, but I note that we are = not >(in >section 3.1) trying to show that BRPC can be used in any arbitrary >domain >mesh when the domain path is not known. In fact, we are trying to >explain >why it may be very inappropriate. > True... Comment#3 The Hierarchical PCE is a better approach (although = you need another PCE to rule them all). In case of multiple domains = belonging to the same operator (I am thinking in a GMPLS network subdivided in = several administrative domains with different vendors, or the different domains = of its MPLS network), the Hierarchical PCE approach makes sense. However, = for bigger number of domains... But as you say in the draft, the aim is at solving the problem in reasonable sized number of domains. DK>> Indeed. The current charter specifically prohibits expending effort = on "large" groups of domains. The definition of "large" is open to interpretation, and various discussions on this list have occurred over = the years on this specific topic. Applicability of H-PCE and the number of domains it services may also depend on the size of the domains. In the optical world, a single ring of a specific technology type or vendor, = may be a domain in itself.=20 >> - "The ingress PCE sends the path computation request direct to the >PCE >> responsible for the domain containing the destination node (the >egress >> PCE)". >> Comment #4: Do you assume that the PCEs knows how to reach all the >> other PCEs? I assume that, at least a PCE must know how to reach = its >> neighboring PCEs. If the PCE only knows that information, the >request >> should be flooded until it reaches the egress PCE. > >When you say "know how to reach" I presume you mean "know the identity >and >address of". YES > >And, yes, this is exactly one of the problems. In small domain meshes, >this >is not unreasonable, but some mechnism (config or flooding) would be >needed. >In large domain meshes, this would be less reasonable. >You highlight yet another reason why BRPC would not be so appropriate. > >It is clear to me that we need to expand on the final paragraph of 3.1 >that >currently says: > > Clearly this mechanism (which could be called path computation > flooding) has significant scaling issues. It could be improved by > the application of policy and filtering, but such mechanisms are not > simple and would still leave scaling concerns. DK>> Indeed. We have tried to avoid mechanisms that use flooding = techniques. > >It seems to me that we should also add a section on "Forward Recursive >Path >Computation" in this case. This form of "flooding" VPSTs helps >"discover" >the destination domain since each PCE only needs to know its neighbors, >but >pruning the VPST during the process is harder, so there is more >overhead. > OK! DK>> Ah FRPC, indeed other techniques may also be applied including Dual Recursive Path Computation. With DRPC the H-PCE could send out multiple requests in either direction across the multi-domain topology and stitch together responses and prune where necessary. Although you need to = consider where the middle is, rather hard in a cloud :-)=20 >Anyway, as I say, the purpose of section 3 is to highlight that BRPC is >not >a viable solution in the case where the domain path is unknown and the >domains are arranged in a mesh. > >Cheers, >Adrian Finally a few comments about the relation with ASON. In chapter 6.2, you talk about the ASON Architecture. You mention that the Routing = Controller is synonymous with a PCE. In 6.2.1 you mention that PCE can be seen as a realization of a RC. So.... just to clarify, you mean the second, that = if you want to implement a RC, use the Hierarchical PCE and its associated protocols (PCEP)?=20 DK>> Yes. [G-8080] describes that the Routing Controller Component is an abstract entity (in our case a PCE), which is responsible for responding = to requests for path (route) information and topology information. = [G-7715-2] describes the Route Query Requester as an RC that sends a route query message to one or more RCs to compute paths that satisfies a set of = routing constraints. In this context the Parent PCE (Parent RC) and Child PCEs (Child RCs) could communicate using PCEP and this would translate to = route query (RI_QUERY / PCEP Request) and route query response (RI_UPDATE / = PCEP Response) messages as per [G-7715-2].=20 Regarding this relation with ASON, the OIF standardized in 2007 the OIF-ENNI-OSPF-01.0 interface. So, in analogy to the RC-PCE, can it be mentioned that some sort of OSPF extension will be a realization of the E-NNI 1.0 and can be used to fill in the TEDs that the Hierarchical PCE would use? You mention something in the draft about how to fill in the TEDs (in = section 5.4 there is something),but I guess this is far from the scope of the document...=20 DK>> Very true, the TED could be comprised of information retrieved from = an NMS system or as you mentioned OSPF-TE, or indeed something else = entirely and various work has already been started in this area (see draft-lee-pce-ted-alternatives). Also bear in mind that to maintain confidentiality and scaling we may not want to provide the Parent RC the full Child RC database. =20 Best Regards, =D3scar _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From root@core3.amsl.com Mon Jun 7 15:30:46 2010 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3A9B13A6837; Mon, 7 Jun 2010 15:30:27 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100607223044.3A9B13A6837@core3.amsl.com> Date: Mon, 7 Jun 2010 15:30:28 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-pcep-svec-list-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 22:30:46 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : The use of SVEC (Synchronization VECtor) list for Synchronized dependent path computations Author(s) : I. Nishioka, D. King Filename : draft-ietf-pce-pcep-svec-list-05.txt Pages : 17 Date : 2010-6-7 A Path Computation Element (PCE) may be required to perform dependent path computations. Dependent path computations are requests that need to be synchronized in order to meet specific objectives. An example of a dependent request would be a PCE computing a set of services which are required to be diverse (disjointed) from each other. When a PCE computes sets of dependent path computation requests concurrently, it is required to use the Synchronization VECtor (SVEC) list for association among the sets of dependent path computation requests. The SVEC object is optional and carried within the Path Computation Element Protocol (PCEP) PCRequest (PCReq) message. This document does not specify the PCEP SVEC object or procedure. This informational document clarifies the use of the SVEC list for synchronized path computations when computing dependent requests. The document also describes a number of usage scenarios for SVEC lists within single domain and multi-domain environments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-svec-list-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-pcep-svec-list-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-6-7152139.I-D@ietf.org> --NextPart-- From daniel@olddog.co.uk Tue Jun 8 01:40:25 2010 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5427528C120 for ; Tue, 8 Jun 2010 01:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.979 X-Spam-Level: X-Spam-Status: No, score=0.979 tagged_above=-999 required=5 tests=[AWL=3.579, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EdQitvsIMGR for ; Tue, 8 Jun 2010 01:40:24 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id E64DE28C107 for ; Tue, 8 Jun 2010 01:40:22 -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 o588e4RI011431 for ; Tue, 8 Jun 2010 09:40:09 +0100 Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id o588e2ZO011411 for ; Tue, 8 Jun 2010 09:40:03 +0100 From: "Daniel King" To: References: <20100607223044.3A9B13A6837@core3.amsl.com> In-Reply-To: <20100607223044.3A9B13A6837@core3.amsl.com> Date: Tue, 8 Jun 2010 09:40:05 +0100 Message-ID: <000601cb06e6$324ca680$96e5f380$@co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcsGkfAxw2Sf0U0kQE2vTxVsNDtCFwAU8AFw Content-Language: en-gb Subject: Re: [Pce] I-D ACTION:draft-ietf-pce-pcep-svec-list-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 08:40:25 -0000 Hi All, This new version resolves a single Discuss from Tim Polk regarding the construction of associated SVECs. Br, Dan. -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: 07 June 2010 23:30 To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: I-D ACTION:draft-ietf-pce-pcep-svec-list-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : The use of SVEC (Synchronization VECtor) list for Synchronized dependent path computations Author(s) : I. Nishioka, D. King Filename : draft-ietf-pce-pcep-svec-list-05.txt Pages : 17 Date : 2010-6-7 A Path Computation Element (PCE) may be required to perform dependent path computations. Dependent path computations are requests that need to be synchronized in order to meet specific objectives. An example of a dependent request would be a PCE computing a set of services which are required to be diverse (disjointed) from each other. When a PCE computes sets of dependent path computation requests concurrently, it is required to use the Synchronization VECtor (SVEC) list for association among the sets of dependent path computation requests. The SVEC object is optional and carried within the Path Computation Element Protocol (PCEP) PCRequest (PCReq) message. This document does not specify the PCEP SVEC object or procedure. This informational document clarifies the use of the SVEC list for synchronized path computations when computing dependent requests. The document also describes a number of usage scenarios for SVEC lists within single domain and multi-domain environments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-svec-list-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From wwwrun@rfc-editor.org Tue Jun 8 11:37:25 2010 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 493293A67C1; Tue, 8 Jun 2010 11:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.375 X-Spam-Level: X-Spam-Status: No, score=0.375 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_50=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ji4zHGSwv0O; Tue, 8 Jun 2010 11:37:24 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 7CE7E3A6784; Tue, 8 Jun 2010 11:37:24 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 20F88E068A; Tue, 8 Jun 2010 11:37:26 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100608183726.20F88E068A@rfc-editor.org> Date: Tue, 8 Jun 2010 11:37:26 -0700 (PDT) Cc: pce@ietf.org, rfc-editor@rfc-editor.org Subject: [Pce] RFC 5862 on Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 18:37:25 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5862 Title: Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE Author: S. Yasukawa, A. Farrel Status: Informational Stream: IETF Date: June 2010 Mailbox: yasukawa.seisho@lab.ntt.co.jp, adrian@olddog.co.uk Pages: 11 Characters: 24219 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pce-p2mp-req-05.txt URL: http://www.rfc-editor.org/rfc/rfc5862.txt The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs). The use of PCE in MPLS networks is already established, and since P2MP TE LSP routes are sometimes complex to compute, it is likely that PCE will be used for P2MP LSPs. Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in RFC 4657, "Path Computation Element (PCE) Communication Protocol Generic Requirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements for point-to-multipoint MPLS/GMPLS traffic engineering. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Path Computation Element Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@core3.amsl.com Fri Jun 11 08:26:33 2010 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 53F913A68E7; Fri, 11 Jun 2010 08:26:33 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100611152633.53F913A68E7@core3.amsl.com> Date: Fri, 11 Jun 2010 08:26:33 -0700 (PDT) Cc: Internet Architecture Board , pce mailing list , pce chair , RFC Editor Subject: [Pce] Protocol Action: 'Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths' to Proposed Standard X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 15:26:33 -0000 The IESG has approved the following document: - 'Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths ' as a Proposed Standard This document is the product of the Path Computation Element Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-p2mp-extensions-11.txt Technical Summary The Path Computation Element (PCE) defined in [RFC4655] is an entity that is capable of computing a network path or route based on a network graph, and applying computational constraints. A Path Computation Client (PCC) may make requests to a PCE for paths to be computed. [RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The PCE has been identified as a suitable application for the computation of paths for P2MP TE LSPs [RFC5671]. The PCE communication protocol (PCEP) is designed as a communication protocol between PCCs and PCEs for point-to-point (P2P) path computations and is defined in [RFC5440]. However, that specification does not provide a mechanism to request path computation of P2MP TE LSPs. A P2MP LSP is comprised of multiple source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set up between ingress and egress LSRs and are appropriately overlaid to construct a P2MP TE LSP. During path computation, the P2MP TE LSP may be determined as a set of S2L sub- LSPs that are computed separately and combined to give the path of the P2MP LSP, or the entire P2MP TE LSP may be determined as a P2MP tree in a single computation. This document relies on the mechanisms of PCEP to request path computation for P2MP TE LSPs. One path computation request message from a PCC may request the computation of the whole P2MP TE LSP, or the request may be limited to a sub-set of the S2L sub-LSPs. In the extreme case, the PCC may request the S2L sub-LSPs to be computed individually with it being the PCC's responsibility to decide whether to signal individual S2L sub-LSPs or combine the computation results to signal the entire P2MP TE LSP. Hence the PCC may use one path computation request message or may split the request across multiple path computation messages. Working Group Summary No controversy. Document Quality Good. There is one known implementations of the protocol extensions described in this document. RFC Editor Note Section 3.10 paragraph 4 OLD The PCC must also provide the list of old leaves, if any, including END-POINTS with leaf type 3, leaf type 4 or both. The error values when the conditions are not satisfied (i.e., when there is no END-POINTS with leaf type 3 or 4, in the presence of END-POINTS with leaf type 1 or 2). A generic "Inconsistent END-POINT" error is also requested if a PCC receives a request that has an inconsistent END-POINT (i.e., if a leaf specified as type 1 already exists). The The IANA request for all new error values is documented in Section 6.6. (PCEP Error Objects and Types) of this document. NEW When adding new leaves or removing old leaves to the existing P2MP tree the PCC must also provide the list of old leaves, if any, including END-POINTS with leaf type 3, leaf type 4 or both. New PCEP error objects and types are necessary to report when certain conditions are not satisfied (i.e., when there are no END-POINTS with leaf type 3 or 4, in the presence of END-POINTS with leaf type 1 or 2). A generic "Inconsistent END-POINT" error will be used if a PCC receives a request that has an inconsistent END-POINT (i.e., if a leaf specified as type 1 already exists). These IANA requests are documented in Section 6.6. (PCEP Error Objects and Types) of this document. END --- Section 4.1 First bullet OLD o The ability to enable to disable P2MP path computations on the PCE. NEW o The ability to enable or disable P2MP path computations on the PCE. END From ramon.casellas@cttc.es Wed Jun 16 00:48:18 2010 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FD273A6AD8 for ; Wed, 16 Jun 2010 00:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifhPe4GYCowc for ; Wed, 16 Jun 2010 00:48:17 -0700 (PDT) Received: from scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by core3.amsl.com (Postfix) with ESMTP id 6FF0D3A6AD3 for ; Wed, 16 Jun 2010 00:48:15 -0700 (PDT) Received: from castor (postfix@castor.cttc.es [84.88.62.196]) by scorpius.cttc.es (8.13.8/8.13.5) with ESMTP id o5G7lpNS008155 for ; Wed, 16 Jun 2010 09:47:51 +0200 Received: from [84.88.61.50] (pcrcasellas.cttc.es [84.88.61.50]) by castor (Postfix) with ESMTP id 0D96E2FC248; Wed, 16 Jun 2010 09:47:31 +0200 (CEST) Message-ID: <4C188255.8020101@cttc.es> Date: Wed, 16 Jun 2010 09:50:45 +0200 From: Ramon Casellas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: pce@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (castor); Wed, 16 Jun 2010 09:47:32 +0200 (CEST) X-Scanned-By: MIMEDefang 2.57 on 84.88.62.197 Subject: [Pce] Questions on draft-ietf-pce-monitoring-09 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 07:48:18 -0000 Dear draft authors, all, We have started reading the I.-D. draft-ietf-pce-monitoring-09, and we have some comments / questions as detailed below. Clarifications and comments are much welcome :) Questions ============ * In Section 3.1 it is stated that "there is one mandatory object that MUST be included (...) Other objects are optional"; however, the EBNF notation suggests that PCC-ID-REQ is mandatory (pag 7). Also, Section 4.2 states that "PCC-ID-REQ MUST be included (...)". There seems to be a contradiction in Section 3.1 * Similar questions apply for PCReq (pag 8), PCMonRep(pag 10), PCRep, regarding the same PCC-ID-REQ object. * Related to these, In section 4.2. it is stated "The PCC-ID-REQ MUST be inserted within a PCReq or a PCMonReq message to (...)". We interpret this as "The PCC-ID-REQ MUST be inserted within a PCReq message with monitoring data requested (i.e. after the MONITORING) object" * If PCC-ID-REQ is mandatory, souldn't an Error 6 : Mandatory Object missing / 5: PCC-ID-REQ Object missing be added"? along the lines of "If a PCE receives a PCMonReq with the PCC-ID-REQ missing or a PCReq with a MONITORING object but without a PCC-ID-REQ missing it MUST generate aPCEPError 6,5? MONITORING * The draft specifies the procedure when the flags, are set. For the sake of completeness, if flags L, P, C are *not* set in the MONITORING object, what would be the recommended action? the PCE should/should not/may/must not/ include the correspondong PCE_ID, PROC_TIME and OVERLOAD metrics? PROC-TIME * In PROC-TIME object, the variance is said to be indicated in milliseconds. Shouldn't it be in squared milliseconds ? (alternatively one should use the standard deviation) * From our understanding, the PROC_TIME object is supposed to include the path computation time. What is the rationale to not include also the queueing (waiting) time, which specially on overloaded situations, may be significant? On the one hand, the total service request seen by the PCC will also include queueing time (and of course, network latency, etc.), but on the other hand, the text seems to hint that to estimate / to compute processing time the PCE may / must perform the actual path computation, but the queueing time is not mentioned. Since one may assume that permanent regime the PCE will have a queue with (optionally) some priority management, and that we can define a mean number of "customers" (opt. per priority) and mean waiting time, we understand that the total processing time would required either add an estimated "mean waiting time", or, for the actual computation, the request should be tagged at arrival before enqueieng it. OVERLOAD * In Section 4.5 it is said that OVERLOAD MUST be present if C bit (...) is set *and* the PCE is experiencing a congested state. One could assume that the overload may be estimated by the product "number of queued requests at the time the MONITORING object is processed" * "average processing time" or * "max processing time" (worst case), (in seconds). What is the procedure if the PCE is *not* congested (e.g. no backlog), must it return 0? (In other words, the confusing part is "and the PCE is experiencing a congested state" as a condition to insert the OVERLOAD object. Errata? ============ * Section 4.2 mentions object PCE-ID-REQ, (the format of the PCE-ID-REQ... ) typo. It should say PCC-ID-REQ. * Section 4.3 typo "specifyt". * Section 4.5 "This field indicates in the amount of time in seconds" * Section 4.5 refers to the OVERLOAD object but in pag 19. the old? CONGESTION name is used: "the format of the CONGESTION object" Thanks for reading, Ramon ps: We are using object classes from http://www.iana.org/assignments/pcep/pcep.xhtml which, although refer to draft-ietf-pce-monitoring-09, are different -- Ramon Casellas, Ph.D. Research Associate - Optical Networking Area -- http://wikiona.cttc.es CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4 Av. Carl Friedrich Gauss 7 08860 Castelldefels (Barcelona) - Spain Tel.: +34 93 645 29 16 -- Fax. +34 93 645 29 01 From julien.meuric@orange-ftgroup.com Wed Jun 16 09:46:35 2010 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA0C83A6940 for ; Wed, 16 Jun 2010 09:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.349 X-Spam-Level: X-Spam-Status: No, score=-0.349 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_32=0.6, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0Zod-vGnveA for ; Wed, 16 Jun 2010 09:46:34 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 543303A6820 for ; Wed, 16 Jun 2010 09:46:34 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id ED603A02304; Wed, 16 Jun 2010 18:44:04 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id A14E8FC4008; Wed, 16 Jun 2010 18:32:08 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jun 2010 18:32:06 +0200 Received: from [10.193.71.77] ([10.193.71.77]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jun 2010 18:32:06 +0200 Message-ID: <4C18FC86.8030408@orange-ftgroup.com> Date: Wed, 16 Jun 2010 18:32:06 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: pce@ietf.org, Ramon Casellas References: <4C188255.8020101@cttc.es> In-Reply-To: <4C188255.8020101@cttc.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 16 Jun 2010 16:32:06.0666 (UTC) FILETIME=[75A8E6A0:01CB0D71] Subject: Re: [Pce] Questions on draft-ietf-pce-monitoring-09 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 16:46:35 -0000 Hi Ramon. This kind of review and feedback to the PCE mailing list (and to any WG list) is very welcome. Nevertheless, draft-ietf-pce-monitoring-09 has already run through the IESG and is nearly RFC 5886 (just a matter of days). As a result, I have 2 requests: - Ramon, people behind "we" and PCE'rs a large, reviews and comments are necessary to build and improve internet drafts: please, try to start sending them as soon as WG status is achieved (when the group owns the document) and before the end of last calls; - authors, I think some answers from you would be useful to the community. Thanks Julien Le 16/06/2010 09:50, Ramon Casellas a écrit : > Dear draft authors, all, > > We have started reading the I.-D. draft-ietf-pce-monitoring-09, and we > have some comments / questions as detailed below. > > Clarifications and comments are much welcome :) > > > Questions > ============ > > * In Section 3.1 it is stated that "there is one mandatory object that > MUST be included (...) Other objects are optional"; however, the EBNF > notation suggests that PCC-ID-REQ is mandatory (pag 7). Also, Section > 4.2 states that "PCC-ID-REQ MUST be included (...)". There seems to be > a contradiction in Section 3.1 > > * Similar questions apply for PCReq (pag 8), PCMonRep(pag 10), PCRep, > regarding the same PCC-ID-REQ object. > > * Related to these, In section 4.2. it is stated "The PCC-ID-REQ MUST > be inserted within a PCReq or a PCMonReq message to (...)". We > interpret this as "The PCC-ID-REQ MUST be inserted within a PCReq > message with monitoring data requested (i.e. after the MONITORING) > object" > > * If PCC-ID-REQ is mandatory, souldn't an Error 6 : Mandatory Object > missing / 5: PCC-ID-REQ Object missing be added"? along the lines of > "If a PCE receives a PCMonReq with the PCC-ID-REQ missing or a PCReq > with a MONITORING object but without a PCC-ID-REQ missing it MUST > generate aPCEPError 6,5? > > > MONITORING > > * The draft specifies the procedure when the flags, are set. For the > sake of completeness, if flags L, P, C are *not* set in the MONITORING > object, what would be the recommended action? the PCE should/should > not/may/must not/ include the correspondong PCE_ID, PROC_TIME and > OVERLOAD metrics? > > > PROC-TIME > > * In PROC-TIME object, the variance is said to be indicated in > milliseconds. Shouldn't it be in squared milliseconds ? (alternatively > one should use the standard deviation) > > * From our understanding, the PROC_TIME object is supposed to include > the path computation time. What is the rationale to not include also > the queueing (waiting) time, which specially on overloaded situations, > may be significant? On the one hand, the total service request seen by > the PCC will also include queueing time (and of course, network > latency, etc.), but on the other hand, the text seems to hint that to > estimate / to compute processing time the PCE may / must perform the > actual path computation, but the queueing time is not mentioned. Since > one may assume that permanent regime the PCE will have a queue with > (optionally) some priority management, and that we can define a mean > number of "customers" (opt. per priority) and mean waiting time, we > understand that the total processing time would required either add an > estimated "mean waiting time", or, for the actual computation, the > request should be tagged at arrival before enqueieng it. > > > OVERLOAD > > * In Section 4.5 it is said that OVERLOAD MUST be present if C bit > (...) is set *and* the PCE is experiencing a congested state. One > could assume that the overload may be estimated by the product "number > of queued requests at the time the MONITORING object is processed" * > "average processing time" or * "max processing time" (worst case), (in > seconds). What is the procedure if the PCE is *not* congested (e.g. > no backlog), must it return 0? (In other words, the confusing part is > "and the PCE is experiencing a congested state" as a condition to > insert the OVERLOAD object. > > > Errata? > ============ > > * Section 4.2 mentions object PCE-ID-REQ, (the format of the > PCE-ID-REQ... ) typo. It should say PCC-ID-REQ. > > * Section 4.3 typo "specifyt". > > * Section 4.5 "This field indicates in the amount of time in seconds" > > * Section 4.5 refers to the OVERLOAD object but in pag 19. the old? > CONGESTION name is used: "the format of the CONGESTION object" > > > Thanks for reading, > > Ramon > > > ps: We are using object classes from > http://www.iana.org/assignments/pcep/pcep.xhtml which, although refer > to draft-ietf-pce-monitoring-09, are different > > From ramon.casellas@cttc.es Wed Jun 16 10:49:07 2010 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B6C43A6B6A for ; Wed, 16 Jun 2010 10:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.901 X-Spam-Level: X-Spam-Status: No, score=0.901 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIZCG6chc1eC for ; Wed, 16 Jun 2010 10:49:05 -0700 (PDT) Received: from aries.cttc.es (aries.cttc.es [84.88.62.194]) by core3.amsl.com (Postfix) with ESMTP id AA7523A69CE for ; Wed, 16 Jun 2010 10:49:03 -0700 (PDT) Received: from webmail.cttc.es (web.cttc.es [84.88.62.199]) (authenticated bits=0) by aries.cttc.es (8.13.8/8.13.8) with ESMTP id o5GHmsAH020132; Wed, 16 Jun 2010 19:48:54 +0200 Received: from 62.83.139.10 (SquirrelMail authenticated user rcasellas) by webmail.cttc.es with HTTP; Wed, 16 Jun 2010 19:49:53 +0200 (CEST) Message-ID: <50143.62.83.139.10.1276710593.squirrel@webmail.cttc.es> In-Reply-To: <4C18FC86.8030408@orange-ftgroup.com> References: <4C188255.8020101@cttc.es> <4C18FC86.8030408@orange-ftgroup.com> Date: Wed, 16 Jun 2010 19:49:53 +0200 (CEST) From: "Ramon Casellas" To: "Julien Meuric" User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: pce@ietf.org, Ramon Casellas Subject: Re: [Pce] Questions on draft-ietf-pce-monitoring-09 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 17:49:07 -0000 On Wed, June 16, 2010 6:32 pm, Julien Meuric wrote: > This kind of review (...) > already run through the IESG and is nearly RFC 5886 (...) > - Ramon, people behind "we" and PCE'rs a large, reviews and comments are > necessary to build and improve internet drafts: please, try to start > sending them as soon as WG status is achieved (when the group owns the > document) and before the end of last calls; Julien, all I understand the issue; We are sorry for the late feedback (at this point in the I.D. lifetime), but we got involved in active participation in IETF PCE standardization work very recently. Given that in our first read of the draft we spotted some issues, we reported them, hoping that it can still be useful (to avoid these situations, we'll check the proper procedures in order to report such issues once an I.D. has run through the IESG or is already an RFC). > - authors, I think some answers from you would be useful to the community. For what is worth, let me point out a few more. We apologize if most(all?) of them have already been fixed in the to-be-released rfc: * Typo: "in term of". * The document mixes PCC_ID_REQ and PCC_REQ_ID, the PCE IANA file seems to set on using PCC_REQ_ID * Since the draft cites RFC5441 (objective function) it may be worth mentioning that PCMonReq EBNF grammar mentions OF while PCReq one does not. Likewise it does not appear in svec lists, * In page 17, to avoid confusion, it is worth mentioning that the G bit refers to the MONITORING object: "In the former case, the E bit of the PROC-TIME object MUST be set. The G bit MUST be cleared ..." - Thanks R. From wwwrun@rfc-editor.org Mon Jun 21 15:55:36 2010 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E63A128C0F9; Mon, 21 Jun 2010 15:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.364 X-Spam-Level: X-Spam-Status: No, score=-0.364 tagged_above=-999 required=5 tests=[AWL=-0.778, BAYES_40=-0.185, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEpq6uQNePMk; Mon, 21 Jun 2010 15:55:36 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 1D9ED28C131; Mon, 21 Jun 2010 15:55:36 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 941BDE06AC; Mon, 21 Jun 2010 15:55:43 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100621225543.941BDE06AC@rfc-editor.org> Date: Mon, 21 Jun 2010 15:55:43 -0700 (PDT) Cc: pce@ietf.org, rfc-editor@rfc-editor.org Subject: [Pce] RFC 5886 on A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 22:55:37 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5886 Title: A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture Author: JP. Vasseur, Ed., JL. Le Roux, Y. Ikejiri Status: Standards Track Stream: IETF Date: June 2010 Mailbox: jpv@cisco.com, jeanlouis.leroux@orange-ftgroup.com, y.ikejiri@ntt.com Pages: 26 Characters: 56554 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pce-monitoring-09.txt URL: http://www.rfc-editor.org/rfc/rfc5886.txt A Path Computation Element (PCE)-based architecture has been specified for the computation of Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks in the context of single or multiple domains (where a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as Interior Gateway Protocol (IGP) areas and Autonomous Systems). Path Computation Clients (PCCs) send computation requests to PCEs, and these may forward the requests to and cooperate with other PCEs forming a "path computation chain". In PCE-based environments, it is thus critical to monitor the state of the path computation chain for troubleshooting and performance monitoring purposes: liveness of each element (PCE) involved in the PCE chain and detection of potential resource contention states and statistics in terms of path computation times are examples of such metrics of interest. This document specifies procedures and extensions to the Path Computation Element Protocol (PCEP) in order to gather such information. [STANDARDS TRACK] This document is a product of the Path Computation Element Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From mdomdor@unex.es Wed Jun 23 11:53:31 2010 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C80743A6AA8 for ; Wed, 23 Jun 2010 11:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vy3uZ34MCz61 for ; Wed, 23 Jun 2010 11:53:30 -0700 (PDT) Received: from pizarro.unex.es (pizarro.unex.es [158.49.8.2]) by core3.amsl.com (Postfix) with ESMTP id 8FE8C3A6885 for ; Wed, 23 Jun 2010 11:53:30 -0700 (PDT) Received: from localhost (lavadora.siue [192.168.1.121]) by pizarro.unex.es (Postfix) with ESMTP id 8DB5A1485E8; Wed, 23 Jun 2010 20:53:37 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lavadora.unex.es Received: from pizarro.unex.es ([192.168.1.103]) by localhost (lavadora.unex.es [192.168.1.121]) (amavisd-new, port 10024) with ESMTP id 0K+KN9TQzE-6; Wed, 23 Jun 2010 20:48:05 +0200 (CEST) Received: from guadiana.unex.es (guadiana.unex.es [158.49.17.23]) by pizarro.unex.es (Postfix) with ESMTP id 713C61481AE; Wed, 23 Jun 2010 20:53:37 +0200 (CEST) Received: from [192.168.0.192] (unknown [95.60.140.197]) (Authenticated sender: mdomdor@guadiana.unex.es) by guadiana.unex.es (Postfix) with ESMTP id 20E251FF6F; Wed, 23 Jun 2010 20:53:36 +0200 (CEST) Message-ID: <4C22582E.5060408@unex.es> Date: Wed, 23 Jun 2010 20:53:34 +0200 From: Manuel Dominguez Dorado Organization: University of Extremadura User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: pce@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [Pce] About LSPA object X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mdomdor@unex.es List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 18:53:31 -0000 Hello, I am developing a PCEP simulator to test some improvements and I want to implement PCEP LSPA object. In RFC 5440 one can read: "Most of the fields of the LSPA object are identical to the fields of the SESSION-ATTRIBUTE object (C-Type = 7) defined in [RFC3209] and [RFC4090]. When absent from the PCReq message, this means that the Setup and Holding priorities are equal to 0, and there are no affinity constraints. See Section 4.7.4 of [RFC3209] for a detailed description of the use of resource affinities." Well, reading RFC 3209 the operation of the three tests (Exclude-any , Include-any and Include-all) is clear, but it uses a 32 bit vector called Link-attr that is associated with a link. I cannot find the definition of Link-attr. Is it a administratively defined vector with only intra-domain meaning or maybe Link-attr is standardized in other document? Moreover, in RFC 3209 SESSION_ATTRIBUTE has two variants: with and without resources affinities. As I understand from RFC5440, LSPA object in PCEP has only the possibility of including resource affinities information. Is it correct or I am in a mistake? I would thank any information related to this fields of LSPA object because I think LSPA can be very useful to my research. Thank you in advance. -- ------------------------------------------------------------------------ MANUEL DOMÍNGUEZ DORADO Departamento de Ingeniería de Sistemas Informáticos y Telemáticos Universidad de Extremadura ------------------------------------------------------------------------ Addr.: C/ Juan Ramón Jiménez, 6, 1ºH 06300 - Zafra (Badajoz) Phone: +34 607 417 860 Email: mdomdor@unex.es Web..: http://www.ManoloDominguez.com ------------------------------------------------------------------------ From wwwrun@core3.amsl.com Wed Jun 23 12:32:40 2010 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 90B363A696B; Wed, 23 Jun 2010 12:32:38 -0700 (PDT) To: Jeanlouis.Leroux@orange-ftgroup.com, zali@cisco.com, takeda.tomonori@lab.ntt.co.jp, julien.meuric@orange-ftgroup.com, qzhao@huawei.com, daniel@olddog.co.uk, fabien.verhaeghe@gmail.com, mohamad.chaitou@gmail.com From: IETF Secretariat Message-Id: <20100623193239.90B363A696B@core3.amsl.com> Date: Wed, 23 Jun 2010 12:32:39 -0700 (PDT) X-Mailman-Approved-At: Thu, 24 Jun 2010 00:03:05 -0700 Cc: jpv@cisco.com, pce@ietf.org, adrian.farrel@huawei.com, ipr-announce@ietf.org Subject: [Pce] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-pce-pcep-p2mp-extensions-11 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 19:32:40 -0000 Dear Jean-Louis Le Roux, Zafar Ali, Tomonori Takeda, Julien Meuric, Quintin Zhao, Daniel King, Fabien Verhaeghe, Mohamad Chaitou: An IPR disclosure that pertains to your Internet-Draft entitled "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths" (draft-ietf-pce-pcep-p2mp-extensions) was submitted to the IETF Secretariat on 2010-06-23 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1339/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-pce-pcep-p2mp-extensions-11." The IETF Secretariat From jpv@cisco.com Thu Jun 24 00:45:34 2010 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B14B28C106 for ; Thu, 24 Jun 2010 00:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.26 X-Spam-Level: X-Spam-Status: No, score=-10.26 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iB9mOLgWH7-F for ; Thu, 24 Jun 2010 00:45:33 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id BD45D28C0F1 for ; Thu, 24 Jun 2010 00:45:32 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwFABeqIkxAZnwN/2dsb2JhbACBQ51ycaVmmkuFGwQ X-IronPort-AV: E=Sophos;i="4.53,472,1272844800"; d="scan'208,217";a="125039220" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 24 Jun 2010 07:45:40 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o5O7jbto006137 for ; Thu, 24 Jun 2010 07:45:40 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Jun 2010 09:45:39 +0200 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Jun 2010 09:45:38 +0200 Message-Id: <6F77858D-CE6F-40D7-93F4-F9B2A997317B@cisco.com> From: JP Vasseur To: pce@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-41-557991089 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 24 Jun 2010 09:43:38 +0200 References: <20100623193239.90B363A696B@core3.amsl.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 24 Jun 2010 07:45:39.0048 (UTC) FILETIME=[3D46E680:01CB1371] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17464.005 X-TM-AS-Result: No--29.514600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [Pce] Fwd: IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-pce-pcep-p2mp-extensions-11 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 07:45:34 -0000 --Apple-Mail-41-557991089 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear all, We have just been informed of that IPR disclosure (late in the process) while the document (draft-ietf-pcep-pcep-p2mp-extensions-11) is in the RFC editor queue. Please let me know by July 9 if you have any objection moving forward knowing of that IPR. Thanks. JP. Begin forwarded message: > From: IETF Secretariat > Date: June 23, 2010 9:32:39 PM CEDT > To: Jeanlouis.Leroux@orange-ftgroup.com, zali@cisco.com, takeda.tomonori@lab.ntt.co.jp > , julien.meuric@orange-ftgroup.com, qzhao@huawei.com, daniel@olddog.co.uk > , fabien.verhaeghe@gmail.com, mohamad.chaitou@gmail.com > Cc: stbryant@cisco.com, adrian.farrel@huawei.com, pce@ietf.org, jpv@cisco.com > , julien.meuric@orange-ftgroup.com, ipr-announce@ietf.org > Subject: IPR Disclosure: Huawei Technologies Co.,Ltd's Statement > about IPR related to draft-ietf-pce-pcep-p2mp-extensions-11 > > Dear Jean-Louis Le Roux, Zafar Ali, Tomonori Takeda, Julien Meuric, > Quintin Zhao, Daniel King, Fabien Verhaeghe, Mohamad Chaitou: > > An IPR disclosure that pertains to your Internet-Draft entitled > "Extensions to > the Path Computation Element Communication Protocol (PCEP) for > Point-to-Multipoint Traffic Engineering Label Switched Paths" > (draft-ietf-pce-pcep-p2mp-extensions) was submitted to the IETF > Secretariat on > 2010-06-23 and has been posted on the "IETF Page of Intellectual > Property Rights > Disclosures" (https://datatracker.ietf.org/ipr/1339/). The title of > the IPR > disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR > related to > draft-ietf-pce-pcep-p2mp-extensions-11." > > The IETF Secretariat > > --Apple-Mail-41-557991089 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear all,

We = have just been informed of that IPR disclosure (late in the process) = while the document (draft-ietf-pcep-pcep-p2mp-extensions-11) is in the = RFC editor queue.
Please let me know by July 9 if you have any = objection moving forward knowing of that = IPR.

Thanks.

JP.

Begin forwarded message:

From: = IETF Secretariat <ietf-ipr@ietf.org>
Date: = June 23, 2010 9:32:39 PM CEDT
Cc: stbryant@cisco.com, adrian.farrel@huawei.com, = pce@ietf.org, jpv@cisco.com, julien.meuric@orange-ftgr= oup.com, ipr-announce@ietf.org
Subject: = IPR Disclosure: Huawei Technologies Co.,Ltd's Statement = about IPR related to = draft-ietf-pce-pcep-p2mp-extensions-11

Dear = Jean-Louis Le Roux, Zafar Ali, Tomonori Takeda, Julien Meuric, Quintin = Zhao, Daniel King, Fabien Verhaeghe, Mohamad Chaitou:

An IPR = disclosure that pertains to your Internet-Draft entitled "Extensions = to
the Path Computation Element Communication Protocol (PCEP) = for
Point-to-Multipoint Traffic Engineering Label Switched = Paths"
(draft-ietf-pce-pcep-p2mp-extensions) was submitted to the = IETF Secretariat on
2010-06-23 and has been posted on the "IETF Page = of Intellectual Property Rights
Disclosures" (https://datatracker.ietf.o= rg/ipr/1339/). The title of the IPR
disclosure is "Huawei = Technologies Co.,Ltd's Statement about IPR related = to
draft-ietf-pce-pcep-p2mp-extensions-11."

The IETF = Secretariat



= --Apple-Mail-41-557991089-- From jpv@cisco.com Thu Jun 24 00:45:44 2010 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B9A428C10A for ; Thu, 24 Jun 2010 00:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.264 X-Spam-Level: X-Spam-Status: No, score=-10.264 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MuACOizTaR28 for ; Thu, 24 Jun 2010 00:45:43 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0071428C106 for ; Thu, 24 Jun 2010 00:45:42 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwFAGWpIkyrR7Hu/2dsb2JhbACBQ51ycaVrmkuFGwQ X-IronPort-AV: E=Sophos;i="4.53,472,1272844800"; d="scan'208,217";a="338139755" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 24 Jun 2010 07:45:51 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o5O7jdjW011950 for ; Thu, 24 Jun 2010 07:45:50 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Jun 2010 09:45:43 +0200 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Jun 2010 09:45:42 +0200 Message-Id: <0AABDB80-8FC5-4E87-B682-B2014D770EF0@cisco.com> From: JP Vasseur To: pce@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-42-558115433 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 24 Jun 2010 09:45:42 +0200 References: <20100623193239.90B363A696B@core3.amsl.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 24 Jun 2010 07:45:42.0657 (UTC) FILETIME=[3F6D9710:01CB1371] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17464.005 X-TM-AS-Result: No--29.514600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [Pce] Fwd: IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-pce-pcep-p2mp-extensions-11 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 07:45:44 -0000 --Apple-Mail-42-558115433 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear all, We have just been informed of that IPR disclosure (late in the process) while the document (draft-ietf-pcep-pcep-p2mp-extensions-11) is in the RFC editor queue. Please let me know by July 9 if you have any objection moving forward knowing of that IPR. Thanks. JP. Begin forwarded message: > From: IETF Secretariat > Date: June 23, 2010 9:32:39 PM CEDT > To: Jeanlouis.Leroux@orange-ftgroup.com, zali@cisco.com, takeda.tomonori@lab.ntt.co.jp > , julien.meuric@orange-ftgroup.com, qzhao@huawei.com, daniel@olddog.co.uk > , fabien.verhaeghe@gmail.com, mohamad.chaitou@gmail.com > Cc: stbryant@cisco.com, adrian.farrel@huawei.com, pce@ietf.org, jpv@cisco.com > , julien.meuric@orange-ftgroup.com, ipr-announce@ietf.org > Subject: IPR Disclosure: Huawei Technologies Co.,Ltd's Statement > about IPR related to draft-ietf-pce-pcep-p2mp-extensions-11 > > Dear Jean-Louis Le Roux, Zafar Ali, Tomonori Takeda, Julien Meuric, > Quintin Zhao, Daniel King, Fabien Verhaeghe, Mohamad Chaitou: > > An IPR disclosure that pertains to your Internet-Draft entitled > "Extensions to > the Path Computation Element Communication Protocol (PCEP) for > Point-to-Multipoint Traffic Engineering Label Switched Paths" > (draft-ietf-pce-pcep-p2mp-extensions) was submitted to the IETF > Secretariat on > 2010-06-23 and has been posted on the "IETF Page of Intellectual > Property Rights > Disclosures" (https://datatracker.ietf.org/ipr/1339/). The title of > the IPR > disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR > related to > draft-ietf-pce-pcep-p2mp-extensions-11." > > The IETF Secretariat > > --Apple-Mail-42-558115433 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear all,

We = have just been informed of that IPR disclosure (late in the process) = while the document (draft-ietf-pcep-pcep-p2mp-extensions-11) is in the = RFC editor queue.
Please let me know by July 9 if you have any = objection moving forward knowing of that = IPR.

Thanks.

JP.

Begin forwarded message:

From: = IETF Secretariat <ietf-ipr@ietf.org>
Date: = June 23, 2010 9:32:39 PM CEDT
Cc: stbryant@cisco.com, adrian.farrel@huawei.com, = pce@ietf.org, jpv@cisco.com, julien.meuric@orange-ftgr= oup.com, ipr-announce@ietf.org
Subject: = IPR Disclosure: Huawei Technologies Co.,Ltd's Statement = about IPR related to = draft-ietf-pce-pcep-p2mp-extensions-11

Dear = Jean-Louis Le Roux, Zafar Ali, Tomonori Takeda, Julien Meuric, Quintin = Zhao, Daniel King, Fabien Verhaeghe, Mohamad Chaitou:

An IPR = disclosure that pertains to your Internet-Draft entitled "Extensions = to
the Path Computation Element Communication Protocol (PCEP) = for
Point-to-Multipoint Traffic Engineering Label Switched = Paths"
(draft-ietf-pce-pcep-p2mp-extensions) was submitted to the = IETF Secretariat on
2010-06-23 and has been posted on the "IETF Page = of Intellectual Property Rights
Disclosures" (https://datatracker.ietf.o= rg/ipr/1339/). The title of the IPR
disclosure is "Huawei = Technologies Co.,Ltd's Statement about IPR related = to
draft-ietf-pce-pcep-p2mp-extensions-11."

The IETF = Secretariat



= --Apple-Mail-42-558115433-- From wwwrun@core3.amsl.com Thu Jun 24 12:09:35 2010 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 4F1C428C0D9; Thu, 24 Jun 2010 12:09:35 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100624190935.4F1C428C0D9@core3.amsl.com> Date: Thu, 24 Jun 2010 12:09:35 -0700 (PDT) Cc: Internet Architecture Board , pce mailing list , pce chair , RFC Editor Subject: [Pce] Document Action: 'The use of SVEC (Synchronization VECtor) list for Synchronized dependent path computations' to Informational RFC X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 19:09:35 -0000 The IESG has approved the following document: - 'The use of SVEC (Synchronization VECtor) list for Synchronized dependent path computations ' as an Informational RFC This document is the product of the Path Computation Element Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-svec-list-05.txt Technical Summary A Path Computation Element (PCE) performing dependent path computations, for instance calculating a diverse working and protected path not sharing common network points, would need to synchronize the computations in order to increase the probability of meeting the working and protected path diversity (or disjointness) objective and network resource optimization objective. When a PCE computes multiple sets of dependent path computation requests concurrently, it is required to use Synchronization VECtor (SVEC) list for association among the sets of dependent path computation requests. SVEC is also applicable to end-to-end diverse path computation across multiple domains. This document describes the usage of SVECs in the SVEC list and diverse path computation guideline, for the synchronized computation of dependent paths. Working Group Summary No controversy. Document Quality This document is informational, explaining the detail of existing protocol mechanisms to achieve specific functions. There is at least one implementation that we are aware of that makes use of the mechanisms described here. Personnel JP Vasseur (jvasseur@cisco.com) is the Document Shepherd. Adrian Farrel (adrian.farrel@huawei.com) is the Responsible AD. RFC Editor Note Section 1.1 Please expand "SRLG" as "Shared Risk Link Group" --- Section 5.1 OLD If the PCE does not have capability to handle the associated SVEC objects, it may send a PCErr message with Error-Type="Capability not supported". NEW If the PCE, which is unable to handle the associated SVEC, finds the common request-IDs in multiple SVEC objects, the PCE should cancel the path computation request and respond to the PCC with the PCErr message Error-Type="Capability not supported". --- Section 5.2 OLD If a PCC sends path computation requests to a PCE and then sends another path computation requests, which are dependent on the first requests and has been associated by using a SVEC list. NEW However, if a PCC sends path computation requests to a PCE, and then sends a further path computation request to a different PCE using the SVEC list to show that the further request is dependent on the first requests, there is no method for the PCE to correlate the dependent requests sent to different PCEs. --- Section 5.3 Please expand "BRPC" as "Backward Recursive Path Computation" From wwwrun@core3.amsl.com Thu Jun 24 14:28:02 2010 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 971F73A68D8; Thu, 24 Jun 2010 14:28:02 -0700 (PDT) From: Greg Jones(ITU-T SG 15) To: lberger@labn.net, dbrungard@att.com, jpv@cisco.com, julien.meuric@orange-ftgroup.com, swallow@cisco.com, loa@pi.nu Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100624212802.971F73A68D8@core3.amsl.com> Date: Thu, 24 Jun 2010 14:28:02 -0700 (PDT) X-Mailman-Approved-At: Fri, 25 Jun 2010 08:26:59 -0700 Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, steve.trowbridge@alcatel-lucent.com, ccamp@ietf.org, yoichi.maeda@ntt-at.co.jp, koike.yoshinori@lab.ntt.co.jp, paf@cisco.com, adrian.farrel@huawei.com, tsbsg15@itu.int, rcallon@juniper.net, pce@ietf.org Subject: [Pce] New Liaison Statement, "LS204 - SG15 OTNT standardization work plan" X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 21:28:03 -0000 Title: LS204 - SG15 OTNT standardization work plan Submission Date: 2010-06-24 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=913 Please reply by 2011-02-01 From: Greg Jones(ITU-T SG 15) To: IETF CCAMP, PCE and MPLS WGs(lberger@labn.net,dbrungard@att.com,jpv@cisco.com,julien.meuric@orange-ftgroup.com,swallow@cisco.com,loa@pi.nu) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com rcallon@juniper.net mpls@ietf.org pce@ietf.org ccamp@ietf.org yoichi.maeda@ntt-at.co.jp steve.trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: koike.yoshinori@lab.ntt.co.jp Purpose: For comment Body: Attachment(s): LS204 - SG15 OTNT standardization work plan - pdf body (https://datatracker.ietf.org/documents/LIAISON/file1054.pdf) LS204 - SG15 OTNT standardization work plan - pdf attach (https://datatracker.ietf.org/documents/LIAISON/file1055.pdf) From julien.meuric@orange-ftgroup.com Tue Jun 29 06:08:41 2010 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4DDF3A6A21 for ; Tue, 29 Jun 2010 06:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_20=-0.74, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLhhnSd-OkOY for ; Tue, 29 Jun 2010 06:08:41 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 9651B3A67B7 for ; Tue, 29 Jun 2010 06:08:40 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5FB26A0062C for ; Tue, 29 Jun 2010 15:02:12 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 57400A0062F for ; Tue, 29 Jun 2010 15:02:12 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jun 2010 15:01:47 +0200 Received: from [10.193.71.77] ([10.193.71.77]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jun 2010 15:01:47 +0200 Message-ID: <4C29EEBA.1070208@orange-ftgroup.com> Date: Tue, 29 Jun 2010 15:01:46 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11pre) Gecko/20100626 Lightning/1.0b1 Shredder/3.0.6pre MIME-Version: 1.0 To: pce@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jun 2010 13:01:47.0100 (UTC) FILETIME=[3B2EB1C0:01CB178B] Subject: [Pce] Fwd: Third Call for Nomcom 2010-11 Volunteers X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 13:08:41 -0000 FYI -------- Message original -------- De : NomCom Chair Hi all, This is the Third call for Volunteers for the 2010-2011 Nomcom. We are now 2/3 of the way through the volunteer period so if you are considering volunteering please do so now as the time in which you may volunteer is beginning to run short. The call for volunteers remains open until 17:00 PDT (24:00 UTC) on July 8, 2010. I am pleased to report that we currently have 65 volunteers thus far whose qualifications have been confirmed by the secretariat. I have notified each of these volunteers by email. I will publish the current list of volunteers in a separate message. If you volunteered before 12:00 PDT (19:00 UTC) on June 28 to serve as a voting member and have not received a confirmation email from me, please re-submit and bring to my attention right away! We still need additional volunteers, please! If you have attended at least 3 of the last 5 IETF meetings you are eligible to volunteer. The 10 nominating committee members are selected randomly from a pool of volunteers. The details of the operation of Nomcom may be found in RFC 3777. The process on how to volunteer for Nomcom is in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2330/ The lists of open positions and people whose terms end in March 2011 and thus the positions for which the nominating committee is responsible are summarized in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2330/ Please volunteer by sending an email before: 17:00 PDT (24:00 UTC) July 8, 2010 as follows: To: nomcom-chair@ietf.org Subject: Nomcom 2010-11 Volunteer Please include the following information in the body: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name // typically what goes in the Company field // in the IETF Registration Form [] // // For confirmation if selected Please expect an email response from me within 3 days stating whether or not you are qualified. If you don't receive a response, please re-send your email with the tag "Duplicate:" added to the subject line. Thank you and I hope to hear from you, Thomas Walsh Chair, Nomcom 2010-11 Email: nomcom-chair@ietf.org _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce