Hi Mike, One of my point is that one optimization is a peculiar case of n optimization. For the particuliar case of candidate path, it can be attached to a given association, each TE-LSP can have the same optimization criterias.
I understand the argument for Option 2 as "I want to carry and manage my constraint (and candidate path) as one PCEP entity", the drawback is that it will become complicated in case of inter-domain and OAM which are per path. The case for option 1 is one path, one LSP, but as you pointed out it becomes complicated when there is one candidate path that desire a behavior similar to LOAD-BALANCING where the PCC ask the PCE to decide how many path are needed. I think that option 1 is better in term of protocol reuse and will offer more flexibility, but that depends on how to deal with the PCE-managed number of paths. I will not attend the IETF meeting, Best regards, Cyril On Fri, 19 Jul 2019 at 16:51, Mike Koldychev (mkoldych) <mkold...@cisco.com> wrote: > Hi Cyril, > > > > Thanks a lot for your feedback! > > > > Maybe I need to make it clear that the problem we’re trying to solve is a > single optimization objective resulting in multiple ECMP/UCMP paths. This > is motivated by SR-TE Policy use case, where each Candidate Path represents > a single optimization objective. The Candidate Path has a set of Segment > Lists that satisfy the optimization objective. > > > > You seem to want to solve a different problem: two or more different > optimization objectives and each ECMP path is mapped to a different > objective. In that case Solution 1 is absolutely necessary and it would not > have any of the down-sides, because the PCC knows in advance how many > optimization objectives it has and can create that many PCEP LSPs. However > for our problem, Solution 1 would introduce a lot of implementation > complexity and protocol overhead. > > > > We have a side-meeting scheduled on Wednesday at 8:30 to discuss this > topic, you are welcome to attend if you want to contribute your input. > > > > Thanks, > > Mike. > > > > *From:* Cyril Margaria <cyril.marga...@gmail.com> > *Sent:* Friday, July 19, 2019 9:37 AM > *To:* Mike Koldychev (mkoldych) <mkold...@cisco.com> > *Cc:* pce@ietf.org > *Subject:* Re: [Pce] Proposal for signaling ECMP or UCMP paths > > > > Hi, > > > > On slide "LSP objectives and constraints": Stateless PCE can compute set > of EROs/Label switch paths using RFC6007, including multi-domain and > multi-PCEs scenarios. This can be used for computing a set of EROs for SR > candidate paths, one case that can apply to the candidate path and > explicitly mentioned by the RFC is "Two or more end-to-end diverse > paths". This does not cover the stateful PCE case directly, but there are > similar situations to what RFC6007 in the form of path protection > (primary/secondary/standby) for statefull PCE, which use the association > mechanism. Those two existing mechanism exists to coordinate several paths > and could be used to indicate how multiple paths are related and on how to > signal them together (SVEC) > > > > On slide "Analysis of Solution 1": > - For PCC-Initated LSPs: what prevents the PCE to to create > PCE-Initiated LSPs using the same association id? This would tackle the > problem. > > - The possibility of each path to have different objective does seems to > be an advantage as its less restrictive. Having the same restriction on a > set of paths is easy, relaxing a restriction on the ERO #5 is more > complicated (in term of encoding). > - There is a set of options to achieve the "signal the set of paths > together": > a) set of LSPs can be reported in the same message, it can be > enforced by the document defining that specific association type. > > b) SVEC/SVEC List can be extended to statefull PCEP, > > > That solution would work in case of multi-domain PCEs, and also be helpful > for OAM and auto-bw mechanism. > > As a segment list is one path in the network, that maps nicely to one LSP.. > > > > > > Solution 2: > > - This limit the set of constraints to be applied, policies like "10% of > the traffic does not need to be protected" cannot be expressed (it can be > with solution 1, clear L bit of LSPA on one TE-LSP out of 10) > > - 2.a when the LSP is reported down : which ERO is down?, the same is > applicable for auto-bw and any form of OAM data. > > - Solution 2.b allows for Optimized branch encoding, that should be > disabled for that solution > > > > > > Slide "Comparison of Solutions": > > - There are solutions to most of the points raised for solution 1 > > - The database problem seems specific to one implementation, other > implementation will have the problem for solution 2 > > - multi-PCE and multi-domain are not evaluated. Solutions and > consideration are available for solution 1, not for solution 2. > (experimental Inter-domain P2MP tree solutions exists). > > > > Best Regards, > > Cyril > > > > On Fri, 12 Jul 2019 at 22:02, Mike Koldychev (mkoldych) < > mkold...@cisco.com> wrote: > > Hi WG, > > As per SPRING WG, SR Policy may contain multiple Candidate Paths and each > Candidate Path may contain multiple Segment Lists. Existing SR standards in > PCEP allow only a single ERO (one Segment List) for the SR Path in a > stateful PCEP message. There is a need to signal multiple Segment Lists in > PCEP for this as well as other load balancing use cases. > > See the link that describes this, as well as list possible ways to achieve > this. Please provide your feedback on the list or during the WG session. > > https://github.com/dhruvdhody-huawei/105/blob/master/multiple_ERO_jl03a.pdf > > Thanks, > Mike. > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > >
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
