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) <ssi...@cisco.com> 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) <andrew.st...@nokia.com> > *Sent:* Wednesday, April 5, 2023 4:50 PM > *To:* Samuel Sidor (ssidor) <ssi...@cisco.com>; peng.sha...@zte.com.cn > *Cc:* pce@ietf.org; pce-cha...@ietf.org; slitkows.i...@gmail.com; > d...@dhruvdhody.com > *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)" <ssi...@cisco.com> > *Date: *Wednesday, April 5, 2023 at 4:48 AM > *To: *"Andrew Stone (Nokia)" <andrew.st...@nokia.com>, " > peng.sha...@zte.com.cn" <peng.sha...@zte.com.cn> > *Cc: *"pce@ietf.org" <pce@ietf.org>, "pce-cha...@ietf.org" < > pce-cha...@ietf.org>, "slitkows.i...@gmail.com" <slitkows.i...@gmail.com>, > "d...@dhruvdhody.com" <d...@dhruvdhody.com> > *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) <andrew.st...@nokia.com> > *Sent:* Tuesday, April 4, 2023 8:58 PM > *To:* Samuel Sidor (ssidor) <ssi...@cisco.com>; peng.sha...@zte.com.cn > *Cc:* pce@ietf.org; pce-cha...@ietf.org; slitkows.i...@gmail.com; > d...@dhruvdhody.com > *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)" <ssi...@cisco.com> > *Date: *Monday, April 3, 2023 at 9:31 AM > *To: *"Andrew Stone (Nokia)" <andrew.st...@nokia.com>, " > peng.sha...@zte.com.cn" <peng.sha...@zte.com.cn> > *Cc: *"pce@ietf.org" <pce@ietf.org>, "pce-cha...@ietf.org" < > pce-cha...@ietf.org>, "slitkows.i...@gmail.com" <slitkows.i...@gmail.com>, > "d...@dhruvdhody.com" <d...@dhruvdhody.com> > *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) <andrew.st...@nokia.com> > *Sent:* Friday, March 31, 2023 5:18 AM > *To:* Samuel Sidor (ssidor) <ssi...@cisco.com>; peng.sha...@zte.com.cn > *Cc:* pce@ietf.org; pce-cha...@ietf.org; slitkows.i...@gmail.com; > d...@dhruvdhody.com > *Subject:* Re: [Pce] PCE SID-algo draft extension > > > > Hi Samuel, > > > > Replies inline below with [Andrew] > > > > Thanks > > Andrew > > > > *From: *"Samuel Sidor (ssidor)" <ssi...@cisco.com> > *Date: *Thursday, March 30, 2023 at 8:22 AM > *To: *"Andrew Stone (Nokia)" <andrew.st...@nokia.com>, " > peng.sha...@zte.com.cn" <peng.sha...@zte.com.cn> > *Cc: *"pce@ietf.org" <pce@ietf.org>, "pce-cha...@ietf.org" < > pce-cha...@ietf.org>, "slitkows.i...@gmail.com" <slitkows.i...@gmail.com>, > "d...@dhruvdhody.com" <d...@dhruvdhody.com> > *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) <andrew.st...@nokia.com> > *Sent:* Wednesday, March 29, 2023 4:24 PM > *To:* peng.sha...@zte.com.cn; Samuel Sidor (ssidor) <ssi...@cisco.com> > *Cc:* pce@ietf.org; pce-cha...@ietf.org; slitkows.i...@gmail.com; > d...@dhruvdhody.com > *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: *"peng.sha...@zte.com.cn" <peng.sha...@zte.com.cn> > *Date: *Wednesday, March 29, 2023 at 5:46 AM > *To: *"ssi...@cisco.com" <ssi...@cisco.com> > *Cc: *"pce@ietf.org" <pce@ietf.org>, "pce-cha...@ietf.org" < > pce-cha...@ietf.org>, "slitkows.i...@gmail.com" <slitkows.i...@gmail.com>, > "d...@dhruvdhody.com" <d...@dhruvdhody.com>, "Andrew Stone (Nokia)" < > andrew.st...@nokia.com> > *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) <ssi...@cisco.com> > > *To: *pce@ietf.org <pce@ietf.org>;'pce-chairs' <pce-cha...@ietf.org>; > > *Cc: *slitkows.i...@gmail.com <slitkows.i...@gmail.com>;'Dhruv Dhody' < > d...@dhruvdhody.com>;彭少富10053815;Stone, Andrew (Nokia - CA/Ottawa) < > andrew.st...@nokia.com>; > > *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 <pce-boun...@ietf.org> *On Behalf Of *Samuel Sidor (ssidor) > *Sent:* Thursday, January 12, 2023 10:12 AM > *To:* slitkows.i...@gmail.com; 'Dhruv Dhody' <d...@dhruvdhody.com> > *Cc:* pce@ietf.org; 'pce-chairs' <pce-cha...@ietf.org> > *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:* slitkows.i...@gmail.com <slitkows.i...@gmail.com> > *Sent:* Tuesday, January 10, 2023 5:34 PM > *To:* 'Dhruv Dhody' <d...@dhruvdhody.com>; Samuel Sidor (ssidor) < > ssi...@cisco.com> > *Cc:* pce@ietf.org; 'pce-chairs' <pce-cha...@ietf.org> > *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 <pce-boun...@ietf.org> *On Behalf Of *Dhruv Dhody > *Sent:* mardi 10 janvier 2023 14:00 > *To:* Samuel Sidor (ssidor) <ssi...@cisco.com> > *Cc:* pce@ietf.org; pce-chairs <pce-cha...@ietf.org> > *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) <ssi...@cisco.com> > 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 Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
