Hi, Just to conclude this for the list, I had an offline discussion with Kowsalya.
This was a case where PCC identifies that the path provided by the PCE is incorrect. I suggested that PCC should raise an alarm and notify operator. Additionally, Kowsalya pointed out that RFC 8231 section 6.2 states that LSP-ERROR-CODE TLV with "Unacceptable parameters" can be sent in response to a PCUpd that cannot be satisfied. Thanks! Dhruv On Tue, Nov 25, 2025 at 7:10 PM Kowsalya Dhevi < [email protected]> wrote: > Hi Dhruv, > > Thank you for your response. > The PCE is indeed sending a path that violates the hop-count constraint. > The PCRep message contained an ERO with two SR sub-objects, indicating that > the ERO path is more than one hop away, despite the PCC's hop-count > constraint being set to one. > > Could you please clarify the expected behavior of the PCC upon receiving > such a PCRep message? I am wondering if this scenario should be interpreted > as an error. > > Regards, > Kowsalya > > On Tue, Nov 25, 2025 at 6:32 PM Dhruv Dhody <[email protected]> wrote: > >> Hi Kowsalya, >> >> On Tue, Nov 25, 2025 at 4:55 PM Kowsalya Dhevi < >> [email protected]> wrote: >> >>> Hi All, >>> >>> Kindly share your insights regarding the following query. >>> >>> RFC 5440, section 7.8, states that "If no path satisfying the constraints >>> could be found by the PCE, the METRIC objects MAY also be present in the >>> PCRep message with the NO-PATH object to indicate the constraint metric >>> that could be satisfied." >>> >>> However, I have encountered a scenario where the PCE sent a PCRep message >>> with an Explicit Route Object (ERO), even when it could not locate a path >>> meeting the constraints. Specifically, the Path Computation Client (PCC) >>> sent a PCReq message with a Metric Object for "Hop Counts" set to "1" >>> with >>> the B flag enabled. Nevertheless, the PCE responded with a PCRep message >>> containing an ERO object but with a different Metric Object "TE Metric". >>> >>> >> Dhruv: Just for my understanding - what is the content of the ERO? >> >> https://datatracker.ietf.org/doc/html/rfc5440#section-7.5 is clear that >> "When a PCE cannot find a path satisfying a set of constraints, it MUST >> include a NO-PATH object in the PCRep message." >> >> The presence of the ERO in PCRep indicates successful path computation. >> >> >> >>> In such an instance, I wonder if it is appropriate for the PCC to send a >>> PCErr message. If so, I would appreciate it if you could provide the >>> appropriate Error-type and Error-value. >>> >>> >> Dhruv: If there is no NO-PATH object present in the PCRep message, the >> PCC does not have a way to infer that the path computation failed. This is >> why RFC 5440 does not have an explicit error message specified. >> >> For comparison, Stateful PCE implementations use an empty ERO to signal >> "no path" in the PCUpd message (not PCRep). That is why I asked about ERO >> content - to understand whether the PCE is sending a path that clearly >> violates the hop-count constraint or something else is going on. >> >> Thanks! >> Dhruv >> (As a WG participant) >> >> >> >>> Regards, >>> Kowsalya Dhevi >>> >>> -- >>> >> > .
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
