Re: [Pce] Proposal for signaling ECMP or UCMP paths

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) <mkoldych@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.margaria@gmail.com>
> *Sent:* Friday, July 19, 2019 9:37 AM
> *To:* Mike Koldychev (mkoldych) <mkoldych@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) <
> mkoldych@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
>
>