Re: [Pce] PCE SID-algo draft extension

[Dhruv Dhody <[e-mail]>]

Hi Samuel,

Thanks for the discussion! Looking forward to the updated text in the draft
to review!

Thanks!
Dhruv

On Tue, Apr 11, 2023 at 2:50 PM Samuel Sidor (ssidor) <[e-mail]>
wrote:

> Hi all,
>
>
>
> Since nobody else (besides Andrew and Peng Shaofu) had any other
> opinions/proposals, I’ll proceed with draft update.
>
>
>
> Regards,
>
> Samuel
>
>
>
> *From:* Andrew Stone (Nokia) <[e-mail]>
> *Sent:* Wednesday, April 5, 2023 4:50 PM
> *To:* Samuel Sidor (ssidor) <[e-mail]>; [e-mail]
> *Cc:* [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> *Subject:* Re: [Pce] PCE SID-algo draft extension
>
>
>
> Hi Samuel, ACK – rationale and comparisons sounds reasonable and good to
> me.
>
>
>
> Thanks
>
> Andrew
>
>
>
> *From: *"Samuel Sidor (ssidor)" <[e-mail]>
> *Date: *Wednesday, April 5, 2023 at 4:48 AM
> *To: *"Andrew Stone (Nokia)" <[e-mail]>, "
> [e-mail]" <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>,
> "[e-mail]" <[e-mail]>
> *Subject: *RE: [Pce] PCE SID-algo draft extension
>
>
>
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See http://nok.it/ext for
> additional information.
>
>
>
> Hi Andrew,
>
>
>
> My proposal was really to use something like P/I flag from PCEP object. In
> this case, SID-algo constraint is TLV, so there is no way to enforce it
> using P flag), so yes – I meant “permitted to compute and program a path *as
> if* LSPA never contained the SID Algo TLV”.
>
>
>
> If SID-algo constraint is not included, then PCE can use algo SIDs freely
> (even if there is no draft or no SID-algo constraint specified) – e.g. to
> decrease size of label stack. So same thing would apply to L=1. If PCE
> cannot fully satisfy constraint, then it can fallback into “no SID-algo
> constraint” behavior and it can still compute path with algo SIDs if
> needed, but there is no explicit preference to specific algo SIDs or
> anything like that.
>
>
>
> For cases, where for example multi-domain path is needed, where some
> domains have FA support, but some domain does not support that FA,
> recommended approach can be still policy stitching.
>
>
>
> I personally consider such approach as consistent with other constraints,
> which we have – e.g. for affinities we also does not have L flag to
> partially ignore it in part of the network, but still consider in other
> parts. And we have “Strict Disjointness” flag in diversity, which almost
> similar – allowing to fallback other disjoint types or non-disjoint path
> (but still constraint is applied to complete path and not only to some hops
> or some domain). Rules for path-computation are already more complex with
> other constraints (considering topology pruning, ASLA constraints, other
> constraints from PCRpt,…), so increasing complexity even more and allowing
> combination of algos in same segment-list, but still preferring some of
> them can be really too much.
>
>
>
> Regards,
>
> Samuel
>
>
>
> *From:* Andrew Stone (Nokia) <[e-mail]>
> *Sent:* Tuesday, April 4, 2023 8:58 PM
> *To:* Samuel Sidor (ssidor) <[e-mail]>; [e-mail]
> *Cc:* [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> *Subject:* Re: [Pce] PCE SID-algo draft extension
>
>
>
> Hi Samuel,
>
>
>
> To confirm what you’re suggesting - It reads to me like it says if L=1,
> then PCE is effectively permitted to compute and program a path *as if*
> LSPA never contained the SID Algo TLV. Or am I mistaken? Or is the
> suggestion that it’s really up to PCE to decide how ‘loose’ it wants to go
> in regards to ‘constraint’ (path prune vs encoding) and it’s permitted to
> approach the problem as a form of relaxation as it sees fit to get the path
> up? I agree, the scope needs to be kept down and clear for relatively
> consistent interop for what the ‘intention’ is of the knobs. I see the
> standardization goal here about intention of the knobs/behavior and wire
> encoding, but permit implementation to decide how best to achieve the
> signalled intention.
>
>
>
> Thanks
>
> Andrew
>
>
>
> *From: *"Samuel Sidor (ssidor)" <[e-mail]>
> *Date: *Monday, April 3, 2023 at 9:31 AM
> *To: *"Andrew Stone (Nokia)" <[e-mail]>, "
> [e-mail]" <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>,
> "[e-mail]" <[e-mail]>
> *Subject: *RE: [Pce] PCE SID-algo draft extension
>
>
>
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See http://nok.it/ext for
> additional information.
>
>
>
> Thanks Andrew,
>
>
>
> One proposal for all about that L flag – what about really changing
> behavior of L flag to make it simple for both use-cases (option A and
> option B), so:
>
> If L=0, then constraints have to be satisfied. If such path cannot be
> found, then empty path will be returned. (no change)
>
> For L=1, if path cannot be found with that constraint, then constraint can
> be ignored and path can be recomputed without considering it at all (SID of
> that algo does not need to be preferred).
>
>
>
> From draft perspective it is about modifying this part:
>
> ·         L (Loose): If set to 1, the PCE MAY insert SIDs with a
> different Algorithm, *but it MUST prefer the specified Algorithm whenever
> possible.*
>
>
>
> That way PCE can still use SIDs of specified algo, but constraint is not
> enforcing it, so PCE can still compute complete end-to-end path with just
> algo 0 SIDs (of included SIDs of specified algo if it is considering it as
> safe). So there are no special requirements from topology pruning or SID
> filtering for L flag.
>
>
>
> To me it seems that there would be really too many options/combinations if
> we will keep original definition of that flag and probably not all vendors
> will implement all of them and we will end-up with various interop issues,
> so would need extra capabilities as well to advertise what is supported and
> what is not.
>
>
>
> Thanks,
>
> Samuel
>
>
>
> *From:* Andrew Stone (Nokia) <[e-mail]>
> *Sent:* Friday, March 31, 2023 5:18 AM
> *To:* Samuel Sidor (ssidor) <[e-mail]>; [e-mail]
> *Cc:* [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> *Subject:* Re: [Pce] PCE SID-algo draft extension
>
>
>
> Hi Samuel,
>
>
>
> Replies inline below with [Andrew]
>
>
>
> Thanks
>
> Andrew
>
>
>
> *From: *"Samuel Sidor (ssidor)" <[e-mail]>
> *Date: *Thursday, March 30, 2023 at 8:22 AM
> *To: *"Andrew Stone (Nokia)" <[e-mail]>, "
> [e-mail]" <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>,
> "[e-mail]" <[e-mail]>
> *Subject: *RE: [Pce] PCE SID-algo draft extension
>
>
>
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See http://nok.it/ext for
> additional information.
>
>
>
> Hi Andrew,
>
>
>
> Thanks for good comment.
>
>
>
> There are really 3 things – optionA, optionB and L flag.
>
>
>
> *Option A + option B:*
>
> Option A cannot be combined with Option B as main difference here is
> source of optimization metric/constraints and topology attributes, which
> are supposed to be used in the path-computation (ASLA vs legacy).
>
>
>
> [Andrew] Agreed
>
>
>
> *Option A + L flag:*
>
> I would say that option A can be combined with L flag as you are really
> doing path-computation based on “legacy” constraints specified in PCRpt.
> That will result in some path, which is translated into SID list and algo
> of those SIDs is not that important (if IGP path of those SIDs is congruent
> with computed path).
>
>
>
> [Andrew] Agreed. My interpretation for a use case on the original adoption
> was that if PCE is setting up a path, it would be more ideal to set it up
> following a given Algo, so that way any native IGP convergence or
> protection mechanisms will still respect a metric/constraints differing
> from algo-0, and if you fail to resolve a SID list using the algo be
> permitted to use any SIDs available.
>
>
>
> *Option B + L flag:*
>
> Option B is implicitly restricting topology to only nodes/links with
> participation in that FA (PCE need to follow from path-computation what IGP
> is doing for that option). Constraints and metric-type in FAD are defining
> FA ASLA constraints, so even in the path-computation PCE is supposed to use
> FA ASLA link attributes. So if PCE would suddenly need to use links/nodes
> (if we would allow usage of non-FA topology for L=1), which does not
> advertise those attributes, then PCE would have to fallback into legacy
> (non-ASLA) link attributes and resulting path would have for example
> accumulated metric, which is combining ASLA latency of some links with
> non-ASLA latency of other links (it seems to me like mixing apples and
> oranges as it is not guaranteed that FA ASLA metric value for specific link
> is same as legacy metric value of same link). So I tend to say that
> topology should be restricted even with L=1 with option B.
>
>
>
> [Andrew] Yes, agree that topology(edges in the graph) should be restricted
> with L=1. Topology must be restricted to links matching the flex algo, and
> thus any path programmed must only be for links within that flex algo, and
> If a given resource violates the FAD it must be pruned. But I do think
> there’s two sides to it, topology filtering vs SID selection to encode the
> selected the path in a given topology. If we take a simplistic case of a
> FAD with metric Delay without any constraints, assuming the entire network
> supports the Algo, Algo=0 and Algo=Delay are one-to-one with a difference
> of weights, so the concern for topological filtering is not as significant
> – what matters is encoding of the intended “best path”
> (FAD+LspConstraints+Rules imposed on PCE) using SIDs from Algo 0 or
> Algo=Delay.  (Secondary comment about MSD below)
>
>
>
> I just described topology which must be used and not SIDs. I can still
> imagine that if L=1 is set, then PCE will use FA topology, but it can still
> fallback into Algo-0 Prefix SIDs (even if I think that there is higher
> change that adj SIDs + FA SIDs will be used) assuming that final computed
> path will still be shortest path of specified ASLA metric and it will
> satisfy ASLA constraints from FAD.
>
>
>
> [Andrew] Yep agreed.
>
>
>
> Btw for your other example with MSD – I assume that in most of the cases
> you will end up with smaller number of SIDs if you will use FA SIDs (as IGP
> forwarding will be more aligned with intended constraints in PCE
> path-computation) when compared with algo-0 SIDs.
>
>
>
> [Andrew] While I generally agree with you, it could still be possible
> (likely outlier scenarios)  where the path constraints and behavior imposed
> by PCE may need to deviate from the Algo shortest path (ex: Delay)
> significantly enough that MSD becomes constraining. This would be more
> likely to occur with combination of factors imposed at PCE, such as
> de-congestion optimization and rules such as Bidirectionality and/or
> Diversity which by its nature generally requires avoiding the shortest
> path, potentially for each set of LSPs having diversity imposed on them.
>
>
>
> I’ll think about it a little bit more, L flag is definitely introducing
> extra complexity into both cases, so maybe even dropping that flag may work
> (PCE can still compute path mix of FA and algo0 SIDs even without any
> constraint, so maybe added value of SID-algo constraint + L=1 is relatively
> small) or we can modify it to restrict it to combination of FA SIDs + adj
> SIDs.
>
>
>
> [Andrew] ACK. Will think more about it as well. I don’t have a concrete
> suggestion at this moment. I do agree we need one or many knobs in the
> picture , and it seems reasonable to drop knob(s) into the FA SID TLV, but
> just want to make sure we’re covering exactly what scenarios these knobs
> are intending to cover/not cover.
>
>
>
> Regards,
>
> Samuel
>
>
>
> *From:* Andrew Stone (Nokia) <[e-mail]>
> *Sent:* Wednesday, March 29, 2023 4:24 PM
> *To:* [e-mail]; Samuel Sidor (ssidor) <[e-mail]>
> *Cc:* [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> *Subject:* Re: [Pce] PCE SID-algo draft extension
>
>
>
> Hi Samuel, PCE WG
>
>
>
> I think your comparison points cover the differences well.
> Comparing/contrasting the two scenarios and behaviors should probably be in
> the updated document, too.
>
>
>
> It does seem a need to signal the different behavior intention in some
> form or another (whether flag or inclusion/exclusion of constructs).
> Something not remarked in (B), is PCE implicitly restricted to using only
> SIDs found from the Flex Algo Tree? Or is it still permitted to use any SID
> it wants (existing draft L=1) if the path is using resources respecting the
> FAD. As an example, Let's say PCE computes a path based on FAD constraints
> but needs to work around constraints defined outside of the algo, such as
> known planned maintenance or other impairments/rules. Due to MSD, maybe it
> can't encode this path within the confines of the Algo specified. However,
> if it used Algo-0 or another SIDs it can encode the path. I would assume
> this should be permitted, but Is there a need to prohibit this and restrict
> (B) to also use only the SIDs from the same algo? I think I’m looking to
> clarify, if (A) is filtering strictness and (B) metric/constraint, is the
> behavior needed actually A||B, or is it A=true/false, B=true/false?
>
>
>
> Thanks
>
> Andrew
>
>
>
> *From: *"[e-mail]" <[e-mail]>
> *Date: *Wednesday, March 29, 2023 at 5:46 AM
> *To: *"[e-mail]" <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>,
> "[e-mail]" <[e-mail]>, "Andrew Stone (Nokia)" <
> [e-mail]>
> *Subject: *Re: [Pce] PCE SID-algo draft extension
>
>
>
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See http://nok.it/ext for
> additional information.
>
>
>
>
>
> Hi Samuel, WG,
>
>
>
> Thanks for the effort work to get the consensus about path computation
> according to the content of FAD.
>
> An explicit flag based on the existing SID-algo constraint for the purpose
> of behavior b, seems good to me.
>
>
>
> Regards,
>
> PSF
>
>
>
>
>
> Original
>
> *From: *SamuelSidor(ssidor) <[e-mail]>
>
> *To: *[e-mail] <[e-mail]>;'pce-chairs' <[e-mail]>;
>
> *Cc: *[e-mail] <[e-mail]>;'Dhruv Dhody' <
> [e-mail]>;彭少富10053815;Stone, Andrew (Nokia - CA/Ottawa) <
> [e-mail]>;
>
> *Date: *2023年03月29日 17:10
>
> *Subject: RE: [Pce] PCE SID-algo draft extension*
>
> Hi all,
>
>
>
> Thanks all for discussion, which happened during PCE session and thanks
> for supporting this extension.
>
>
>
> I think that we agreed that it is necessary to consider FAD in the
> path-computation on PCE side if SID-algo constraint was specified, but we
> were not able to finish discussion whether there is a need to introduce new
> flag, which will control whether original behavior (SID-algo filtering) or
> new behavior should be used, so re-opening this mail thread to finish that
> discussion.
>
>
>
> I would say that there are really at least two usecases/behaviors for
> SID-algo constraint and we need new flag in SID-algorithm constraint to
> allow PCC to pick required behavior.
>
>
>
>    1. SID-filtering - already exists in the draft (valid for all
>    algorithms)
>
>
>    - Path-computation should occur on the topology associated with
>    specified SID-algo
>    - Computed path can have only SIDs of specified algo value (+
>    adjacency SIDs)
>    - PCE path-computation is done based on metric-type and constraints
>    from PCRpt
>    - Flex-algo specific part:
>
>
>    - PCE still has to make sure that IGP path of FA SID is congruent with
>       computed path
>
>
>    1. Path-computation based on FAD (only valid for Flex-algo)
>
>
>    - Metric-type and constraints are primarily retrieved from FAD
>    - Path-computation follow IGP Flex-algo path-computation logic
>
>
>    - Flex-algo participation, ASLA attributes,...
>
>
>    - Metric-type from FAD is overriding metric-type from PCRpt
>    - PCUpdate will use metric-type from FAD
>    - PCC can send metric-type in PCRpt and it does not have to be same as
>    metric-type from FAD, but it is recommended to do not advertise any
>    optimization metric
>    - Other constraints from PCRpt:
>
>
>    - PCE implementation can decide based on flags in PCEP object
>       - It is not recommended to specify constraints in PCRpt, which are
>       already specified in FAD
>       - PCE is not supposed to include constraints from FAD in PCUpdate
>
>
>
> Description here is slightly different then the proposal presented in
> original slides, but main idea is still same and more details is provided
> now. Please provide any comments.
>
>
>
> Thanks,
>
> Samuel
>
>
>
> *From:* Pce <[e-mail]> *On Behalf Of *Samuel Sidor (ssidor)
> *Sent:* Thursday, January 12, 2023 10:12 AM
> *To:* [e-mail]; 'Dhruv Dhody' <[e-mail]>
> *Cc:* [e-mail]; 'pce-chairs' <[e-mail]>
> *Subject:* Re: [Pce] PCE SID-algo draft extension
>
>
>
> Hi Dhruv,
>
>
>
> Thanks for feedback. I completely agree – I would like to hear from WG if
> they can see added value in both (or they can specify even other) use-cases
> – using SID-algo constraint just for SID filtering and using it also for
> specification of constraints from FAD (I agree with Stephane here –
> computation based on in FAD seems to be even more important use-case to me
> and it is not covered in current version of that draft).
>
>
>
> For constraint conflict solving – there are multiple possible solutions,
> but I would prefer to ignore metric-type from PCRpt (as metric-type would
> be retrieved from FAD) or reject PCEP Metric object completely (that may
> have potential issues with backward compatibility). Do not block usage of
> other constraints on top of SID-algo constraint explicitly in the draft –
> actual PCE implementation can still reject any combination of constraints,
> which PCE cannot handle (with PCUpdate with empty ERO or with some specific
> PCError) That would allow usage of some specific constraints like metric
> bounds on top of path computed with constraints from FAD. I would like to
> clearly specify in the draft that PCC is not supposed to reflect
> constraints from FAD in PCRpt as intended/requested attributes (only
> constraints, which should be used on top of FAD should be specified).
>
>
>
> For SID-algo constraint signaling – can you please specify benefit of
> using association in this case? FAD with constraints is part of topology
> information received from IGP/BGP-LS, so we need to encode only algorithm
> number (and potentially source IGP, but that is separate story).
>
>
>
> Thanks,
>
> Samuel
>
>
>
> *From:* [e-mail] <[e-mail]>
> *Sent:* Tuesday, January 10, 2023 5:34 PM
> *To:* 'Dhruv Dhody' <[e-mail]>; Samuel Sidor (ssidor) <
> [e-mail]>
> *Cc:* [e-mail]; 'pce-chairs' <[e-mail]>
> *Subject:* RE: [Pce] PCE SID-algo draft extension
>
>
>
> Hi
>
>
>
> Happy new year guys !
>
>
>
> IMO, from a use case point of view, the SID filtering use case is far more
> limited and niche (e.g.: plane selection…) vs the interdomain FA path
> computation which is widely required. For large networks that are
> multidomain, there must be a PCE based solution for interdomain FA path
> computation.
>
>
>
> Brgds,
>
>
>
> Stephane
>
>
>
> *From:* Pce <[e-mail]> *On Behalf Of *Dhruv Dhody
> *Sent:* mardi 10 janvier 2023 14:00
> *To:* Samuel Sidor (ssidor) <[e-mail]>
> *Cc:* [e-mail]; pce-chairs <[e-mail]>
> *Subject:* Re: [Pce] PCE SID-algo draft extension
>
>
>
> 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
>
>
>