Hi Authors, WG, IETF Last Call has concluded for this document. Although Adrian only used the “has issues” result for his review and not “serious issues”, and although he hasn’t indicated “not ready” [1], I’m concerned that he’s raised some substantive points that have gone unanswered for over a week. I don’t insist that the issues be fully resolved before I issue the IESG ballot for this document, but I’d like to see some progress toward acknowledging and discussing Adrian’s concerns. Thanks, —John [1] But he hasn't indicated “ready” either! > On Jan 31, 2025, at 10:34 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. > > --- > > 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
