Re: [Pce] PCE SID-algo draft extension

[Dhruv Dhody <[e-mail]>]

Hi Samuel,

Thanks for the update! Two quick high level comments -

(1) Don't limit yourself to stateful PCEP messages only. Please describe
PCReq/PCRep behaviour as well.

(2) Have a look again at all the SHOULDs that you have added, and think in
which cases you would find the condition okay to be NOT met! Basically, do
you have good justifications for those SHOULDs?

Thanks!
Dhruv

On Wed, Apr 19, 2023 at 3:17 PM Samuel Sidor (ssidor) <[e-mail]>
wrote:

> Hi all,
>
>
>
> Attaching updated version of the draft and diff of changes.
>
>
>
> List of changes:
>
>    - Added F flag -> F=0 -> SID filtering option, F=1 -> Flex-algo
>    path-computation as described sooner in this mail thread
>    - Added details for both behaviors (F=0 and F=1) based on discussion
>    in the thread
>    - Modified meaning of L (loose) flag and renamed it to S (strict), now
>    it is more consistent with other PCE RFCs (e.g. LSP diversity)
>    - Renamed SID Algorithm to SR Algorithm to align with other drafts in
>    other working groups (based on comments received in the past)
>    - Clarified that only one instance of SR algorithm constraint TLV is
>    supposed to be included
>    - Added section with remaining gaps/enhancements – to track them
>
>
>
> In case of no major comments, I’ll submit updated version by end of this
> week or beginning of next week.
>
>
>
> Regards,
>
> Samuel
>
>
>
> *From:* Dhruv Dhody <[e-mail]>
> *Sent:* Wednesday, April 12, 2023 11:36 AM
> *To:* Samuel Sidor (ssidor) <[e-mail]>
> *Cc:* Andrew Stone (Nokia) <[e-mail]>;
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> *Subject:* Re: [Pce] PCE SID-algo draft extension
>
>
>
> 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
>
>
>
>