Hello Haomain -
Replies inline:
On 9/4/26 9:44 AM, Zhenghaomian wrote:
Hi Robert,
Thank you for your review. We would like to propose some opinions inline before
we update the document.
Please check if these address the comments.
Your conversation should be more with the group than with me. Make sure
the group agrees this is the way to go.
Best wishes,
Haomian
-----邮件原件-----
发件人: Robert Sparks via Datatracker <[email protected]>
发送时间: 2026年8月31日 4:27
收件人: [email protected]
抄送: [email protected]; [email protected]; [email protected]
主题: draft-ietf-pce-flexible-grid-16 ietf last call Genart review
Document: draft-ietf-pce-flexible-grid
Title: PCEP Extension for Flexible Grid Networks
Reviewer: Robert Sparks
Review result: Not Ready
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF
Chair. Please treat these comments just like any other last call comments.
For more information, please see the FAQ at
<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.
Document: draft-ietf-pce-flexible-grid-16
Reviewer: Robert Sparks
Review Date: 2026-08-30
IETF LC End Date: 2026-09-01
IESG Telechat date: Not scheduled for a telechat
Summary: Not ready for publication as a Proposed Standard RFC
It's been awhile since I've tried to load all of PCEP into my head - apologies
if any of this off base.
My primary issue:
The document is currently using the wrong kind of error, claiming "a PathErr MUST be
generated" but what it lays out isn't PCEP - it appears to be taken from RSVP. If
I'm right, addressing this will have quite a bit of impact on what's being asked of IANA,
and will likely change the prose of the discussions of errors enough that deeper review
should wait until after that is addressed.
[Author] This is good catch, but we need to clarify that it's not purely about
error handling, as indicated in section 4.1 it just try to illustrate the
behavior for PCEs that does not support these attributes. Of course the PCE
does not work if the capability and attributes are missing.
After discussion we realized that sending a PathErr is incorrect, and we
propose to remove the improper illustration text - including the following text
in section 4.1 and the whole section 9.9.
TEXT to be REMOVED:
If a PCE does not support the attribute(s), its behavior is specified below:
* S bit clear not supported: a PathErr MUST be generated with the Error Code "Routing
Problem" (24) with error sub-code "Unsupported Frequency Slot Selection Symmetry
value" (TBD3).
* FSA method not supported: a PathErr MUST be generated with the Error Code "Routing
Problem" (24) with error sub-code "Unsupported Frequency Slot Assignment value"
(TBD4).
Ok with me. Be sure to update the IANA considerations accordingly.
Other concerns:
Consider being a bit more descriptive with where in a PCEP PCRep or PCUpd
message the TLV object described in section 5 is intended to occur. I _think_
it's aimed towards hop-by-hop and if so, are length constraints going to be a
problem?
[Author] Section 5 indicated the ERO TLV usage in a per hop manner, referencing
to RFC5440 (it is a typo to ref RFC5420). The encoding is intended to the
RFC7570 hop attributes in section 2.1. Regarding the length, we now have up to
2^16 the length could support 65,535 bytes, to cover the length of link
identifier and allocated spectrum. Given each hop could usually cover a
distance of 80km and the upper bound of value n would normally be +/- 40, a
16-bit length field could be sufficient. BTW we found a wrong reference to
RFC5420, which should be RFC5440.
ok
Why does the document limit frequency slots to >=193.1 THz? That is, why does
section 4.1's discussion of FSA restrict n to be non-negative? RFC7698 does not.
[Author] the value of n could be both positive and negative, including zero,
propose to be:
OLD: All the feasible frequency slots are numbered (based on 'n' parameter),
and this SA method chooses the available frequency slot with the lowest index,
where 'n' is the parameter in f = 193.1 THz + n x 0.00625 THz where 193.1THz is
the ITU-T 'anchor frequency' and 'n' is a positive integer including 0
[RFC7698].
NEW: All the feasible frequency slots are numbered (based on 'n' parameter),
and this SA method chooses the available frequency slot with the lowest index,
where 'n' is the parameter in f = 193.1 THz + n x 0.00625 THz where 193.1THz is
the ITU-T 'anchor frequency' and 'n' is a positive or negative integer
including 0 [RFC7698].
ok (note to the IESG - the verbose "positive or negative integer
including 0" is how RFC7698 said this).
Should these objects be richer in describing the requested slot width? I can
see how a minimum width can be expressed as a constraint, but that's not the
same as a desired width.
[Author] For flexi-grid the slot width is described by value m, as a multiple
of slot width granularity - we could refer to Appendix I of ITU-T G.694.1 as
the usage examples.
Well, my point is that a _desired_ m is not carried anywhere in the
objects sent by the PCC. Am I missing where the protocol you are
specifying here allows that? I see where you can declare a minimum m
constraint, but that's not the same thing.
The text talking about the Count and Link Identifiers fields in section 4.9 reads badly
when the link identifiers are the ends of ranges. Consider being more precise about
"link identifier record" or something similar..
[Author] I assume you are referring to figure 3 in section 4.2 and try to
understand the comments correctly. Do you mean we need to describe Count/Link
Identifiers text according to the action field? Some considerations of
proposals are initiated as follow, please let us know your preference or
correct us if we get you wrong.
OLD:
* Count: The number of the link identifiers (8 bits).
* Reserved: Reserved for future use (16 bits). It MUST be set to zero by the
sender and ignored by the receiver.
* Link Identifiers: Identifies each link ID for which restriction is applied.
The length is dependent on the link format and the Count field. See Section
4.3.1 in [RFC8780] for Link Identifier encoding.
NEW1:
* Count: The number of Link Identifier Records (8 bits).
* Reserved: Reserved for future use (16 bits). It MUST be set to zero by the
sender and ignored by the receiver.
* Link Identifiers: Contains one or more Link Identifier Records. The
interpretation of each record depends on the Action field:
When Action=0 (Inclusive List), each record consists of a single link
identifier.
When Action=1 (Inclusive Range), each record consists of two link
identifiers, indicating the start and end of the range (inclusive).
I would prefer the form of NEW1 with this change:
When Action=1 (Inclusive Range), there are exactly two records,
indicating the start and end of the range (inclusive).
NEW2:
* Count: The number of Link Identifier Records (8 bits).
* Reserved: Reserved for future use (16 bits). It MUST be set to zero by the
sender and ignored by the receiver.
* Link Identifiers: Identifies each link ID for which restriction is applied.
When the Action field indicates an Inclusive Range (Action=1), this field
contains exactly two link identifiers, with the first indicating the start of
the range and the second indicating the end of the range (inclusive). The
length is dependent on the link format and the Count field.
_______________________________________________
Gen-art mailing list -- [email protected]
To unsubscribe send an email to [email protected]
