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) <[email protected]>
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
> [email protected]
> https://www.ietf.org/mailman/listinfo/pce
>
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
