Subject: Fwd: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp

From: JP Vasseur <[email-masked]>
Date: Mon, 8 Oct 2007 16:35:57 -0400

Dear WG,

Christian Jacquenet on behalf of IPSphere proposed to make several  
comments on this document.
Christian, could you please send them to the list ?

As agreed, we're still planning to issue a WG LC after this round of  
discussion.

Thanks.

JP.

Begin forwarded message:

> From: JP Vasseur <[email-masked]>
> Date: September 18, 2007 2:10:12 PM EDT
> To: [email-masked], Lou Berger <[email-masked]>, Igor Bryskin  
> <[email-masked]>, Dimitri Papadimitriou  
> <[email-masked]>, [email-masked]
> Cc: Thomas Walsh <[email-masked]>, JACQUENET Christian RD-TCH- 
> REN <[email-masked]>
> Subject: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp
>
> Dear WG,
>
> From the WG minutes of the IETF-69 meeting:
>
> 12) Update on Policy-Enabled Path Computation Framework
> draft-ietf-pce-policy-enabled-path-comp-01.txt (Lou - 5mn) [110]
>
> Lou> ready for Last Call
> JP> It sounds ready. Suggestion: offer IPSphere to have a look at  
> the doc before last call. JP will be the point
> of contact. Asked Ross whether this is a good idea, and Ross  
> agreed. Once comments are received, last call.
> Adrian> OK, but this is not an indefinite consultation. We want to  
> be able to move ahead and complete the I-D
> relatively soon.
>
> We have contacted IPSphere and RA WG of IPSphere should provide us  
> some feed-back by
> mid-October. I have copied Tom Walsh and Christian Jacquenet (chair  
> of the RAWG) IPSphere.
>
> Thanks.
>
> JP.
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pce

_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: "JACQUENET Christian RD-DDEV-REN" <[email-masked]>
Date: Tue, 9 Oct 2007 13:47:55 +0200

Dear all,
 
Please find herein my comments, which are *not* on behalf of the IPSF - only personal :-)
1. General:

	I think this is a very useful document that clearly identifies the advantages of policy-based path computation management in PCE environments. Nevertheless, I would encourage a refined organization of the document, which would distinguish between the framework (current sections 2.1, 4 and 5 basically), the requirements (section 3, but also part of the text that relates to scenarios) and use cases or scenarios (sections 2.2.x, a bit of sections 7 and 8).

2. Section 2.1, page 5:

	The introductory sentence of the third paragraph implicly indicates that PCE may very well behave as either a PDP (makes decisions to be applied by PCC clients for example) or a PEP (applies decisions possibly made by PCC clients and/or other PCE components). I think this is one of the very key notions introduced by this draft, and would therefore suggest an introductory section that would elaborate on this heuristic, possibly after the reminder about basic concepts of policy-based management.

3. Section 2.1, page 6:

	The last sentence of the first paragraph is slightly confusing: I don't think the "or" is exclusive, that is, provider-defined policies might very well be real time.

4. Section 2.2.3, page 11:

	What's a policy-enabled PCC? A PCC that either embeds a PEP, a PDP or both? I think this should be elaborated, possibly in the Terminology section. Note also that the last sentence of the page mixes the notions of "making decision" and "apply user or service-specific policies": since the text introduces a kind of causality effect (the PEP embedded in the PCC enforces user or service-specific policies, which seems to result in soliciting the PDP embedded in the PEP to make decisions about the scope of constraints that need to be taken into account for path computation purposes), I would suggest a kind of flow diagram that could possibly elaborate on the corresponding chronology.

5. Section 2.2.3, page 12:

	Related to the comment above, the sentence "when deciding..." of the first paragraph may also suggest the activation of a LPDP capability. I would also elaborate on the possible interactions between the PEP, the PDP and the possible LPDP capabilities that may be embedded in the PCC, assuming a differentiation "a la COPS Client-Type". Who's the destinee of the path computation request in the "once the constraints..." sentence of the same paragraph - the PCE?

	In the third paragraph, it seems that (1) The PCC embeds a PDP that makes decisions about constraint-defined policies, (2) Sends a path computation request that conveys the aforementioned policy information towards the PCE, whose embedded PEP (3) Applies the corresponding decisions: is this statement correct? If so, I don't understand why the PCE may "decide to reject the request": that is, from a policy management standpoint, only the PEP of the PCE is solicited in this context, which means that the PEP may not be capable of enforcing the decision, but I don't think the PEP is entitled to *reject* the decision, as part of a decision making process. Maybe it's a wording issue.

	What would be the conditions to send path computation requests to more than one PCE, aside from an inter-domain context? I'm not sure I understand why the response sent by the PCE-PEP back to the requesting PCC-PDP may indicate *policies*. Unless the document refers to a kind of PCE-inferred feedback PIB (RFC 3571)? In that case, I would elaborate.

