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

[JP Vasseur <[e-mail]>]

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.

>
> 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.
>>
>> 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:[e-mail]]
>> Envoyé : lundi 8 octobre 2007 22:36
>> À : [e-mail]; Lou Berger; Igor Bryskin; Dimitri Papadimitriou;  
>> [e-mail]
>> 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 <<mailto:[e-mail]>[e-mail]>
>>> Date: September 18, 2007 2:10:12 PM EDT
>>> To: <mailto:[e-mail]>[e-mail], Lou Berger  
>>> <<mailto:[e-mail]>[e-mail]>, Igor Bryskin  
>>> <<mailto:[e-mail]>[e-mail]>,  Dimitri  
>>> Papadimitriou  
>>> <<mailto:[e-mail]>[e-mail]>,  
>>> <mailto:[e-mail]>[e-mail]
>>> Cc: Thomas Walsh  
>>> <<mailto:[e-mail]>[e-mail]>,  JACQUENET  
>>> Christian RD-TCH-REN  
>>> <<mailto:[e-mail]>christian.jacquenet@f 
>>> rancetelecom.com>
>>> 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
>>> <mailto:[e-mail]>[e-mail]
>>> https://www1.ietf.org/mailman/listinfo/pce


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