Hi PCE Chairs and WG A few questions/comments regarding draft-barth-pce-segment-routing-policy-cp-06:
1. draft-ietf-spring-segment-routing-policy states that only a single candidate path can be active within an SR Policy. While we wouldn't want to repeat all the text in the PCEP document that it's in the spring document and focus more on the encoding of signalling, should PCEP comment on this (only 1 active CP in an SR Policy association group)? 2. Binding SID is an important attribute of SR Policy, and for PCEP that is currently described independently in draft-sivabalan-pce-binding-label-sid (as it should be) - should draft-barth-pce-segment-routing-policy-cp-06 make a point to reference this? For an implementation of draft-barth-pce-segment-routing-policy-cp, must it support draft-sivabalan-pce-binding-label-sid ? 3. Similar to previous point, draft-barth-pce-segment-routing-policy-cp-06 has editor comments regarding support of multiple SID lists to be described in another document. draft-koldychev-pce-multipath describes a mechanism for this. Should draft-barth-pce-segment-routing-policy-cp make a reference to this? For an implementation of draft-barth-pce-segment-routing-policy-cp, must it support draft-koldychev-pce-multipath ? 4. Section 4.3 leaves me confused. The term 'sub-candidate path' is not used anywhere else to my knowledge, and the concept of ECMP/UCMP makes it sound like the behaviour of multiple SID Lists to me, since a single candidate path will W-ECMP across multiple SID Lists. The use case requirement for encoding objective/constraints was discussed in the past, in Montreal if I recall, to allow the ability to tell PCE different constraints (ex: path1 take red plane, path2 take blue plane) and ECMP across it. I think this is certainly a valid use case, but it's not clear to me from this section how that's achieved within PCEP encoding and how that fits into the SR Policy model. How does a sub-candidate path differ from a SID list? Or are they the same? Then why all the language about PCEP tunnel and candidate path? Or is the intent to basically signal multiple candidate paths with the intent to ECMP across the SID Lists contained within them? I get a slight impression that there's a either (intentionally or unintentionally) potentially a logical new containment introduced in the SR Policy model in order to encode optimization objective/constraints for PCE. The language of mapping sub-candidate paths each to a PCEP Tunnel also leaves me confused since a candidate path is a PCEP Tunnel as described in section 4.1. Some additional clarification, diagrams or examples in this section is needed I think. Regarding the adoption call: Overall I think the draft should be adopted by the PCE WG. Having PCE instantiate and compute paths for a Candidate path, with full awareness of the context of an SR Policy is a natural fit. The existing implementations of SR Policy via BGP shows that SR Policy instantiation from a controller to the network is important, however in some deployments and platforms using PCEP would be a better fit than BGP. Using PCEP also helps ease the feedback complexity in reporting state back to the controller, felt by BGP. With the exception of section 4.3 to me, I think the document reflects the overall architecture and model described in draft-ietf-spring-segment-routing-policy and follows a sensible encoding model in PCEP in its mappings of PLSP-ID/Candidate path and use of association. I think section 4.3 need to be evaluated and discussed in more detail - whether I think it should be before or after adoption I'll leave up to the WG consensus on this section ... Thanks Andrew On 2020-06-07, 3:46 AM, "Pce on behalf of Dhruv Dhody" <[email protected] on behalf of [email protected]> wrote: Hi WG, This email begins the WG adoption poll for draft-barth-pce-segment-routing-policy-cp-06. https://datatracker.ietf.org/doc/draft-barth-pce-segment-routing-policy-cp/06/ Should this draft be adopted by the PCE WG? Please state your reasons - Why / Why not? What needs to be fixed before or after adoption? Are you willing to work on this draft? Review comments should be posted to the list. This adoption poll will end on 22nd June 2020. Thanks! Dhruv & Julien _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