6. Section 3, page 15:

	The notion of trusted nodes (as introdcued in the third paragraph) should deserve some elaboration, IMHO. The security considerations of this page should either be extended (e.g. preservation of the confidentiality of the information that will be exchanged between a PDP and a set of PDPs), or reference the "true" Security Considerations section of the document, which BTW, rightfully elaborates on such issues.

7. Section 5, page 18:

	I don't understand why a protocol like COPS couldn't be used in the case where PEP and PDP are colocated. In any case, a protocol is required to convey the exchanges between the PEP and the PDP...

	In addition (last line of the page), it's very unlikely that SNMP will be used to retrieve information from a PIB.

8. Section 5, page 19:

	I would suggest some elaboration on the kind of information any given PEP (PCC or PCE) may receive from another *PEP* - is this a typo (i.e. read PDP instead), or does this relate to information different from "policy-related" information or else? In a COPS context, multiple Client-Types can certainly reside and coexist within a PEP, but I'm not sure I understand why PEPs would exchange information.

	Also, the following paragraph ("any given policy...") is a bit confusing to me: I don't understand this notion of partial interpretation, and would rather suggest another wording - enforcement instead of interpretation. Besides, I'm not sure this paragraph helps in understanding the roles played by PEPs and PDPs.

9. Section 6.1., page 20:

	Why *all* PC policy types used in the net *must* be applied? It's a "Client-Type" specific thing, IMHO.

10. Section 6.1., page 21:

	In the first paragraph, I don't understand why the PCE selection should be static. Even if the policy enforcement is restricted to the PCE (for path computation purposes), nothing prevents a PEP embedded in a PCC to support the relevant "Client-Type", hence yielding the dynamic identification of the corresponding PCE, by means of the COPS-like OPEN message at PCC bootstrap, for example.

	In the third paragraph, the "must" of the first sentence is too strong, IMHO, unless the sentence means that any kind of policy must "encouarge" the support of the corresponding "Client-Types" in the PCC-PEP. If so, I would rephrase.

11. Section 6.2., page 22:

	I don't understand why matching repositories would result in a single PC repository, unless further elaboration on such match is provided.

12. Section 6.3, page 23:

	Does the figure relate to PCE instead of PCC (same for figure 12)?

13. Section 7.1., page 25:

	What's an "objection function"?

14. Typos:

	TED = Traffic Engineering Database?

	SRLG = Shared Risk Link Group?

	Page 16, provide the normative reference associated to LDAPv3.

	Page 17, remove the "s" of the very last word of the page.

Cheers,

Christian.

________________________________

De : JP Vasseur [mailto:[email-masked]] 
Envoyé : lundi 8 octobre 2007 22:36
À : [email-masked]; Lou Berger; Igor Bryskin; Dimitri Papadimitriou; [email-masked]
Cc : Thomas Walsh; JACQUENET Christian RD-DDEV-REN
Objet : Fwd: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp

Dear WG, 

Christian Jacquenet on behalf of IPSphere proposed to make several comments on this document.
Christian, could you please send them to the list ?

As agreed, we're still planning to issue a WG LC after this round of discussion.

Thanks.

JP.

Begin forwarded message:

	From: JP Vasseur <[email-masked]>
	Date: September 18, 2007 2:10:12 PM EDT
	To: [email-masked], Lou Berger <[email-masked]>, Igor Bryskin <[email-masked]>, Dimitri Papadimitriou <[email-masked]>, [email-masked]
	Cc: Thomas Walsh <[email-masked]>, JACQUENET Christian RD-TCH-REN <[email-masked]>
	Subject: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp

	Dear WG, 

	Lou> ready for Last Call
	JP> It sounds ready. Suggestion: offer IPSphere to have a look at the doc before last call. JP will be the point
	of contact. Asked Ross whether this is a good idea, and Ross agreed. Once comments are received, last call.
	Adrian> OK, but this is not an indefinite consultation. We want to be able to move ahead and complete the I-D
	relatively soon.

	We have contacted IPSphere and RA WG of IPSphere should provide us some feed-back by
	mid-October. I have copied Tom Walsh and Christian Jacquenet (chair of the RAWG) IPSphere.

	Thanks.

	JP.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 11 Oct 2007 13:09:34 +0100

Christian,

Many thanks for a good review and useful comments.

