[Pce] IPR Poll on draft-barth-pce-segment-routing-policy-cp-06
Hi Authors, In preparation for WG adoption on this draft, I'd like all authors and contributors to confirm on the list that they are in compliance with IETF IPR rules. Please respond (copying the mailing list) to say one of: I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. I am aware of IPR applicable to this draft, and it has already been disclosed to the IETF. I am aware of IPR applicable to this draft, but that has not yet been disclosed to the IETF. I will work to ensure that it will be disclosed in a timely manner. Thanks, - Hari ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] IPR Poll on draft-barth-pce-segment-routing-policy-cp-06
I am not aware of any IPR applicable to this draft. Thanks, Mike. From: Hariharan Ananthakrishnan Sent: Monday, June 8, 2020 11:49 AM To: Mike Koldychev (mkoldych) ; msiva...@gmail.com; Colby Barth ; pengshup...@huawei.com; hooman.bidg...@nokia.com Cc: pce@ietf.org Subject: IPR Poll on draft-barth-pce-segment-routing-policy-cp-06 Hi Authors, In preparation for WG adoption on this draft, I'd like all authors and contributors to confirm on the list that they are in compliance with IETF IPR rules. Please respond (copying the mailing list) to say one of: I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. I am aware of IPR applicable to this draft, and it has already been disclosed to the IETF. I am aware of IPR applicable to this draft, but that has not yet been disclosed to the IETF. I will work to ensure that it will be disclosed in a timely manner. Thanks, - Hari ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
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" 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
Re: [Pce] IPR Poll on draft-barth-pce-segment-routing-policy-cp-06
I am not aware of any IPR applicable to this draft. --Colby From: Hariharan Ananthakrishnan Date: Monday, June 8, 2020 at 11:49 AM To: "Mike Koldychev (mkoldych)" , "msiva...@gmail.com" , Colby Barth , "pengshup...@huawei.com" , "hooman.bidg...@nokia.com" Cc: "pce@ietf.org" Subject: IPR Poll on draft-barth-pce-segment-routing-policy-cp-06 [External Email. Be cautious of content] Hi Authors, In preparation for WG adoption on this draft, I'd like all authors and contributors to confirm on the list that they are in compliance with IETF IPR rules. Please respond (copying the mailing list) to say one of: I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. I am aware of IPR applicable to this draft, and it has already been disclosed to the IETF. I am aware of IPR applicable to this draft, but that has not yet been disclosed to the IETF. I will work to ensure that it will be disclosed in a timely manner. Thanks, - Hari Juniper Business Use Only ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
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 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 l
Re: [Pce] IPR Poll on draft-barth-pce-segment-routing-policy-cp-06
I am not aware of any IPR applicable to this draft. Best regards, Shuping From: Hariharan Ananthakrishnan [mailto:h...@netflix.com] Sent: Monday, June 8, 2020 11:49 PM To: Mike Koldychev (mkoldych) ; msiva...@gmail.com; Colby Barth ; Pengshuping (Peng Shuping) ; hooman.bidg...@nokia.com Cc: pce@ietf.org Subject: IPR Poll on draft-barth-pce-segment-routing-policy-cp-06 Hi Authors, In preparation for WG adoption on this draft, I'd like all authors and contributors to confirm on the list that they are in compliance with IETF IPR rules. Please respond (copying the mailing list) to say one of: I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. I am aware of IPR applicable to this draft, and it has already been disclosed to the IETF. I am aware of IPR applicable to this draft, but that has not yet been disclosed to the IETF. I will work to ensure that it will be disclosed in a timely manner. Thanks, - Hari ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] IPR Poll on draft-barth-pce-segment-routing-policy-cp-06
I am not aware of any IPR applicable to this draft. Thanks Hooman From: Hariharan Ananthakrishnan Sent: Monday, June 8, 2020 11:49 AM To: Mike Koldychev (mkoldych) ; msiva...@gmail.com; Colby Barth ; pengshup...@huawei.com; Bidgoli, Hooman (Nokia - CA/Ottawa) Cc: pce@ietf.org Subject: IPR Poll on draft-barth-pce-segment-routing-policy-cp-06 Hi Authors, In preparation for WG adoption on this draft, I'd like all authors and contributors to confirm on the list that they are in compliance with IETF IPR rules. Please respond (copying the mailing list) to say one of: I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. I am aware of IPR applicable to this draft, and it has already been disclosed to the IETF. I am aware of IPR applicable to this draft, but that has not yet been disclosed to the IETF. I will work to ensure that it will be disclosed in a timely manner. Thanks, - Hari ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] IPR Poll on draft-barth-pce-segment-routing-policy-cp-06
I am not aware of any IPR applicable to this draft. Thanks, Siva On Mon, Jun 8, 2020 at 11:49 AM Hariharan Ananthakrishnan wrote: > Hi Authors, > > In preparation for WG adoption on this draft, I'd like all > authors and contributors to confirm on the list that they are in compliance > with IETF IPR rules. > > Please respond (copying the mailing list) to say one of: > > I am not aware of any IPR applicable to this draft that should be disclosed > in accordance with IETF IPR rules. > > I am aware of IPR applicable to this draft, and it has already been > disclosed to the IETF. > > I am aware of IPR applicable to this draft, but that has not yet been > disclosed to the IETF. I will work to ensure that it will be disclosed in a > timely manner. > > Thanks, > - Hari > > ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
