Adrian,
Thanks for the thorough review. Apologies for the delayed reply. Version 09 of the draft should address most of your comments/concerns.
Please see inline responses below (prefixed VPB) for your comments.
Regards,
-Pavan (on behalf of the authors)
Thanks for the thorough review. Apologies for the delayed reply. Version 09 of the draft should address most of your comments/concerns.
Please see inline responses below (prefixed VPB) for your comments.
Regards,
-Pavan (on behalf of the authors)
On Fri, Jan 31, 2025 at 7:35 AM Adrian Farrel via Datatracker <noreply@xxxxxxxx> wrote:
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.
[VPB] The draft uses a generic PCEP TLV (and has since the document's inception) to associate an intent or objective (color) with a TE tunnel. Given that the document has reached this stage, it is safe to assume that there was consensus in the WG to use this TLV. AFAIK there was no discussion or debate during the WG process on whether the draft could have used an alternative encoding mechanism.
---
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.
[VPB] In version 09 of the document, the "SHOULD NOT" in Section 2 has been replaced with "MUST NOT". Please note that an implementation of [I-D.ietf-pce-segment-routing-policy-cp], which is oblivious to this document, will not be using the Color TLV.
---
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.
[VPB] This is addressed in version 09 of the document. The suggested change has been adopted.
= 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.
[VPB] This is addressed in version 09 of the document. The note to the editor in this section has been removed.
---
[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.
[VPB] This is addressed in version 09 of the document. The reference has been upgraded.
---
3.1 and 3.2
Remove the text saying "early allocation by IANA". This should not be
left in the final RFC.
[VPB] This is addressed in version 09 of the document.
= Nits =
Title
s/Protocol(PCEP)/Protocol (PCEP)/
[VPB] This is addressed in version 09 of the document.
---
1.
s/setup using/set up using/ (twice)
[VPB] This is addressed in version 09 of the document.
_______________________________________________
Pce mailing list -- pce@xxxxxxxx
To unsubscribe send an email to pce-leave@xxxxxxxx
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