Can I assume that there are no further comments coming specifically from the 
IPSphere Forum?

Authors, can you tell me whether the scope of comments here are large enough 
to justify a new revision before working group last call? It seems to me 
that the answer should probably be "yes", but I'm open to persuasion.

Thanks,
Adrian

----- Original Message ----- 
From: "JACQUENET Christian RD-DDEV-REN" 
<[email-masked]>
To: "JP Vasseur" <[email-masked]>; <[email-masked]>; "Lou Berger" 
<[email-masked]>; "Igor Bryskin" <[email-masked]>; "Dimitri 
Papadimitriou" <[email-masked]>; <[email-masked]>
Cc: "Thomas Walsh" <[email-masked]>
Sent: Tuesday, October 09, 2007 12:47 PM
Subject: RE: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp

Dear all,

Please find herein my comments, which are *not* on behalf of the IPSF - only 
personal :-)
1. General:

I think this is a very useful document that clearly identifies the 
advantages of policy-based path computation management in PCE environments. 
Nevertheless, I would encourage a refined organization of the document, 
which would distinguish between the framework (current sections 2.1, 4 and 5 
basically), the requirements (section 3, but also part of the text that 
relates to scenarios) and use cases or scenarios (sections 2.2.x, a bit of 
sections 7 and 8).

2. Section 2.1, page 5:

The introductory sentence of the third paragraph implicly indicates that PCE 
may very well behave as either a PDP (makes decisions to be applied by PCC 
clients for example) or a PEP (applies decisions possibly made by PCC 
clients and/or other PCE components). I think this is one of the very key 
notions introduced by this draft, and would therefore suggest an 
introductory section that would elaborate on this heuristic, possibly after 
the reminder about basic concepts of policy-based management.

3. Section 2.1, page 6:

The last sentence of the first paragraph is slightly confusing: I don't 
think the "or" is exclusive, that is, provider-defined policies might very 
well be real time.

What's a policy-enabled PCC? A PCC that either embeds a PEP, a PDP or both? 
I think this should be elaborated, possibly in the Terminology section. Note 
also that the last sentence of the page mixes the notions of "making 
decision" and "apply user or service-specific policies": since the text 
introduces a kind of causality effect (the PEP embedded in the PCC enforces 
user or service-specific policies, which seems to result in soliciting the 
PDP embedded in the PEP to make decisions about the scope of constraints 
that need to be taken into account for path computation purposes), I would 
suggest a kind of flow diagram that could possibly elaborate on the 
corresponding chronology.

Related to the comment above, the sentence "when deciding..." of the first 
paragraph may also suggest the activation of a LPDP capability. I would also 
elaborate on the possible interactions between the PEP, the PDP and the 
possible LPDP capabilities that may be embedded in the PCC, assuming a 
differentiation "a la COPS Client-Type". Who's the destinee of the path 
computation request in the "once the constraints..." sentence of the same 
paragraph - the PCE?

In the third paragraph, it seems that (1) The PCC embeds a PDP that makes 
decisions about constraint-defined policies, (2) Sends a path computation 
request that conveys the aforementioned policy information towards the PCE, 
whose embedded PEP (3) Applies the corresponding decisions: is this 
statement correct? If so, I don't understand why the PCE may "decide to 
reject the request": that is, from a policy management standpoint, only the 
PEP of the PCE is solicited in this context, which means that the PEP may 
not be capable of enforcing the decision, but I don't think the PEP is 
entitled to *reject* the decision, as part of a decision making process. 
Maybe it's a wording issue.

What would be the conditions to send path computation requests to more than 
one PCE, aside from an inter-domain context? I'm not sure I understand why 
the response sent by the PCE-PEP back to the requesting PCC-PDP may indicate 
*policies*. Unless the document refers to a kind of PCE-inferred feedback 
PIB (RFC 3571)? In that case, I would elaborate.

6. Section 3, page 15:

The notion of trusted nodes (as introdcued in the third paragraph) should 
deserve some elaboration, IMHO. The security considerations of this page 
should either be extended (e.g. preservation of the confidentiality of the 
information that will be exchanged between a PDP and a set of PDPs), or 
reference the "true" Security Considerations section of the document, which 
BTW, rightfully elaborates on such issues.

7. Section 5, page 18:

I don't understand why a protocol like COPS couldn't be used in the case 
where PEP and PDP are colocated. In any case, a protocol is required to 
convey the exchanges between the PEP and the PDP...

In addition (last line of the page), it's very unlikely that SNMP will be 
used to retrieve information from a PIB.

8. Section 5, page 19:

