Hi Adrian, Just wanted to acknowledge receiving this – thanks for taking the time to review on this. Will address most of your comments in the next update.
Regarding Section 7 / overload and keep sending PcRpt -> certainly a valid concern. There is (CPU/Memory) cost in fully reprocessing a flood of PcRpt and thus could be a potential reason for being overloaded or at least adding to it. However, there is a trade-off to this because the longer PCE goes without knowing the latest state of the network the more inaccurate decisions it could be making. As well, the implementation of what it means to be overloaded can differ. For example, an implementation may have dedicated resources to deal with reports and dedicated resources to deal with compute. Perhaps it’s simply dealing with computations that has it overloaded, but no problem ingesting reports. Or perhaps it wants to be in sync with the network but not actively participating yet in calculation – a form of bootstrapping an instance without active participation. Additionally, as you described, if the PCC does decide to throttle PcRpts, under which conditions is a PcRpt significant or not? I would say it cannot depend just on local policy because, for example, a PCC should still send a PcRpt in response to a PcUpd since a PCE could be marked overloaded but still taking actions if a path is still delegated (or even doing a new PCE-Initiated path). We would need to list out some specifics here, I think. Additional administrative concern: RFC5440 indicates that no other “requests” should be sent. Report is not a request, so the text saying reports are still sent is not modifying or introducing new text. If we decide to broaden the statement to say “no other requests or reports should be sent” then this is likely considered an update to RFC5440 rather than clarification. If we need to expand what should be done, perhaps should cover that in the amendment document. Open for more discussion and hopefully some others on the list can add in and we can discuss in Madrid. Thanks! Andrew From: Adrian Farrel <[email protected]> Date: Monday, June 30, 2025 at 2:51 PM To: [email protected] <[email protected]> Cc: [email protected] <[email protected]> Subject: RE: I-D Action: draft-ietf-pce-operational-01.txt CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi authors, Thanks for continuing to work on this document. Here are some minor comments. And one larger concern on Section 7. Cheers, Adrian === Your I-D has 6 front-page authors. The chairs can work with you on this, but 5 is the usual upper limit. Maybe, as this is an interop document, you could reduce to just one author from each implementation? --- Abstract. Could "PCEP protocol" be abbreviated to "PCEPP" ? ;-) --- As this document is projected as Informational, I wonder whether the Abstract could give some clues about what is going on. Something like... This document does not make any updates or revisions to any PCEP specifications, but provides additional information to aid in the interpretation of those documents. Add something similar to the Introduction. --- Section 1 Due to different interpretations of PCEP standards I think you should include a list of references at this point. --- Section 2 You don't use any BCP 14 key words. You can remove this section and the references. --- Section 3 Either s/terminologies are/terminology is/ Or s/terminologies are/terms are/ --- Section 3 Where these are terms we are familiar with, ae there any differences? If so, I think you should call out those differences. If not (probably the case), you can simply point at the defining document. For example, OLD PCC: Path Computation Client. Any client application requesting a path computation to be performed by a Path Computation Element. NEW PCC: Path Computation Client [RFC4655]. END --- Section 3 ERO is a good example of where you have additional information specific to this document. In your text, I think you should call out an absent ERO as a third think and say (trivially) that it is indicated by showing no ERO. This is important because there is a difference between an absent and an empty ERO. --- Section 3 It is not clear from the definition whether a PCRPT-LSP-DB contains LSPs reported by the speaker that holds the DB, or reported to that speaker (or the sum of both). 4.2 explains "both the PCE and PCC maintain their own local copies of the PCRPT-LSP-DB" which may explain this (or not). Presumably, the PCE's DB contains state from all reporting PCCs. But the PCC only carries state for the LSPs for which it serves as head end. --- Section 3 For EXTENDED-LSP-DB I note that you say that this DB is used to capture information related to *a* Label Switched Path. Are there multiple of these data stores or, as hinted by the use of a key, one DB holding information related to multiple LSPs? Which LSPs are included and which not? Is there a difference between "an implementation-specific logical datastore" and a "logical datastore"? I suspect what you are trying to say is that some implementations may implement an EXTENDED-LSP-DB, but that it is not strictly necessary in a PCEP implementation. Does this DB exist on a PCE or a PCC or both? --- Section 4 I appreciate what you have done wrt "LSP". However... Alternatively, the term "LSP" could be replaced with "Instance" ...is not good because you have to have an instance of a thing. --- 4.1 The PCRPT-LSP-DB contains two types of information: LSPs and Tunnels. You might have said this when defining the DB in section 3 --- 4.1 A Tunnel may or may not correspond to an actual tunnel on the router. While the example is useful, I think your top-level statement is likely to cause confusion. Are the things represented by the PLSP-IDs not also on the router? What, of course, is going on is that there is a layering (or sub-layering) of networks so that a "tunnel" (the "actual tunnel on the router") is the thing into which data is inserted by the client layer. But that tunnel may be supported by one or more tunnels at the underlying (MPLS, for example) network layer. I do understand why it is necessary to make a clarification if people are confused by the use of the word "tunnel", and clarification by example is not a bad thing, but your introductory statement is just a little odd. --- 4.2 para 2 has some non-ASCII characters 4.3 para 1 has some non-ASCII characters --- 4.2 It is important to note that the PCRPT-LSP-DB reflects only the live view of the network Of course, there are two convergence windows: 1. The network state has changed, but the PCC hasn't yet updated its PCRPT-LSP-DB 2. The PCC has updated its PCRPT-LSP-DB, but the state update has not found its way into the PCE's PCRPT-LSP-DB So the PCRPT-LSP-DB doesn't necessarily reflect the live view of the network. --- 4.3.1 and 4.3.2 All of the figures show "Content of LSP DB". Shouldn't that be "Content of PCRPT-LSP-DB"? The text should reference the figures explicitly. --- Section 5. s/instantiate/instantiation/ ---- Section 5. Shouldn't "PCE ASSO DB" be hyphenated like the other two DBs? Shouldn't this DB be described in Section 3. --- Sections 4 and 5 Is it clear to all readers what all of the message parameters are? For example, ASSO_R_FLAG --- 5.1 and 5.2 Each paragraph that starts s/PCC/The PCC/ --- 5.1 and 5.2 The text should reference the figures explicitly. --- 5.1 s/PcRpt/PCRpt/ --- 6. s/PcRpt/PCRpt/ thrice --- 7. s/PcReq/PCReq/ s/PcRpt/PCRpt/ --- 7. This may be a big one! The PCE will continue to send PcRpt messages to PCE even though it may indicate it is overloaded, otherwise the the PCRPT-LSP-DB on PCE may go out of sync. s/The PCE/The PCC/ s/PcRpt/PCRpt/ s/to PCE/to the PCE/ s/the the/the/ The issue here is that the PCC knows that the PCE is overloaded. It cannot handle performing and path computations (including update computations for existing LSPs), and the processing of update PCRpt messages could be more computationally significant than an initial path computation. So this paragraph says, because the PCE/PCC may get out of synch (which they do for a small window, anyway), the PCC must conspire to continue to overload the PCE. Surely, if the update is small, the PCC can choose to hold off (e.g., threshold) the update. And since this is a subjective choice, I think you should have... If the PCE indicates it is congested, the PCE may make a local decision about whether to immediately send a PCRpt message to PCE or may hold that message to send when the PCE indicates it is no longer congested. This decision may depend on local policy about how significant the change to the LSP is, how long the message has been held, and how many other messages are held for the same reason. In any case, the PCC should log the situation (applying thresholding to the rate of generation of log events) so that an operator can determine what is happening. --- Section 8. That's a bit worrying! What are the security implications of not resolving the misunderstanding that you have described? --- Section 9. Given the name of the document, this section should probably not be empty. Apart from the logging that I introduced for Section 7, I think you need to discuss the ability for an operator to read the three logical DBs you have described. They sound like classic YANG data models. How does a PCC and PCE (or an operator) verify that their DBs are synched? You may find draft-opsarea-rfc5706bis gives useful guidance, or you could look back at RFC 6123. -----Original Message----- From: [email protected] <[email protected]> Sent: 30 June 2025 16:07 To: [email protected] Cc: [email protected] Subject: I-D Action: draft-ietf-pce-operational-01.txt Internet-Draft draft-ietf-pce-operational-01.txt is now available. It is a work item of the Path Computation Element (PCE) WG of the IETF. Title: PCEP Operational Clarification Authors: Mike Koldychev Siva Sivabalan Shuping Peng Diego Achaval Hari Kotni Andrew Stone Name: draft-ietf-pce-operational-01.txt Pages: 13 Dates: 2025-06-30 Abstract: This document clarifies certain operational behavior aspects of the PCEP protocol. The content of this document has been compiled based on several interop exercises. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Path Computation Element mailing list ([email protected]), which is archived at https://mailarchive.ietf.org/arch/browse/pce/. Source for this draft and an issue tracker can be found at https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-wg-pce%2Fdraft-ietf-pce-operational&data=05%7C02%7Candrew.stone%40nokia.com%7C7fa7d83e02494c4e905f08ddb8070a4c%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638869062618052098%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=VaqbPOABtLDdeQGCrLVLf5S0othXw3JAZcnin9oRsQw%3D&reserved=0<https://github.com/ietf-wg-pce/draft-ietf-pce-operational>. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-operational/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-pce-operational-01.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-operational-01 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts _______________________________________________ I-D-Announce mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
