From pce-bounces@lists.ietf.org Tue Jan 03 12:17:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etpgy-0008Pq-KF; Tue, 03 Jan 2006 12:11:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etpgw-0008Pd-Js for pce@megatron.ietf.org; Tue, 03 Jan 2006 12:11:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24528 for ; Tue, 3 Jan 2006 12:10:08 -0500 (EST) Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtpmA-0002mp-V1 for pce@ietf.org; Tue, 03 Jan 2006 12:16:52 -0500 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1EtpgV-0002lX-A1 for pce@ietf.org; Tue, 03 Jan 2006 18:10:55 +0100 Received: from 12.47.115.90 ([12.47.115.90]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 Jan 2006 18:10:55 +0100 Received: from ptorab by 12.47.115.90 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 Jan 2006 18:10:55 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: pce@ietf.org From: "Payam Torab" Date: Tue, 3 Jan 2006 11:59:56 -0500 Lines: 100 Message-ID: References: <131001c5c034$eaf1ba70$28849ed9@Puppy> X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 12.47.115.90 X-Newsreader: Microsoft Outlook Express 6.00.2900.2670 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-RFC2646: Format=Flowed; Original X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: Subject: [Pce] Re: Internet-Drafts Submission Cutoff Dates for the 64th IETFMeeting in Vancouver, British Columbia, Canada X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi JP and others- Here are some comments, suggestions and questions. Thanks, Payam ------ - Document title: We know this document does not intend to describe the architecture of a PCE- A title such as "Architectural Framework for End-to-End Path Computation using Path Computation Elements" is more appropriate. - Section 3 (Definitions): "Inter-domain path computation may involve the correlation of topology, routing and policy information between domains." What exactly do you mean by correlation? More descriptive text is needed here, may be an example. - Section 4.3: In case the TED is supplemented through configuration or management plane, how do we deal with the address space? Does the TED use IP addresses as identifiers? Yes and no answers deserve to be discussed here. - Section 4.9.2: "Back-off times, alternate path computations, and crankback can help to mitigate this sort of problem, and PCE may also improve the chances of successful TE LSP setup." Suggest "computation of alternate paths" to avoid ambiguity. Also, suggest adding the fundamental solution where the PCE supports batch requests (multiple path computation requests between source and destination pairs) by design, i.e., the requests are not processed sequentially. - Section 5.4: "Multiple PCE path computation with inter-PCE communication involves coordination between distributed PCEs such that the result of the computation performed by one PCE depends on information supplied by other PCEs. This model does not provide a distributed computation algorithm, but allows distinct PCEs to be responsible for computation of parts (segments) of the path." 1- I believe you mean different or distinct PCEs instead of distributed PCEs. 2- We need to exapnd this part. Cooperation between PCEs can take one of two forms, which we refer to as model-based and ad hoc. In model-based cooperation (the case described here), PCEs have information on other domains (aggregate or detailed, available a priori or upon request), and the path (or a section of the path) is decided by one PCE at the end. There is another way the PCEs can cooperate, where they do not share any information, and they find the end-to-end path in an ad hoc fashion (similar to DSR). In this case, we have a distributed path computation. - Figure 5: Suggest adding a link between NMS and TED to show alternate ways for synchronization (the TED synchronization arrow does not suggest a possible link to NMS). - Section 6.3: Synchronization is a bad term for this section. You definitely are not suggesting we compute paths based on a synchronized global clock ;) Suggest "Simultaneous path computation" for the section title, "simultaneous processing of path computation requests" for "synchronized path computation", and "sequential processing of path computation requests" for "non-synchronized path computation" - Section 6.3: Suggest "better" or "closer to optimal" instead of "more optimal". - Section 6.3: "The involvement of more than one PCE in the computation of a series of paths is by its nature non-synchronized. However, a set of cooperating PCEs may be synchronized under the control of a single PCE. For example, a PCC may send a request to a PCE which invokes domain-specific computations by other PCEs before supplying a result to the PCC." Can you elaborate here? - Section 6.3: "Conversely, the PCC may issue a single request to the PCE asking for all of the paths to be computed in a synchronized manner. The PCE will then perform simultaneous computation of the set of requested path. Such synchronized computation can often provide more optimal results." The distinction is clearly important in computation and an algorithms, however, this is not an attribute that can be exposed to or requested by the user- user should have a more descriptive requirement (e.g., two full disjoint paths with total cost of less than x - how the answer is derived, through simultaneous or sequential processing is not something the user should ask for (it is like the user asks for Dijkstra's algorithm to be used). - Section 6.6: Perhaps reliability instread of level of robustness? "JP Vasseur" <> wrote in message news:2DD8AA26-799C-43D4-ABA7-615D5396EB11@cisco.com... > Hi, > > A new revision of draft-ietf-pce-architecture has been edited > addressing several comments related to the Policy aspects, which > requires a new Working Group Last Call. > > This email initiates a working group last call on draft-ietf-pce- > architecture-03.txt. > > The last call will end on January 3 at noon EST. > > Please send your comments to the mailing list and copy the chairs. > > Thanks. > > JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Jan 03 12:58:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtqQH-0002CA-Cu; Tue, 03 Jan 2006 12:58:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtqQF-0002Bt-IN for pce@megatron.ietf.org; Tue, 03 Jan 2006 12:58:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03167 for ; Tue, 3 Jan 2006 12:56:56 -0500 (EST) Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtqVY-0004hr-Sk for pce@ietf.org; Tue, 03 Jan 2006 13:03:41 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EtqPz-0006TW-EV for pce@ietf.org; Tue, 03 Jan 2006 18:57:55 +0100 Received: from 12.47.115.90 ([12.47.115.90]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 Jan 2006 18:57:55 +0100 Received: from ptorab by 12.47.115.90 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 Jan 2006 18:57:55 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: pce@ietf.org From: "Payam Torab" Date: Tue, 3 Jan 2006 12:56:30 -0500 Lines: 106 Message-ID: References: <2DD8AA26-799C-43D4-ABA7-615D5396EB11@cisco.com> X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 12.47.115.90 X-Newsreader: Microsoft Outlook Express 6.00.2900.2670 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-RFC2646: Format=Flowed; Response X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: Subject: [Pce] Re: Working Group Last call on draft-ietf-pce-architecture-03.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Apparently I sent the message to the wrong thread. Please ignore my last post. Sorry for inconvenience. Payam -------- Hi JP and others- Here are some comments, suggestions and questions. Thanks, Payam ------ - Document title: We know this document does not intend to describe the architecture of a PCE- A title such as "Architectural Framework for End-to-End Path Computation using Path Computation Elements" is more appropriate. - Section 3 (Definitions): "Inter-domain path computation may involve the correlation of topology, routing and policy information between domains." What exactly do you mean by correlation? More descriptive text is needed here, may be an example. - Section 4.3: In case the TED is supplemented through configuration or management plane, how do we deal with the address space? Does the TED use IP addresses as identifiers? Yes and no answers deserve to be discussed here. - Section 4.9.2: "Back-off times, alternate path computations, and crankback can help to mitigate this sort of problem, and PCE may also improve the chances of successful TE LSP setup." Suggest "computation of alternate paths" to avoid ambiguity. Also, suggest adding the fundamental solution where the PCE supports batch requests (multiple path computation requests between source and destination pairs) by design, i.e., the requests are not processed sequentially. - Section 5.4: "Multiple PCE path computation with inter-PCE communication involves coordination between distributed PCEs such that the result of the computation performed by one PCE depends on information supplied by other PCEs. This model does not provide a distributed computation algorithm, but allows distinct PCEs to be responsible for computation of parts (segments) of the path." 1- I believe you mean different or distinct PCEs instead of distributed PCEs. 2- We need to exapnd this part. Cooperation between PCEs can take one of two forms, which we refer to as model-based and ad hoc. In model-based cooperation (the case described here), PCEs have information on other domains (aggregate or detailed, available a priori or upon request), and the path (or a section of the path) is decided by one PCE at the end. There is another way the PCEs can cooperate, where they do not share any information, and they find the end-to-end path in an ad hoc fashion (similar to DSR). In this case, we have a distributed path computation. - Figure 5: Suggest adding a link between NMS and TED to show alternate ways for synchronization (the TED synchronization arrow does not suggest a possible link to NMS). - Section 6.3: Synchronization is a bad term for this section. You definitely are not suggesting we compute paths based on a synchronized global clock ;) Suggest "Simultaneous path computation" for the section title, "simultaneous processing of path computation requests" for "synchronized path computation", and "sequential processing of path computation requests" for "non-synchronized path computation" - Section 6.3: Suggest "better" or "closer to optimal" instead of "more optimal". - Section 6.3: "The involvement of more than one PCE in the computation of a series of paths is by its nature non-synchronized. However, a set of cooperating PCEs may be synchronized under the control of a single PCE. For example, a PCC may send a request to a PCE which invokes domain-specific computations by other PCEs before supplying a result to the PCC." Can you elaborate here? - Section 6.3: "Conversely, the PCC may issue a single request to the PCE asking for all of the paths to be computed in a synchronized manner. The PCE will then perform simultaneous computation of the set of requested path. Such synchronized computation can often provide more optimal results." The distinction is clearly important in computation and algorithms, however, this is not an attribute that can be exposed to or requested by the user- user should have a more descriptive requirement (e.g., two full disjoint paths with total cost of less than x - how the answer is derived, through simultaneous or sequential processing is not something the user should ask for (it is like the user asks for Dijkstra's algorithm to be used). - Section 6.6: Perhaps reliability instread of level of robustness? "JP Vasseur" <> wrote in message news:2DD8AA26-799C-43D4-ABA7-615D5396EB11@cisco.com... > Hi, > > A new revision of draft-ietf-pce-architecture has been edited > addressing several comments related to the Policy aspects, which > requires a new Working Group Last Call. > > This email initiates a working group last call on draft-ietf-pce- > architecture-03.txt. > > The last call will end on January 3 at noon EST. > > Please send your comments to the mailing list and copy the chairs. > > Thanks. > > JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Jan 03 16:19:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EttRE-0002Uw-B5; Tue, 03 Jan 2006 16:11:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EttRB-0002UP-UL for pce@megatron.ietf.org; Tue, 03 Jan 2006 16:11:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05698 for ; Tue, 3 Jan 2006 16:10:05 -0500 (EST) Received: from relay2.mail.uk.clara.net ([80.168.70.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EttWT-0005Wn-Kq for pce@ietf.org; Tue, 03 Jan 2006 16:16:50 -0500 Received: from du-069-0050.access.clara.net ([217.158.132.50] helo=Puppy) by relay2.mail.uk.clara.net with esmtp (Exim 4.50) id 1EttQr-0009eb-72; Tue, 03 Jan 2006 21:11:12 +0000 Message-ID: <017901c610aa$b6c1b270$b8849ed9@Puppy> From: "Adrian Farrel" To: References: <2DD8AA26-799C-43D4-ABA7-615D5396EB11@cisco.com> Subject: Re: [Pce] Re: Working Group Last call ondraft-ietf-pce-architecture-03.txt Date: Tue, 3 Jan 2006 21:13:45 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.6 (/) X-Scan-Signature: dd530fb5c702ad6eef32cae6dcb86145 Cc: Payam Torab X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0905536938==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0905536938== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0176_01C610AA.94FD49B0" This is a multi-part message in MIME format. ------=_NextPart_000_0176_01C610AA.94FD49B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Payam, Thanks for your interest in this document. Responses in line. Cheers, Adrian > Hi JP and others- > Here are some comments, suggestions and questions. > Thanks, > Payam > ------ >=20 > - Document title: We know this document does not intend to describe = the > architecture of a PCE- A title such as "Architectural Framework for > End-to-End Path Computation using Path Computation Elements" is more > appropriate. I think I disagree. There are a couple of points. - Architecture and Framework have meanings established by usage within the IETF (in fact the PCE WG has already been around the houses once discussing whether to use "architecture" or "framework"). The document as it stands describes an architecture. - I don't think there is anything here that specifies that the computed path must be end-to-end. Quite to the contrary, in fact. - You are right that the document does not describe the architecture of a PCE. Rather it describes the architecture of a PCE-based model. But the title doesn't say it describes the architecture of a=20 PCE. This is such a small point. Do we really need to make a change? > - Section 3 (Definitions): "Inter-domain path computation may involve = the > correlation of topology, routing and policy information between = domains." > What exactly do you mean by correlation? More descriptive text is = needed > here, may be an example. Hmmm. I guess that by "correlation" we meant that there may be a need to = bring together in mutual realtionship the topology, routing and policy = information that exists in the separate domains. I suppose an example = would be that in order to perform inter-domain path computation we might = need to pull together routing information from both domains. I'm sturggling to find a way to say this different from what I typed. = Maybe someone else can suggest some text. =20 > - Section 4.3: In case the TED is supplemented through configuration = or > management plane, how do we deal with the address space? Does the TED = use IP > addresses as identifiers? Yes and no answers deserve to be discussed = here. I'm not sure I understand your question. The TED can use whatever = identifiers it finds convenient. The only requirement is that the output = should be useable by the PCC to generate signaling messages, and that = the input could be generated from information taken from the IGP-TE. = Both of these operations could utilise a mapping function. Is there some specific case underlying your question? > - Section 4.9.2: "Back-off times, alternate path computations, and = crankback > can help to mitigate this sort of problem, and PCE may also improve = the > chances of successful TE LSP setup." Suggest "computation of alternate > paths" to avoid ambiguity. Yes. > Also, suggest adding the fundamental solution > where the PCE supports batch requests (multiple path computation = requests > between source and destination pairs) by design, i.e., the requests = are not > processed sequentially. It is hard to see how multiple PCCs could arrange for batched processing = without removing any sense of real time computation. Perhaps this is = your point? In order to guarantee non-conflicting computation, it is = necessary to batch all computations together on single centralized = server performing all computations "simultaneously". But, our point is that even this does not guarantee LSP establishment. = The sentence after the one you quote says... However, a single, centralized PCE is not viewed as a solution that can guarantee TE LSP establishment since the potential for network failures or contention for resources still exists where the centralized TED cannot fully reflect current (i.e., real-time) network state. So I don't think your proposed solution is *the* fundamental solution. > - Section 5.4: "Multiple PCE path computation with inter-PCE = communication > involves coordination between distributed PCEs such that the result of = the > computation performed by one PCE depends on information supplied by = other > PCEs. This model does not provide a distributed computation algorithm, = but > allows distinct PCEs to be responsible for computation of parts = (segments) > of the path."=20 > 1- I believe you mean different or distinct PCEs instead of = distributed PCEs. Yes. > 2- We need to exapnd this part. Cooperation between PCEs > can take one of two forms, which we refer to as model-based and ad = hoc. In > model-based cooperation (the case described here), PCEs have = information on > other domains (aggregate or detailed, available a priori or upon = request), > and the path (or a section of the path) is decided by one PCE at the = end. > There is another way the PCEs can cooperate, where they do not share = any > information, and they find the end-to-end path in an ad hoc fashion = (similar > to DSR). In this case, we have a distributed path computation. In your second case, how is the route known by the PCC? Isn't it the = case that the PCEs share the computed route fragments? > - Figure 5: Suggest adding a link between NMS and TED to show = alternate ways > for synchronization (the TED synchronization arrow does not suggest a > possible link to NMS). Yeah, probably. The text covers this pretty well, however. Actually, we debated removing the TED synchronization arrows as beyond = the scope of PCE. > - Section 6.3: Synchronization is a bad term for this section. You > definitely are not suggesting we compute paths based on a synchronized > global clock ;) Suggest "Simultaneous path computation" for the = section > title, "simultaneous processing of path computation requests" for > "synchronized path computation", and "sequential processing of path > computation requests" for "non-synchronized path computation" Synchronization is from the verb, to synchronize. Synchorinze - to make synchronous Synchronous - happening at the same time; occurring together; = simultaneous So I don't see that changing "synchronized" for "simultaneous" has any = gain. In fact, in the third paragraph we use both "synchronized" and = "simultaneous" to make double sure that we are understood. > - Section 6.3: Suggest "better" or "closer to optimal" instead of = "more > optimal". Agreed. > - Section 6.3: "The involvement of more than one PCE in the = computation of a > series of paths is by its nature non-synchronized. However, a set of > cooperating PCEs may be synchronized under the control of a single = PCE. For > example, a PCC may send a request to a PCE which invokes = domain-specific > computations by other PCEs before supplying a result to the PCC." Can = you > elaborate here? Well, consider four domains: B / \ A D \ / C A PCC in domain A may request a pair of diverse paths from an ingress in = domain A to an egress in domain B. Let us assume that there are multiple domain border nodes between = domains B and D, but between no other domains. The PCE for domain A may request paths from the domains B and C. The PCE = for domain B may return several candidate paths. The PCE for domain A = will now request paths through domain D to the egress and considering = the entry points into domain D from domains B and C. Once the results are in, the PCE for domain A can select a pair of = disjoint paths. (Disjointedness being necessary in domains A and D). HOWEVER, this example of how one might decompose a request is entirely = implementation-specific. There are other applicabilities of PCE = cooperation that might achieve this differently. > - Section 6.3: "Conversely, the PCC may issue a single request to the = PCE > asking for all of the paths to be computed in a synchronized manner. = The PCE > will then perform simultaneous computation of the set of requested = path. > Such synchronized computation can often provide more optimal results." = The > distinction is clearly important in computation and algorithms, = however, > this is not an attribute that can be exposed to or requested by the = user- > user should have a more descriptive requirement (e.g., two full = disjoint > paths with total cost of less than x - how the answer is derived, = through > simultaneous or sequential processing is not something the user should = ask > for (it is like the user asks for Dijkstra's algorithm to be used). When you say "user" do you mean the PCC? In the first instance the PCC MUST be responsible for this level of = determinism. That is, if it makes two separate requests for paths, = simultaneous computation cannot be performed. But nevertheless the = requests would be valid... 1. Compute me a path from A to B with least cost. 2. Compute be a path from A to B that is disjoint from the previous path = and which has least cost. Thus, the PCC already has some control over whether simultaneous = computation is requested. Now, many people have told us that they *do* want to be able to specify = which algorithm is used. And this may be very valid because cheap = (small, local, easily accessed) PCEs might not be able to perform = simultaneous computation of very many paths at the same time. It would = then be necessary for these PCEs to reject the request (so that the PCC = could redirect it to a more sophisticated PCE) or redirect the request = itself. > - Section 6.6: Perhaps reliability instread of level of robustness? Oooh! This sent me scampering to the CCAMP P&R drafts to find the definitions = of reliable and robust. Unfortunately not there :-( Having spent some time with Mr. Webster, I conclude that Reliable and = Robust are adequate synonyms. The reason that I don't like to use = "reliable" is an old networking joke... You can rely on our product completely. It fails *every* Tuesday. However, I also note that we should include Resilience. So the bullet = now reads... - the levels of robustness and resilience of the path resources ------=_NextPart_000_0176_01C610AA.94FD49B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Payam,
 
Thanks for your interest in this=20 document.
 
Responses in line.
 
Cheers,
Adrian
 
> Hi JP and others-
> Here = are some=20 comments, suggestions and questions.
> Thanks,
> = Payam
>=20 ------
>
> - Document title: We know this document does not = intend=20 to describe the
> architecture of a PCE- A title such as = "Architectural=20 Framework for
> End-to-End Path Computation using Path Computation = Elements" is more
> appropriate.
 
I think I disagree. There are a = couple of=20 points.
- Architecture and Framework have = meanings=20 established by usage
  within the IETF (in fact = the PCE WG=20 has already been around the
  houses once discussing = whether to use=20 "architecture" or "framework").
  The document as it stands = describes an=20 architecture.
- I don't think there is anything = here that=20 specifies that the computed
  path must be end-to-end. Quite = to the=20 contrary, in fact.
- You are right that the document = does not=20 describe the architecture
  of a PCE. Rather it describes = the=20 architecture of a PCE-based
  model. But the title doesn't = say it=20 describes the architecture of a
  PCE.
 
This is such a small point. Do we = really need to=20 make a change?
 
> - Section 3 (Definitions): = "Inter-domain=20 path computation may involve the
> correlation of topology, = routing and=20 policy information between domains."
> What exactly do you mean by = correlation? More descriptive text is needed
> here, may be an=20 example.
 
Hmmm. I guess that by "correlation" = we meant that=20 there may be a need to bring together in mutual realtionship the = topology,=20 routing and policy information that exists in the separate domains. I = suppose an=20 example would be that in order to perform inter-domain path computation = we might=20 need to pull together routing information from both = domains.
 
I'm sturggling to find a way to say = this=20 different from what I typed. Maybe someone else can suggest some=20 text.
 
> - Section 4.3: In case the TED is supplemented = through=20 configuration or
> management plane, how do we deal with the = address=20 space? Does the TED use IP
> addresses as identifiers? Yes and no = answers=20 deserve to be discussed here.
 
I'm not sure I understand your = question. The TED=20 can use whatever identifiers it finds convenient. The only requirement = is that=20 the output should be useable by the PCC to generate signaling messages, = and that=20 the input could be generated from information taken from the IGP-TE. = Both of=20 these operations could utilise a mapping function.
 
Is there some specific case = underlying your=20 question?

> - Section 4.9.2: "Back-off = times,=20 alternate path computations, and crankback
> can help to mitigate = this=20 sort of problem, and PCE may also improve the
> chances of = successful TE=20 LSP setup." Suggest "computation of alternate
> paths" to avoid=20 ambiguity.
 
Yes.
 
> Also, suggest adding the = fundamental=20 solution
> where the PCE supports batch requests (multiple path=20 computation requests
> between source and destination pairs) by = design,=20 i.e., the requests are not
> processed sequentially.
 
It is hard to see how multiple PCCs = could arrange=20 for batched processing without removing any sense of real time = computation.=20 Perhaps this is your point? In order to guarantee non-conflicting = computation,=20 it is necessary to batch all computations together on single centralized = server=20 performing all computations "simultaneously".
 
But, our point is that even this does = not=20 guarantee LSP establishment. The sentence after the one you quote=20 says...
   However, a single,=20 centralized
   PCE is not viewed as a solution that can = guarantee=20 TE LSP
   establishment since the potential for network = failures or=20 contention
   for resources still exists where the = centralized TED=20 cannot fully
   reflect current (i.e., real-time) network=20 state.
 
So I don't think your proposed = solution is *the*=20 fundamental solution.

> - Section 5.4: "Multiple PCE path = computation=20 with inter-PCE communication
> involves coordination between = distributed=20 PCEs such that the result of the
> computation performed by one = PCE=20 depends on information supplied by other
> PCEs. This model does = not=20 provide a distributed computation algorithm, but
> allows distinct = PCEs to=20 be responsible for computation of parts (segments)
> of the path." =
> 1- I believe you mean different = or distinct=20 PCEs instead of distributed PCEs.
 
Yes.
 
> 2- We need to exapnd this = part.=20 Cooperation between PCEs
> can take one of two forms, which we = refer to as=20 model-based and ad hoc. In
> model-based cooperation (the case = described=20 here), PCEs have information on
> other domains (aggregate or = detailed,=20 available a priori or upon request),
> and the path (or a section = of the=20 path) is decided by one PCE at the end.
> There is another way the = PCEs=20 can cooperate, where they do not share any
> information, and they = find=20 the end-to-end path in an ad hoc fashion (similar
> to DSR). In = this case,=20 we have a distributed path computation.
 
In your second case, how is the route = known by=20 the PCC? Isn't it the case that the PCEs share the computed route=20 fragments?
 
> - Figure 5: Suggest adding a = link between=20 NMS and TED to show alternate ways
> for synchronization (the TED=20 synchronization arrow does not suggest a
> possible link to=20 NMS).
 
Yeah, probably. The text covers this = pretty well,=20 however.
Actually, we debated removing the TED = synchronization arrows as beyond the scope of PCE.

> - Section 6.3: = Synchronization is a bad=20 term for this section. You
> definitely are not suggesting we = compute=20 paths based on a synchronized
> global clock ;) Suggest = "Simultaneous path=20 computation" for the section
> title, "simultaneous processing of = path=20 computation requests" for
> "synchronized path computation", and=20 "sequential processing of path
> computation requests" for=20 "non-synchronized path computation"
 
Synchronization is from the verb, to=20 synchronize.
Synchorinze - to make = synchronous
Synchronous - happening at the same = time;=20 occurring together; simultaneous
 
So I don't see that changing = "synchronized" for=20 "simultaneous" has any gain.
 
In fact, in the third paragraph we = use both=20 "synchronized" and "simultaneous" to make double sure that we are=20 understood.

> - Section 6.3: Suggest = "better" or=20 "closer to optimal" instead of "more
> optimal".
 
Agreed.

> -=20 Section 6.3: "The involvement of more than one PCE in the computation of = a
> series of paths is by its nature non-synchronized. However, a = set=20 of
> cooperating PCEs may be synchronized under the control of a = single=20 PCE. For
> example, a PCC may send a request to a PCE which = invokes=20 domain-specific
> computations by other PCEs before supplying a = result to=20 the PCC." Can you
> elaborate here?
 
Well, consider four = domains:
  B
 / \
A   D
 \ /
  C
 
 
A PCC in domain A may request a pair = of diverse=20 paths from an ingress in domain A to an egress in domain B.
 
Let us assume that there are multiple = domain=20 border nodes between domains B and D, but between no other = domains.
 
The PCE for domain A may request = paths from the=20 domains B and C. The PCE for domain B may return several candidate = paths. The=20 PCE for domain A will now request paths through domain D to the egress = and=20 considering the entry points into domain D from domains B and = C.
 
Once the results are in, the PCE for = domain A can=20 select a pair of disjoint paths. (Disjointedness being necessary in = domains A=20 and D).
 
HOWEVER, this example of how one = might decompose=20 a request is entirely implementation-specific. There are other = applicabilities=20 of PCE cooperation that might achieve this differently.
 
 
> - Section 6.3: "Conversely, the PCC may issue a single request = to the=20 PCE
> asking for all of the paths to be computed in a synchronized = manner.=20 The PCE
> will then perform simultaneous computation of the set of = requested path.
> Such synchronized computation can often provide = more=20 optimal results." The
> distinction is clearly important in = computation=20 and algorithms, however,
> this is not an attribute that can be = exposed to=20 or requested by the user-
> user should have a more descriptive=20 requirement (e.g., two full disjoint
> paths with total cost of = less than=20 x - how the answer is derived, through
> simultaneous or = sequential=20 processing is not something the user should ask
> for (it is like = the user=20 asks for Dijkstra's algorithm to be used).
 
When you say "user" do you mean the PCC?
 
In the first instance the PCC MUST be responsible for this level of = determinism. That is, if it makes two separate requests for paths, = simultaneous=20 computation cannot be performed. But nevertheless the requests would be=20 valid...
1. Compute me a path from A to B with least cost.
2. Compute be a path from A to B that is disjoint from the previous = path=20 and which has least cost.
 
Thus, the PCC already has some control over whether simultaneous=20 computation is requested.
 
Now, many people have told us that they *do* want to be able to = specify=20 which algorithm is used. And this may be very valid because cheap = (small, local,=20 easily accessed) PCEs might not be able to perform simultaneous = computation of=20 very many paths at the same time. It would then be necessary for these = PCEs to=20 reject the request (so that the PCC could redirect it to a more = sophisticated=20 PCE) or redirect the request itself.
 
> - Section 6.6: Perhaps reliability instread of level of=20 robustness?
Oooh!
 
This sent me scampering to the CCAMP P&R drafts to find the = definitions=20 of reliable and robust. Unfortunately not there :-(
 
Having spent some time with Mr. Webster, I conclude that Reliable = and=20 Robust are adequate synonyms. The reason that I don't like to use = "reliable" is=20 an old networking joke...
 
    You can rely on our product completely. It fails = *every*=20 Tuesday.
 
However, I also note that we should = include Resilience. So=20 the bullet now reads...
 
   - the levels of robustness and resilience of the path=20 resources
 
 ------=_NextPart_000_0176_01C610AA.94FD49B0-- --===============0905536938== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0905536938==-- From pce-bounces@lists.ietf.org Tue Jan 03 18:49:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtvuD-00012b-DB; Tue, 03 Jan 2006 18:49:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtvuB-00012W-EG for pce@megatron.ietf.org; Tue, 03 Jan 2006 18:49:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05975 for ; Tue, 3 Jan 2006 18:48:12 -0500 (EST) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtvzU-0006HV-K9 for pce@ietf.org; Tue, 03 Jan 2006 18:54:57 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3) with ESMTP id k03NnATS012866; Wed, 4 Jan 2006 00:49:10 +0100 In-Reply-To: <017901c610aa$b6c1b270$b8849ed9@Puppy> To: Adrian Farrel Subject: Re: [Pce] Re: Working Group Last call ondraft-ietf-pce-architecture-03.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Wed, 4 Jan 2006 00:49:07 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 01/04/2006 00:49:09, Serialize complete at 01/04/2006 00:49:09 X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.8 (/) X-Scan-Signature: dabfd8cc2c196ec56401c44f64d155c2 Cc: pce-bounces@ietf.org, pce@ietf.org, Payam Torab X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1586348354==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multipart message in MIME format. --===============1586348354== Content-Type: multipart/alternative; boundary="=_alternative 0082D6B5C12570EB_=" This is a multipart message in MIME format. --=_alternative 0082D6B5C12570EB_= Content-Type: text/plain; charset="US-ASCII" adrian - some hints inline Hi Payam, Thanks for your interest in this document. Responses in line. Cheers, Adrian > Hi JP and others- > Here are some comments, suggestions and questions. > Thanks, > Payam > ------ > > - Document title: We know this document does not intend to describe the > architecture of a PCE- A title such as "Architectural Framework for > End-to-End Path Computation using Path Computation Elements" is more > appropriate. I think I disagree. There are a couple of points. - Architecture and Framework have meanings established by usage within the IETF (in fact the PCE WG has already been around the houses once discussing whether to use "architecture" or "framework"). The document as it stands describes an architecture. - I don't think there is anything here that specifies that the computed path must be end-to-end. Quite to the contrary, in fact. - You are right that the document does not describe the architecture of a PCE. Rather it describes the architecture of a PCE-based model. But the title doesn't say it describes the architecture of a PCE. This is such a small point. Do we really need to make a change? [dp] point has been already discussed; so, ok but only if there is no other document planned that is going to describe the PCE architecture > - Section 3 (Definitions): "Inter-domain path computation may involve the > correlation of topology, routing and policy information between domains." > What exactly do you mean by correlation? More descriptive text is needed > here, may be an example. Hmmm. I guess that by "correlation" we meant that there may be a need to bring together in mutual realtionship the topology, routing and policy information that exists in the separate domains. I suppose an example would be that in order to perform inter-domain path computation we might need to pull together routing information from both domains. I'm sturggling to find a way to say this different from what I typed. Maybe someone else can suggest some text. [dp] the notion of correlation could be replaced by "association of topology, routing and policy information of two or more domains from which specific relationships may be deduced in order to help in performing path computation." > - Section 4.3: In case the TED is supplemented through configuration or > management plane, how do we deal with the address space? Does the TED use IP > addresses as identifiers? Yes and no answers deserve to be discussed here. I'm not sure I understand your question. The TED can use whatever identifiers it finds convenient. The only requirement is that the output should be useable by the PCC to generate signaling messages, and that the input could be generated from information taken from the IGP-TE. Both of these operations could utilise a mapping function. Is there some specific case underlying your question? > - Section 4.9.2: "Back-off times, alternate path computations, and crankback > can help to mitigate this sort of problem, and PCE may also improve the > chances of successful TE LSP setup." Suggest "computation of alternate > paths" to avoid ambiguity. Yes. > Also, suggest adding the fundamental solution > where the PCE supports batch requests (multiple path computation requests > between source and destination pairs) by design, i.e., the requests are not > processed sequentially. It is hard to see how multiple PCCs could arrange for batched processing without removing any sense of real time computation. Perhaps this is your point? In order to guarantee non-conflicting computation, it is necessary to batch all computations together on single centralized server performing all computations "simultaneously". But, our point is that even this does not guarantee LSP establishment. The sentence after the one you quote says... However, a single, centralized PCE is not viewed as a solution that can guarantee TE LSP establishment since the potential for network failures or contention for resources still exists where the centralized TED cannot fully reflect current (i.e., real-time) network state. So I don't think your proposed solution is *the* fundamental solution. > - Section 5.4: "Multiple PCE path computation with inter-PCE communication > involves coordination between distributed PCEs such that the result of the > computation performed by one PCE depends on information supplied by other > PCEs. This model does not provide a distributed computation algorithm, but > allows distinct PCEs to be responsible for computation of parts (segments) > of the path." > 1- I believe you mean different or distinct PCEs instead of distributed PCEs. Yes. > 2- We need to exapnd this part. Cooperation between PCEs > can take one of two forms, which we refer to as model-based and ad hoc. In > model-based cooperation (the case described here), PCEs have information on > other domains (aggregate or detailed, available a priori or upon request), > and the path (or a section of the path) is decided by one PCE at the end. > There is another way the PCEs can cooperate, where they do not share any > information, and they find the end-to-end path in an ad hoc fashion (similar > to DSR). In this case, we have a distributed path computation. In your second case, how is the route known by the PCC? Isn't it the case that the PCEs share the computed route fragments? > - Figure 5: Suggest adding a link between NMS and TED to show alternate ways > for synchronization (the TED synchronization arrow does not suggest a > possible link to NMS). Yeah, probably. The text covers this pretty well, however. Actually, we debated removing the TED synchronization arrows as beyond the scope of PCE. > - Section 6.3: Synchronization is a bad term for this section. You > definitely are not suggesting we compute paths based on a synchronized > global clock ;) Suggest "Simultaneous path computation" for the section > title, "simultaneous processing of path computation requests" for > "synchronized path computation", and "sequential processing of path > computation requests" for "non-synchronized path computation" Synchronization is from the verb, to synchronize. Synchorinze - to make synchronous Synchronous - happening at the same time; occurring together; simultaneous So I don't see that changing "synchronized" for "simultaneous" has any gain. In fact, in the third paragraph we use both "synchronized" and "simultaneous" to make double sure that we are understood. [dp] don't think the issue is on sync'ing computation but on combining e.g. protected and protecting path computation to avoid trap problem; so i would suggest making use of the term "separated" or "disjoint" vs "joined" path computation > - Section 6.3: Suggest "better" or "closer to optimal" instead of "more > optimal". Agreed. > - Section 6.3: "The involvement of more than one PCE in the computation of a > series of paths is by its nature non-synchronized. However, a set of > cooperating PCEs may be synchronized under the control of a single PCE. For > example, a PCC may send a request to a PCE which invokes domain-specific > computations by other PCEs before supplying a result to the PCC." Can you > elaborate here? Well, consider four domains: B / \ A D \ / C A PCC in domain A may request a pair of diverse paths from an ingress in domain A to an egress in domain B. Let us assume that there are multiple domain border nodes between domains B and D, but between no other domains. The PCE for domain A may request paths from the domains B and C. The PCE for domain B may return several candidate paths. The PCE for domain A will now request paths through domain D to the egress and considering the entry points into domain D from domains B and C. Once the results are in, the PCE for domain A can select a pair of disjoint paths. (Disjointedness being necessary in domains A and D). HOWEVER, this example of how one might decompose a request is entirely implementation-specific. There are other applicabilities of PCE cooperation that might achieve this differently. > - Section 6.3: "Conversely, the PCC may issue a single request to the PCE > asking for all of the paths to be computed in a synchronized manner. The PCE > will then perform simultaneous computation of the set of requested path. > Such synchronized computation can often provide more optimal results." The > distinction is clearly important in computation and algorithms, however, > this is not an attribute that can be exposed to or requested by the user- > user should have a more descriptive requirement (e.g., two full disjoint > paths with total cost of less than x - how the answer is derived, through > simultaneous or sequential processing is not something the user should ask > for (it is like the user asks for Dijkstra's algorithm to be used). When you say "user" do you mean the PCC? In the first instance the PCC MUST be responsible for this level of determinism. That is, if it makes two separate requests for paths, simultaneous computation cannot be performed. But nevertheless the requests would be valid... 1. Compute me a path from A to B with least cost. 2. Compute be a path from A to B that is disjoint from the previous path and which has least cost. Thus, the PCC already has some control over whether simultaneous computation is requested. Now, many people have told us that they *do* want to be able to specify which algorithm is used. And this may be very valid because cheap (small, local, easily accessed) PCEs might not be able to perform simultaneous computation of very many paths at the same time. It would then be necessary for these PCEs to reject the request (so that the PCC could redirect it to a more sophisticated PCE) or redirect the request itself. > - Section 6.6: Perhaps reliability instread of level of robustness? Oooh! This sent me scampering to the CCAMP P&R drafts to find the definitions of reliable and robust. Unfortunately not there :-( [dp] p&r deals with resiliency issues and to clarify these terms resiliency = ability of a system to reach and maintain an acceptable level of functioning and structure with one or more of its components malfunctioning reliability = ability of a system or component to perform consistently its required functions under stated conditions for a specified period of time robustness = the degree to which a system or component can function correctly in the presence of invalid inputs or stressful environment conditions Having spent some time with Mr. Webster, I conclude that Reliable and Robust are adequate synonyms. The reason that I don't like to use "reliable" is an old networking joke... You can rely on our product completely. It fails *every* Tuesday. However, I also note that we should include Resilience. So the bullet now reads... - the levels of robustness and resilience of the path resources _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --=_alternative 0082D6B5C12570EB_= Content-Type: text/html; charset="US-ASCII"
adrian - some hints inline






Hi Payam,
 
Thanks for your interest in this document.
 
Responses in line.
 
Cheers,
Adrian
 
> Hi JP and others-
> Here are some comments, suggestions and questions.
> Thanks,
> Payam
> ------
>
> - Document title: We know this document does not intend to describe the
> architecture of a PCE- A title such as "Architectural Framework for
> End-to-End Path Computation using Path Computation Elements" is more
> appropriate.
 
I think I disagree. There are a couple of points.
- Architecture and Framework have meanings established by usage
  within the IETF (in fact the PCE WG has already been around the
  houses once discussing whether to use "architecture" or "framework").
  The document as it stands describes an architecture.
- I don't think there is anything here that specifies that the computed
  path must be end-to-end. Quite to the contrary, in fact.
- You are right that the document does not describe the architecture
  of a PCE. Rather it describes the architecture of a PCE-based
  model. But the title doesn't say it describes the architecture of a
  PCE.
 
This is such a small point. Do we really need to make a change?
 
[dp] point has been already discussed; so, ok but only if there is no other document planned that is going to describe the PCE architecture

> - Section 3 (Definitions): "Inter-domain path computation may involve the
> correlation of topology, routing and policy information between domains."
> What exactly do you mean by correlation? More descriptive text is needed
> here, may be an example.
 
Hmmm. I guess that by "correlation" we meant that there may be a need to bring together in mutual realtionship the topology, routing and policy information that exists in the separate domains. I suppose an example would be that in order to perform inter-domain path computation we might need to pull together routing information from both domains.
 
I'm sturggling to find a way to say this different from what I typed. Maybe someone else can suggest some text.

[dp] the notion of correlation could be replaced by "association of topology, routing and policy information of two or more domains from which specific relationships may be deduced in order to help in performing path computation."

> - Section 4.3: In case the TED is supplemented through configuration or
> management plane, how do we deal with the address space? Does the TED use IP
> addresses as identifiers? Yes and no answers deserve to be discussed here.
 
I'm not sure I understand your question. The TED can use whatever identifiers it finds convenient. The only requirement is that the output should be useable by the PCC to generate signaling messages, and that the input could be generated from information taken from the IGP-TE. Both of these operations could utilise a mapping function.
 
Is there some specific case underlying your question?

> - Section 4.9.2: "Back-off times, alternate path computations, and crankback
> can help to mitigate this sort of problem, and PCE may also improve the
> chances of successful TE LSP setup." Suggest "computation of alternate
> paths" to avoid ambiguity.
 
Yes.
 
> Also, suggest adding the fundamental solution
> where the PCE supports batch requests (multiple path computation requests
> between source and destination pairs) by design, i.e., the requests are not
> processed sequentially.
 
It is hard to see how multiple PCCs could arrange for batched processing without removing any sense of real time computation. Perhaps this is your point? In order to guarantee non-conflicting computation, it is necessary to batch all computations together on single centralized server performing all computations "simultaneously".
 
But, our point is that even this does not guarantee LSP establishment. The sentence after the one you quote says...
   However, a single, centralized
  PCE is not viewed as a solution that can guarantee TE LSP
  establishment since the potential for network failures or contention
  for resources still exists where the centralized TED cannot fully
  reflect current (i.e., real-time) network state.
 
So I don't think your proposed solution is *the* fundamental solution.

> - Section 5.4: "Multiple PCE path computation with inter-PCE communication
> involves coordination between distributed PCEs such that the result of the
> computation performed by one PCE depends on information supplied by other
> PCEs. This model does not provide a distributed computation algorithm, but
> allows distinct PCEs to be responsible for computation of parts (segments)
> of the path."
> 1- I believe you mean different or distinct PCEs instead of distributed PCEs.
 
Yes.
 
> 2- We need to exapnd this part. Cooperation between PCEs
> can take one of two forms, which we refer to as model-based and ad hoc. In
> model-based cooperation (the case described here), PCEs have information on
> other domains (aggregate or detailed, available a priori or upon request),
> and the path (or a section of the path) is decided by one PCE at the end.
> There is another way the PCEs can cooperate, where they do not share any
> information, and they find the end-to-end path in an ad hoc fashion (similar
> to DSR). In this case, we have a distributed path computation.
 
In your second case, how is the route known by the PCC? Isn't it the case that the PCEs share the computed route fragments?
 
> - Figure 5: Suggest adding a link between NMS and TED to show alternate ways
> for synchronization (the TED synchronization arrow does not suggest a
> possible link to NMS).
 
Yeah, probably. The text covers this pretty well, however.
Actually, we debated removing the TED synchronization arrows as beyond the scope of PCE.

> - Section 6.3: Synchronization is a bad term for this section. You
> definitely are not suggesting we compute paths based on a synchronized
> global clock ;) Suggest "Simultaneous path computation" for the section
> title, "simultaneous processing of path computation requests" for
> "synchronized path computation", and "sequential processing of path
> computation requests" for "non-synchronized path computation"
 
Synchronization is from the verb, to synchronize.
Synchorinze - to make synchronous
Synchronous - happening at the same time; occurring together; simultaneous
 
So I don't see that changing "synchronized" for "simultaneous" has any gain.
 
In fact, in the third paragraph we use both "synchronized" and "simultaneous" to make double sure that we are understood.

[dp] don't think the issue is on sync'ing computation but on combining e.g. protected and protecting path computation to avoid trap problem; so i would suggest making use of the term "separated" or "disjoint" vs "joined" path computation

> - Section 6.3: Suggest "better" or "closer to optimal" instead of "more
> optimal".
 
Agreed.

> - Section 6.3: "The involvement of more than one PCE in the computation of a
> series of paths is by its nature non-synchronized. However, a set of
> cooperating PCEs may be synchronized under the control of a single PCE. For
> example, a PCC may send a request to a PCE which invokes domain-specific
> computations by other PCEs before supplying a result to the PCC." Can you
> elaborate here?
 
Well, consider four domains:
  B
 / \
A   D
 \ /
  C
 
 
A PCC in domain A may request a pair of diverse paths from an ingress in domain A to an egress in domain B.
 
Let us assume that there are multiple domain border nodes between domains B and D, but between no other domains.
 
The PCE for domain A may request paths from the domains B and C. The PCE for domain B may return several candidate paths. The PCE for domain A will now request paths through domain D to the egress and considering the entry points into domain D from domains B and C.
 
Once the results are in, the PCE for domain A can select a pair of disjoint paths. (Disjointedness being necessary in domains A and D).
 
HOWEVER, this example of how one might decompose a request is entirely implementation-specific. There are other applicabilities of PCE cooperation that might achieve this differently.
 
 
> - Section 6.3: "Conversely, the PCC may issue a single request to the PCE
> asking for all of the paths to be computed in a synchronized manner. The PCE
> will then perform simultaneous computation of the set of requested path.
> Such synchronized computation can often provide more optimal results." The
> distinction is clearly important in computation and algorithms, however,
> this is not an attribute that can be exposed to or requested by the user-
> user should have a more descriptive requirement (e.g., two full disjoint
> paths with total cost of less than x - how the answer is derived, through
> simultaneous or sequential processing is not something the user should ask
> for (it is like the user asks for Dijkstra's algorithm to be used).
 
When you say "user" do you mean the PCC?
 
In the first instance the PCC MUST be responsible for this level of determinism. That is, if it makes two separate requests for paths, simultaneous computation cannot be performed. But nevertheless the requests would be valid...
1. Compute me a path from A to B with least cost.
2. Compute be a path from A to B that is disjoint from the previous path and which has least cost.
 
Thus, the PCC already has some control over whether simultaneous computation is requested.
 
Now, many people have told us that they *do* want to be able to specify which algorithm is used. And this may be very valid because cheap (small, local, easily accessed) PCEs might not be able to perform simultaneous computation of very many paths at the same time. It would then be necessary for these PCEs to reject the request (so that the PCC could redirect it to a more sophisticated PCE) or redirect the request itself.
 
> - Section 6.6: Perhaps reliability instread of level of robustness?
Oooh!
 
This sent me scampering to the CCAMP P&R drafts to find the definitions of reliable and robust. Unfortunately not there :-(

[dp] p&r deals with resiliency issues and to clarify these terms

resiliency = ability of a system to reach and maintain an acceptable level of functioning and structure with one or more of its components
malfunctioning

reliability = ability of a system or component to perform consistently its required functions under stated conditions for a specified period of time

robustness = the degree to which a system or component can function correctly in the presence of invalid inputs or stressful environment
conditions


 
Having spent some time with Mr. Webster, I conclude that Reliable and Robust are adequate synonyms. The reason that I don't like to use "reliable" is an old networking joke...
 
    You can rely on our product completely. It fails *every* Tuesday.
 
However, I also note that we should include Resilience. So the bullet now reads...
 
   - the levels of robustness and resilience of the path resources
 _______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce
--=_alternative 0082D6B5C12570EB_=-- --===============1586348354== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1586348354==-- From pce-bounces@lists.ietf.org Wed Jan 04 06:55:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu7Ev-0001Zv-93; Wed, 04 Jan 2006 06:55:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu6XV-0000dk-OE for pce@megatron.ietf.org; Wed, 04 Jan 2006 06:10:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14078 for ; Wed, 4 Jan 2006 06:09:30 -0500 (EST) Received: from mail.lopsys.com ([12.47.115.93] helo=mailsrv01.vasw) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eu6cx-00039m-HG for pce@ietf.org; Wed, 04 Jan 2006 06:16:24 -0500 Received: from NETPTORAB (net-torab.vasw [192.168.254.48]) by mailsrv01.vasw (8.13.1/8.13.1) with SMTP id k04BAOos008122; Wed, 4 Jan 2006 06:10:24 -0500 From: "Payam Torab" To: "'Adrian Farrel'" , Subject: RE: [Pce] Re: Working Group Last call ondraft-ietf-pce-architecture-03.txt Date: Wed, 4 Jan 2006 06:09:21 -0500 Message-ID: <007d01c6111f$50f30500$30fea8c0@NETPTORAB> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <017901c610aa$b6c1b270$b8849ed9@Puppy> Importance: Normal X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on localhost X-Virus-Status: Clean X-Spam-Score: 0.6 (/) X-Scan-Signature: 74c8c6a39062dbfd583931efcf641276 X-Mailman-Approved-At: Wed, 04 Jan 2006 06:55:34 -0500 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1236149892==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1236149892== Content-Type: multipart/alternative; boundary="----=_NextPart_000_007E_01C610F5.681CFD00" This is a multi-part message in MIME format. ------=_NextPart_000_007E_01C610F5.681CFD00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thanks Adrian- I snipped the resolved parts. See inline for the rest. Payam > - Document title: We know this document does not intend to describe the > architecture of a PCE- A title such as "Architectural Framework for > End-to-End Path Computation using Path Computation Elements" is more > appropriate. - I don't think there is anything here that specifies that the computed path must be end-to-end. Quite to the contrary, in fact. [PT] Every path is end-to-end. What I meant is how we end up at the destination using PCEs, i.e., how PCEs take us from one end to another. - You are right that the document does not describe the architecture of a PCE. Rather it describes the architecture of a PCE-based model. But the title doesn't say it describes the architecture of a PCE. This is such a small point. Do we really need to make a change? [PT] The current title is "Path Computation Element (PCE) Architecture", which means the same thing as the architecture of a PCE. Sorry, this is a wrong title. Now I'm having a struggle myself finding the right title- based on your input, "Architecture for Path Computation Using a Path Computation Element (PCE)" is a better title. This way we also have room if we really want to have a document on PCE architecture. > - Section 4.3: In case the TED is supplemented through configuration or > management plane, how do we deal with the address space? Does the TED use IP > addresses as identifiers? Yes and no answers deserve to be discussed here. I'm not sure I understand your question. The TED can use whatever identifiers it finds convenient. The only requirement is that the output should be useable by the PCC to generate signaling messages, and that the input could be generated from information taken from the IGP-TE. Both of these operations could utilise a mapping function. Is there some specific case underlying your question? [PT] PCE is bringing together path computation functionalities in management plane and control plane. I was concerned about the identifiers used for network elements which do and do not have a control plane. As long as these IDs are assigned from the same pool we are fine. This is almost always the case (NMS assigning addresses to all elements), but I thought we need to mention that. Note this is the first time a common database TED is allowed to be supplemented by the two planes. For example, a switched connection appearing as a link in TED (an FA-LSP for example) needs to have an Id. How do we make sure this Id is not the same as the Id assigned to a transport link with no control plane? Also, suggest adding the fundamental solution > where the PCE supports batch requests (multiple path computation requests > between source and destination pairs) by design, i.e., the requests are not > processed sequentially. It is hard to see how multiple PCCs could arrange for batched processing without removing any sense of real time computation. Perhaps this is your point? In order to guarantee non-conflicting computation, it is necessary to batch all computations together on single centralized server performing all computations "simultaneously". [PT] Batch processing simply means processing multiple requests together. This is a PCE feature and PCCs have no knowledge or control over it. PCE may choose to wait to receive multiple requests, or the case that makes more sense is PCE is busy with a task at hand, and once done there are one or more requests in the queue, and PCE processes them together. So, it is invisible to PCC. But, our point is that even this does not guarantee LSP establishment. The sentence after the one you quote says... However, a single, centralized PCE is not viewed as a solution that can guarantee TE LSP establishment since the potential for network failures or contention for resources still exists where the centralized TED cannot fully reflect current (i.e., real-time) network state. So I don't think your proposed solution is *the* fundamental solution. [PT] well we are not talking about going to the moon, so when I say fundamental I mean -the- best algorithmic solution given all the existing requests at the time- any path computation result is of course subject to blocking. Now, beyond the choice of words: The text is about computing two or more paths, which could happen in response to requests by one or more PCCs. One PCC may make multiple path computation requests for different source-destination pairs (different sources could be different starting interfaces on the same node for example). The ability to process these requests together (flow-based computation) is -the- best solution. Even in case the requests arrive from multiple PCCs, batch processing is indeed the best solution to the problem described here, and if we want to hint at any solution we should at least mention the best one. So, here's a shot at the paragraph, which actually sits nice with the second part: "Batch processing of all requests, back-off times, computing alternate paths, and crankback can help to mitigate this sort of problem, and PCE may also improve the chances of successful TE LSP setup. However, a single, centralized PCE is not viewed as a solution that can guarantee TE LSP establishment since the potential for network failures or contention for resources still exists where the centralized TED cannot fully reflect current (i.e., real-time) network state." > 2- We need to exapnd this part. Cooperation between PCEs > can take one of two forms, which we refer to as model-based and ad hoc. In > model-based cooperation (the case described here), PCEs have information on > other domains (aggregate or detailed, available a priori or upon request), > and the path (or a section of the path) is decided by one PCE at the end. > There is another way the PCEs can cooperate, where they do not share any > information, and they find the end-to-end path in an ad hoc fashion (similar > to DSR). In this case, we have a distributed path computation. In your second case, how is the route known by the PCC? Isn't it the case that the PCEs share the computed route fragments? [PT] Yes and no- they share route fragments, but these fragments are not limited to each domain , rather they end at destination. Suggest looking at DSR ad hoc routing. With -zero- topology information shared between PCEs, a complete end-to-end path can be computed in a distributed fashion. > - Section 6.3: "Conversely, the PCC may issue a single request to the PCE > asking for all of the paths to be computed in a synchronized manner. The PCE > will then perform simultaneous computation of the set of requested path. > Such synchronized computation can often provide more optimal results." The > distinction is clearly important in computation and algorithms, however, > this is not an attribute that can be exposed to or requested by the user- > user should have a more descriptive requirement (e.g., two full disjoint > paths with total cost of less than x - how the answer is derived, through > simultaneous or sequential processing is not something the user should ask > for (it is like the user asks for Dijkstra's algorithm to be used). When you say "user" do you mean the PCC? In the first instance the PCC MUST be responsible for this level of determinism. That is, if it makes two separate requests for paths, simultaneous computation cannot be performed. But nevertheless the requests would be valid... 1. Compute me a path from A to B with least cost. 2. Compute be a path from A to B that is disjoint from the previous path and which has least cost. Thus, the PCC already has some control over whether simultaneous computation is requested. [PT] Not true. As described above PCE may choose to batch process the requests and process these two requests (and possibly many more in the queue) together. We should not assume any correlation between how the requests are sent and how they are processed. Therefore, the starting paragraph in Section 6.3 also needs to be modified, as multiple PCC requests does not necessarily mean non-synchronized path computation (unless explicitly requested, which we'll address in the next bullet). Now, many people have told us that they *do* want to be able to specify which algorithm is used. And this may be very valid because cheap (small, local, easily accessed) PCEs might not be able to perform simultaneous computation of very many paths at the same time. It would then be necessary for these PCEs to reject the request (so that the PCC could redirect it to a more sophisticated PCE) or redirect the request itself. [PT] This is a sad point that kills the black box elegance of this work. What happens if I come up with a modified or original algorithm in my PCE that outperforms existing algorithms? It may never get called because its algorithm is not listed in the PCC list of algorithms. Since this is a dangerous issue, let's be clear: Algorithm opacity is fundamental to the value of this work, and if someone is interested in specifying an algorithm, they are in fact interested in one or more high-level requirements that are addressed by that algorithm. These high-level requirements can be negotiated at the time of discovery, which is a much better time than in the middle of making a request and getting disappointed by a cheap PCE. I suggest we spell this out in the document. So, is synchronized vs. non-synchronized an algorithmic requirement, or a high-level requirement? My view is that it is a (poorly defined) algorithmic requirement. I can think of a high-level requirement but believe it is outside the scope (e.g., total cost should be within x% of the solution that is found by processing n requests at the same time). The point is we should drop the whole idea of asking for synchronized or non-synchronized computation. The better approach is to have the PCC learn the PCE capabilities at the time of discovery and decide not to choose a PCE because it cannot satisfy a more high-level requirement. > - Section 6.6: Perhaps reliability instread of level of robustness? Oooh! Having spent some time with Mr. Webster, I conclude that Reliable and Robust are adequate synonyms. [PT] Sorry about being picky for certain words, but there are tons of material on assigning reliability functions (standard term in reliability engineering with clear definition based on the resource failure rate and resource age) to network elements/resources, and using reliability as a metric in path computation- Suggest you do a search for "computing the most reliable path". ------=_NextPart_000_007E_01C610F5.681CFD00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks Adrian- I snipped the resolved parts. = See inline=20 for the rest.
Payam
> - Document title: We know this document does not intend = to=20 describe the
> architecture of a PCE- A title such as = "Architectural=20 Framework for
> End-to-End Path Computation using Path = Computation=20 Elements" is more
> appropriate.
 
- I=20 don't think there is anything here that specifies that the=20 computed
  path must be = end-to-end. Quite to=20 the contrary, in fact.
[PT] Every path is end-to-end. What I meant is = how=20 we end up at the destination using PCEs, i.e., how PCEs take = us from=20 one end to another.
 
- You are right that the document = does not=20 describe the architecture
  of a PCE. Rather it = describes the=20 architecture of a PCE-based
  model. But the title doesn't = say it=20 describes the architecture of a
  PCE.
 
This is such a small point. = Do we really=20 need to make a change?
[PT]  The current = title is=20 "Path = Computation=20 Element (PCE) Architecture", = which means=20 the same thing as the architecture of a PCE. Sorry, this is a = wrong=20 title. Now I'm having a struggle myself finding the right title- based = on your=20 input, "Architecture for Path Computation Using a Path = Computation=20 Element (PCE)" is a better title. This way we also have room if we = really want=20 to have a document on PCE=20 architecture.
 
> - Section 4.3: In case the TED = is=20 supplemented through configuration or
> management plane, how do = we deal=20 with the address space? Does the TED use IP
> addresses as = identifiers?=20 Yes and no answers deserve to be discussed here.
 
I'm not sure I understand your = question. The=20 TED can use whatever identifiers it finds convenient. The only = requirement is=20 that the output should be useable by the PCC to generate signaling = messages,=20 and that the input could be generated from information taken from the = IGP-TE.=20 Both of these operations could utilise a mapping = function.
 
Is there some specific case = underlying=20 your question?
[PT] PCE is bringing together path computation=20 functionalities in management plane and control plane. I was=20 concerned about the identifiers used for network = elements which do=20 and do not have a control plane. As long as these IDs are = assigned from=20 the same pool we are fine. This is almost always the case (NMS = assigning=20 addresses to all elements), but I thought we need to mention that. = Note this=20 is the first time a common database TED is allowed to be supplemented = by the=20 two planes. For example, a switched connection appearing as a link in = TED (an=20 FA-LSP for example) needs to have an Id. How do we make sure this Id = is not=20 the same as the Id assigned to a transport link with no = control=20 plane?

 Also, suggest adding the = fundamental=20 solution
> where the PCE supports batch requests (multiple path=20 computation requests
> between source and destination pairs) by = design,=20 i.e., the requests are not
> processed = sequentially.
 
It is hard to see how multiple PCCs = could=20 arrange for batched processing without removing any sense of real = time=20 computation. Perhaps this is your point? In order to guarantee = non-conflicting=20 computation, it is necessary to batch all computations together on = single=20 centralized server performing all computations = "simultaneously".
[PT] Batch=20 processing simply means processing multiple requests together. = This is a=20 PCE feature and PCCs have no knowledge or control over it. PCE = may choose=20 to wait to receive multiple requests, or the case that makes more = sense is PCE=20 is busy with a task at hand, and once done there are one or more = requests=20 in the queue, and PCE processes them together. So, it is invisible=20 to PCC. 
 
But, our point is that even this = does not=20 guarantee LSP establishment. The sentence after the one you quote=20 says...
   However, a single,=20 centralized
   PCE is not viewed as a solution that can = guarantee=20 TE LSP
   establishment since the potential for network = failures=20 or contention
   for resources still exists where the = centralized=20 TED cannot fully
   reflect current (i.e., real-time) = network=20 state.
 
So I don't think your proposed = solution is=20 *the* fundamental solution.
[PT] well we are not talking about = going to=20 the moon, so when I say fundamental I mean -the- best algorithmic = solution=20 given all the existing requests at the time- any path = computation=20 result is of course subject to blocking. Now, beyond the choice of=20 words:
 
The text is about computing two or more = paths,=20 which could happen in response to requests by one or more PCCs.=20 One PCC may make multiple path computation requests for = different source-destination pairs (different sources could be = different=20 starting interfaces on the same node for example). The ability to = process=20 these requests together (flow-based computation) is = -the- best=20 solution. Even = in case the=20 requests arrive from multiple PCCs, batch processing is = indeed=20 the best solution to the problem described here, and if we = want=20 to hint at any solution we should at least mention=20 the best one.
 
So, here's a shot at the paragraph, = which actually=20 sits nice with the second part: "Batch processing of all requests, = back-off times, computing alternate paths, and crankback can = help to=20 mitigate this sort of problem, and PCE may also improve the chances of = successful TE LSP setup. However, a single, centralized PCE is not = viewed as a=20 solution that can guarantee TE LSP establishment since the potential = for=20 network failures or contention for resources still exists where the=20 centralized TED cannot fully reflect current (i.e., real-time) network = state."

> 2- We need=20 to exapnd this part. Cooperation between PCEs
> can take one of = two=20 forms, which we refer to as model-based and ad hoc. In
> = model-based=20 cooperation (the case described here), PCEs have information = on
> other=20 domains (aggregate or detailed, available a priori or upon = request),
>=20 and the path (or a section of the path) is decided by one PCE at the=20 end.
> There is another way the PCEs can cooperate, where they = do not=20 share any
> information, and they find the end-to-end path in an = ad hoc=20 fashion (similar
> to DSR). In this case, we have a distributed = path=20 computation.
 
In your second case, how is = the route=20 known by the PCC? Isn't it the case that the PCEs share the computed = route=20 fragments?
[PT] Yes and no- they share route fragments, = but these=20 fragments are not limited to each domain , rather they end=20 at destination. Suggest looking at DSR ad hoc routing. With = -zero-=20 topology information shared between PCEs, a complete end-to-end path = can be=20 computed in a distributed=20 fashion. 

> - Section 6.3: "Conversely, the PCC = may issue a=20 single request to the PCE
> asking for all of the paths to be = computed=20 in a synchronized manner. The PCE
> will then perform = simultaneous=20 computation of the set of requested path.
> Such synchronized=20 computation can often provide more optimal results." The
> = distinction=20 is clearly important in computation and algorithms, however,
> = this is=20 not an attribute that can be exposed to or requested by the = user-
> user=20 should have a more descriptive requirement (e.g., two full = disjoint
>=20 paths with total cost of less than x - how the answer is derived,=20 through
> simultaneous or sequential processing is not something = the=20 user should ask
> for (it is like the user asks for Dijkstra's = algorithm=20 to be used).
 
When you say "user" do you mean the = PCC?
 
In the first instance the PCC MUST be responsible = for this=20 level of determinism. That is, if it makes two separate requests for = paths,=20 simultaneous computation cannot be performed. But nevertheless the = requests=20 would be valid...
1. Compute me a path from A to B with least=20 cost.
2. Compute be a path from A to B that is disjoint = from the=20 previous path and which has least cost.
 
Thus, the PCC already has some control over = whether=20 simultaneous computation is requested.
[PT] Not true. As described above = PCE may=20 choose to batch process the requests and process these two = requests (and=20 possibly many more in the queue) together. We should not assume = any=20 correlation between how the requests are sent and how they = are=20 processed. Therefore, the starting paragraph in Section 6.3 also needs = to be=20 modified, as multiple PCC requests does not necessarily mean = non-synchronized=20 path computation (unless explicitly requested, which we'll address in = the next=20 bullet).
 
Now, many people have told us that they *do* want = to be able=20 to specify which algorithm is used. And this may be very valid because = cheap=20 (small, local, easily accessed) PCEs might not be able to perform = simultaneous=20 computation of very many paths at the same time. It would then be = necessary=20 for these PCEs to reject the request (so that the PCC could redirect = it to a=20 more sophisticated PCE) or redirect the request itself.
[PT] This is a sad point that kills the = black box=20 elegance of this work. What happens if I come up with a modified=20 or original algorithm in my PCE that outperforms existing=20 algorithms? It may never get called because its algorithm is = not=20 listed in the PCC list of algorithms. Since this is a dangerous = issue,=20 let's be clear: Algorithm opacity is fundamental to the value of this = work,=20 and if someone is interested in specifying an algorithm, they are in = fact=20 interested in one or more high-level requirements that are = addressed by=20 that algorithm. These high-level requirements can be negotiated at the = time of=20 discovery, which is a much better time than in the middle of making a = request=20 and getting disappointed by a cheap PCE. I suggest we spell this = out in=20 the document.
 
So, is synchronized vs. non-synchronized an = algorithmic requirement, or a high-level requirement? My view is = that it=20 is a (poorly defined) algorithmic requirement. I can think of a = high-level=20 requirement but believe it is outside the scope (e.g., total = cost=20 should be within x% of the solution that is found by processing n = requests at the same time).
 
The point is we should drop the whole idea = of asking=20 for synchronized or non-synchronized computation. The better=20 approach is to have the PCC learn the PCE capabilities at = the time=20 of discovery and decide not to choose a PCE because it cannot satisfy = a more=20 high-level requirement.
 
> - Section 6.6: Perhaps reliability instread = of level of=20 robustness?
Oooh!
 
Having spent some time with Mr. Webster, I = conclude that=20 Reliable and Robust are adequate synonyms.
[PT] Sorry=20 about being picky for certain words, but there are tons of material on = assigning reliability functions (standard term in reliability=20 engineering with clear definition based on the resource = failure=20 rate and resource age) to network elements/resources, and = using=20 reliability as a metric in path computation- Suggest you do a search = for=20 "computing the most reliable path".
 
------=_NextPart_000_007E_01C610F5.681CFD00-- --===============1236149892== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1236149892==-- From pce-bounces@lists.ietf.org Wed Jan 04 08:32:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu8ky-0006R7-WD; Wed, 04 Jan 2006 08:32:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu8kx-0006R1-31 for pce@megatron.ietf.org; Wed, 04 Jan 2006 08:32:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00205 for ; Wed, 4 Jan 2006 08:31:31 -0500 (EST) Received: from relay1.mail.uk.clara.net ([80.168.70.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eu8qP-0008P4-5n for pce@ietf.org; Wed, 04 Jan 2006 08:38:27 -0500 Received: from du-069-0083.access.clara.net ([217.158.132.83] helo=Puppy) by relay1.mail.uk.clara.net with esmtp (Exim 4.46) id 1Eu8km-000MUJ-H5; Wed, 04 Jan 2006 13:32:37 +0000 Message-ID: <027701c61133$d7ac5ec0$b8849ed9@Puppy> From: "Adrian Farrel" To: References: Subject: Re: [Pce] Re: Working Group Last call on draft-ietf-pce-architecture-03.txt Date: Wed, 4 Jan 2006 12:26:18 -0000 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Cc: pce@ietf.org, Payam Torab X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Thanks Dimitri, >>> - Section 3 (Definitions): "Inter-domain path computation may involve >>> the correlation of topology, routing and policy information between >>> domains." >>> What exactly do you mean by correlation? More descriptive text is >>> needed here, may be an example. >> >>Hmmm. I guess that by "correlation" we meant that there may be a need to >>bring together in mutual realtionship the topology, routing and policy >>information that exists in the separate domains. I suppose an example >>would be that in order to perform inter-domain path computation we might >>need to pull together routing information from both domains. >> >>I'm sturggling to find a way to say this different from what I typed. >>Maybe someone else can suggest some text. > > [dp] the notion of correlation could be replaced by "association of > topology, routing and policy information of two or more domains from which > specific relationships may be deduced in order to help in performing path > computation." If the working group thinks "association" is a more acceptable word than "correlation", I'm easy with that. The second half of your sentence is useful. Thanks. >>> - Section 6.3: Synchronization is a bad term for this section. You >>> definitely are not suggesting we compute paths based on a synchronized >>> global clock ;) Suggest "Simultaneous path computation" for the section >>> title, "simultaneous processing of path computation requests" for >>> "synchronized path computation", and "sequential processing of path >>> computation requests" for "non-synchronized path computation" >> >>Synchronization is from the verb, to synchronize. >>Synchorinze - to make synchronous >>Synchronous - happening at the same time; occurring together; simultaneous >> >>So I don't see that changing "synchronized" for "simultaneous" has any >>gain. >> >>In fact, in the third paragraph we use both "synchronized" and >>"simultaneous" to make double sure that we are understood. > > [dp] don't think the issue is on sync'ing computation but on combining > e.g. protected and protecting path computation to avoid trap problem; so i > would suggest making use of the term "separated" or "disjoint" vs "joined" > path computation I don't get it. None of these terms (including the one we currently have in the I-D) has any meaning without an accompanying definition. So why is it so important to change the word? I prefer to use a word that sits naturally in the language. >>> - Section 6.6: Perhaps reliability instread of level of robustness? >>Oooh! >> >>This sent me scampering to the CCAMP P&R drafts to find the definitions of >>reliable and robust. Unfortunately not there :-( > > [dp] p&r deals with resiliency issues and to clarify these terms > > resiliency = ability of a system to reach and maintain an acceptable level > of functioning and structure with one or more of its components > malfunctioning > > reliability = ability of a system or component to perform consistently its > required functions under stated conditions for a specified period of time > > robustness = the degree to which a system or component can function > correctly in the presence of invalid inputs or stressful environment > conditions Well, given that statement, I guess our text should read... - the levels of resiliency, reliability and robustness of the path resources ... which should satisfy Payam as well. Cheers, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jan 04 08:32:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu8l2-0006Rd-GJ; Wed, 04 Jan 2006 08:32:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu8ky-0006R6-Ll for pce@megatron.ietf.org; Wed, 04 Jan 2006 08:32:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00218 for ; Wed, 4 Jan 2006 08:31:33 -0500 (EST) Received: from relay1.mail.uk.clara.net ([80.168.70.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eu8qS-0008Pe-8z for pce@ietf.org; Wed, 04 Jan 2006 08:38:29 -0500 Received: from du-069-0083.access.clara.net ([217.158.132.83] helo=Puppy) by relay1.mail.uk.clara.net with esmtp (Exim 4.46) id 1Eu8kp-000MUJ-Gg; Wed, 04 Jan 2006 13:32:46 +0000 Message-ID: <027801c61133$d9646f00$b8849ed9@Puppy> From: "Adrian Farrel" To: "Payam Torab" , References: <007d01c6111f$50f30500$30fea8c0@NETPTORAB> Subject: Re: [Pce] Re: Working Group Last call ondraft-ietf-pce-architecture-03.txt Date: Wed, 4 Jan 2006 13:35:29 -0000 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4ec58ef3f343ebf5ac40a04538f9a6fc Content-Transfer-Encoding: 7bit Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, >>> - Document title: We know this document does not intend to describe the >>> architecture of a PCE- A title such as "Architectural Framework for >>> End-to-End Path Computation using Path Computation Elements" is more >>> appropriate. >> >> - I don't think there is anything here that specifies that the computed >> path must be end-to-end. Quite to the contrary, in fact. > [PT] Every path is end-to-end. What I meant is how we end up at the > destination using PCEs, i.e., how PCEs take us from one end to another. > >> - You are right that the document does not describe the architecture >> of a PCE. Rather it describes the architecture of a PCE-based >> model. But the title doesn't say it describes the architecture of a >> PCE. >> >> This is such a small point. Do we really need to make a change? > [PT] The current title is "Path Computation Element (PCE) Architecture", > which means the same thing as the architecture of a PCE. Sorry, this is a > wrong title. Now I'm having a struggle myself finding the right title- based > on your input, "Architecture for Path Computation Using a Path Computation > Element (PCE)" is a better title. This way we also have room if we really > want to have a document on PCE architecture. Well, I must confess that I find this discussions of semantics frustrating. However, if the title confused you that is reason enough to change it. But we must change it to something that is accurate. How about... "A PCE-Based Network Architecture" >>> - Section 4.3: In case the TED is supplemented through configuration or >>> management plane, how do we deal with the address space? Does the TED >>> use IP addresses as identifiers? Yes and no answers deserve to be discussed >>> here. >> >> I'm not sure I understand your question. The TED can use whatever >> identifiers it finds convenient. The only requirement is that the output >> should be useable by the PCC to generate signaling messages, and that the >> input could be generated from information taken from the IGP-TE. Both of >> these operations could utilise a mapping function. >> >> Is there some specific case underlying your question? > [PT] PCE is bringing together path computation functionalities in > management plane and control plane. I was concerned about the identifiers > used for network elements which do and do not have a control plane. As long > as these IDs are assigned from the same pool we are fine. This is almost > always the case (NMS assigning addresses to all elements), but I thought we > need to mention that. Are you saying that it is not possible to compute a path unless all identifiers come from the same name space? 'Cos that is clearly not true - the computation operates on an abstraction. So you may be saying that the computed path must be presented to the PCC using identifiers that can be understood by the PCC. But that is only superficially true - the PCC only needs to understand the identifiers that it must process. It is quite conceivable that a multidomain path will be signaled by a control plane for the first domain, but will cross an E-NNI into a domain where the LSP is established using a management plane. I still don't get your point. > Note this is the first time a common database TED is > allowed to be supplemented by the two planes. Well, it is not the first time a routing database has been built from management and control plane information. I think this has been happening for a while. > For example, a switched > connection appearing as a link in TED (an FA-LSP for example) needs to have > an Id. How do we make sure this Id is not the same as the Id assigned to a > transport link with no control plane? This is not a PCE question. >>> Also, suggest adding the fundamental solution >>> where the PCE supports batch requests (multiple path computation >>> requests between source and destination pairs) by design, i.e., the >>> requests are not processed sequentially. >> >> It is hard to see how multiple PCCs could arrange for batched processing >> without removing any sense of real time computation. Perhaps this is your >> point? In order to guarantee non-conflicting computation, it is necessary to >> batch all computations together on single centralized server performing all >> computations "simultaneously". > [PT] Batch processing simply means processing multiple requests together. > This is a PCE feature and PCCs have no knowledge or control over it. PCE > may choose to wait to receive multiple requests, or the case that makes more > sense is PCE is busy with a task at hand, and once done there are one or > more requests in the queue, and PCE processes them together. So, it is > invisible to PCC. Sure, PCE could operate in this way. And PCC could chhose not to issue the second request until it has received a response to the first request. So, you see, PCC *can* exercise control over this function. >> But, our point is that even this does not guarantee LSP establishment. The >> sentence after the one you quote says... >> However, a single, centralized >> PCE is not viewed as a solution that can guarantee TE LSP >> establishment since the potential for network failures or contention >> for resources still exists where the centralized TED cannot fully >> reflect current (i.e., real-time) network state. >> >> So I don't think your proposed solution is *the* fundamental solution. > [PT] well we are not talking about going to the moon, so when I say > fundamental I mean -the- best algorithmic solution given all the existing > requests at the time- any path computation result is of course subject to > blocking. Now, beyond the choice of words: > > The text is about computing two or more paths, which could happen in > response to requests by one or more PCCs. One PCC may make multiple path > computation requests for different source-destination pairs (different > sources could be different starting interfaces on the same node for > example). The ability to process these requests together (flow-based > computation) is -the- best solution. Even in case the requests arrive from > multiple PCCs, batch processing is indeed the best solution to the problem > described here, and if we want to hint at any solution we should at least > mention the best one. > > So, here's a shot at the paragraph, which actually sits nice with the > second part: "Batch processing of all requests, back-off times, computing > alternate paths, and crankback can help to mitigate this sort of problem, > and PCE may also improve the chances of successful TE LSP setup. However, a > single, centralized PCE is not viewed as a solution that can guarantee TE > LSP establishment since the potential for network failures or contention for > resources still exists where the centralized TED cannot fully reflect > current (i.e., real-time) network state." Yes. >>> 2- We need to exapnd this part. Cooperation between PCEs >>> can take one of two forms, which we refer to as model-based and >>> ad hoc. >>> In model-based cooperation (the case described here), PCEs have >>> information on other domains (aggregate or detailed, available a >>> priori or upon request), and the path (or a section of the path) is >>> decided by one PCE at the end. >>> There is another way the PCEs can cooperate, where they do not >>> share any information, and they find the end-to-end path in an ad >>> hoc fashion (similar to DSR). In this case, we have a distributed >>> path computation. >> >> In your second case, how is the route known by the PCC? Isn't it the case >> that the PCEs share the computed route fragments? > > [PT] Yes and no- they share route fragments, but these fragments are not > limited to each domain , rather they end at destination. Suggest looking at > DSR ad hoc routing. With -zero- topology information shared between PCEs, a > complete end-to-end path can be computed in a distributed fashion. This sounds like we're going round in circles. Recall, we are in section 5.4 (Multiple PCE Path Computation with Inter-PCE Communication). You imply that the model described assumes that "PCEs have information on other domains (aggregate or detailed) availabel a priori or upon request." This is not the case. I think you are confused by the text... Multiple PCE path computation with inter-PCE communication involves coordination between distinct PCEs such that the result of the computation performed by one PCE depends on information supplied by other PCEs. You assume that the "information supplied" is TE information. But it doesn't say that. Perhaps we should clarify what this information is since it is less than clear. We will update this to indicate that the information is "path fragment information". But maybe you will still class this as aggregate TE information and say that this is model-based cooperation. That's OK, but let's look at where ad hoc routing fits in. There are two cases: 1. The routing progresses in step with the signaling. That is, each segment is computed and signaled, then the next segment is computed and signaled, and so on. In this case the each PCE is invoked independently and there is no cooperation or communication between PCEs. This is the model shown in section 5.3. 2. The alternative is that all of the routing is done before any signaling is started. In this case, each PCE computes a segment of the path and passes the request on to the next PCE to compute the next segment. The segment paths are returned to the initial PCE which is able to pass the full path to the PCC. But this is exactly the case described in 5.4. Clearly there are variables. - Does the initial PCE send requests to more than one other PCE? - Does the initial PCE suggest multiple border nodes? - Do the downstream PCEs return multiple paths with different qualities to allow the initial PCE to choose? If the answer to these and other questions is "no" then you have ad hoc routing. >>> - Section 6.3: "Conversely, the PCC may issue a single request to >>> the PCE asking for all of the paths to be computed in a synchronized >>> manner. The PCE will then perform simultaneous computation of the >>> set of requested path. Such synchronized computation can often >>> provide more optimal results." >>> The distinction is clearly important in computation and algorithms, >>> however, this is not an attribute that can be exposed to or requested >>> by the user - user should have a more descriptive requirement (e.g., >>> two full disjoint paths with total cost of less than x - how the answer >>> is derived, through simultaneous or sequential processing is not >>> something the user should ask for (it is like the user asks for Dijkstra's >>> algorithm to be used). >> >> When you say "user" do you mean the PCC? >> >> In the first instance the PCC MUST be responsible for this level of >> determinism. That is, if it makes two separate requests for paths, >> simultaneous computation cannot be performed. But nevertheless the requests >> would be valid... >> 1. Compute me a path from A to B with least cost. >> 2. Compute be a path from A to B that is disjoint from the previous path >> and which has least cost. >> >> Thus, the PCC already has some control over whether simultaneous >> computation is requested. > [PT] Not true. As described above PCE may choose to batch process the > requests and process these two requests (and possibly many more in the > queue) together. We should not assume any correlation between how the > requests are sent and how they are processed. With respect, this is tosh. If I send request number one and do not send request number two until I see the response to request number one then I have complete control over the requests being processed separately and the PCE (unless psychic) cannot do anything about it. I think you have this on its head and should re-read 6.3. Here you will find that the PCC does not have the power to force the PCE to process requests separately except by withholding the subsequent requests. OTOH the PCC does have the power to require that the PCE process requests simultaneously. The middle option is that the PCC can say that the PCE is free to process the requests separately if it chooses. > Therefore, the starting > paragraph in Section 6.3 also needs to be modified, as multiple PCC requests > does not necessarily mean non-synchronized path computation (unless > explicitly requested, which we'll address in the next bullet). OK. I can change "will" to "may" to read... In this case of non-synchronized path computation, the PCE may make multiple individual path computations to generate the paths and the >> Now, many people have told us that they *do* want to be able to specify >> which algorithm is used. And this may be very valid because cheap (small, >> local, easily accessed) PCEs might not be able to perform simultaneous >> computation of very many paths at the same time. It would then be necessary >> for these PCEs to reject the request (so that the PCC could redirect it to a >> more sophisticated PCE) or redirect the request itself. > > [PT] This is a sad point that kills the black box elegance of this work. > What happens if I come up with a modified or original algorithm in my PCE > that outperforms existing algorithms? What if you do? 1. I do not have to exert control, just because I have control. I can leave the choice to the PCE. 2. However, if I don't trust your new algorithm, I should be able to select a different one. In reality all algorithms have positive and negative points. - Some are more accurate at the cost of being slower - Some optimise for one feature ahead of other features - Some are newly developed and untrusted - Some work poorly in certain network contditions To say that the user is unable to select the algorithm, is like saying that the user is not allowed to set the constraints. > It may never get called because its > algorithm is not listed in the PCC list of algorithms. Since this is a > dangerous issue, let's be clear: Algorithm opacity is fundamental to the > value of this work, and if someone is interested in specifying an algorithm, > they are in fact interested in one or more high-level requirements that are > addressed by that algorithm. These high-level requirements can be negotiated > at the time of discovery, which is a much better time than in the middle of > making a request and getting disappointed by a cheap PCE. I suggest we spell > this out in the document. I think it is late to revisit this argument. However, if the WG wants to change its mind, I guess that's fine. Anyone else want to support Payam on this point? > So, is synchronized vs. non-synchronized an algorithmic requirement, or a > high-level requirement? My view is that it is a (poorly defined) algorithmic > requirement. I can think of a high-level requirement but believe it is > outside the scope (e.g., total cost should be within x% of the solution that > is found by processing n requests at the same time). Hmmm. Suppose I set up an unprotected service. Now I change the service to desire protection. This can only be achieved by non-synchronized computation (unless I always assume that all services might one day need all features!) But, again, I think you have it on its head. The requirement that is presented in the draft is that the PCC must be able to constrin the PCE to do synchronized computation. That is, the PCC must be able to say "I know this is more work for you, and I know it will chew up your CPU, and I know it requires you to implement a more clever algorithm, but I insist that you use synchronized computation because I want the better quality result that will be produced." > The point is we should drop the whole idea of asking for synchronized or > non-synchronized computation. The better approach is to have the PCC learn > the PCE capabilities at the time of discovery and decide not to choose a PCE > because it cannot satisfy a more high-level requirement. And how will you describe the PCC capabilities? Presumably you will indicate that the PCE can or cannot perform synchronized computation. But suppose a PCE says "I can do fast unsynchronized computation, or slow synchronized computation" That is, the PCE has two algorithms available. So the PCC chooses this PCE to service its request. How will the PCE know which algorithm to use? > > - Section 6.6: Perhaps reliability instread of level of robustness? > > Oooh! > > Having spent some time with Mr. Webster, I conclude that Reliable and > Robust are adequate synonyms. > [PT] Sorry about being picky for certain words, but there are tons of > material on assigning reliability functions (standard term in reliability > engineering with clear definition based on the resource failure rate and > resource age) to network elements/resources, and using reliability as a > metric in path computation- Suggest you do a search for "computing the most > reliable path". You are welcome to be picky about the use of English; I am all the time. Will you settle for the text suggested to Dimitri... - the levels of resiliency, reliability and robustness of the path resources Cheers, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jan 04 11:27:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuBTn-0008PT-4C; Wed, 04 Jan 2006 11:27:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuBTl-0008PK-38 for pce@megatron.ietf.org; Wed, 04 Jan 2006 11:27:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23898 for ; Wed, 4 Jan 2006 11:25:58 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuBZG-000718-8r for pce@ietf.org; Wed, 04 Jan 2006 11:32:54 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 04 Jan 2006 11:27:04 -0500 X-IronPort-AV: i="3.99,330,1131339600"; d="scan'208"; a="79360579:sNHT35049600" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k04GQk6V012275; Wed, 4 Jan 2006 11:27:01 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 Jan 2006 11:26:29 -0500 Received: from [192.168.1.101] ([10.86.242.183]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 Jan 2006 11:26:28 -0500 In-Reply-To: <027801c61133$d9646f00$b8849ed9@Puppy> References: <007d01c6111f$50f30500$30fea8c0@NETPTORAB> <027801c61133$d9646f00$b8849ed9@Puppy> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2B5A8A45-553F-45C1-833D-402B76C6B3FB@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Re: Working Group Last call ondraft-ietf-pce-architecture-03.txt Date: Wed, 4 Jan 2006 11:25:58 -0500 To: Adrian Farrel , Payam Torab X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 04 Jan 2006 16:26:28.0286 (UTC) FILETIME=[9D1E35E0:01C6114B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ba9b8496764663b12c333825fbf6b3d Content-Transfer-Encoding: 7bit Cc: pce@ietf.org, Payam Torab X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, [snip] > >>>> 2- We need to exapnd this part. Cooperation between PCEs >>>> can take one of two forms, which we refer to as model-based and >>>> ad hoc. >>>> In model-based cooperation (the case described here), PCEs have >>>> information on other domains (aggregate or detailed, available a >>>> priori or upon request), and the path (or a section of the path) is >>>> decided by one PCE at the end. >>>> There is another way the PCEs can cooperate, where they do not >>>> share any information, and they find the end-to-end path in an ad >>>> hoc fashion (similar to DSR). In this case, we have a distributed >>>> path computation. >>> >>> In your second case, how is the route known by the PCC? Isn't it the > case >>> that the PCEs share the computed route fragments? >> >> [PT] Yes and no- they share route fragments, but these fragments >> are > not >> limited to each domain , rather they end at destination. Suggest >> looking > at >> DSR ad hoc routing. With -zero- topology information shared between > PCEs, a >> complete end-to-end path can be computed in a distributed fashion. > > This sounds like we're going round in circles. > Recall, we are in section 5.4 (Multiple PCE Path Computation with > Inter-PCE Communication). > > You imply that the model described assumes that "PCEs have > information on > other domains (aggregate or detailed) availabel a priori or upon > request." > This is not the case. I think you are confused by the text... > Multiple PCE path computation with inter-PCE communication involves > coordination between distinct PCEs such that the result of the > computation performed by one PCE depends on information supplied by > other PCEs. > You assume that the "information supplied" is TE information. But it > doesn't say that. Perhaps we should clarify what this information > is since > it is less than clear. > We will update this to indicate that the information is "path fragment > information". Agree, Adrian, this should be clarified since this is apparently not clear. Payam, in the case of inter-Provider it is more than likely that no TE information will be shared at all but rather computed (loose) path along with their respective cost. > > But maybe you will still class this as aggregate TE information and > say > that this is model-based cooperation. That's OK, but let's look at > where > ad hoc routing fits in. There are two cases: > 1. The routing progresses in step with the signaling. That is, each > segment > is computed and signaled, then the next segment is computed and > signaled, and so on. In this case the each PCE is invoked > independently > and there is no cooperation or communication between PCEs. This is > the model shown in section 5.3. > 2. The alternative is that all of the routing is done before any > signaling > is > started. In this case, each PCE computes a segment of the path and > passes the request on to the next PCE to compute the next segment. > The segment paths are returned to the initial PCE which is able to > pass the full path to the PCC. > But this is exactly the case described in 5.4. > Clearly there are variables. > - Does the initial PCE send requests to more than one other PCE? > - Does the initial PCE suggest multiple border nodes? > - Do the downstream PCEs return multiple paths with different > qualities to allow the initial PCE to choose? > If the answer to these and other questions is "no" then you > have ad > hoc > routing. > Payam, does this explanation close the point ? >>>> - Section 6.3: "Conversely, the PCC may issue a single request to >>>> the PCE asking for all of the paths to be computed in a >>>> synchronized >>>> manner. The PCE will then perform simultaneous computation of the >>>> set of requested path. Such synchronized computation can often >>>> provide more optimal results." >>>> The distinction is clearly important in computation and algorithms, >>>> however, this is not an attribute that can be exposed to or >>>> requested >>>> by the user - user should have a more descriptive requirement >>>> (e.g., >>>> two full disjoint paths with total cost of less than x - how the > answer >>>> is derived, through simultaneous or sequential processing is not >>>> something the user should ask for (it is like the user asks for > Dijkstra's >>>> algorithm to be used). >>> >>> When you say "user" do you mean the PCC? >>> >>> In the first instance the PCC MUST be responsible for this level of >>> determinism. That is, if it makes two separate requests for paths, >>> simultaneous computation cannot be performed. But nevertheless the > requests >>> would be valid... >>> 1. Compute me a path from A to B with least cost. >>> 2. Compute be a path from A to B that is disjoint from the >>> previous > path >>> and which has least cost. >>> >>> Thus, the PCC already has some control over whether simultaneous >>> computation is requested. >> [PT] Not true. As described above PCE may choose to batch process the >> requests and process these two requests (and possibly many more in >> the >> queue) together. We should not assume any correlation between how the >> requests are sent and how they are processed. > > With respect, this is tosh. > If I send request number one and do not send request number two > until I > see the response to request number one then I have complete control > over > the requests being processed separately and the PCE (unless psychic) > cannot do anything about it. > > I think you have this on its head and should re-read 6.3. > Here you will find that the PCC does not have the power to force > the PCE > to process requests separately except by withholding the subsequent > requests. > OTOH the PCC does have the power to require that the PCE process > requests > simultaneously. > The middle option is that the PCC can say that the PCE is free to > process > the requests separately if it chooses. Fully agree, as pointed out in my previous email. > >> Therefore, the starting >> paragraph in Section 6.3 also needs to be modified, as multiple PCC > requests >> does not necessarily mean non-synchronized path computation (unless >> explicitly requested, which we'll address in the next bullet). > > OK. I can change "will" to "may" to read... > In this case of non-synchronized path computation, the PCE may make > multiple individual path computations to generate the paths and the > ok >>> Now, many people have told us that they *do* want to be able to >>> specify >>> which algorithm is used. And this may be very valid because cheap > (small, >>> local, easily accessed) PCEs might not be able to perform >>> simultaneous >>> computation of very many paths at the same time. It would then be > necessary >>> for these PCEs to reject the request (so that the PCC could >>> redirect it > to a >>> more sophisticated PCE) or redirect the request itself. >> >> [PT] This is a sad point that kills the black box elegance of this >> work. >> What happens if I come up with a modified or original algorithm in my > PCE >> that outperforms existing algorithms? > > What if you do? > > 1. I do not have to exert control, just because I have control. I can > leave the choice to the PCE. > 2. However, if I don't trust your new algorithm, I should be able to > select a different one. > > In reality all algorithms have positive and negative points. > - Some are more accurate at the cost of being slower > - Some optimise for one feature ahead of other features > - Some are newly developed and untrusted > - Some work poorly in certain network contditions > > To say that the user is unable to select the algorithm, is like saying > that the user is not allowed to set the constraints. > See previous email. >> It may never get called because its >> algorithm is not listed in the PCC list of algorithms. Since this >> is a >> dangerous issue, let's be clear: Algorithm opacity is fundamental >> to the >> value of this work, and if someone is interested in specifying an > algorithm, >> they are in fact interested in one or more high-level requirements >> that > are >> addressed by that algorithm. These high-level requirements can be > negotiated >> at the time of discovery, which is a much better time than in the >> middle > of >> making a request and getting disappointed by a cheap PCE. I >> suggest we > spell >> this out in the document. > > I think it is late to revisit this argument. > > However, if the WG wants to change its mind, I guess that's fine. > > Anyone else want to support Payam on this point? > >> So, is synchronized vs. non-synchronized an algorithmic >> requirement, or > a >> high-level requirement? My view is that it is a (poorly defined) > algorithmic >> requirement. I can think of a high-level requirement but believe >> it is >> outside the scope (e.g., total cost should be within x% of the >> solution > that >> is found by processing n requests at the same time). > > Hmmm. > Suppose I set up an unprotected service. > Now I change the service to desire protection. > This can only be achieved by non-synchronized computation (unless I > always > assume that all services might one day need all features!) > > But, again, I think you have it on its head. The requirement that is > presented in the draft is that the PCC must be able to constrin the > PCE to > do synchronized computation. That is, the PCC must be able to say > "I know > this is more work for you, and I know it will chew up your CPU, and > I know > it requires you to implement a more clever algorithm, but I insist > that > you use synchronized computation because I want the better quality > result > that will be produced." > In sync with Adrian as per my previous email. >> The point is we should drop the whole idea of asking for >> synchronized or >> non-synchronized computation. The better approach is to have the PCC > learn >> the PCE capabilities at the time of discovery and decide not to >> choose a > PCE >> because it cannot satisfy a more high-level requirement. > > And how will you describe the PCC capabilities? Presumably you will > indicate that the PCE can or cannot perform synchronized computation. > > But suppose a PCE says "I can do fast unsynchronized computation, > or slow > synchronized computation" That is, the PCE has two algorithms > available. > So the PCC chooses this PCE to service its request. How will the > PCE know > which algorithm to use? Note that this belongs to the requirements IDs ... To be discussed in this context. > >>> - Section 6.6: Perhaps reliability instread of level of robustness? >> >> Oooh! >> >> Having spent some time with Mr. Webster, I conclude that >> Reliable and >> Robust are adequate synonyms. >> [PT] Sorry about being picky for certain words, but there are >> tons of >> material on assigning reliability functions (standard term in > reliability >> engineering with clear definition based on the resource failure >> rate and >> resource age) to network elements/resources, and using reliability >> as a >> metric in path computation- Suggest you do a search for "computing >> the > most >> reliable path". > > You are welcome to be picky about the use of English; I am all the > time. > > Will you settle for the text suggested to Dimitri... > > - the levels of resiliency, reliability and robustness of the path > resources > Thanks. JP. > Cheers, > Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jan 04 11:36:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuBd9-0002Xh-2O; Wed, 04 Jan 2006 11:36:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuBJf-0004uA-6n for pce@megatron.ietf.org; Wed, 04 Jan 2006 11:16:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22394 for ; Wed, 4 Jan 2006 11:15:32 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuBP7-0006aU-W1 for pce@ietf.org; Wed, 04 Jan 2006 11:22:28 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 04 Jan 2006 11:16:32 -0500 X-IronPort-AV: i="3.99,330,1131339600"; d="scan'208,217"; a="79359005:sNHT65904300" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k04GFu6j009134; Wed, 4 Jan 2006 11:16:27 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 Jan 2006 11:16:23 -0500 Received: from [192.168.1.101] ([10.86.242.183]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 Jan 2006 11:16:20 -0500 In-Reply-To: <007d01c6111f$50f30500$30fea8c0@NETPTORAB> References: <007d01c6111f$50f30500$30fea8c0@NETPTORAB> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 (Normal) Message-Id: <148C4987-2F13-45AC-BEFB-9F127E068150@cisco.com> From: JP Vasseur Subject: Re: [Pce] Re: Working Group Last call ondraft-ietf-pce-architecture-03.txt Date: Wed, 4 Jan 2006 11:15:49 -0500 To: Payam Torab X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 04 Jan 2006 16:16:20.0911 (UTC) FILETIME=[331823F0:01C6114A] X-Spam-Score: 0.6 (/) X-Scan-Signature: bd66cfde135644e4bab6b3fe781c3104 X-Mailman-Approved-At: Wed, 04 Jan 2006 11:36:53 -0500 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0964067625==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============0964067625== Content-Type: multipart/alternative; boundary=Apple-Mail-18--829639922 --Apple-Mail-18--829639922 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi, On Jan 4, 2006, at 6:09 AM, Payam Torab wrote: > Thanks Adrian- I snipped the resolved parts. See inline for the rest. > Payam > > - Document title: We know this document does not intend to > describe the > > architecture of a PCE- A title such as "Architectural Framework for > > End-to-End Path Computation using Path Computation Elements" is more > > appropriate. > > - I don't think there is anything here that specifies that the > computed > path must be end-to-end. Quite to the contrary, in fact. > [PT] Every path is end-to-end. Nope, as pointed out in my previous email, a PCE may be responsible for the computation of a path segment. This part of a path is not an end to end path. > What I meant is how we end up at the destination using PCEs, i.e., > how PCEs take us from one end to another. There are many possible ways. One of the possible procedure has been described some time ago in draft-vasseur-ccamp-inter-domain-path- comp-00.txt (Scenario 2) and will be resurrected soon. One can expect separate IDs proposing different models. > > - You are right that the document does not describe the architecture > of a PCE. Rather it describes the architecture of a PCE-based > model. But the title doesn't say it describes the architecture of a > PCE. > > This is such a small point. Do we really need to make a change? > [PT] The current title is "Path Computation Element (PCE) > Architecture", which means the same thing as the architecture of a > PCE. Sorry, this is a wrong title. Now I'm having a struggle myself > finding the right title- based on your input, "Architecture for > Path Computation Using a Path Computation Element (PCE)" is a > better title. This way we also have room if we really want to have > a document on PCE architecture. I'll follow up on the list on the proposal ... trying to quickly converge here. > > - Section 4.3: In case the TED is supplemented through > configuration or > > management plane, how do we deal with the address space? Does the > TED use IP > > addresses as identifiers? Yes and no answers deserve to be > discussed here. > > I'm not sure I understand your question. The TED can use whatever > identifiers it finds convenient. The only requirement is that the > output should be useable by the PCC to generate signaling messages, > and that the input could be generated from information taken from > the IGP-TE. Both of these operations could utilise a mapping function. > > Is there some specific case underlying your question? > [PT] PCE is bringing together path computation functionalities in > management plane and control plane. I was concerned about the > identifiers used for network elements which do and do not have a > control plane. As long as these IDs are assigned from the same pool > we are fine. This is almost always the case (NMS assigning > addresses to all elements), but I thought we need to mention that. > Note this is the first time a common database TED is allowed to be > supplemented by the two planes. For example, a switched connection > appearing as a link in TED (an FA-LSP for example) needs to have an > Id. How do we make sure this Id is not the same as the Id assigned > to a transport link with no control plane? Not sure to see your point here ... > > Also, suggest adding the fundamental solution > > where the PCE supports batch requests (multiple path computation > requests > > between source and destination pairs) by design, i.e., the > requests are not > > processed sequentially. > > It is hard to see how multiple PCCs could arrange for batched > processing without removing any sense of real time computation. > Perhaps this is your point? In order to guarantee non-conflicting > computation, it is necessary to batch all computations together on > single centralized server performing all computations > "simultaneously". > [PT] Batch processing simply means processing multiple requests > together. This is a PCE feature and PCCs have no knowledge or > control over it. Again, this is not correct. It is fundamental for the PCC to be able to have a control over it, at least for its own set of requests. > PCE may choose to wait to receive multiple requests, or the case > that makes more sense is PCE is busy with a task at hand, and once > done there are one or more requests in the queue, and PCE processes > them together. So, it is invisible to PCC. > > But, our point is that even this does not guarantee LSP > establishment. The sentence after the one you quote says... > However, a single, centralized > PCE is not viewed as a solution that can guarantee TE LSP > establishment since the potential for network failures or > contention > for resources still exists where the centralized TED cannot fully > reflect current (i.e., real-time) network state. > > So I don't think your proposed solution is *the* fundamental solution. > [PT] well we are not talking about going to the moon, so when I say > fundamental I mean -the- best algorithmic solution given all the > existing requests at the time- any path computation result is of > course subject to blocking. Now, beyond the choice of words: > > The text is about computing two or more paths, which could happen > in response to requests by one or more PCCs. One PCC may make > multiple path computation requests for different source-destination > pairs (different sources could be different starting interfaces on > the same node for example). The ability to process these requests > together (flow-based computation) is -the- best solution. Even in > case the requests arrive from multiple PCCs, batch processing is > indeed the best solution to the problem described here, and if we > want to hint at any solution we should at least mention the best one. Quite frankly I do not think that the discussion on the optimality of the so called global optimization and local optimization belongs to this ID at all. In this case, even in the case of global optimization you could also discuss many different algorithms ... Again, does not belong to this ID. > > So, here's a shot at the paragraph, which actually sits nice with > the second part: "Batch processing of all requests, back-off times, > computing alternate paths, and crankback can help to mitigate this > sort of problem, and PCE may also improve the chances of successful > TE LSP setup. However, a single, centralized PCE is not viewed as a > solution that can guarantee TE LSP establishment since the > potential for network failures or contention for resources still > exists where the centralized TED cannot fully reflect current > (i.e., real-time) network state." Does not hurt to add this text although that sounds pretty obvious ... > > > 2- We need to exapnd this part. Cooperation between PCEs > > can take one of two forms, which we refer to as model-based and > ad hoc. In > > model-based cooperation (the case described here), PCEs have > information on > > other domains (aggregate or detailed, available a priori or upon > request), > > and the path (or a section of the path) is decided by one PCE at > the end. > > There is another way the PCEs can cooperate, where they do not > share any > > information, and they find the end-to-end path in an ad hoc > fashion (similar > > to DSR). In this case, we have a distributed path computation. > > In your second case, how is the route known by the PCC? Isn't it > the case that the PCEs share the computed route fragments? > [PT] Yes and no- they share route fragments, but these fragments > are not limited to each domain , rather they end at destination. > Suggest looking at DSR ad hoc routing. With -zero- topology > information shared between PCEs, a complete end-to-end path can be > computed in a distributed fashion. > > > - Section 6.3: "Conversely, the PCC may issue a single request to > the PCE > > asking for all of the paths to be computed in a synchronized > manner. The PCE > > will then perform simultaneous computation of the set of > requested path. > > Such synchronized computation can often provide more optimal > results." The > > distinction is clearly important in computation and algorithms, > however, > > this is not an attribute that can be exposed to or requested by > the user- > > user should have a more descriptive requirement (e.g., two full > disjoint > > paths with total cost of less than x - how the answer is derived, > through > > simultaneous or sequential processing is not something the user > should ask > > for (it is like the user asks for Dijkstra's algorithm to be used). > > When you say "user" do you mean the PCC? > > In the first instance the PCC MUST be responsible for this level of > determinism. That is, if it makes two separate requests for paths, > simultaneous computation cannot be performed. But nevertheless the > requests would be valid... > 1. Compute me a path from A to B with least cost. > 2. Compute be a path from A to B that is disjoint from the previous > path and which has least cost. > > Thus, the PCC already has some control over whether simultaneous > computation is requested. > [PT] Not true. As described above PCE may choose to batch process > the requests and process these two requests (and possibly many more > in the queue) together. We should not assume any correlation > between how the requests are sent and how they are processed. > Therefore, the starting paragraph in Section 6.3 also needs to be > modified, as multiple PCC requests does not necessarily mean non- > synchronized path computation (unless explicitly requested, which > we'll address in the next bullet). > > Now, many people have told us that they *do* want to be able to > specify which algorithm is used. And this may be very valid because > cheap (small, local, easily accessed) PCEs might not be able to > perform simultaneous computation of very many paths at the same > time. It would then be necessary for these PCEs to reject the > request (so that the PCC could redirect it to a more sophisticated > PCE) or redirect the request itself. > [PT] This is a sad point that kills the black box elegance of this > work. What happens if I come up with a modified or original > algorithm in my PCE that outperforms existing algorithms? It may > never get called because its algorithm is not listed in the PCC > list of algorithms. Since this is a dangerous issue, let's be > clear: Algorithm opacity is fundamental to the value of this work, > and if someone is interested in specifying an algorithm, they are > in fact interested in one or more high-level requirements that are > addressed by that algorithm. These high-level requirements can be > negotiated at the time of discovery, which is a much better time > than in the middle of making a request and getting disappointed by > a cheap PCE. I suggest we spell this out in the document. > The control of the algorithm used by the PCE is entirely optional. On the discovery requirement aspect, you may want to discuss this in the context of draft-ietf-pce-discovery-reqs-02.txt > So, is synchronized vs. non-synchronized an algorithmic > requirement, or a high-level requirement? My view is that it is a > (poorly defined) algorithmic requirement. I can think of a high- > level requirement but believe it is outside the scope (e.g., total > cost should be within x% of the solution that is found by > processing n requests at the same time). > > The point is we should drop the whole idea of asking for > synchronized or non-synchronized computation. Note that this has been discussed quite a few times within the WG with a consensus to be able to request for synchronized or non- synchronized computation (see requirements ID and solution ID). > The better approach is to have the PCC learn the PCE capabilities > at the time of discovery and decide not to choose a PCE because it > cannot satisfy a more high-level requirement. > > > - Section 6.6: Perhaps reliability instread of level of robustness? > Oooh! > > Having spent some time with Mr. Webster, I conclude that Reliable > and Robust are adequate synonyms. > [PT] Sorry about being picky for certain words, but there are tons > of material on assigning reliability functions (standard term in > reliability engineering with clear definition based on the resource > failure rate and resource age) to network elements/resources, and > using reliability as a metric in path computation- Suggest you do a > search for "computing the most reliable path". Thanks. JP. > > --Apple-Mail-18--829639922 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

On Jan 4, = 2006, at 6:09 AM, Payam Torab wrote:

Thanks Adrian- I snipped the resolved parts. See inline for = the rest.
> - Document title: We know this = document does not intend to describe the
> architecture of a PCE- A title = such as "Architectural Framework for
> End-to-End Path Computation = using Path Computation Elements" is more
> = appropriate.
=A0
- I don't think there is anything here that specifies that = the computed
=A0 path must be end-to-end. Quite to the = contrary, in fact.
[PT]=A0Every = path is end-to-end. =
Nope, as pointed out in my previous email, a PCE may be responsible = for the computation of a path segment. This part of a path is not an end = to end path.
What I meant = is how we=A0end up at=A0the destination using PCEs, i.e., how PCEs take = us from one end to = another.
There are many possible ways. One of the possible procedure has = been described some time ago = in=A0draft-vasseur-ccamp-inter-domain-path-comp-00.txt=A0 (Scenario 2) = and will be resurrected soon. One can expect separate IDs proposing = different models.
=A0
- You are right = that the document does not describe the = architecture
=A0 of a PCE. Rather it describes the = architecture of a PCE-based
=A0 model. But the title doesn't say it = describes the architecture=A0of a
=A0 = PCE.
=A0
This is such a small point. Do we really = need to make a change?
[PT]=A0=A0The current title is = "Path Computation = Element (PCE) Architecture", which=A0means the same thing=A0as the = architecture of a PCE. Sorry, this is a wrong title. Now I'm having a = struggle myself finding the right title- based on your input, = "Architecture for Path Computation Using=A0a Path Computation Element = (PCE)" is a better title. This way we also have room if we really want = to have a document on PCE = architecture.=A0
I'll follow up on the list on the proposal = ... trying to quickly converge here.
> - Section 4.3: In case the TED is = supplemented through configuration or
> management = plane, how do we deal with the address space? Does the TED use = IP
> addresses as identifiers? Yes and no answers deserve to = be discussed here.
=A0
I'm not sure I understand your question. The TED can use = whatever identifiers it finds convenient. The only requirement is that = the output should be useable by the PCC to generate signaling messages, = and that the input could be generated from information taken from the = IGP-TE. Both of these operations could utilise a mapping = function.
=A0
Is there some specific case underlying = your question?
[PT]=A0PCE = is bringing together path computation functionalities in management = plane and control plane. I=A0was concerned=A0about the identifiers used = for network elements=A0which do and do not have a=A0control plane. As = long as these IDs are assigned from the same pool we are fine. This is = almost always the case (NMS assigning addresses to all elements), but I = thought we need to mention that. Note this is the first time a common = database TED is allowed to be supplemented by the two planes. For = example, a switched connection appearing as a link in TED (an FA-LSP for = example) needs to have an Id. How do we make sure this Id is not the = same as=A0the Id assigned to a transport link=A0with no control = plane?
Not sure to see your point here ...

Also, suggest = adding the fundamental solution
> where the PCE = supports batch requests (multiple path computation requests
> between source and destination pairs) by design, i.e., = the requests are not
> processed = sequentially.
=A0
It is hard to see how multiple PCCs could arrange for=A0batched= processing without removing any sense of real time computation. Perhaps = this is your point? In order to guarantee non-conflicting computation, = it is necessary to batch all computations together on single centralized = server performing all computations "simultaneously".
[PT]=A0Batch = processing=A0simply means processing multiple requests together. This is = a PCE feature and PCCs have=A0no knowledge or control over it. =
Aga= in, this is not correct. It is fundamental for the PCC to be able to = have a control over it, at least for its own set of = requests.
PCE may = choose to wait to receive multiple requests, or the case that makes more = sense is PCE is busy with a task at hand, and once done there are=A0one = or more requests in the queue, and PCE processes them together. So, it = is invisible to=A0PCC.=A0
=A0
But, our point is that even this does not guarantee LSP = establishment. The sentence after the one you quote = says...
=A0=A0 However, a single, = centralized
=A0=A0 PCE is not viewed as a solution that can = guarantee TE LSP
=A0=A0 establishment since the potential = for network failures or contention
=A0=A0 for = resources still exists where the centralized TED cannot fully
=A0=A0 reflect current (i.e., real-time) network = state.
=A0
So I don't think your proposed solution = is *the* fundamental solution.
[PT]=A0well we are not talking about going to the moon, so = when I say fundamental I mean -the- best algorithmic solution given=A0all = the existing=A0requests at the time- any path computation result is of = course subject to blocking. Now, beyond the choice of = words:
=A0
The text is about computing two or more paths, which could = happen in response to requests by one or more PCCs. One=A0PCC=A0may make = multiple path computation requests=A0for different source-destination = pairs (different sources could be different starting interfaces on the = same node for=A0example). The ability to process these requests = together=A0(flow-based computation) is -the-=A0best solution. = Even in case = the requests arrive from multiple PCCs,=A0batch processing=A0is indeed = the=A0best solution to the problem described here, and if=A0we want = to=A0hint at=A0any solution=A0we should at least mention the=A0best = one.
Qui= te frankly I do not think that the discussion on the optimality of the = so called global optimization and local optimization belongs to this ID = at all. In this case, even in the case of global optimization you could = also discuss many different algorithms ... Again, does not belong to = this ID.
=A0
So, here's a shot at the paragraph, which actually sits nice = with the second part: "Batch processing of all requests, back-off times, = computing alternate paths, and crankback can help to mitigate this sort = of problem, and PCE may also improve the chances of successful TE LSP = setup. However, a single, centralized PCE is not viewed as a solution = that can guarantee TE LSP establishment since the potential for network = failures or contention for resources still exists where the centralized = TED cannot fully reflect current (i.e., real-time) network = state."
Does not hurt to add this text although that sounds pretty = obvious ...=A0

>=A02- We need to exapnd this part. Cooperation between = PCEs
> can take one of two forms, which we refer to = as model-based and ad hoc. In
> model-based = cooperation (the case described here), PCEs have information = on
> other domains (aggregate or detailed, available a priori = or upon request),
> and the path (or a section of the = path) is decided by one PCE at the end.
> There is = another way the PCEs can cooperate, where they do not share = any
> information, and they find the end-to-end path in an ad = hoc fashion (similar
> to DSR). In this case, we have a = distributed path computation.
=A0
In your second = case, how is the route known by the PCC? Isn't it the case that the PCEs = share the computed route fragments?
[PT]=A0Yes and no- they share route fragments, but=A0these = fragments=A0are not limited to each domain , rather they end = at=A0destination.=A0Suggest looking at DSR ad hoc routing. With -zero- = topology information shared between PCEs, a complete end-to-end path can = be computed=A0in a distributed = fashion.=A0

> - Section 6.3: = "Conversely, the PCC may issue a single request to the PCE
> asking for all of the paths to be computed in a = synchronized manner. The PCE
> will then = perform simultaneous computation of the set of requested path.
> Such synchronized computation can often provide more = optimal results." The
> distinction is = clearly important in computation and algorithms, however,
> this is not an attribute that can be exposed to or = requested by the user-
> user should = have a more descriptive requirement (e.g., two full disjoint
> paths with total cost of less than x - how the answer is = derived, through
> simultaneous or sequential = processing is not something the user should ask
> for (it is like the user asks for Dijkstra's algorithm = to be used).
When you say "user" do you mean the = PCC?
=A0
In the first instance the PCC MUST be = responsible for this level of determinism. That is, if it makes two = separate requests for paths, simultaneous computation cannot be = performed. But nevertheless the requests would be = valid...
1. Compute me a path from A to B with = least cost.
2. Compute be a path from A to B that is = disjoint from the previous path and which has least = cost.
=A0
Thus, the PCC already has some control = over whether simultaneous computation is requested.
[PT]=A0Not = true. As described above PCE may choose to=A0batch process the requests = and process these two requests (and possibly many more in the queue) = together.=A0We should not assume any correlation between how the = requests are=A0sent=A0and how they are processed. Therefore, the = starting paragraph in Section 6.3 also needs to be modified, as multiple = PCC requests does not necessarily mean non-synchronized path computation = (unless explicitly requested, which we'll address in the next = bullet).
=A0
Now, many people have told us that they *do* want to be able = to specify which algorithm is used. And this may be very valid because = cheap (small, local, easily accessed) PCEs might not be able to perform = simultaneous computation of very many paths at the same time. It would = then be necessary for these PCEs to reject the request (so that the PCC = could redirect it to a more sophisticated PCE) or redirect the request = itself.
[PT]=A0This is a=A0sad point that kills the black box = elegance=A0of this work. What happens if I come up with a modified = or=A0original algorithm in my PCE that outperforms=A0existing = algorithms?=A0It may=A0never get called because its algorithm is not = listed in=A0the PCC list of algorithms. Since this is a dangerous issue, = let's be clear: Algorithm opacity is fundamental to the value of this = work, and if someone is interested in specifying an algorithm, they are = in fact interested in one or more high-level requirements that=A0are = addressed by that algorithm. These high-level requirements can be = negotiated at the time of discovery, which is a much better time than in = the middle of making a request and getting disappointed by a cheap = PCE.=A0I suggest we spell this out in the = document.
So, is synchronized vs. non-synchronized = an algorithmic requirement, or a high-level requirement?=A0My view is = that it is a (poorly defined) algorithmic requirement. I can think of a = high-level requirement=A0but believe it is outside the scope=A0(e.g., = total cost should be within x% of the solution that is found by = processing=A0n requests at the same = time).
The point is we should drop the whole idea of asking for = synchronized or non-synchronized = computation.=A0
<= /BLOCKQUOTE>Note that this has been discussed quite a few times within = the WG with a consensus to be able to request for synchronized or = non-synchronized computation (see requirements ID and solution = ID).
The better approach=A0is to have the = PCC=A0learn the PCE capabilities at the time of discovery and decide not = to choose a PCE because it cannot satisfy a more high-level = requirement.
> - Section 6.6: Perhaps reliability = instread of level of robustness?
=A0
Having spent some time with Mr. Webster, = I conclude that Reliable and Robust are adequate = synonyms.
[PT]=A0Sorry about being picky for certain words, but there = are tons of material on assigning=A0reliability functions (standard term = in reliability engineering=A0with=A0clear definition based on = the=A0resource failure rate and resource age)=A0to network = elements/resources,=A0and using reliability as a metric in path = computation- Suggest you do a search for "computing the most reliable = path".
Thanks.
<= BR class=3D"khtml-block-placeholder">
JP.


= --Apple-Mail-18--829639922-- --===============0964067625== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0964067625==-- From pce-bounces@lists.ietf.org Wed Jan 04 11:36:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuBd9-0002Y6-OX; Wed, 04 Jan 2006 11:36:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuBLW-0005PF-Nv for pce@megatron.ietf.org; Wed, 04 Jan 2006 11:18:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22665 for ; Wed, 4 Jan 2006 11:17:28 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuBR0-0006gO-4p for pce@ietf.org; Wed, 04 Jan 2006 11:24:24 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 04 Jan 2006 07:57:52 -0800 X-IronPort-AV: i="3.99,330,1131350400"; d="scan'208,217"; a="387283947:sNHT1340838600" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k04FvpQi005120; Wed, 4 Jan 2006 07:57:51 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 Jan 2006 10:57:51 -0500 Received: from [192.168.1.101] ([10.86.242.183]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 Jan 2006 10:57:49 -0500 In-Reply-To: <017901c610aa$b6c1b270$b8849ed9@Puppy> References: <2DD8AA26-799C-43D4-ABA7-615D5396EB11@cisco.com> <017901c610aa$b6c1b270$b8849ed9@Puppy> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 Message-Id: <8C6415C8-71A8-4842-8794-B970F8D4B20A@cisco.com> From: JP Vasseur Subject: Re: [Pce] Re: Working Group Last call ondraft-ietf-pce-architecture-03.txt Date: Wed, 4 Jan 2006 10:57:18 -0500 To: Adrian Farrel , ptorab@lopsys.com X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 04 Jan 2006 15:57:49.0279 (UTC) FILETIME=[9C828EF0:01C61147] X-Spam-Score: 0.2 (/) X-Scan-Signature: 5111b5a9ab7dba405901980ae5cc17e9 X-Mailman-Approved-At: Wed, 04 Jan 2006 11:36:54 -0500 Cc: pce@ietf.org, Payam Torab X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1191433257==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============1191433257== Content-Type: multipart/alternative; boundary=Apple-Mail-17--830750786 --Apple-Mail-17--830750786 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi, Thanks Payam for the comments. On Jan 3, 2006, at 4:13 PM, Adrian Farrel wrote: > Hi Payam, > > Thanks for your interest in this document. > > Responses in line. > > Cheers, > Adrian > > > Hi JP and others- > > Here are some comments, suggestions and questions. > > Thanks, > > Payam > > ------ > > > > - Document title: We know this document does not intend to > describe the > > architecture of a PCE- A title such as "Architectural Framework for > > End-to-End Path Computation using Path Computation Elements" is more > > appropriate. > > I think I disagree. There are a couple of points. > - Architecture and Framework have meanings established by usage > within the IETF (in fact the PCE WG has already been around the > houses once discussing whether to use "architecture" or > "framework"). > The document as it stands describes an architecture. > - I don't think there is anything here that specifies that the > computed > path must be end-to-end. Quite to the contrary, in fact. > - You are right that the document does not describe the architecture > of a PCE. Rather it describes the architecture of a PCE-based > model. But the title doesn't say it describes the architecture of a > PCE. > > This is such a small point. Do we really need to make a change? > Since this point has already been raised, we may want to change the title for something like "A PCE-based architecture model" ? On the other comment I agree with Adrian, there is no assumption on whether the computed path must be end to end. For the sake of illustration, there could be a end-to-end TE LSP spanning multiple domains where path segments are computed using various techniques. > > - Section 3 (Definitions): "Inter-domain path computation may > involve the > > correlation of topology, routing and policy information between > domains." > > What exactly do you mean by correlation? More descriptive text is > needed > > here, may be an example. > > Hmmm. I guess that by "correlation" we meant that there may be a > need to bring together in mutual realtionship the topology, routing > and policy information that exists in the separate domains. I > suppose an example would be that in order to perform inter-domain > path computation we might need to pull together routing information > from both domains. > > I'm sturggling to find a way to say this different from what I > typed. Maybe someone else can suggest some text. > Looks clear enough to me ... > > - Section 4.3: In case the TED is supplemented through > configuration or > > management plane, how do we deal with the address space? Does the > TED use IP > > addresses as identifiers? Yes and no answers deserve to be > discussed here. > > I'm not sure I understand your question. The TED can use whatever > identifiers it finds convenient. The only requirement is that the > output should be useable by the PCC to generate signaling messages, > and that the input could be generated from information taken from > the IGP-TE. Both of these operations could utilise a mapping function. > > Is there some specific case underlying your question? > > > - Section 4.9.2: "Back-off times, alternate path computations, > and crankback > > can help to mitigate this sort of problem, and PCE may also > improve the > > chances of successful TE LSP setup." Suggest "computation of > alternate > > paths" to avoid ambiguity. > > Yes. > > > Also, suggest adding the fundamental solution > > where the PCE supports batch requests (multiple path computation > requests > > between source and destination pairs) by design, i.e., the > requests are not > > processed sequentially. > > It is hard to see how multiple PCCs could arrange for batched > processing without removing any sense of real time computation. > Perhaps this is your point? In order to guarantee non-conflicting > computation, it is necessary to batch all computations together on > single centralized server performing all computations > "simultaneously". > > But, our point is that even this does not guarantee LSP > establishment. The sentence after the one you quote says... > However, a single, centralized > PCE is not viewed as a solution that can guarantee TE LSP > establishment since the potential for network failures or > contention > for resources still exists where the centralized TED cannot fully > reflect current (i.e., real-time) network state. > > So I don't think your proposed solution is *the* fundamental solution. > > > - Section 5.4: "Multiple PCE path computation with inter-PCE > communication > > involves coordination between distributed PCEs such that the > result of the > > computation performed by one PCE depends on information supplied > by other > > PCEs. This model does not provide a distributed computation > algorithm, but > > allows distinct PCEs to be responsible for computation of parts > (segments) > > of the path." > > 1- I believe you mean different or distinct PCEs instead of > distributed PCEs. > > Yes. > > > 2- We need to exapnd this part. Cooperation between PCEs > > can take one of two forms, which we refer to as model-based and > ad hoc. In > > model-based cooperation (the case described here), PCEs have > information on > > other domains (aggregate or detailed, available a priori or upon > request), > > and the path (or a section of the path) is decided by one PCE at > the end. > > There is another way the PCEs can cooperate, where they do not > share any > > information, and they find the end-to-end path in an ad hoc > fashion (similar > > to DSR). In this case, we have a distributed path computation. > > In your second case, how is the route known by the PCC? Isn't it > the case that the PCEs share the computed route fragments? > > > - Figure 5: Suggest adding a link between NMS and TED to show > alternate ways > > for synchronization (the TED synchronization arrow does not > suggest a > > possible link to NMS). > > Yeah, probably. The text covers this pretty well, however. > Actually, we debated removing the TED synchronization arrows as > beyond the scope of PCE. > > > - Section 6.3: Synchronization is a bad term for this section. You > > definitely are not suggesting we compute paths based on a > synchronized > > global clock ;) Suggest "Simultaneous path computation" for the > section > > title, "simultaneous processing of path computation requests" for > > "synchronized path computation", and "sequential processing of path > > computation requests" for "non-synchronized path computation" > > Synchronization is from the verb, to synchronize. > Synchorinze - to make synchronous > Synchronous - happening at the same time; occurring together; > simultaneous > > So I don't see that changing "synchronized" for "simultaneous" has > any gain. > > In fact, in the third paragraph we use both "synchronized" and > "simultaneous" to make double sure that we are understood. > > > - Section 6.3: Suggest "better" or "closer to optimal" instead of > "more > > optimal". > > Agreed. > > > - Section 6.3: "The involvement of more than one PCE in the > computation of a > > series of paths is by its nature non-synchronized. However, a set of > > cooperating PCEs may be synchronized under the control of a > single PCE. For > > example, a PCC may send a request to a PCE which invokes domain- > specific > > computations by other PCEs before supplying a result to the PCC." > Can you > > elaborate here? > > Well, consider four domains: > B > / \ > A D > \ / > C > > > A PCC in domain A may request a pair of diverse paths from an > ingress in domain A to an egress in domain B. > > Let us assume that there are multiple domain border nodes between > domains B and D, but between no other domains. > > The PCE for domain A may request paths from the domains B and C. > The PCE for domain B may return several candidate paths. The PCE > for domain A will now request paths through domain D to the egress > and considering the entry points into domain D from domains B and C. > > Once the results are in, the PCE for domain A can select a pair of > disjoint paths. (Disjointedness being necessary in domains A and D). > > HOWEVER, this example of how one might decompose a request is > entirely implementation-specific. There are other applicabilities > of PCE cooperation that might achieve this differently. > > > > - Section 6.3: "Conversely, the PCC may issue a single request to > the PCE > > asking for all of the paths to be computed in a synchronized > manner. The PCE > > will then perform simultaneous computation of the set of > requested path. > > Such synchronized computation can often provide more optimal > results." The > > distinction is clearly important in computation and algorithms, > however, > > this is not an attribute that can be exposed to or requested by > the user- > > user should have a more descriptive requirement Clearly, it is since the PCC would stipulate the requirement for simultaneous computations in its request. See for example the set of mechanisms specified in PCEP. > (e.g., two full disjoint > > paths with total cost of less than x - how the answer is derived, > through > > simultaneous or sequential processing is not something the user > should ask > > for (it is like the user asks for Dijkstra's algorithm to be used). > > When you say "user" do you mean the PCC? > > In the first instance the PCC MUST be responsible for this level of > determinism. That is, if it makes two separate requests for paths, > simultaneous computation cannot be performed. But nevertheless the > requests would be valid... > 1. Compute me a path from A to B with least cost. > 2. Compute be a path from A to B that is disjoint from the previous > path and which has least cost. > > Thus, the PCC already has some control over whether simultaneous > computation is requested. > > Now, many people have told us that they *do* want to be able to > specify which algorithm is used. And this may be very valid because > cheap (small, local, easily accessed) PCEs might not be able to > perform simultaneous computation of very many paths at the same > time. It would then be necessary for these PCEs to reject the > request (so that the PCC could redirect it to a more sophisticated > PCE) or redirect the request itself. > > > - Section 6.6: Perhaps reliability instread of level of robustness? > Oooh! > > This sent me scampering to the CCAMP P&R drafts to find the > definitions of reliable and robust. Unfortunately not there :-( > > Having spent some time with Mr. Webster, I conclude that Reliable > and Robust are adequate synonyms. The reason that I don't like to > use "reliable" is an old networking joke... > > You can rely on our product completely. It fails *every* Tuesday. > > However, I also note that we should include Resilience. So the > bullet now reads... > > - the levels of robustness and resilience of the path resources Thanks. JP. > > --Apple-Mail-17--830750786 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Thanks Payam for the = comments.

On Jan 3, 2006, at 4:13 PM, Adrian = Farrel wrote:

Hi = Payam,
=A0
Thanks for your interest in this = document.
=A0
Responses in line.
=A0
Cheers,
=A0
> Hi JP and others-
> Here are some = comments, suggestions and questions.
> = Thanks,
> Payam
> = ------
>
> - Document = title: We know this document does not intend to describe the
> architecture of a PCE- A title such as "Architectural = Framework for
> End-to-End Path Computation using = Path Computation Elements" is more
> = appropriate.
=A0
I think I disagree. There are a couple of = points.
- Architecture and Framework have meanings established by = usage
=A0=A0within the IETF (in fact the PCE WG has already been = around the
=A0=A0houses once discussing whether to use "architecture" or = "framework").
=A0 The document as it stands describes = an architecture.
- I don't think there is anything here = that specifies that the computed
=A0 path must be = end-to-end. Quite to the contrary, in = fact.
- You are right that the document does not describe the = architecture
=A0 of a PCE. Rather it describes the = architecture of a PCE-based
=A0 model. But the title doesn't say it = describes the architecture=A0of a
=A0 = PCE.
=A0
This is such a small point. Do we really need to make a = change?
=A0

Since this point has = already been raised, we may want to change the title for something like = "A PCE-based architecture model" ?

On the other comment I = agree with Adrian, there is no assumption on whether the computed path = must be end to end. For the sake of illustration, there could be a = end-to-end TE LSP spanning multiple domains where path segments are = computed using various techniques.

> - Section 3 = (Definitions): "Inter-domain path computation may involve the
> correlation of topology, routing and policy information = between domains."
> What exactly do you mean by = correlation? More descriptive text is needed
> here, may be an example.
=A0
Hmmm. I guess that by "correlation" we = meant that there may be a need to bring together in mutual realtionship = the topology, routing and policy information that exists in the separate = domains. I suppose an example would be that in order to perform = inter-domain path computation we might need to pull together routing = information from both domains.
=A0
I'm sturggling to find a way to say this = different from what I typed. Maybe someone else can suggest some = text.
=A0

Looks clear enough to me = ...

> - Section 4.3: = In case the TED is supplemented through configuration or
> management plane, how do we deal with the address space? = Does the TED use IP
> addresses as identifiers? Yes and no = answers deserve to be discussed here.
=A0
I'm not sure I understand your question. = The TED can use whatever identifiers it finds convenient. The only = requirement is that the output should be useable by the PCC to generate = signaling messages, and that the input could be generated from = information taken from the IGP-TE. Both of these operations could = utilise a mapping function.
=A0
Is there some specific case underlying your = question?

> - Section 4.9.2: "Back-off times, = alternate path computations, and crankback
> can help to = mitigate this sort of problem, and PCE may also improve the
> chances of successful TE LSP setup." Suggest = "computation of alternate
> paths" to = avoid ambiguity.
=A0
Yes.
=A0
>=A0Also, suggest adding the fundamental = solution
> where the PCE supports batch requests = (multiple path computation requests
> between source = and destination pairs) by design, i.e., the requests are not
> processed sequentially.
=A0
It is hard to see how multiple PCCs could = arrange for=A0batched processing without removing any sense of real time = computation. Perhaps this is your point? In order to guarantee = non-conflicting computation, it is necessary to batch all computations = together on single centralized server performing all computations = "simultaneously".
=A0
But, our point is that even this does not guarantee LSP = establishment. The sentence after the one you quote = says...
=A0=A0 However, a single, = centralized
=A0=A0 PCE is not viewed as a solution that can = guarantee TE LSP
=A0=A0 establishment since the potential = for network failures or contention
=A0=A0 for = resources still exists where the centralized TED cannot fully
=A0=A0 reflect current (i.e., real-time) network = state.
=A0
So I don't think your proposed solution = is *the* fundamental solution.

> - Section 5.4: "Multiple PCE path = computation with inter-PCE communication
> involves = coordination between distributed PCEs such that the result of = the
> computation performed by one PCE depends on information = supplied by other
> PCEs. This model does not provide a = distributed computation algorithm, but
> allows = distinct PCEs to be responsible for computation of parts = (segments)
> of the path."
> 1- I believe = you mean different or distinct PCEs instead of distributed = PCEs.
=A0
Yes.
=A0
>=A02- We need to exapnd this part. Cooperation between = PCEs
> can take one of two forms, which we refer to = as model-based and ad hoc. In
> model-based = cooperation (the case described here), PCEs have information = on
> other domains (aggregate or detailed, available a priori = or upon request),
> and the path (or a section of the = path) is decided by one PCE at the end.
> There is = another way the PCEs can cooperate, where they do not share = any
> information, and they find the end-to-end path in an ad = hoc fashion (similar
> to DSR). In this case, we have a = distributed path computation.
=A0
In your second case, how is the route = known by the PCC? Isn't it the case that the PCEs share the computed = route fragments?
=A0
> - Figure 5: Suggest adding a link between NMS and TED to = show alternate ways
> for synchronization (the TED = synchronization arrow does not suggest a
> possible link = to NMS).
=A0
Yeah, probably. The text covers this pretty well, = however.
Actually, we debated removing the TED synchronization arrows = as beyond the scope of PCE.

> - Section 6.3: = Synchronization is a bad term for this section. You
> definitely are not suggesting we compute paths based on = a synchronized
> global clock ;) Suggest = "Simultaneous path computation" for the section
> title, "simultaneous processing of path computation = requests" for
> "synchronized path computation", and = "sequential processing of path
> computation = requests" for "non-synchronized path = computation"
=A0
Synchronization is from the verb, to = synchronize.
Synchorinze - to make = synchronous
Synchronous - happening at the same time; = occurring together; simultaneous
=A0
So I don't see that changing = "synchronized" for "simultaneous" has any = gain.
=A0
In fact, in the third paragraph we use both "synchronized" = and "simultaneous" to make double sure that we are = understood.

> - Section 6.3: Suggest "better" or = "closer to optimal" instead of "more
> = optimal".
=A0
Agreed.

> - Section 6.3: "The involvement of more than one PCE in = the computation of a
> series of paths is by its nature = non-synchronized. However, a set of
> cooperating = PCEs may be synchronized under the control of a single PCE. = For
> example, a PCC may send a request to a PCE which invokes = domain-specific
> computations by other PCEs before = supplying a result to the PCC." Can you
> elaborate = here?
=A0
Well, consider four domains:
=A0 = B
=A0/=A0\
A=A0=A0 D
=A0 C
=A0
=A0
A PCC in domain A may request a pair of diverse paths from an = ingress in domain A to an egress in domain = B.
=A0
Let us assume that there are multiple domain border nodes = between domains B and D, but between no other = domains.
=A0
The PCE for domain A may request paths from the domains B and = C. The PCE for domain B may return several candidate paths. The PCE for = domain A will now request paths through domain D to the egress and = considering the entry points into domain D from domains B and = C.
=A0
Once the results are in, the PCE for domain A can select a = pair of disjoint paths. (Disjointedness being necessary in domains A and = D).
=A0
HOWEVER, this example of how one might decompose a request is = entirely implementation-specific. There are other applicabilities of PCE = cooperation that might achieve this = differently.
=A0
=A0
> - Section 6.3: "Conversely, the PCC = may issue a single request to the PCE
> asking for all = of the paths to be computed in a synchronized manner. The PCE
> will then perform simultaneous computation of the set of = requested path.
> Such synchronized computation can = often provide more optimal results." The
> distinction is = clearly important in computation and algorithms, however,
> this is not an attribute that can be exposed to or = requested by the user-
> user should = have a more descriptive requirement =

Clearly, it is since the = PCC would stipulate the requirement for simultaneous computations in its = request. See for example the set of mechanisms specified in = PCEP.

(e.g., two full = disjoint
> paths with total cost of less than x - how = the answer is derived, through
> simultaneous = or sequential processing is not something the user should ask
> for (it is like the user asks for Dijkstra's algorithm = to be used).
=A0
When you say "user" = do you mean the PCC?
=A0
In the first instance the PCC MUST be responsible for this = level of determinism. That is, if it makes two separate requests for = paths, simultaneous computation cannot be performed. But nevertheless = the requests would be valid...
1. Compute me a = path from A to B with least cost.
2. Compute be a = path from A to B that is disjoint from the previous path and which has = least cost.
=A0
Thus, the PCC = already has some control over whether simultaneous computation is = requested.
=A0
Now, many people = have told us that they *do* want to be able to specify which algorithm = is used. And this may be very valid because cheap (small, local, easily = accessed) PCEs might not be able to perform simultaneous computation of = very many paths at the same time. It would then be necessary for these = PCEs to reject the request (so that the PCC could redirect it to a more = sophisticated PCE) or redirect the request itself.
=A0
> - Section 6.6: = Perhaps reliability instread of level of robustness?
Oooh!
=A0
This sent me scampering to the CCAMP P&R drafts to find = the definitions of reliable and robust. Unfortunately not there = :-(
=A0
Having spent some = time with Mr. Webster, I conclude that Reliable and Robust are adequate = synonyms. The reason that I don't like to use "reliable" is an old = networking joke...
=A0
=A0=A0=A0 You can rely on our product completely. It fails = *every* Tuesday.
=A0
However, I also=A0note that we should include=A0Resilience.=A0S= o the bullet now reads...
=A0
=A0=A0 - the levels of robustness and resilience of the path = resources
Thanks.

JP.


= --Apple-Mail-17--830750786-- --===============1191433257== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1191433257==-- From pce-bounces@lists.ietf.org Wed Jan 04 12:52:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuCoH-0000eA-LD; Wed, 04 Jan 2006 12:52:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuCoG-0000e5-SO for pce@megatron.ietf.org; Wed, 04 Jan 2006 12:52:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06246 for ; Wed, 4 Jan 2006 12:51:14 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuCtm-0002I6-OO for pce@ietf.org; Wed, 04 Jan 2006 12:58:12 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 04 Jan 2006 12:52:19 -0500 X-IronPort-AV: i="3.99,330,1131339600"; d="scan'208"; a="79371764:sNHT27559280" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k04HpjKB012225; Wed, 4 Jan 2006 12:52:17 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 Jan 2006 12:51:45 -0500 Received: from [192.168.1.101] ([10.86.242.183]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 Jan 2006 12:51:44 -0500 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <08582923-909A-4B9F-98A0-571284150E62@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Wed, 4 Jan 2006 12:51:13 -0500 To: LE ROUX Jean-Louis RD-CORE-LAN X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 04 Jan 2006 17:51:44.0623 (UTC) FILETIME=[86B147F0:01C61157] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: pce@ietf.org Subject: [Pce] Action item on draft-ietf-pce-discovery-reqs-02.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Jean-Louis, As recorded in the last PCE WG meeting minutes, there are (minor?) changes required in draft-ietf-pce-discovery-reqs-02.txt (policy + inter-AS) so as to move forward. Would you be willing to make the changes, make sure we have an agreement on the list and repost ? Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jan 04 14:33:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuEOM-0003n0-Pd; Wed, 04 Jan 2006 14:33:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuEOL-0003ms-QG for pce@megatron.ietf.org; Wed, 04 Jan 2006 14:33:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14910 for ; Wed, 4 Jan 2006 14:32:34 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuETs-0005IU-1P for pce@ietf.org; Wed, 04 Jan 2006 14:39:33 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 04 Jan 2006 11:07:41 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,330,1131350400"; d="scan'208,217"; a="18861789:sNHT36211732" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k04J7b6J027300; Wed, 4 Jan 2006 14:07:39 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 Jan 2006 14:07:38 -0500 Received: from [192.168.1.101] ([10.86.242.183]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 Jan 2006 14:07:36 -0500 In-Reply-To: <000001c60b7f$14a2bf00$570c6f0a@huawei.com> References: <000001c60b7f$14a2bf00$570c6f0a@huawei.com> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 Message-Id: <050ECEB9-E5F5-4308-9ACF-66FE764A9B29@cisco.com> From: JP Vasseur Subject: Re: [Pce] Comment on draft-ietf-pce-pcecp-interarea-reqs-00.txt Date: Wed, 4 Jan 2006 14:07:05 -0500 To: Zhang Renhai X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 04 Jan 2006 19:07:36.0248 (UTC) FILETIME=[1FAC2380:01C61162] X-Spam-Score: 0.8 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1864433739==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============1864433739== Content-Type: multipart/alternative; boundary=Apple-Mail-72--819364228 --Apple-Mail-72--819364228 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi , On Dec 28, 2005, at 2:03 AM, Zhang Renhai wrote: > Hi, Jean-Louis > > I have some comment on the draft draft-ietf-pce-pcecp-interarea- > reqs-00.txt > > In section 7.11.1, In case of network failure, jittering will be > used to avoid > simultaneous requests sent to one PCE. Could more consideration be > given here to > the preemptment, becouse the jittering timeout is stochastic, some > lower request > may be served before a higher request and the path may be > calculated differently. > which may increase the probability of a preemptment. > The decision on the PCC request scheduling is out of the scope of this ID. Note that the point that you mentioned also applies to the located-PCE case. > > I have always been thinking a question: if a PCC will not perform > the CSPF > computation, why does it still maintain the TEDB any longer? which > may consume > a lot of memory and CPU of a LSR.This question dost not aid at this > draft. > Because (1) The PCE may decide to use a remote PCE for some LSPs and not for others (for instance, inter versus intra-domain) (2) The PCE may decide to always use a PCE and fall back to local path computation or loose hop routing under specific conditions > In inter-area environment,sometimes, a PCC may wish to get as many > paths as possible, > for all kinds of purpose,so could the PCC send the request to more > than one PCEs? > Yes, although this would clearly be very sub-optimal .... JP. > Regards, > Zhang > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-72--819364228 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi ,

On Dec = 28, 2005, at 2:03 AM, Zhang Renhai wrote:

=
Hi, Jean-Louis
=A0
=A0I have some comment = on the draft draft-ietf-pce-pcecp-interarea-reqs-00.txt
=
=A0
=A0In = section 7.11.1, In case of network failure, jittering will be used to = avoid
simultaneous requests sent to = one PCE.=A0Could more consideration be given here to
=
the preemptment, becouse the jittering timeout is = stochastic, some lower request
may be = served before a higher request and the path may be calculated = differently.
which may increase the = probability=A0of a preemptment.


The decision on the PCC = request scheduling is out of the scope of this ID. Note that the point = that you mentioned also applies to the located-PCE = case.

=A0
=A0I have always been thinking a question: if a PCC will not = perform the CSPF=A0
computation, why = does it still maintain the TEDB any longer? which may consume =
a lot of memory and CPU of a LSR.This question dost not aid=A0at this = draft.
=A0

Because
(1) The = PCE may decide to use a remote PCE for some LSPs and not for others (for = instance, inter versus intra-domain)
(2) The PCE may decide to = always use a PCE and fall back to local path computation or loose hop = routing under specific conditions

=
=A0In inter-area environment,sometimes, a PCC may wish to get as many paths as = possible,
for all kinds of purpose,so = could the PCC send the request to more than one = PCEs?
=A0

Yes, although this would = clearly be very sub-optimal ....

JP.

Regards,
Zhang
Pce mailing list
=

= --Apple-Mail-72--819364228-- --===============1864433739== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1864433739==-- From pce-bounces@lists.ietf.org Wed Jan 04 18:06:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuHiT-0008IW-Fm; Wed, 04 Jan 2006 18:06:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuHiQ-0008HU-VS for pce@megatron.ietf.org; Wed, 04 Jan 2006 18:06:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16538 for ; Wed, 4 Jan 2006 18:05:32 -0500 (EST) Received: from mail.lopsys.com ([12.47.115.93] helo=mailsrv01.vasw) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuHnz-00075z-RQ for pce@ietf.org; Wed, 04 Jan 2006 18:12:32 -0500 Received: from NETPTORAB (net-torab.vasw [192.168.254.48]) by mailsrv01.vasw (8.13.1/8.13.1) with SMTP id k04N5Mi6001355; Wed, 4 Jan 2006 18:05:22 -0500 From: "Payam Torab" To: "'Adrian Farrel'" , Subject: RE: [Pce] Re: Working Group Last call ondraft-ietf-pce-architecture-03.txt Date: Wed, 4 Jan 2006 18:04:19 -0500 Message-ID: <009401c61183$31f44d80$30fea8c0@NETPTORAB> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <027801c61133$d9646f00$b8849ed9@Puppy> Importance: Normal X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on localhost X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Adrian- The list is down to one point (algorithm specification by PCC) thanks to your patience. How about... "A PCE-Based Network Architecture" [PT] Thanks. Any title other than "PCE Architecture" would satisfy the purpose, and sorry for stress on wording. Are you saying that it is not possible to compute a path unless all identifiers come from the same name space? 'Cos that is clearly not true - the computation operates on an abstraction. I still don't get your point. [PT] My point was the following example, which you believe is not a PCE question. So, we'll just assume TED avoids name space clash, and it is a design issue that does not need standardization. You imply that the model described assumes that "PCEs have information on other domains (aggregate or detailed) availabel a priori or upon request." This is not the case. I think you are confused by the text... Multiple PCE path computation with inter-PCE communication involves coordination between distinct PCEs such that the result of the computation performed by one PCE depends on information supplied by other PCEs. You assume that the "information supplied" is TE information. But it doesn't say that. Perhaps we should clarify what this information is since it is less than clear. We will update this to indicate that the information is "path fragment information". [PT] Yes- I was assuming the information refers to TE information. Adding that the shared information can be path information or TE information will serve the purpose, and no distinction between model-based and ad hoc is necessary. let's look at where ad hoc routing fits in. There are two cases: 1. ... 2. The alternative is that all of the routing is done before any signaling is started. In this case, each PCE computes a segment of the path and passes the request on to the next PCE to compute the next segment. The segment paths are returned to the initial PCE which is able to pass the full path to the PCC. But this is exactly the case described in 5.4. Clearly there are variables. - Does the initial PCE send requests to more than one other PCE? - Does the initial PCE suggest multiple border nodes? - Do the downstream PCEs return multiple paths with different qualities to allow the initial PCE to choose? If the answer to these and other questions is "no" then you have ad hoc routing. [PT] While ad hoc has a much simpler definition (simply no TE information and no presumption about the sequence of domains taken), discussion is now irrelevant and you addressed the question. >> Now, many people have told us that they *do* want to be able to specify >> which algorithm is used. And this may be very valid because cheap (small, >> local, easily accessed) PCEs might not be able to perform simultaneous >> computation of very many paths at the same time. It would then be necessary >> for these PCEs to reject the request (so that the PCC could redirect it to a >> more sophisticated PCE) or redirect the request itself. > > [PT] This is a sad point that kills the black box elegance of this work. > What happens if I come up with a modified or original algorithm in my PCE > that outperforms existing algorithms? What if you do? 1. I do not have to exert control, just because I have control. I can leave the choice to the PCE. 2. However, if I don't trust your new algorithm, I should be able to select a different one. In reality all algorithms have positive and negative points. - Some are more accurate at the cost of being slower - Some optimise for one feature ahead of other features - Some are newly developed and untrusted - Some work poorly in certain network contditions To say that the user is unable to select the algorithm, is like saying that the user is not allowed to set the constraints. [PT] I am sure this is an old discussion that algorithm specification per se is meaningless, as implementation or CPU power may be poor for example. The only meaningful requirements are quantitative metrics on accuracy, performance etc. As I said, if people have asked for algorithm specification, they have indeed asked for other requirements addressed by the algorithms. If I am wrong, and PCC is indeed required to be able to specify an "algorithm", then please mention that in the document. The point is let's not walk away here, and make a declaration on algorithm issue. > Since this is a dangerous issue, let's be clear: Algorithm opacity > is fundamental to the value of this work, and if someone is interested > in specifying an algorithm, they are in fact interested in one or more > high-level requirements that are addressed by that algorithm. These > high-level requirements can be negotiated at the time of discovery, > which is a much better time than in the middle of > making a request and getting disappointed by a cheap PCE. I suggest we > spell this out in the document. I think it is late to revisit this argument. However, if the WG wants to change its mind, I guess that's fine. Anyone else want to support Payam on this point? [PT] Thanks. Being late for my comments, I respect any decision, but would be disappointed if we target algorithm specification. But, again, I think you have it on its head. The requirement that is presented in the draft is that the PCC must be able to constrin the PCE to do synchronized computation. That is, the PCC must be able to say "I know this is more work for you, and I know it will chew up your CPU, and I know it requires you to implement a more clever algorithm, but I insist that you use synchronized computation because I want the better quality result that will be produced." [PT] Ok. I see. My point was asking for "synchronized" is as meaningless as asking for "Dijkstra": I can come up with a synchronized algorithm that performs worse than a non-synchronized version with respect to a metric. But, going with the popular assumption that "Synchronized" means "better paths at the price of more CPU time", as ill-defined as it is and as long as this meaning is clear to every one, no objection. Reading Section 6.3, I think confusion can be minimized if you swap the second and third paragraphs (removing "conversely" at the beginning) But suppose a PCE says "I can do fast unsynchronized computation, or slow synchronized computation" That is, the PCE has two algorithms available. So the PCC chooses this PCE to service its request. How will the PCE know which algorithm to use? [PT] Ok. Although absolute requirements such as max path computation time are better in this case, I can also see they are hard to measure and therefore hard to request. > - Section 6.6: Perhaps reliability instread of level of robustness? Will you settle for the text suggested to Dimitri... - the levels of resiliency, reliability and robustness of the path resources [PT] Yes- thanks. Thanks, Payam _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jan 04 18:49:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuINu-0005R4-Bz; Wed, 04 Jan 2006 18:49:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuINs-0005Pm-I9 for pce@megatron.ietf.org; Wed, 04 Jan 2006 18:49:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21881 for ; Wed, 4 Jan 2006 18:48:21 -0500 (EST) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuITQ-0000Nz-TP for pce@ietf.org; Wed, 04 Jan 2006 18:55:22 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3) with ESMTP id k04NnNF0025805 for ; Thu, 5 Jan 2006 00:49:23 +0100 To: pce@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Thu, 5 Jan 2006 00:49:20 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 01/05/2006 00:49:22, Serialize complete at 01/05/2006 00:49:22 X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.3 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Subject: [Pce] clarification on draft-ietf-pce-architecture-03.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0729804729==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multipart message in MIME format. --===============0729804729== Content-Type: multipart/alternative; boundary="=_alternative 0082DC97C12570EC_=" This is a multipart message in MIME format. --=_alternative 0082DC97C12570EC_= Content-Type: text/plain; charset="US-ASCII" arch. document section 6.6 mentions "The path computation request may include a significant set of requirements including: - the source and destination of the path" ... there is an underlying question beside this, is it the source/destination of the LSP or is it the source/destination between which path computation has to be performed and that may correspond to the source/destination of the LSP itself the side point is that in that the notion of path was since so far linked to the signaling protocol hence linked to the notion of LSP, but it in the context of a PCE this notion does not necessarily hold anymore, e.g., one coudl request for the computation of a path between point A and point B (A being not the sourceof the LSP and B being not the destination of the LSP) even if there is no a 1:1 relationship between the entity corresponding to the path between A and B and the way the signaling protocol translate the "path segment" between A and B some clarification would be welcome here in the context of this document thanks, - dimitri; --=_alternative 0082DC97C12570EC_= Content-Type: text/html; charset="US-ASCII"
arch. document section 6.6 mentions

   "The path computation request may include a significant set of
  requirements including:

  - the source and destination of the path"

... there is an underlying question beside this, is it the source/destination of the LSP or is it the source/destination between which path computation has to be performed and that may correspond to the source/destination of the LSP itself

the side point is that in that the notion of path was since so far linked to the signaling protocol hence linked to the notion of LSP, but it in the context of a PCE this notion does not necessarily hold anymore, e.g., one coudl request for the computation of a path between point A and point B (A being not the sourceof the LSP and B being not the destination of the LSP) even if there is no a 1:1 relationship between the entity corresponding to the path between A and B and the way the signaling protocol translate the "path segment" between A and B

some clarification would be welcome here in the context of this document

thanks,
- dimitri; --=_alternative 0082DC97C12570EC_=-- --===============0729804729== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0729804729==-- From pce-bounces@lists.ietf.org Wed Jan 04 22:22:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuLhs-0003KD-TB; Wed, 04 Jan 2006 22:22:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuLhr-0003K6-4z for pce@megatron.ietf.org; Wed, 04 Jan 2006 22:22:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11806 for ; Wed, 4 Jan 2006 22:21:12 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuLnS-0007AJ-Ji for pce@ietf.org; Wed, 04 Jan 2006 22:28:15 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 04 Jan 2006 19:22:17 -0800 X-IronPort-AV: i="3.99,331,1131350400"; d="scan'208,217"; a="387498722:sNHT43916988" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k053MGWF005993; Wed, 4 Jan 2006 19:22:16 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 Jan 2006 22:22:16 -0500 Received: from [192.168.1.101] ([10.86.242.183]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 Jan 2006 22:22:15 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Message-Id: <4AC2F305-4759-41D5-894A-5C443C588E54@cisco.com> From: JP Vasseur Subject: Re: [Pce] clarification on draft-ietf-pce-architecture-03.txt Date: Wed, 4 Jan 2006 22:21:44 -0500 To: Dimitri.Papadimitriou@alcatel.be X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 05 Jan 2006 03:22:15.0600 (UTC) FILETIME=[39F1DB00:01C611A7] X-Spam-Score: 0.5 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1722934652==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============1722934652== Content-Type: multipart/alternative; boundary=Apple-Mail-90--789685183 --Apple-Mail-90--789685183 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi Dimitri, On Jan 4, 2006, at 6:49 PM, Dimitri.Papadimitriou@alcatel.be wrote: > > arch. document section 6.6 mentions > > "The path computation request may include a significant set of > requirements including: > > - the source and destination of the path" > > ... there is an underlying question beside this, is it the source/ > destination of the LSP or is it the source/destination between > which path computation has to be performed and that may correspond > to the source/destination of the LSP itself > > the side point is that in that the notion of path was since so far > linked to the signaling protocol hence linked to the notion of LSP, > but it in the context of a PCE this notion does not necessarily > hold anymore, e.g., one coudl request for the computation of a path > between point A and point B (A being not the sourceof the LSP and B > being not the destination of the LSP) even if there is no a 1:1 > relationship between the entity corresponding to the path between A > and B and the way the signaling protocol translate the "path > segment" between A and B The request applies for a path computation between a point A and a point B (the source and destination). The text does not imply that the source and the destination of such path correspond to the source and destination of the TE LSP ? Thanks. JP. > > some clarification would be welcome here in the context of this > document > > thanks, > - dimitri; > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-90--789685183 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Dimitri,

On = Jan 4, 2006, at 6:49 PM, Dimitri.Papadimitriou@alc= atel.be wrote:


arch. document section 6.6 mentions
=
=A0 =A0"The path computation request may = include a significant set of
=A0 requirements including:

=A0 = - the source and destination of the path"

... there is an underlying question beside this, is it = the source/destination of the LSP or is it the source/destination = between which path computation has to be performed and that may = correspond to the source/destination of the LSP itself
=
the side point is that in that the notion of = path was since so far linked to the signaling protocol hence linked to = the notion of LSP, but it in the context of a PCE this notion does not = necessarily hold anymore, e.g., one coudl request for the computation of = a path between point A and point B (A being not the sourceof the LSP and = B being not the destination of the LSP) even if there is no a 1:1 = relationship between the entity corresponding to the path between A and = B and the way the signaling protocol translate the "path segment" = between A and B

The request applies for a = path computation between a point A and a point B (the source and = destination). The text does not imply that the source and the = destination of such path correspond to the source and destination of the = TE LSP ?

Thanks.

JP.


some clarification would be = welcome here in the context of this document

thanks,
- dimitri; =
Pce mailing list
=

= --Apple-Mail-90--789685183-- --===============1722934652== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1722934652==-- From pce-bounces@lists.ietf.org Thu Jan 05 04:18:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuRGR-0000rr-0V; Thu, 05 Jan 2006 04:18:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuRGP-0000rY-79 for pce@megatron.ietf.org; Thu, 05 Jan 2006 04:18:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15896 for ; Thu, 5 Jan 2006 04:17:12 -0500 (EST) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuRM1-000218-Cf for pce@ietf.org; Thu, 05 Jan 2006 04:24:20 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3) with ESMTP id k059IEO1027453; Thu, 5 Jan 2006 10:18:14 +0100 In-Reply-To: <4AC2F305-4759-41D5-894A-5C443C588E54@cisco.com> To: JP Vasseur Subject: Re: [Pce] clarification on draft-ietf-pce-architecture-03.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Thu, 5 Jan 2006 10:18:12 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 01/05/2006 10:18:13, Serialize complete at 01/05/2006 10:18:13 X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.4 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: pce-bounces@ietf.org, pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0019882341==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multipart message in MIME format. --===============0019882341== Content-Type: multipart/alternative; boundary="=_alternative 00331B73C12570ED_=" This is a multipart message in MIME format. --=_alternative 00331B73C12570ED_= Content-Type: text/plain; charset="US-ASCII" hi j-p see in-line On Jan 4, 2006, at 6:49 PM, Dimitri.Papadimitriou@alcatel.be wrote: arch. document section 6.6 mentions "The path computation request may include a significant set of requirements including: - the source and destination of the path" ... there is an underlying question beside this, is it the source/destination of the LSP or is it the source/destination between which path computation has to be performed and that may correspond to the source/destination of the LSP itself the side point is that in that the notion of path was since so far linked to the signaling protocol hence linked to the notion of LSP, but it in the context of a PCE this notion does not necessarily hold anymore, e.g., one coudl request for the computation of a path between point A and point B (A being not the sourceof the LSP and B being not the destination of the LSP) even if there is no a 1:1 relationship between the entity corresponding to the path between A and B and the way the signaling protocol translate the "path segment" between A and B The request applies for a path computation between a point A and a point B (the source and destination). The text does not imply that the source and the destination of such path correspond to the source and destination of the TE LSP ? [dp] so, the source and destination (as listed) is the source and destination of the path to be computed and not the source and destination of the LSP (for which this computation is requested) it is thus worth dropping a couple of lines concerning this relationship to avoid any further confusion; indeed, when i look at the interpretation done in PCEP the situation is not the one described in the architecture document "7.5. END-POINTS Object The END-POINTS object is used in a PCReq message to specify the source IP address and the destination IP address of the TE LSP for which a path computation is requested. Two END-POINTS objects (for IPv4 and IPv6) are defined." this said, having the computation request scope decoupled from the LSP reach is of primary importance thanks, - dimitri; _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --=_alternative 00331B73C12570ED_= Content-Type: text/html; charset="US-ASCII"
hi j-p see in-line



On Jan 4, 2006, at 6:49 PM, Dimitri.Papadimitriou@alcatel.be wrote:


arch. document section 6.6 mentions

   "The path computation request may include a significant set of
  requirements including:

  - the source and destination of the path"

... there is an underlying question beside this, is it the source/destination of the LSP or is it the source/destination between which path computation has to be performed and that may correspond to the source/destination of the LSP itself

the side point is that in that the notion of path was since so far linked to the signaling protocol hence linked to the notion of LSP, but it in the context of a PCE this notion does not necessarily hold anymore, e.g., one coudl request for the computation of a path between point A and point B (A being not the sourceof the LSP and B being not the destination of the LSP) even if there is no a 1:1 relationship between the entity corresponding to the path between A and B and the way the signaling protocol translate the "path segment" between A and B

The request applies for a path computation between a point A and a point B (the source and destination). The text does not imply that the source and the destination of such path correspond to the source and destination of the TE LSP ?

[dp] so, the source and destination (as listed) is the source and destination of the path to be computed and not the source and destination of the LSP (for which this computation is requested) it is thus worth dropping a couple of lines concerning this relationship to avoid any further confusion; indeed, when i look at the interpretation done in PCEP the situation is not the one described in the architecture document

       "7.5. END-POINTS Object
       
      The END-POINTS object is used in a PCReq message to specify the
      source IP address and the destination IP address of the TE LSP for
      which a path computation is requested. Two END-POINTS objects (for
      IPv4 and IPv6) are defined."  

this said, having the computation request scope decoupled from the LSP reach is of primary importance

thanks,
- dimitri;
_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce
--=_alternative 00331B73C12570ED_=-- --===============0019882341== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0019882341==-- From pce-bounces@lists.ietf.org Thu Jan 05 06:12:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuT2s-0006VA-VQ; Thu, 05 Jan 2006 06:12:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuT2r-0006V4-3u for pce@megatron.ietf.org; Thu, 05 Jan 2006 06:12:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27374 for ; Thu, 5 Jan 2006 06:11:22 -0500 (EST) Received: from relay1.mail.uk.clara.net ([80.168.70.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuT8U-0005d6-0O for pce@ietf.org; Thu, 05 Jan 2006 06:18:29 -0500 Received: from du-069-0123.access.clara.net ([217.158.132.123] helo=Puppy) by relay1.mail.uk.clara.net with esmtp (Exim 4.46) id 1EuT2a-000Mfh-IM; Thu, 05 Jan 2006 11:12:22 +0000 Message-ID: <039401c611e9$6b381ed0$b8849ed9@Puppy> From: "Adrian Farrel" To: , "JP Vasseur" References: Date: Thu, 5 Jan 2006 11:15:34 -0000 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: pce@ietf.org Subject: [Pce] PCEP Spec [Was: clarification on draft-ietf-pce-architecture-03.txt] X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, Changed the subject line since the comments now apply to section 7.5 draft-ietf-pce-pcep-00.txt I agree with Dimitri. The next needs to be cleaned a little because it implies that the end points of the requested computation are the end points of the TE LSP. It is also interesting to consider whether it would be useful to the PCE to know the actual end points of the service for which this computation is providing a segment. Fells like it might be, but unless we can actually see that reason now, we should leave the information out, and only add it when we discover the need. Cheers, Adrian > arch. document section 6.6 mentions > > "The path computation request may include a significant set of > requirements including: > > - the source and destination of the path" > > ... there is an underlying question beside this, is it the > source/destination of the LSP or is it the source/destination between > which path computation has to be performed and that may correspond to the > source/destination of the LSP itself > > the side point is that in that the notion of path was since so far linked > to the signaling protocol hence linked to the notion of LSP, but it in the > context of a PCE this notion does not necessarily hold anymore, e.g., one > coudl request for the computation of a path between point A and point B (A > being not the sourceof the LSP and B being not the destination of the LSP) > even if there is no a 1:1 relationship between the entity corresponding to > the path between A and B and the way the signaling protocol translate the > "path segment" between A and B > > The request applies for a path computation between a point A and a point B > (the source and destination). The text does not imply that the source and > the destination of such path correspond to the source and destination of > the TE LSP ? > > [dp] so, the source and destination (as listed) is the source and > destination of the path to be computed and not the source and destination > of the LSP (for which this computation is requested) it is thus worth > dropping a couple of lines concerning this relationship to avoid any > further confusion; indeed, when i look at the interpretation done in PCEP > the situation is not the one described in the architecture document > > "7.5. END-POINTS Object > > The END-POINTS object is used in a PCReq message to specify the > source IP address and the destination IP address of the TE LSP for > which a path computation is requested. Two END-POINTS objects (for > IPv4 and IPv6) are defined." > > this said, having the computation request scope decoupled from the LSP > reach is of primary importance _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jan 05 07:46:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuUVR-0005QL-Vp; Thu, 05 Jan 2006 07:46:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuUVP-0005O5-U4 for pce@megatron.ietf.org; Thu, 05 Jan 2006 07:46:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08527 for ; Thu, 5 Jan 2006 07:44:56 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuUb6-0000NR-I8 for pce@ietf.org; Thu, 05 Jan 2006 07:52:05 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 05 Jan 2006 04:46:03 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,334,1131350400"; d="scan'208,217"; a="18949817:sNHT41476884" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k05CjqJl018326; Thu, 5 Jan 2006 07:45:59 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 Jan 2006 07:44:13 -0500 Received: from [192.168.1.101] ([10.86.240.151]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 Jan 2006 07:45:52 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Message-Id: <3E2DD914-F529-4183-890F-67D2F56BA9E7@cisco.com> From: JP Vasseur Subject: Re: [Pce] clarification on draft-ietf-pce-architecture-03.txt Date: Thu, 5 Jan 2006 07:45:19 -0500 To: Dimitri.Papadimitriou@alcatel.be X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 05 Jan 2006 12:45:52.0905 (UTC) FILETIME=[F6A11790:01C611F5] X-Spam-Score: 0.6 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1400434110==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============1400434110== Content-Type: multipart/alternative; boundary=Apple-Mail-91--755870015 --Apple-Mail-91--755870015 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi Dimitri, On Jan 5, 2006, at 4:18 AM, Dimitri.Papadimitriou@alcatel.be wrote: > > hi j-p see in-line > > > > On Jan 4, 2006, at 6:49 PM, Dimitri.Papadimitriou@alcatel.be wrote: > > > arch. document section 6.6 mentions > > "The path computation request may include a significant set of > requirements including: > > - the source and destination of the path" > > ... there is an underlying question beside this, is it the source/ > destination of the LSP or is it the source/destination between > which path computation has to be performed and that may correspond > to the source/destination of the LSP itself > > the side point is that in that the notion of path was since so far > linked to the signaling protocol hence linked to the notion of LSP, > but it in the context of a PCE this notion does not necessarily > hold anymore, e.g., one coudl request for the computation of a path > between point A and point B (A being not the sourceof the LSP and B > being not the destination of the LSP) even if there is no a 1:1 > relationship between the entity corresponding to the path between A > and B and the way the signaling protocol translate the "path > segment" between A and B > > The request applies for a path computation between a point A and a > point B (the source and destination). The text does not imply that > the source and the destination of such path correspond to the > source and destination of the TE LSP ? > > [dp] so, the source and destination (as listed) is the source and > destination of the path to be computed and not the source and > destination of the LSP (for which this computation is requested) it > is thus worth dropping a couple of lines concerning this > relationship to avoid any further confusion; indeed, when i look at > the interpretation done in PCEP the situation is not the one > described in the architecture document > > "7.5. END-POINTS Object > > The END-POINTS object is used in a PCReq message to specify the > source IP address and the destination IP address of the TE > LSP for > which a path computation is requested. Two END-POINTS objects > (for > IPv4 and IPv6) are defined." > Agree, the definition of the END-POINT object in PCEP will be reworded in the next rev to avoid confusion indeed. Thanks. JP. > this said, having the computation request scope decoupled from the > LSP reach is of primary importance > > thanks, > - dimitri; > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > --Apple-Mail-91--755870015 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Dimitri,

On = Jan 5, 2006, at 4:18 AM, Dimitri.Papadimitriou@alc= atel.be wrote:


hi j-p see in-line


=
On Jan 4, 2006, at 6:49 PM, = Dimitri.Papadimitriou@alcatel.be wrote:


arch. document section 6.6 mentions

= =A0 =A0"The path computation request may include a significant set = of
=A0 requirements including:

=A0 - the source and = destination of the path"

... there is an underlying question = beside this, is it the source/destination of the LSP or is it the = source/destination between which path computation has to be performed = and that may correspond to the source/destination of the LSP itself
=
the side point is that in that the notion of path was since so far = linked to the signaling protocol hence linked to the notion of LSP, but = it in the context of a PCE this notion does not necessarily hold = anymore, e.g., one coudl request for the computation of a path between = point A and point B (A being not the sourceof the LSP and B being not = the destination of the LSP) even if there is no a 1:1 relationship = between the entity corresponding to the path between A and B and the way = the signaling protocol translate the "path segment" between A and B =

The request = applies for a path computation between a point A and a point B (the = source and destination). The text does not imply that the source and the = destination of such path correspond to the source and destination of the = TE LSP ?

[dp] so, = the source and destination (as listed) is the source and destination of = the path to be computed and not the source and destination of the LSP = (for which this computation is requested) it is thus worth dropping a = couple of lines concerning this relationship to avoid any further = confusion; indeed, when i look at the interpretation done in PCEP the = situation is not the one described in the architecture document =

=A0 =A0 =A0 =A0"7.5. = END-POINTS Object
=A0 =A0 =A0 =A0
=A0 =A0 =A0 The END-POINTS = object is used in a PCReq message to specify the
=A0 =A0 =A0 source = IP address and the destination IP address of the TE LSP for
=A0 =A0 = =A0 which a path computation is requested. Two END-POINTS objects (for =
=A0 =A0 =A0 IPv4 and IPv6) are defined." =A0
=

Agree, the definition of = the END-POINT object in PCEP will be reworded in the next rev to avoid = confusion indeed.

Thanks.

JP.

this said, having = the computation request scope decoupled from the LSP reach is of primary = importance

thanks,
- dimitri;
_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing = list
Pce@lists.ietf.org
= https://www1.ietf.org/= mailman/listinfo/pce
 =

= --Apple-Mail-91--755870015-- --===============1400434110== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1400434110==-- From pce-bounces@lists.ietf.org Thu Jan 05 08:32:01 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuVDl-0006Bx-IR; Thu, 05 Jan 2006 08:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuVDj-0006Bn-Dq for pce@megatron.ietf.org; Thu, 05 Jan 2006 08:31:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14063 for ; Thu, 5 Jan 2006 08:30:43 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuVJP-0002Fo-9M for pce@ietf.org; Thu, 05 Jan 2006 08:37:52 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 Jan 2006 14:31:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Jan 2006 14:31:52 +0100 Message-ID: Thread-Topic: Action item on draft-ietf-pce-discovery-reqs-02.txt thread-index: AcYRV5vYVX3sLdmiRIGyOGMz1uxDuAApHr8A From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "JP Vasseur" X-OriginalArrivalTime: 05 Jan 2006 13:31:53.0629 (UTC) FILETIME=[642624D0:01C611FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org Subject: [Pce] RE: Action item on draft-ietf-pce-discovery-reqs-02.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Jean Philippe A new version will be submitted by the end of next week. It will account for inter-AS and policy aspects. Regards, JL=20 > -----Message d'origine----- > De : JP Vasseur [mailto:jvasseur@cisco.com]=20 > Envoy=E9 : mercredi 4 janvier 2006 18:51 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > Cc : pce@ietf.org > Objet : Action item on draft-ietf-pce-discovery-reqs-02.txt >=20 > Hi Jean-Louis, >=20 > As recorded in the last PCE WG meeting minutes, there are=20 > (minor?) changes required in=20 > draft-ietf-pce-discovery-reqs-02.txt (policy + > inter-AS) so as to move forward. Would you be willing to make=20 > the changes, make sure we have an agreement on the list and repost ? >=20 > Thanks. >=20 > JP. >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jan 05 09:40:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuWIK-0003eu-VW; Thu, 05 Jan 2006 09:40:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuWII-0003eS-Qu; Thu, 05 Jan 2006 09:40:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21850; Thu, 5 Jan 2006 09:39:30 -0500 (EST) Received: from webmail.movaz.com ([70.158.43.219] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuWO0-0004iB-9Q; Thu, 05 Jan 2006 09:46:40 -0500 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 8694EC60E; Thu, 5 Jan 2006 09:37:54 -0500 (EST) Message-ID: <026601c61205$f84dc2e0$7a1810ac@movaz.com> From: "Igor Bryskin" To: , "JP Vasseur" References: Subject: Re: [Pce] clarification on draft-ietf-pce-architecture-03.txt Date: Thu, 5 Jan 2006 09:40:27 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.6 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Cc: pce-bounces@ietf.org, pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1572816978==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1572816978== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0263_01C611DC.0F422BF0" This is a multi-part message in MIME format. ------=_NextPart_000_0263_01C611DC.0F422BF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I agree with Dimitri. Path computation is concerned only with definition of path(s) between a = set of one or more sources and a set of one or more destinations and = signaling of the resulting paths for the purpose of dynamic LSP = provisioning is just one (of many) ways how PCE technology could be = used. In my opinion all PCE related definitions should be decoupled from = LSP related definitions as much as possible. Igor ----- Original Message -----=20 From: Dimitri.Papadimitriou@alcatel.be=20 To: JP Vasseur=20 Cc: pce-bounces@ietf.org ; pce@ietf.org=20 Sent: Thursday, January 05, 2006 4:18 AM Subject: Re: [Pce] clarification on draft-ietf-pce-architecture-03.txt hi j-p see in-line=20 On Jan 4, 2006, at 6:49 PM, Dimitri.Papadimitriou@alcatel.be wrote:=20 arch. document section 6.6 mentions=20 "The path computation request may include a significant set of requirements including: - the source and destination of the path"=20 ... there is an underlying question beside this, is it the = source/destination of the LSP or is it the source/destination between = which path computation has to be performed and that may correspond to = the source/destination of the LSP itself=20 the side point is that in that the notion of path was since so far = linked to the signaling protocol hence linked to the notion of LSP, but = it in the context of a PCE this notion does not necessarily hold = anymore, e.g., one coudl request for the computation of a path between = point A and point B (A being not the sourceof the LSP and B being not = the destination of the LSP) even if there is no a 1:1 relationship = between the entity corresponding to the path between A and B and the way = the signaling protocol translate the "path segment" between A and B=20 The request applies for a path computation between a point A and a = point B (the source and destination). The text does not imply that the = source and the destination of such path correspond to the source and = destination of the TE LSP ?=20 [dp] so, the source and destination (as listed) is the source and = destination of the path to be computed and not the source and = destination of the LSP (for which this computation is requested) it is = thus worth dropping a couple of lines concerning this relationship to = avoid any further confusion; indeed, when i look at the interpretation = done in PCEP the situation is not the one described in the architecture = document=20 "7.5. END-POINTS Object=20 =20 The END-POINTS object is used in a PCReq message to specify the=20 source IP address and the destination IP address of the TE LSP = for=20 which a path computation is requested. Two END-POINTS objects = (for=20 IPv4 and IPv6) are defined." =20 this said, having the computation request scope decoupled from the LSP = reach is of primary importance thanks,=20 - dimitri;=20 _______________________________________________=20 Pce mailing list=20 Pce@lists.ietf.org=20 https://www1.ietf.org/mailman/listinfo/pce=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce -------------------------------------------------------------------------= ----- _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------=_NextPart_000_0263_01C611DC.0F422BF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I agree with Dimitri.
 
Path computation is concerned only with = definition=20 of path(s) between a set of one or more sources and a set of one or more = destinations and signaling of the resulting paths for the purpose of = dynamic LSP=20 provisioning is just one (of many) ways how PCE technology could be = used. In my=20 opinion all PCE related definitions should be decoupled from LSP related = definitions as much as possible.
 
Igor
----- Original Message -----
From:=20 Dimitri.Papadimitriou@al= catel.be=20
Cc: pce-bounces@ietf.org ; pce@ietf.org =
Sent: Thursday, January 05, = 2006 4:18=20 AM
Subject: Re: [Pce] = clarification on=20 draft-ietf-pce-architecture-03.txt


hi j-p see = in-line=20



On Jan 4, 2006, at = 6:49 PM,=20 Dimitri.Papadimitriou@alcatel.be wrote:


arch.=20 document section 6.6 mentions

   "The path = computation=20 request may include a significant set of
  requirements=20 including:

  - the source and destination of the path" =

...=20 there is an underlying question beside this, is it the = source/destination of=20 the LSP or is it the source/destination between which path computation = has to=20 be performed and that may correspond to the source/destination of the = LSP=20 itself

the side point is that in that the notion of path was = since so=20 far linked to the signaling protocol hence linked to the notion of = LSP, but it=20 in the context of a PCE this notion does not necessarily hold anymore, = e.g.,=20 one coudl request for the computation of a path between point A and = point B (A=20 being not the sourceof the LSP and B being not the destination of the = LSP)=20 even if there is no a 1:1 relationship between the entity = corresponding to the=20 path between A and B and the way the signaling protocol translate the = "path=20 segment" between A and B

The=20 request applies for a path computation between a point A and a point B = (the=20 source and destination). The text does not imply that the source and = the=20 destination of such path correspond to the source and destination of = the TE=20 LSP ?

[dp] so, the = source and=20 destination (as listed) is the source and destination of the path to = be=20 computed and not the source and destination of the LSP (for which this = computation is requested) it is thus worth dropping a couple of lines=20 concerning this relationship to avoid any further confusion; indeed, = when i=20 look at the interpretation done in PCEP the situation is not the one = described=20 in the architecture document

       "7.5. END-POINTS Object
  =  =20    
      The END-POINTS object is used in = a PCReq=20 message to specify the
      source IP address and = the=20 destination IP address of the TE LSP for
      = which a path=20 computation is requested. Two END-POINTS objects (for
  =    =20 IPv4 and IPv6) are defined."  

this said, having the computation request scope decoupled = from the LSP=20 reach is of primary importance

thanks,
- dimitri; =
_______________________________________________ =
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce=20
_______________________________________________
Pce = mailing=20 = list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce<= BR>

_______________________________________________
Pce mailing=20 = list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce<= BR> ------=_NextPart_000_0263_01C611DC.0F422BF0-- --===============1572816978== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1572816978==-- From pce-bounces@lists.ietf.org Thu Jan 05 09:54:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuWVR-0007b4-Uh; Thu, 05 Jan 2006 09:54:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuWVQ-0007az-AV for pce@megatron.ietf.org; Thu, 05 Jan 2006 09:54:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23427 for ; Thu, 5 Jan 2006 09:53:03 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuWb5-0005Bq-D1 for pce@ietf.org; Thu, 05 Jan 2006 10:00:14 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 05 Jan 2006 06:50:58 -0800 X-IronPort-AV: i="3.99,335,1131350400"; d="scan'208,217"; a="1763933161:sNHT7295523708" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k05Eoujt025323; Thu, 5 Jan 2006 06:50:56 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 Jan 2006 09:50:52 -0500 Received: from [192.168.1.101] ([10.86.240.151]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 Jan 2006 09:50:51 -0500 In-Reply-To: <026601c61205$f84dc2e0$7a1810ac@movaz.com> References: <026601c61205$f84dc2e0$7a1810ac@movaz.com> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 Message-Id: From: JP Vasseur Subject: Re: [Pce] clarification on draft-ietf-pce-architecture-03.txt Date: Thu, 5 Jan 2006 09:50:20 -0500 To: "Igor Bryskin" X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 05 Jan 2006 14:50:51.0639 (UTC) FILETIME=[6C391870:01C61207] X-Spam-Score: 0.2 (/) X-Scan-Signature: e654cfa5e44bd623be3eb2c720858b05 Cc: Dimitri Papadimitriou , pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1363161067==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============1363161067== Content-Type: multipart/alternative; boundary=Apple-Mail-98--748369221 --Apple-Mail-98--748369221 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi Igor, As I said I also agree ... and this is in line with the architecture ID. Thanks. JP. On Jan 5, 2006, at 9:40 AM, Igor Bryskin wrote: > Hi, > > I agree with Dimitri. > > Path computation is concerned only with definition of path(s) > between a set of one or more sources and a set of one or more > destinations and signaling of the resulting paths for the purpose > of dynamic LSP provisioning is just one (of many) ways how PCE > technology could be used. In my opinion all PCE related definitions > should be decoupled from LSP related definitions as much as possible. > > Igor > ----- Original Message ----- > From: Dimitri.Papadimitriou@alcatel.be > To: JP Vasseur > Cc: pce-bounces@ietf.org ; pce@ietf.org > Sent: Thursday, January 05, 2006 4:18 AM > Subject: Re: [Pce] clarification on draft-ietf-pce-architecture-03.txt > > > hi j-p see in-line > > > > On Jan 4, 2006, at 6:49 PM, Dimitri.Papadimitriou@alcatel.be wrote: > > > arch. document section 6.6 mentions > > "The path computation request may include a significant set of > requirements including: > > - the source and destination of the path" > > ... there is an underlying question beside this, is it the source/ > destination of the LSP or is it the source/destination between > which path computation has to be performed and that may correspond > to the source/destination of the LSP itself > > the side point is that in that the notion of path was since so far > linked to the signaling protocol hence linked to the notion of LSP, > but it in the context of a PCE this notion does not necessarily > hold anymore, e.g., one coudl request for the computation of a path > between point A and point B (A being not the sourceof the LSP and B > being not the destination of the LSP) even if there is no a 1:1 > relationship between the entity corresponding to the path between A > and B and the way the signaling protocol translate the "path > segment" between A and B > > The request applies for a path computation between a point A and a > point B (the source and destination). The text does not imply that > the source and the destination of such path correspond to the > source and destination of the TE LSP ? > > [dp] so, the source and destination (as listed) is the source and > destination of the path to be computed and not the source and > destination of the LSP (for which this computation is requested) it > is thus worth dropping a couple of lines concerning this > relationship to avoid any further confusion; indeed, when i look at > the interpretation done in PCEP the situation is not the one > described in the architecture document > > "7.5. END-POINTS Object > > The END-POINTS object is used in a PCReq message to specify the > source IP address and the destination IP address of the TE > LSP for > which a path computation is requested. Two END-POINTS objects > (for > IPv4 and IPv6) are defined." > > this said, having the computation request scope decoupled from the > LSP reach is of primary importance > > thanks, > - dimitri; > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > --Apple-Mail-98--748369221 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Igor,

As I said I also agree ... = and this is in line with the architecture ID.

Thanks.

JP.

O= n Jan 5, 2006, at 9:40 AM, Igor Bryskin wrote:

Hi,
=A0
=A0
Path = computation is concerned only with definition of path(s) between a set = of one or more sources and a set of one or more destinations and = signaling of the resulting paths for the purpose of dynamic LSP = provisioning is just one (of many) ways how PCE technology could be = used. In my opinion all PCE related definitions should be decoupled from = LSP related definitions as much as = possible.
=A0
----- Original = Message -----
Sent: Thursday, January 05, 2006 4:18 AM
Subject: Re: [Pce] clarification on = draft-ietf-pce-architecture-03.txt


hi j-p see = in-line=A0



On Jan 4, 2006, = at 6:49 PM, wrote:=A0


arch. document section 6.6 mentions =

=A0 =A0"The path computation request may include a = significant set of
=A0 = requirements including:

=A0 - the source and destination of = the path"

... there is an underlying question beside this, = is it the source/destination of the LSP or is it the source/destination = between which path computation has to be performed and that may = correspond to the source/destination of the LSP itself

the side point is that in that the notion of path was since = so far linked to the signaling protocol hence linked to the notion of = LSP, but it in the context of a PCE this notion does not necessarily = hold anymore, e.g., one coudl request for the computation of a path = between point A and point B (A being not the sourceof the LSP and B = being not the destination of the LSP) even if there is no a 1:1 = relationship between the entity corresponding to the path between A and = B and the way the signaling protocol translate the "path segment" = between A and B

The request applies for a path = computation between a point A and a point B (the source and = destination). The text does not imply that the source and the = destination of such path correspond to the source and destination of the = TE LSP ?=A0

[dp] so, the source and destination = (as listed) is the source and destination of the path to be computed and = not the source and destination of the LSP (for which this computation is = requested) it is thus worth dropping a couple of lines concerning this = relationship to avoid any further confusion; indeed, when i look at the = interpretation done in PCEP the situation is not the one described in = the architecture document=A0

=A0 =A0 =A0 =A0"7.5. END-POINTS = Object
=A0 =A0 =A0 =A0
=A0 =A0 =A0 The = END-POINTS object is used in a PCReq message to specify the
=A0 =A0 =A0 source IP address and the destination IP address = of the TE LSP for
=A0 =A0 =A0 = which a path computation is requested. Two END-POINTS objects (for =
=A0 =A0 =A0 IPv4 and IPv6) are defined." = =A0=A0

this said, having the computation = request scope decoupled from the LSP reach is of primary = importance

thanks,
- dimitri; =
_______________________________________________=A0
Pce mailing list=A0
=A0
=A0
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/= mailman/listinfo/pce



__________________________________= _____________
Pce mailing list
Pce@lists.ietf.org
https://www1.= ietf.org/mailman/listinfo/pce


= --Apple-Mail-98--748369221-- --===============1363161067== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1363161067==-- From pce-bounces@lists.ietf.org Thu Jan 05 10:07:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuWiO-0003TT-PA; Thu, 05 Jan 2006 10:07:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuWiM-0003TL-Ph for pce@megatron.ietf.org; Thu, 05 Jan 2006 10:07:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24960 for ; Thu, 5 Jan 2006 10:06:26 -0500 (EST) Received: from webmail.movaz.com ([70.158.43.219] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuWo4-0005cd-A4 for pce@ietf.org; Thu, 05 Jan 2006 10:13:37 -0500 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id CA69B13905; Thu, 5 Jan 2006 10:04:57 -0500 (EST) Message-ID: <029001c61209$bfd91b40$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Payam Torab" , "'Adrian Farrel'" , References: <009401c61183$31f44d80$30fea8c0@NETPTORAB> Subject: Re: [Pce] Re: Working Group Last callondraft-ietf-pce-architecture-03.txt Date: Thu, 5 Jan 2006 10:07:30 -0500 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.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, I agree with Payam on the path computation algorithm issue. When a PCC builds a path computation request, it applies a service specific policies so that the new service will meet SLA requirements. Hence PCC requires a particular set of constraints, their relaxation strategy in case they could not fully be met, optimization criterias, timing parameters, etc. but it should not control nor care which algorithm PCE selects to satisfy such a request. Besides, if a PCC requires, say, "Dijkstra_Improved_By_Payam_Torab" algorithm, how it can then verify that the specified algorithm indeed was or was not used? Igor ----- Original Message ----- From: "Payam Torab" To: "'Adrian Farrel'" ; Sent: Wednesday, January 04, 2006 6:04 PM Subject: RE: [Pce] Re: Working Group Last callondraft-ietf-pce-architecture-03.txt > Hi Adrian- The list is down to one point (algorithm > specification by PCC) thanks to your patience. > > > How about... > "A PCE-Based Network Architecture" > > [PT] Thanks. Any title other than "PCE Architecture" would satisfy > the purpose, and sorry for stress on wording. > > Are you saying that it is not possible to compute a path unless all > identifiers come from the same name space? 'Cos that is clearly not true - > the computation operates on an abstraction. > > I still don't get your point. > > [PT] My point was the following example, which you believe > is not a PCE question. So, we'll just assume TED avoids name space > clash, and it is a design issue that does not need standardization. > > You imply that the model described assumes that "PCEs have information on > other domains (aggregate or detailed) availabel a priori or upon request." > This is not the case. I think you are confused by the text... > Multiple PCE path computation with inter-PCE communication involves > coordination between distinct PCEs such that the result of the > computation performed by one PCE depends on information supplied by > other PCEs. > You assume that the "information supplied" is TE information. But it > doesn't say that. Perhaps we should clarify what this information is since > it is less than clear. > We will update this to indicate that the information is "path fragment > information". > > [PT] Yes- I was assuming the information refers to TE information. > Adding that the shared information can be path information or TE > information will serve the purpose, and no distinction between > model-based and ad hoc is necessary. > > let's look at where ad hoc routing fits in. > There are two cases: > 1. ... > 2. The alternative is that all of the routing is done before any signaling > is started. In this case, each PCE computes a segment of the path and > passes the request on to the next PCE to compute the next segment. > The segment paths are returned to the initial PCE which is able to > pass the full path to the PCC. But this is exactly the case described > in 5.4. Clearly there are variables. > - Does the initial PCE send requests to more than one other PCE? > - Does the initial PCE suggest multiple border nodes? > - Do the downstream PCEs return multiple paths with different > qualities to allow the initial PCE to choose? > If the answer to these and other questions is "no" then you have ad > hoc routing. > [PT] While ad hoc has a much simpler definition (simply no TE information > and no presumption about the sequence of domains taken), discussion > is now irrelevant and you addressed the question. > > >> Now, many people have told us that they *do* want to be able to specify > >> which algorithm is used. And this may be very valid because cheap (small, > >> local, easily accessed) PCEs might not be able to perform simultaneous > >> computation of very many paths at the same time. It would then be > necessary > >> for these PCEs to reject the request (so that the PCC could redirect it > to a > >> more sophisticated PCE) or redirect the request itself. > > > > [PT] This is a sad point that kills the black box elegance of this work. > > What happens if I come up with a modified or original algorithm in my PCE > > that outperforms existing algorithms? > > What if you do? > > 1. I do not have to exert control, just because I have control. I can > leave the choice to the PCE. > 2. However, if I don't trust your new algorithm, I should be able to > select a different one. > > In reality all algorithms have positive and negative points. > - Some are more accurate at the cost of being slower > - Some optimise for one feature ahead of other features > - Some are newly developed and untrusted > - Some work poorly in certain network contditions > > To say that the user is unable to select the algorithm, is like saying > that the user is not allowed to set the constraints. > > [PT] I am sure this is an old discussion that algorithm specification > per se is meaningless, as implementation or CPU power may be poor > for example. The only meaningful requirements are quantitative > metrics on accuracy, performance etc. As I said, if people have > asked for algorithm specification, they have > indeed asked for other requirements addressed by the algorithms. If I > am wrong, and PCC is indeed required to be able to specify an "algorithm", > then please mention that in the document. The point is let's not > walk away here, and make a declaration on algorithm issue. > > > > > Since this is a dangerous issue, let's be clear: Algorithm opacity > > is fundamental to the value of this work, and if someone is interested > > in specifying an algorithm, they are in fact interested in one or more > > high-level requirements that are addressed by that algorithm. These > > high-level requirements can be negotiated at the time of discovery, > > which is a much better time than in the middle of > > making a request and getting disappointed by a cheap PCE. I suggest we > > spell this out in the document. > > I think it is late to revisit this argument. > However, if the WG wants to change its mind, I guess that's fine. > Anyone else want to support Payam on this point? > > [PT] Thanks. Being late for my comments, I respect any decision, > but would be disappointed if we target algorithm specification. > > But, again, I think you have it on its head. The requirement that is > presented in the draft is that the PCC must be able to constrin the PCE to > do synchronized computation. That is, the PCC must be able to say "I know > this is more work for you, and I know it will chew up your CPU, and I know > it requires you to implement a more clever algorithm, but I insist that > you use synchronized computation because I want the better quality result > that will be produced." > > [PT] Ok. I see. My point was asking for "synchronized" is as > meaningless as asking for "Dijkstra": I can come up with a > synchronized algorithm that performs worse than a non-synchronized > version with respect to a metric. But, going with the popular assumption > that "Synchronized" means "better paths at the price of more CPU time", > as ill-defined as it is and as long as this meaning is clear to > every one, no objection. Reading Section 6.3, I think confusion > can be minimized if you swap the second and third paragraphs > (removing "conversely" at the beginning) > > > But suppose a PCE says "I can do fast unsynchronized computation, or slow > synchronized computation" That is, the PCE has two algorithms available. > So the PCC chooses this PCE to service its request. How will the PCE know > which algorithm to use? > > [PT] Ok. Although absolute requirements such as max path computation time > are better in this case, I can also see they are hard to measure and > therefore hard to request. > > > - Section 6.6: Perhaps reliability instread of level of robustness? > > Will you settle for the text suggested to Dimitri... > > - the levels of resiliency, reliability and robustness of the path > resources > > [PT] Yes- thanks. > > Thanks, > Payam > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jan 05 11:45:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuYFH-0001DP-3W; Thu, 05 Jan 2006 11:45:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuYFD-0001Cb-VE for pce@megatron.ietf.org; Thu, 05 Jan 2006 11:45:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07352 for ; Thu, 5 Jan 2006 11:44:28 -0500 (EST) Received: from mail.lopsys.com ([12.47.115.93] helo=mailsrv01.vasw) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuYKt-000145-1o for pce@ietf.org; Thu, 05 Jan 2006 11:51:38 -0500 Received: from NETPTORAB (net-torab.vasw [192.168.254.48]) by mailsrv01.vasw (8.13.1/8.13.1) with SMTP id k05GjAFu028497; Thu, 5 Jan 2006 11:45:11 -0500 From: "Payam Torab" To: "'JP Vasseur'" , "'Adrian Farrel'" Subject: RE: [Pce] Re: Working Group Last call ondraft-ietf-pce-architecture-03.txt Date: Thu, 5 Jan 2006 11:44:08 -0500 Message-ID: <00ae01c61217$402a7570$30fea8c0@NETPTORAB> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <2B5A8A45-553F-45C1-833D-402B76C6B3FB@cisco.com> Importance: Normal X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on localhost X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi JP - Your question got lost in the middle of text. > ad hoc routing fits in. There are two cases: > 1. The routing progresses in step with the signaling. That is, each > segment > is computed and signaled, then the next segment is computed and > signaled, and so on. In this case the each PCE is invoked > independently > and there is no cooperation or communication between PCEs. This is > the model shown in section 5.3. > 2. The alternative is that all of the routing is done before any > signaling > is > started. In this case, each PCE computes a segment of the path and > passes the request on to the next PCE to compute the next segment. > The segment paths are returned to the initial PCE which is able to > pass the full path to the PCC. > But this is exactly the case described in 5.4. > Clearly there are variables. > - Does the initial PCE send requests to more than one other PCE? > - Does the initial PCE suggest multiple border nodes? > - Do the downstream PCEs return multiple paths with different > qualities to allow the initial PCE to choose? > If the answer to these and other questions is "no" then you > have ad hoc routing. > Payam, does this explanation close the point ? [PT] Yes- Adrian's update to clarify that the shared information can be TE information or path information closed this discussion. Thanks, Payam _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jan 05 11:46:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuYGE-0001Vc-RE; Thu, 05 Jan 2006 11:46:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuYGD-0001U3-Dg for pce@megatron.ietf.org; Thu, 05 Jan 2006 11:46:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07609 for ; Thu, 5 Jan 2006 11:45:30 -0500 (EST) Received: from relay1.mail.uk.clara.net ([80.168.70.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuYLu-0001Ay-4G for pce@ietf.org; Thu, 05 Jan 2006 11:52:39 -0500 Received: from du-069-0246.access.clara.net ([217.158.132.246] helo=Puppy) by relay1.mail.uk.clara.net with esmtp (Exim 4.46) id 1EuYFg-000JbM-Id; Thu, 05 Jan 2006 16:46:16 +0000 Message-ID: <04b601c61218$0f938900$b8849ed9@Puppy> From: "Adrian Farrel" To: "Igor Bryskin" , "Payam Torab" , References: <009401c61183$31f44d80$30fea8c0@NETPTORAB> <029001c61209$bfd91b40$7a1810ac@movaz.com> Subject: Re: [Pce] Re: Working Group Last callondraft-ietf-pce-architecture-03.txt Date: Thu, 5 Jan 2006 16:49:54 -0000 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Content-Transfer-Encoding: 7bit Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, > I agree with Payam on the path computation algorithm issue. OK. Not that we're counting votes, but that's two votes. > When a PCC builds a path computation request, it applies a service specific > policies so that the new service will meet SLA requirements. Hence PCC > requires a particular set of constraints, their relaxation strategy in case > they could not fully be met, optimization criterias, timing parameters, etc. > but it should not control nor care which algorithm PCE selects to satisfy > such a request. I completely get your point that most computation constraints should be quantative/qualative. But what if it *does* care about the algorithm given more than one algorithm that meets the contraints? For example, it believes that there is a bug in Dijkstra_Improved_By_Adrian that means that bad paths are sometimes generated. So it wishes to request the use of Dijkstra_Improved_By_Igor. That would be a classic example of a service specific policy. Such a policy might simply dictate a choice between PCEs in which case no further action is necessary on the computation request. But if the chosen PCE supports both algorithms, how will you satisfy the policy? Clearly, you can't have a parameter on the computation request that says "please use the algorithm with fewest bugs". [Hint: if you say the answer is that the PCC must pass "policy" information to the PCE, you will find that this is compatible with the text in the I-D at the moment.] > Besides, if a PCC requires, say, "Dijkstra_Improved_By_Payam_Torab" > algorithm, how it can then verify that the specified algorithm indeed was or > was not used? I don't see why/how that quesiton is relevant. When a PCC requests a shortest path, how does it verify that the path returned is the shortest that was available at the time of computation? Cheers, Adrian > ----- Original Message ----- > From: "Payam Torab" > To: "'Adrian Farrel'" ; > Sent: Wednesday, January 04, 2006 6:04 PM > Subject: RE: [Pce] Re: Working Group Last > callondraft-ietf-pce-architecture-03.txt > > > > Hi Adrian- The list is down to one point (algorithm > > specification by PCC) thanks to your patience. > > > > > > How about... > > "A PCE-Based Network Architecture" > > > > [PT] Thanks. Any title other than "PCE Architecture" would satisfy > > the purpose, and sorry for stress on wording. > > > > Are you saying that it is not possible to compute a path unless all > > identifiers come from the same name space? 'Cos that is clearly not true - > > the computation operates on an abstraction. > > > > I still don't get your point. > > > > [PT] My point was the following example, which you believe > > is not a PCE question. So, we'll just assume TED avoids name space > > clash, and it is a design issue that does not need standardization. > > > > You imply that the model described assumes that "PCEs have information on > > other domains (aggregate or detailed) availabel a priori or upon request." > > This is not the case. I think you are confused by the text... > > Multiple PCE path computation with inter-PCE communication involves > > coordination between distinct PCEs such that the result of the > > computation performed by one PCE depends on information supplied by > > other PCEs. > > You assume that the "information supplied" is TE information. But it > > doesn't say that. Perhaps we should clarify what this information is since > > it is less than clear. > > We will update this to indicate that the information is "path fragment > > information". > > > > [PT] Yes- I was assuming the information refers to TE information. > > Adding that the shared information can be path information or TE > > information will serve the purpose, and no distinction between > > model-based and ad hoc is necessary. > > > > let's look at where ad hoc routing fits in. > > There are two cases: > > 1. ... > > 2. The alternative is that all of the routing is done before any signaling > > is started. In this case, each PCE computes a segment of the path and > > passes the request on to the next PCE to compute the next segment. > > The segment paths are returned to the initial PCE which is able to > > pass the full path to the PCC. But this is exactly the case described > > in 5.4. Clearly there are variables. > > - Does the initial PCE send requests to more than one other PCE? > > - Does the initial PCE suggest multiple border nodes? > > - Do the downstream PCEs return multiple paths with different > > qualities to allow the initial PCE to choose? > > If the answer to these and other questions is "no" then you have ad > > hoc routing. > > [PT] While ad hoc has a much simpler definition (simply no TE information > > and no presumption about the sequence of domains taken), discussion > > is now irrelevant and you addressed the question. > > > > >> Now, many people have told us that they *do* want to be able to specify > > >> which algorithm is used. And this may be very valid because cheap > (small, > > >> local, easily accessed) PCEs might not be able to perform simultaneous > > >> computation of very many paths at the same time. It would then be > > necessary > > >> for these PCEs to reject the request (so that the PCC could redirect it > > to a > > >> more sophisticated PCE) or redirect the request itself. > > > > > > [PT] This is a sad point that kills the black box elegance of this work. > > > What happens if I come up with a modified or original algorithm in my > PCE > > > that outperforms existing algorithms? > > > > What if you do? > > > > 1. I do not have to exert control, just because I have control. I can > > leave the choice to the PCE. > > 2. However, if I don't trust your new algorithm, I should be able to > > select a different one. > > > > In reality all algorithms have positive and negative points. > > - Some are more accurate at the cost of being slower > > - Some optimise for one feature ahead of other features > > - Some are newly developed and untrusted > > - Some work poorly in certain network contditions > > > > To say that the user is unable to select the algorithm, is like saying > > that the user is not allowed to set the constraints. > > > > [PT] I am sure this is an old discussion that algorithm specification > > per se is meaningless, as implementation or CPU power may be poor > > for example. The only meaningful requirements are quantitative > > metrics on accuracy, performance etc. As I said, if people have > > asked for algorithm specification, they have > > indeed asked for other requirements addressed by the algorithms. If I > > am wrong, and PCC is indeed required to be able to specify an "algorithm", > > then please mention that in the document. The point is let's not > > walk away here, and make a declaration on algorithm issue. > > > > > > > > > Since this is a dangerous issue, let's be clear: Algorithm opacity > > > is fundamental to the value of this work, and if someone is interested > > > in specifying an algorithm, they are in fact interested in one or more > > > high-level requirements that are addressed by that algorithm. These > > > high-level requirements can be negotiated at the time of discovery, > > > which is a much better time than in the middle of > > > making a request and getting disappointed by a cheap PCE. I suggest we > > > spell this out in the document. > > > > I think it is late to revisit this argument. > > However, if the WG wants to change its mind, I guess that's fine. > > Anyone else want to support Payam on this point? > > > > [PT] Thanks. Being late for my comments, I respect any decision, > > but would be disappointed if we target algorithm specification. > > > > But, again, I think you have it on its head. The requirement that is > > presented in the draft is that the PCC must be able to constrin the PCE to > > do synchronized computation. That is, the PCC must be able to say "I know > > this is more work for you, and I know it will chew up your CPU, and I know > > it requires you to implement a more clever algorithm, but I insist that > > you use synchronized computation because I want the better quality result > > that will be produced." > > > > [PT] Ok. I see. My point was asking for "synchronized" is as > > meaningless as asking for "Dijkstra": I can come up with a > > synchronized algorithm that performs worse than a non-synchronized > > version with respect to a metric. But, going with the popular assumption > > that "Synchronized" means "better paths at the price of more CPU time", > > as ill-defined as it is and as long as this meaning is clear to > > every one, no objection. Reading Section 6.3, I think confusion > > can be minimized if you swap the second and third paragraphs > > (removing "conversely" at the beginning) > > > > > > But suppose a PCE says "I can do fast unsynchronized computation, or slow > > synchronized computation" That is, the PCE has two algorithms available. > > So the PCC chooses this PCE to service its request. How will the PCE know > > which algorithm to use? > > > > [PT] Ok. Although absolute requirements such as max path computation time > > are better in this case, I can also see they are hard to measure and > > therefore hard to request. > > > > > - Section 6.6: Perhaps reliability instread of level of robustness? > > > > Will you settle for the text suggested to Dimitri... > > > > - the levels of resiliency, reliability and robustness of the path > > resources > > > > [PT] Yes- thanks. > > > > Thanks, > > Payam > > > > > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jan 05 12:29:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuYvb-0004AG-1R; Thu, 05 Jan 2006 12:29:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuYvZ-0004A3-Cr for pce@megatron.ietf.org; Thu, 05 Jan 2006 12:29:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14011 for ; Thu, 5 Jan 2006 12:28:13 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuZ1E-000324-OF for pce@ietf.org; Thu, 05 Jan 2006 12:35:24 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 05 Jan 2006 12:29:09 -0500 X-IronPort-AV: i="3.99,335,1131339600"; d="scan'208"; a="79494284:sNHT34797900" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k05HSbK5013009; Thu, 5 Jan 2006 12:29:06 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 Jan 2006 12:28:19 -0500 Received: from [192.168.1.101] ([10.86.240.151]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 Jan 2006 12:28:42 -0500 In-Reply-To: <04b601c61218$0f938900$b8849ed9@Puppy> References: <009401c61183$31f44d80$30fea8c0@NETPTORAB> <029001c61209$bfd91b40$7a1810ac@movaz.com> <04b601c61218$0f938900$b8849ed9@Puppy> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7D108873-3F0B-403D-9EE1-5ACDE3BA653E@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Thu, 5 Jan 2006 12:28:11 -0500 To: Adrian Farrel , pce@ietf.org, Payam Torab , Igor Bryskin X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 05 Jan 2006 17:28:42.0222 (UTC) FILETIME=[792160E0:01C6121D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8 Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] WG feed-back needed ! X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Adrian et al, On Jan 5, 2006, at 11:49 AM, Adrian Farrel wrote: > Hi, > >> I agree with Payam on the path computation algorithm issue. > > OK. Not that we're counting votes, but that's two votes. > >> When a PCC builds a path computation request, it applies a service > specific >> policies so that the new service will meet SLA requirements. Hence >> PCC >> requires a particular set of constraints, their relaxation >> strategy in > case >> they could not fully be met, optimization criterias, timing >> parameters, > etc. >> but it should not control nor care which algorithm PCE selects to > satisfy >> such a request. > > I completely get your point that most computation constraints > should be > quantative/qualative. > But what if it *does* care about the algorithm given more than one > algorithm that meets the contraints? > For example, it believes that there is a bug in > Dijkstra_Improved_By_Adrian that means that bad paths are sometimes > generated. So it wishes to request the use of > Dijkstra_Improved_By_Igor. > That would be a classic example of a service specific policy. > > Such a policy might simply dictate a choice between PCEs in which > case no > further action is necessary on the computation request. But if the > chosen > PCE supports both algorithms, how will you satisfy the policy? > > Clearly, you can't have a parameter on the computation request that > says > "please use the algorithm with fewest bugs". > > [Hint: if you say the answer is that the PCC must pass "policy" > information to the PCE, you will find that this is compatible with the > text in the I-D at the moment.] Right. Another example ... Why wouldn't these two scenario be valid ? (1) SLAs (qualitative or quantitative) are specified as objective within the path computation request without mentioning any algorithm (2) The PCEs advertise within their capability the ability to support a set of Algorithms along with their respective characteristics (e.g. in term of computational resource requirement (and consequently computation speed), path quality (and thus optimality) and so on A PCC may decide for some LSP to request the use of Algo_1 versus Algo_2 as a policy constraint. Furthermore, for a single LSP the PCC may decide to request a specific algorithm depending on the circumstances (e.g. less optimal but fast if the LSP is down and more optimal but slower for a reoptimization). It looks to me that both scenario may be required. At this point, in order to close on this last remaining open item, I'd like to pool the WG - especially Service Providers, please voice up. Thanks. > >> Besides, if a PCC requires, say, "Dijkstra_Improved_By_Payam_Torab" >> algorithm, how it can then verify that the specified algorithm indeed > was or >> was not used? > > I don't see why/how that quesiton is relevant. When a PCC requests a > shortest path, how does it verify that the path returned is the > shortest > that was available at the time of computation? > > Cheers, > Adrian > >> ----- Original Message ----- >> From: "Payam Torab" >> To: "'Adrian Farrel'" ; >> Sent: Wednesday, January 04, 2006 6:04 PM >> Subject: RE: [Pce] Re: Working Group Last >> callondraft-ietf-pce-architecture-03.txt >> >> >>> Hi Adrian- The list is down to one point (algorithm >>> specification by PCC) thanks to your patience. >>> >>> >>> How about... >>> "A PCE-Based Network Architecture" >>> >>> [PT] Thanks. Any title other than "PCE Architecture" would satisfy >>> the purpose, and sorry for stress on wording. >>> >>> Are you saying that it is not possible to compute a path unless all >>> identifiers come from the same name space? 'Cos that is clearly not > true - >>> the computation operates on an abstraction. >>> >>> I still don't get your point. >>> >>> [PT] My point was the following example, which you believe >>> is not a PCE question. So, we'll just assume TED avoids name space >>> clash, and it is a design issue that does not need standardization. >>> >>> You imply that the model described assumes that "PCEs have >>> information > on >>> other domains (aggregate or detailed) availabel a priori or upon > request." >>> This is not the case. I think you are confused by the text... >>> Multiple PCE path computation with inter-PCE communication >>> involves >>> coordination between distinct PCEs such that the result of the >>> computation performed by one PCE depends on information >>> supplied by >>> other PCEs. >>> You assume that the "information supplied" is TE information. But it >>> doesn't say that. Perhaps we should clarify what this information is > since >>> it is less than clear. >>> We will update this to indicate that the information is "path >>> fragment >>> information". >>> >>> [PT] Yes- I was assuming the information refers to TE information. >>> Adding that the shared information can be path information or TE >>> information will serve the purpose, and no distinction between >>> model-based and ad hoc is necessary. >>> >>> let's look at where ad hoc routing fits in. >>> There are two cases: >>> 1. ... >>> 2. The alternative is that all of the routing is done before any > signaling >>> is started. In this case, each PCE computes a segment of the >>> path and >>> passes the request on to the next PCE to compute the next >>> segment. >>> The segment paths are returned to the initial PCE which is >>> able to >>> pass the full path to the PCC. But this is exactly the case > described >>> in 5.4. Clearly there are variables. >>> - Does the initial PCE send requests to more than one other PCE? >>> - Does the initial PCE suggest multiple border nodes? >>> - Do the downstream PCEs return multiple paths with different >>> qualities to allow the initial PCE to choose? >>> If the answer to these and other questions is "no" then you have > ad >>> hoc routing. >>> [PT] While ad hoc has a much simpler definition (simply no TE > information >>> and no presumption about the sequence of domains taken), > discussion >>> is now irrelevant and you addressed the question. >>> >>>>> Now, many people have told us that they *do* want to be able to > specify >>>>> which algorithm is used. And this may be very valid because cheap >> (small, >>>>> local, easily accessed) PCEs might not be able to perform > simultaneous >>>>> computation of very many paths at the same time. It would then be >>> necessary >>>>> for these PCEs to reject the request (so that the PCC could > redirect it >>> to a >>>>> more sophisticated PCE) or redirect the request itself. >>>> >>>> [PT] This is a sad point that kills the black box elegance of this > work. >>>> What happens if I come up with a modified or original algorithm in > my >> PCE >>>> that outperforms existing algorithms? >>> >>> What if you do? >>> >>> 1. I do not have to exert control, just because I have control. I >>> can >>> leave the choice to the PCE. >>> 2. However, if I don't trust your new algorithm, I should be able to >>> select a different one. >>> >>> In reality all algorithms have positive and negative points. >>> - Some are more accurate at the cost of being slower >>> - Some optimise for one feature ahead of other features >>> - Some are newly developed and untrusted >>> - Some work poorly in certain network contditions >>> >>> To say that the user is unable to select the algorithm, is like >>> saying >>> that the user is not allowed to set the constraints. >>> >>> [PT] I am sure this is an old discussion that algorithm >>> specification >>> per se is meaningless, as implementation or CPU power may be poor >>> for example. The only meaningful requirements are quantitative >>> metrics on accuracy, performance etc. As I said, if people have >>> asked for algorithm specification, they have >>> indeed asked for other requirements addressed by the algorithms. >>> If I >>> am wrong, and PCC is indeed required to be able to specify an > "algorithm", >>> then please mention that in the document. The point is let's not >>> walk away here, and make a declaration on algorithm issue. >>> >>> >>> >>>> Since this is a dangerous issue, let's be clear: Algorithm opacity >>>> is fundamental to the value of this work, and if someone is > interested >>>> in specifying an algorithm, they are in fact interested in one or > more >>>> high-level requirements that are addressed by that algorithm. These >>>> high-level requirements can be negotiated at the time of discovery, >>>> which is a much better time than in the middle of >>>> making a request and getting disappointed by a cheap PCE. I suggest > we >>>> spell this out in the document. >>> >>> I think it is late to revisit this argument. >>> However, if the WG wants to change its mind, I guess that's fine. >>> Anyone else want to support Payam on this point? >>> >>> [PT] Thanks. Being late for my comments, I respect any decision, >>> but would be disappointed if we target algorithm specification. >>> >>> But, again, I think you have it on its head. The requirement that is >>> presented in the draft is that the PCC must be able to constrin the > PCE to >>> do synchronized computation. That is, the PCC must be able to say "I > know >>> this is more work for you, and I know it will chew up your CPU, >>> and I > know >>> it requires you to implement a more clever algorithm, but I insist > that >>> you use synchronized computation because I want the better quality > result >>> that will be produced." >>> >>> [PT] Ok. I see. My point was asking for "synchronized" is as >>> meaningless as asking for "Dijkstra": I can come up with a >>> synchronized algorithm that performs worse than a non-synchronized >>> version with respect to a metric. But, going with the popular > assumption >>> that "Synchronized" means "better paths at the price of more CPU > time", >>> as ill-defined as it is and as long as this meaning is clear to >>> every one, no objection. Reading Section 6.3, I think confusion >>> can be minimized if you swap the second and third paragraphs >>> (removing "conversely" at the beginning) >>> >>> >>> But suppose a PCE says "I can do fast unsynchronized computation, or > slow >>> synchronized computation" That is, the PCE has two algorithms > available. >>> So the PCC chooses this PCE to service its request. How will the PCE > know >>> which algorithm to use? >>> >>> [PT] Ok. Although absolute requirements such as max path computation > time >>> are better in this case, I can also see they are hard to measure and >>> therefore hard to request. >>> >>>> - Section 6.6: Perhaps reliability instread of level of robustness? >>> >>> Will you settle for the text suggested to Dimitri... >>> >>> - the levels of resiliency, reliability and robustness of the >>> path >>> resources >>> >>> [PT] Yes- thanks. >>> >>> Thanks, >>> Payam >>> >>> >>> _______________________________________________ >>> Pce mailing list >>> Pce@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/pce >>> >> >> >> > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jan 05 12:42:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuZ8W-0000r5-Vp; Thu, 05 Jan 2006 12:42:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuZ8W-0000qU-5g for pce@megatron.ietf.org; Thu, 05 Jan 2006 12:42:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15870 for ; Thu, 5 Jan 2006 12:41:36 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuZEC-0003iE-1p for pce@ietf.org; Thu, 05 Jan 2006 12:48:44 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 05 Jan 2006 09:42:33 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k05HgIcb012084; Thu, 5 Jan 2006 09:42:32 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 Jan 2006 12:41:47 -0500 Received: from [192.168.1.101] ([10.86.240.151]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 Jan 2006 12:42:12 -0500 In-Reply-To: <009401c61183$31f44d80$30fea8c0@NETPTORAB> References: <009401c61183$31f44d80$30fea8c0@NETPTORAB> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2581C15E-95A3-42D0-A050-1CF7E8B2E858@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Re: Working Group Last call ondraft-ietf-pce-architecture-03.txt Date: Thu, 5 Jan 2006 12:41:40 -0500 To: Payam Torab X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 05 Jan 2006 17:42:12.0332 (UTC) FILETIME=[5BFE5AC0:01C6121F] X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Content-Transfer-Encoding: 7bit Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, On Jan 4, 2006, at 6:04 PM, Payam Torab wrote: > Hi Adrian- The list is down to one point (algorithm > specification by PCC) thanks to your patience. > Glad that we're approaching a closure, thanks. See below, > > How about... > "A PCE-Based Network Architecture" > > [PT] Thanks. Any title other than "PCE Architecture" would satisfy > the purpose, and sorry for stress on wording. > I'll send an email summary on the list with three proposals, should people desire to make express their opinion. Anyway, there was a need for a title change indeed, thanks. > Are you saying that it is not possible to compute a path unless all > identifiers come from the same name space? 'Cos that is clearly not > true - > the computation operates on an abstraction. > > I still don't get your point. > > [PT] My point was the following example, which you believe > is not a PCE question. So, we'll just assume TED avoids name space > clash, and it is a design issue that does not need standardization. > > You imply that the model described assumes that "PCEs have > information on > other domains (aggregate or detailed) availabel a priori or upon > request." > This is not the case. I think you are confused by the text... > Multiple PCE path computation with inter-PCE communication involves > coordination between distinct PCEs such that the result of the > computation performed by one PCE depends on information supplied by > other PCEs. > You assume that the "information supplied" is TE information. But it > doesn't say that. Perhaps we should clarify what this information > is since > it is less than clear. > We will update this to indicate that the information is "path fragment > information". > > [PT] Yes- I was assuming the information refers to TE information. > Adding that the shared information can be path information or TE > information will serve the purpose, and no distinction between > model-based and ad hoc is necessary. > ok, point closed then. > let's look at where ad hoc routing fits in. > There are two cases: > 1. ... > 2. The alternative is that all of the routing is done before any > signaling > is started. In this case, each PCE computes a segment of the path and > passes the request on to the next PCE to compute the next segment. > The segment paths are returned to the initial PCE which is able to > pass the full path to the PCC. But this is exactly the case > described > in 5.4. Clearly there are variables. > - Does the initial PCE send requests to more than one other PCE? > - Does the initial PCE suggest multiple border nodes? > - Do the downstream PCEs return multiple paths with different > qualities to allow the initial PCE to choose? > If the answer to these and other questions is "no" then you > have ad > hoc routing. > [PT] While ad hoc has a much simpler definition (simply no TE > information > and no presumption about the sequence of domains taken), > discussion > is now irrelevant and you addressed the question. > >>> Now, many people have told us that they *do* want to be able to >>> specify >>> which algorithm is used. And this may be very valid because cheap >>> (small, >>> local, easily accessed) PCEs might not be able to perform >>> simultaneous >>> computation of very many paths at the same time. It would then be > necessary >>> for these PCEs to reject the request (so that the PCC could >>> redirect it > to a >>> more sophisticated PCE) or redirect the request itself. >> >> [PT] This is a sad point that kills the black box elegance of this >> work. >> What happens if I come up with a modified or original algorithm in >> my PCE >> that outperforms existing algorithms? > > What if you do? > > 1. I do not have to exert control, just because I have control. I can > leave the choice to the PCE. > 2. However, if I don't trust your new algorithm, I should be able to > select a different one. > > In reality all algorithms have positive and negative points. > - Some are more accurate at the cost of being slower > - Some optimise for one feature ahead of other features > - Some are newly developed and untrusted > - Some work poorly in certain network contditions > > To say that the user is unable to select the algorithm, is like saying > that the user is not allowed to set the constraints. > > [PT] I am sure this is an old discussion that algorithm specification > per se is meaningless, as implementation or CPU power may be poor > for example. The only meaningful requirements are quantitative > metrics on accuracy, performance etc. As I said, if people have > asked for algorithm specification, they have > indeed asked for other requirements addressed by the algorithms. If I > am wrong, and PCC is indeed required to be able to specify an > "algorithm", > then please mention that in the document. The point is let's not > walk away here, and make a declaration on algorithm issue. > See my other emails. Your opinion is well taken, let's see what others think. But yes indeed, we heard several people requiring algorithm selection ... > > >> Since this is a dangerous issue, let's be clear: Algorithm opacity >> is fundamental to the value of this work, and if someone is >> interested >> in specifying an algorithm, they are in fact interested in one or >> more >> high-level requirements that are addressed by that algorithm. These >> high-level requirements can be negotiated at the time of discovery, >> which is a much better time than in the middle of >> making a request and getting disappointed by a cheap PCE. I >> suggest we >> spell this out in the document. > > I think it is late to revisit this argument. > However, if the WG wants to change its mind, I guess that's fine. > Anyone else want to support Payam on this point? > > [PT] Thanks. Being late for my comments, I respect any decision, > but would be disappointed if we target algorithm specification. > > But, again, I think you have it on its head. The requirement that is > presented in the draft is that the PCC must be able to constrin the > PCE to > do synchronized computation. That is, the PCC must be able to say > "I know > this is more work for you, and I know it will chew up your CPU, and > I know > it requires you to implement a more clever algorithm, but I insist > that > you use synchronized computation because I want the better quality > result > that will be produced." > > [PT] Ok. I see. My point was asking for "synchronized" is as > meaningless as asking for "Dijkstra": I can come up with a > synchronized algorithm that performs worse than a non-synchronized > version with respect to a metric. But, going with the popular > assumption > that "Synchronized" means "better paths at the price of more CPU > time", > as ill-defined as it is and as long as this meaning is clear to > every one, no objection. Reading Section 6.3, I think confusion > can be minimized if you swap the second and third paragraphs > (removing "conversely" at the beginning) > Here I fundamentally disagree and please see the discussion that took place on this on the list and requirements ID. There are many cases where synchronization is required. A simple case: computation of N diverse paths ... Other cases are so as to minimize call set failure due to double bw allocation and so on. Unless the WG desires to change this of course. > > But suppose a PCE says "I can do fast unsynchronized computation, > or slow > synchronized computation" That is, the PCE has two algorithms > available. > So the PCC chooses this PCE to service its request. How will the > PCE know > which algorithm to use? > > [PT] Ok. Although absolute requirements such as max path > computation time > are better in this case, I can also see they are hard to measure and > therefore hard to request. > >> - Section 6.6: Perhaps reliability instread of level of robustness? > > Will you settle for the text suggested to Dimitri... > > - the levels of resiliency, reliability and robustness of the path > resources > > [PT] Yes- thanks. > Thanks. JP. > Thanks, > Payam _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jan 05 13:20:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuZj8-0007pr-Eo; Thu, 05 Jan 2006 13:20:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuZj5-0007oG-AV for pce@megatron.ietf.org; Thu, 05 Jan 2006 13:20:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22445 for ; Thu, 5 Jan 2006 13:19:23 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuZoi-00058f-9E for pce@ietf.org; Thu, 05 Jan 2006 13:26:31 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 05 Jan 2006 10:20:23 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k05IKJQL005384; Thu, 5 Jan 2006 10:20:19 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 Jan 2006 13:20:19 -0500 Received: from [192.168.1.101] ([10.86.240.151]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 Jan 2006 13:20:18 -0500 In-Reply-To: <00ae01c61217$402a7570$30fea8c0@NETPTORAB> References: <00ae01c61217$402a7570$30fea8c0@NETPTORAB> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Re: Working Group Last call ondraft-ietf-pce-architecture-03.txt Date: Thu, 5 Jan 2006 13:19:47 -0500 To: Payam Torab X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 05 Jan 2006 18:20:18.0676 (UTC) FILETIME=[AEC2C340:01C61224] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Thanks. JP. On Jan 5, 2006, at 11:44 AM, Payam Torab wrote: > Hi JP - Your question got lost in the middle of text. > >> ad hoc routing fits in. There are two cases: >> 1. The routing progresses in step with the signaling. That is, each >> segment >> is computed and signaled, then the next segment is computed and >> signaled, and so on. In this case the each PCE is invoked >> independently >> and there is no cooperation or communication between PCEs. >> This is >> the model shown in section 5.3. >> 2. The alternative is that all of the routing is done before any >> signaling >> is >> started. In this case, each PCE computes a segment of the path >> and >> passes the request on to the next PCE to compute the next >> segment. >> The segment paths are returned to the initial PCE which is >> able to >> pass the full path to the PCC. >> But this is exactly the case described in 5.4. >> Clearly there are variables. >> - Does the initial PCE send requests to more than one other PCE? >> - Does the initial PCE suggest multiple border nodes? >> - Do the downstream PCEs return multiple paths with different >> qualities to allow the initial PCE to choose? >> If the answer to these and other questions is "no" then you >> have ad hoc routing. >> > > Payam, does this explanation close the point ? > > [PT] Yes- Adrian's update to clarify that the shared information > can be TE information or path information closed this discussion. > > Thanks, > Payam _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jan 05 13:53:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuaEQ-0005GQ-TA; Thu, 05 Jan 2006 13:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuaEP-0005GB-5U for pce@megatron.ietf.org; Thu, 05 Jan 2006 13:53:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26023 for ; Thu, 5 Jan 2006 13:51:45 -0500 (EST) Received: from mail.lopsys.com ([12.47.115.93] helo=mailsrv01.vasw) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuaK8-0006OG-3i for pce@ietf.org; Thu, 05 Jan 2006 13:58:57 -0500 Received: from NETPTORAB (net-torab.vasw [192.168.254.48]) by mailsrv01.vasw (8.13.1/8.13.1) with SMTP id k05IqbKj001618; Thu, 5 Jan 2006 13:52:37 -0500 From: "Payam Torab" To: "'JP Vasseur'" Subject: RE: [Pce] Re: Working Group Last call ondraft-ietf-pce-architecture-03.txt Date: Thu, 5 Jan 2006 13:51:35 -0500 Message-ID: <00af01c61229$0e189910$30fea8c0@NETPTORAB> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <2581C15E-95A3-42D0-A050-1CF7E8B2E858@cisco.com> Importance: Normal X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on localhost X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi JP, > [PT] Ok. I see. My point was asking for "synchronized" is as > meaningless as asking for "Dijkstra": I can come up with a > synchronized algorithm that performs worse than a non-synchronized > version with respect to a metric. But, going with the popular > assumption that "Synchronized" means "better paths at the price > of more CPU time", as ill-defined as it is and as long as this > meaning is clear to every one, no objection. Reading Section 6.3, > I think confusion can be minimized if you swap the second and > third paragraphs (removing "conversely" at the beginning) > Here I fundamentally disagree and please see the discussion that took place on this on the list and requirements ID. There are many cases where synchronization is required. A simple case: computation of N diverse paths ... Other cases are so as to minimize call set failure due to double bw allocation and so on. Unless the WG desires to change this of course. [PT] Fully understand that there are nice algorithms to handle multiple path computations, with diverse paths perhaps the most important. The point is the ill definition of "synchronized": What does it really mean to PCC? to PCE? To illustrate, assume PCC asks for diverse paths and "synchronized" processing. PCE from vendor A has implemented a sophisticated algorithm that it calls synchronized (may be close to popular diverse computation algorithms). PCE from vendor B computes 1000000 alternate paths and finds disjoint paths between them, but claims it is synchronized. PCE from vendor C just cheats and processes the requests sequentially and succeeds in this example. As a PCC, you will not know the difference- and what is the point of asking for something that PCC cannot verify? What are the requirements that you as a PCC can detect, measure and verify? You can ask for a computation time of one second or less. It is up to PCE to make the best decision based on its current load (requests from other PCCs), etc. to pick the best among algorithms it supports, which may be proprietary and unnamed. You may even ask multiple PCEs and give them different requirements and pick between the paths returned. The reality is PCEs will provide better algorithms everyday, and providers will test these PCEs with known topologies, etc. to make sure they work ok with respect to algorithms. So, that was the point, but I am ok with the document at this stage, as the interface to PCE is flexible enough to support any requirements, and over time correct requirements will emerge, as we understand more. Thanks, Payam _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jan 05 13:53:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuaEu-0005Nv-VY; Thu, 05 Jan 2006 13:53:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuaEt-0005Ne-1E for pce@megatron.ietf.org; Thu, 05 Jan 2006 13:53:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26050 for ; Thu, 5 Jan 2006 13:52:15 -0500 (EST) Received: from webmail.movaz.com ([70.158.43.219] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuaKc-0006P9-7R for pce@ietf.org; Thu, 05 Jan 2006 13:59:27 -0500 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 712802E67D; Thu, 5 Jan 2006 13:50:42 -0500 (EST) Message-ID: <02ca01c61229$4955d9c0$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Adrian Farrel" , "Payam Torab" , References: <009401c61183$31f44d80$30fea8c0@NETPTORAB> <029001c61209$bfd91b40$7a1810ac@movaz.com> <04b601c61218$0f938900$b8849ed9@Puppy> Subject: Re: [Pce] Re: Working Group Last callondraft-ietf-pce-architecture-03.txt Date: Thu, 5 Jan 2006 13:53:15 -0500 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.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc Content-Transfer-Encoding: 7bit Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Adrian, Please, see in-line. Igor ----- Original Message ----- From: "Adrian Farrel" To: "Igor Bryskin" ; "Payam Torab" ; Sent: Thursday, January 05, 2006 11:49 AM Subject: Re: [Pce] Re: Working Group Last callondraft-ietf-pce-architecture-03.txt > Hi, > > > I agree with Payam on the path computation algorithm issue. > > OK. Not that we're counting votes, but that's two votes. > > > When a PCC builds a path computation request, it applies a service > specific > > policies so that the new service will meet SLA requirements. Hence PCC > > requires a particular set of constraints, their relaxation strategy in > case > > they could not fully be met, optimization criterias, timing parameters, > etc. > > but it should not control nor care which algorithm PCE selects to > satisfy > > such a request. > > I completely get your point that most computation constraints should be > quantative/qualative. > But what if it *does* care about the algorithm given more than one > algorithm that meets the contraints? > For example, it believes that there is a bug in > Dijkstra_Improved_By_Adrian that means that bad paths are sometimes > generated. So it wishes to request the use of Dijkstra_Improved_By_Igor. > That would be a classic example of a service specific policy. > IB>> Suppose a PCC explicitly asks for the Dijkstra_Improved_By_Igor. Nothing would prevent the PCE to still use the Dijkstra_Improved_By_Adrian because: a) PCE believes that all problems that happened in the past now are fixed; b) It takes less resources (and hence cheaper) while providing the same or better results. PCC gets the response and thinks that the Dijkstra_Improved_By_Igor was used. Now, if the paths prove still not to be good, PCC is even more confused because it believes that Dijkstra_Improved_By_Igor has the same problems as Dijkstra_Improved_By_Adrian used to have :=). To me requesting a particular path computation algorithm sounds as useful as requesting by an RSVP speaker from its peer a specific algorithm for label allocation or resource reservation. Note that there are precedents when a protocol speaker requires a particular algorithm from its peer. For instance, a Radius server may request MD5 or MD5 Ses or MD5 AKA algorithm for the digest computation. But this is necessary because both client and server must run the same algorithm for the operation to succeed. This is very different from the case of PCC-PCE communication. > Such a policy might simply dictate a choice between PCEs in which case no > further action is necessary on the computation request. But if the chosen > PCE supports both algorithms, how will you satisfy the policy? > > Clearly, you can't have a parameter on the computation request that says > "please use the algorithm with fewest bugs". > > [Hint: if you say the answer is that the PCC must pass "policy" > information to the PCE, you will find that this is compatible with the > text in the I-D at the moment.] > > > Besides, if a PCC requires, say, "Dijkstra_Improved_By_Payam_Torab" > > algorithm, how it can then verify that the specified algorithm indeed > was or > > was not used? > > I don't see why/how that quesiton is relevant. When a PCC requests a > shortest path, how does it verify that the path returned is the shortest > that was available at the time of computation? IB>> Well, the resulting path will asumabely come with its cost. PCC could send the request to some other PCE and get the path with a lesser cost and choose the second path. The point is that PCC only can evaluate quantative characteristics visible from outside of the PCE. Igor > > Cheers, > Adrian > > > ----- Original Message ----- > > From: "Payam Torab" > > To: "'Adrian Farrel'" ; > > Sent: Wednesday, January 04, 2006 6:04 PM > > Subject: RE: [Pce] Re: Working Group Last > > callondraft-ietf-pce-architecture-03.txt > > > > > > > Hi Adrian- The list is down to one point (algorithm > > > specification by PCC) thanks to your patience. > > > > > > > > > How about... > > > "A PCE-Based Network Architecture" > > > > > > [PT] Thanks. Any title other than "PCE Architecture" would satisfy > > > the purpose, and sorry for stress on wording. > > > > > > Are you saying that it is not possible to compute a path unless all > > > identifiers come from the same name space? 'Cos that is clearly not > true - > > > the computation operates on an abstraction. > > > > > > I still don't get your point. > > > > > > [PT] My point was the following example, which you believe > > > is not a PCE question. So, we'll just assume TED avoids name space > > > clash, and it is a design issue that does not need standardization. > > > > > > You imply that the model described assumes that "PCEs have information > on > > > other domains (aggregate or detailed) availabel a priori or upon > request." > > > This is not the case. I think you are confused by the text... > > > Multiple PCE path computation with inter-PCE communication involves > > > coordination between distinct PCEs such that the result of the > > > computation performed by one PCE depends on information supplied by > > > other PCEs. > > > You assume that the "information supplied" is TE information. But it > > > doesn't say that. Perhaps we should clarify what this information is > since > > > it is less than clear. > > > We will update this to indicate that the information is "path fragment > > > information". > > > > > > [PT] Yes- I was assuming the information refers to TE information. > > > Adding that the shared information can be path information or TE > > > information will serve the purpose, and no distinction between > > > model-based and ad hoc is necessary. > > > > > > let's look at where ad hoc routing fits in. > > > There are two cases: > > > 1. ... > > > 2. The alternative is that all of the routing is done before any > signaling > > > is started. In this case, each PCE computes a segment of the path and > > > passes the request on to the next PCE to compute the next segment. > > > The segment paths are returned to the initial PCE which is able to > > > pass the full path to the PCC. But this is exactly the case > described > > > in 5.4. Clearly there are variables. > > > - Does the initial PCE send requests to more than one other PCE? > > > - Does the initial PCE suggest multiple border nodes? > > > - Do the downstream PCEs return multiple paths with different > > > qualities to allow the initial PCE to choose? > > > If the answer to these and other questions is "no" then you have > ad > > > hoc routing. > > > [PT] While ad hoc has a much simpler definition (simply no TE > information > > > and no presumption about the sequence of domains taken), > discussion > > > is now irrelevant and you addressed the question. > > > > > > >> Now, many people have told us that they *do* want to be able to > specify > > > >> which algorithm is used. And this may be very valid because cheap > > (small, > > > >> local, easily accessed) PCEs might not be able to perform > simultaneous > > > >> computation of very many paths at the same time. It would then be > > > necessary > > > >> for these PCEs to reject the request (so that the PCC could > redirect it > > > to a > > > >> more sophisticated PCE) or redirect the request itself. > > > > > > > > [PT] This is a sad point that kills the black box elegance of this > work. > > > > What happens if I come up with a modified or original algorithm in > my > > PCE > > > > that outperforms existing algorithms? > > > > > > What if you do? > > > > > > 1. I do not have to exert control, just because I have control. I can > > > leave the choice to the PCE. > > > 2. However, if I don't trust your new algorithm, I should be able to > > > select a different one. > > > > > > In reality all algorithms have positive and negative points. > > > - Some are more accurate at the cost of being slower > > > - Some optimise for one feature ahead of other features > > > - Some are newly developed and untrusted > > > - Some work poorly in certain network contditions > > > > > > To say that the user is unable to select the algorithm, is like saying > > > that the user is not allowed to set the constraints. > > > > > > [PT] I am sure this is an old discussion that algorithm specification > > > per se is meaningless, as implementation or CPU power may be poor > > > for example. The only meaningful requirements are quantitative > > > metrics on accuracy, performance etc. As I said, if people have > > > asked for algorithm specification, they have > > > indeed asked for other requirements addressed by the algorithms. If I > > > am wrong, and PCC is indeed required to be able to specify an > "algorithm", > > > then please mention that in the document. The point is let's not > > > walk away here, and make a declaration on algorithm issue. > > > > > > > > > > > > > Since this is a dangerous issue, let's be clear: Algorithm opacity > > > > is fundamental to the value of this work, and if someone is > interested > > > > in specifying an algorithm, they are in fact interested in one or > more > > > > high-level requirements that are addressed by that algorithm. These > > > > high-level requirements can be negotiated at the time of discovery, > > > > which is a much better time than in the middle of > > > > making a request and getting disappointed by a cheap PCE. I suggest > we > > > > spell this out in the document. > > > > > > I think it is late to revisit this argument. > > > However, if the WG wants to change its mind, I guess that's fine. > > > Anyone else want to support Payam on this point? > > > > > > [PT] Thanks. Being late for my comments, I respect any decision, > > > but would be disappointed if we target algorithm specification. > > > > > > But, again, I think you have it on its head. The requirement that is > > > presented in the draft is that the PCC must be able to constrin the > PCE to > > > do synchronized computation. That is, the PCC must be able to say "I > know > > > this is more work for you, and I know it will chew up your CPU, and I > know > > > it requires you to implement a more clever algorithm, but I insist > that > > > you use synchronized computation because I want the better quality > result > > > that will be produced." > > > > > > [PT] Ok. I see. My point was asking for "synchronized" is as > > > meaningless as asking for "Dijkstra": I can come up with a > > > synchronized algorithm that performs worse than a non-synchronized > > > version with respect to a metric. But, going with the popular > assumption > > > that "Synchronized" means "better paths at the price of more CPU > time", > > > as ill-defined as it is and as long as this meaning is clear to > > > every one, no objection. Reading Section 6.3, I think confusion > > > can be minimized if you swap the second and third paragraphs > > > (removing "conversely" at the beginning) > > > > > > > > > But suppose a PCE says "I can do fast unsynchronized computation, or > slow > > > synchronized computation" That is, the PCE has two algorithms > available. > > > So the PCC chooses this PCE to service its request. How will the PCE > know > > > which algorithm to use? > > > > > > [PT] Ok. Although absolute requirements such as max path computation > time > > > are better in this case, I can also see they are hard to measure and > > > therefore hard to request. > > > > > > > - Section 6.6: Perhaps reliability instread of level of robustness? > > > > > > Will you settle for the text suggested to Dimitri... > > > > > > - the levels of resiliency, reliability and robustness of the path > > > resources > > > > > > [PT] Yes- thanks. > > > > > > Thanks, > > > Payam > > > > > > > > > _______________________________________________ > > > Pce mailing list > > > Pce@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jan 05 18:23:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EueSE-00031X-8K; Thu, 05 Jan 2006 18:23:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EueSC-00031P-CV for pce@megatron.ietf.org; Thu, 05 Jan 2006 18:23:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09407 for ; Thu, 5 Jan 2006 18:22:16 -0500 (EST) Received: from relay1.mail.uk.clara.net ([80.168.70.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EueXx-00039f-5v for pce@ietf.org; Thu, 05 Jan 2006 18:29:30 -0500 Received: from du-069-0221.access.clara.net ([217.158.132.221] helo=Puppy) by relay1.mail.uk.clara.net with esmtp (Exim 4.46) id 1EueRq-0000qa-H4; Thu, 05 Jan 2006 23:23:11 +0000 Message-ID: <058301c6124f$844b1fb0$b8849ed9@Puppy> From: "Adrian Farrel" To: "Igor Bryskin" , "Payam Torab" , References: <009401c61183$31f44d80$30fea8c0@NETPTORAB> <029001c61209$bfd91b40$7a1810ac@movaz.com> <04b601c61218$0f938900$b8849ed9@Puppy> <02ca01c61229$4955d9c0$7a1810ac@movaz.com> Subject: Re: [Pce] Re: Working Group Last callondraft-ietf-pce-architecture-03.txt Date: Thu, 5 Jan 2006 23:25:50 -0000 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, I'm not sure this is worth pursuing, but I will because I never can leave tings alone... > > > Besides, if a PCC requires, say, "Dijkstra_Improved_By_Payam_Torab" > > > algorithm, how it can then verify that the specified algorithm indeed > > > was or was not used? > > > > I don't see why/how that quesiton is relevant. When a PCC requests a > > shortest path, how does it verify that the path returned is the shortest > > that was available at the time of computation? > > IB>> Well, the resulting path will asumabely come with its cost. PCC could > send the request to some other PCE and get the path with a lesser cost and > choose the second path. The point is that PCC only can evaluate quantative > characteristics visible from outside of the PCE. Actually, you can only test whether another PCE can compute a shorter path at a different time using potentially different information. You simply cannot catch the PCE out in a lie unless you also ask it to dump its TED and do the computation yourself. Hey, and what if the PCEs were cooperating in fibbing to you. My God! It's a global conspiracy! And why would a PCE say it had used one algorithm when it had actually used another? A _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jan 05 20:07:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eug4V-0004Ct-3t; Thu, 05 Jan 2006 20:07:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eug4T-0004Aj-Ji for pce@megatron.ietf.org; Thu, 05 Jan 2006 20:07:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20017 for ; Thu, 5 Jan 2006 20:05:53 -0500 (EST) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EugAE-00071A-CC for pce@ietf.org; Thu, 05 Jan 2006 20:13:08 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3) with ESMTP id k0616smU020732; Fri, 6 Jan 2006 02:06:54 +0100 In-Reply-To: <058301c6124f$844b1fb0$b8849ed9@Puppy> To: Adrian Farrel Subject: Re: [Pce] Re: Working Group Last callondraft-ietf-pce-architecture-03.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Fri, 6 Jan 2006 02:06:52 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 01/06/2006 02:06:54, Serialize complete at 01/06/2006 02:06:54 X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.3 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: pce-bounces@ietf.org, pce@ietf.org, Payam Torab X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1972265316==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multipart message in MIME format. --===============1972265316== Content-Type: multipart/alternative; boundary="=_alternative 00061F90C12570EE_=" This is a multipart message in MIME format. --=_alternative 00061F90C12570EE_= Content-Type: text/plain; charset="US-ASCII" adrian - this is what is called reliability a system does what it claims to do; more specifically the question is not there, the question is whether one can trust the delegation of a given computation such that the PCC receives an answer inline with its request the other side issue is whether the PCE architecture model does also include 1) PCE performance objectives and 2) if those have to be taken into account during PCE selection by the PCC(s) if this is the case the latter shall be translated in the same way as you translate other objectives on the computation task result (such as "maximize residual bandwidth on most loaded links" or "shortest bounded delay path") in terms of resource consumption vs computation result speed; but there is no need tell how this objective is achieved thanks, - dimitri. "Adrian Farrel" Sent by: pce-bounces@lists.ietf.org 06/01/2006 00:25 Please respond to Adrian Farrel To: "Igor Bryskin" , "Payam Torab" , cc: Subject: Re: [Pce] Re: Working Group Last callondraft-ietf-pce-architecture-03.txt Hi, I'm not sure this is worth pursuing, but I will because I never can leave tings alone... > > > Besides, if a PCC requires, say, "Dijkstra_Improved_By_Payam_Torab" > > > algorithm, how it can then verify that the specified algorithm indeed > > > was or was not used? > > > > I don't see why/how that quesiton is relevant. When a PCC requests a > > shortest path, how does it verify that the path returned is the shortest > > that was available at the time of computation? > > IB>> Well, the resulting path will asumabely come with its cost. PCC could > send the request to some other PCE and get the path with a lesser cost and > choose the second path. The point is that PCC only can evaluate quantative > characteristics visible from outside of the PCE. Actually, you can only test whether another PCE can compute a shorter path at a different time using potentially different information. You simply cannot catch the PCE out in a lie unless you also ask it to dump its TED and do the computation yourself. Hey, and what if the PCEs were cooperating in fibbing to you. My God! It's a global conspiracy! And why would a PCE say it had used one algorithm when it had actually used another? A _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --=_alternative 00061F90C12570EE_= Content-Type: text/html; charset="US-ASCII"
adrian - this is what is called reliability a system does what it claims to do; more specifically the question is not there, the question is whether one can trust the delegation of a given computation such that the PCC receives an answer inline with its request

the other side issue is whether the PCE architecture model does also include 1) PCE performance objectives and 2) if those have to be taken into account during PCE selection by the PCC(s)
 
if this is the case the latter shall be translated in the same way as you translate other objectives on the computation task result (such as "maximize residual bandwidth on most loaded links" or "shortest bounded delay path") in terms of resource consumption vs computation result speed; but there is no need tell how this objective is achieved

thanks,
- dimitri.



"Adrian Farrel" <adrian@olddog.co.uk>
Sent by: pce-bounces@lists.ietf.org

06/01/2006 00:25
Please respond to Adrian Farrel

       
        To:        "Igor Bryskin" <ibryskin@movaz.com>, "Payam Torab" <ptorab@lopsys.com>, <pce@ietf.org>
        cc:        
        Subject:        Re: [Pce] Re: Working Group Last        callondraft-ietf-pce-architecture-03.txt



Hi,

I'm not sure this is worth pursuing, but I will because I never can leave
tings alone...

> > > Besides, if a PCC requires, say, "Dijkstra_Improved_By_Payam_Torab"
> > > algorithm, how it can then verify that the specified algorithm
indeed
> > > was or was not used?
> >
> > I don't see why/how that quesiton is relevant. When a PCC requests a
> > shortest path, how does it verify that the path returned is the
shortest
> > that was available at the time of computation?
>
> IB>> Well, the resulting path will asumabely come with its cost. PCC
could
> send the request to some other PCE and get the path with a lesser cost
and
> choose the second path. The point is that PCC only can evaluate
quantative
> characteristics visible from outside of the PCE.

Actually, you can only test whether another PCE can compute a shorter path
at a different time using potentially different information. You simply
cannot catch the PCE out in a lie unless you also ask it to dump its TED
and do the computation yourself.

Hey, and what if the PCEs were cooperating in fibbing to you. My God! It's
a global conspiracy!

And why would a PCE say it had used one algorithm when it had actually
used another?

A


_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce
--=_alternative 00061F90C12570EE_=-- --===============1972265316== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1972265316==-- From pce-bounces@lists.ietf.org Fri Jan 06 11:23:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuuNh-0002WF-3j; Fri, 06 Jan 2006 11:23:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuuNe-0002W3-N9 for pce@megatron.ietf.org; Fri, 06 Jan 2006 11:23:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11795 for ; Fri, 6 Jan 2006 11:22:37 -0500 (EST) Received: from webmail.movaz.com ([70.158.43.219] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuuTY-0006ie-S2 for pce@ietf.org; Fri, 06 Jan 2006 11:30:02 -0500 Received: from ib (vpn23.atlanta.movaz.com [172.18.0.23]) by jera.movaz.com (Postfix) with SMTP id 2C3EE2DFCD; Fri, 6 Jan 2006 11:20:55 -0500 (EST) Message-ID: <00e101c612dd$890f9510$6601a8c0@movaz.com> From: "Igor Bryskin" To: "Adrian Farrel" , "Payam Torab" , References: <009401c61183$31f44d80$30fea8c0@NETPTORAB> <029001c61209$bfd91b40$7a1810ac@movaz.com> <04b601c61218$0f938900$b8849ed9@Puppy> <02ca01c61229$4955d9c0$7a1810ac@movaz.com> <058301c6124f$844b1fb0$b8849ed9@Puppy> Subject: Re: [Pce] Re: Working Group Last callondraft-ietf-pce-architecture-03.txt Date: Fri, 6 Jan 2006 11:23:31 -0500 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.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Adrian, Please see in-line. Igor ----- Original Message ----- From: "Adrian Farrel" To: "Igor Bryskin" ; "Payam Torab" ; Sent: Thursday, January 05, 2006 6:25 PM Subject: Re: [Pce] Re: Working Group Last callondraft-ietf-pce-architecture-03.txt > Hi, > > I'm not sure this is worth pursuing, but I will because I never can leave > tings alone... > > > > > Besides, if a PCC requires, say, "Dijkstra_Improved_By_Payam_Torab" > > > > algorithm, how it can then verify that the specified algorithm > indeed > > > > was or was not used? > > > > > > I don't see why/how that quesiton is relevant. When a PCC requests a > > > shortest path, how does it verify that the path returned is the > shortest > > > that was available at the time of computation? > > > > IB>> Well, the resulting path will asumabely come with its cost. PCC > could > > send the request to some other PCE and get the path with a lesser cost > and > > choose the second path. The point is that PCC only can evaluate > quantative > > characteristics visible from outside of the PCE. > > Actually, you can only test whether another PCE can compute a shorter path > at a different time using potentially different information. You simply > cannot catch the PCE out in a lie unless you also ask it to dump its TED > and do the computation yourself. > > Hey, and what if the PCEs were cooperating in fibbing to you. My God! It's > a global conspiracy! > > And why would a PCE say it had used one algorithm when it had actually > used another? Hey, a) Because it can b) Because it is a good marketing point - I can sell more PCEs if I claim that I support Dijkstra_Improved_By_Igor We agreed long time ago that we do not standardize path computation algorithms. So what does it mean that my PCE supports Dijkstra_Improved_By_Igor? It means pretty much nothing because even if this is a published algorithm anybody can add any tweaks he wants and still claim that this is Dijkstra_Improved_By_Igor. So in IMO it does not make any sense to neither advertise nor request path computation algorithms. Igor > > A > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jan 06 12:21:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuvHn-0003ET-Uk; Fri, 06 Jan 2006 12:21:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuvHm-0003EO-RO for pce@megatron.ietf.org; Fri, 06 Jan 2006 12:21:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16222 for ; Fri, 6 Jan 2006 12:20:38 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuvNi-0000FU-2E for pce@ietf.org; Fri, 06 Jan 2006 12:28:02 -0500 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k06HLWs07333; Fri, 6 Jan 2006 12:21:32 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Re: Working Group Lastcallondraft-ietf-pce-architecture-03.txt Date: Fri, 6 Jan 2006 12:21:30 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB646507BB7DFD@zcarhxm1.corp.nortel.com> Thread-Topic: [Pce] Re: Working Group Lastcallondraft-ietf-pce-architecture-03.txt Thread-Index: AcYS3fqj978XUJMNR4qbLMl2GhEEUwABdeCQ From: "Darek Skalecki" To: "Igor Bryskin" , "Adrian Farrel" , "Payam Torab" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org It has been interesting to watch this discussion from the sidelines but now I want to jump in and side with Igor that we should not advertise or request actual path computation algorithms. I also recall that actual computation algorithms were always purposefully left out of standardization. All that should be advertised by a PCE is what it can compute, i.e. - shortest path - shortest pair of diverse paths with respect to nodes and/or links and or SRLGs - etc.=20 By the way, since one PCE can forward a particular PCReq to another PCE, what should it advertise? If the answer is a union of all its and other PCEs capabilities then this can get really messy when availability of PCEs in the network changes due to failures, etc. =20 Darek Darek Skalecki Optical Networks Nortel dareks@nortel.com -----Original Message----- From: pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] On Behalf Of Igor Bryskin Sent: January 6, 2006 11:24 AM To: Adrian Farrel; Payam Torab; pce@ietf.org Subject: Re: [Pce] Re: Working Group Lastcallondraft-ietf-pce-architecture-03.txt Adrian, Please see in-line. Igor ----- Original Message -----=20 From: "Adrian Farrel" To: "Igor Bryskin" ; "Payam Torab" ; Sent: Thursday, January 05, 2006 6:25 PM Subject: Re: [Pce] Re: Working Group Last callondraft-ietf-pce-architecture-03.txt > Hi, > > I'm not sure this is worth pursuing, but I will because I never can=20 > leave tings alone... > > > > > Besides, if a PCC requires, say,=20 > > > > "Dijkstra_Improved_By_Payam_Torab" > > > > algorithm, how it can then verify that the specified algorithm > indeed > > > > was or was not used? > > > > > > I don't see why/how that quesiton is relevant. When a PCC requests > > > a shortest path, how does it verify that the path returned is the > shortest > > > that was available at the time of computation? > > > > IB>> Well, the resulting path will asumabely come with its cost. PCC > could > > send the request to some other PCE and get the path with a lesser=20 > > cost > and > > choose the second path. The point is that PCC only can evaluate > quantative > > characteristics visible from outside of the PCE. > > Actually, you can only test whether another PCE can compute a shorter=20 > path at a different time using potentially different information. You=20 > simply cannot catch the PCE out in a lie unless you also ask it to=20 > dump its TED and do the computation yourself. > > Hey, and what if the PCEs were cooperating in fibbing to you. My God!=20 > It's a global conspiracy! > > And why would a PCE say it had used one algorithm when it had actually > used another? Hey, a) Because it can b) Because it is a good marketing point - I can sell more PCEs if I claim that I support Dijkstra_Improved_By_Igor We agreed long time ago that we do not standardize path computation algorithms. So what does it mean that my PCE supports Dijkstra_Improved_By_Igor? It means pretty much nothing because even if this is a published algorithm anybody can add any tweaks he wants and still claim that this is Dijkstra_Improved_By_Igor. So in IMO it does not make any sense to neither advertise nor request path computation algorithms. Igor > > A > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jan 06 16:18:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuyuO-0005uk-BZ; Fri, 06 Jan 2006 16:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuyuL-0005nS-FR for pce@megatron.ietf.org; Fri, 06 Jan 2006 16:13:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11883 for ; Fri, 6 Jan 2006 16:12:40 -0500 (EST) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Euz0I-0001x3-Rf for pce@ietf.org; Fri, 06 Jan 2006 16:20:07 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3) with ESMTP id k06LDbnP017116; Fri, 6 Jan 2006 22:13:38 +0100 In-Reply-To: <9473683187ADC049A855ED2DA739ABCA09FA9842@KCCLUST06EVS1.ugd.att.com> To: "Ash, Gerald R \(Jerry\), ALABS" Subject: Re: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Fri, 6 Jan 2006 22:13:36 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 01/06/2006 22:13:37, Serialize complete at 01/06/2006 22:13:37 X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.8 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 Cc: pce-bounces@ietf.org, pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1039911199==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multipart message in MIME format. --===============1039911199== Content-Type: multipart/alternative; boundary="=_alternative 00749A6CC12570EE_=" This is a multipart message in MIME format. --=_alternative 00749A6CC12570EE_= Content-Type: text/plain; charset="US-ASCII" hi jerry section 6.1.17 mentions The PCECP MUST support the following "unsynchronized" objective functions: o Minimum cost path (shortest path) o Least loaded path (widest path) o To be determined not sure to understand the last bullet, this said by mandating multiple functions, there is no "simple" default anymore one should assess the impact of such implication section 6.3.14 " The path computation request message MUST support TE LSP path reoptimization and the inclusion of a previously computed path." i don't understand the sentence, how a message can support re-optimization; i think you mean here that an indication is required as part of the message ? btw, the only that differentiates the path request for re-routing vs re-optimization is timing, and that the former must support inclusion of the failed element and the "old path" this is not the case for re-optimization " This will help ensure optimal routing of a reoptimized path, since it will allow the PCE to avoid double bandwidth accounting and help reduce blocking issues." the fact of giving the "old path" is not an indication of avoiding double bandwidth accounting (it is linked to make-before-break process) nor ensuring optimal routing thanks, - dimitri. "Ash, Gerald R \(Jerry\), ALABS" Sent by: pce-bounces@lists.ietf.org 28/12/2005 18:18 To: cc: Subject: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt Hi All, Please review and comment on the updated version of the PCE communications protocol (PCECP) generic requirements I-D http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req s-03.txt. Per our agreements at IETF-64 (see JL's slide at http://www3.ietf.org/proceedings/05nov/slides/pce-11/sld7.htm), the referenced requirements in the inter-area PCECP requirements draft have been moved into the generic PCECP requirements draft. In particular, - Section 6.1.17 'Objective Functions Supported' was added - Section 6.3.4 'LSP Rerouting & Reoptimization' was updated Our objective is to start a WG last call soon. We look forward to your review and comments. Thanks, Regards, Jerry -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, December 28, 2005 10:50 AM To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.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 : PCE Communication Protocol Generic Requirements Author(s) : J. Le Roux, J. Ash Filename : draft-ietf-pce-comm-protocol-gen-reqs-03.txt Pages : 22 Date : 2005-12-28 The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req s-03.txt _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --=_alternative 00749A6CC12570EE_= Content-Type: text/html; charset="US-ASCII"
hi jerry

section 6.1.17 mentions

The PCECP MUST support the following "unsynchronized" objective
  functions:

  o Minimum cost path (shortest path)
  o Least loaded path (widest path)
  o To be determined

not  sure to understand the last bullet, this said by mandating multiple functions, there is no "simple" default anymore one should assess the impact of such implication

section 6.3.14

"  The path computation request message MUST support TE LSP path
 reoptimization and the inclusion of a previously computed path."

i don't understand the sentence, how a message can support re-optimization; i think you mean here that an indication is required as part of the message ?

btw, the only that differentiates the path request for re-routing vs re-optimization is timing, and that the former must support inclusion of the failed element and the "old path" this is not the case for re-optimization

" This will help ensure optimal routing of a reoptimized path, since it will
 allow the PCE to avoid double bandwidth accounting and help reduce
 blocking issues."

the fact of giving the "old path" is not an indication of avoiding double bandwidth accounting (it is linked to make-before-break process) nor ensuring optimal routing

thanks,
- dimitri.



"Ash, Gerald R \(Jerry\), ALABS" <gash@att.com>
Sent by: pce-bounces@lists.ietf.org

28/12/2005 18:18

       
        To:        <pce@ietf.org>
        cc:        
        Subject:        [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt



Hi All,

Please review and comment on the updated version of the PCE
communications protocol (PCECP) generic requirements I-D
http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req
s-03.txt.

Per our agreements at IETF-64 (see JL's slide at
http://www3.ietf.org/proceedings/05nov/slides/pce-11/sld7.htm), the
referenced requirements in the inter-area PCECP requirements draft have
been moved into the generic PCECP requirements draft.  In particular,

- Section 6.1.17 'Objective Functions Supported' was added
- Section 6.3.4 'LSP Rerouting & Reoptimization' was updated

Our objective is to start a WG last call soon.  We look forward to your
review and comments.

Thanks,
Regards,
Jerry

-----Original Message-----
From: i-d-announce-bounces@ietf.org
[mailto:i-d-announce-bounces@ietf.org] On Behalf Of
Internet-Drafts@ietf.org
Sent: Wednesday, December 28, 2005 10:50 AM
To: i-d-announce@ietf.org
Cc: pce@ietf.org
Subject: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.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                                  : PCE Communication Protocol Generic
Requirements
                Author(s)                 : J. Le Roux, J. Ash
                Filename                 : draft-ietf-pce-comm-protocol-gen-reqs-03.txt
                Pages                                  : 22
                Date                                  : 2005-12-28
               
The PCE model is described in the "PCE Architecture" document and
  facilitates path computation requests from Path Computation Clients
  (PCCs) to Path Computation Elements (PCEs).  This document specifies
  generic requirements for a communication protocol between PCCs and
  PCEs, and also between PCEs where cooperation between PCEs is
  desirable.  Subsequent documents will specify application-specific
  requirements for the PCE communication protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req
s-03.txt

_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce
--=_alternative 00749A6CC12570EE_=-- --===============1039911199== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1039911199==-- From pce-bounces@lists.ietf.org Fri Jan 06 17:52:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ev0S3-0008Ru-ST; Fri, 06 Jan 2006 17:52:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ev0S1-0008Oi-QM for pce@megatron.ietf.org; Fri, 06 Jan 2006 17:52:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18750 for ; Fri, 6 Jan 2006 17:51:32 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ev0Y0-0004sT-6J for pce@ietf.org; Fri, 06 Jan 2006 17:59:00 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 06 Jan 2006 14:52:40 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,339,1131350400"; d="scan'208,217"; a="19180071:sNHT41412552" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k06MqZJh001499; Fri, 6 Jan 2006 17:52:37 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 6 Jan 2006 17:52:34 -0500 Received: from [192.168.1.101] ([10.86.240.56]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 6 Jan 2006 17:52:30 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Message-Id: <44B1B751-9B55-4FB8-9472-F3E34B0A859A@cisco.com> From: JP Vasseur Subject: Re: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt Date: Fri, 6 Jan 2006 17:51:58 -0500 To: Dimitri.Papadimitriou@alcatel.be X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 06 Jan 2006 22:52:30.0676 (UTC) FILETIME=[DFCDF140:01C61313] X-Spam-Score: 0.6 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0946124413==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============0946124413== Content-Type: multipart/alternative; boundary=Apple-Mail-136--633071278 --Apple-Mail-136--633071278 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi, On Jan 6, 2006, at 4:13 PM, Dimitri.Papadimitriou@alcatel.be wrote: > > hi jerry > > section 6.1.17 mentions > > The PCECP MUST support the following "unsynchronized" objective > functions: > > o Minimum cost path (shortest path) > o Least loaded path (widest path) > o To be determined > > not sure to understand the last bullet, this said by mandating > multiple functions, there is no "simple" default anymore one should > assess the impact of such implication > Right. > section 6.3.14 > > " The path computation request message MUST support TE LSP path > reoptimization and the inclusion of a previously computed path." > > i don't understand the sentence, how a message can support re- > optimization; i think you mean here that an indication is required > as part of the message ? > > btw, the only that differentiates the path request for re-routing > vs re-optimization is timing, and that the former must support > inclusion of the failed element and the "old path" this is not the > case for re-optimization > > " This will help ensure optimal routing of a reoptimized path, > since it will > allow the PCE to avoid double bandwidth accounting and help reduce > blocking issues." > > the fact of giving the "old path" is not an indication of avoiding > double bandwidth accounting (it is linked to make-before-break > process) nor ensuring optimal routing > Well this is easy to understand. You must be able to differentiate the two following cases: (1) PCC requests a path computation for a new LSP (2) PCC requests a path computation for an existing LSP: this refers to as the reoptimization case and of course, the PCC needs to provide the existing path to avoid double bandwidth accounting that could lead to sub-optimal path ... JP. > thanks, > - dimitri. > > > > "Ash, Gerald R \(Jerry\), ALABS" > Sent by: pce-bounces@lists.ietf.org > 28/12/2005 18:18 > > > To: > cc: > Subject: [Pce] RE: I-D ACTION:draft-ietf-pce-comm- > protocol-gen-reqs-03.txt > > > > Hi All, > > Please review and comment on the updated version of the PCE > communications protocol (PCECP) generic requirements I-D > http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol- > gen-req > s-03.txt. > > Per our agreements at IETF-64 (see JL's slide at > http://www3.ietf.org/proceedings/05nov/slides/pce-11/sld7.htm), the > referenced requirements in the inter-area PCECP requirements draft > have > been moved into the generic PCECP requirements draft. In particular, > > - Section 6.1.17 'Objective Functions Supported' was added > - Section 6.3.4 'LSP Rerouting & Reoptimization' was updated > > Our objective is to start a WG last call soon. We look forward to > your > review and comments. > > Thanks, > Regards, > Jerry > > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Wednesday, December 28, 2005 10:50 AM > To: i-d-announce@ietf.org > Cc: pce@ietf.org > Subject: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.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 : PCE > Communication Protocol Generic > Requirements > Author(s) : J. Le Roux, J. Ash > Filename : draft-ietf-pce-comm- > protocol-gen-reqs-03.txt > Pages : 22 > Date : 2005-12-28 > > The PCE model is described in the "PCE Architecture" document and > facilitates path computation requests from Path Computation Clients > (PCCs) to Path Computation Elements (PCEs). This document specifies > generic requirements for a communication protocol between PCCs and > PCEs, and also between PCEs where cooperation between PCEs is > desirable. Subsequent documents will specify application-specific > requirements for the PCE communication protocol. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol- > gen-req > s-03.txt > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-136--633071278 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

On Jan 6, = 2006, at 4:13 PM, Dimitri.Papadimitriou@alc= atel.be wrote:


hi jerry

section 6.1.17 mentions

The PCECP MUST support the following = "unsynchronized" objective
=A0 functions:

=A0 o Minimum = cost path (shortest path)
=A0 o Least loaded path (widest path)
= =A0 o To be determined

not =A0sure to understand the last bullet, this said by mandating = multiple functions, there is no "simple" default anymore one should = assess the impact of such implication
=

Right.

section = 6.3.14

" =A0The = path computation request message MUST support TE LSP path
= =A0reoptimization and the inclusion of a previously computed = path."

i don't = understand the sentence, how a message can support re-optimization; i = think you mean here that an indication is required as part of the = message ?

btw, the = only that differentiates the path request for re-routing vs = re-optimization is timing, and that the former must support inclusion of = the failed element and the "old path" this is not the case for = re-optimization

" = This will help ensure optimal routing of a reoptimized path, since it = will
=A0allow the PCE to avoid double bandwidth accounting and help = reduce
=A0blocking issues."

the fact of giving the "old path" is not an = indication of avoiding double bandwidth accounting (it is linked to = make-before-break process) nor ensuring optimal routing
=

Well this is easy to = understand. You must be able to differentiate the two following = cases:
(1) PCC requests a path computation for a new = LSP
(2) PCC requests a path computation for an existing LSP: = this refers to as the reoptimization case and of course, the PCC needs = to provide the existing path to avoid double bandwidth accounting that = could lead to sub-optimal path ...

JP.

thanks, =
- dimitri.

=

= "Ash, Gerald R = \(Jerry\), ALABS" <gash@att.com>
Sent by: pce-bounces@lists.ietf.org<= /FONT>

28/12/2005 18:18 =

=A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 To: =A0 =A0 =A0 = =A0<pce@ietf.org> =
=A0 =A0 =A0 =A0 cc: =A0 =A0 =A0 = =A0
=A0 =A0 =A0 =A0 = Subject: =A0 =A0 =A0 =A0[Pce] RE: I-D = ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt



Hi All,

Please = review and comment on the updated version of the PCE
communications = protocol (PCECP) generic requirements I-D
http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-g= en-req
s-03.txt.

Per our agreements at IETF-64 (see = JL's slide at
htt= p://www3.ietf.org/proceedings/05nov/slides/pce-11/sld7.htm), the
= referenced requirements in the inter-area PCECP requirements draft = have
been moved into the generic PCECP requirements draft. =A0In = particular,

- Section 6.1.17 'Objective Functions Supported' = was added
- Section 6.3.4 'LSP Rerouting & Reoptimization' was = updated

Our objective is to start a WG last call soon. =A0We = look forward to your
review and comments.

Thanks,
= Regards,
Jerry

-----Original Message-----
From: i-d-announce-bounces@ietf.or= g
[mailto:i-d-announce-bounces@= ietf.org] On Behalf Of
Internet-Drafts@ietf.org
= Sent: Wednesday, December 28, 2005 10:50 AM
To: i-d-announce@ietf.org
Cc: = pce@ietf.org
Subject: I-D = ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.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.

=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0: PCE Communication Protocol Generic
Requirements
=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : J. = Le Roux, J. Ash
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 : draft-ietf-pce-comm-protocol-gen-reqs-03.txt
=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0: 22
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = Date =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: = 2005-12-28
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
The PCE model is = described in the "PCE Architecture" document and
=A0 facilitates = path computation requests from Path Computation Clients
=A0 (PCCs) = to Path Computation Elements (PCEs). =A0This document specifies
=A0 = generic requirements for a communication protocol between PCCs and
=A0= PCEs, and also between PCEs where cooperation between PCEs is
=A0 = desirable. =A0Subsequent documents will specify application-specific
= =A0 requirements for the PCE communication protocol.

A URL for = this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-g= en-req
s-03.txt

= _______________________________________________
Pce mailing list
= Pce@lists.ietf.org
https://www1.ietf.org/= mailman/listinfo/pce
Pce mailing list
=

= --Apple-Mail-136--633071278-- --===============0946124413== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0946124413==-- From pce-bounces@lists.ietf.org Fri Jan 06 18:15:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ev0oL-0007cC-4x; Fri, 06 Jan 2006 18:15:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ev0oJ-0007bw-Na for pce@megatron.ietf.org; Fri, 06 Jan 2006 18:15:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20020 for ; Fri, 6 Jan 2006 18:14:35 -0500 (EST) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ev0uF-0005Sf-EN for pce@ietf.org; Fri, 06 Jan 2006 18:22:02 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3) with ESMTP id k06NFW5i027802; Sat, 7 Jan 2006 00:15:32 +0100 In-Reply-To: <44B1B751-9B55-4FB8-9472-F3E34B0A859A@cisco.com> To: JP Vasseur Subject: Re: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Sat, 7 Jan 2006 00:15:30 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 01/07/2006 00:15:32, Serialize complete at 01/07/2006 00:15:32 X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 1.2 (+) X-Scan-Signature: 841b5d6ad57042632519d2198f34cc8d Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0566820473==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multipart message in MIME format. --===============0566820473== Content-Type: multipart/alternative; boundary="=_alternative 007FC359C12570EE_=" This is a multipart message in MIME format. --=_alternative 007FC359C12570EE_= Content-Type: text/plain; charset="US-ASCII" hi - see in-line On Jan 6, 2006, at 4:13 PM, Dimitri.Papadimitriou@alcatel.be wrote: hi jerry section 6.1.17 mentions The PCECP MUST support the following "unsynchronized" objective functions: o Minimum cost path (shortest path) o Least loaded path (widest path) o To be determined not sure to understand the last bullet, this said by mandating multiple functions, there is no "simple" default anymore one should assess the impact of such implication Right. section 6.3.14 " The path computation request message MUST support TE LSP path reoptimization and the inclusion of a previously computed path." i don't understand the sentence, how a message can support re-optimization; i think you mean here that an indication is required as part of the message ? btw, the only that differentiates the path request for re-routing vs re-optimization is timing, and that the former must support inclusion of the failed element and the "old path" this is not the case for re-optimization " This will help ensure optimal routing of a reoptimized path, since it will allow the PCE to avoid double bandwidth accounting and help reduce blocking issues." the fact of giving the "old path" is not an indication of avoiding double bandwidth accounting (it is linked to make-before-break process) nor ensuring optimal routing Well this is easy to understand. You must be able to differentiate the two following cases: (1) PCC requests a path computation for a new LSP (2) PCC requests a path computation for an existing LSP: this refers to as the reoptimization case and of course, the PCC needs to provide the existing path to avoid double bandwidth accounting that could lead to sub-optimal path ... [dp] understood but the answer depends on the first point i.e. is there an explicit indication for re-optimzation or not - the sentence says "and" the inclusion so i consider this is an information put in addition of the explicit indication ? please confirm or infirm because the sentence is open to interpetation; [dp] now, the only purpose for having this additional information is to force the "new path" to make use as much as possible of the "old path" such as to minimize the sum of the resources required by the old and the new path during the transient period of re-optimization (hence, including the "old path" is not an indication for avoiding double booking it is an indication for minimizing the transient resource required for the re-optimization) JP. thanks, - dimitri. "Ash, Gerald R \(Jerry\), ALABS" Sent by: pce-bounces@lists.ietf.org 28/12/2005 18:18 To: cc: Subject: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt Hi All, Please review and comment on the updated version of the PCE communications protocol (PCECP) generic requirements I-D http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req s-03.txt. Per our agreements at IETF-64 (see JL's slide at http://www3.ietf.org/proceedings/05nov/slides/pce-11/sld7.htm), the referenced requirements in the inter-area PCECP requirements draft have been moved into the generic PCECP requirements draft. In particular, - Section 6.1.17 'Objective Functions Supported' was added - Section 6.3.4 'LSP Rerouting & Reoptimization' was updated Our objective is to start a WG last call soon. We look forward to your review and comments. Thanks, Regards, Jerry -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, December 28, 2005 10:50 AM To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.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 : PCE Communication Protocol Generic Requirements Author(s) : J. Le Roux, J. Ash Filename : draft-ietf-pce-comm-protocol-gen-reqs-03.txt Pages : 22 Date : 2005-12-28 The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req s-03.txt _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --=_alternative 007FC359C12570EE_= Content-Type: text/html; charset="US-ASCII"
hi - see in-line



On Jan 6, 2006, at 4:13 PM, Dimitri.Papadimitriou@alcatel.be wrote:


hi jerry

section 6.1.17 mentions

The PCECP MUST support the following "unsynchronized" objective
  functions:

  o Minimum cost path (shortest path)
  o Least loaded path (widest path)
  o To be determined

not  sure to understand the last bullet, this said by mandating multiple functions, there is no "simple" default anymore one should assess the impact of such implication


Right.

section 6.3.14

"  The path computation request message MUST support TE LSP path
 reoptimization and the inclusion of a previously computed path."

i don't understand the sentence, how a message can support re-optimization; i think you mean here that an indication is required as part of the message ?

btw, the only that differentiates the path request for re-routing vs re-optimization is timing, and that the former must support inclusion of the failed element and the "old path" this is not the case for re-optimization

" This will help ensure optimal routing of a reoptimized path, since it will
 allow the PCE to avoid double bandwidth accounting and help reduce
 blocking issues."

the fact of giving the "old path" is not an indication of avoiding double bandwidth accounting (it is linked to make-before-break process) nor ensuring optimal routing


Well this is easy to understand. You must be able to differentiate the two following cases:
(1) PCC requests a path computation for a new LSP
(2) PCC requests a path computation for an existing LSP: this refers to as the reoptimization case and of course, the PCC needs to provide the existing path to avoid double bandwidth accounting that could lead to sub-optimal path ...

[dp] understood but the answer depends on the first point i.e. is there an explicit indication for re-optimzation or not - the sentence says "and" the inclusion so i consider this is an information put in addition of the explicit indication ? please confirm or infirm because the sentence is open to interpetation;

[dp] now, the only purpose for having this additional information is to force the "new path" to make use as much as possible of the "old path" such as to minimize the sum of the resources required by the old and the new path during the transient period of re-optimization (hence, including the "old path" is not an indication for avoiding double booking it is an indication for minimizing the transient resource required for the re-optimization)

JP.

thanks,
- dimitri.


"Ash, Gerald R \(Jerry\), ALABS" <gash@att.com>
Sent by: pce-bounces@lists.ietf.org

28/12/2005 18:18

       
        To:        <pce@ietf.org>
        cc:        
        Subject:        [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt




Hi All,

Please review and comment on the updated version of the PCE
communications protocol (PCECP) generic requirements I-D
http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req
s-03.txt.

Per our agreements at IETF-64 (see JL's slide at
http://www3.ietf.org/proceedings/05nov/slides/pce-11/sld7.htm), the
referenced requirements in the inter-area PCECP requirements draft have
been moved into the generic PCECP requirements draft.  In particular,

- Section 6.1.17 'Objective Functions Supported' was added
- Section 6.3.4 'LSP Rerouting & Reoptimization' was updated

Our objective is to start a WG last call soon.  We look forward to your
review and comments.

Thanks,
Regards,
Jerry

-----Original Message-----
From: i-d-announce-bounces@ietf.org
[mailto:i-d-announce-bounces@ietf.org] On Behalf Of
Internet-Drafts@ietf.org
Sent: Wednesday, December 28, 2005 10:50 AM
To: i-d-announce@ietf.org
Cc: pce@ietf.org
Subject: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.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                                  : PCE Communication Protocol Generic
Requirements
                Author(s)                 : J. Le Roux, J. Ash
                Filename                 : draft-ietf-pce-comm-protocol-gen-reqs-03.txt
                Pages                                  : 22
                Date                                  : 2005-12-28
               
The PCE model is described in the "PCE Architecture" document and
  facilitates path computation requests from Path Computation Clients
  (PCCs) to Path Computation Elements (PCEs).  This document specifies
  generic requirements for a communication protocol between PCCs and
  PCEs, and also between PCEs where cooperation between PCEs is
  desirable.  Subsequent documents will specify application-specific
  requirements for the PCE communication protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req
s-03.txt

_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce

--=_alternative 007FC359C12570EE_=-- --===============0566820473== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0566820473==-- From pce-bounces@lists.ietf.org Fri Jan 06 18:18:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ev0qy-00083Q-10; Fri, 06 Jan 2006 18:18:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ev0qx-00082T-1d for pce@megatron.ietf.org; Fri, 06 Jan 2006 18:18:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20365 for ; Fri, 6 Jan 2006 18:17:18 -0500 (EST) Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ev0wq-0005ZR-Nl for pce@ietf.org; Fri, 06 Jan 2006 18:24:45 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-5.tower-121.messagelabs.com!1136589481!9483728!3 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 22017 invoked from network); 6 Jan 2006 23:18:19 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-5.tower-121.messagelabs.com with SMTP; 6 Jan 2006 23:18:19 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 43AED14A0011D72D; Fri, 6 Jan 2006 18:18:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt Date: Fri, 6 Jan 2006 17:18:18 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA989C@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt Thread-Index: AcYTBhgvU61Ll1wLSFOibB6P9vdqEQAD1+NQ From: "Ash, Gerald R \(Jerry\)" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Dimitri, =20 Thanks a lot for your comments > section 6.1.17 mentions=20 > > The PCECP MUST support the following "unsynchronized" objective > functions: > > o Minimum cost path (shortest path)=20 > o Least loaded path (widest path) > o To be determined=20 > > not sure to understand the last bullet, this said by mandating > multiple functions, there is no "simple" default anymore one > should assess the impact of such implication=20 I agree that the TBD should be removed. > section 6.3.14=20 > > " The path computation request message MUST support TE LSP path > reoptimization and the inclusion of a previously computed path."=20 > > i don't understand the sentence, how a message can support > re-optimization; i think you mean here that an indication is > required as part of the message?=20 It means that the current path needs to be known to the PCE to properly account for available bandwidth when doing reoptimization (when the current path is removed). It can probably be phrased better, any suggestions? Thanks, Regards, Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jan 06 18:30:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ev12d-0005tw-JJ; Fri, 06 Jan 2006 18:30:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ev12a-0005qf-Nq for pce@megatron.ietf.org; Fri, 06 Jan 2006 18:30:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22031 for ; Fri, 6 Jan 2006 18:29:20 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ev18Z-00068S-2H for pce@ietf.org; Fri, 06 Jan 2006 18:36:47 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 06 Jan 2006 15:30:25 -0800 X-IronPort-AV: i="3.99,339,1131350400"; d="scan'208,217"; a="388417691:sNHT55460224" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k06NUNWF005116; Fri, 6 Jan 2006 15:30:24 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 6 Jan 2006 18:30:23 -0500 Received: from [192.168.1.101] ([10.86.240.56]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 6 Jan 2006 18:30:22 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Message-Id: <9CB2BE12-D706-453B-9499-407FA35CE894@cisco.com> From: JP Vasseur Subject: Re: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt Date: Fri, 6 Jan 2006 18:29:50 -0500 To: Dimitri.Papadimitriou@alcatel.be X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 06 Jan 2006 23:30:22.0536 (UTC) FILETIME=[29F04480:01C61319] X-Spam-Score: 0.7 (/) X-Scan-Signature: 46ad68ada464411807db2a0edd5648ae Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0205475093==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============0205475093== Content-Type: multipart/alternative; boundary=Apple-Mail-137--630798980 --Apple-Mail-137--630798980 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Jan 6, 2006, at 6:15 PM, Dimitri.Papadimitriou@alcatel.be wrote: > > hi - see in-line > > > > On Jan 6, 2006, at 4:13 PM, Dimitri.Papadimitriou@alcatel.be wrote: > > > hi jerry > > section 6.1.17 mentions > > The PCECP MUST support the following "unsynchronized" objective > functions: > > o Minimum cost path (shortest path) > o Least loaded path (widest path) > o To be determined > > not sure to understand the last bullet, this said by mandating > multiple functions, there is no "simple" default anymore one should > assess the impact of such implication > > > Right. > > section 6.3.14 > > " The path computation request message MUST support TE LSP path > reoptimization and the inclusion of a previously computed path." > > i don't understand the sentence, how a message can support re- > optimization; i think you mean here that an indication is required > as part of the message ? > > btw, the only that differentiates the path request for re-routing > vs re-optimization is timing, and that the former must support > inclusion of the failed element and the "old path" this is not the > case for re-optimization > > " This will help ensure optimal routing of a reoptimized path, > since it will > allow the PCE to avoid double bandwidth accounting and help reduce > blocking issues." > > the fact of giving the "old path" is not an indication of avoiding > double bandwidth accounting (it is linked to make-before-break > process) nor ensuring optimal routing > > > Well this is easy to understand. You must be able to differentiate > the two following cases: > (1) PCC requests a path computation for a new LSP > (2) PCC requests a path computation for an existing LSP: this > refers to as the reoptimization case and of course, the PCC needs > to provide the existing path to avoid double bandwidth accounting > that could lead to sub-optimal path ... > > [dp] understood but the answer depends on the first point i.e. is > there an explicit indication for re-optimzation or not - the > sentence says "and" the inclusion so i consider this is an > information put in addition of the explicit indication ? please > confirm or infirm because the sentence is open to interpetation; > Yes, there is an indication for reoptimization > [dp] now, the only purpose for having this additional information > is to force the "new path" to make use as much as possible of the > "old path" such as to minimize the sum of the resources required by > the old and the new path during the transient period of re- > optimization (hence, including the "old path" is not an indication > for avoiding double booking it is an indication for minimizing the > transient resource required for the re-optimization) No you missed my point. The purpose of providing the existing path is for the PCE to take into account the bw used by the existing LSP while computing the new path (which might be more optimal). JP. > > JP. > > thanks, > - dimitri. > > > "Ash, Gerald R \(Jerry\), ALABS" > Sent by: pce-bounces@lists.ietf.org > 28/12/2005 18:18 > > > To: > cc: > Subject: [Pce] RE: I-D ACTION:draft-ietf-pce-comm- > protocol-gen-reqs-03.txt > > > > > Hi All, > > Please review and comment on the updated version of the PCE > communications protocol (PCECP) generic requirements I-D > http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol- > gen-req > s-03.txt. > > Per our agreements at IETF-64 (see JL's slide at > http://www3.ietf.org/proceedings/05nov/slides/pce-11/sld7.htm), the > referenced requirements in the inter-area PCECP requirements draft > have > been moved into the generic PCECP requirements draft. In particular, > > - Section 6.1.17 'Objective Functions Supported' was added > - Section 6.3.4 'LSP Rerouting & Reoptimization' was updated > > Our objective is to start a WG last call soon. We look forward to > your > review and comments. > > Thanks, > Regards, > Jerry > > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Wednesday, December 28, 2005 10:50 AM > To: i-d-announce@ietf.org > Cc: pce@ietf.org > Subject: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.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 : PCE > Communication Protocol Generic > Requirements > Author(s) : J. Le Roux, J. Ash > Filename : draft-ietf-pce-comm- > protocol-gen-reqs-03.txt > Pages : 22 > Date : 2005-12-28 > > The PCE model is described in the "PCE Architecture" document and > facilitates path computation requests from Path Computation Clients > (PCCs) to Path Computation Elements (PCEs). This document specifies > generic requirements for a communication protocol between PCCs and > PCEs, and also between PCEs where cooperation between PCEs is > desirable. Subsequent documents will specify application-specific > requirements for the PCE communication protocol. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol- > gen-req > s-03.txt > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > --Apple-Mail-137--630798980 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Jan 6, 2006, at = 6:15 PM, Dimitri.Papadimitriou@alc= atel.be wrote:


hi - see in-line


=
On Jan 6, 2006, at 4:13 PM, = Dimitri.Papadimitriou@alcatel.be wrote:


hi jerry

section 6.1.17 mentions =

The PCECP MUST support the following "unsynchronized" = objective
=A0 functions:

=A0 o Minimum cost path (shortest = path)
=A0 o Least loaded path (widest path)
=A0 o To be = determined

not =A0sure to understand the last bullet, this = said by mandating multiple functions, there is no "simple" default = anymore one should assess the impact of such implication
=

Right.
=
section 6.3.14

" = =A0The path computation request message MUST support TE LSP path
= =A0reoptimization and the inclusion of a previously computed path."
=
i don't understand the sentence, how a message can support = re-optimization; i think you mean here that an indication is required as = part of the message ?

btw, the only that differentiates the = path request for re-routing vs re-optimization is timing, and that the = former must support inclusion of the failed element and the "old path" = this is not the case for re-optimization

" This will help = ensure optimal routing of a reoptimized path, since it will
=A0allow = the PCE to avoid double bandwidth accounting and help reduce
= =A0blocking issues."

the fact of giving the "old path" is not = an indication of avoiding double bandwidth accounting (it is linked to = make-before-break process) nor ensuring optimal routing
=

Well this is easy to = understand. You must be able to differentiate the two following = cases:
(1) PCC requests = a path computation for a new LSP
(2) PCC requests a path computation for an existing = LSP: this refers to as the reoptimization case and of course, the PCC = needs to provide the existing path to avoid double bandwidth accounting = that could lead to sub-optimal path ...

[dp] understood but the answer depends on the first = point i.e. is there an explicit indication for re-optimzation or not - = the sentence says "and" the inclusion so i consider this is an = information put in addition of the explicit indication ? please confirm = or infirm because the sentence is open to interpetation;
=

Yes, there is an indication = for reoptimization

[dp] now, the only purpose for having this = additional information is to force the "new path" to make use as much as = possible of the "old path" such as to minimize the sum of the resources = required by the old and the new path during the transient period of = re-optimization (hence, including the "old path" is not an indication = for avoiding double booking it is an indication for minimizing the = transient resource required for the re-optimization) =

No = you missed my point. The purpose of providing the existing path is for = the PCE to take into account the bw used by the existing LSP while = computing the new path (which might be more optimal).

JP.


JP.
=
thanks,
- dimitri.
=

"Ash, Gerald R \(Jerry\), ALABS" <gash@att.com>
Sent by: pce-bounces@lists.ietf.org

28/12/2005 18:18

=A0 =A0 =A0 =A0
= =A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0<pce@ietf.org>
=A0 =A0 =A0 =A0 cc: =A0 =A0 =A0 =A0
= =A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0[Pce] RE: I-D = ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt




Hi = All,

Please review and comment on the updated version of the = PCE
communications protocol (PCECP) generic requirements = I-D
= http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-= req
s-03.txt.
=
Per our agreements at IETF-64 (see JL's slide at
http://www3.ietf.org/proceedings/05nov/slides/pce-11/sld7.htm<= /A>), the
referenced = requirements in the inter-area PCECP requirements draft have
been = moved into the generic PCECP requirements draft. =A0In particular,
=
- Section 6.1.17 'Objective Functions Supported' was added
- = Section 6.3.4 'LSP Rerouting & Reoptimization' was updated

= Our objective is to start a WG last call soon. =A0We look forward to = your
review and comments.

Thanks,
Regards,
= Jerry

-----Original Message-----
From: i-d-announce-bounces@ietf.org
[mailto:i-d-announce-bounces@ietf.org] On Behalf Of
Internet-Drafts@ietf.org
Sent: Wednesday, December 28, 2005 10:50 = AM
To: i-d-announce@ietf.org
Cc: pce@ietf.org
Subject: I-D = ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.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.

=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0: PCE Communication Protocol Generic
Requirements
=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : J. = Le Roux, J. Ash
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 : draft-ietf-pce-comm-protocol-gen-reqs-03.txt
=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0: 22
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = Date =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: = 2005-12-28
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
The PCE model is = described in the "PCE Architecture" document and
=A0 facilitates = path computation requests from Path Computation Clients
=A0 (PCCs) = to Path Computation Elements (PCEs). =A0This document specifies
=A0 = generic requirements for a communication protocol between PCCs and
=A0= PCEs, and also between PCEs where cooperation between PCEs is
=A0 = desirable. =A0Subsequent documents will specify application-specific
= =A0 requirements for the PCE communication protocol.

A URL for = this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-= req
s-03.txt
=
_______________________________________________
Pce mailing = list
= Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce
=

= --Apple-Mail-137--630798980-- --===============0205475093== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0205475093==-- From pce-bounces@lists.ietf.org Fri Jan 06 19:07:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ev1c3-0001iO-Ip; Fri, 06 Jan 2006 19:07:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ev1c2-0001h5-6u for pce@megatron.ietf.org; Fri, 06 Jan 2006 19:07:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26810 for ; Fri, 6 Jan 2006 19:05:58 -0500 (EST) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ev1i0-0007yI-Rt for pce@ietf.org; Fri, 06 Jan 2006 19:13:25 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3) with ESMTP id k0706xLi002586; Sat, 7 Jan 2006 01:06:59 +0100 In-Reply-To: <9473683187ADC049A855ED2DA739ABCA09FA989C@KCCLUST06EVS1.ugd.att.com> To: "Ash, Gerald R \(Jerry\)" Subject: RE: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Sat, 7 Jan 2006 01:06:57 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 01/07/2006 01:06:59, Serialize complete at 01/07/2006 01:06:59 X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.8 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: pce-bounces@ietf.org, pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1379513626==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multipart message in MIME format. --===============1379513626== Content-Type: multipart/alternative; boundary="=_alternative 0000A351C12570EF_=" This is a multipart message in MIME format. --=_alternative 0000A351C12570EF_= Content-Type: text/plain; charset="US-ASCII" jerry - see inline "Ash, Gerald R \(Jerry\)" Sent by: pce-bounces@lists.ietf.org 07/01/2006 00:18 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: pce@ietf.org Subject: RE: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt Hi Dimitri, Thanks a lot for your comments > section 6.1.17 mentions > > The PCECP MUST support the following "unsynchronized" objective > functions: > > o Minimum cost path (shortest path) > o Least loaded path (widest path) > o To be determined > > not sure to understand the last bullet, this said by mandating > multiple functions, there is no "simple" default anymore one > should assess the impact of such implication I agree that the TBD should be removed. > section 6.3.14 > > " The path computation request message MUST support TE LSP path > reoptimization and the inclusion of a previously computed path." > > i don't understand the sentence, how a message can support > re-optimization; i think you mean here that an indication is > required as part of the message? It means that the current path needs to be known to the PCE to properly account for available bandwidth when doing reoptimization (when the current path is removed). It can probably be phrased better, any suggestions? [dp] "The path computation request message MUST indicate if the computation is for path reoptimization of the TE LSP and MUST include the current path of this LSP." Thanks, Regards, Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --=_alternative 0000A351C12570EF_= Content-Type: text/html; charset="US-ASCII"
jerry - see inline


"Ash, Gerald R \(Jerry\)" <gash@att.com>
Sent by: pce-bounces@lists.ietf.org

07/01/2006 00:18

       
        To:        Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:        pce@ietf.org
        Subject:        RE: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt



Hi Dimitri,

Thanks a lot for your comments

> section 6.1.17 mentions
>
> The PCECP MUST support the following "unsynchronized" objective
> functions:
>
>  o Minimum cost path (shortest path)
>  o Least loaded path (widest path)
>  o To be determined
>
> not sure to understand the last bullet, this said by mandating
> multiple functions, there is no "simple" default anymore one
> should assess the impact of such implication

I agree that the TBD should be removed.

> section 6.3.14
>
> "  The path computation request message MUST support TE LSP path
> reoptimization and the inclusion of a previously computed path."
>
> i don't understand the sentence, how a message can support
> re-optimization; i think you mean here that an indication is
> required as part of the message?

It means that the current path needs to be known to the PCE to properly
account for available bandwidth when doing reoptimization (when the
current path is removed).  It can probably be phrased better, any
suggestions?

[dp] "The path computation request message MUST indicate if the computation is for path reoptimization of the TE LSP and MUST include the current path of this LSP."

Thanks,
Regards,
Jerry

_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce
--=_alternative 0000A351C12570EF_=-- --===============1379513626== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1379513626==-- From pce-bounces@lists.ietf.org Fri Jan 06 19:43:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ev2BU-0003NH-O8; Fri, 06 Jan 2006 19:43:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ev2BT-0003Mm-0A for pce@megatron.ietf.org; Fri, 06 Jan 2006 19:43:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29198 for ; Fri, 6 Jan 2006 19:42:34 -0500 (EST) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ev2HR-0000Zf-Ff for pce@ietf.org; Fri, 06 Jan 2006 19:50:02 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3) with ESMTP id k070hVOG004931; Sat, 7 Jan 2006 01:43:31 +0100 In-Reply-To: <9CB2BE12-D706-453B-9499-407FA35CE894@cisco.com> To: JP Vasseur Subject: Re: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Sat, 7 Jan 2006 01:43:28 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 01/07/2006 01:43:31, Serialize complete at 01/07/2006 01:43:31 X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 1.2 (+) X-Scan-Signature: 00134749b78ab2213964fc53d03de937 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1473768864==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multipart message in MIME format. --===============1473768864== Content-Type: multipart/alternative; boundary="=_alternative 0003FB1EC12570EF_=" This is a multipart message in MIME format. --=_alternative 0003FB1EC12570EF_= Content-Type: text/plain; charset="US-ASCII" JP Vasseur 07/01/2006 00:29 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Ash, Gerald R ((Jerry)), ALABS" , pce@ietf.org Subject: Re: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt On Jan 6, 2006, at 6:15 PM, Dimitri.Papadimitriou@alcatel.be wrote: hi - see in-line On Jan 6, 2006, at 4:13 PM, Dimitri.Papadimitriou@alcatel.be wrote: hi jerry section 6.1.17 mentions The PCECP MUST support the following "unsynchronized" objective functions: o Minimum cost path (shortest path) o Least loaded path (widest path) o To be determined not sure to understand the last bullet, this said by mandating multiple functions, there is no "simple" default anymore one should assess the impact of such implication Right. section 6.3.14 " The path computation request message MUST support TE LSP path reoptimization and the inclusion of a previously computed path." i don't understand the sentence, how a message can support re-optimization; i think you mean here that an indication is required as part of the message ? btw, the only that differentiates the path request for re-routing vs re-optimization is timing, and that the former must support inclusion of the failed element and the "old path" this is not the case for re-optimization " This will help ensure optimal routing of a reoptimized path, since it will allow the PCE to avoid double bandwidth accounting and help reduce blocking issues." the fact of giving the "old path" is not an indication of avoiding double bandwidth accounting (it is linked to make-before-break process) nor ensuring optimal routing Well this is easy to understand. You must be able to differentiate the two following cases: (1) PCC requests a path computation for a new LSP (2) PCC requests a path computation for an existing LSP: this refers to as the reoptimization case and of course, the PCC needs to provide the existing path to avoid double bandwidth accounting that could lead to sub-optimal path ... [dp] understood but the answer depends on the first point i.e. is there an explicit indication for re-optimzation or not - the sentence says "and" the inclusion so i consider this is an information put in addition of the explicit indication ? please confirm or infirm because the sentence is open to interpetation; Yes, there is an indication for reoptimization [dp] ok [dp] now, the only purpose for having this additional information is to force the "new path" to make use as much as possible of the "old path" such as to minimize the sum of the resources required by the old and the new path during the transient period of re-optimization (hence, including the "old path" is not an indication for avoiding double booking it is an indication for minimizing the transient resource required for the re-optimization) No you missed my point. The purpose of providing the existing path is for the PCE to take into account the bw used by the existing LSP while computing the new path (which might be more optimal). [dp] ok, you mean that a re-optimization computation is to be performed by taking only into account the global network resource consumption pruned from the bandwidth used by the LSP requesting re-optimization (hence, as if it was a newly requested path) but you don't take into account the constraint put by the current path itself ... imho, this should be policy-driven as it is dependent on the gain obtained (in terms of bandwidth for inst.) vs modification implied JP. JP. thanks, - dimitri. "Ash, Gerald R \(Jerry\), ALABS" Sent by: pce-bounces@lists.ietf.org 28/12/2005 18:18 To: cc: Subject: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt Hi All, Please review and comment on the updated version of the PCE communications protocol (PCECP) generic requirements I-D http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req s-03.txt. Per our agreements at IETF-64 (see JL's slide at http://www3.ietf.org/proceedings/05nov/slides/pce-11/sld7.htm), the referenced requirements in the inter-area PCECP requirements draft have been moved into the generic PCECP requirements draft. In particular, - Section 6.1.17 'Objective Functions Supported' was added - Section 6.3.4 'LSP Rerouting & Reoptimization' was updated Our objective is to start a WG last call soon. We look forward to your review and comments. Thanks, Regards, Jerry -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, December 28, 2005 10:50 AM To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.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 : PCE Communication Protocol Generic Requirements Author(s) : J. Le Roux, J. Ash Filename : draft-ietf-pce-comm-protocol-gen-reqs-03.txt Pages : 22 Date : 2005-12-28 The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req s-03.txt _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --=_alternative 0003FB1EC12570EF_= Content-Type: text/html; charset="US-ASCII"


JP Vasseur <jvasseur@cisco.com>

07/01/2006 00:29

       
        To:        Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:        "Ash, Gerald R ((Jerry)), ALABS" <gash@att.com>, pce@ietf.org
        Subject:        Re: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt




On Jan 6, 2006, at 6:15 PM, Dimitri.Papadimitriou@alcatel.be wrote:


hi - see in-line



On Jan 6, 2006, at 4:13 PM, Dimitri.Papadimitriou@alcatel.be wrote:


hi jerry

section 6.1.17 mentions

The PCECP MUST support the following "unsynchronized" objective
  functions:

  o Minimum cost path (shortest path)
  o Least loaded path (widest path)
  o To be determined

not  sure to understand the last bullet, this said by mandating multiple functions, there is no "simple" default anymore one should assess the impact of such implication


Right.

section 6.3.14

"  The path computation request message MUST support TE LSP path
 reoptimization and the inclusion of a previously computed path."

i don't understand the sentence, how a message can support re-optimization; i think you mean here that an indication is required as part of the message ?

btw, the only that differentiates the path request for re-routing vs re-optimization is timing, and that the former must support inclusion of the failed element and the "old path" this is not the case for re-optimization

" This will help ensure optimal routing of a reoptimized path, since it will
 allow the PCE to avoid double bandwidth accounting and help reduce
 blocking issues."

the fact of giving the "old path" is not an indication of avoiding double bandwidth accounting (it is linked to make-before-break process) nor ensuring optimal routing


Well this is easy to understand. You must be able to differentiate the two following cases:
(1) PCC requests a path computation for a new LSP
(2) PCC requests a path computation for an existing LSP: this refers to as the reoptimization case and of course, the PCC needs to provide the existing path to avoid double bandwidth accounting that could lead to sub-optimal path ...

[dp] understood but the answer depends on the first point i.e. is there an explicit indication for re-optimzation or not - the sentence says "and" the inclusion so i consider this is an information put in addition of the explicit indication ? please confirm or infirm because the sentence is open to interpetation;


Yes, there is an indication for reoptimization

[dp] ok

[dp] now, the only purpose for having this additional information is to force the "new path" to make use as much as possible of the "old path" such as to minimize the sum of the resources required by the old and the new path during the transient period of re-optimization (hence, including the "old path" is not an indication for avoiding double booking it is an indication for minimizing the transient resource required for the re-optimization)

No you missed my point. The purpose of providing the existing path is for the PCE to take into account the bw used by the existing LSP while computing the new path (which might be more optimal).

[dp] ok, you mean that a re-optimization computation is to be performed by taking only into account the global network resource consumption pruned from the bandwidth used by the LSP requesting re-optimization (hence, as if it was a newly requested path) but you don't take into account the constraint put by the current path itself ... imho, this should be policy-driven as it is dependent on the gain obtained (in terms of bandwidth for inst.) vs modification implied

JP.


JP.

thanks,
- dimitri.

"Ash, Gerald R \(Jerry\), ALABS" <gash@att.com>
Sent by: pce-bounces@lists.ietf.org

28/12/2005 18:18

       
        To:        <pce@ietf.org>
        cc:        
        Subject:        [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt





Hi All,

Please review and comment on the updated version of the PCE
communications protocol (PCECP) generic requirements I-D
http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req
s-03.txt.

Per our agreements at IETF-64 (see JL's slide at
http://www3.ietf.org/proceedings/05nov/slides/pce-11/sld7.htm), the
referenced requirements in the inter-area PCECP requirements draft have
been moved into the generic PCECP requirements draft.  In particular,

- Section 6.1.17 'Objective Functions Supported' was added
- Section 6.3.4 'LSP Rerouting & Reoptimization' was updated

Our objective is to start a WG last call soon.  We look forward to your
review and comments.

Thanks,
Regards,
Jerry

-----Original Message-----
From: i-d-announce-bounces@ietf.org
[mailto:i-d-announce-bounces@ietf.org] On Behalf Of
Internet-Drafts@ietf.org
Sent: Wednesday, December 28, 2005 10:50 AM
To: i-d-announce@ietf.org
Cc: pce@ietf.org
Subject: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.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                                  : PCE Communication Protocol Generic
Requirements
                Author(s)                 : J. Le Roux, J. Ash
                Filename                 : draft-ietf-pce-comm-protocol-gen-reqs-03.txt
                Pages                                  : 22
                Date                                  : 2005-12-28
               
The PCE model is described in the "PCE Architecture" document and
  facilitates path computation requests from Path Computation Clients
  (PCCs) to Path Computation Elements (PCEs).  This document specifies
  generic requirements for a communication protocol between PCCs and
  PCEs, and also between PCEs where cooperation between PCEs is
  desirable.  Subsequent documents will specify application-specific
  requirements for the PCE communication protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req
s-03.txt

_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce

_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce


--=_alternative 0003FB1EC12570EF_=-- --===============1473768864== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1473768864==-- From pce-bounces@lists.ietf.org Sat Jan 07 08:42:04 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvEKZ-0004WE-SI; Sat, 07 Jan 2006 08:42:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvEKX-0004W9-Tb for pce@megatron.ietf.org; Sat, 07 Jan 2006 08:42:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09898 for ; Sat, 7 Jan 2006 08:40:45 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvEQc-0003Aq-El for pce@ietf.org; Sat, 07 Jan 2006 08:48:20 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 07 Jan 2006 05:41:48 -0800 X-IronPort-AV: i="3.99,342,1131350400"; d="scan'208"; a="1764534703:sNHT30633468" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k07DflQi009592; Sat, 7 Jan 2006 05:41:47 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 7 Jan 2006 08:41:46 -0500 Received: from [192.168.1.101] ([10.86.240.196]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 7 Jan 2006 08:41:46 -0500 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <27AD1176-EF4A-427B-BDEA-E983D3020EA0@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Sat, 7 Jan 2006 08:41:14 -0500 To: pce@ietf.org X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 07 Jan 2006 13:41:46.0551 (UTC) FILETIME=[1A625C70:01C61390] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Working Group Last Call on draft-ietf-pce-architecture-03.txt ended X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org WG, Working Group Last call on draft-ietf-pce-architecture-03.txt ended has ended on January 3. There were several points discussed on the list that all came to a resolution, except one that relates to the ability for the PCC to request from the PCE the use of a specific path computation algorithm. This was listed as a requirement by several individual in the past, three others recently mentioned that they were opposed to it. So we now need to close on this. Please voice you opinion. Once we'll get an agreement on the list, thanks to Adrian for posting a new revision incorporating the changes. Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sat Jan 07 09:03:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvEfG-0002jm-Ky; Sat, 07 Jan 2006 09:03:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvEfE-0002it-Ob for pce@megatron.ietf.org; Sat, 07 Jan 2006 09:03:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10918 for ; Sat, 7 Jan 2006 09:02:07 -0500 (EST) Received: from webmail.movaz.com ([70.158.43.219] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvElK-0003eu-Si for pce@ietf.org; Sat, 07 Jan 2006 09:09:43 -0500 Received: from ib (vpn17.atlanta.movaz.com [172.18.0.17]) by jera.movaz.com (Postfix) with SMTP id C4A1112E1C; Sat, 7 Jan 2006 09:00:34 -0500 (EST) Message-ID: <026b01c61393$19343550$6601a8c0@movaz.com> From: "Igor Bryskin" To: , "JP Vasseur" References: Subject: Re: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt Date: Sat, 7 Jan 2006 09:03:12 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 1.0 (+) X-Scan-Signature: 2ed9477f79f24ff120e9894ad9dc9cb5 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0705059161==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0705059161== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0268_01C61369.301F76A0" This is a multi-part message in MIME format. ------=_NextPart_000_0268_01C61369.301F76A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I think both Dimitri and JP are correct here. While performing = re-optimization path computation PCE needs to know about the old path = for two reasons: a) Not to block TE links that do not have enough bandwidth (JP's point) b) Not to route the new path unnecessarily over new TE links (for = example in case of equal cost paths) to avoid extra resource management = activities that could adversely affect network stability (Dimitri's = point)=20 Igor ----- Original Message -----=20 From: Dimitri.Papadimitriou@alcatel.be=20 To: JP Vasseur=20 Cc: pce@ietf.org=20 Sent: Friday, January 06, 2006 6:15 PM Subject: Re: [Pce] RE: I-D = ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt hi - see in-line=20 On Jan 6, 2006, at 4:13 PM, Dimitri.Papadimitriou@alcatel.be wrote:=20 hi jerry=20 section 6.1.17 mentions=20 The PCECP MUST support the following "unsynchronized" objective functions: o Minimum cost path (shortest path)=20 o Least loaded path (widest path) o To be determined=20 not sure to understand the last bullet, this said by mandating = multiple functions, there is no "simple" default anymore one should = assess the impact of such implication=20 Right.=20 section 6.3.14=20 " The path computation request message MUST support TE LSP path reoptimization and the inclusion of a previously computed path."=20 i don't understand the sentence, how a message can support = re-optimization; i think you mean here that an indication is required as = part of the message ?=20 btw, the only that differentiates the path request for re-routing vs = re-optimization is timing, and that the former must support inclusion of = the failed element and the "old path" this is not the case for = re-optimization=20 " This will help ensure optimal routing of a reoptimized path, since = it will allow the PCE to avoid double bandwidth accounting and help reduce blocking issues."=20 the fact of giving the "old path" is not an indication of avoiding = double bandwidth accounting (it is linked to make-before-break process) = nor ensuring optimal routing=20 Well this is easy to understand. You must be able to differentiate the = two following cases:=20 (1) PCC requests a path computation for a new LSP=20 (2) PCC requests a path computation for an existing LSP: this refers = to as the reoptimization case and of course, the PCC needs to provide = the existing path to avoid double bandwidth accounting that could lead = to sub-optimal path ...=20 [dp] understood but the answer depends on the first point i.e. is = there an explicit indication for re-optimzation or not - the sentence = says "and" the inclusion so i consider this is an information put in = addition of the explicit indication ? please confirm or infirm because = the sentence is open to interpetation;=20 [dp] now, the only purpose for having this additional information is = to force the "new path" to make use as much as possible of the "old = path" such as to minimize the sum of the resources required by the old = and the new path during the transient period of re-optimization (hence, = including the "old path" is not an indication for avoiding double = booking it is an indication for minimizing the transient resource = required for the re-optimization)=20 JP.=20 thanks,=20 - dimitri.=20 "Ash, Gerald R \(Jerry\), ALABS" =20 Sent by: pce-bounces@lists.ietf.org=20 28/12/2005 18:18=20 =20 To: =20 cc: =20 Subject: [Pce] RE: I-D = ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt=20 Hi All, Please review and comment on the updated version of the PCE communications protocol (PCECP) generic requirements I-D = http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req s-03.txt. Per our agreements at IETF-64 (see JL's slide at http://www3.ietf.org/proceedings/05nov/slides/pce-11/sld7.htm), the referenced requirements in the inter-area PCECP requirements draft = have been moved into the generic PCECP requirements draft. In particular, - Section 6.1.17 'Objective Functions Supported' was added - Section 6.3.4 'LSP Rerouting & Reoptimization' was updated Our objective is to start a WG last call soon. We look forward to = your review and comments. Thanks, Regards, Jerry -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, December 28, 2005 10:50 AM To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt=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. Title : PCE = Communication Protocol Generic Requirements Author(s) : J. Le Roux, J. Ash Filename : = draft-ietf-pce-comm-protocol-gen-reqs-03.txt Pages : 22 Date : 2005-12-28 =20 The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. A URL for this Internet-Draft is: = http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req s-03.txt _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________=20 Pce mailing list=20 Pce@lists.ietf.org=20 https://www1.ietf.org/mailman/listinfo/pce=20 -------------------------------------------------------------------------= ----- _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------=_NextPart_000_0268_01C61369.301F76A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I think both Dimitri and JP are correct = here. While=20 performing re-optimization path computation PCE needs to know about the = old path=20 for two reasons:
 
a) Not to block TE links that do not = have enough=20 bandwidth (JP's point)
b) Not to route the new path = unnecessarily over new=20 TE links (for example in case of equal cost paths) to avoid extra=20 resource management activities that could adversely affect network=20 stability (Dimitri's point) 
 
Igor
----- Original Message -----
From:=20 Dimitri.Papadimitriou@al= catel.be=20
Sent: Friday, January 06, 2006 = 6:15=20 PM
Subject: Re: [Pce] RE: I-D=20 ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt


hi - see = in-line=20



On Jan 6, 2006, at = 4:13 PM,=20 Dimitri.Papadimitriou@alcatel.be wrote:


hi jerry=20

section 6.1.17 mentions

The PCECP MUST support the = following=20 "unsynchronized" objective
  functions:

  o = Minimum cost=20 path (shortest path)
  o Least loaded path (widest = path)
  o=20 To be determined

not  sure to understand the last bullet, = this=20 said by mandating multiple functions, there is no "simple" default = anymore one=20 should assess the impact of such implication


Right.

section 6.3.14

"  The path computation request = message=20 MUST support TE LSP path
 reoptimization and the inclusion of = a=20 previously computed path."

i don't understand the sentence, = how a=20 message can support re-optimization; i think you mean here that an = indication=20 is required as part of the message ?

btw, the only that = differentiates=20 the path request for re-routing vs re-optimization is timing, and that = the=20 former must support inclusion of the failed element and the "old path" = this is=20 not the case for re-optimization

" This will help ensure = optimal=20 routing of a reoptimized path, since it will
 allow the PCE to = avoid=20 double bandwidth accounting and help reduce
 blocking issues." =

the fact of giving the "old path" is not an indication of = avoiding=20 double bandwidth accounting (it is linked to make-before-break = process) nor=20 ensuring optimal routing


Well this is easy to understand. You must be able to = differentiate the=20 two following cases:
(1) PCC=20 requests a path computation for a new LSP
(2) PCC requests a path computation for an existing LSP: this = refers to=20 as the reoptimization case and of course, the PCC needs to provide the = existing path to avoid double bandwidth accounting that could lead to=20 sub-optimal path ...

[dp]=20 understood but the answer depends on the first point i.e. is there an = explicit=20 indication for re-optimzation or not - the sentence says "and" the = inclusion=20 so i consider this is an information put in addition of the explicit=20 indication ? please confirm or infirm because the sentence is open to=20 interpetation;

[dp] = now, the=20 only purpose for having this additional information is to force the = "new path"=20 to make use as much as possible of the "old path" such as to minimize = the sum=20 of the resources required by the old and the new path during the = transient=20 period of re-optimization (hence, including the "old path" is not an=20 indication for avoiding double booking it is an indication for = minimizing the=20 transient resource required for the re-optimization) =

JP.

thanks,
- dimitri.






Hi All,

Please review = and comment=20 on the updated version of the PCE
communications protocol (PCECP) = generic=20 requirements I-D
http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol= -gen-req
s-03.txt.

Per our agreements = at IETF-64=20 (see JL's slide at
http://www3.ietf.org/proceedings/05nov/slides/pce-11/sld7.htm), the
referenced requirements in the = inter-area=20 PCECP requirements draft have
been moved into the generic PCECP=20 requirements draft.  In particular,

- Section 6.1.17 = 'Objective=20 Functions Supported' was added
- Section 6.3.4 'LSP Rerouting & = Reoptimization' was updated

Our objective is to start a WG last = call=20 soon.  We look forward to your
review and=20 comments.

Thanks,
Regards,
Jerry

-----Original=20 Message-----
From: i-d-announce-bounces@ietf.org
[mailto:i-d-announce-bounces@ietf.org] On Behalf Of
Internet-Drafts@ietf.org
Sent: Wednesday, December 28, 2005 = 10:50=20 AM
To: i-d-announce@ietf.org
Cc: pce@ietf.org
Subject: I-D=20 ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt

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

    =  =20           Title         =  =20                     =  =20  : PCE Communication Protocol Generic
Requirements
  =  =20             Author(s)     =  =20           : J. Le Roux, J. Ash
  =  =20             Filename     =    =20         :=20 draft-ietf-pce-comm-protocol-gen-reqs-03.txt
      =  =20         Pages           =  =20                     =  :=20 22
                Date =  =20                     =  =20          : 2005-12-28
      =  =20        
The PCE model is described in the "PCE = Architecture" document and
  facilitates path computation = requests=20 from Path Computation Clients
  (PCCs) to Path Computation = Elements=20 (PCEs).  This document specifies
  generic requirements = for a=20 communication protocol between PCCs and
  PCEs, and also = between PCEs=20 where cooperation between PCEs is
  desirable. =  Subsequent=20 documents will specify application-specific
  requirements for = the PCE=20 communication protocol.

A URL for this Internet-Draft = is:
http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol= -gen-req
s-03.txt

____________________________________________= ___
Pce=20 mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce

_______________________________________________ =
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce=20

_______________________________________________
Pce mailing=20 = list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce<= BR> ------=_NextPart_000_0268_01C61369.301F76A0-- --===============0705059161== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0705059161==-- From pce-bounces@lists.ietf.org Sat Jan 07 09:18:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvEtQ-0000LY-SX; Sat, 07 Jan 2006 09:18:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvEre-00085X-Ee for pce@megatron.ietf.org; Sat, 07 Jan 2006 09:16:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11598 for ; Sat, 7 Jan 2006 09:14:57 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvExj-0003yV-Rv for pce@ietf.org; Sat, 07 Jan 2006 09:22:33 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 07 Jan 2006 06:16:03 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k07EG3WF004421; Sat, 7 Jan 2006 06:16:03 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 7 Jan 2006 09:16:30 -0500 Received: from [192.168.1.101] ([10.86.240.196]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 7 Jan 2006 09:16:01 -0500 In-Reply-To: <026b01c61393$19343550$6601a8c0@movaz.com> References: <026b01c61393$19343550$6601a8c0@movaz.com> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 Message-Id: From: JP Vasseur Subject: Re: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt Date: Sat, 7 Jan 2006 09:15:29 -0500 To: "Igor Bryskin" X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 07 Jan 2006 14:16:01.0067 (UTC) FILETIME=[E2F89FB0:01C61394] X-Spam-Score: 0.4 (/) X-Scan-Signature: 1dbd668ceca1a76e1ad844a781a4818d X-Mailman-Approved-At: Sat, 07 Jan 2006 09:18:03 -0500 Cc: Dimitri.Papadimitriou@alcatel.be, pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0621645722==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============0621645722== Content-Type: multipart/alternative; boundary=Apple-Mail-143--577660699 --Apple-Mail-143--577660699 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi Igor, On Jan 7, 2006, at 9:03 AM, Igor Bryskin wrote: > Hi, > > I think both Dimitri and JP are correct here. While performing re- > optimization path computation PCE needs to know about the old path > for two reasons: > > a) Not to block TE links that do not have enough bandwidth (JP's > point) > b) Not to route the new path unnecessarily over new TE links (for > example in case of equal cost paths) to avoid extra resource > management activities that could adversely affect network stability > (Dimitri's point) > Well note that (a) is clearly mandatory and easy to understand. Dimitri's point on whether the PCE should try to "to force the "new path" to make use as much as possible of the "old path" such as to minimize the sum of the resources required by the old and the new path during the transient period of re-optimization" is arguable since this may lead to a less optimal path of course. But this is an algorithmic aspect that does not need to be standardized. Bottom line is that the only request was editorial to clarify the need. Thanks. JP. > > Igor > ----- Original Message ----- > From: Dimitri.Papadimitriou@alcatel.be > To: JP Vasseur > Cc: pce@ietf.org > Sent: Friday, January 06, 2006 6:15 PM > Subject: Re: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen- > reqs-03.txt > > > hi - see in-line > > > > On Jan 6, 2006, at 4:13 PM, Dimitri.Papadimitriou@alcatel.be wrote: > > > hi jerry > > section 6.1.17 mentions > > The PCECP MUST support the following "unsynchronized" objective > functions: > > o Minimum cost path (shortest path) > o Least loaded path (widest path) > o To be determined > > not sure to understand the last bullet, this said by mandating > multiple functions, there is no "simple" default anymore one should > assess the impact of such implication > > > Right. > > section 6.3.14 > > " The path computation request message MUST support TE LSP path > reoptimization and the inclusion of a previously computed path." > > i don't understand the sentence, how a message can support re- > optimization; i think you mean here that an indication is required > as part of the message ? > > btw, the only that differentiates the path request for re-routing > vs re-optimization is timing, and that the former must support > inclusion of the failed element and the "old path" this is not the > case for re-optimization > > " This will help ensure optimal routing of a reoptimized path, > since it will > allow the PCE to avoid double bandwidth accounting and help reduce > blocking issues." > > the fact of giving the "old path" is not an indication of avoiding > double bandwidth accounting (it is linked to make-before-break > process) nor ensuring optimal routing > > > Well this is easy to understand. You must be able to differentiate > the two following cases: > (1) PCC requests a path computation for a new LSP > (2) PCC requests a path computation for an existing LSP: this > refers to as the reoptimization case and of course, the PCC needs > to provide the existing path to avoid double bandwidth accounting > that could lead to sub-optimal path ... > > [dp] understood but the answer depends on the first point i.e. is > there an explicit indication for re-optimzation or not - the > sentence says "and" the inclusion so i consider this is an > information put in addition of the explicit indication ? please > confirm or infirm because the sentence is open to interpetation; > > [dp] now, the only purpose for having this additional information > is to force the "new path" to make use as much as possible of the > "old path" such as to minimize the sum of the resources required by > the old and the new path during the transient period of re- > optimization (hence, including the "old path" is not an indication > for avoiding double booking it is an indication for minimizing the > transient resource required for the re-optimization) > > JP. > > thanks, > - dimitri. > > > "Ash, Gerald R \(Jerry\), ALABS" > Sent by: pce-bounces@lists.ietf.org > 28/12/2005 18:18 > > > To: > cc: > Subject: [Pce] RE: I-D ACTION:draft-ietf-pce-comm- > protocol-gen-reqs-03.txt > > > > > Hi All, > > Please review and comment on the updated version of the PCE > communications protocol (PCECP) generic requirements I-D > http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol- > gen-req > s-03.txt. > > Per our agreements at IETF-64 (see JL's slide at > http://www3.ietf.org/proceedings/05nov/slides/pce-11/sld7.htm), the > referenced requirements in the inter-area PCECP requirements draft > have > been moved into the generic PCECP requirements draft. In particular, > > - Section 6.1.17 'Objective Functions Supported' was added > - Section 6.3.4 'LSP Rerouting & Reoptimization' was updated > > Our objective is to start a WG last call soon. We look forward to > your > review and comments. > > Thanks, > Regards, > Jerry > > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Wednesday, December 28, 2005 10:50 AM > To: i-d-announce@ietf.org > Cc: pce@ietf.org > Subject: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.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 : PCE > Communication Protocol Generic > Requirements > Author(s) : J. Le Roux, J. Ash > Filename : draft-ietf-pce-comm- > protocol-gen-reqs-03.txt > Pages : 22 > Date : 2005-12-28 > > The PCE model is described in the "PCE Architecture" document and > facilitates path computation requests from Path Computation Clients > (PCCs) to Path Computation Elements (PCEs). This document specifies > generic requirements for a communication protocol between PCCs and > PCEs, and also between PCEs where cooperation between PCEs is > desirable. Subsequent documents will specify application-specific > requirements for the PCE communication protocol. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol- > gen-req > s-03.txt > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > --Apple-Mail-143--577660699 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Igor,

On = Jan 7, 2006, at 9:03 AM, Igor Bryskin wrote:

Hi,
=A0
=A0
a) Not to = block TE links that do not have enough bandwidth (JP's = point)
b) Not to = route the new path unnecessarily over new TE links (for example in case = of equal cost paths) to avoid extra resource=A0management activities = that could adversely affect network stability (Dimitri's = point)=A0


Well note that (a) is = clearly mandatory and easy to understand.=A0

Dimitri's point on whether = the PCE should try to=A0 "to force the "new path" to make use as much as possible of the = "old path" such as to minimize the sum of the resources required by the = old and the new path during the transient period of = re-optimization" is arguable since this may lead to a less = optimal path of course. But this is an algorithmic aspect that does not = need to be standardized.

Bottom line is that the = only request was editorial to clarify the need.

Thanks.

JP.

----- Original = Message -----
Cc:

<= /DIV>
hi - see in-line=A0



On Jan 6, 2006, = at 4:13 PM, wrote:=A0


hi jerry

section 6.1.17 mentions

The PCECP MUST = support the following "unsynchronized" objective
=A0 functions:

=A0 o Minimum cost path (shortest = path)
=A0 o Least loaded path (widest path)
=A0 o To be determined

not =A0sure to = understand the last bullet, this said by mandating multiple functions, = there is no "simple" default anymore one should assess the impact of = such implication


Right.=A0

section 6.3.14

" =A0The path computation request message MUST support TE LSP = path
=A0reoptimization and the inclusion of a = previously computed path."

i don't understand the sentence, how = a message can support re-optimization; i think you mean here that an = indication is required as part of the message ?

btw, the only that differentiates the path request for = re-routing vs re-optimization is timing, and that the former must = support inclusion of the failed element and the "old path" this is not = the case for re-optimization

" This will = help ensure optimal routing of a reoptimized path, since it = will
=A0allow the PCE to avoid double bandwidth = accounting and help reduce
=A0blocking = issues."

the fact of giving the "old path" is not an = indication of avoiding double bandwidth accounting (it is linked to = make-before-break process) nor ensuring optimal routing
Well this is easy to understand. You must be able to = differentiate the two following cases:=A0
(1) PCC requests a path computation = for a new LSP=A0
(2) PCC requests a path computation = for an existing LSP: this refers to as the reoptimization case and of = course, the PCC needs to provide the existing path to avoid double = bandwidth accounting that could lead to sub-optimal path = ...=A0

[dp] understood but the answer = depends on the first point i.e. is there an explicit indication for = re-optimzation or not - the sentence says "and" the inclusion so i = consider this is an information put in addition of the explicit = indication ? please confirm or infirm because the sentence is open to = interpetation;

[dp] now, the only purpose for having = this additional information is to force the "new path" to make use as = much as possible of the "old path" such as to minimize the sum of the = resources required by the old and the new path during the transient = period of re-optimization (hence, including the "old path" is not an = indication for avoiding double booking it is an indication for = minimizing the transient resource required for the = re-optimization)=A0

JP.=A0

thanks,
- dimitri.


"Ash, Gerald = R=20 \(Jerry\), ALABS" <gash@att.com>
Sent by: pce-bounces@lists.ietf.org=20

28/12/2005 18:18 =

  =    =20  
        To:      =20  <pce@ietf.org>
        cc:     =  =20  
        Subject:     =  =20  [Pce] RE: I-D=20 = ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt
"Ash, Gerald R \(Jerry\), ALABS" <>
Sent by: =

28/12/2005 = 18:18

=A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0<>
=A0 =A0 =A0 =A0 cc: = =A0 =A0 =A0 =A0
=A0 =A0 =A0 =A0 Subject: = =A0 =A0 =A0 =A0[Pce] RE: I-D = ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt




Hi All,

Please review and comment on the = updated version of the PCE
communications = protocol (PCECP) generic requirements I-D
http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req=
s-03.txt.

Per our agreements at IETF-64 (see = JL's slide at
http://www3.ietf.org/proceedings/05nov/slides/pce-11/sld7.htm), the
referenced = requirements in the inter-area PCECP requirements draft have
been moved into the generic PCECP requirements draft. =A0In = particular,

- Section 6.1.17 'Objective Functions Supported' = was added
- Section 6.3.4 'LSP Rerouting & = Reoptimization' was updated

Our objective is to start a WG last = call soon. =A0We look forward to your
review and = comments.

Thanks,
Jerry

-----Original = Message-----
From:
[] On Behalf = Of
Internet-Drafts@ietf.org
Sent: = Wednesday, December 28, 2005 10:50 AM
To: = i-d-announce@ietf.org
Cc:
Subject: I-D = ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.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.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: PCE Communication Protocol = Generic
Requirements
=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : J. Le Roux, = J. Ash
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Filename =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 : = draft-ietf-pce-comm-protocol-gen-reqs-03.txt
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: 22
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: 2005-12-28
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
The PCE model is described in the "PCE Architecture" document = and
=A0 facilitates path computation requests from = Path Computation Clients
=A0 (PCCs) to = Path Computation Elements (PCEs). =A0This document specifies
=A0 generic requirements for a communication protocol between = PCCs and
=A0 PCEs, and also between PCEs where = cooperation between PCEs is
=A0 desirable. = =A0Subsequent documents will specify application-specific
=A0 requirements for the PCE communication = protocol.

A URL for this Internet-Draft = is:
http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req=
s-03.txt

Pce mailing list



=A0
Pce mailing list=A0
=A0
=A0



__________________________________= _____________
Pce mailing list
Pce@lists.ietf.org
https://www1.= ietf.org/mailman/listinfo/pce


= --Apple-Mail-143--577660699-- --===============0621645722== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0621645722==-- From pce-bounces@lists.ietf.org Sat Jan 07 09:41:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvFGH-0000wz-D6; Sat, 07 Jan 2006 09:41:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvFGF-0000wr-7K for pce@megatron.ietf.org; Sat, 07 Jan 2006 09:41:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12994 for ; Sat, 7 Jan 2006 09:40:22 -0500 (EST) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvFMM-0004dP-09 for pce@ietf.org; Sat, 07 Jan 2006 09:47:58 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3) with ESMTP id k07EfPQK032138; Sat, 7 Jan 2006 15:41:25 +0100 In-Reply-To: <026b01c61393$19343550$6601a8c0@movaz.com> To: "Igor Bryskin" Subject: Re: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Sat, 7 Jan 2006 15:41:25 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 01/07/2006 15:41:25, Serialize complete at 01/07/2006 15:41:25 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.3 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: pce-bounces@ietf.org, pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org igor, indeed, and as i indicated a re-optimization computation is to be performed not only by taking into account the global network resource consumption pruned from the bandwidth used by the LSP requesting re-optimization (hence, as if it was a newly requested path) but also taking account the constraint put by the current path itself; this should be policy-driven as it is dependent on the gain obtained (in terms of bandwidth for inst.) vs modification implied ... this means the "re-optimization" process is bound; to come to the text, it reads as "optimization" is the only criteria independently of gain and impact "Igor Bryskin" Sent by: pce-bounces@lists.ietf.org 07/01/2006 15:03 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "JP Vasseur" cc: pce@ietf.org Subject: Re: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt Hi, I think both Dimitri and JP are correct here. While performing re-optimization path computation PCE needs to know about the old path for two reasons: a) Not to block TE links that do not have enough bandwidth (JP's point) b) Not to route the new path unnecessarily over new TE links (for example in case of equal cost paths) to avoid extra resource management activities that could adversely affect network stability (Dimitri's point) Igor ----- Original Message ----- From: Dimitri.Papadimitriou@alcatel.be To: JP Vasseur Cc: pce@ietf.org Sent: Friday, January 06, 2006 6:15 PM Subject: Re: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt hi - see in-line On Jan 6, 2006, at 4:13 PM, Dimitri.Papadimitriou@alcatel.be wrote: hi jerry section 6.1.17 mentions The PCECP MUST support the following "unsynchronized" objective functions: o Minimum cost path (shortest path) o Least loaded path (widest path) o To be determined not sure to understand the last bullet, this said by mandating multiple functions, there is no "simple" default anymore one should assess the impact of such implication Right. section 6.3.14 " The path computation request message MUST support TE LSP path reoptimization and the inclusion of a previously computed path." i don't understand the sentence, how a message can support re-optimization; i think you mean here that an indication is required as part of the message ? btw, the only that differentiates the path request for re-routing vs re-optimization is timing, and that the former must support inclusion of the failed element and the "old path" this is not the case for re-optimization " This will help ensure optimal routing of a reoptimized path, since it will allow the PCE to avoid double bandwidth accounting and help reduce blocking issues." the fact of giving the "old path" is not an indication of avoiding double bandwidth accounting (it is linked to make-before-break process) nor ensuring optimal routing Well this is easy to understand. You must be able to differentiate the two following cases: (1) PCC requests a path computation for a new LSP (2) PCC requests a path computation for an existing LSP: this refers to as the reoptimization case and of course, the PCC needs to provide the existing path to avoid double bandwidth accounting that could lead to sub-optimal path ... [dp] understood but the answer depends on the first point i.e. is there an explicit indication for re-optimzation or not - the sentence says "and" the inclusion so i consider this is an information put in addition of the explicit indication ? please confirm or infirm because the sentence is open to interpetation; [dp] now, the only purpose for having this additional information is to force the "new path" to make use as much as possible of the "old path" such as to minimize the sum of the resources required by the old and the new path during the transient period of re-optimization (hence, including the "old path" is not an indication for avoiding double booking it is an indication for minimizing the transient resource required for the re-optimization) JP. thanks, - dimitri. "Ash, Gerald R \(Jerry\), ALABS" Sent by: pce-bounces@lists.ietf.org 28/12/2005 18:18 To: cc: Subject: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt Hi All, Please review and comment on the updated version of the PCE communications protocol (PCECP) generic requirements I-D http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req s-03.txt. Per our agreements at IETF-64 (see JL's slide at http://www3.ietf.org/proceedings/05nov/slides/pce-11/sld7.htm), the referenced requirements in the inter-area PCECP requirements draft have been moved into the generic PCECP requirements draft. In particular, - Section 6.1.17 'Objective Functions Supported' was added - Section 6.3.4 'LSP Rerouting & Reoptimization' was updated Our objective is to start a WG last call soon. We look forward to your review and comments. Thanks, Regards, Jerry -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, December 28, 2005 10:50 AM To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.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 : PCE Communication Protocol Generic Requirements Author(s) : J. Le Roux, J. Ash Filename : draft-ietf-pce-comm-protocol-gen-reqs-03.txt Pages : 22 Date : 2005-12-28 The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req s-03.txt _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sat Jan 07 10:13:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvFlC-0003DI-MD; Sat, 07 Jan 2006 10:13:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvFgJ-0001cy-R1 for pce@megatron.ietf.org; Sat, 07 Jan 2006 10:08:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14307 for ; Sat, 7 Jan 2006 10:07:18 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvFmP-0005F5-GV for pce@ietf.org; Sat, 07 Jan 2006 10:14:55 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 07 Jan 2006 07:08:25 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k07F8OWF017868; Sat, 7 Jan 2006 07:08:24 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 7 Jan 2006 10:08:24 -0500 Received: from [192.168.1.101] ([10.86.240.196]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 7 Jan 2006 10:08:21 -0500 In-Reply-To: <02ac01c61399$29c30ad0$6601a8c0@movaz.com> References: <026b01c61393$19343550$6601a8c0@movaz.com> <02ac01c61399$29c30ad0$6601a8c0@movaz.com> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 Message-Id: From: JP Vasseur Subject: Re: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt Date: Sat, 7 Jan 2006 10:07:49 -0500 To: "Igor Bryskin" X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 07 Jan 2006 15:08:21.0480 (UTC) FILETIME=[32CD9E80:01C6139C] X-Spam-Score: 0.4 (/) X-Scan-Signature: 53bbbffb1f9e780660701ef83a59efe0 X-Mailman-Approved-At: Sat, 07 Jan 2006 10:13:37 -0500 Cc: Dimitri.Papadimitriou@alcatel.be, pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0754880790==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============0754880790== Content-Type: multipart/alternative; boundary=Apple-Mail-144--574520567 --Apple-Mail-144--574520567 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi, On Jan 7, 2006, at 9:46 AM, Igor Bryskin wrote: > Hi. > > I probably misunderstood the Dimitiri's point. In this case I have > a point of my own :=) > > If a PCE, while performing path re-optimization, finds out that a > new path exists and it has the same (or even insignificantly > better) cost as the old path. > Would it be beneficial if the PCE in this case returns the old path > rather than the new path? I think yes, because in this case > unnecessary resource management activities would be avoided. The > point is that there is another reason (apart from avoiding double > booking) to pass to PCE the old path in the path re-optimization > request, which I suggest to be spelled out > Well I do not think that we need to spell all the reasons ;-) ... in the requirement document. The optimization that you have mentioned above exist in several implementations already with co-located PCE, along with many other ones. Thanks. JP. > > Igor > ----- Original Message ----- > From: JP Vasseur > To: Igor Bryskin > Cc: Dimitri.Papadimitriou@alcatel.be ; pce@ietf.org > Sent: Saturday, January 07, 2006 9:15 AM > Subject: Re: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen- > reqs-03.txt > > Hi Igor, > > On Jan 7, 2006, at 9:03 AM, Igor Bryskin wrote: > >> Hi, >> >> I think both Dimitri and JP are correct here. While performing re- >> optimization path computation PCE needs to know about the old path >> for two reasons: >> >> a) Not to block TE links that do not have enough bandwidth (JP's >> point) >> b) Not to route the new path unnecessarily over new TE links (for >> example in case of equal cost paths) to avoid extra resource >> management activities that could adversely affect network >> stability (Dimitri's point) >> > > Well note that (a) is clearly mandatory and easy to understand. > > Dimitri's point on whether the PCE should try to "to force the > "new path" to make use as much as possible of the "old path" such > as to minimize the sum of the resources required by the old and the > new path during the transient period of re-optimization" is > arguable since this may lead to a less optimal path of course. But > this is an algorithmic aspect that does not need to be standardized. > > Bottom line is that the only request was editorial to clarify the > need. > > Thanks. > > JP. > >> >> Igor >> ----- Original Message ----- >> From: Dimitri.Papadimitriou@alcatel.be >> To: JP Vasseur >> Cc: pce@ietf.org >> Sent: Friday, January 06, 2006 6:15 PM >> Subject: Re: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen- >> reqs-03.txt >> >> >> hi - see in-line >> >> >> >> On Jan 6, 2006, at 4:13 PM, Dimitri.Papadimitriou@alcatel.be wrote: >> >> >> hi jerry >> >> section 6.1.17 mentions >> >> The PCECP MUST support the following "unsynchronized" objective >> functions: >> >> o Minimum cost path (shortest path) >> o Least loaded path (widest path) >> o To be determined >> >> not sure to understand the last bullet, this said by mandating >> multiple functions, there is no "simple" default anymore one >> should assess the impact of such implication >> >> >> Right. >> >> section 6.3.14 >> >> " The path computation request message MUST support TE LSP path >> reoptimization and the inclusion of a previously computed path." >> >> i don't understand the sentence, how a message can support re- >> optimization; i think you mean here that an indication is required >> as part of the message ? >> >> btw, the only that differentiates the path request for re-routing >> vs re-optimization is timing, and that the former must support >> inclusion of the failed element and the "old path" this is not the >> case for re-optimization >> >> " This will help ensure optimal routing of a reoptimized path, >> since it will >> allow the PCE to avoid double bandwidth accounting and help reduce >> blocking issues." >> >> the fact of giving the "old path" is not an indication of avoiding >> double bandwidth accounting (it is linked to make-before-break >> process) nor ensuring optimal routing >> >> >> Well this is easy to understand. You must be able to differentiate >> the two following cases: >> (1) PCC requests a path computation for a new LSP >> (2) PCC requests a path computation for an existing LSP: this >> refers to as the reoptimization case and of course, the PCC needs >> to provide the existing path to avoid double bandwidth accounting >> that could lead to sub-optimal path ... >> >> [dp] understood but the answer depends on the first point i.e. is >> there an explicit indication for re-optimzation or not - the >> sentence says "and" the inclusion so i consider this is an >> information put in addition of the explicit indication ? please >> confirm or infirm because the sentence is open to interpetation; >> >> [dp] now, the only purpose for having this additional information >> is to force the "new path" to make use as much as possible of the >> "old path" such as to minimize the sum of the resources required >> by the old and the new path during the transient period of re- >> optimization (hence, including the "old path" is not an indication >> for avoiding double booking it is an indication for minimizing the >> transient resource required for the re-optimization) >> >> JP. >> >> thanks, >> - dimitri. >> >> >> "Ash, Gerald R \(Jerry\), ALABS" >> Sent by: pce-bounces@lists.ietf.org >> 28/12/2005 18:18 >> >> >> To: >> cc: >> Subject: [Pce] RE: I-D ACTION:draft-ietf-pce-comm- >> protocol-gen-reqs-03.txt >> >> >> >> >> Hi All, >> >> Please review and comment on the updated version of the PCE >> communications protocol (PCECP) generic requirements I-D >> http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol- >> gen-req >> s-03.txt. >> >> Per our agreements at IETF-64 (see JL's slide at >> http://www3.ietf.org/proceedings/05nov/slides/pce-11/sld7.htm), the >> referenced requirements in the inter-area PCECP requirements draft >> have >> been moved into the generic PCECP requirements draft. In particular, >> >> - Section 6.1.17 'Objective Functions Supported' was added >> - Section 6.3.4 'LSP Rerouting & Reoptimization' was updated >> >> Our objective is to start a WG last call soon. We look forward to >> your >> review and comments. >> >> Thanks, >> Regards, >> Jerry >> >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org >> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >> Internet-Drafts@ietf.org >> Sent: Wednesday, December 28, 2005 10:50 AM >> To: i-d-announce@ietf.org >> Cc: pce@ietf.org >> Subject: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.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 : PCE >> Communication Protocol Generic >> Requirements >> Author(s) : J. Le Roux, J. Ash >> Filename : draft-ietf-pce-comm- >> protocol-gen-reqs-03.txt >> Pages : 22 >> Date : 2005-12-28 >> >> The PCE model is described in the "PCE Architecture" document and >> facilitates path computation requests from Path Computation Clients >> (PCCs) to Path Computation Elements (PCEs). This document >> specifies >> generic requirements for a communication protocol between PCCs and >> PCEs, and also between PCEs where cooperation between PCEs is >> desirable. Subsequent documents will specify application-specific >> requirements for the PCE communication protocol. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol- >> gen-req >> s-03.txt >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> >> >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> > > --Apple-Mail-144--574520567 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

On Jan 7, = 2006, at 9:46 AM, Igor Bryskin wrote:

Hi.
=A0
=A0
If=A0a PCE, = while performing path re-optimization, finds out that a new path exists = and it has the same (or even insignificantly better) cost as the old = path.
Would it be = beneficial if the PCE in this case returns the old path rather than = the=A0new path?=A0I think yes, = because in this case unnecessary=A0resource management activities would = be avoided. The point is that there is another reason (apart from = avoiding double booking) to pass to PCE the old path in the path = re-optimization request, which I suggest to be spelled = out


Well I do not think that we = need to spell all the reasons ;-) ... in the requirement = document.

The = optimization that you have mentioned above exist in several = implementations already with co-located PCE, along with many other = ones.

Thanks.

JP.

----- Original Message -----

<= /DIV>Hi Igor,

On Jan 7, 2006, at 9:03 AM, Igor Bryskin = wrote:

=A0
I think both = Dimitri and JP are correct here. While performing re-optimization path = computation PCE needs to know about the old path for two = reasons:
=A0
a) Not to block = TE links that do not have enough bandwidth (JP's = point)
b) = Not to route the new path unnecessarily over new TE links (for example = in case of equal cost paths) to avoid extra resource=A0management = activities that could adversely affect network stability (Dimitri's = point)=A0


Well note that (a) is = clearly mandatory and easy to understand.=A0

Dimitri's point on whether = the PCE should try to=A0 "to force the "new = path" to make use as much as possible of the "old path" such as to = minimize the sum of the resources required by the old and the new path = during the transient period of re-optimization" is = arguable since this may lead to a less optimal path of course. But this = is an algorithmic aspect that does not need to be = standardized.

Bottom line is that the = only request was editorial to clarify the need.

Thanks.

JP.

=A0
hi - see = in-line=A0



On Jan 6, 2006, at 4:13 PM, Dimitri.Papadimitriou@alcatel.be wrote:=A0


hi jerry =

section 6.1.17 mentions =

The PCECP MUST support the following = "unsynchronized" objective
=A0 functions:

=A0 o Minimum cost = path (shortest path)
=A0 o Least loaded path (widest path)
=A0 o To be determined

not =A0sure to understand the last = bullet, this said by mandating multiple functions, there is no "simple" = default anymore one should assess the impact of such implication =


Right.=A0

section 6.3.14 =

" =A0The path computation request = message MUST support TE LSP path
=A0reoptimization and the inclusion of a previously computed = path."

i don't understand the sentence, how a = message can support re-optimization; i think you mean here that an = indication is required as part of the message ?

btw, the only that differentiates the = path request for re-routing vs re-optimization is timing, and that the = former must support inclusion of the failed element and the "old path" = this is not the case for re-optimization

" This will help ensure optimal routing = of a reoptimized path, since it will
=A0allow the PCE to avoid double bandwidth accounting and help = reduce
=A0blocking = issues."

the fact of giving = the "old path" is not an indication of avoiding double bandwidth = accounting (it is linked to make-before-break process) nor ensuring = optimal routing


Well this is easy to understand. You = must be able to differentiate the two following = cases:=A0
(1) PCC requests a = path computation for a new LSP=A0
(2) PCC requests a = path computation for an existing LSP: this refers to as the = reoptimization case and of course, the PCC needs to provide the existing = path to avoid double bandwidth accounting that could lead to sub-optimal = path ...=A0

[dp] understood = but the answer depends on the first point i.e. is there an explicit = indication for re-optimzation or not - the sentence says "and" the = inclusion so i consider this is an information put in addition of the = explicit indication ? please confirm or infirm because the sentence is = open to interpetation;

[dp] now, the only = purpose for having this additional information is to force the "new = path" to make use as much as possible of the "old path" such as to = minimize the sum of the resources required by the old and the new path = during the transient period of re-optimization (hence, including the = "old path" is not an indication for avoiding double booking it is an = indication for minimizing the transient resource required for the = re-optimization)=A0

=A0

thanks, =
- dimitri. =


"Ash, Gerald R \(Jerry\), = ALABS" <>
Sent by:

28/12/2005 = 18:18

=A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 To: =A0 =A0 = =A0 =A0<>
=A0 =A0 =A0 =A0 cc: =A0 =A0 =A0 =A0
=A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0[Pce] RE: I-D = ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt




Hi All,

Please review and comment on the updated = version of the PCE
communications protocol (PCECP) generic requirements = I-D
http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req=
s-03.txt.

Per our agreements at IETF-64 (see JL's = slide at
http://www3.ietf.org/proceedings/05nov/slides/pce-11/sld7.htm), the
referenced requirements in the = inter-area PCECP requirements draft have
been moved into the generic PCECP = requirements draft. =A0In particular,

- Section 6.1.17 'Objective Functions Supported' was = added
- Section 6.3.4 = 'LSP Rerouting & Reoptimization' was updated

Our objective is to start a WG last call = soon. =A0We look forward to your
review and comments.


-----Original = Message-----
From: = i-d-announce-bounces@ietf.org
[mailto:i-d-announce-bounces@ietf.org] On Behalf Of
Internet-Drafts@ietf.org
Sent: Wednesday, December 28, 2005 10:50 AM
To: i-d-announce@ietf.org
Cc: pce@ietf.org
Subject: I-D = ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.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.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Title =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: PCE = Communication Protocol Generic
Requirements
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 : J. Le Roux, J. Ash
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 : draft-ietf-pce-comm-protocol-gen-reqs-03.txt
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Pages =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: = 22
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0: 2005-12-28
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
The PCE model is described in the "PCE = Architecture" document and
=A0 facilitates path computation requests from Path Computation = Clients
=A0 (PCCs) to Path = Computation Elements (PCEs). =A0This document specifies
=A0 generic requirements for a = communication protocol between PCCs and
=A0 PCEs, and also between PCEs where = cooperation between PCEs is
=A0 desirable. =A0Subsequent documents will specify = application-specific
=A0 requirements for the PCE communication = protocol.

A URL for this = Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req=
s-03.txt

Pce mailing = list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce

=A0
Pce mailing = list=A0
Pce@lists.ietf.org=A0
https://www1.ietf.org/mailman/listinfo/pce=A0



__________________________________= _____________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/= mailman/listinfo/pce




= --Apple-Mail-144--574520567-- --===============0754880790== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0754880790==-- From pce-bounces@lists.ietf.org Sat Jan 07 10:13:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvFlP-0003JB-VI; Sat, 07 Jan 2006 10:13:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvFLE-0002i7-Hy for pce@megatron.ietf.org; Sat, 07 Jan 2006 09:46:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13163 for ; Sat, 7 Jan 2006 09:45:30 -0500 (EST) Received: from webmail.movaz.com ([70.158.43.219] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvFRK-0004ir-9s for pce@ietf.org; Sat, 07 Jan 2006 09:53:07 -0500 Received: from ib (vpn17.atlanta.movaz.com [172.18.0.17]) by jera.movaz.com (Postfix) with SMTP id 4BACE12E1C; Sat, 7 Jan 2006 09:43:59 -0500 (EST) Message-ID: <02ac01c61399$29c30ad0$6601a8c0@movaz.com> From: "Igor Bryskin" To: "JP Vasseur" References: <026b01c61393$19343550$6601a8c0@movaz.com> Subject: Re: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt Date: Sat, 7 Jan 2006 09:46:37 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.4 (/) X-Scan-Signature: a524c7c9e934f9a0c4cc31bc9e9e4c51 X-Mailman-Approved-At: Sat, 07 Jan 2006 10:13:49 -0500 Cc: Dimitri.Papadimitriou@alcatel.be, pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0469829259==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0469829259== Content-Type: multipart/alternative; boundary="----=_NextPart_000_02A9_01C6136F.40B8FA80" This is a multi-part message in MIME format. ------=_NextPart_000_02A9_01C6136F.40B8FA80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi. I probably misunderstood the Dimitiri's point. In this case I have a = point of my own :=3D) If a PCE, while performing path re-optimization, finds out that a new = path exists and it has the same (or even insignificantly better) cost as = the old path.=20 Would it be beneficial if the PCE in this case returns the old path = rather than the new path? I think yes, because in this case unnecessary = resource management activities would be avoided. The point is that there = is another reason (apart from avoiding double booking) to pass to PCE = the old path in the path re-optimization request, which I suggest to be = spelled out Igor=20 ----- Original Message -----=20 From: JP Vasseur=20 To: Igor Bryskin=20 Cc: Dimitri.Papadimitriou@alcatel.be ; pce@ietf.org=20 Sent: Saturday, January 07, 2006 9:15 AM Subject: Re: [Pce] RE: I-D = ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt Hi Igor, On Jan 7, 2006, at 9:03 AM, Igor Bryskin wrote: Hi, I think both Dimitri and JP are correct here. While performing = re-optimization path computation PCE needs to know about the old path = for two reasons: a) Not to block TE links that do not have enough bandwidth (JP's = point) b) Not to route the new path unnecessarily over new TE links (for = example in case of equal cost paths) to avoid extra resource management = activities that could adversely affect network stability (Dimitri's = point)=20 Well note that (a) is clearly mandatory and easy to understand.=20 Dimitri's point on whether the PCE should try to "to force the "new = path" to make use as much as possible of the "old path" such as to = minimize the sum of the resources required by the old and the new path = during the transient period of re-optimization" is arguable since this = may lead to a less optimal path of course. But this is an algorithmic = aspect that does not need to be standardized. Bottom line is that the only request was editorial to clarify the = need. Thanks. JP. Igor ----- Original Message ----- From: Dimitri.Papadimitriou@alcatel.be To: JP Vasseur Cc: pce@ietf.org Sent: Friday, January 06, 2006 6:15 PM Subject: Re: [Pce] RE: I-D = ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt hi - see in-line=20 On Jan 6, 2006, at 4:13 PM, Dimitri.Papadimitriou@alcatel.be = wrote:=20 hi jerry=20 section 6.1.17 mentions=20 The PCECP MUST support the following "unsynchronized" objective functions: o Minimum cost path (shortest path)=20 o Least loaded path (widest path) o To be determined=20 not sure to understand the last bullet, this said by mandating = multiple functions, there is no "simple" default anymore one should = assess the impact of such implication=20 Right.=20 section 6.3.14=20 " The path computation request message MUST support TE LSP path reoptimization and the inclusion of a previously computed path."=20 i don't understand the sentence, how a message can support = re-optimization; i think you mean here that an indication is required as = part of the message ?=20 btw, the only that differentiates the path request for re-routing = vs re-optimization is timing, and that the former must support inclusion = of the failed element and the "old path" this is not the case for = re-optimization " This will help ensure optimal routing of a reoptimized path, = since it will allow the PCE to avoid double bandwidth accounting and help = reduce blocking issues."=20 the fact of giving the "old path" is not an indication of avoiding = double bandwidth accounting (it is linked to make-before-break process) = nor ensuring optimal routing=20 Well this is easy to understand. You must be able to differentiate = the two following cases:=20 (1) PCC requests a path computation for a new LSP=20 (2) PCC requests a path computation for an existing LSP: this = refers to as the reoptimization case and of course, the PCC needs to = provide the existing path to avoid double bandwidth accounting that = could lead to sub-optimal path ...=20 [dp] understood but the answer depends on the first point i.e. is = there an explicit indication for re-optimzation or not - the sentence = says "and" the inclusion so i consider this is an information put in = addition of the explicit indication ? please confirm or infirm because = the sentence is open to interpetation;=20 [dp] now, the only purpose for having this additional information = is to force the "new path" to make use as much as possible of the "old = path" such as to minimize the sum of the resources required by the old = and the new path during the transient period of re-optimization (hence, = including the "old path" is not an indication for avoiding double = booking it is an indication for minimizing the transient resource = required for the re-optimization)=20 JP.=20 thanks,=20 - dimitri.=20 "Ash, Gerald R \(Jerry\), ALABS" =20 Sent by: pce-bounces@lists.ietf.org 28/12/2005 18:18 =20 To: =20 cc: =20 Subject: [Pce] RE: I-D = ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt=20 Hi All, Please review and comment on the updated version of the PCE communications protocol (PCECP) generic requirements I-D = http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req s-03.txt. Per our agreements at IETF-64 (see JL's slide at http://www3.ietf.org/proceedings/05nov/slides/pce-11/sld7.htm), = the referenced requirements in the inter-area PCECP requirements draft = have been moved into the generic PCECP requirements draft. In = particular, - Section 6.1.17 'Objective Functions Supported' was added - Section 6.3.4 'LSP Rerouting & Reoptimization' was updated Our objective is to start a WG last call soon. We look forward to = your review and comments. Thanks, Regards, Jerry -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, December 28, 2005 10:50 AM To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt=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. Title : PCE = Communication Protocol Generic Requirements Author(s) : J. Le Roux, J. Ash Filename : = draft-ietf-pce-comm-protocol-gen-reqs-03.txt Pages : 22 Date : 2005-12-28 =20 The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation = Clients (PCCs) to Path Computation Elements (PCEs). This document = specifies generic requirements for a communication protocol between PCCs = and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify = application-specific requirements for the PCE communication protocol. A URL for this Internet-Draft is: = http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req s-03.txt _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________=20 Pce mailing list=20 Pce@lists.ietf.org=20 https://www1.ietf.org/mailman/listinfo/pce=20 -------------------------------------------------------------------------= - _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------=_NextPart_000_02A9_01C6136F.40B8FA80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi.
 
I probably misunderstood the Dimitiri's = point. In=20 this case I have a point of my own :=3D)
 
If a PCE, while performing path=20 re-optimization, finds out that a new path exists and it has the same = (or even=20 insignificantly better) cost as the old path.
Would it be beneficial if the PCE in = this case=20 returns the old path rather than the new path? I think yes, because in this case unnecessary resource = management=20 activities would be avoided. The point is that there is another reason = (apart=20 from avoiding double booking) to pass to PCE the old path in the path=20 re-optimization request, which I suggest to be spelled out
 
Igor 
----- Original Message -----
From:=20 JP = Vasseur=20
Cc: Dimitri.Papadimitriou@al= catel.be=20 ; pce@ietf.org
Sent: Saturday, January 07, = 2006 9:15=20 AM
Subject: Re: [Pce] RE: I-D=20 ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt

Hi Igor,

On Jan 7, 2006, at 9:03 AM, Igor Bryskin wrote:
Hi,
 
I think both Dimitri and JP are correct = here. While=20 performing re-optimization path computation PCE needs to know about = the old=20 path for two reasons:
 
a) Not to block TE links that do not have = enough=20 bandwidth (JP's point)
b) Not to route the new path unnecessarily = over new=20 TE links (for example in case of equal cost paths) to avoid extra=20 resource management activities that could adversely affect = network=20 stability (Dimitri's point) 


Well note that (a) is clearly mandatory and easy to=20 understand. 

Dimitri's point on whether the PCE should try to  "to force the "new path" to make use as much = as=20 possible of the "old path" such as to minimize the sum of the = resources=20 required by the old and the new path during the transient period of=20 re-optimization" is arguable since this may lead to a = less=20 optimal path of course. But this is an algorithmic aspect that does = not need=20 to be standardized.

Bottom line is that the only request was editorial to clarify the = need.

Thanks.

JP.

 
Igor
----- Original = Message=20 -----
Sent:=20 Friday, January 06, 2006 6:15 PM
Subject: Re:=20 [Pce] RE: I-D=20 ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt


hi - see=20 in-line 



On Jan 6, = 2006, at 4:13=20 PM, Dimitri.Papadimitriou@alcatel.be=20 wrote: 


hi jerry = section 6.1.17 = mentions=20

The PCECP MUST = support=20 the following "unsynchronized" objective =20 functions:
  o = Minimum cost=20 path (shortest path)   o Least = loaded=20 path (widest path)  o To be = determined not  sure = to=20 understand the last bullet, this said by mandating multiple = functions,=20 there is no "simple" default anymore one should assess the impact = of such=20 implication

Right. 

section 6.3.14 =

"=20  The path computation request message MUST support TE LSP=20 path
 reoptimization and=20 the inclusion of a previously computed path." i=20 don't understand the sentence, how a message can support = re-optimization;=20 i think you mean here that an indication is required as part of = the=20 message ?
btw, the only = that=20 differentiates the path request for re-routing vs re-optimization = is=20 timing, and that the former must support inclusion of the failed = element=20 and the "old path" this is not the case for = re-optimization"=20 This will help ensure optimal routing of a reoptimized path, since = it=20 will
 allow = the PCE to=20 avoid double bandwidth accounting and help reduce blocking = issues."=20

the fact of = giving the=20 "old path" is not an indication of avoiding double bandwidth = accounting=20 (it is linked to make-before-break process) nor ensuring optimal = routing=20

Well this is = easy to=20 understand. You must be able to differentiate the two following=20 cases: 
(1) PCC = requests a path=20 computation for a new LSP 
(2) PCC = requests a path=20 computation for an existing LSP: this refers to as the = reoptimization case=20 and of course, the PCC needs to provide the existing path to avoid = double=20 bandwidth accounting that could lead to sub-optimal path=20 ... 

[dp] = understood but the=20 answer depends on the first point i.e. is there an explicit = indication for=20 re-optimzation or not - the sentence says "and" the inclusion so i = consider this is an information put in addition of the explicit = indication=20 ? please confirm or infirm because the sentence is open to = interpetation;=20

[dp] now, the = only=20 purpose for having this additional information is to force the = "new path"=20 to make use as much as possible of the "old path" such as to = minimize the=20 sum of the resources required by the old and the new path during = the=20 transient period of re-optimization (hence, including the "old = path" is=20 not an indication for avoiding double booking it is an indication = for=20 minimizing the transient resource required for the=20 re-optimization) 

JP. 

thanks, = -=20 dimitri.
"Ash,=20 Gerald R \(Jerry\), ALABS" <gash@att.com>=20 Sent=20 by: pce-bounces@lists.ietf.org

28/12/2005=20 18:18

  =20        =20       To:      =20  <pce@ietf.org>=20  =20       cc:         =  =20       Subject:       =  [Pce] RE:=20 I-D=20 = ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt

Hi = All,Please review = and=20 comment on the updated version of the PCEcommunications = protocol=20 (PCECP) generic requirements I-Dhttp://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protoc= ol-gen-reqs-03.txt.Per our = agreements at=20 IETF-64 (see JL's slide athttp://www3.ietf.org/proceedings/05nov/slides/pce-11/sld7.htm<= /SPAN>), = thereferenced = requirements=20 in the inter-area PCECP requirements draft havebeen moved = into the=20 generic PCECP requirements draft.  In particular,-=20 Section 6.1.17 'Objective Functions Supported' was added
-=20 Section 6.3.4 'LSP Rerouting & Reoptimization' was = updatedOur objective = is to=20 start a WG last call soon.  We look forward to your
review and=20 comments.
Thanks,Regards,Jerry-----Original=20 Message-----From: = i-d-announce-bounces@ietf.org[mailto:i-d-announce-bounces@ietf.org] On Behalf=20 OfInternet-Drafts@ietf.orgSent: = Wednesday,=20 December 28, 2005 10:50 AMTo: = i-d-announce@ietf.orgCc: = pce@ietf.orgSubject: I-D=20 ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt A=20 New Internet-Draft is available from the on-line = Internet-Draftsdirectories.This draft is = a work=20 item of the Path Computation Element Working Groupof the = IETF.    =  =20           Title       =  =20                   =  =20      : PCE Communication Protocol Generic
Requirements    =  =20           Author(s)       =  =20         : J. Le Roux, J. Ash    =  =20           Filename       =  =20         :=20 draft-ietf-pce-comm-protocol-gen-reqs-03.txt    =  =20           Pages       =  =20                   =  =20      : 22    =  =20           Date       =    =20                   =  =20    : 2005-12-28    =  =20           The PCE model = is=20 described in the "PCE Architecture" document and  = facilitates path=20 computation requests from Path Computation Clients  (PCCs) = to Path=20 Computation Elements (PCEs).  This document = specifies  generic = requirements for a communication protocol between PCCs = and  PCEs, = and also=20 between PCEs where cooperation between PCEs is  = desirable.=20  Subsequent documents will specify = application-specific  = requirements for=20 the PCE communication protocol.A=20 URL for this Internet-Draft is:http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protoc= ol-gen-reqs-03.txt_______________________________________________Pce mailing=20 listPce@lists.ietf.orghttps://www1.ietf.org/mailman/listinfo/pce
_______________________________________________ 
Pce mailing=20 list 
Pce@lists.ietf.org 
https://www1.ietf.org/mailman/listinfo/pce 


___________________________________= ____________
Pce=20 mailing list
Pce@lists.ietf.org
https://www1= .ietf.org/mailman/listinfo/pce

------=_NextPart_000_02A9_01C6136F.40B8FA80-- --===============0469829259== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0469829259==-- From pce-bounces@lists.ietf.org Sat Jan 07 12:15:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvHdI-0002CI-Jt; Sat, 07 Jan 2006 12:13:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvHdH-0002C9-V0 for pce@megatron.ietf.org; Sat, 07 Jan 2006 12:13:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21262 for ; Sat, 7 Jan 2006 12:12:17 -0500 (EST) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvHjP-0000Av-TL for pce@ietf.org; Sat, 07 Jan 2006 12:19:56 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3) with ESMTP id k07HDK5l010652; Sat, 7 Jan 2006 18:13:20 +0100 In-Reply-To: To: JP Vasseur Subject: Re: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Sat, 7 Jan 2006 18:13:20 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 01/07/2006 18:13:20, Serialize complete at 01/07/2006 18:13:20 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.3 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: pce-bounces@ietf.org, pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org jp - the issue is not editorial, and is not (only) algorithmic because it has comm.protocol impact the text should read such as to indicate that the inclusion of the old path in the PCC->PCE request is such as 1) to avoid the PCE taking into account resources used by the path during new path computation (pruning) 2) to bind the gain obtained with this newly computed path vs modification implied from the old path hence, there are two possibilities o) either the PCC->PCE request should include as part of the request the expect, the gain from which PCC would accept receiving a different path from the PCE, and return the new path iff this gain is attained (PCE driven decision) o) or the PCE should provide in the response the gain between the old and new path, together with the new path (PCC driven decision) otherwise each time a new path, the requesting PCC will not have the possibility to assess what is the value of the answer (i.e. the new path) wrt to the modification from the current path thanks, - dimitri. JP Vasseur Sent by: pce-bounces@lists.ietf.org 07/01/2006 15:15 To: "Igor Bryskin" cc: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, pce@ietf.org Subject: Re: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt Hi Igor, On Jan 7, 2006, at 9:03 AM, Igor Bryskin wrote: Hi, I think both Dimitri and JP are correct here. While performing re-optimization path computation PCE needs to know about the old path for two reasons: a) Not to block TE links that do not have enough bandwidth (JP's point) b) Not to route the new path unnecessarily over new TE links (for example in case of equal cost paths) to avoid extra resource management activities that could adversely affect network stability (Dimitri's point) Well note that (a) is clearly mandatory and easy to understand. Dimitri's point on whether the PCE should try to "to force the "new path" to make use as much as possible of the "old path" such as to minimize the sum of the resources required by the old and the new path during the transient period of re-optimization" is arguable since this may lead to a less optimal path of course. But this is an algorithmic aspect that does not need to be standardized. Bottom line is that the only request was editorial to clarify the need. Thanks. JP. Igor ----- Original Message ----- From: Dimitri.Papadimitriou@alcatel.be To: JP Vasseur Cc: pce@ietf.org Sent: Friday, January 06, 2006 6:15 PM Subject: Re: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt hi - see in-line On Jan 6, 2006, at 4:13 PM, Dimitri.Papadimitriou@alcatel.be wrote: hi jerry section 6.1.17 mentions The PCECP MUST support the following "unsynchronized" objective functions: o Minimum cost path (shortest path) o Least loaded path (widest path) o To be determined not sure to understand the last bullet, this said by mandating multiple functions, there is no "simple" default anymore one should assess the impact of such implication Right. section 6.3.14 " The path computation request message MUST support TE LSP path reoptimization and the inclusion of a previously computed path." i don't understand the sentence, how a message can support re-optimization; i think you mean here that an indication is required as part of the message ? btw, the only that differentiates the path request for re-routing vs re-optimization is timing, and that the former must support inclusion of the failed element and the "old path" this is not the case for re-optimization " This will help ensure optimal routing of a reoptimized path, since it will allow the PCE to avoid double bandwidth accounting and help reduce blocking issues." the fact of giving the "old path" is not an indication of avoiding double bandwidth accounting (it is linked to make-before-break process) nor ensuring optimal routing Well this is easy to understand. You must be able to differentiate the two following cases: (1) PCC requests a path computation for a new LSP (2) PCC requests a path computation for an existing LSP: this refers to as the reoptimization case and of course, the PCC needs to provide the existing path to avoid double bandwidth accounting that could lead to sub-optimal path ... [dp] understood but the answer depends on the first point i.e. is there an explicit indication for re-optimzation or not - the sentence says "and" the inclusion so i consider this is an information put in addition of the explicit indication ? please confirm or infirm because the sentence is open to interpetation; [dp] now, the only purpose for having this additional information is to force the "new path" to make use as much as possible of the "old path" such as to minimize the sum of the resources required by the old and the new path during the transient period of re-optimization (hence, including the "old path" is not an indication for avoiding double booking it is an indication for minimizing the transient resource required for the re-optimization) JP. thanks, - dimitri. "Ash, Gerald R \(Jerry\), ALABS" Sent by: pce-bounces@lists.ietf.org 28/12/2005 18:18 To: cc: Subject: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt Hi All, Please review and comment on the updated version of the PCE communications protocol (PCECP) generic requirements I-D http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req s-03.txt. Per our agreements at IETF-64 (see JL's slide at http://www3.ietf.org/proceedings/05nov/slides/pce-11/sld7.htm), the referenced requirements in the inter-area PCECP requirements draft have been moved into the generic PCECP requirements draft. In particular, - Section 6.1.17 'Objective Functions Supported' was added - Section 6.3.4 'LSP Rerouting & Reoptimization' was updated Our objective is to start a WG last call soon. We look forward to your review and comments. Thanks, Regards, Jerry -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, December 28, 2005 10:50 AM To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.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 : PCE Communication Protocol Generic Requirements Author(s) : J. Le Roux, J. Ash Filename : draft-ietf-pce-comm-protocol-gen-reqs-03.txt Pages : 22 Date : 2005-12-28 The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req s-03.txt _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sat Jan 07 12:37:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvI0O-0005QX-Ka; Sat, 07 Jan 2006 12:37:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvI0N-0005QM-8D for pce@megatron.ietf.org; Sat, 07 Jan 2006 12:37:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22733 for ; Sat, 7 Jan 2006 12:36:09 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvI6V-0000tu-I4 for pce@ietf.org; Sat, 07 Jan 2006 12:43:48 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 07 Jan 2006 09:37:17 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,342,1131350400"; d="scan'208"; a="19222581:sNHT27702852" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k07HbE6H003016; Sat, 7 Jan 2006 12:37:14 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 7 Jan 2006 12:37:21 -0500 Received: from [192.168.1.101] ([10.86.240.196]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 7 Jan 2006 12:37:13 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt Date: Sat, 7 Jan 2006 12:36:41 -0500 To: Dimitri.Papadimitriou@alcatel.be X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 07 Jan 2006 17:37:13.0214 (UTC) FILETIME=[FE8811E0:01C613B0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24 Content-Transfer-Encoding: 7bit Cc: pce-bounces@ietf.org, pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org On Jan 7, 2006, at 12:13 PM, Dimitri.Papadimitriou@alcatel.be wrote: > jp - > > the issue is not editorial, and is not (only) algorithmic because > it has > comm.protocol impact > > the text should read such as to indicate that the inclusion of the old > path in the PCC->PCE request is such as > 1) to avoid the PCE taking into account resources used by the path > during > new path computation (pruning) > 2) to bind the gain obtained with this newly computed path vs > modification > implied from the old path > > hence, there are two possibilities > > o) either the PCC->PCE request should include as part of the > request the > expect, the gain from which PCC would accept receiving a different > path > from the PCE, and return the new path iff this gain is attained (PCE > driven decision) > > o) or the PCE should provide in the response the gain between the > old and > new path, together with the new path (PCC driven decision) > Make it simple, please ! Or at least not unnecessarily complicated ... The PCC will issue a regular request but in this case it will mention that this is for en existing LSP whose path is XYZ ... The PCE(s) will then deduct the bw of the existing path and compute a new path returned to the requester. As already explained, the PCC has to provide the existing path because otherwise the PCE would not provide the best results. If it turns out that the PCC does not want to use it because it is not significantly better this is the decision of the PCC: in any case, the PCE will have to compute the path, so it is easier to just provide it and let the PCC decide rather than adding a complex semantic in the request. As already pointed, this is how TE implementations with co-located PCEs have been working for years. There is no need to specify a complex semantic such as: I have a path X whose cost is Y, provide me a path if the newly computed path (considering that this is a reop) is better by x% ... You could also add a ton of other constraints in this case ... (hop counts, SRLG in common, ...). Now if you want to add other constraint such as "try to re-use the max number of common links", this is another requirement (with side effects: my opinion and I'll let the WG decide here). I'll stop the discussion here and let the authors of this ID and the WG voice their opinion but it it I think quite important to avoid unnecessary complexity if not required. JP. > otherwise each time a new path, the requesting PCC will not have the > possibility to assess what is the value of the answer (i.e. the new > path) > wrt to the modification from the current path > > thanks, > - dimitri. > > > > > > JP Vasseur > Sent by: pce-bounces@lists.ietf.org > 07/01/2006 15:15 > > To: "Igor Bryskin" > cc: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, pce@ietf.org > Subject: Re: [Pce] RE: I-D > ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt > > > Hi Igor, > > On Jan 7, 2006, at 9:03 AM, Igor Bryskin wrote: > > Hi, > > I think both Dimitri and JP are correct here. While performing > re-optimization path computation PCE needs to know about the old > path for > two reasons: > > a) Not to block TE links that do not have enough bandwidth (JP's > point) > b) Not to route the new path unnecessarily over new TE links (for > example > in case of equal cost paths) to avoid extra resource management > activities > that could adversely affect network stability (Dimitri's point) > > > Well note that (a) is clearly mandatory and easy to understand. > > Dimitri's point on whether the PCE should try to "to force the > "new path" > to make use as much as possible of the "old path" such as to > minimize the > sum of the resources required by the old and the new path during the > transient period of re-optimization" is arguable since this may > lead to a > less optimal path of course. But this is an algorithmic aspect that > does > not need to be standardized. > > Bottom line is that the only request was editorial to clarify the > need. > > Thanks. > > JP. > > > Igor > ----- Original Message ----- > From: Dimitri.Papadimitriou@alcatel.be > To: JP Vasseur > Cc: pce@ietf.org > Sent: Friday, January 06, 2006 6:15 PM > Subject: Re: [Pce] RE: I-D > ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt > > > hi - see in-line > > > > On Jan 6, 2006, at 4:13 PM, Dimitri.Papadimitriou@alcatel.be wrote: > > > hi jerry > > section 6.1.17 mentions > > The PCECP MUST support the following "unsynchronized" objective > functions: > > o Minimum cost path (shortest path) > o Least loaded path (widest path) > o To be determined > > not sure to understand the last bullet, this said by mandating > multiple > functions, there is no "simple" default anymore one should assess the > impact of such implication > > > Right. > > section 6.3.14 > > " The path computation request message MUST support TE LSP path > reoptimization and the inclusion of a previously computed path." > > i don't understand the sentence, how a message can support > re-optimization; i think you mean here that an indication is > required as > part of the message ? > > btw, the only that differentiates the path request for re-routing vs > re-optimization is timing, and that the former must support > inclusion of > the failed element and the "old path" this is not the case for > re-optimization > > " This will help ensure optimal routing of a reoptimized path, > since it > will > allow the PCE to avoid double bandwidth accounting and help reduce > blocking issues." > > the fact of giving the "old path" is not an indication of avoiding > double > bandwidth accounting (it is linked to make-before-break process) nor > ensuring optimal routing > > > Well this is easy to understand. You must be able to differentiate > the two > following cases: > (1) PCC requests a path computation for a new LSP > (2) PCC requests a path computation for an existing LSP: this > refers to as > the reoptimization case and of course, the PCC needs to provide the > existing path to avoid double bandwidth accounting that could lead to > sub-optimal path ... > > [dp] understood but the answer depends on the first point i.e. is > there an > explicit indication for re-optimzation or not - the sentence says > "and" > the inclusion so i consider this is an information put in addition > of the > explicit indication ? please confirm or infirm because the sentence is > open to interpetation; > > [dp] now, the only purpose for having this additional information > is to > force the "new path" to make use as much as possible of the "old path" > such as to minimize the sum of the resources required by the old > and the > new path during the transient period of re-optimization (hence, > including > the "old path" is not an indication for avoiding double booking it > is an > indication for minimizing the transient resource required for the > re-optimization) > > JP. > > thanks, > - dimitri. > > > > "Ash, Gerald R \(Jerry\), ALABS" > Sent by: pce-bounces@lists.ietf.org > 28/12/2005 18:18 > > To: > cc: > Subject: [Pce] RE: I-D > ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt > > > > > Hi All, > > Please review and comment on the updated version of the PCE > communications protocol (PCECP) generic requirements I-D > http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol- > gen-req > s-03.txt. > > Per our agreements at IETF-64 (see JL's slide at > http://www3.ietf.org/proceedings/05nov/slides/pce-11/sld7.htm), the > referenced requirements in the inter-area PCECP requirements draft > have > been moved into the generic PCECP requirements draft. In particular, > > - Section 6.1.17 'Objective Functions Supported' was added > - Section 6.3.4 'LSP Rerouting & Reoptimization' was updated > > Our objective is to start a WG last call soon. We look forward to > your > review and comments. > > Thanks, > Regards, > Jerry > > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Wednesday, December 28, 2005 10:50 AM > To: i-d-announce@ietf.org > Cc: pce@ietf.org > Subject: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.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 : PCE > Communication > Protocol Generic > Requirements > Author(s) : J. Le Roux, J. Ash > Filename : > draft-ietf-pce-comm-protocol-gen-reqs-03.txt > Pages : 22 > Date : 2005-12-28 > > The PCE model is described in the "PCE Architecture" document and > facilitates path computation requests from Path Computation Clients > (PCCs) to Path Computation Elements (PCEs). This document specifies > generic requirements for a communication protocol between PCCs and > PCEs, and also between PCEs where cooperation between PCEs is > desirable. Subsequent documents will specify application-specific > requirements for the PCE communication protocol. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol- > gen-req > s-03.txt > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sat Jan 07 13:21:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvIhR-0002TF-WC; Sat, 07 Jan 2006 13:21:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvIhQ-0002T1-4V for pce@megatron.ietf.org; Sat, 07 Jan 2006 13:21:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25549 for ; Sat, 7 Jan 2006 13:20:39 -0500 (EST) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvInY-0002Eu-9Y for pce@ietf.org; Sat, 07 Jan 2006 13:28:17 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3) with ESMTP id k07ILfrf015117; Sat, 7 Jan 2006 19:21:41 +0100 In-Reply-To: To: JP Vasseur Subject: Re: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Sat, 7 Jan 2006 19:21:41 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 01/07/2006 19:21:40, Serialize complete at 01/07/2006 19:21:40 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.3 (/) X-Scan-Signature: 9c7d7a899dc8f3389bf7ace6f0ad8e29 Cc: pce-bounces@ietf.org, pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org JP Vasseur 07/01/2006 18:36 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Igor Bryskin" , pce@ietf.org, pce-bounces@lists.ietf.org Subject: Re: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt On Jan 7, 2006, at 12:13 PM, Dimitri.Papadimitriou@alcatel.be wrote: > jp - > > the issue is not editorial, and is not (only) algorithmic because > it has > comm.protocol impact > > the text should read such as to indicate that the inclusion of the old > path in the PCC->PCE request is such as > 1) to avoid the PCE taking into account resources used by the path > during > new path computation (pruning) > 2) to bind the gain obtained with this newly computed path vs > modification > implied from the old path > > hence, there are two possibilities > > o) either the PCC->PCE request should include as part of the > request the > expect, the gain from which PCC would accept receiving a different > path > from the PCE, and return the new path iff this gain is attained (PCE > driven decision) > > o) or the PCE should provide in the response the gain between the > old and > new path, together with the new path (PCC driven decision) > Make it simple, please ! Or at least not unnecessarily complicated ... [dp] re-optimization is a complex topic in any case; now the purpose here is that if you leave the PCC making a full re-check i don't think the global system is getting simpler because such operation will have to be performed in a way or another as i don't think it is a common practice to create unnecessary transients for the sake of a potentially infinitesimal gain; in brief, there is a set of operations to be performed in a re-optimization process and proposal here is to make use of a more convenient distribution of these operations The PCC will issue a regular request but in this case it will mention that this is for en existing LSP whose path is XYZ ... The PCE(s) will then deduct the bw of the existing path and compute a new path returned to the requester. As already explained, the PCC has to provide the existing path because otherwise the PCE would not provide the best results. If it turns out that the PCC does not want to use it because it is not significantly better this is the decision of the PCC: in any case, the PCE will have to compute the path, so it is easier to just provide it and let the PCC decide rather than adding a complex semantic in the request. As already pointed, this is how TE implementations with co-located PCEs have been working for years. [dp] the solution leaving the PCC making this decision is possible (see above, second bullet, PCC-driven decision process), what is important to avoid is a system where the PCC gets a new path and has to make a complete check whether the newly received path is of any value wrt to modification it implies There is no need to specify a complex semantic such as: I have a path X whose cost is Y, provide me a path if the newly computed path (considering that this is a reop) is better by x% ... You could also add a ton of other constraints in this case ... (hop counts, SRLG in common, ...). [dp] you could simply leave the PCE providing its estimation to the PCC as stated above (btw, constraints that can be used in the re-optimization process are the same than the those used for the initial computation; if the feeling is that we have too much mandatory constraints then one should revisit the latter set) Now if you want to add other constraint such as "try to re-use the max number of common links", this is another requirement (with side effects: my opinion and I'll let the WG decide here). [dp] as stated previously, it is part of the set of constraints that should be allowed in the context of a re-optimization process; for inst. in non-PSC networks, in particular, one of the big concerns in the re-optimization process is the sum of transient resources requires I'll stop the discussion here and let the authors of this ID and the WG voice their opinion but it it I think quite important to avoid unnecessary complexity if not required. JP. > otherwise each time a new path, the requesting PCC will not have the > possibility to assess what is the value of the answer (i.e. the new > path) > wrt to the modification from the current path > > thanks, > - dimitri. > > > > > > JP Vasseur > Sent by: pce-bounces@lists.ietf.org > 07/01/2006 15:15 > > To: "Igor Bryskin" > cc: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, pce@ietf.org > Subject: Re: [Pce] RE: I-D > ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt > > > Hi Igor, > > On Jan 7, 2006, at 9:03 AM, Igor Bryskin wrote: > > Hi, > > I think both Dimitri and JP are correct here. While performing > re-optimization path computation PCE needs to know about the old > path for > two reasons: > > a) Not to block TE links that do not have enough bandwidth (JP's > point) > b) Not to route the new path unnecessarily over new TE links (for > example > in case of equal cost paths) to avoid extra resource management > activities > that could adversely affect network stability (Dimitri's point) > > > Well note that (a) is clearly mandatory and easy to understand. > > Dimitri's point on whether the PCE should try to "to force the > "new path" > to make use as much as possible of the "old path" such as to > minimize the > sum of the resources required by the old and the new path during the > transient period of re-optimization" is arguable since this may > lead to a > less optimal path of course. But this is an algorithmic aspect that > does > not need to be standardized. > > Bottom line is that the only request was editorial to clarify the > need. > > Thanks. > > JP. > > > Igor > ----- Original Message ----- > From: Dimitri.Papadimitriou@alcatel.be > To: JP Vasseur > Cc: pce@ietf.org > Sent: Friday, January 06, 2006 6:15 PM > Subject: Re: [Pce] RE: I-D > ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt > > > hi - see in-line > > > > On Jan 6, 2006, at 4:13 PM, Dimitri.Papadimitriou@alcatel.be wrote: > > > hi jerry > > section 6.1.17 mentions > > The PCECP MUST support the following "unsynchronized" objective > functions: > > o Minimum cost path (shortest path) > o Least loaded path (widest path) > o To be determined > > not sure to understand the last bullet, this said by mandating > multiple > functions, there is no "simple" default anymore one should assess the > impact of such implication > > > Right. > > section 6.3.14 > > " The path computation request message MUST support TE LSP path > reoptimization and the inclusion of a previously computed path." > > i don't understand the sentence, how a message can support > re-optimization; i think you mean here that an indication is > required as > part of the message ? > > btw, the only that differentiates the path request for re-routing vs > re-optimization is timing, and that the former must support > inclusion of > the failed element and the "old path" this is not the case for > re-optimization > > " This will help ensure optimal routing of a reoptimized path, > since it > will > allow the PCE to avoid double bandwidth accounting and help reduce > blocking issues." > > the fact of giving the "old path" is not an indication of avoiding > double > bandwidth accounting (it is linked to make-before-break process) nor > ensuring optimal routing > > > Well this is easy to understand. You must be able to differentiate > the two > following cases: > (1) PCC requests a path computation for a new LSP > (2) PCC requests a path computation for an existing LSP: this > refers to as > the reoptimization case and of course, the PCC needs to provide the > existing path to avoid double bandwidth accounting that could lead to > sub-optimal path ... > > [dp] understood but the answer depends on the first point i.e. is > there an > explicit indication for re-optimzation or not - the sentence says > "and" > the inclusion so i consider this is an information put in addition > of the > explicit indication ? please confirm or infirm because the sentence is > open to interpetation; > > [dp] now, the only purpose for having this additional information > is to > force the "new path" to make use as much as possible of the "old path" > such as to minimize the sum of the resources required by the old > and the > new path during the transient period of re-optimization (hence, > including > the "old path" is not an indication for avoiding double booking it > is an > indication for minimizing the transient resource required for the > re-optimization) > > JP. > > thanks, > - dimitri. > > > > "Ash, Gerald R \(Jerry\), ALABS" > Sent by: pce-bounces@lists.ietf.org > 28/12/2005 18:18 > > To: > cc: > Subject: [Pce] RE: I-D > ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt > > > > > Hi All, > > Please review and comment on the updated version of the PCE > communications protocol (PCECP) generic requirements I-D > http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol- > gen-req > s-03.txt. > > Per our agreements at IETF-64 (see JL's slide at > http://www3.ietf.org/proceedings/05nov/slides/pce-11/sld7.htm), the > referenced requirements in the inter-area PCECP requirements draft > have > been moved into the generic PCECP requirements draft. In particular, > > - Section 6.1.17 'Objective Functions Supported' was added > - Section 6.3.4 'LSP Rerouting & Reoptimization' was updated > > Our objective is to start a WG last call soon. We look forward to > your > review and comments. > > Thanks, > Regards, > Jerry > > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Wednesday, December 28, 2005 10:50 AM > To: i-d-announce@ietf.org > Cc: pce@ietf.org > Subject: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.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 : PCE > Communication > Protocol Generic > Requirements > Author(s) : J. Le Roux, J. Ash > Filename : > draft-ietf-pce-comm-protocol-gen-reqs-03.txt > Pages : 22 > Date : 2005-12-28 > > The PCE model is described in the "PCE Architecture" document and > facilitates path computation requests from Path Computation Clients > (PCCs) to Path Computation Elements (PCEs). This document specifies > generic requirements for a communication protocol between PCCs and > PCEs, and also between PCEs where cooperation between PCEs is > desirable. Subsequent documents will specify application-specific > requirements for the PCE communication protocol. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol- > gen-req > s-03.txt > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sat Jan 07 19:34:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvOVa-0003oa-M9; Sat, 07 Jan 2006 19:34:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvOVZ-0003oN-ES for pce@megatron.ietf.org; Sat, 07 Jan 2006 19:34:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14684 for ; Sat, 7 Jan 2006 19:32:48 -0500 (EST) Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EvObh-00038I-7w for pce@ietf.org; Sat, 07 Jan 2006 19:40:29 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-4.tower-121.messagelabs.com!1136680410!9053378!5 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 1768 invoked from network); 8 Jan 2006 00:33:51 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-4.tower-121.messagelabs.com with SMTP; 8 Jan 2006 00:33:51 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 43AED14A0012661F; Sat, 7 Jan 2006 19:33:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt Date: Sat, 7 Jan 2006 18:33:49 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA98AB@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt Thread-Index: AcYTt5WYpFJriitZRK6HdPj75KPhKAAMlE8w From: "Ash, Gerald R \(Jerry\)" To: , "JP Vasseur" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org > I'll stop the discussion here and let the authors of this ID and the=20 > WG voice their opinion but it is I think quite important to avoid=20 > unnecessary complexity if not required. I agree with JP here. I have made a similar comment a few times wrt complexity of other PCE requirements... For reoptimization, IMO it is sufficient to request reoptimization and specify the current path. As suggested earlier by Dimitri, I think this wording of the requirement is fine: "The path computation request message MUST indicate if the computation is for path reoptimization of the TE LSP and MUST include the current path of this LSP." I think specifying thresholds for 'how much improvement will a PCC accept', etc., is more complex that needed at this stage. Perhaps we can add such a capability in a later phase, after we get some experience to verify that it is really needed. Thanks, Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jan 12 13:16:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex6zz-0001Uw-VQ; Thu, 12 Jan 2006 13:16:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex6zu-0001Uo-II for pce@megatron.ietf.org; Thu, 12 Jan 2006 13:16:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04852 for ; Thu, 12 Jan 2006 13:15:09 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex771-0003og-CB for pce@ietf.org; Thu, 12 Jan 2006 13:23:54 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 Jan 2006 19:16:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Working Group Last Call on draft-ietf-pce-architecture-03.txtended Date: Thu, 12 Jan 2006 19:16:27 +0100 Message-ID: Thread-Topic: [Pce] Working Group Last Call on draft-ietf-pce-architecture-03.txtended thread-index: AcYTkCyQM1eBoCy2RnO/GOMoQA2TdQEB92vg From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "JP Vasseur" , X-OriginalArrivalTime: 12 Jan 2006 18:16:23.0391 (UTC) FILETIME=[4B695EF0:01C617A4] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Jean-Philippe, all I'm waking up a bit late on this thread... Please see inline=20 > -----Message d'origine----- > De : pce-bounces@lists.ietf.org=20 > [mailto:pce-bounces@lists.ietf.org] De la part de JP Vasseur > Envoy=E9 : samedi 7 janvier 2006 14:41 > =C0 : pce@ietf.org > Objet : [Pce] Working Group Last Call on=20 > draft-ietf-pce-architecture-03.txtended >=20 > WG, >=20 > Working Group Last call on draft-ietf-pce-architecture-03.txt=20 > ended has ended on January 3. There were several points=20 > discussed on the list that all came to a resolution, except=20 > one that relates to the ability for the PCC to request from=20 > the PCE the use of a specific path computation algorithm.=20 > This was listed as a requirement by several individual in the=20 > past, three others recently mentioned that they were opposed >to it. If I well remember we add a long discussion a few monthes ago on this = aspect and it was agreed that the request should not specify the = algorithm but rather the objective function. And we updated the generic = requirement ID to account for the result of that discussion by the way. I fully agree here with Payam, Igor and Dimitri.=20 As already pointed out a few monthes ago, the PCC should IMO only = indicate the objective it wants to achieve and then the PCE can select, = in its algo box, an algorithm that achieves these objectives. = Algortithms definition and selection is definitely a local = implementation issue and should not be standardized. The algo selection = should stay a local PCE decision that depends on various parameters (PCE = capacities, PCE current load...).=20 Also there are plenty of (G)MPLS path computation algorithms with = plethora of variants, that differ with regards to the optimality, CPU = consumption and computation time. What about if PCE support twenty = distinct algorithms? As we all agree here, algorithm standarization does = not make sense, hence a mechanism would be required to indicate to PCCs = the characteristic of all these algorithms and the PCC would have to be = able to understand all these characteristics before to make a = selection... That' being said, it would be good to add, as a requirement, that the = request must allow indicating whether computation time is an issue or = not for the PCC (i.e. whether the PCC is hurried or not!). Then the PCE = can select an appropriate algo.=20 This could be achieved in a best effort way by using a simple bit flag = in the request: H=3D0 means that the PCC is not hurried and the PCE should not care = about computation time and should rather favor optimality when selecting = an algo. This is the case for instance when setting up a new LSP or = asking for a reoptimization. H=3D1 means that the PCC is hurried and the PCE should favor low = computation time when selecting an algo. This is the case for instance = when asking for an alternate path after failure (path restoration). Also, as suggested by Payam, this could be more sophisticated, and a PCC = may also optionally indicate a computation time bound. A PCE that has = the capability to predict the computation time of a given algo, based on = the algo type and its current CPU load, can select an algorithm that = best fits the optimization objectives and time constraints.=20 Also, there are some algorithms (like for instance Lagrange relaxation = based algorithms used for computation of delay bounded minimum cost = paths) that progress toward an optimal solution and can stop when time = is over and return the best computed path. Such approach would allow controlling the tradeoff "optimality vs = computation time" in a really flexible manner, and this sounds = definitely much better than a specific algorithm indication.=20 To conclude I would suggest not standardizing any algo selection = procedure but rather relying on objective functions that account for = optimization criterias and time constraints. Anyway, one could still rely on yet not defined proprietary PCEP = objects, if it really wants to support a proprietary PCC algo selection = procedure... Best Regards, JL >=20 > So we now need to close on this. Please voice you opinion. >=20 > Once we'll get an agreement on the list, thanks to Adrian for=20 > posting a new revision incorporating the changes. >=20 > Thanks. >=20 > JP. >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jan 12 15:48:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex9NR-0005HR-VF; Thu, 12 Jan 2006 15:48:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex9NM-0005HB-GE for pce@megatron.ietf.org; Thu, 12 Jan 2006 15:48:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16926 for ; Thu, 12 Jan 2006 15:47:30 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex9UV-0000ZT-4J for pce@ietf.org; Thu, 12 Jan 2006 15:56:17 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 12 Jan 2006 12:48:40 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0CKmdjt021532; Thu, 12 Jan 2006 12:48:40 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 Jan 2006 15:48:39 -0500 Received: from [192.168.1.101] ([10.86.242.175]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 Jan 2006 15:48:38 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <7FE7A738-365B-42B7-8A3D-D8A0F1CEE21C@cisco.com> Content-Transfer-Encoding: quoted-printable From: JP Vasseur Subject: Re: [Pce] Working Group Last Call on draft-ietf-pce-architecture-03.txtended Date: Thu, 12 Jan 2006 15:48:03 -0500 To: LE ROUX Jean-Louis RD-CORE-LAN X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 12 Jan 2006 20:48:39.0010 (UTC) FILETIME=[90AA3420:01C617B9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Jean-Louis, On Jan 12, 2006, at 1:16 PM, LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi Jean-Philippe, all > > I'm waking up a bit late on this thread... > No pb, still worth it ! > Please see inline > >> -----Message d'origine----- >> De : pce-bounces@lists.ietf.org >> [mailto:pce-bounces@lists.ietf.org] De la part de JP Vasseur >> Envoy=E9 : samedi 7 janvier 2006 14:41 >> =C0 : pce@ietf.org >> Objet : [Pce] Working Group Last Call on >> draft-ietf-pce-architecture-03.txtended >> >> WG, >> >> Working Group Last call on draft-ietf-pce-architecture-03.txt >> ended has ended on January 3. There were several points >> discussed on the list that all came to a resolution, except >> one that relates to the ability for the PCC to request from >> the PCE the use of a specific path computation algorithm. >> This was listed as a requirement by several individual in the >> past, three others recently mentioned that they were opposed >to it. > > If I well remember we add a long discussion a few monthes ago on =20 > this aspect and it was agreed that the request should not specify =20 > the algorithm but rather the objective function. And we updated the =20= > generic requirement ID to account for the result of that discussion =20= > by the way. > > I fully agree here with Payam, Igor and Dimitri. > As already pointed out a few monthes ago, the PCC should IMO only =20 > indicate the objective it wants to achieve and then the PCE can =20 > select, in its algo box, an algorithm that achieves these =20 > objectives. Algortithms definition and selection is definitely a =20 > local implementation issue and should not be standardized. The algo =20= > selection should stay a local PCE decision that depends on various =20 > parameters (PCE capacities, PCE current load...). Perfect ! We've got a WG consensus on this point that we can now close. > Also there are plenty of (G)MPLS path computation algorithms with =20 > plethora of variants, that differ with regards to the optimality, =20 > CPU consumption and computation time. What about if PCE support =20 > twenty distinct algorithms? As we all agree here, algorithm =20 > standarization does not make sense, hence a mechanism would be =20 > required to indicate to PCCs the characteristic of all these =20 > algorithms and the PCC would have to be able to understand all =20 > these characteristics before to make a selection... > > That' being said, it would be good to add, as a requirement, that =20 > the request must allow indicating whether computation time is an =20 > issue or not for the PCC (i.e. whether the PCC is hurried or not!). =20= > Then the PCE can select an appropriate algo. > This could be achieved in a best effort way by using a simple bit =20 > flag in the request: > H=3D0 means that the PCC is not hurried and the PCE should not = care =20 > about computation time and should rather favor optimality when =20 > selecting an algo. This is the case for instance when setting up a =20 > new LSP or asking for a reoptimization. > H=3D1 means that the PCC is hurried and the PCE should favor low = =20 > computation time when selecting an algo. This is the case for =20 > instance when asking for an alternate path after failure (path =20 > restoration). > > Also, as suggested by Payam, this could be more sophisticated, and =20 > a PCC may also optionally indicate a computation time bound. A PCE =20 > that has the capability to predict the computation time of a given =20 > algo, based on the algo type and its current CPU load, can select =20 > an algorithm that best fits the optimization objectives and time =20 > constraints. > Also, there are some algorithms (like for instance Lagrange =20 > relaxation based algorithms used for computation of delay bounded =20 > minimum cost paths) that progress toward an optimal solution and =20 > can stop when time is over and return the best computed path. > > Such approach would allow controlling the tradeoff "optimality vs =20 > computation time" in a really flexible manner, and this sounds =20 > definitely much better than a specific algorithm indication. > > To conclude I would suggest not standardizing any algo selection =20 > procedure but rather relying on objective functions that account =20 > for optimization criterias and time constraints. > Anyway, one could still rely on yet not defined proprietary PCEP =20 > objects, if it really wants to support a proprietary PCC algo =20 > selection procedure... Great, thanks. JP. > > Best Regards, > > JL > >> >> So we now need to close on this. Please voice you opinion. >> >> Once we'll get an agreement on the list, thanks to Adrian for >> posting a new revision incorporating the changes. >> >> Thanks. >> >> JP. >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jan 12 17:59:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExBPy-0000sv-86; Thu, 12 Jan 2006 17:59:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExBPv-0000pg-E0; Thu, 12 Jan 2006 17:59:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03196; Thu, 12 Jan 2006 17:58:18 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExBX5-0007IQ-6s; Thu, 12 Jan 2006 18:07:06 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 Jan 2006 23:58:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt Date: Thu, 12 Jan 2006 23:58:49 +0100 Message-ID: Thread-Topic: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt thread-index: AcYTt5GmdMCGDXgHTKm/yZOvMqthswEDIvLA From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , "JP Vasseur" X-OriginalArrivalTime: 12 Jan 2006 22:58:56.0610 (UTC) FILETIME=[C4514C20:01C617CB] X-Spam-Score: 0.0 (/) X-Scan-Signature: dfc64cf6e4c6efdbf6b8f4c995df04df Content-Transfer-Encoding: quoted-printable Cc: pce-bounces@ietf.org, pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Dimitri, [dp] as stated previously, it is part of the set of constraints that = should be allowed in the context of a re-optimization process; for inst. = in non-PSC networks, in particular, one of the big concerns in the = re-optimization process is the sum of transient resources requires=20 [JLLR] You have actually the same problem in packet networks when you = want to move a set of TE-LSPs. This is a well known "Morphing" problem. I agree with you that when doing a global reoptimization (that is taking = into account all LSPs in a coordinated manner) so as to improve a global = crieria (e.g. Minimize aggregate bandwidth consumption on all links), = you may want to take into account the set of old paths so as to avoid = blocking issues, and maybe also to minimize the number of rerouted LSPs = (minimum perturbation problem): If L1 is the initial LSPs layout and L2 = the final layout there are algorithms that compute L2 taking into = account L1 so as to allow L1-> L2 migration without any blocking issue.=20 However when you are reoptimizing on a per LSP basis, i.e. in a greedy = manner (for instance you are looking for a better path cost), the = problem is quite different. If you achieve to find a better path this = means that there are ressources available on this better path so I don't = see any transient ressource issue here. I agree that during the mb4b = reoptimization you will consume more ressources but they are available = anyway... By the way, trying to maximize link reutilization could become counter = productive w.r.t the reoptimization objective. You combine two = competitive criterias. You will end up with requests such as "Try to = reduce the path cost form X% while reusing at least Y% of links"...This = will rapidily become unmanageable from an operational point of view. Best Regards, JL > -----Message d'origine----- > De : pce-bounces@lists.ietf.org=20 > [mailto:pce-bounces@lists.ietf.org] De la part de=20 > Dimitri.Papadimitriou@alcatel.be > Envoy=E9 : samedi 7 janvier 2006 19:22 > =C0 : JP Vasseur > Cc : pce-bounces@ietf.org; pce@ietf.org > Objet : Re: [Pce] RE: I-D=20 > ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt >=20 > JP Vasseur > 07/01/2006 18:36 > =20 > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: "Igor Bryskin" , pce@ietf.org,=20 > pce-bounces@lists.ietf.org > Subject: Re: [Pce] RE: I-D=20 > ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt >=20 >=20 > On Jan 7, 2006, at 12:13 PM, Dimitri.Papadimitriou@alcatel.be wrote: >=20 > > jp - > > > > the issue is not editorial, and is not (only) algorithmic=20 > because it=20 > > has comm.protocol impact > > > > the text should read such as to indicate that the inclusion=20 > of the old=20 > > path in the PCC->PCE request is such as > > 1) to avoid the PCE taking into account resources used by the path=20 > > during new path computation (pruning) > > 2) to bind the gain obtained with this newly computed path vs=20 > > modification implied from the old path > > > > hence, there are two possibilities > > > > o) either the PCC->PCE request should include as part of=20 > the request=20 > > the expect, the gain from which PCC would accept receiving=20 > a different=20 > > path from the PCE, and return the new path iff this gain is=20 > attained=20 > > (PCE driven decision) > > > > o) or the PCE should provide in the response the gain=20 > between the old=20 > > and new path, together with the new path (PCC driven decision) > > >=20 > Make it simple, please ! Or at least not unnecessarily complicated ... >=20 > [dp] re-optimization is a complex topic in any case; now the=20 > purpose here is that if you leave the PCC making a full=20 > re-check i don't think the global system is getting simpler=20 > because such operation will have to be performed in a way or=20 > another as i don't think it is a common practice to create=20 > unnecessary transients for the sake of a potentially=20 > infinitesimal gain; in brief, there is a set of operations to=20 > be performed in a re-optimization process and proposal here=20 > is to make use of a more convenient distribution of these operations >=20 > The PCC will issue a regular request but in this case it will=20 > mention that this is for en existing LSP whose path is XYZ=20 > ... The PCE(s) will then deduct the bw of the existing path=20 > and compute a new path returned to the requester. As already=20 > explained, the PCC has to provide the existing path because=20 > otherwise the PCE would not provide the best results. If it=20 > turns out that the PCC does not want to use it because it is=20 > not significantly better this is the decision of the > PCC: in any case, the PCE will have to compute the path, so=20 > it is easier to just provide it and let the PCC decide rather=20 > than adding a complex semantic in the request. As already=20 > pointed, this is how TE implementations with co-located PCEs=20 > have been working for years. >=20 > [dp] the solution leaving the PCC making this decision is=20 > possible (see above, second bullet, PCC-driven decision=20 > process), what is important to avoid is a system where the=20 > PCC gets a new path and has to make a complete check whether=20 > the newly received path is of any value wrt to modification it implies >=20 > There is no need to specify a complex semantic such as: I=20 > have a path X whose cost is Y, provide me a path if the newly=20 > computed path (considering that this is a reop) is better by=20 > x% ... You could also add a ton of other constraints in this=20 > case ... (hop counts, SRLG in common, ...). >=20 > [dp] you could simply leave the PCE providing its estimation=20 > to the PCC as stated above (btw, constraints that can be used=20 > in the re-optimization process are the same than the those=20 > used for the initial computation; if the feeling is that we=20 > have too much mandatory constraints then one should revisit=20 > the latter set)=20 >=20 > Now if you want to add other constraint such as "try to=20 > re-use the max number of common links", this is another=20 > requirement (with side > effects: my opinion and I'll let the WG decide here). >=20 > [dp] as stated previously, it is part of the set of=20 > constraints that should be allowed in the context of a=20 > re-optimization process; for inst.=20 > in non-PSC networks, in particular, one of the big concerns=20 > in the re-optimization process is the sum of transient=20 > resources requires >=20 > I'll stop the discussion here and let the authors of this ID=20 > and the WG voice their opinion but it it I think quite=20 > important to avoid unnecessary complexity if not required. >=20 > JP. >=20 > > otherwise each time a new path, the requesting PCC will not=20 > have the=20 > > possibility to assess what is the value of the answer (i.e. the new > > path) > > wrt to the modification from the current path > > > > thanks, > > - dimitri. > > > > > > > > > > > > JP Vasseur > > Sent by: pce-bounces@lists.ietf.org > > 07/01/2006 15:15 > > > > To: "Igor Bryskin" > > cc: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL,=20 > pce@ietf.org > > Subject: Re: [Pce] RE: I-D > > ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt > > > > > > Hi Igor, > > > > On Jan 7, 2006, at 9:03 AM, Igor Bryskin wrote: > > > > Hi, > > > > I think both Dimitri and JP are correct here. While performing=20 > > re-optimization path computation PCE needs to know about=20 > the old path=20 > > for two reasons: > > > > a) Not to block TE links that do not have enough bandwidth (JP's > > point) > > b) Not to route the new path unnecessarily over new TE links (for=20 > > example in case of equal cost paths) to avoid extra resource=20 > > management activities that could adversely affect network stability=20 > > (Dimitri's point) > > > > > > Well note that (a) is clearly mandatory and easy to understand. > > > > Dimitri's point on whether the PCE should try to "to force the=20 > > "new path" > > to make use as much as possible of the "old path" such as to=20 > > minimize the > > sum of the resources required by the old and the new path during the > > transient period of re-optimization" is arguable since this may=20 > > lead to a > > less optimal path of course. But this is an algorithmic aspect that=20 > > does > > not need to be standardized. > > > > Bottom line is that the only request was editorial to clarify the=20 > > need. > > > > Thanks. > > > > JP. > > > > > > Igor > > ----- Original Message ----- > > From: Dimitri.Papadimitriou@alcatel.be > > To: JP Vasseur > > Cc: pce@ietf.org > > Sent: Friday, January 06, 2006 6:15 PM > > Subject: Re: [Pce] RE: I-D > > ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt > > > > > > hi - see in-line > > > > > > > > On Jan 6, 2006, at 4:13 PM, Dimitri.Papadimitriou@alcatel.be wrote: > > > > > > hi jerry > > > > section 6.1.17 mentions > > > > The PCECP MUST support the following "unsynchronized" objective > > functions: > > > > o Minimum cost path (shortest path) > > o Least loaded path (widest path) > > o To be determined > > > > not sure to understand the last bullet, this said by mandating=20 > > multiple > > functions, there is no "simple" default anymore one should=20 > assess the > > impact of such implication > > > > > > Right. > > > > section 6.3.14 > > > > " The path computation request message MUST support TE LSP path > > reoptimization and the inclusion of a previously computed path." > > > > i don't understand the sentence, how a message can support > > re-optimization; i think you mean here that an indication is=20 > > required as > > part of the message ? > > > > btw, the only that differentiates the path request for re-routing vs > > re-optimization is timing, and that the former must support=20 > > inclusion of > > the failed element and the "old path" this is not the case for > > re-optimization > > > > " This will help ensure optimal routing of a reoptimized path,=20 > > since it > > will > > allow the PCE to avoid double bandwidth accounting and help reduce > > blocking issues." > > > > the fact of giving the "old path" is not an indication of avoiding=20 > > double > > bandwidth accounting (it is linked to make-before-break process) nor > > ensuring optimal routing > > > > > > Well this is easy to understand. You must be able to differentiate=20 > > the two > > following cases: > > (1) PCC requests a path computation for a new LSP > > (2) PCC requests a path computation for an existing LSP: this=20 > > refers to as > > the reoptimization case and of course, the PCC needs to provide the > > existing path to avoid double bandwidth accounting that=20 > could lead to > > sub-optimal path ... > > > > [dp] understood but the answer depends on the first point i.e. is=20 > > there an > > explicit indication for re-optimzation or not - the sentence says=20 > > "and" > > the inclusion so i consider this is an information put in addition=20 > > of the > > explicit indication ? please confirm or infirm because the=20 > sentence is > > open to interpetation; > > > > [dp] now, the only purpose for having this additional information=20 > > is to > > force the "new path" to make use as much as possible of the=20 > "old path" > > such as to minimize the sum of the resources required by the old=20 > > and the > > new path during the transient period of re-optimization (hence,=20 > > including > > the "old path" is not an indication for avoiding double booking it=20 > > is an > > indication for minimizing the transient resource required for the > > re-optimization) > > > > JP. > > > > thanks, > > - dimitri. > > > > > > > > "Ash, Gerald R \(Jerry\), ALABS" > > Sent by: pce-bounces@lists.ietf.org > > 28/12/2005 18:18 > > > > To: > > cc: > > Subject: [Pce] RE: I-D > > ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt > > > > > > > > > > Hi All, > > > > Please review and comment on the updated version of the PCE > > communications protocol (PCECP) generic requirements I-D > > http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-=20 > > gen-req > > s-03.txt. > > > > Per our agreements at IETF-64 (see JL's slide at > > http://www3.ietf.org/proceedings/05nov/slides/pce-11/sld7.htm), the > > referenced requirements in the inter-area PCECP requirements draft=20 > > have > > been moved into the generic PCECP requirements draft. In=20 > particular, > > > > - Section 6.1.17 'Objective Functions Supported' was added > > - Section 6.3.4 'LSP Rerouting & Reoptimization' was updated > > > > Our objective is to start a WG last call soon. We look forward to=20 > > your > > review and comments. > > > > Thanks, > > Regards, > > Jerry > > > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org > > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > > Internet-Drafts@ietf.org > > Sent: Wednesday, December 28, 2005 10:50 AM > > To: i-d-announce@ietf.org > > Cc: pce@ietf.org > > Subject: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.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=20 > > Group > > of the IETF. > > > > Title : PCE=20 > > Communication > > Protocol Generic > > Requirements > > Author(s) : J. Le Roux, J. Ash > > Filename : > > draft-ietf-pce-comm-protocol-gen-reqs-03.txt > > Pages : 22 > > Date : 2005-12-28 > > > > The PCE model is described in the "PCE Architecture" document and > > facilitates path computation requests from Path=20 > Computation Clients > > (PCCs) to Path Computation Elements (PCEs). This=20 > document specifies > > generic requirements for a communication protocol between PCCs and > > PCEs, and also between PCEs where cooperation between PCEs is > > desirable. Subsequent documents will specify application-specific > > requirements for the PCE communication protocol. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-=20 > > gen-req > > s-03.txt > > > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > > > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce >=20 >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jan 12 18:05:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExBVw-0001sy-Hs; Thu, 12 Jan 2006 18:05:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExBVu-0001sp-EB for pce@megatron.ietf.org; Thu, 12 Jan 2006 18:05:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03688 for ; Thu, 12 Jan 2006 18:04:30 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExBd6-0007Vh-Sj for pce@ietf.org; Thu, 12 Jan 2006 18:13:17 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 Jan 2006 00:05:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt Date: Fri, 13 Jan 2006 00:05:42 +0100 Message-ID: Thread-Topic: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt thread-index: AcYTt5WYpFJriitZRK6HdPj75KPhKAAMlE8wAPhYN5A= From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Ash, Gerald R \(Jerry\)" , , "JP Vasseur" X-OriginalArrivalTime: 12 Jan 2006 23:05:43.0610 (UTC) FILETIME=[B6E891A0:01C617CC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Jerry, all,=20 > -----Message d'origine----- > De : pce-bounces@lists.ietf.org=20 > [mailto:pce-bounces@lists.ietf.org] De la part de Ash, Gerald=20 > R (Jerry) > Envoy=E9 : dimanche 8 janvier 2006 01:34 > =C0 : Dimitri.Papadimitriou@alcatel.be; JP Vasseur > Cc : pce@ietf.org > Objet : RE: [Pce] RE: I-D=20 > ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt >=20 > > I'll stop the discussion here and let the authors of this=20 > ID and the=20 > > WG voice their opinion but it is I think quite important to avoid=20 > > unnecessary complexity if not required. >=20 > I agree with JP here. I have made a similar comment a few=20 > times wrt complexity of other PCE requirements... >=20 > For reoptimization, IMO it is sufficient to request=20 > reoptimization and specify the current path. As suggested=20 > earlier by Dimitri, I think this wording of the requirement is fine: > "The path computation request message MUST indicate if the=20 > computation is for path reoptimization of the TE LSP and MUST=20 > include the current path of this LSP." This re-wording sounds good to me.=20 The requirement is quite straightforward by the way. There is functionally nothing new from what is performed today on = head-end LSRs... >=20 > I think specifying thresholds for 'how much improvement will=20 > a PCC accept', etc., is more complex that needed at this stage. I agree. IMO this introduces useless complexity at this stage. As well = pointed out by JP the path needs to be computed anyway so why not = replying and letting the PCC decide whether the LSP has to be = reoptimized or not? Regards, JL >=20 > Perhaps we can add such a capability in a later phase, after=20 > we get some experience to verify that it is really needed. >=20 > Thanks, > Jerry >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jan 12 22:40:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExFnf-0004oK-I7; Thu, 12 Jan 2006 22:40:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExFnc-0004jf-9l for pce@megatron.ietf.org; Thu, 12 Jan 2006 22:40:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25593 for ; Thu, 12 Jan 2006 22:39:02 -0500 (EST) Received: from usaga01-in.huawei.com ([12.129.211.51] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExFuq-0000o8-6i for pce@ietf.org; Thu, 12 Jan 2006 22:47:53 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IT000IQZI1EM5@usaga01-in.huawei.com> for pce@ietf.org; Thu, 12 Jan 2006 19:36:50 -0800 (PST) Received: from huawei.com ([172.17.1.188]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IT000M4FI1CBW@usaga01-in.huawei.com> for pce@ietf.org; Thu, 12 Jan 2006 19:36:50 -0800 (PST) Received: from [172.24.1.3] (Forwarded-For: [10.161.114.61]) by szxmc01-in.huawei.com (mshttpd); Fri, 13 Jan 2006 11:40:01 +0800 Date: Fri, 13 Jan 2006 11:40:01 +0800 From: zhangrenhai 18605 Subject: Re: [Pce] Comment on draft-ietf-pce-pcecp-interarea-reqs-00.txt To: JP Vasseur Message-id: <11aac111b1bc.11b1bc11aac1@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7BIT Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, JP Sorry for seeing your reply so late. Thanks, see inline. ----- Original Message ----- From: JP Vasseur Date: Thursday, January 5, 2006 3:07 am Subject: Re: [Pce] Comment on draft-ietf-pce-pcecp-interarea-reqs-00.txt > Hi , > > On Dec 28, 2005, at 2:03 AM, Zhang Renhai wrote: > > > Hi, Jean-Louis > > > > I have some comment on the draft draft-ietf-pce-pcecp-interarea- > > > reqs-00.txt > > > > In section 7.11.1, In case of network failure, jittering will > be > > used to avoid > > simultaneous requests sent to one PCE. Could more consideration > be > > given here to > > the preemptment, becouse the jittering timeout is stochastic, > some > > lower request > > may be served before a higher request and the path may be > > calculated differently. > > which may increase the probability of a preemptment. > > > > The decision on the PCC request scheduling is out of the scope of > this ID. Note that the point that you mentioned also applies to > the > located-PCE case. I am not sure what scope this point belongs to. I just considered more about what has been mentioned in the draft. Is this consideration important anough to be added somewhere? > > > > > I have always been thinking a question: if a PCC will not > perform > > the CSPF > > computation, why does it still maintain the TEDB any longer? > which > > may consume > > a lot of memory and CPU of a LSR.This question dost not aid at > this > > draft. > > > > Because > (1) The PCE may decide to use a remote PCE for some LSPs and not > for > others (for instance, inter versus intra-domain) > (2) The PCE may decide to always use a PCE and fall back to local > path computation or loose hop routing under specific conditions Agree, I just want to be convinced if some routers acting as a pure PCC (no longer perform path computation)can save some CPU and memory so there could be a lower requirement on capability to these routers in PCE-based environment.Maybe this is a benefit to PCE Architecture. > > > In inter-area environment,sometimes, a PCC may wish to get as > many > > paths as possible, > > for all kinds of purpose,so could the PCC send the request to > more > > than one PCEs? > > > > Yes, although this would clearly be very sub-optimal .... I am not sure your point, could you please expand your explanation any more? In my opinion, a ABR acting as a PCE usually can not have a full AS-scope information of TED. so it may return a sub-optimal compuation result compared to some latent path which can be returned by other ABR linked to a different area. I know this can be solved by a ABR through sending the request to multiple ABR in a area, otherwise, how to solve this problem? Thanks, Zhang > > JP. > > > Regards, > > Zhang > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jan 13 04:22:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExL8T-000165-GY; Fri, 13 Jan 2006 04:22:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExL8R-00014w-2s for pce@megatron.ietf.org; Fri, 13 Jan 2006 04:22:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15284 for ; Fri, 13 Jan 2006 04:20:52 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExLFg-0002Li-EG for pce@ietf.org; Fri, 13 Jan 2006 04:29:47 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 Jan 2006 10:22:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 13 Jan 2006 10:22:02 +0100 Message-ID: Thread-Topic: Comment on draft-ietf-pce-pcecp-interarea-reqs-00.txt thread-index: AcYLgsQkN8ow3MnoSNWJT/9vaJdZ1QMmJJMQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Zhang Renhai" X-OriginalArrivalTime: 13 Jan 2006 09:22:03.0080 (UTC) FILETIME=[D063E480:01C61822] X-Spam-Score: 0.6 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: pce@ietf.org Subject: [Pce] RE: Comment on draft-ietf-pce-pcecp-interarea-reqs-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1249155614==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1249155614== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61822.D0465EED" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61822.D0465EED Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Zhang =20 sorry for replying so late... =20 Please see inline, ________________________________ De : Zhang Renhai [mailto:zhangrenhai@huawei.com]=20 Envoy=E9 : mercredi 28 d=E9cembre 2005 08:04 =C0 : LE ROUX Jean-Louis RD-CORE-LAN Cc : pce@ietf.org Objet : Comment on draft-ietf-pce-pcecp-interarea-reqs-00.txt =09 =09 Hi, Jean-Louis =20 I have some comment on the draft = draft-ietf-pce-pcecp-interarea-reqs-00.txt =20 In section 7.11.1, In case of network failure, jittering will be used = to avoid simultaneous requests sent to one PCE. Could more consideration be = given here to the preemptment, becouse the jittering timeout is stochastic, some = lower request may be served before a higher request and the path may be calculated = differently. which may increase the probability of a preemptment.=20 =20 JLLR: You raised a good point. First of all note that this point is not a protocol requirement, this = is a local implementation issue, and the jittering was just given as an = example... The PCC could apply different jitter to low priority and high priority = requests, and could send high priority request before low priority one, this is a local PCC = decision. Also the request prioritization function could be used so that the PCE = serves high priority requests first. The way a PCE is going to handle = request prioritites is also a local implementation issue. Maybe we should remove this sentence to avoid any confusion.=20 By the way note that this section is generic and has just been moved to = the generic requirement draft. So we will have to clarify in the generic draft.=20 =20 =20 I have always been thinking a question: if a PCC will not perform the = CSPF=20 computation, why does it still maintain the TEDB any longer? which may = consume=20 a lot of memory and CPU of a LSR.This question dost not aid at this = draft.=20 =20 [JLLR] A LSR may be a PCC for some LSPs and a PCE for other LSPs.=20 Anyway a LSR that runs ISIS or OSPF for IP routing has to maintain a = LSDB. I agree removing TE info would save some memory and CPU but the = gain sounds quite low compared to the impact: For any computation, even = a simple intra-area CSPF, you would have to ask a PCE, and this may lead = to a high PCE stress. You would have a small CPU gain on LSRs at a cost = of a huge CPU consumption on PCEs... =20 In inter-area environment,sometimes, a PCC may wish to get as many = paths as possible, for all kinds of purpose,so could the PCC send the request to more than = one PCEs? =20 =20 [JLLR] Yes, and this is a procedure local to the PCC, that does not = imply specific PCECP procedure. =20 Thanks for these valuable comments =20 Regards, =20 JL =20 =20 Regards, Zhang=20 ------_=_NextPart_001_01C61822.D0465EED Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Zhang
 
sorry for replying so = late...
 
Please see inline,

De : Zhang Renhai=20 [mailto:zhangrenhai@huawei.com]
Envoy=E9 : mercredi 28 = d=E9cembre=20 2005 08:04
=C0 : LE ROUX Jean-Louis=20 RD-CORE-LAN
Cc : pce@ietf.org
Objet : = Comment on=20 draft-ietf-pce-pcecp-interarea-reqs-00.txt

Hi, Jean-Louis
 
 I have some comment on the draft=20 draft-ietf-pce-pcecp-interarea-reqs-00.txt
 
 In section 7.11.1, In case of network = failure,=20 jittering will be used to avoid
simultaneous requests sent to one PCE. Could = more=20 consideration be given here to
the preemptment, becouse the jittering timeout is=20 stochastic, some lower request
may be served before a higher request and the path = may be=20 calculated differently.
which may increase the probability of a=20 preemptment. 
 
JLLR: You raised = a good=20 point.
First of all note = that this=20 point is not a protocol requirement, this is a local implementation = issue, and=20 the jittering was just given as an example...
The PCC could = apply different=20 jitter to low priority and high priority requests, and could=20 send
high priority = request before=20 low priority one, this is a local PCC decision.
Also the request=20 prioritization function could be used so that the PCE serves high = priority=20 requests first. The way a PCE is going to handle request prioritites = is also a=20 local implementation issue.
Maybe we should = remove this=20 sentence to avoid any confusion.
By the way note = that this=20 section is generic and has just been moved to the generic requirement=20 draft.
So we will have = to clarify in=20 the generic draft. 
 
 
 I have always been thinking a question: if a = PCC will=20 not perform the CSPF 
computation, why does it still maintain the TEDB = any longer?=20 which may consume
a lot of memory and CPU of a LSR.This question = dost not=20 aid at this draft. 
 
[JLLR] A LSR may be a=20 PCC for some LSPs and a PCE for other=20 LSPs. 
Anyway a LSR that runs ISIS or=20 OSPF for IP routing has to maintain a LSDB. I = agree removing TE=20 info would save some memory and CPU but the gain sounds=20 quite low compared to the impact: For any computation, even a = simple=20 intra-area CSPF, you would have to ask a PCE, and this = may lead=20 to a high PCE stress. You would have a small CPU gain on LSRs at = a cost=20 of a huge CPU consumption on PCEs...
 
In inter-area environment,sometimes, a PCC may = wish to get=20 as many paths as possible,
for all kinds of purpose,so could the PCC send the = request=20 to more than one PCEs?  
 
[JLLR] Yes, and this is a procedure = local to the=20 PCC, that does not imply specific = PCECP procedure.
 
Thanks for these valuable=20 comments
 
Regards,
 
JL
 
 
Regards,
Zhang
------_=_NextPart_001_01C61822.D0465EED-- --===============1249155614== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1249155614==-- From pce-bounces@lists.ietf.org Fri Jan 13 08:13:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExOiU-00084k-Gr; Fri, 13 Jan 2006 08:11:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExOiS-000845-Qg for pce@megatron.ietf.org; Fri, 13 Jan 2006 08:11:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04340 for ; Fri, 13 Jan 2006 08:10:19 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExOpj-0002c8-32 for pce@ietf.org; Fri, 13 Jan 2006 08:19:14 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 13 Jan 2006 05:11:28 -0800 X-IronPort-AV: i="3.99,365,1131350400"; d="scan'208,217"; a="391416368:sNHT52795504" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0DDBRWF020340; Fri, 13 Jan 2006 05:11:27 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 Jan 2006 08:11:27 -0500 Received: from [192.168.1.101] ([10.86.240.196]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 Jan 2006 08:11:26 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Message-Id: From: JP Vasseur Subject: Re: [Pce] RE: Comment on draft-ietf-pce-pcecp-interarea-reqs-00.txt Date: Fri, 13 Jan 2006 08:10:51 -0500 To: LE ROUX Jean-Louis RD-CORE-LAN , Zhang Renhai X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 13 Jan 2006 13:11:26.0422 (UTC) FILETIME=[DBFB3760:01C61842] X-Spam-Score: 0.6 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0456990763==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============0456990763== Content-Type: multipart/alternative; boundary=Apple-Mail-221--63138567 --Apple-Mail-221--63138567 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable Hi, On Jan 13, 2006, at 4:22 AM, LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi Zhang > > sorry for replying so late... > > Please see inline, > > De : Zhang Renhai [mailto:zhangrenhai@huawei.com] > Envoy=E9 : mercredi 28 d=E9cembre 2005 08:04 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > Cc : pce@ietf.org > Objet : Comment on draft-ietf-pce-pcecp-interarea-reqs-00.txt > > Hi, Jean-Louis > > I have some comment on the draft draft-ietf-pce-pcecp-interarea-=20 > reqs-00.txt > > In section 7.11.1, In case of network failure, jittering will be =20 > used to avoid > simultaneous requests sent to one PCE. Could more consideration be =20 > given here to > the preemptment, becouse the jittering timeout is stochastic, some =20 > lower request > may be served before a higher request and the path may be =20 > calculated differently. > which may increase the probability of a preemptment. > > JLLR: You raised a good point. > First of all note that this point is not a protocol requirement, =20 > this is a local implementation issue, and the jittering was just =20 > given as an example... > The PCC could apply different jitter to low priority and high =20 > priority requests, and could send > high priority request before low priority one, this is a local PCC =20 > decision. > Also the request prioritization function could be used so that the =20 > PCE serves high priority requests first. The way a PCE is going to =20 > handle request prioritites is also a local implementation issue. > Maybe we should remove this sentence to avoid any confusion. > By the way note that this section is generic and has just been =20 > moved to the generic requirement draft. > So we will have to clarify in the generic draft. Thanks indeed to remove this section since this is out of scope. JP. > > > I have always been thinking a question: if a PCC will not perform =20 > the CSPF > computation, why does it still maintain the TEDB any longer? which =20 > may consume > a lot of memory and CPU of a LSR.This question dost not aid at this =20= > draft. > > [JLLR] A LSR may be a PCC for some LSPs and a PCE for other LSPs. > Anyway a LSR that runs ISIS or OSPF for IP routing has to maintain =20 > a LSDB. I agree removing TE info would save some memory and CPU but =20= > the gain sounds quite low compared to the impact: For any =20 > computation, even a simple intra-area CSPF, you would have to ask a =20= > PCE, and this may lead to a high PCE stress. You would have a small =20= > CPU gain on LSRs at a cost of a huge CPU consumption on PCEs... > > In inter-area environment,sometimes, a PCC may wish to get as many =20 > paths as possible, > for all kinds of purpose,so could the PCC send the request to more =20 > than one PCEs? > > [JLLR] Yes, and this is a procedure local to the PCC, that does not =20= > imply specific PCECP procedure. > > Thanks for these valuable comments > > Regards, > > JL > > > Regards, > Zhang > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-221--63138567 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

On Jan 13, = 2006, at 4:22 AM, LE ROUX Jean-Louis RD-CORE-LAN wrote:

Hi Zhang
=
=A0
sorry for replying so = late...
=A0
Please see inline,

=
De=A0: = Zhang Renhai [mailto:zhangrenhai@huawei.com] =
Envoy=E9=A0: mercredi 28 d=E9cembre 2005 = 08:04
=C0=A0: LE ROUX Jean-Louis RD-CORE-LAN
Cc=A0: = pce@ietf.org
Objet=A0: = Comment on = draft-ietf-pce-pcecp-interarea-reqs-00.txt

=
Hi, Jean-Louis
=
=A0
=A0I have = some comment on the draft = draft-ietf-pce-pcecp-interarea-reqs-00.txt
=A0
=A0In section 7.11.1, = In case of network failure, jittering will be used to = avoid
simultaneous requests sent to = one PCE.=A0Could more consideration be given here to
=
the preemptment, becouse the jittering timeout is = stochastic, some lower request
may = be served before a higher request and the path may be calculated = differently.
which may increase the = probability=A0of a preemptment.=A0
=
=A0
JLLR: You raised a good = point.
First of all note that this point is not = a protocol requirement, this is a local implementation issue, and the = jittering was just given as an example...
=
The PCC could = apply different jitter to low priority and high priority requests, and = could send
high priority request before low priority = one, this is a local PCC decision.
Also the request = prioritization function could be used so that the PCE serves high = priority requests first. The way a PCE is going to handle request = prioritites is also a local implementation issue.
=
Maybe we should = remove this sentence to avoid any confusion.
=
By the way note = that this section is generic and has just been moved to the generic = requirement draft.
So we will have to clarify in the generic = draft.=A0
Thanks indeed to = remove this section since this is out of scope.

JP.
=
=A0
=A0
=A0I have always been = thinking a question: if a PCC will not perform the CSPF=A0
=
computation, why does it still maintain the TEDB = any longer? which may consume
a = lot of memory and CPU of a LSR.This question dost not aid=A0at this = draft.=A0
=A0
=
[JLLR]=A0A=A0LSR may be a PCC=A0for some LSPs and a = PCE=A0for=A0other LSPs.=A0
Anyway a LSR=A0that runs=A0ISIS or = OSPF=A0for IP routing=A0has to maintain a LSDB. I agree=A0removing TE = info would save some memory and CPU=A0but the gain=A0sounds quite=A0low = compared to the impact: For any computation, even a simple intra-area = CSPF, you would have to ask=A0a PCE,=A0and this may=A0lead to a high = PCE stress. You would have a small CPU gain=A0on LSRs at a cost of a = huge CPU consumption on PCEs...
=A0
In= inter-area environment,sometimes, a PCC may wish to get as many paths = as possible,
for all kinds of = purpose,so could the PCC send the request to more than one PCEs?=A0=A0
=A0
=
[JLLR] Yes, and=A0this is a procedure local = to the PCC, that does not imply specific = PCECP=A0procedure.
=A0
Thanks for these valuable = comments
=A0
=
Regards,
=A0
JL
=A0
=
=A0
Regards,
Zhang =
Pce mailing list
=

= --Apple-Mail-221--63138567-- --===============0456990763== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0456990763==-- From pce-bounces@lists.ietf.org Fri Jan 13 08:37:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExP7Y-0007EP-S9; Fri, 13 Jan 2006 08:37:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExP7X-0007EK-Cl for pce@megatron.ietf.org; Fri, 13 Jan 2006 08:37:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05740 for ; Fri, 13 Jan 2006 08:36:13 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExPEq-0003QD-M6 for pce@ietf.org; Fri, 13 Jan 2006 08:45:09 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 13 Jan 2006 08:37:23 -0500 X-IronPort-AV: i="3.99,365,1131339600"; d="scan'208,217"; a="80190152:sNHT50773848" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0DDbJ6J009921; Fri, 13 Jan 2006 08:37:21 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 Jan 2006 08:37:00 -0500 Received: from [192.168.1.101] ([10.86.240.196]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 Jan 2006 08:37:16 -0500 Mime-Version: 1.0 (Apple Message framework v746.2) To: pce@ietf.org, Adrian Farrel Message-Id: <86903041-45B8-4054-8863-D21F2E3DFBCF@cisco.com> From: JP Vasseur Date: Fri, 13 Jan 2006 08:36:41 -0500 X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 13 Jan 2006 13:37:16.0563 (UTC) FILETIME=[77EFF630:01C61846] X-Spam-Score: 0.4 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Cc: Subject: [Pce] Recollection on the PCE Architecture ID last call discussion X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1492889572==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============1492889572== Content-Type: multipart/alternative; boundary=Apple-Mail-224--61588203 --Apple-Mail-224--61588203 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi, Thanks for all of you who participated in the resolution of the items discussed during the last WG Last Call. We've now reached a consensus. Below is my recollection on the proposed changes to draft-ietf-pce- architecture triggered by the discussions during WG Last Call. 1) Title change: Four proposals: a) A PCE-Based Network Architecture b) Architecture for Path Computation Using a Path Computation Element (PCE) c) A PCE-based architecture model d) A PCE-based path computation model I'd vote for d) (IMO the most accurate) Objection ? 2) > > - Section 4.9.2: "Back-off times, alternate path computations, > and crankback > > can help to mitigate this sort of problem, and PCE may also > improve the > > chances of successful TE LSP setup." Suggest "computation of > alternate > > paths" to avoid ambiguity. > > Yes. 3) > > - Section 5.4: "Multiple PCE path computation with inter-PCE > communication > > involves coordination between distributed PCEs such that the > result of the > > computation performed by one PCE depends on information supplied > by other > > PCEs. This model does not provide a distributed computation > algorithm, but > > allows distinct PCEs to be responsible for computation of parts > (segments) > > of the path." > > 1- I believe you mean different or distinct PCEs instead of > distributed PCEs. > > Yes. 4) > > - Section 6.3: Suggest "better" or "closer to optimal" instead of > "more > > optimal". > > Agreed. 5) > Recall, we are in section 5.4 (Multiple PCE Path Computation with > Inter-PCE Communication). > > You imply that the model described assumes that "PCEs have > information on > other domains (aggregate or detailed) availabel a priori or upon > request." > This is not the case. I think you are confused by the text... > Multiple PCE path computation with inter-PCE communication involves > coordination between distinct PCEs such that the result of the > computation performed by one PCE depends on information supplied by > other PCEs. > You assume that the "information supplied" is TE information. But it > doesn't say that. Perhaps we should clarify what this information > is since > it is less than clear. > We will update this to indicate that the information is "path fragment > information". 6) >> Therefore, the starting >> paragraph in Section 6.3 also needs to be modified, as multiple PCC > requests >> does not necessarily mean non-synchronized path computation (unless >> explicitly requested, which we'll address in the next bullet). > > OK. I can change "will" to "may" to read... > In this case of non-synchronized path computation, the PCE may make > multiple individual path computations to generate the paths and the 7) Specification of the algorithm to use by the PCE not required: quantitative/qualitative constraints must be specified in the request, algo to use may be valuable. 8) Few other minor editorial changes. Adrian, could you please post the new revision incorporating these changes and we'll move forward and send to AD. Thanks. JP. --Apple-Mail-224--61588203 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Thanks for all of you who = participated in the resolution of the items discussed during the last WG = Last Call.=A0

We've now reached a = consensus.=A0

Below=A0is my recollection = on the proposed changes to draft-ietf-pce-architecture triggered by the = discussions during WG Last Call.=A0

1) Title = change:

Four = proposals:
a)=A0A PCE-Based Network Architecture
b) Architecture for Path Computation Using=A0a Path = Computation Element (PCE)
c) A = PCE-based architecture model
d) A PCE-based path computation = model

I'd = vote for d) (IMO the most accurate)

Objection ?

2)=A0
> - Section 4.9.2: "Back-off times, alternate path = computations, and crankback
> can help = to mitigate this sort of problem, and PCE may also improve the
> chances of successful TE LSP setup." Suggest "computation = of alternate
> paths" to avoid = ambiguity.
=A0
Yes.

3)=A0
> - Section 5.4: "Multiple PCE path computation with = inter-PCE communication
> involves = coordination between distributed PCEs such that the result of the
> computation performed by one PCE depends on information = supplied by other
> PCEs. This = model does not provide a distributed computation algorithm, but
> allows distinct PCEs to be responsible for computation of = parts (segments)
> of the = path."
> 1- I believe you mean different or distinct PCEs instead = of distributed PCEs.
=A0
Yes.

4)
> - Section 6.3: Suggest "better" or "closer to optimal" = instead of "more
> = optimal".
=A0
Agreed.

5)
Recall, we are in section 5.4 = (Multiple PCE Path Computation with
Inter-PCE = Communication).

You imply that the model = described assumes that "PCEs have information on
other domains (aggregate or detailed) availabel a = priori or upon request."
This is not = the case. I think you are confused by the text...
=A0=A0 Multiple PCE path computation with inter-PCE = communication involves
=A0=A0 coordination between = distinct PCEs such that the result of the
=A0=A0 = computation performed by one PCE depends on information supplied = by
=A0=A0 other PCEs.
You = assume that the "information supplied" is TE information. But = it
doesn't say that. Perhaps we should clarify = what this information is since
it is less = than clear.
We will update this to indicate = that the information is "path fragment

6)
Therefore, = the starting
paragraph in Section 6.3 also = needs to be modified, as multiple PCC
requests
does not necessarily mean non-synchronized path = computation (unless
explicitly requested, which = we'll address in the next bullet).

OK. I can change "will" to "may" to = read...
=A0=A0 In this case of = non-synchronized path computation, the PCE may make
=A0=A0 multiple individual path computations to = generate the paths and the

7) = Specification of the algorithm to use by the PCE not required: = quantitative/qualitative=A0constraints must be specified in the request, = algo to use may be valuable.

8) Few other minor = editorial changes.

Adrian, could you please = post the new revision incorporating these changes and we'll move forward = and send to AD.

Thanks.

JP.
= --Apple-Mail-224--61588203-- --===============1492889572== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1492889572==-- From pce-bounces@lists.ietf.org Fri Jan 13 08:53:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExPMv-0003UV-5a; Fri, 13 Jan 2006 08:53:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExPMt-0003Ty-8O for pce@megatron.ietf.org; Fri, 13 Jan 2006 08:53:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06624 for ; Fri, 13 Jan 2006 08:52:05 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExPUA-0003yS-48 for pce@ietf.org; Fri, 13 Jan 2006 09:01:01 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 13 Jan 2006 05:53:14 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0DDrCk3025491; Fri, 13 Jan 2006 05:53:14 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 Jan 2006 08:53:13 -0500 Received: from [192.168.1.101] ([10.86.240.196]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 Jan 2006 08:53:13 -0500 In-Reply-To: <11aac111b1bc.11b1bc11aac1@huawei.com> References: <11aac111b1bc.11b1bc11aac1@huawei.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Comment on draft-ietf-pce-pcecp-interarea-reqs-00.txt Date: Fri, 13 Jan 2006 08:52:38 -0500 To: zhangrenhai 18605 X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 13 Jan 2006 13:53:13.0141 (UTC) FILETIME=[B21A2E50:01C61848] X-Spam-Score: 2.2 (++) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: 7bit Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, On Jan 12, 2006, at 10:40 PM, zhangrenhai 18605 wrote: > Hi, JP > > Sorry for seeing your reply so late. > Thanks, see inline. > > ----- Original Message ----- > From: JP Vasseur > Date: Thursday, January 5, 2006 3:07 am > Subject: Re: [Pce] Comment on draft-ietf-pce-pcecp-interarea- > reqs-00.txt > >> Hi , >> >> On Dec 28, 2005, at 2:03 AM, Zhang Renhai wrote: >> >>> Hi, Jean-Louis >>> >>> I have some comment on the draft draft-ietf-pce-pcecp-interarea- >> >>> reqs-00.txt >>> >>> In section 7.11.1, In case of network failure, jittering will >> be >>> used to avoid >>> simultaneous requests sent to one PCE. Could more consideration >> be >>> given here to >>> the preemptment, becouse the jittering timeout is stochastic, >> some >>> lower request >>> may be served before a higher request and the path may be >>> calculated differently. >>> which may increase the probability of a preemptment. >>> >> >> The decision on the PCC request scheduling is out of the scope of >> this ID. Note that the point that you mentioned also applies to >> the >> located-PCE case. > I am not sure what scope this point belongs to. I just considered > more about what > has been mentioned in the draft. > Is this consideration important anough to be added somewhere? You're very welcome to discuss the topic on the list but PCC request request scheduling are not standardized. >> >>> >>> I have always been thinking a question: if a PCC will not >> perform >>> the CSPF >>> computation, why does it still maintain the TEDB any longer? >> which >>> may consume >>> a lot of memory and CPU of a LSR.This question dost not aid at >> this >>> draft. >>> >> >> Because >> (1) The PCE may decide to use a remote PCE for some LSPs and not >> for >> others (for instance, inter versus intra-domain) >> (2) The PCE may decide to always use a PCE and fall back to local >> path computation or loose hop routing under specific conditions > Agree, I just want to be convinced if some routers acting as a pure > PCC > (no longer perform path computation)can save some CPU and memory so > there could be a lower requirement on capability to these routers > in PCE-based environment.Maybe this is a benefit to PCE Architecture. Sure, this is an option already described in the draft. >> >>> In inter-area environment,sometimes, a PCC may wish to get as >> many >>> paths as possible, >>> for all kinds of purpose,so could the PCC send the request to >> more >>> than one PCEs? >>> >> >> Yes, although this would clearly be very sub-optimal .... > I am not sure your point, could you please expand your explanation > any more? > In my opinion, a ABR acting as a PCE usually can not have a full AS- > scope information of TED. > so it may return a sub-optimal compuation result compared to some > latent path which can be returned by other ABR linked to a different > area. I know this can be solved by a ABR through sending the > request to multiple > ABR in a area, otherwise, how to solve this problem? Yes stay tuned ... I'll resurrect soon a draft that used to be discussed in CCAMP detailing these aspects. Thanks. JP. > > > Thanks, > Zhang > >> >> JP. >> >>> Regards, >>> Zhang >>> _______________________________________________ >>> Pce mailing list >>> Pce@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/pce >> >> _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jan 16 04:20:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyQWz-0007ic-Qf; Mon, 16 Jan 2006 04:20:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyQWy-0007iB-6K for pce@megatron.ietf.org; Mon, 16 Jan 2006 04:20:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26597 for ; Mon, 16 Jan 2006 04:18:40 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyQeq-00010H-4s for pce@ietf.org; Mon, 16 Jan 2006 04:28:14 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IT600E7KIFZ8R@szxga02-in.huawei.com> for pce@ietf.org; Mon, 16 Jan 2006 17:31:11 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IT600ETBIFYP4@szxga02-in.huawei.com> for pce@ietf.org; Mon, 16 Jan 2006 17:31:11 +0800 (CST) Received: from z18605 ([10.111.12.87]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IT600KNTILLM9@szxml01-in.huawei.com>; Mon, 16 Jan 2006 17:34:33 +0800 (CST) Date: Mon, 16 Jan 2006 16:53:05 +0800 From: Zhang Renhai To: LE ROUX Jean-Louis RD-CORE-LAN Message-id: <005f01c61a7a$441384e0$570c6f0a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 3.3 (+++) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: pce@ietf.org Subject: [Pce] Re: Comment on draft-ietf-pce-pcecp-interarea-reqs-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0517005409==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0517005409== Content-type: multipart/alternative; boundary="Boundary_(ID_84wyYID0R8tSBv+UQGpivw)" This is a multi-part message in MIME format. --Boundary_(ID_84wyYID0R8tSBv+UQGpivw) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 SGksIEplYW4tTG91aXMNCg0KIFRoYW5rcyBmb3IgeW91ciByZXBseSwgc2VlIGlubGluZS4NCiAg LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCiAgRnJvbTogTEUgUk9VWCBKZWFuLUxvdWlz IFJELUNPUkUtTEFOIA0KICBUbzogWmhhbmcgUmVuaGFpIA0KICBDYzogcGNlQGlldGYub3JnIA0K ICBTZW50OiBGcmlkYXksIEphbnVhcnkgMTMsIDIwMDYgNToyMiBQTQ0KICBTdWJqZWN0OiBSRTog Q29tbWVudCBvbiBkcmFmdC1pZXRmLXBjZS1wY2VjcC1pbnRlcmFyZWEtcmVxcy0wMC50eHQNCg0K DQogIEhpIFpoYW5nDQoNCiAgc29ycnkgZm9yIHJlcGx5aW5nIHNvIGxhdGUuLi4NCg0KICBQbGVh c2Ugc2VlIGlubGluZSwNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICBEZSA6IFpoYW5n IFJlbmhhaSBbbWFpbHRvOnpoYW5ncmVuaGFpQGh1YXdlaS5jb21dIA0KICAgIEVudm956SA6IG1l cmNyZWRpIDI4IGTpY2VtYnJlIDIwMDUgMDg6MDQNCiAgICDAIDogTEUgUk9VWCBKZWFuLUxvdWlz IFJELUNPUkUtTEFODQogICAgQ2MgOiBwY2VAaWV0Zi5vcmcNCiAgICBPYmpldCA6IENvbW1lbnQg b24gZHJhZnQtaWV0Zi1wY2UtcGNlY3AtaW50ZXJhcmVhLXJlcXMtMDAudHh0DQoNCg0KICAgIEhp LCBKZWFuLUxvdWlzDQoNCiAgICAgSSBoYXZlIHNvbWUgY29tbWVudCBvbiB0aGUgZHJhZnQgZHJh ZnQtaWV0Zi1wY2UtcGNlY3AtaW50ZXJhcmVhLXJlcXMtMDAudHh0DQoNCiAgICAgSW4gc2VjdGlv biA3LjExLjEsIEluIGNhc2Ugb2YgbmV0d29yayBmYWlsdXJlLCBqaXR0ZXJpbmcgd2lsbCBiZSB1 c2VkIHRvIGF2b2lkDQogICAgc2ltdWx0YW5lb3VzIHJlcXVlc3RzIHNlbnQgdG8gb25lIFBDRS4g Q291bGQgbW9yZSBjb25zaWRlcmF0aW9uIGJlIGdpdmVuIGhlcmUgdG8NCiAgICB0aGUgcHJlZW1w dG1lbnQsIGJlY291c2UgdGhlIGppdHRlcmluZyB0aW1lb3V0IGlzIHN0b2NoYXN0aWMsIHNvbWUg bG93ZXIgcmVxdWVzdA0KICAgIG1heSBiZSBzZXJ2ZWQgYmVmb3JlIGEgaGlnaGVyIHJlcXVlc3Qg YW5kIHRoZSBwYXRoIG1heSBiZSBjYWxjdWxhdGVkIGRpZmZlcmVudGx5Lg0KICAgIHdoaWNoIG1h eSBpbmNyZWFzZSB0aGUgcHJvYmFiaWxpdHkgb2YgYSBwcmVlbXB0bWVudC4gDQoNCiAgICBKTExS OiBZb3UgcmFpc2VkIGEgZ29vZCBwb2ludC4NCiAgICBGaXJzdCBvZiBhbGwgbm90ZSB0aGF0IHRo aXMgcG9pbnQgaXMgbm90IGEgcHJvdG9jb2wgcmVxdWlyZW1lbnQsIHRoaXMgaXMgYSBsb2NhbCBp bXBsZW1lbnRhdGlvbiBpc3N1ZSwgYW5kIHRoZSBqaXR0ZXJpbmcgd2FzIGp1c3QgZ2l2ZW4gYXMg YW4gZXhhbXBsZS4uLg0KICAgIFRoZSBQQ0MgY291bGQgYXBwbHkgZGlmZmVyZW50IGppdHRlciB0 byBsb3cgcHJpb3JpdHkgYW5kIGhpZ2ggcHJpb3JpdHkgcmVxdWVzdHMsIGFuZCBjb3VsZCBzZW5k DQogICAgaGlnaCBwcmlvcml0eSByZXF1ZXN0IGJlZm9yZSBsb3cgcHJpb3JpdHkgb25lLCB0aGlz IGlzIGEgbG9jYWwgUENDIGRlY2lzaW9uLg0KICAgIEFsc28gdGhlIHJlcXVlc3QgcHJpb3JpdGl6 YXRpb24gZnVuY3Rpb24gY291bGQgYmUgdXNlZCBzbyB0aGF0IHRoZSBQQ0Ugc2VydmVzIGhpZ2gg cHJpb3JpdHkgcmVxdWVzdHMgZmlyc3QuIFRoZSB3YXkgYSBQQ0UgaXMgZ29pbmcgdG8gaGFuZGxl IHJlcXVlc3QgcHJpb3JpdGl0ZXMgaXMgYWxzbyBhIGxvY2FsIGltcGxlbWVudGF0aW9uIGlzc3Vl Lg0KICAgIE1heWJlIHdlIHNob3VsZCByZW1vdmUgdGhpcyBzZW50ZW5jZSB0byBhdm9pZCBhbnkg Y29uZnVzaW9uLiANCiAgICBCeSB0aGUgd2F5IG5vdGUgdGhhdCB0aGlzIHNlY3Rpb24gaXMgZ2Vu ZXJpYyBhbmQgaGFzIGp1c3QgYmVlbiBtb3ZlZCB0byB0aGUgZ2VuZXJpYyByZXF1aXJlbWVudCBk cmFmdC4NCiAgICBTbyB3ZSB3aWxsIGhhdmUgdG8gY2xhcmlmeSBpbiB0aGUgZ2VuZXJpYyBkcmFm dC4gDQogICAgW1pSSF0gSSBhZ3JlZS4NCg0KICAgICBJIGhhdmUgYWx3YXlzIGJlZW4gdGhpbmtp bmcgYSBxdWVzdGlvbjogaWYgYSBQQ0Mgd2lsbCBub3QgcGVyZm9ybSB0aGUgQ1NQRiANCiAgICBj b21wdXRhdGlvbiwgd2h5IGRvZXMgaXQgc3RpbGwgbWFpbnRhaW4gdGhlIFRFREIgYW55IGxvbmdl cj8gd2hpY2ggbWF5IGNvbnN1bWUgDQogICAgYSBsb3Qgb2YgbWVtb3J5IGFuZCBDUFUgb2YgYSBM U1IuVGhpcyBxdWVzdGlvbiBkb3N0IG5vdCBhaWQgYXQgdGhpcyBkcmFmdC4gDQoNCiAgICBbSkxM Ul0gQSBMU1IgbWF5IGJlIGEgUENDIGZvciBzb21lIExTUHMgYW5kIGEgUENFIGZvciBvdGhlciBM U1BzLiANCiAgICBBbnl3YXkgYSBMU1IgdGhhdCBydW5zIElTSVMgb3IgT1NQRiBmb3IgSVAgcm91 dGluZyBoYXMgdG8gbWFpbnRhaW4gYSBMU0RCLiBJIGFncmVlIHJlbW92aW5nIFRFIGluZm8gd291 bGQgc2F2ZSBzb21lIG1lbW9yeSBhbmQgQ1BVIGJ1dCB0aGUgZ2FpbiBzb3VuZHMgcXVpdGUgbG93 IGNvbXBhcmVkIHRvIHRoZSBpbXBhY3Q6IEZvciBhbnkgY29tcHV0YXRpb24sIGV2ZW4gYSBzaW1w bGUgaW50cmEtYXJlYSBDU1BGLCB5b3Ugd291bGQgaGF2ZSB0byBhc2sgYSBQQ0UsIGFuZCB0aGlz IG1heSBsZWFkIHRvIGEgaGlnaCBQQ0Ugc3RyZXNzLiBZb3Ugd291bGQgaGF2ZSBhIHNtYWxsIENQ VSBnYWluIG9uIExTUnMgYXQgYSBjb3N0IG9mIGEgaHVnZSBDUFUgY29uc3VtcHRpb24gb24gUENF cy4uLg0KICAgIFtaUkhdeWVzLCB5b3VyIGV4cGFuYXRpb24gaXMgZ3JlYXQsIEkgdGhpbmsgeW91 IGFyZSByaWdodC4NCg0KICAgIEluIGludGVyLWFyZWEgZW52aXJvbm1lbnQsc29tZXRpbWVzLCBh IFBDQyBtYXkgd2lzaCB0byBnZXQgYXMgbWFueSBwYXRocyBhcyBwb3NzaWJsZSwNCiAgICBmb3Ig YWxsIGtpbmRzIG9mIHB1cnBvc2Usc28gY291bGQgdGhlIFBDQyBzZW5kIHRoZSByZXF1ZXN0IHRv IG1vcmUgdGhhbiBvbmUgUENFcz8gIA0KDQogICAgW0pMTFJdIFllcywgYW5kIHRoaXMgaXMgYSBw cm9jZWR1cmUgbG9jYWwgdG8gdGhlIFBDQywgdGhhdCBkb2VzIG5vdCBpbXBseSBzcGVjaWZpYyBQ Q0VDUCBwcm9jZWR1cmUuDQogICAgW1pSSF0gSSBub3RpY2VkIHRoYXQgaW4gdGhlIGRyYWZ0IGRy YWZ0LWlldGYtcGNlLWFyY2hpdGVjdHVyZS0wMywgdGhlcmUgYXJlIGFscmVhZHkgcmVzdHJpY3Rp b24gZm9yIGEgUENDIHRvIHNlbnQgbXVsdGlwbGUNCiAgICByZXF1ZXN0cyBmb3IgYSBMU1AuIFNv IEkgd291bGQgbGlrdCB0byBhc2sgaWYgdGhlIHJlc3RyaWN0aW9uIGNhbiBiZSByZW1vdmUgYmVm b3JlIHdlIHJlYWNoIGEgYWdyZWVtZW50IA0KICAgIG9uIHRoaXMgcG9pbnQ/IA0KDQogICAgVGhh bmtzIGZvciB0aGVzZSB2YWx1YWJsZSBjb21tZW50cw0KDQogICAgUmVnYXJkcywNCg0KICAgIEpM DQoNCg0KICAgIFJlZ2FyZHMsDQogICAgWmhhbmcgDQo= --Boundary_(ID_84wyYID0R8tSBv+UQGpivw) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDUuNTAuNDgwNy4yMzAwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMw Nzsgc2l6ZT0yPkhpLCA8Rk9OVCANCmZhY2U9IlRpbWVzIE5ldyBSb21hbiI+SmVhbi1Mb3Vpczwv Rk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDtUaGFua3MgZm9yIHlvdXIgcmVwbHksIHM8L0ZPTlQ+ PEZPTlQgc2l6ZT0yPmVlIA0KaW5saW5lLjwvRk9OVD48L0RJVj4NCjxCTE9DS1FVT1RFIGRpcj1s dHIgDQpzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lO LUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6 IDBweCI+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij4tLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KICA8RElWIHN0eWxlPSJCQUNLR1JPVU5EOiAj ZTRlNGU0OyBGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OzsgZm9udC1jb2xvcjogYmxhY2siPjxC PkZyb206PC9CPiANCiAgPEEgdGl0bGU9amVhbmxvdWlzLmxlcm91eEBmcmFuY2V0ZWxlY29tLmNv bSANCiAgaHJlZj0ibWFpbHRvOmplYW5sb3Vpcy5sZXJvdXhAZnJhbmNldGVsZWNvbS5jb20iPkxF IFJPVVggSmVhbi1Mb3VpcyANCiAgUkQtQ09SRS1MQU48L0E+IDwvRElWPg0KICA8RElWIHN0eWxl PSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+VG86PC9CPiA8QSB0aXRsZT16aGFuZ3Jl bmhhaUBodWF3ZWkuY29tIA0KICBocmVmPSJtYWlsdG86emhhbmdyZW5oYWlAaHVhd2VpLmNvbSI+ WmhhbmcgUmVuaGFpPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7 JiMyMDMwNzsiPjxCPkNjOjwvQj4gPEEgdGl0bGU9cGNlQGlldGYub3JnIA0KICBocmVmPSJtYWls dG86cGNlQGlldGYub3JnIj5wY2VAaWV0Zi5vcmc8L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJG T05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U2VudDo8L0I+IEZyaWRheSwgSmFudWFyeSAx MywgMjAwNiA1OjIyIFBNPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYj MjAzMDc7Ij48Qj5TdWJqZWN0OjwvQj4gUkU6IENvbW1lbnQgb24gDQogIGRyYWZ0LWlldGYtcGNl LXBjZWNwLWludGVyYXJlYS1yZXFzLTAwLnR4dDwvRElWPg0KICA8RElWPjxCUj48L0RJVj4NCiAg PERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MDE3MzIyODA4LTEzMDEyMDA2PjxG T05UIGZhY2U9QXJpYWwgDQogIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPkhpIFpoYW5nPC9GT05UPjwv U1BBTj48L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MDE3MzIy ODA4LTEzMDEyMDA2PjxGT05UIGZhY2U9QXJpYWwgDQogIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwv Rk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFO IGNsYXNzPTAxNzMyMjgwOC0xMzAxMjAwNj48Rk9OVCBmYWNlPUFyaWFsIA0KICBjb2xvcj0jMDAw MGZmIHNpemU9Mj5zb3JyeSBmb3IgcmVwbHlpbmcgc28gbGF0ZS4uLjwvRk9OVD48L1NQQU4+PC9E SVY+DQogIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTAxNzMyMjgwOC0xMzAx MjAwNj48Rk9OVCBmYWNlPUFyaWFsIA0KICBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PC9T UEFOPiZuYnNwOzwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0w MTczMjI4MDgtMTMwMTIwMDY+PEZPTlQgZmFjZT1BcmlhbCANCiAgY29sb3I9IzAwMDBmZiBzaXpl PTI+UGxlYXNlIHNlZSBpbmxpbmUsPC9GT05UPjwvU1BBTj48L0RJVj48QlI+DQogIDxCTE9DS1FV T1RFIGRpcj1sdHIgDQogIHN0eWxlPSJQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVw eDsgQk9SREVSLUxFRlQ6ICMwMDAwZmYgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQog ICAgPERJViBjbGFzcz1PdXRsb29rTWVzc2FnZUhlYWRlciBsYW5nPWZyIGRpcj1sdHIgYWxpZ249 bGVmdD4NCiAgICA8SFIgdGFiSW5kZXg9LTE+DQogICAgPEZPTlQgZmFjZT1UYWhvbWEgc2l6ZT0y PjxCPkRlJm5ic3A7OjwvQj4gWmhhbmcgUmVuaGFpIA0KICAgIFttYWlsdG86emhhbmdyZW5oYWlA aHVhd2VpLmNvbV0gPEJSPjxCPkVudm956SZuYnNwOzo8L0I+IG1lcmNyZWRpIDI4IA0KICAgIGTp Y2VtYnJlIDIwMDUgMDg6MDQ8QlI+PEI+wCZuYnNwOzo8L0I+IExFIFJPVVggSmVhbi1Mb3VpcyAN CiAgICBSRC1DT1JFLUxBTjxCUj48Qj5DYyZuYnNwOzo8L0I+IDxBIA0KICAgIGhyZWY9Im1haWx0 bzpwY2VAaWV0Zi5vcmciPnBjZUBpZXRmLm9yZzwvQT48QlI+PEI+T2JqZXQmbmJzcDs6PC9CPiBD b21tZW50IA0KICAgIG9uIGRyYWZ0LWlldGYtcGNlLXBjZWNwLWludGVyYXJlYS1yZXFzLTAwLnR4 dDxCUj48L0ZPTlQ+PEJSPjwvRElWPg0KICAgIDxESVY+PC9ESVY+DQogICAgPERJVj48Rk9OVCBz aXplPTI+SGksIEplYW4tTG91aXM8L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48Rk9OVCBzaXplPTI+ PC9GT05UPiZuYnNwOzwvRElWPg0KICAgIDxESVY+PEZPTlQgc2l6ZT0yPiZuYnNwO0kgaGF2ZSBz b21lIGNvbW1lbnQgb24gdGhlIGRyYWZ0IA0KICAgIGRyYWZ0LWlldGYtcGNlLXBjZWNwLWludGVy YXJlYS1yZXFzLTAwLnR4dDwvRk9OVD48L0RJVj4NCiAgICA8RElWPjxGT05UIHNpemU9Mj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQogICAgPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7SW4gc2VjdGlvbiA3 LjExLjEsIEluIGNhc2Ugb2YgbmV0d29yayBmYWlsdXJlLCANCiAgICBqaXR0ZXJpbmcgd2lsbCBi ZSB1c2VkIHRvIGF2b2lkPC9GT05UPjwvRElWPg0KICAgIDxESVY+PEZPTlQgc2l6ZT0yPnNpbXVs dGFuZW91cyByZXF1ZXN0cyBzZW50IHRvIG9uZSBQQ0UuJm5ic3A7Q291bGQgbW9yZSANCiAgICBj b25zaWRlcmF0aW9uIGJlIGdpdmVuIGhlcmUgdG88L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48Rk9O VCBzaXplPTI+dGhlIHByZWVtcHRtZW50LCBiZWNvdXNlIHRoZSBqaXR0ZXJpbmcgdGltZW91dCBp cyANCiAgICBzdG9jaGFzdGljLCBzb21lIGxvd2VyIHJlcXVlc3Q8L0ZPTlQ+PC9ESVY+DQogICAg PERJVj48Rk9OVCBzaXplPTI+bWF5IGJlIHNlcnZlZCBiZWZvcmUgYSBoaWdoZXIgcmVxdWVzdCBh bmQgdGhlIHBhdGggbWF5IGJlIA0KICAgIGNhbGN1bGF0ZWQgZGlmZmVyZW50bHkuPC9GT05UPjwv RElWPg0KICAgIDxESVY+PEZPTlQgc2l6ZT0yPndoaWNoIG1heSBpbmNyZWFzZSB0aGUgcHJvYmFi aWxpdHkmbmJzcDtvZiBhIA0KICAgIHByZWVtcHRtZW50LjxTUEFOIGNsYXNzPTAxNzMyMjgwOC0x MzAxMjAwNj48Rk9OVCBmYWNlPUFyaWFsIA0KICAgIGNvbG9yPSMwMDAwZmY+Jm5ic3A7PC9GT05U PjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48Rk9OVCBzaXplPTI+PFNQQU4gY2xhc3M9 MDE3MzIyODA4LTEzMDEyMDA2PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogICAgPERJVj48 Rk9OVCBzaXplPTI+PFNQQU4gY2xhc3M9MDE3MzIyODA4LTEzMDEyMDA2PkpMTFI6IFlvdSByYWlz ZWQgYSBnb29kIA0KICAgIHBvaW50LjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48Rk9O VCBzaXplPTI+PFNQQU4gY2xhc3M9MDE3MzIyODA4LTEzMDEyMDA2PkZpcnN0IG9mIGFsbCBub3Rl IHRoYXQgdGhpcyANCiAgICBwb2ludCBpcyBub3QgYSBwcm90b2NvbCByZXF1aXJlbWVudCwgdGhp cyBpcyBhIGxvY2FsIGltcGxlbWVudGF0aW9uIGlzc3VlLCANCiAgICBhbmQgdGhlIGppdHRlcmlu ZyB3YXMganVzdCBnaXZlbiBhcyBhbiBleGFtcGxlLi4uPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAg ICA8RElWPjxGT05UIHNpemU9Mj48U1BBTiBjbGFzcz0wMTczMjI4MDgtMTMwMTIwMDY+VGhlIFBD QyBjb3VsZCBhcHBseSANCiAgICBkaWZmZXJlbnQgaml0dGVyIHRvIGxvdyBwcmlvcml0eSBhbmQg aGlnaCBwcmlvcml0eSByZXF1ZXN0cywgYW5kIGNvdWxkIA0KICAgIHNlbmQ8L1NQQU4+PC9GT05U PjwvRElWPg0KICAgIDxESVY+PEZPTlQgc2l6ZT0yPjxTUEFOIGNsYXNzPTAxNzMyMjgwOC0xMzAx MjAwNj5oaWdoIHByaW9yaXR5IHJlcXVlc3QgDQogICAgYmVmb3JlIGxvdyBwcmlvcml0eSBvbmUs IHRoaXMgaXMgYSBsb2NhbCBQQ0MgZGVjaXNpb24uPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgICA8 RElWPjxGT05UIHNpemU9Mj48U1BBTiBjbGFzcz0wMTczMjI4MDgtMTMwMTIwMDY+QWxzbyB0aGUg cmVxdWVzdCANCiAgICBwcmlvcml0aXphdGlvbiBmdW5jdGlvbiBjb3VsZCBiZSB1c2VkIHNvIHRo YXQgdGhlIFBDRSBzZXJ2ZXMgaGlnaCBwcmlvcml0eSANCiAgICByZXF1ZXN0cyBmaXJzdC4gVGhl IHdheSBhIFBDRSBpcyBnb2luZyB0byBoYW5kbGUgcmVxdWVzdCBwcmlvcml0aXRlcyBpcyBhbHNv IA0KICAgIGEgbG9jYWwgaW1wbGVtZW50YXRpb24gaXNzdWUuPC9TUEFOPjwvRk9OVD48L0RJVj4N CiAgICA8RElWPjxGT05UIHNpemU9Mj48U1BBTiBjbGFzcz0wMTczMjI4MDgtMTMwMTIwMDY+TWF5 YmUgd2Ugc2hvdWxkIHJlbW92ZSB0aGlzIA0KICAgIHNlbnRlbmNlIHRvIGF2b2lkIGFueSBjb25m dXNpb24uIDwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48Rk9OVCBzaXplPTI+PFNQQU4g Y2xhc3M9MDE3MzIyODA4LTEzMDEyMDA2PkJ5IHRoZSB3YXkgbm90ZSB0aGF0IHRoaXMgDQogICAg c2VjdGlvbiBpcyBnZW5lcmljIGFuZCBoYXMganVzdCBiZWVuIG1vdmVkIHRvIHRoZSBnZW5lcmlj IHJlcXVpcmVtZW50IA0KICAgIGRyYWZ0LjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48 Rk9OVCBzaXplPTI+PFNQQU4gY2xhc3M9MDE3MzIyODA4LTEzMDEyMDA2PlNvIHdlIHdpbGwgaGF2 ZSB0byBjbGFyaWZ5IA0KICAgIGluIHRoZSBnZW5lcmljIGRyYWZ0LiZuYnNwOzwvU1BBTj48L0ZP TlQ+PC9ESVY+DQogICAgPERJVj48Rk9OVCBzaXplPTI+PFNQQU4gY2xhc3M9MDE3MzIyODA4LTEz MDEyMDA2PltaUkhdIEkgDQogICAgYWdyZWUuPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgICA8RElW PjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogICAgPERJVj48Rk9OVCBzaXplPTI+ Jm5ic3A7SSBoYXZlIGFsd2F5cyBiZWVuIHRoaW5raW5nIGEgcXVlc3Rpb246IGlmIGEgUENDIA0K ICAgIHdpbGwgbm90IHBlcmZvcm0gdGhlIENTUEYmbmJzcDs8L0ZPTlQ+PC9ESVY+DQogICAgPERJ Vj48Rk9OVCBzaXplPTI+Y29tcHV0YXRpb24sIHdoeSBkb2VzIGl0IHN0aWxsIG1haW50YWluIHRo ZSBURURCIGFueSANCiAgICBsb25nZXI/IHdoaWNoIG1heSBjb25zdW1lIDwvRk9OVD48L0RJVj4N CiAgICA8RElWPjxGT05UIHNpemU9Mj5hIGxvdCBvZiBtZW1vcnkgYW5kIENQVSBvZiBhIExTUi5U aGlzIHF1ZXN0aW9uIGRvc3Qgbm90IA0KICAgIGFpZCZuYnNwO2F0IHRoaXMgZHJhZnQuPFNQQU4g Y2xhc3M9MDE3MzIyODA4LTEzMDEyMDA2PjxGT05UIGZhY2U9QXJpYWwgDQogICAgY29sb3I9IzAw MDBmZj4mbmJzcDs8L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgICA8RElWPjxGT05UIHNp emU9Mj48U1BBTiBjbGFzcz0wMTczMjI4MDgtMTMwMTIwMDY+PC9TUEFOPjwvRk9OVD4mbmJzcDs8 L0RJVj4NCiAgICA8RElWPjxGT05UIHNpemU9Mj48U1BBTiBjbGFzcz0wMTczMjI4MDgtMTMwMTIw MDY+PEZPTlQgZmFjZT1BcmlhbCANCiAgICBjb2xvcj0jMDAwMGZmPltKTExSXSZuYnNwOzwvRk9O VD48L1NQQU4+PC9GT05UPjxGT05UIHNpemU9Mj48U1BBTiANCiAgICBjbGFzcz0wMTczMjI4MDgt MTMwMTIwMDY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmPkEmbmJzcDtMU1IgbWF5IGJl IGEgDQogICAgUENDJm5ic3A7Zm9yIHNvbWUgTFNQcyBhbmQgYSBQQ0UmbmJzcDtmb3ImbmJzcDtv dGhlciANCiAgICBMU1BzLjwvRk9OVD4mbmJzcDs8L1NQQU4+PC9GT05UPjwvRElWPg0KICAgIDxE SVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCiAgICBjbGFz cz0wMTczMjI4MDgtMTMwMTIwMDY+QW55d2F5IGEgTFNSJm5ic3A7dGhhdCBydW5zJm5ic3A7SVNJ UyBvciANCiAgICBPU1BGJm5ic3A7Zm9yIElQIHJvdXRpbmcmbmJzcDtoYXMgdG8gbWFpbnRhaW4g YSBMU0RCLiBJIGFncmVlJm5ic3A7cmVtb3ZpbmcgDQogICAgVEUgaW5mbyB3b3VsZCBzYXZlIHNv bWUgbWVtb3J5IGFuZCBDUFUmbmJzcDtidXQgdGhlIGdhaW4mbmJzcDtzb3VuZHMgDQogICAgcXVp dGUmbmJzcDtsb3cgY29tcGFyZWQgdG8gdGhlIGltcGFjdDogRm9yIGFueSBjb21wdXRhdGlvbiwg ZXZlbiBhIHNpbXBsZSANCiAgICBpbnRyYS1hcmVhIENTUEYsIHlvdSB3b3VsZCBoYXZlIHRvIGFz ayZuYnNwO2EgUENFLCZuYnNwO2FuZCB0aGlzIA0KICAgIG1heSZuYnNwO2xlYWQgdG8gYSBoaWdo IFBDRSBzdHJlc3MuIFlvdSB3b3VsZCBoYXZlIGEgc21hbGwgQ1BVIGdhaW4mbmJzcDtvbiANCiAg ICBMU1JzIGF0IGEgY29zdCBvZiBhIGh1Z2UgQ1BVIGNvbnN1bXB0aW9uIG9uIFBDRXMuLi48L1NQ QU4+PC9GT05UPjwvRElWPg0KICAgIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4g Y2xhc3M9MDE3MzIyODA4LTEzMDEyMDA2PltaUkhdeWVzLCB5b3VyIA0KICAgIGV4cGFuYXRpb24g aXMgZ3JlYXQsIEkgdGhpbmsgeW91IGFyZSByaWdodC48L1NQQU4+PC9GT05UPjwvRElWPg0KICAg IDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogICAgY2xhc3M9MDE3MzIyODA4 LTEzMDEyMDA2PjwvU1BBTj48L0ZPTlQ+PEZPTlQgc2l6ZT0yPjxTUEFOIA0KICAgIGNsYXNzPTAx NzMyMjgwOC0xMzAxMjAwNj48Rk9OVCBmYWNlPUFyaWFsIA0KICAgIGNvbG9yPSMwMDAwZmY+PC9G T05UPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogICAgPERJVj48Rk9OVCBzaXplPTI+SW4g aW50ZXItYXJlYSBlbnZpcm9ubWVudCxzb21ldGltZXMsIGEgUENDIG1heSB3aXNoIHRvIGdldCAN CiAgICBhcyBtYW55IHBhdGhzIGFzIHBvc3NpYmxlLDwvRk9OVD48L0RJVj4NCiAgICA8RElWPjxG T05UIHNpemU9Mj5mb3IgYWxsIGtpbmRzIG9mIHB1cnBvc2Usc28gY291bGQgdGhlIFBDQyBzZW5k IHRoZSByZXF1ZXN0IA0KICAgIHRvIG1vcmUgdGhhbiBvbmUgUENFcz8mbmJzcDs8U1BBTiBjbGFz cz0wMTczMjI4MDgtMTMwMTIwMDY+PEZPTlQgZmFjZT1BcmlhbCANCiAgICBjb2xvcj0jMDAwMGZm PiZuYnNwOzwvRk9OVD48L1NQQU4+PC9GT05UPjwvRElWPg0KICAgIDxESVY+PEZPTlQgc2l6ZT0y PjxTUEFOIGNsYXNzPTAxNzMyMjgwOC0xMzAxMjAwNj48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElW Pg0KICAgIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiAN CiAgICBjbGFzcz0wMTczMjI4MDgtMTMwMTIwMDY+W0pMTFJdIFllcywgYW5kJm5ic3A7dGhpcyBp cyBhIHByb2NlZHVyZSBsb2NhbCB0byANCiAgICB0aGUgUENDLCB0aGF0IGRvZXMgbm90IGltcGx5 IHNwZWNpZmljIA0KICAgIFBDRUNQJm5ic3A7cHJvY2VkdXJlLjwvU1BBTj48L0ZPTlQ+PC9ESVY+ DQogICAgPERJVj48Rk9OVCBzaXplPTI+PEZPTlQgZmFjZT1BcmlhbD48U1BBTiANCiAgICBjbGFz cz0wMTczMjI4MDgtMTMwMTIwMDY+W1pSSF0mbmJzcDtJIG5vdGljZWQgdGhhdCBpbiB0aGUgZHJh ZnQgDQogICAgZHJhZnQtaWV0Zi1wY2UtYXJjaGl0ZWN0dXJlLTAzLCB0aGVyZSBhcmUgYWxyZWFk eSByZXN0cmljdGlvbiA8L1NQQU4+PFNQQU4gDQogICAgY2xhc3M9MDE3MzIyODA4LTEzMDEyMDA2 PmZvciBhIFBDQyB0byBzZW50IA0KICAgIG11bHRpcGxlPC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9E SVY+DQogICAgPERJVj48Rk9OVCBzaXplPTI+PEZPTlQgZmFjZT1BcmlhbD48U1BBTiBjbGFzcz0w MTczMjI4MDgtMTMwMTIwMDY+cmVxdWVzdHMgDQogICAgZm9yIGEgTFNQLiA8L1NQQU4+PFNQQU4g Y2xhc3M9MDE3MzIyODA4LTEzMDEyMDA2PlNvIEkgd291bGQgbGlrdCB0byBhc2sgaWYgDQogICAg dGhlIHJlc3RyaWN0aW9uIGNhbiBiZSByZW1vdmUgYmVmb3JlIHdlIHJlYWNoIGEgYWdyZWVtZW50 IA0KICAgIDwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvRElWPg0KICAgIDxESVY+PEZPTlQgZmFjZT1B cmlhbCBzaXplPTI+PFNQQU4gY2xhc3M9MDE3MzIyODA4LTEzMDEyMDA2Pm9uIHRoaXMgcG9pbnQ/ IA0KICAgIDwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48U1BBTiBjbGFzcz0wMTczMjI4 MDgtMTMwMTIwMDY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IA0KICAgIHNpemU9Mj48L0ZP TlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICAgIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0j MDAwMGZmIHNpemU9Mj48U1BBTiANCiAgICBjbGFzcz0wMTczMjI4MDgtMTMwMTIwMDY+VGhhbmtz IGZvciB0aGVzZSB2YWx1YWJsZSANCiAgICBjb21tZW50czwvU1BBTj48L0ZPTlQ+PC9ESVY+DQog ICAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICAg IGNsYXNzPTAxNzMyMjgwOC0xMzAxMjAwNj48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KICAg IDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCiAgICBj bGFzcz0wMTczMjI4MDgtMTMwMTIwMDY+UmVnYXJkcyw8L1NQQU4+PC9GT05UPjwvRElWPg0KICAg IDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCiAgICBj bGFzcz0wMTczMjI4MDgtMTMwMTIwMDY+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgICA8 RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQogICAgY2xh c3M9MDE3MzIyODA4LTEzMDEyMDA2PkpMPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgICA8RElWPjxG T05UIHNpemU9Mj48U1BBTiBjbGFzcz0wMTczMjI4MDgtMTMwMTIwMDY+PC9TUEFOPjwvRk9OVD4m bmJzcDs8L0RJVj4NCiAgICA8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQog ICAgPERJVj48Rk9OVCBzaXplPTI+UmVnYXJkcyw8L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48Rk9O VCBzaXplPTI+WmhhbmcgPC9GT05UPjwvRElWPjwvQkxPQ0tRVU9URT48L0JMT0NLUVVPVEU+PC9C T0RZPjwvSFRNTD4NCg== --Boundary_(ID_84wyYID0R8tSBv+UQGpivw)-- --===============0517005409== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0517005409==-- From pce-bounces@lists.ietf.org Tue Jan 17 15:50:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyxms-00023J-7y; Tue, 17 Jan 2006 15:50:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyxmH-0001tO-72; Tue, 17 Jan 2006 15:50:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16663; Tue, 17 Jan 2006 15:48:38 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyxuQ-000666-Ul; Tue, 17 Jan 2006 15:58:31 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EyxmD-0008E0-Pe; Tue, 17 Jan 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 17 Jan 2006 15:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-architecture-04.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : A Path Computation Element (PCE) Based Architecture Author(s) : A. Farrel, et al. Filename : draft-ietf-pce-architecture-04.txt Pages : 37 Date : 2006-1-17 Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region or multi-layer networks is complex and may require special computational components and cooperation between the different network domains. This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-architecture-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-architecture-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-architecture-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-1-17130515.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-architecture-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-architecture-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-17130515.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Wed Jan 18 04:04:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez9FG-0008SC-BN; Wed, 18 Jan 2006 04:04:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez9FE-0008On-Gg for pce@megatron.ietf.org; Wed, 18 Jan 2006 04:04:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20223 for ; Wed, 18 Jan 2006 04:03:17 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ez9NT-0000Xj-H3 for pce@ietf.org; Wed, 18 Jan 2006 04:13:19 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ITA00CKA71ZLB@szxga02-in.huawei.com> for pce@ietf.org; Wed, 18 Jan 2006 17:15:36 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ITA005OJ71Z14@szxga02-in.huawei.com> for pce@ietf.org; Wed, 18 Jan 2006 17:15:35 +0800 (CST) Received: from z18605 ([10.111.12.87]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ITA00JAF77NII@szxml01-in.huawei.com>; Wed, 18 Jan 2006 17:19:00 +0800 (CST) Date: Wed, 18 Jan 2006 16:37:23 +0800 From: Zhang Renhai Subject: Re: [Pce] Comment on draft-ietf-pce-pcecp-interarea-reqs-00.txt To: JP Vasseur Message-id: <015801c61c0a$6839b1a0$570c6f0a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <11aac111b1bc.11b1bc11aac1@huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: 7BIT Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, Jean-Philippe See inline. ----- Original Message ----- From: "JP Vasseur" To: "zhangrenhai 18605" Cc: "LE ROUX Jean-Louis RD-CORE-LAN" ; Sent: Friday, January 13, 2006 9:52 PM Subject: Re: [Pce] Comment on draft-ietf-pce-pcecp-interarea-reqs-00.txt > Hi, > > On Jan 12, 2006, at 10:40 PM, zhangrenhai 18605 wrote: > > > Hi, JP > > > > Sorry for seeing your reply so late. > > Thanks, see inline. > > > > ----- Original Message ----- > > From: JP Vasseur > > Date: Thursday, January 5, 2006 3:07 am > > Subject: Re: [Pce] Comment on draft-ietf-pce-pcecp-interarea- > > reqs-00.txt > > > >> Hi , > >> > >> On Dec 28, 2005, at 2:03 AM, Zhang Renhai wrote: > >> > >>> Hi, Jean-Louis > >>> > >>> I have some comment on the draft draft-ietf-pce-pcecp-interarea- > >> > >>> reqs-00.txt > >>> > >>> In section 7.11.1, In case of network failure, jittering will > >> be > >>> used to avoid > >>> simultaneous requests sent to one PCE. Could more consideration > >> be > >>> given here to > >>> the preemptment, becouse the jittering timeout is stochastic, > >> some > >>> lower request > >>> may be served before a higher request and the path may be > >>> calculated differently. > >>> which may increase the probability of a preemptment. > >>> > >> > >> The decision on the PCC request scheduling is out of the scope of > >> this ID. Note that the point that you mentioned also applies to > >> the > >> located-PCE case. > > I am not sure what scope this point belongs to. I just considered > > more about what > > has been mentioned in the draft. > > Is this consideration important anough to be added somewhere? > > You're very welcome to discuss the topic on the list [ZRH](Can I cut your words so?) Thanks ! but PCC request > request scheduling are not standardized. > > >> > >>> > >>> I have always been thinking a question: if a PCC will not > >> perform > >>> the CSPF > >>> computation, why does it still maintain the TEDB any longer? > >> which > >>> may consume > >>> a lot of memory and CPU of a LSR.This question dost not aid at > >> this > >>> draft. > >>> > >> > >> Because > >> (1) The PCE may decide to use a remote PCE for some LSPs and not > >> for > >> others (for instance, inter versus intra-domain) > >> (2) The PCE may decide to always use a PCE and fall back to local > >> path computation or loose hop routing under specific conditions > > Agree, I just want to be convinced if some routers acting as a pure > > PCC > > (no longer perform path computation)can save some CPU and memory so > > there could be a lower requirement on capability to these routers > > in PCE-based environment.Maybe this is a benefit to PCE Architecture. > > Sure, this is an option already described in the draft. > > >> > >>> In inter-area environment,sometimes, a PCC may wish to get as > >> many > >>> paths as possible, > >>> for all kinds of purpose,so could the PCC send the request to > >> more > >>> than one PCEs? > >>> > >> > >> Yes, although this would clearly be very sub-optimal .... > > I am not sure your point, could you please expand your explanation > > any more? > > In my opinion, a ABR acting as a PCE usually can not have a full AS- > > scope information of TED. > > so it may return a sub-optimal compuation result compared to some > > latent path which can be returned by other ABR linked to a different > > area. I know this can be solved by a ABR through sending the > > request to multiple > > ABR in a area, otherwise, how to solve this problem? > > Yes stay tuned ... I'll resurrect soon a draft that used to be > discussed in CCAMP detailing these aspects. [ZRH]If possible, I can join you. > > Thanks. > > JP. > > > > > > > Thanks, > > Zhang > > > >> > >> JP. > >> > >>> Regards, > >>> Zhang > >>> _______________________________________________ > >>> Pce mailing list > >>> Pce@lists.ietf.org > >>> https://www1.ietf.org/mailman/listinfo/pce > >> > >> _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jan 18 17:24:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzLj8-0004Fi-Ey; Wed, 18 Jan 2006 17:24:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzLj6-0004A8-5G for pce@megatron.ietf.org; Wed, 18 Jan 2006 17:24:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15946; Wed, 18 Jan 2006 17:22:56 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzLrU-0001pX-DQ; Wed, 18 Jan 2006 17:33:05 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by sj-iport-1.cisco.com with ESMTP; 18 Jan 2006 14:24:13 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0IMNk6f012084; Wed, 18 Jan 2006 17:24:10 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 Jan 2006 17:22:58 -0500 Received: from [161.44.71.184] ([161.44.71.184]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 Jan 2006 17:22:57 -0500 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Wed, 18 Jan 2006 17:22:26 -0500 To: Alex Zinin , Bill Fenner X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 18 Jan 2006 22:22:57.0718 (UTC) FILETIME=[BBFF0560:01C61C7D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: iesg-secretary@ietf.org, pce@ietf.org Subject: [Pce] Publication Request: draft-ietf-pce-architecture-04.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, draft-ietf-pce-architecture-04.txt has completed WG Last Call and is now ready according to the WG chairs' judgement. Please consider it for publication as an Informational RFC. Thanks, JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jan 27 14:14:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Z3V-0001lS-GN; Fri, 27 Jan 2006 14:14:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Z3T-0001lH-Rd for pce@megatron.ietf.org; Fri, 27 Jan 2006 14:14:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06466 for ; Fri, 27 Jan 2006 14:13:11 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2ZDg-0002CS-5n for pce@ietf.org; Fri, 27 Jan 2006 14:25:17 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 27 Jan 2006 11:14:07 -0800 X-IronPort-AV: i="4.01,227,1136188800"; d="scan'208,217"; a="397369328:sNHT1209578382" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0RJE3Kd012367; Fri, 27 Jan 2006 11:14:07 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 Jan 2006 14:14:03 -0500 Received: from [192.168.1.101] ([10.86.242.63]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 Jan 2006 14:14:03 -0500 Mime-Version: 1.0 (Apple Message framework v746.2) To: pce@ietf.org Message-Id: From: JP Vasseur Date: Fri, 27 Jan 2006 14:13:35 -0500 X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 27 Jan 2006 19:14:03.0366 (UTC) FILETIME=[D5E9E860:01C62375] X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Bill Fenner Subject: [Pce] New WG Milestone X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0712064046==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============0712064046== Content-Type: multipart/alternative; boundary=Apple-Mail-21--979257938 --Apple-Mail-21--979257938 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi, Just a quick note to let you know that we have reached a new WG Milestone: Done Submit PCE architecture specification to the IESG to be considered as Informational RFC Thanks. JP. --Apple-Mail-21--979257938 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Just a quick note to let = you know that we have reached a new WG Milestone:=A0

Done=A0Submit PCE architecture = specification to the IESG to be considered as Informational = RFC

Thanks.

JP.
= --Apple-Mail-21--979257938-- --===============0712064046== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0712064046==-- From pce-bounces@lists.ietf.org Sat Jan 28 05:43:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2nYK-0007fE-SH; Sat, 28 Jan 2006 05:43:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2nYJ-0007f3-4E for pce@megatron.ietf.org; Sat, 28 Jan 2006 05:43:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12236 for ; Sat, 28 Jan 2006 05:41:57 -0500 (EST) Received: from relay3.mail.uk.clara.net ([80.168.70.143]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2nid-0007Mg-Ma for pce@ietf.org; Sat, 28 Jan 2006 05:54:13 -0500 Received: from host4-128.pool81119.interbusiness.it ([81.119.128.4] helo=Puppy) by relay3.mail.uk.clara.net with esmtpa (Exim 4.46) id 1F2nY4-000JtC-EV for pce@ietf.org; Sat, 28 Jan 2006 10:43:16 +0000 Message-ID: <03db01c623f8$30001090$06807751@Puppy> From: "Adrian Farrel" To: Date: Sat, 28 Jan 2006 10:46:04 -0000 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Clara-Relay: Message sent using Claranet Relay Service using auth code: olddog X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Fw: Internet-Drafts Submission Cutoff Dates for the 65th IETF Meeting in Dallas, TX, USA X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org FYI ----- Original Message ----- From: To: Sent: Friday, January 27, 2006 5:00 AM Subject: Internet-Drafts Submission Cutoff Dates for the 65th IETF Meeting in Dallas, TX, USA > > There are two (2) Internet-Draft cutoff dates for the 65th > IETF Meeting in Dallas, TX, USA: > > February 27th: Cutoff Date for Initial (i.e., version -00) > Internet-Draft Submissions > > All initial Internet-Drafts (version -00) must be submitted by Monday, > February 27th at 9:00 AM ET. As always, all initial submissions with a > filename beginning with "draft-ietf" must be approved by the > appropriate WG Chair before they can be processed or announced. The > Secretariat would appreciate receiving WG Chair approval by Monday, > February 20th at 9:00 AM ET. > > March 6th: Cutoff Date for Revised (i.e., version -01 and higher) > Internet-Draft Submissions > > All revised Internet-Drafts (version -01 and higher) must be submitted > by Monday, March 6th at 9:00 AM ET. > > Initial and revised Internet-Drafts received after their respective > cutoff dates will not be made available in the Internet-Drafts > directory or announced until on or after Monday, March 20th at 9:00 > AM ET, when Internet-Draft posting resumes. Please do not wait until > the last minute to submit. > > Thank you for your understanding and cooperation. If you have any > questions or concerns, then please send a message to > internet-drafts@ietf.org. > > The IETF Secretariat > > FYI: The Internet-Draft cutoff dates as well as other significant dates > for the 65th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_65.html. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sat Jan 28 13:47:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2v6x-0001cU-Pz; Sat, 28 Jan 2006 13:47:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2v6v-0001bF-Pb for pce@megatron.ietf.org; Sat, 28 Jan 2006 13:47:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05320 for ; Sat, 28 Jan 2006 13:46:05 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2vHE-0002Bs-L6 for pce@ietf.org; Sat, 28 Jan 2006 13:58:25 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 28 Jan 2006 10:47:29 -0800 X-IronPort-AV: i="4.01,230,1136188800"; d="scan'208"; a="397701834:sNHT27841252" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0SIlSWF012617; Sat, 28 Jan 2006 10:47:28 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 28 Jan 2006 13:47:28 -0500 Received: from [192.168.1.101] ([10.86.241.51]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 28 Jan 2006 13:47:27 -0500 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1F4E4DB7-2D48-45CC-B9F1-232F32D8D043@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Sat, 28 Jan 2006 13:46:59 -0500 To: pce@ietf.org X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 28 Jan 2006 18:47:27.0828 (UTC) FILETIME=[494FE140:01C6243B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Next WG meeting ... X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, We have requested a 2-hour slot for our next meeting in Dallas. Since we'll start working soon on the agenda, if you have plan to request a slot, thanks to let us know. Thanks. JP and Adrian. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce