Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05

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

Hi Quan,

(sorry I sent it before finishing mail)

Originally we listed explicitly only RSVP-TE and SR-TE and then we modified based on comments from Dhruv to all setup types (attached mail).

Extensions covered in this draft were introduced to support required extensions for CS policies, but at least some of those extensions (if specific section is not describing something else) is potentially applicable to other setup types. E.g. extensions from section 3.2 for blocking re-computation.

We can still drop that specific statement and explicitly describe for each extension whether it is generic or applicable to specific setup type only. Would that work for you?

Thanks,
Samuel

From: Samuel Sidor (ssidor)
Sent: Thursday, December 14, 2023 9:24 AM
To: [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: RE: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05

Hi Quan,

Originally we explicitly listed

From: Pce <[e-mail]<mailto:[e-mail]>> On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Thursday, December 14, 2023 7:53 AM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05


Hi Dhruv,



I support the adoption of this draft. Thanks for the work from authors.

But I am confused about section 1 "PCEP extensions described in this document are applicable to all Path   Setup Types".

This draft mainly focus on the Circuit Style Policies and SR policy but path setup types include RSVP-TE,SR,PCECC,SRv6, Native IP TE path  and the newly adopted BIER-TE.

I suggest that it is better to provide clarification about other path setup types or remove this sentence.



Thanks,

Quan



<<Hi WG,



<<This email begins the WG adoption poll for

<<draft-sidor-pce-circuit-style-pcep-extensions-05.https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/Should this draft be adopted by the PCE <<WG? Please state your reasons - Why

<</ Why not? What needs to be fixed before or after adoption? Are you willing

<<to work on this draft? Review comments should be posted to the list.



<<Please respond by Friday 15th Dec 2023.



<<Please be more vocal during WG polls!



<<Thanks!

<<Dhruv & Julien

--- Begin Message ---

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

--- End Message ---