Document: draft-ietf-pce-pcep-ls Title: PCEP extensions for Distribution of Link-State and TE Information Reviewer: Sergio Belotti Review result: Has Nits
Hi, I have been selected as the Operational Directorate (opsdir) reviewer for this Internet-Draft. The Operational Directorate reviews all operational and management-related Internet-Drafts to ensure alignment with operational best practices and that adequate operational considerations are covered. A complete set of _"Guidelines for Considering Operations and Management in IETF Specifications"_ can be found at https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/. While these comments are primarily for the Operations and Management Area Directors (Ops ADs), the authors should consider them alongside other feedback received. - Document: [draft-ietf-pce-pcep-ls-04] - Reviewer: [Sergio Belotti] - Review Date: [02-25-2026] - Intended Status: [Experimental] ## Summary Choose one: - Has Nits: This document is basically ready for publication but has nits that should be considered prior to publication. ## General Operational Comments Alignment with RFC 5706bis Provide an overview of the draft’s operational feasibility, readability, and alignment with RFC5706bis guidelines. Example: This document defines an extension to PCEP protocol (RFC 5440) to support link-state and Traffic Engineering (TE) information distribution using PCEP protocol, including also a mechanisms for the PCE speakers to exchange information about their capabilities in support of this PCEP extension. This document is designated as "experimental" with the purpose to collect more information about deployment and implementation of PCEP used for LS and TE topology information before attempting to standardize the mechanism. For this reason I would say that the operational feasibility are well covered. Since the document presents an extension of PCEP protocol the readability of the document is compromised by the need to refer other document or RFC related to PCEP protocol. In my review I tried to concentrate the effort to this specific document, avoiding checking directly other document and taking many times as trusted the various references to other RFC mentioned. Due to his original nature of "protocol extension" the document does not follow explicitly RFC5706bis guidelines, since many basic sections described in the guideline are already present in the base PCEP RFCs, e.g. manageability considerations in RFC 5440, ## Major Issues No major issues found ## Minor Issues These comments are mainly editorial and sometimes with the purpose to request clarification to help make the text more clear in certain part of I-D. 1) Section 1, 1st paragraph I can understand what "circuit" is but maybe a definition in the terminology section would be better . 2) Section 1 There is the sentence " The mechanism is applicable to physical and virtual links as well as further subjected to various policies." Not clear the meaning here of "as well as further subjected to various policies". Need to be clarified. Moreover it is used the term "virtual link" . Do you really mean virtual link or abstract link as defined in RFC 7926? Is it possible to add a reference for this term that we know very well e.g. in ACTN. Maybe RFC9731 ? 3) Section 1.1.1 "The experiment will end three years after the RFC is published " If my understanding is correct , the RFC will be published as Experimental. If yes, I would specify in the sentence the type of published document. C/”RFC is published”/”RFC is published as Experimental” 4) Section 6.3, at the beginning "The purpose of LS Synchronization is to provide a checkpoint-in-time state replica of a PCC's link-state (and TE) database in a PCE" Not clear for me the the two first lines in section 6.3. Not essential for me since the description of LS Synchronization is in the second paragraph. I would delete these two sentences unless a rewording is done. 5) Section 9.2.1 I would reword a bit: "The value comprises a single field for flags with only 1 flag defined (32 bits)" 6) Section 9.3.3 Not sure it is needed all the introduction related to ACTN. Moreover is mentioned "ietf-teas-actn-requirements" that is a draft no more active. Proposed taxt : "Following requirement contained in RFC 8453 and RFC 8454 there is a need for associating the abstracted link-state and TE topology with a VN "construct" to facilitate VN operations in PCE architecture." 7) Section 9.3.6 at the bottom Following what stated in the last sentence “length and value fields are as per [RFC8232]”, I would also modify the Length field as the Value field : s/variable/[RFC8232] 8) Beginning of Section 9.3.9.1, Node Attribute is a TLV. s/”This is an optional attribute”/ "This is an optional TLV" 9) Section 9.3.10 the sentence “An absence of a sub-TLV that was included earlier MUST be interpreted as no change.”.When something has to be considered a change ? It would help readers to add a sentence about that to clarify the alternative case. 10) Section 12.1, 4th paragraph what is the implication of this requirement related to this PCEP extension? For example we can interpretate the requirement as the possibility for a customer to "create" a virtual network with a certain level of abstraction (as described in RFC 8453) but not clear why this requirement can imply something for this document. Is it possible to add a sentence to make that understandable? 11) Section 12.2 Is there a difference between peer and neighbor? Since the terminology section is not provided in this document, I have difficult to distinguish the two terms. In my view for specific case like this the definition of the two terms should be added in the terminology. That would not prevent to go on referring for most of the terms definition to RFC 5440 and RFC 4655. 12) Section 12.2, last paragraph the requirement is to limit inbound LSRpt right? What is the difference between the policy to limit inbound LSRpt and the mentioned “means” again to limit inbound LSRpts ? It seems to me a repetition. 13) Section 13.3 1st paragraph s/to manage the Flag field/to manage the Protocol-ID field 14) Section 14, figure 4 s/3.2.1.2/5.2.1.2 and s/3.2.1.3/5.2.1.3 15) Appendix A.1 There are misalignments between the figure and the text: In the figure the IPv4 interface should be 192.0.2.1/24 per RTA and 192.0.2.2/24 per RTB RTB IGP Router-ID should be 22.22.22.22 as described in the example. --- ## Nits 1) Section 3, 4th bullet s/for Provisioning Network Controller (PNC)/from Provisioning Network Controller (PNC) 2) In section 6.3, 5th paragraph s/properly/not properly 3) Section 9.3.1 s/belongs/belongs to --- _______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
