I synced up with PK in-person this morning and clarified his questions. I'm reproducing my response here on the list to keep record.
The weights are specified per sub-candidate path. If the sub-candidate path is dynamic, the specified weight is distributed across the set of segment-lists as dynamically computed by the compute-engine. So for example, if the specified weight for the dynamic sub-candidate path is 3 and the computation result yielded 3 equal cost segment-lists, then the weight associated with each segment-list would be 1. If the sub-candidate path is explicit, the specified weight translates to the weight of the corresponding segment-list. Regards, -Pavan On Wed, Jul 24, 2019 at 1:23 PM Przemyslaw Krol <[email protected]> wrote: > Hi Vishnu, > > Clarification question, if I may. > Are you envisioning weights to be normalized for all sub-candidate-paths > (regardless of the candidate-path they belong to), or rather propose to > have a 2-level split: > - weight for candidate-path grouping specific sub-candidate-paths defining > "global" share of traffic, in comparison with other candidate-paths > - weight for specific sub-candidate-path defining "local" share of the > traffic within specific candidate-path, in comparison with other > sub-candidate-paths in that particular candidate-path > > thanks, > pk > > On Wed, Jul 24, 2019 at 6:42 AM Vishnu Pavan Beeram < > [email protected]> wrote: > >> Authors, Hi! >> >> There are some use-cases where the candidate-path (multipath) needs to be >> constructed in such a way that a part of the multipath (a set of >> segment-lists) uses one set of constraints, while the other part (another >> set of segment-lists) uses another set of constraints. Consider the >> scenario where the traffic needs to be steered onto a policy in such a way >> that a specified portion of it uses paths that traverse only blue links >> while the rest uses paths that traverse only red links. >> >> The current semantics of a candidate-path as defined in Section 2.2 of >> version 3 preclude such use-cases. It should be possible to let the >> semantics be a tad more flexible than they currently are and cater to the >> above scenario (and the likes of it). >> >> There are a few different ways of addressing this, but I would like to >> propose one that seems least disruptive. >> >> In addition to the currently specified semantics: >> -- A candidate path may comprise of a set of sub-candidate paths where >> each each sub-candidate path is either dynamic or explicit. The >> sub-candidate path is the unit of signaling of an SR policy between a >> headend and a controller.. >> >> Regards, >> -Pavan >> _______________________________________________ >> spring mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/spring >> > > > -- > Przemyslaw "PK" Krol | Strategic Network Engineer ing | [email protected] >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