I would suggest some elaboration on the kind of information any given PEP 
(PCC or PCE) may receive from another *PEP* - is this a typo (i.e. read PDP 
instead), or does this relate to information different from "policy-related" 
information or else? In a COPS context, multiple Client-Types can certainly 
reside and coexist within a PEP, but I'm not sure I understand why PEPs 
would exchange information.

Also, the following paragraph ("any given policy...") is a bit confusing to 
me: I don't understand this notion of partial interpretation, and would 
rather suggest another wording - enforcement instead of interpretation. 
Besides, I'm not sure this paragraph helps in understanding the roles played 
by PEPs and PDPs.

Why *all* PC policy types used in the net *must* be applied? It's a 
"Client-Type" specific thing, IMHO.

In the first paragraph, I don't understand why the PCE selection should be 
static. Even if the policy enforcement is restricted to the PCE (for path 
computation purposes), nothing prevents a PEP embedded in a PCC to support 
the relevant "Client-Type", hence yielding the dynamic identification of the 
corresponding PCE, by means of the COPS-like OPEN message at PCC bootstrap, 
for example.

In the third paragraph, the "must" of the first sentence is too strong, 
IMHO, unless the sentence means that any kind of policy must "encouarge" the 
support of the corresponding "Client-Types" in the PCC-PEP. If so, I would 
rephrase.

I don't understand why matching repositories would result in a single PC 
repository, unless further elaboration on such match is provided.

14. Typos:

Cheers,

Christian.

À : [email-masked]; Lou Berger; Igor Bryskin; Dimitri Papadimitriou; 
[email-masked]

Dear WG,

Christian Jacquenet on behalf of IPSphere proposed to make several comments 
on this document.
Christian, could you please send them to the list ?

Thanks.

JP.

Begin forwarded message:

From: JP Vasseur <[email-masked]>
Date: September 18, 2007 2:10:12 PM EDT
To: [email-masked], Lou Berger <[email-masked]>, Igor Bryskin 
<[email-masked]>, Dimitri Papadimitriou <[email-masked]>, 
[email-masked]
Cc: Thomas Walsh <[email-masked]>, JACQUENET Christian RD-TCH-REN 
<[email-masked]>
Subject: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp

Dear WG,

Lou> ready for Last Call
JP> It sounds ready. Suggestion: offer IPSphere to have a look at the doc 
before last call. JP will be the point
of contact. Asked Ross whether this is a good idea, and Ross agreed. Once 
comments are received, last call.
Adrian> OK, but this is not an indefinite consultation. We want to be able 
to move ahead and complete the I-D
relatively soon.

We have contacted IPSphere and RA WG of IPSphere should provide us some 
feed-back by
mid-October. I have copied Tom Walsh and Christian Jacquenet (chair of the 
RAWG) IPSphere.

Thanks.

JP.

---

From: "JACQUENET Christian RD-DDEV-REN" <[email-masked]>
Date: Thu, 11 Oct 2007 17:13:33 +0200

Adrian,

Pleasure's all mine :-) Don't expect further comments from the "IPSF", but I'll let individuals who are also involved in the IPSF comment further if they want to.

Cheers,

Christian. 

-----Message d'origine-----
De : Adrian Farrel [mailto:[email-masked]] 
Envoyé : jeudi 11 octobre 2007 14:10
À : JACQUENET Christian RD-DDEV-REN
Cc : Thomas Walsh; JP Vasseur; [email-masked]; Lou Berger; Igor Bryskin; Dimitri Papadimitriou; [email-masked]
Objet : Re: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp

Christian,

Can I assume that there are no further comments coming specifically from the IPSphere Forum?

Authors, can you tell me whether the scope of comments here are large enough to justify a new revision before working group last call? It seems to me that the answer should probably be "yes", but I'm open to persuasion.

Thanks,
Adrian

----- Original Message -----
<[email-masked]>; "Igor Bryskin" <[email-masked]>; "Dimitri Papadimitriou" <[email-masked]>; <[email-masked]>

Dear all,

Please find herein my comments, which are *not* on behalf of the IPSF - only personal :-) 1. General:

I think this is a very useful document that clearly identifies the advantages of policy-based path computation management in PCE environments. 
Nevertheless, I would encourage a refined organization of the document, which would distinguish between the framework (current sections 2.1, 4 and 5 basically), the requirements (section 3, but also part of the text that relates to scenarios) and use cases or scenarios (sections 2.2.x, a bit of sections 7 and 8).

2. Section 2.1, page 5:

3. Section 2.1, page 6:

