[Pce] Re: I-D Action: draft-ietf-pce-operational-01.txt

["Andrew Stone (Nokia)" <[e-mail]>]

Hi Adrian, PCE WG

Just rolled over a year later =)  Version -03 has been posted to address mostof the comments below, as well as discussions that were had at IETF 123.

https://datatracker.ietf.org/doc/html/draft-ietf-pce-operational-03

Thanks
Andrew



From: Andrew Stone (Nokia) <[e-mail]>
Date: Wednesday, July 2, 2025 at 1:44 PM
To: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: I-D Action: draft-ietf-pce-operational-01.txt

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 <[e-mail]>
Date: Monday, June 30, 2025 at 2:51 PM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
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: [e-mail] <[e-mail]>
Sent: 30 June 2025 16:07
To: [e-mail]
Cc: [e-mail]
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 ([e-mail]) 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 -- [e-mail]
To unsubscribe send an email to [e-mail]