Re: [Pce] In prep for adoption call for draft-sidor-pce-circuit-style-pcep-extensions

["Samuel Sidor (ssidor)" <[e-mail]>]

Just to keep mail thread updated.

New version submitted (and thanks again for your comments Dhruv).

Regards,
Samuel

From: Samuel Sidor (ssidor) <[e-mail]>
Sent: Monday, November 27, 2023 10:27 AM
To: Dhruv Dhody <[e-mail]>; [e-mail]
Cc: pce-chairs <[e-mail]>; [e-mail]
Subject: RE: In prep for adoption call for draft-sidor-pce-circuit-style-pcep-extensions

Hi Dhruv,

Please see inline <S>.

Thanks a lot,
Samuel

From: Dhruv Dhody <[e-mail]<mailto:[e-mail]>>
Sent: Saturday, November 25, 2023 6:23 AM
To: [e-mail]<mailto:[e-mail]>
Cc: pce-chairs <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
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

--- Begin Message ---

A new version of Internet-Draft
draft-sidor-pce-circuit-style-pcep-extensions-05.txt has been successfully
submitted by Samuel Sidor and posted to the
IETF repository.

Name:     draft-sidor-pce-circuit-style-pcep-extensions
Revision: 05
Title:    PCEP extensions for Circuit Style Policies
Date:     2023-12-01
Group:    Individual Submission
Pages:    12
URL:      https://www.ietf.org/archive/id/draft-sidor-pce-circuit-style-pcep-extensions-05.txt
Status:   https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/
HTML:     https://www.ietf.org/archive/id/draft-sidor-pce-circuit-style-pcep-extensions-05.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-sidor-pce-circuit-style-pcep-extensions
Diff:     https://author-tools.ietf.org/iddiff?url2=draft-sidor-pce-circuit-style-pcep-extensions-05

Abstract:

   This document proposes a set of extensions for Path Computation
   Element Communication Protocol (PCEP) for Circuit Style Policies -
   Segment-Routing Policy designed to satisfy requirements for
   connection-oriented transport services.  New TLV is introduced to
   control path recomputation and new flag to add ability to request
   path with strict hops only.



The IETF Secretariat

--- End Message ---