Hi Mrinmoy, Please check inline <S>.
Thanks, Samuel From: Mrinmoy Das <[email protected]> Sent: Friday, June 20, 2025 11:39 AM To: Diptiranjan Dash <[email protected]> Cc: [email protected] Subject: [Pce] Re: IETF Query: Regarding SR Policy Hello Team, Hope you are doing well. We have some clarifications required for SR Policy Capabilities and its processing. Please look into it and let us know your views on these points. We are eagerly waiting to get feedback from you guys. Thanks & Regards, Mrinmoy On Tue, Jun 17, 2025 at 8:53 PM Diptiranjan Dash <[email protected]<mailto:[email protected]>> wrote: Reminder Regards, Diptiranjan On Tue, Jun 17, 2025 at 4:12 PM Diptiranjan Dash <[email protected]<mailto:[email protected]>> wrote: Hi Team, While reviewing the following draft: draft-ietf-pce-segment-routing-policy-cp-27 - Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (SR) Policy Candidate Paths<https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/27/> We came across a few areas that are currently unclear . We request your clarification on the following points: 1. SR Policy Capabilities: Computation Priority TLV 5.2.1. Computation Priority TLV, page 15: If the TLV is absent from the LSP object and the P-flag in the SRPOLICY-CAPABILITY TLV is set to 1, a default Priority value of 128 is used. As per above section, if P-flag is set in SRPOLICY-CAPABILITY TLV and Computation Priority TLV is absent then default priority will be 128. Now, what would be in the PCReport from PCC? <S>That statement is just clarifying what is the priority if TLV is not included. PCEP speaker can still include that TLV even if priority is 128. So both versions – including & skipping that TLV is valid. Note that currently only priority field is included, but future extensions can potentially add more fields or flags in that TLV (so it may be necessary to include that TLV even for value 128). 1. Should PCC send a Computation Priority TLV in LSP object with priority 128? <S> As described above. It can, but it will not make any difference for now. 1. Now, as my understanding, if PCE sends any priority update say 50 then PCReport will send Computation Priority TLV in the LSP object with priority 50. Is that correct? <S> Correct. Note that rules from existing RFCs may apply as well, e.g. “https://www.ietf.org/rfc/rfc8231.html#section-6.2” is allowing PCC to have local policy to set values to locally configured defaults if value was not included in the request (“A PCC MAY set missing parameters from locally configured defaults. If the LSP specified in the Update Request is already up, it will be re-signaled.”). Is there any added value for PCE updating priority (which is supposed to be used by PCE) originally reported from PCC? At least for me, main use-case for this TLV is policy initiated on PCC with priority specified and delegated to PCE, so PCE can prioritize path-computation of some policies. 1. In later PCUpdates if there is no change in priority, then should PCC send Computation Priority TLV in the LSP object of PCReport? <S> Every PCRpt should have complete intended state with all intended attributes (We have some exceptions (e.g. association objects), but those have explicit “Remove” flag included to indicate that association should be removed.). So if computation priority TLV is not included in PCRpt, then it can be reset to default value on PCE. 1. Should PCC send Computation Priority TLV in MBB down PCREports or LSP remove PCReports? <S> At least for LSP removal it logically does not make sense to me to include it since there should not be any path-computation triggered for LSP, which is being removed (same way like I don’t see value in including constraints), but I don’t think that it is forbidden. 2. SR Policy Capabilities: Explicit Null Label Policy (ENLP) TLV 5.2.2. Explicit Null Label Policy (ENLP) TLV, page 15: If an ENLP TLV is not present, the decision of whether to push an Explicit NULL label on a given packet is a matter of local configuration 1. Now, as my understanding, if PCE sends ENLP TLV in the LSP object then PCC sends it in the LSP object of PCReport. Is that correct? <S> Correct, but you may need to consider “The behavior signaled in this TLV MAY be overridden by local configuration by the network operator based on their deployment requirements” in https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp#section-5.2.2, so even if PCE requested some behavior, PCC may have local policy and still use different value. 1. In later PCUpdates if there is no change in ENLP TLV, then should PCC send ENLP TLV in the LSP object of PCReport? <S>Yes, complete intended state should be included (as described for Computation Priority TLV) 3. Should PCC send ENLP TLV in MBB down PCREports or LSP remove PCReports? <S> Same as Computation Priority TLV 3. SR Policy Capabilities: Invalidation TLV 5.2.3. Invalidation TLV, page 16: 1. Now, as my understanding, if PCE sends Invalidation TLV in the LSP object then PCC sends it in the LSP object of PCReport. Is that correct? <S> Correct, but note that feature is enabled as soon as it is enabled on single candidate-path of the policy. So even if PCE requested it to be disabled for specific candidate-path, then “Oper” field in that TLV can still indicate that feature is active since it could be enabled from other candidate-paths. 1. In later PCUpdates if there is no change in Invalidation TLV, then should PCC send Invalidation TLV in the LSP object of PCReport? <S> Same as previous TLVs. 3. Should PCC send Invalidation TLV in MBB down PCREports or LSP remove PCReports? <S> Same as above. 4. Another question regarding the below error: 5.1. SR Policy Capability TLV, page 13: If a PCEP speaker receives SRPA but the SRPOLICY-CAPABILITY TLV is not exchanged, then the PCEP speaker MUST send a PCErr message with Error- Type = 10 ("Reception of an invalid object") and Error-Value = TBD2 ("Missing SRPOLICY-CAPABILITY TLV") and MUST then close the PCEP session. Suppose PCC does not support SRPA, so didn't send capability TLV in open message, but PCE supports and sends it in Open message. In this situation, my understanding is, the PCEP session should come up without any issue. Right? <S> Yes, PCEP session should come up, just PCEP peers are not supposed to use SRPA. Note that this requirement was added in later phase of the draft, where some existing implementations were already implemented (so those may not advertise SRPOLICY-CAPABILITY TLV). Now, if PCE receives SRPA from PCC, PCE will send Error- Type = 10 ("Reception of an invalid object") and Error-Value = TBD2 ("Missing SRPOLICY-CAPABILITY TLV") and MUST then close the PCEP session. It is clear to me. But, if PCC receives SRPA from PCE, then which error should be thrown? Error- Type = 10 ("Reception of an invalid object") and Error-Value = TBD2 ("Missing SRPOLICY-CAPABILITY TLV")? But "Missing SRPOLICY-CAPABILITY TLV" is not right as it receives SRPOLICY-CAPABILITY TLV from PCE, rather could be some other error like "SRPOLICY not supported". What do you think regarding this error? <S>If PCC does not support SRPA (I assume that you are expanding case “Suppose PCC does not support SRPA …”), then it most likely also does not support this draft at all including this PCErr message. So it can use some base existing error messages, e.g. PCErr message with Error-Type="Unknown Object" or "Not supported Object" (but PCC may also “silently” ignore it based on flags specified in “Common Object Header”). Thanks & Regards, Dipti Ranjan
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
