Reviewer: Adrian Farrel
Review result: Has Issues
Hello,
I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written with the intent of improving the operational
aspects of the IETF drafts. Comments that are not addressed in last call
may be included in AD reviews during the IESG review. Document editors
and WG chairs should treat these comments just like any other last call
comments.
Regards,
Adrian
===
Reviewer: Adrian Farrel
Draft reviewed: draft-ietf-pce-pcep-color-08
Review Result: Has Issues
The Path Computation Element Protocol (PCEP) is used between a Path
Computation Element (PCE) and a Path Computation Client (PCC) to
provide paths that may be established or used within the network. The
protocol is both request-response (allowing a PCC to ask a PCE to
determine a path for the PCC to use) and a configuration substitute
where a PCE is "in charge" and instruct the PCC which paths to use.
This document allows a "color" to be assigned to a path in the network
so that the head-end of that path may apply a configured policy to steer
traffic to that path. The color is indicated by the PCE when it supplies
the path to the PCC.
This is a very short and simple document.
= Management Considerations =
The PCE working group produced recommendations to guide the inclusion of
manageability considerations sections in documents that it produces.
Those recommendations made a positive difference to the quality of the
RFCs published via the working group. With the publication of RFC 5706,
the PCE working group published RFC 6123 to capture a historic record of
its recommendations, and delegate the responsiblity for specifying the
need for manageability considerations to RFC 5706. Nevertheless, it is
disappointing that this document breaks with the common practice in the
PCE working group to consider the manageability of protocol extensions.
This document allows a PCE to assign a color to the path that it
supplies to the PCC so that the PCC may determine how/whether to place
traffic on the path. This assumes that policies are configured at the
PCC to give meaning to the different colors. However, there is no
discussion of how that policy is configured. This would appear to be a
deficiency. While the document is OK to say...
The mechanism used at the PCC for appropriately mapping services onto
a TE path that is tagged with a color attribute is outside the scope
of this document.
...discussion of the manageability and diagnostic features (or at least
requirements) is needed in order that an implementation of this document
has any value.
Furthermore, an external management station is unable to ask the PCC
what color-based policies it has in place in order that it may verify
correct operation and synchronise the meaning of the colors with the
PCE.
= Technical Issues =
RFC 9168 defines how to associate "Flow Specs" with paths supplied by a
PCE. This allows the PCC to understand how to classify traffic and
determine on which path the traffic should be sent. It seems, from a
high level, that the color attribute defined in this document is "just"
another policy attribute that helps the PCC classify traffic. It is not
clear, therefore, why it was decided to specify a new PCEP extension
rather than extend the process defined in RFC 9168.
---
Section 1 says that the mechanisms introduced in this document "are not
to be used" when the extensions defined in [I-D.ietf-pce-segment-
routing-policy-cp] are used. But Section 2 only says "SHOULD NOT". This
is inconsistent. Furthermore, there is no explanation of why an
implementation MAY choose to use them given that the next sentence says
that an implementation of [I-D.ietf-pce-segment-routing-policy-cp] must
ignore them.
I am also a little bothered that this specification seems to be trying
to dictate how an implementation of another specification will behave.
---
3.1 has
C-bit (Bit 20 - Early allocation by IANA): A PCE/PCC that supports
color capability must turn on this bit.
That would probably be "MUST", but you could better say...
C-bit (Bit 20 - Early allocation by IANA): A PCE/PCC indicates
that it supports the color capability defined in this document by
setting this bit.
= Editorial =
Section 5.4 deprecates an early allocation made in the PCE registry. It
is, of course, regrettable that the stability promised at the time of the
early allocation turned out to not be the case, and that (according to
the implementation section - for which thank you) there was no need for
early allocation to be made.
The section asks the RFC Editor to delete the whole section. I think
this is a poor idea because we will lose the record of why the
deprecation was made and the registry entry (pointing back to this
document as an RFC) will not be of any help. I recommend that the
section is retained.
---
[I-D.ietf-pce-segment-routing-policy-cp] is referenced normatively in
Section 1 (as it says that an implementation of this document needs to
be aware of that document in order to not use the extensions defined in
this document in circumstances described in the other document). So the
reference needs to be upgraded.
---
3.1 and 3.2
Remove the text saying "early allocation by IANA". This should not be
left in the final RFC.
= Nits =
Title
s/Protocol(PCEP)/Protocol (PCEP)/
---
1.
s/setup using/set up using/ (twice)
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
