Hi Sergio, Thanks for your review. I have updated it.
The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-ls/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-pce-pcep-ls-05.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-pcep-ls-05 On Wed, Feb 25, 2026 at 5:17 PM Sergio Belotti via Datatracker < [email protected]> wrote: > 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 . > > Dhruv: I removed the word itself. > 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 > ? > > Dhruv: Changed to "abstract link" and added reference. > 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” > > Dhruv: Ack > 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. > > Dhruv: The phrasing is in sync with the text in RFC 8231. I rephrased it slightly. > 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)" > > Dhruv: Ack > 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." > > Dhruv: Updated > 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] > > Dhruv: Changed the table! > 8) Beginning of Section 9.3.9.1, > > Node Attribute is a TLV. > s/”This is an optional attribute”/ "This is an optional TLV" > > Dhruv: Ack > 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. > > Dhruv: Added "A sub-TLV with a non-zero length indicates that the attribute is being added or updated with the new value." > 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? > > Dhruv: Added "This implies that the PCEP-LS speaker may advertise distinct abstracted topology views per peer, and the PCEP mechanisms defined in this document (including the association of LS information with a specific Virtual Network construct) enable correct identification and separation of such views." > 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. > > Dhruv: Neighbor is only used in the context of LS to refer to a link neighbor. Peer is used in the context of PCEP. > 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. > > Dhruv: Ack > 13) Section 13.3 1st paragraph > > s/to manage the Flag field/to manage the Protocol-ID field > > Dhruv: Ack > 14) Section 14, figure 4 > > s/3.2.1.2/5.2.1.2 and > s/3.2.1.3/5.2.1.3 > > Dhruv: Thanks! Also updated the draft names to RFC! > 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. > > Dhruv: Ack > --- > > ## Nits > > 1) Section 3, 4th bullet > > s/for Provisioning Network Controller (PNC)/from Provisioning Network > Controller (PNC) > > Dhruv: Ack > 2) In section 6.3, 5th paragraph > > s/properly/not properly > > Dhruv: The use of properly is correct as it is saying that there is no Ack messages for successful LSRpt but if there is an error and error message is sent. > 3) Section 9.3.1 > > s/belongs/belongs to > > Dhruv: I rephrased it! Thanks! Dhruv > --- > > >
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
