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: internet-dra...@ietf.org <internet-dra...@ietf.org>
Sent: 30 June 2025 16:07
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
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 (pce@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/pce/.
Source for this draft and an issue tracker can be found at
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 -- i-d-annou...@ietf.org
To unsubscribe send an email to i-d-announce-le...@ietf.org
_______________________________________________
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org
