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

2023-11-24 Thread Dhruv Dhody 
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
- Add text to the security consideration section (add references to
relevant rfcs if no new security threat is assumed)
- Think about adding a mangebility consideration
- Instead of saying that the applicability to RSVP-TE and SR-TE better yet
say it is applicable to all path setup types!
- 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?
- 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?
- 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"?
- Add implementation Status if you have plans of implementations!

Thanks!
Dhruv
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

2023-11-27 Thread Samuel Sidor (ssidor) 
Hi Dhruv,

Please see inline .

Thanks a lot,
Samuel

From: Dhruv Dhody 
Sent: Saturday, November 25, 2023 6:23 AM
To: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org
Cc: pce-chairs ; pce@ietf.org
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
 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)
 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
 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!
 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?
 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?
 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
- 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),
 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"?
 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!
 Sure, I can add it.

Thanks!
Dhruv


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

2023-12-01 Thread Samuel Sidor (ssidor) 
Just to keep mail thread updated.

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

Regards,
Samuel

From: Samuel Sidor (ssidor) 
Sent: Monday, November 27, 2023 10:27 AM
To: Dhruv Dhody ; 
draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org
Cc: pce-chairs ; pce@ietf.org
Subject: RE: In prep for adoption call for 
draft-sidor-pce-circuit-style-pcep-extensions

Hi Dhruv,

Please see inline .

Thanks a lot,
Samuel

From: Dhruv Dhody mailto:d...@dhruvdhody.com>>
Sent: Saturday, November 25, 2023 6:23 AM
To: 
draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org
Cc: pce-chairs mailto:pce-cha...@ietf.org>>; 
pce@ietf.org
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
 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)
 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
 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!
 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?
 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?
 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
- 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),
 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"?
 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!
 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
Pce@ietf.org
https://www.ietf.org/