Hi Andrew, Thanks for taking the time to review and sending us your comments. We missed this one in the previous update and just addressed them as follow:
1. On the S Flag text, you are right that the original reference to RFC 5440 was too vague. Bidirectionality is indicated by the B (Bi-directional) flag in the RP Object, so the text now points explicitly to Section 7.4.1 of RFC 5440. For clarity, the update would be: S (Symmetry, 1 bit): This flag is only meaningful when the request is for a bidirectional LSP, i.e., when the B (Bi-directional) flag is set in the RP Object (see Section 7.4.1 of [RFC5440]). 2. On the error handling point, we agree that "insufficient memory" is not RSA-specific and overlaps with the existing PCEP overload mechanism in RFC 5440 Section 7.15. Let’s remove the RSA-specific error case, keep "Error-Type TBD7" scoped to RSA-specific conditions, and clarify that generic resource exhaustion at the PCE is handled via the overload mechanism rather than this "Error-Type". These changes are reflected in the new (-14) version which was just posted. Best wishes, Haomian 发件人: Andrew Stone (Nokia) <[email protected]> 发送时间: 2025年5月8日 3:27 收件人: [email protected]; [email protected] 主题: [Pce] Re: WG Last Call for draft-ietf-pce-flexible-grid Hi authors, PCE WG I did a read through of the document – keep in mind I'm absolutely not an optical person and have very limited knowledge in optics therefore much of the content and use case flew over my head so I can't judge on its accuracy/correctness/usefulness 😊 With that said, the overall document structure is well written and the PCEP protocol extension encoding itself and some expectations on PCE are clear. Two questions/comments: Section 4.1 mentions S Flag for Symmetry " This flag is only meaningful when the request is for a bidirectional LSP " and references RFC5440 - but RFC5440 doesn't actually use the terms symmetry/symmetrical, or bidirectional. Therefore, I assume this is trying to reference Synchronized Path Requests / SVEC. If so, it might be worth explicitly mentioning see section 7.13 in RFC5440? Regarding Error-Type TBD7:1 -> insufficient memory - is this related to the memory of the PCE itself? This feels like more of a generic PCEP kind of error rather than anything to do with flexi grid-based computations? I guess I'm wondering what value this is to RSA requests, and, also whether a PCE would implement or be capable of responding to PCReq with errors if it has insufficient memory. At that point it should go into overload state instead which implicitly signals to the PCC to stop sending PcReq? i.e is this useful? and if so, should it be scoped within RSA error codes? Or should the implementation just go to overload and drop incoming PcReq which achieves the same? Thanks Andrew From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Date: Wednesday, April 23, 2025 at 5:02 AM To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: [Pce] WG Last Call for draft-ietf-pce-flexible-grid Hi all, This email starts a 2-week WG last call for draft-ietf-pce-flexible-grid-11 [1]. Please review and share your comments using the PCE mailing list. Even a short feedback will be appreciated. This WGLC will end on Wednesday 7th May 2025. Thanks, Dhruv & Julien -- [1] https://datatracker.ietf.org/doc/draft-ietf-pce-flexible-grid/
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
