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.
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 PROTECTED]
Envoyé : lundi 8 octobre 2007 22:36
À : [EMAIL PROTECTED]; Lou Berger; Igor Bryskin;
Dimitri Papadimitriou; [EMAIL PROTECTED]
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:[EMAIL PROTECTED]>[EMAIL PROTECTED]>
Date: September 18, 2007 2:10:12 PM EDT
To: <mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED], Lou
Berger
<<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]>,
Igor Bryskin
<<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]>,
Dimitri Papadimitriou
<<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]>,
<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]
Cc: Thomas Walsh
<<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]>,
JACQUENET Christian RD-TCH-REN
<<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]>
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:[email protected]>[email protected]
https://www1.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
