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) <[email protected]> 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 >
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
