Just to keep mail thread updated.
New version submitted (and thanks again for your comments Dhruv).
Regards,
Samuel
From: Samuel Sidor (ssidor) <[email protected]>
Sent: Monday, November 27, 2023 10:27 AM
To: Dhruv Dhody <[email protected]>;
[email protected]
Cc: pce-chairs <[email protected]>; [email protected]
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 <[email protected]<mailto:[email protected]>>
Sent: Saturday, November 25, 2023 6:23 AM
To:
[email protected]<mailto:[email protected]>
Cc: pce-chairs <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[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
--- 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 ---
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