What's a policy-enabled PCC? A PCC that either embeds a PEP, a PDP or both? 
I think this should be elaborated, possibly in the Terminology section. Note also that the last sentence of the page mixes the notions of "making decision" and "apply user or service-specific policies": since the text introduces a kind of causality effect (the PEP embedded in the PCC enforces user or service-specific policies, which seems to result in soliciting the PDP embedded in the PEP to make decisions about the scope of constraints that need to be taken into account for path computation purposes), I would suggest a kind of flow diagram that could possibly elaborate on the corresponding chronology.

In the third paragraph, it seems that (1) The PCC embeds a PDP that makes decisions about constraint-defined policies, (2) Sends a path computation request that conveys the aforementioned policy information towards the PCE, whose embedded PEP (3) Applies the corresponding decisions: is this statement correct? If so, I don't understand why the PCE may "decide to reject the request": that is, from a policy management standpoint, only the PEP of the PCE is solicited in this context, which means that the PEP may not be capable of enforcing the decision, but I don't think the PEP is entitled to *reject* the decision, as part of a decision making process. 
Maybe it's a wording issue.

6. Section 3, page 15:

7. Section 5, page 18:

8. Section 5, page 19:

I would suggest some elaboration on the kind of information any given PEP (PCC or PCE) may receive from another *PEP* - is this a typo (i.e. read PDP instead), or does this relate to information different from "policy-related" 
information or else? In a COPS context, multiple Client-Types can certainly reside and coexist within a PEP, but I'm not sure I understand why PEPs would exchange information.

Also, the following paragraph ("any given policy...") is a bit confusing to
me: I don't understand this notion of partial interpretation, and would rather suggest another wording - enforcement instead of interpretation. 
Besides, I'm not sure this paragraph helps in understanding the roles played by PEPs and PDPs.

14. Typos:

Cheers,

Christian.

De : JP Vasseur [mailto:[email-masked]] Envoyé : lundi 8 octobre 2007 22:36 À : [email-masked]; Lou Berger; Igor Bryskin; Dimitri Papadimitriou; [email-masked] Cc : Thomas Walsh; JACQUENET Christian RD-DDEV-REN Objet : Fwd: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp

Dear WG,

Thanks.

JP.

Begin forwarded message:

Dear WG,

Lou> ready for Last Call

Thanks.

JP.

---

From: Lou Berger <[email-masked]>
Date: Fri, 12 Oct 2007 17:25:07 -0400

Christian,
         Much thanks for the detailed 
comments.  We'll incorporate changes in the next rev.

BTW one theme in your comments seems to come for 
the style of section 2 staying at a higher level 
(trying to focus on what can be done) and the 
later sections getting into more of the details, 
e.g., PEP and PDP functions.  This approach was 
intentional and I'd be surprised if the next rev 
radically departs from this.  That said, I think 
you have many good comments which will result in 
a more readable document once addressed.

Thanks again for the input,
Lou

At 07:47 AM 10/9/2007, JACQUENET Christian RD-DDEV-REN wrote:

