Re: [Pce] WG adoption poll for draft-barth-pce-segment-routing-policy-cp-06

Hi PCE Chairs,

As one of the authors, I support WG adoption of the current draft.

Hi Andrew,

Thanks for your valuable input, let me reply.

1. It would be up to the head-end to decide what CP is active, so I would say that we probably do not need to explicitly state in this draft that only one CP must be active. But should explicitly state how an active CP is distinguished from non-active CP in terms of PCEP flags.

2. Agree, we should reference draft-sivabalan-pce-binding-label-sid, I would say that it's necessary to support binding-label-sid in order to support the current draft, because it's unpractical to have an SR Policy without a binding SID.

3. Agree, we should reference draft-koldychev-pce-multipath. However, it should not be necessary to support draft-koldychev-pce-multipath in order to support the current draft though. But you would only be able to have a single segment-list per CP without supporting draft-koldychev-pce-multipath.

4. I agree with your concerns, we can wait for wider input/consensus and decide what to do about this section.

Thanks,
Mike.

-----Original Message-----
From: Pce <pce-bounces@ietf.org> On Behalf Of Stone, Andrew (Nokia - CA/Ottawa)
Sent: Monday, June 8, 2020 12:05 PM
To: pce@ietf.org
Subject: Re: [Pce] WG adoption poll for draft-barth-pce-segment-routing-policy-cp-06

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" <pce-bounces@ietf.org on behalf of dhruv.ietf@gmail.com> 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
    Pce@ietf.org
    https://www.ietf.org/mailman/listinfo/pce

_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce