Re: [Pce] PCE SID-algo draft extension

[Dhruv Dhody <[e-mail]>]

Hi Samuel,

As a WG participant --- Assuming the WG agrees with the usecase, we need a
clear way to signal when the Algo is a constraint along with others
(current) v/s when Algo is a shorthand to refer to the constraints as per
the IGP definition (proposed).

This could be a flag in the SID Algorithm TLV or could be a brand new
mechanism (such as a new dynamic association type for FlexAlgo). More
importantly, we need to be clear on how other PCEP constraints interact
with the constraints referred in the IGP. The easiest thing would be to not
allow other PCEP constraints to be encoded at all and rely only on IGP; or
have flags to signal how to handle the complexity of combining them
including mismatch! This needs to be handled with care!

Thanks!
Dhruv

On Tue, Jan 10, 2023 at 3:51 PM Samuel Sidor (ssidor) <[e-mail]>
wrote:

> Hi all,
>
>
>
> I would like to get feedback from PCE WG for one extension proposed for
> existing SID-algo draft
> <https://datatracker.ietf.org/doc/html/draft-tokar-pce-sid-algo-05#name-sid-algorithm-constraint-2>
> (currently expired), which is trying to cover all existing algorithm types
> as defined in IGP – that includes SPF (algo 0), Strict-SPF (algo 1) and
> Flex-algo (algo 128-255)
>
> It introduced SID-algo constraint, which currently can be used for
> filtering SIDs used in path computed by PCE.
>
> To be able to compute inter-domain Flex-algo path, PCE Flex-algo
> path-computation must be aligned with path-computation done by IGP (Use
> ASLA attributes, honor FAD lookup priorities,…). This use-case is different
> one from SID filtering we need to use constraints/metric-type from
> Flex-algo definition that is bound to SID algo number specified in
> constraint.
>
>
>
> Before we modify the draft, we would like to know if WG has any objection.
>
>
>
> Thanks,
>
> Samuel
>