>Dear all,
>
>Please find herein my comments, which are *not* 
>on behalf of the IPSF - only personal :-)
>
>1. General:
>I think this is a very useful document that 
>clearly identifies the advantages of 
>policy-based path computation management in PCE 
>environments. Nevertheless, I would encourage a 
>refined organization of the document, which 
>would distinguish between the framework (current 
>sections 2.1, 4 and 5 basically), the 
>requirements (section 3, but also part of the 
>text that relates to scenarios) and use cases or 
>scenarios (sections 2.2.x, a bit of sections 7 and 8).
>
>2. Section 2.1, page 5:
>The introductory sentence of the third paragraph 
>implicly indicates that PCE may very well behave 
>as either a PDP (makes decisions to be applied 
>by PCC clients for example) or a PEP (applies 
>decisions possibly made by PCC clients and/or 
>other PCE components). I think this is one of 
>the very key notions introduced by this draft, 
>and would therefore suggest an introductory 
>section that would elaborate on this heuristic, 
>possibly after the reminder about basic concepts of policy-based management.
>
>3. Section 2.1, page 6:
>The last sentence of the first paragraph is 
>slightly confusing: I don't think the "or" is 
>exclusive, that is, provider-defined policies might very well be real time.
>
>What's a policy-enabled PCC? A PCC that either 
>embeds a PEP, a PDP or both? I think this should 
>be elaborated, possibly in the Terminology 
>section. Note also that the last sentence of the 
>page mixes the notions of "making decision" and 
>"apply user or service-specific policies": since 
>the text introduces a kind of causality effect 
>(the PEP embedded in the PCC enforces user or 
>service-specific policies, which seems to result 
>in soliciting the PDP embedded in the PEP to 
>make decisions about the scope of constraints 
>that need to be taken into account for path 
>computation purposes), I would suggest a kind of 
>flow diagram that could possibly elaborate on the corresponding chronology.
>
>Related to the comment above, the sentence "when 
>deciding…" of the first paragraph may also 
>suggest the activation of a LPDP capability. I 
>would also elaborate on the possible 
>interactions between the PEP, the PDP and the 
>possible LPDP capabilities that may be embedded 
>in the PCC, assuming a differentiation "a la 
>COPS Client-Type". Who's the destinee of the 
>path computation request in the "once the 
>constraints…" sentence of the same paragraph - 
>the PCE? In the third paragraph, it seems that 
>(1) The PCC embeds a PDP that makes decisions 
>about constraint-defined policies, (2) Sends a 
>path computation request that conveys the 
>aforementioned policy information towards the 
>PCE, whose embedded PEP (3) Applies the 
>corresponding decisions: is this statement 
>correct? If so, I don't understand why the PCE 
>may "decide to reject the request": that is, 
>from a policy management standpoint, only the 
>PEP of the PCE is solicited in this context, 
>which means that the PEP may not be capable of 
>enforcing the decision, but I don't think the 
>PEP is entitled to *reject* the decision, as 
>part of a decision making process. Maybe it's a 
>wording issue. What would be the conditions to 
>send path computation requests to more than one 
>PCE, aside from an inter-domain context? I'm not 
>sure I understand why the response sent by the 
>PCE-PEP back to the requesting PCC-PDP may 
>indicate *policies*. Unless the document refers 
>to a kind of PCE-inferred feedback PIB (RFC 
>3571)? In that case, I would elaborate.
>
>6. Section 3, page 15:
>The notion of trusted nodes (as introdcued in 
>the third paragraph) should deserve some 
>elaboration, IMHO. The security considerations 
>of this page should either be extended (e.g. 
>preservation of the confidentiality of the 
>information that will be exchanged between a PDP 
>and a set of PDPs), or reference the "true" 
>Security Considerations section of the document, 
>which BTW, rightfully elaborates on such issues.
>
>7. Section 5, page 18:
>I don't understand why a protocol like COPS 
>couldn't be used in the case where PEP and PDP 
>are colocated. In any case, a protocol is 
>required to convey the exchanges between the PEP 
>and the PDP… In addition (last line of the 
>page), it's very unlikely that SNMP will be used 
>to retrieve information from a PIB.
>
>8. Section 5, page 19:
>I would suggest some elaboration on the kind of 
>information any given PEP (PCC or PCE) may 
>receive from another *PEP* - is this a typo 
>(i.e. read PDP instead), or does this relate to 
>information different from "policy-related" 
>information or else? In a COPS context, multiple 
>Client-Types can certainly reside and coexist 
>within a PEP, but I'm not sure I understand why 
>PEPs would exchange information. Also, the 
>following paragraph ("any given policy…") is a 
>bit confusing to me: I don't understand this 
>notion of partial interpretation, and would 
>rather suggest another wording - enforcement 
>instead of interpretation. Besides, I'm not sure 
>this paragraph helps in understanding the roles played by PEPs and PDPs.
>
>Why *all* PC policy types used in the net *must* 
>be applied? It's a "Client-Type" specific thing, IMHO.
>
>In the first paragraph, I don't understand why 
>the PCE selection should be static. Even if the 
>policy enforcement is restricted to the PCE (for 
>path computation purposes), nothing prevents a 
>PEP embedded in a PCC to support the relevant 
>"Client-Type", hence yielding the dynamic 
>identification of the corresponding PCE, by 
>means of the COPS-like OPEN message at PCC 
>bootstrap, for example. In the third paragraph, 
>the "must" of the first sentence is too strong, 
>IMHO, unless the sentence means that any kind of 
>policy must "encouarge" the support of the 
>corresponding "Client-Types" in the PCC-PEP. If so, I would rephrase.
>
>I don't understand why matching repositories 
>would result in a single PC repository, unless 
>further elaboration on such match is provided.
>
>TED = Traffic Engineering Database? SRLG = 
>Shared Risk Link Group? Page 16, provide the 
>normative reference associated to LDAPv3. Page 
>17, remove the "s" of the very last word of the page.
>
>Cheers,
>
>Christian.
>
>
>----------
>À : [email-masked]; Lou Berger; Igor Bryskin; 
>Dimitri Papadimitriou; [email-masked]
>Christian Jacquenet on behalf of IPSphere 
>proposed to make several comments on this document.
>>From: JP Vasseur <<mailto:[email-masked]>[email-masked]>
>>To: <mailto:[email-masked]>[email-masked], Lou 
>>Berger 
>><<mailto:[email-masked]>[email-masked]>, 
>>Igor Bryskin 
>><<mailto:[email-masked]>[email-masked]>, 
>>  Dimitri Papadimitriou 
>><<mailto:[email-masked]>[email-masked]>, 
>><mailto:[email-masked]>[email-masked]
>>Cc: Thomas Walsh 
>><<mailto:[email-masked]>[email-masked]>, 
>>  JACQUENET Christian RD-TCH-REN 
>><<mailto:[email-masked]>[email-masked]>
>>JP> It sounds ready. Suggestion: offer IPSphere 
>>to have a look at the doc before last call. JP will be the point
>>of contact. Asked Ross whether this is a good 
>>idea, and Ross agreed. Once comments are received, last call.
>>Adrian> OK, but this is not an indefinite 
>>consultation. We want to be able to move ahead and complete the I-D
>>relatively soon.
>>
>>We have contacted IPSphere and RA WG of 
>>IPSphere should provide us some feed-back by
>>mid-October. I have copied Tom Walsh and 
>>Christian Jacquenet (chair of the RAWG) IPSphere.
>>
>>Thanks.
>>
>>JP.
>><mailto:[email-masked]>[email-masked]

