Hi Dhruv, Please see inline <S>.
Thanks a lot, Samuel From: Dhruv Dhody <[email protected]> Sent: Saturday, November 25, 2023 6:23 AM To: [email protected] Cc: pce-chairs <[email protected]>; [email protected] Subject: In prep for adoption call for draft-sidor-pce-circuit-style-pcep-extensions Hi, Can you please upload a new version of the I-D that tidies up the document in preparation for WG adoption call? - Limit the number of authors to 5 <S> I’ll discuss with existing co-authors and I’ll move some of them to contributors. - Add text to the security consideration section (add references to relevant rfcs if no new security threat is assumed) <S> I’ll add pointers to security considerations from RFC5440, RFC8231, RFC8281 and potential consideration for using best practices from RFC7525. - Think about adding a mangebility consideration <S> I’ll add it. - Instead of saying that the applicability to RSVP-TE and SR-TE better yet say it is applicable to all path setup types! <S> Makes sense, I’ll update it. - I am confused by - "For example Adjacency SIDs MAY be used, but Prefix SIDs MUST NOT be used (even if there is only one adjacency). the PCE MUST use Adjacency SIDs only."; are Adj SID "MAY" or "MUST"?? It should be MUST right? <S> There was discussion between co-authors to allow adjacency SIDs, block prefix SIDs, but still maintain future compatibility for any other SID type if needed, so we wanted to avoid MUST statement. I’ll drop second statement. - What is the way to indicate that a computed path no longer meets the original constraints when the recomputation is blocked? Isn't that something that is useful for operators to know? <S> Operators are notified, but they are notified from PCE (northbound direction) – behavior also depends on flags set in that TLV: - if P flag is cleared, PCE can still re-compute if constraints are not satisfied (I assume that you are not talking about this case) - if P flag is set and F flag is cleared, then operators are notified on PCE and they may decide to trigger manual re-computation on PCE as described in CS SR policy draft<https://www.ietf.org/archive/id/draft-ietf-spring-cs-sr-policy-01.html#name-candidate-path-re-computati> - if P flag is set and F flag is set, then there is no way to update LSP, so assumption is that operator does not want PCE to monitor validity of that path and it relies on liveness detection done by headend (reference<https://www.ietf.org/archive/id/draft-ietf-spring-cs-sr-policy-01.html#name-connectivity-verification>), which is obviously not monitoring some set of constraints. - When the P flag is cleared or the TLV is not present, we fall back to the existing scenario and in which one would assume PCE does the recomputation based on various triggers yet the draft uses "MAY recompute"... could this be a "SHOULD"? <S> Even “SHOULD” is probably not ideal (but I agree that probably better than “MAY” in this case) – I’ll think about it a bit if I can re-phrase it. - Add implementation Status if you have plans of implementations! <S> Sure, I can add it. Thanks! Dhruv
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
