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 PROTECTED]>
To: "JP Vasseur" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Lou Berger"
<[EMAIL PROTECTED]>; "Igor Bryskin" <[EMAIL PROTECTED]>; "Dimitri
Papadimitriou" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: "Thomas Walsh" <[EMAIL PROTECTED]>
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.
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 <[EMAIL PROTECTED]>
Date: September 18, 2007 2:10:12 PM EDT
To: [EMAIL PROTECTED], Lou Berger <[EMAIL PROTECTED]>, Igor Bryskin
<[EMAIL PROTECTED]>, Dimitri Papadimitriou <[EMAIL PROTECTED]>,
[EMAIL PROTECTED]
Cc: Thomas Walsh <[EMAIL PROTECTED]>, JACQUENET Christian RD-TCH-REN
<[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
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