---

From: Lou Berger <[email-masked]>
Date: Fri, 12 Oct 2007 17:34:18 -0400

At 08:09 AM 10/11/2007, Adrian Farrel wrote:
>[...]
>Authors, can you tell me whether the scope of comments here are 
>large enough to justify a new revision before working group last 
>call? It seems to me that the answer should probably be "yes", but 
>I'm open to persuasion.
>[...]

Adrian,
         Speaking only for myself and not my co-authors, I don't 
believe addressing the comments will result in any substantive 
changes.  That said, the resulting document should be more 
readable.  If we wait for the last call, we can probably have a rev 
out in the first week of November.

I have slight preference for doing a last call now so we can find out 
if there are any more substantive issues that need to be 
addressed.  But, it's your call if you want to wait.

Lou

---

From: JP Vasseur <[email-masked]>
Date: Sun, 14 Oct 2007 09:07:33 +0200

Hi Lou,

On Oct 12, 2007, at 11:25 PM, Lou Berger wrote:

> Christian,
>         Much thanks for the detailed comments.  We'll incorporate  
> changes in the next rev.
>
> BTW one theme in your comments seems to come for the style of  
> section 2 staying at a higher level (trying to focus on what can be  
> done) and the later sections getting into more of the details,  
> e.g., PEP and PDP functions.  This approach was intentional and I'd  
> be surprised if the next rev radically departs from this.  That  
> said, I think you have many good comments which will result in a  
> more readable document once addressed.

Lou and co-authors, could you then try to address these comments,  
post the new revision and
we will issue the WG LC right after.

Thanks.

JP.

