[Gen-art] Re: 回复: draft-ietf-pce-flexible-grid-16 ietf last call Genart review

[Robert Sparks <[e-mail]>]

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 <[e-mail]>
> 发送时间: 2026年8月31日 4:27
> 收件人: [e-mail]
> 抄送: [e-mail]; [e-mail]; [e-mail]
> 主题: 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.
>
>