Hello Samuel, Thanks for your detailed clarification. I appreciate your help!
Thanks & Regards, Mrinmoy On Wed, Jun 25, 2025 at 10:32 PM Samuel Sidor (ssidor) <[email protected]> wrote: > 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]> wrote: > > Reminder > > > > Regards, > > Diptiranjan > > > > On Tue, Jun 17, 2025 at 4:12 PM Diptiranjan Dash < > [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. > > 2. 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. > > 3. 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. > > 4. 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. > > 2. 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. > > 2. 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]