>> advantages of policy-based path computation management in PCE  
>> environments. Nevertheless, I would encourage a refined  
>> organization of the document, which would distinguish between the  
>> framework (current sections 2.1, 4 and 5 basically), the  
>> requirements (section 3, but also part of the text that relates to  
>> scenarios) and use cases or scenarios (sections 2.2.x, a bit of  
>> sections 7 and 8).
>>
>> 2. Section 2.1, page 5:
>> The introductory sentence of the third paragraph implicly  
>> indicates that PCE may very well behave as either a PDP (makes  
>> decisions to be applied by PCC clients for example) or a PEP  
>> (applies decisions possibly made by PCC clients and/or other PCE  
>> components). I think this is one of the very key notions  
>> introduced by this draft, and would therefore suggest an  
>> introductory section that would elaborate on this heuristic,  
>> The last sentence of the first paragraph is slightly confusing: I  
>> don't think the "or" is exclusive, that is, provider-defined  
>> policies might very well be real time.
>>
>> What's a policy-enabled PCC? A PCC that either embeds a PEP, a PDP  
>> or both? I think this should be elaborated, possibly in the  
>> Terminology section. Note also that the last sentence of the page  
>> mixes the notions of "making decision" and "apply user or service- 
>> specific policies": since the text introduces a kind of causality  
>> effect (the PEP embedded in the PCC enforces user or service- 
>> specific policies, which seems to result in soliciting the PDP  
>> embedded in the PEP to make decisions about the scope of  
>> constraints that need to be taken into account for path  
>> computation purposes), I would suggest a kind of flow diagram that  
>> could possibly elaborate on the corresponding chronology.
>>
>> Related to the comment above, the sentence "when deciding…" of the  
>> first paragraph may also suggest the activation of a LPDP  
>> capability. I would also elaborate on the possible interactions  
>> between the PEP, the PDP and the possible LPDP capabilities that  
>> may be embedded in the PCC, assuming a differentiation "a la COPS  
>> Client-Type". Who's the destinee of the path computation request  
>> in the "once the constraints…" sentence of the same paragraph -  
>> the PCE? In the third paragraph, it seems that (1) The PCC embeds  
>> a PDP that makes decisions about constraint-defined policies, (2)  
>> Sends a path computation request that conveys the aforementioned  
>> policy information towards the PCE, whose embedded PEP (3) Applies  
>> the corresponding decisions: is this statement correct? If so, I  
>> don't understand why the PCE may "decide to reject the request":  
>> that is, from a policy management standpoint, only the PEP of the  
>> PCE is solicited in this context, which means that the PEP may not  
>> be capable of enforcing the decision, but I don't think the PEP is  
>> entitled to *reject* the decision, as part of a decision making  
>> process. Maybe it's a wording issue. What would be the conditions  
>> to send path computation requests to more than one PCE, aside from  
>> an inter-domain context? I'm not sure I understand why the  
>> response sent by the PCE-PEP back to the requesting PCC-PDP may  
>> indicate *policies*. Unless the document refers to a kind of PCE- 
>> inferred feedback PIB (RFC 3571)? In that case, I would elaborate.
>>
>> 6. Section 3, page 15:
>> The notion of trusted nodes (as introdcued in the third paragraph)  
>> should deserve some elaboration, IMHO. The security considerations  
>> of this page should either be extended (e.g. preservation of the  
>> confidentiality of the information that will be exchanged between  
>> a PDP and a set of PDPs), or reference the "true" Security  
>> Considerations section of the document, which BTW, rightfully  
>> elaborates on such issues.
>>
>> 7. Section 5, page 18:
>> I don't understand why a protocol like COPS couldn't be used in  
>> the case where PEP and PDP are colocated. In any case, a protocol  
>> is required to convey the exchanges between the PEP and the PDP…  
>> In addition (last line of the page), it's very unlikely that SNMP  
>> will be used to retrieve information from a PIB.
>>
>> 8. Section 5, page 19:
>> I would suggest some elaboration on the kind of information any  
>> given PEP (PCC or PCE) may receive from another *PEP* - is this a  
>> typo (i.e. read PDP instead), or does this relate to information  
>> different from "policy-related" information or else? In a COPS  
>> context, multiple Client-Types can certainly reside and coexist  
>> within a PEP, but I'm not sure I understand why PEPs would  
>> exchange information. Also, the following paragraph ("any given  
>> policy…") is a bit confusing to me: I don't understand this notion  
>> of partial interpretation, and would rather suggest another  
>> wording - enforcement instead of interpretation. Besides, I'm not  
>> sure this paragraph helps in understanding the roles played by  
>> PEPs and PDPs.
>>
>> In the first paragraph, I don't understand why the PCE selection  
>> should be static. Even if the policy enforcement is restricted to  
>> the PCE (for path computation purposes), nothing prevents a PEP  
>> embedded in a PCC to support the relevant "Client-Type", hence  
>> yielding the dynamic identification of the corresponding PCE, by  
>> means of the COPS-like OPEN message at PCC bootstrap, for example.  
>> In the third paragraph, the "must" of the first sentence is too  
>> strong, IMHO, unless the sentence means that any kind of policy  
>> must "encouarge" the support of the corresponding "Client-Types"  
>> in the PCC-PEP. If so, I would rephrase.
>>
>> I don't understand why matching repositories would result in a  
>> single PC repository, unless further elaboration on such match is  
>> provided.
>>
>> TED = Traffic Engineering Database? SRLG = Shared Risk Link Group?  
>>> To: <mailto:[email-masked]>[email-masked], Lou Berger  
>>> <<mailto:[email-masked]>[email-masked]>, Igor Bryskin  
>>> <<mailto:[email-masked]>[email-masked]>,  Dimitri  
>>> Papadimitriou  
>>> <<mailto:[email-masked]>[email-masked]>,  JACQUENET  
>>> Christian RD-TCH-REN  
>>> Adrian> OK, but this is not an indefinite consultation. We want  
>>> to be able to move ahead and complete the I-D
>>> relatively soon.
>>>