Hi authors, I support adoption of this document.
A few comments/questions: * Is there reason to limit applicability of that draft to SR-MPLS/SRv6 (e.g. in Section 3.2)? I can imagine that for example BSID allocation may be applicable to RSVP-TE LSPs as well * Is it really good idea to use TLVs in Open message to exchange ID space? * There is no capability advertised before that TLV is included (and there is no way to do it since Open message is 1st message sent in that PCEP session), so when PCC is including it, it does not know whether PCE can support it or not. If PCE is responding with Keepalive message, it can mean 2 things with no simple way to figure out which of them occurred: * ID space control procedure was successful * PCE does not support that TLV and ignored it completely * If any of those ranges has changed, then PCEP session flap will be required (I assume that those are changing often, so this may be acceptable). If any other PCEP message is used, which can be sent on already established PCEP session, then it can be modified without requiring PCEP session flap. Maybe consider using PCNtf or some completely new PCEP message and in such case you can even use explicit capability to indicate whether PCEP extensions from this draft are supported or not * Does it make sense to define some sub-type of delegated space? For example, if PCC included 3 ranges in “LABEL-CONTROL-SPACE TLV”, then there can be some registry of types to specify that 1st range is for BSID, 2nd one for SRGB or SRLB,… How PCE should know which range is supposed to be used for what purpose? (I can imagine that for SRGB, SRLB, it can be derived from complete SRGB/SRLB range learned from IGP, but such approach probably cannot be used for all ranges). * Maybe consider renaming “Block” field in “LABEL-CONTROL-SPACE TLV” to something like “Number of blocks” (see for example PST capability TLV in https://www.rfc-editor.org/rfc/rfc8408.html#section-3) or even potentially drop that field completely as number of ranges can be derived from TLV length * In section 6, you pointed out that synchronization mechanism should be used if same label ranges were allocated for multiple PCEs, but it would be good to specify details how state-sync will solve synchronization issue (if PCC is connected to both PCEs, then both PCEs should see already allocated labels from PCRpt messages directly from PCC) * One small type in section 1 “This documnet adds t…”” Thanks, Samuel From: Dhruv Dhody <d...@dhruvdhody.com> Sent: Friday, May 17, 2024 1:10 PM To: pce@ietf.org Cc: pce-chairs <pce-cha...@ietf.org>; draft-li-pce-controlled-id-sp...@ietf.org Subject: [Pce] WG Adoption of draft-li-pce-controlled-id-space-16 Hi WG, This email begins the WG adoption poll for draft-li-pce-controlled-id-space-16 https://datatracker.ietf.org/doc/draft-li-pce-controlled-id-space/ 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 Monday 3rd June 2024. Please be more vocal during WG polls! Thanks! Dhruv & Julien
_______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org