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]
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:[email protected]>[email protected]
https://www1.ietf.org/mailman/listinfo/pce
