Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

[Mike Koldychev]

Hi Boris,

Sorry for the late reply...

1.1) Yes, it's basically always going to be set to 1. There isn't expected to 
be any other values there in the future, this field is basically unused.

1.2) I've removed that sentence in version 15. I think the intent was that the 
PCC can have multiple loopbacks, but this text just adds confusion and isn't 
necessary.

1.3) Normally, when the PCE creates a new LSP in a new Association, it can 
choose the Association ID however it wants. So if the ID is some 16-bit number, 
then the PCE can choose a random number for example. But in the SR Policy 
use-case this can lead to a (very rare) race condition when two PCEs both 
decide to create the same SR Policy at exactly the same time. Each PCE would 
choose some random number as the Association ID and each PCE sends its random 
Association ID in its PCInitiate message. Now the PCC would receive two 
PCInitiate messages asking to create the same SR Policy (same color and 
endpoint), but these two messages have different Association IDs. To avoid this 
mess, it's just cleaner to make Association ID == Color + Endpoint, so that the 
two PCEs don't have to pick a "random number" for the Association ID. They 
always send a deterministic value. Hopefully that clears it up?

Thanks,
Mike.

On Tuesday, January 23rd, 2024 at 5:17 AM, Boris Khasanov 
 wrote:

> Hi all,
> Sorry for being late, I fully support the adoption too.
>
> Some small comments for the better understanding:
> 1) Section 4.1 Association parameters
> 1.1) Association ID which should be set to 1, will it never be used and 
> should be kept as '1" ?
>
> 1.2) This sentence sounds confusing, IMO:
> "If the PCC receives a PCInit message with the Association Source set not to 
> the headend IP but to some globally unique IP address that the headend owns, 
> then the PCC SHOULD accept the PCInit message and create the SRPA with the 
> Association Source that was sent in the PCInit message."
>
> Why do we need such dualism here? I mean this other IP-address which should 
> be delivered to PCE in advance etc. Complicates an implementation IMO.
>
> 1.3) Also not exactly clear how these parameters can help to escape "a race 
> condition when multiple PCEP speakers want to create the same SR Policy at 
> the same time." Can you please clarify?
> 2) Can you please add into section 7 (Implementation status) some info/plans 
> about the Invalidation TLV. It is very important mechanism in practice.
>
> Thank you.
>
> SY,
> Boris
>
> 08.01.2024, 13:29, "Dhruv Dhody" :
>
>> Hi WG,
>>
>> This email starts a 2-weeks working group last call for 
>> draft-ietf-pce-segment-routing-policy-cp-12.
>>
>> https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/
>>
>> Please indicate your support or concern for this draft. If you are opposed 
>> to the progression of the draft to RFC, please articulate your concern. If 
>> you support it, please indicate that you have read the latest version and it 
>> is ready for publication in your opinion. As always, review comments and 
>> nits are most welcome.
>>
>> The WG LC will end on Monday 22nd January 2024.
>>
>> A general reminder to the WG to be more vocal during the last-call/adoption.
>>
>> 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] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

[Mike Koldychev (mkoldych)]

Hi Dhruv,

There are still a few minor pending comments that I plan to address, so we will 
need a version -14.

Thanks,
Mike.

From: Pce  On Behalf Of Dhruv Dhody
Sent: Monday, January 22, 2024 11:26 PM
To: pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-segment-routing-policy...@ietf.org
Subject: Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi WG,

The WGLC has ended. Thanks to everyone who contributed with review comments 
during this last call discussion. These are very helpful to gauge the consensus 
of the WG to move the draft forward towards publication.

Authors,

Thanks for posting -13. Is there a need for another version update to handle 
any pending comments or are we ready to go?

Thanks!
Dhruv & Julien





On Mon, Jan 8, 2024 at 3:58 PM Dhruv Dhody 
mailto:d...@dhruvdhody.com>> wrote:
Hi WG,

This email starts a 2-weeks working group last call for 
draft-ietf-pce-segment-routing-policy-cp-12.

https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/

Please indicate your support or concern for this draft. If you are opposed to 
the progression of the draft to RFC, please articulate your concern. If you 
support it, please indicate that you have read the latest version and it is 
ready for publication in your opinion. As always, review comments and nits are 
most welcome.

The WG LC will end on Monday 22nd January 2024.

A general reminder to the WG to be more vocal during the last-call/adoption.

Thanks,
Dhruv & Julien


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

Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

[Boris Khasanov]

Hi all,Sorry for being late, I fully support the adoption too. Some small comments for the better understanding:1) Section 4.1 Association parameters1.1) Association ID which should be set to 1, will it never be used and should be kept as '1" ? 1.2) This sentence sounds confusing, IMO:"If the PCC receives a PCInit message with the Association Source set not to the headend IP but to some globally unique IP address that the headend owns, then the PCC SHOULD accept the PCInit message and create the SRPA with the Association Source that was sent in the PCInit message." Why do we need such dualism here? I mean this other IP-address which should be  delivered to PCE in advance etc. Complicates an implementation IMO. 1.3) Also not exactly clear how these parameters can  help to escape "a race condition when multiple PCEP speakers want to create the same SR Policy at the same time." Can you please clarify?2) Can you please add into  section 7 (Implementation status)  some info/plans about  the Invalidation TLV. It is very important mechanism in practice. Thank you. SY,Boris 08.01.2024, 13:29, "Dhruv Dhody" :Hi WG,This email starts a 2-weeks working group last call for draft-ietf-pce-segment-routing-policy-cp-12. https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/  Please indicate your support or concern for this draft. If you are opposed to the progression of the draft to RFC, please articulate your concern. If you support it, please indicate that you have read the latest version and it is ready for publication in your opinion. As always, review comments and nits are most welcome.The WG LC will end on Monday 22nd January 2024.A general reminder to the WG to be more vocal during the last-call/adoption.Thanks,Dhruv & Julien   ,___Pce mailing listPce@ietf.orghttps://www.ietf.org/mailman/listinfo/pce___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

[Dhruv Dhody]

Hi WG,

The WGLC has ended. Thanks to everyone who contributed with review comments
during this last call discussion. These are very helpful to gauge the
consensus of the WG to move the draft forward towards publication.

Authors,

Thanks for posting -13. Is there a need for another version update to
handle any pending comments or are we ready to go?

Thanks!
Dhruv & Julien





On Mon, Jan 8, 2024 at 3:58 PM Dhruv Dhody  wrote:

> Hi WG,
>
> This email starts a 2-weeks working group last call for
> draft-ietf-pce-segment-routing-policy-cp-12.
>
> https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/
>
>
> Please indicate your support or concern for this draft. If you are opposed
> to the progression of the draft to RFC, please articulate your concern. If
> you support it, please indicate that you have read the latest version and
> it is ready for publication in your opinion. As always, review comments and
> nits are most welcome.
>
> The WG LC will end on Monday 22nd January 2024.
>
> A general reminder to the WG to be more vocal during the
> last-call/adoption.
>
> Thanks,
> Dhruv & Julien
>
>
>
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

[chen.ran]

Hi  Dhruv & WG,
I have read the latest version and support WG LC.

Best Regards,
Ran


Original


From: DhruvDhody 
To: pce@ietf.org ;
Cc: pce-chairs 
;draft-ietf-pce-segment-routing-policy...@ietf.org 
;
Date: 2024年01月08日 18:29
Subject: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

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



Hi WG,

This email starts a 2-weeks working group last call for 
draft-ietf-pce-segment-routing-policy-cp-12.


https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/  

Please indicate your support or concern for this draft. If you are opposed to 
the progression of the draft to RFC, please articulate your concern. If you 
support it, please indicate that you have read the latest version and it is 
ready for publication in your opinion. As always, review comments and nits are 
most welcome.

The WG LC will end on Monday 22nd January 2024.

A general reminder to the WG to be more vocal during the last-call/adoption.
Thanks,
Dhruv & Julien___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

[????????????]

Hi WG,

I have read the document and I support the progression to RFC.


Best regards,
Gao xing.




From: Dhruv Dhody<mailto:d...@dhruvdhody.com>
Date: 2024-01-08 18:28
To: pce@ietf.org<mailto:pce@ietf.org>
CC: pce-chairs<mailto:pce-cha...@ietf.org>; 
draft-ietf-pce-segment-routing-policy...@ietf.org<mailto:draft-ietf-pce-segment-routing-policy...@ietf.org>
Subject: WGLC for draft-ietf-pce-segment-routing-policy-cp-12
Hi WG,

This email starts a 2-weeks working group last call for 
draft-ietf-pce-segment-routing-policy-cp-12.

https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/

Please indicate your support or concern for this draft. If you are opposed to 
the progression of the draft to RFC, please articulate your concern. If you 
support it, please indicate that you have read the latest version and it is 
ready for publication in your opinion. As always, review comments and nits are 
most welcome.

The WG LC will end on Monday 22nd January 2024.

A general reminder to the WG to be more vocal during the last-call/adoption.

Thanks,
Dhruv & Julien



如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 
hqs-s...@chinaunicom.cn，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received 
this email in error please notify us immediately by e-mail. Please reply to 
hqs-s...@chinaunicom.cn ,you can unsubscribe from this mail. We will 
immediately remove your information from send catalogue of our.
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

[Cheng Li]

Hi Mike,

Thanks for the quick reply. I think my comments are almost addressed. Please 
see my reply inline.

Thanks,
Cheng


From: Mike Koldychev (mkoldych) 
Sent: Tuesday, January 16, 2024 6:05 PM
To: Cheng Li ; Dhruv Dhody ; pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-segment-routing-policy...@ietf.org; mkold...@proton.me
Subject: RE: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi Cheng,

Thanks for your review! Comments inline with .

Thanks,
Mike.


From: Cheng Li 
mailto:c.l=40huawei@dmarc.ietf.org>>
Sent: Tuesday, January 16, 2024 11:09 AM
To: Dhruv Dhody mailto:d...@dhruvdhody.com>>; 
pce@ietf.org<mailto:pce@ietf.org>
Cc: pce-chairs mailto:pce-cha...@ietf.org>>; 
draft-ietf-pce-segment-routing-policy...@ietf.org<mailto:draft-ietf-pce-segment-routing-policy...@ietf.org>
Subject: RE: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi WG,

I read the document and support the WGLC.
However, I also have some minor comments below.


1.
Abstract

A Segment Routing (SR) Policy 
[RFC9256<https://www.rfc-editor.org/info/rfc9256>] is a non-empty set of SR 
Candidate Paths, that share the same  tuple.
1.Nits: s/that/which.

Sure.


2.share the same <> tuple?

Sorry, not clear what your comment is here? The text is referring to the 
3-tuple that identifies the SR Policy, from here: 
https://www.rfc-editor.org/rfc/rfc9256.html#name-identification-of-an-sr-pol

well， I see your point. But recommend to rephrase the text. But this is not 
a big deal, you can ignore it.

3.This document extends [RFC8664<https://www.rfc-editor.org/info/rfc8664>] to 
fully support the SR Policy construct.
fully? suggest to remove this world. The SR policy is developing, so it can not 
be fully supported now I guess.

Sure, I will remove the “fully”.



4.
Introduction

PCEP Extensions for Segment Routing 
[RFC8664<https://www.rfc-editor.org/info/rfc8664>] specifies extensions that 
allow PCEP to work with basic SR-TE 
paths.¶<https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-12#section-1-1>
s/specifies/specify

Sure, I can just use the RFC Number, instead of the full name.

it works to me.

PCEP Extensions for Establishing Relationships Between Sets of LSPs 
[RFC8697<https://www.rfc-editor.org/info/rfc8697>] introduces
s/introduces/introduce because of extensions?  or you only wanto to list the 
name of the RFC here? anyway, all are nits. Normally, we use RFC as the 
subject directly.

Sure, I can just use the RFC Number, instead of the full name.

great

5. again. Suggest to delete 'fully' in the last paragraph of Introduction.

Will do.


6.
SR Policy Association. PCEP ASSOCATION that describes the SR Policy. Can refer 
to the PCEP object or to the group of LSPs that belong to the Association. This 
should be clear from the 
context.¶<https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-12#section-2-2.4>

suggest to rephrase this description to be more formal? , too casual to me.

Sure, will rephrase. There was a prior comment about this as well.


7.When these rules are not satisfied, the PCE MUST send a PCErr message with 
Error-Type = 26 "Association Error", Error Value = TBD8

Only the PCE sends? do we have any case that a PCC may send this error?

True, it should be “PCEP speaker”, not “PCE”. Thanks.

nice
8.

This Association Type is dynamic in nature, thus operator-configured 
Association Range MUST NOT be set for this Association type and MUST be 
ignored.¶<https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-12#section-4-2>

Sorry I do not understand this paragraph. What do you mean this association 
type is dynamic in nature?

It’s referring to this: https://www.rfc-editor.org/rfc/rfc8697.html#section-3.4 
. The text is basically saying that this Association Type is fully dynamic. I’m 
not sure if this is necessary to say, or if we can rephase it to be clearer? 
Any suggestions?

 All right, I see your point. If you decided to use 6, then the text works 
to me. But I will suggest to add a reference to explain that, and also, it is 
not dynamic in nature. Some of them can be configured so it is dynamic. We 
chosen 6, so it is not dynamic anymore, isn’t it?
9.
·Association ID (16-bit): set to 
"1".¶<https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-12#section-4.1-3.3>
why the ID must be set as 1? do you mean a association is identified by 
association source, color, and endpoint in extended association ID TLV? so we 
do not need Association ID?
or you like to use This ID 1 to avoid the race case between multiple PCE?

Yes, the association is identified by , so this 16-bit 
field is not useful. We set it to “1” to avoid using “0”, which is a reserved 
value for that field. I can put a sentence to clarify this in the text.

All right

10.

   0   1   

Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

[xiong.quan]

Hi Mike,

Thanks for your reply!
I am not sure about this use case. From my understanding, serveral candidate 
paths may be associated to a SR policy in PCE environment, (if this may happen) 
but if all candidate paths are judged to invalid by PCE (for example as per 
draft-chen-pce-sr-policy-cp-validty), then the association should be removed. 
And another confusion about the "MBZ" in figure 3. May I know the full name of 
this abbreviation? Thanks!

Best Regards,
Quan

Original


From: MikeKoldychev(mkoldych) 
To: 熊泉00091065;d...@dhruvdhody.com 
;draft-ietf-pce-segment-routing-policy...@ietf.org 
;
Cc: pce@ietf.org ;pce-cha...@ietf.org 
;mkold...@proton.me ;
Date: 2024年01月17日 00:47
Subject: RE: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12



Hi Quan,
 
Thanks for your review! Comments inline with .
 
Thanks,
Mike.
 

From: Pce  On Behalf Of xiong.q...@zte.com.cn
 Sent: Sunday, January 14, 2024 10:01 PM
 To: d...@dhruvdhody.com; draft-ietf-pce-segment-routing-policy...@ietf.org
 Cc: pce@ietf.org; pce-cha...@ietf.org
 Subject: Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12


 
 
Hi PCE WG, Authors, I have reviewed the latest version in details and I feel 
this draft is good written and I support the progression to RFC.
And I have two minor suggestions.
A，I noticed the [I-D.ietf-idr-segment-routing-te-policy] and 
[I-D.ietf-pce-multipath] are in the Normative References. I am not sure if the 
two drafts should be moved to Informative References when progess to RFC.

Good suggestion, thanks.

B, AS per [RFC9256] section 8.1, an SR policy is invalid when all candidate 
paths are invalid and the SR policy should  transit to invalid state including 
removing the SR Policy and BSID and so.
Maybe it is better to consider or clarify that in the PCEP SR policy. Thanks!

Sorry, what do you mean to clarify it? Isn’t it already clear from RFC9256?

Best Regards,
Quan
 
<https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/Please
 indicate your support or concern for this <<<___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

[Mike Koldychev (mkoldych)]

Hi Cheng,

Thanks for your review! Comments inline with .

Thanks,
Mike.


From: Cheng Li 
Sent: Tuesday, January 16, 2024 11:09 AM
To: Dhruv Dhody ; pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-segment-routing-policy...@ietf.org
Subject: RE: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi WG,

I read the document and support the WGLC.
However, I also have some minor comments below.


1.
Abstract

A Segment Routing (SR) Policy 
[RFC9256<https://www.rfc-editor.org/info/rfc9256>] is a non-empty set of SR 
Candidate Paths, that share the same  tuple.
1.Nits: s/that/which.

Sure.


2.share the same <> tuple?

Sorry, not clear what your comment is here? The text is referring to the 
3-tuple that identifies the SR Policy, from here: 
https://www.rfc-editor.org/rfc/rfc9256.html#name-identification-of-an-sr-pol


3.This document extends [RFC8664<https://www.rfc-editor.org/info/rfc8664>] to 
fully support the SR Policy construct.
fully? suggest to remove this world. The SR policy is developing, so it can not 
be fully supported now I guess.

Sure, I will remove the “fully”.



4.
Introduction

PCEP Extensions for Segment Routing 
[RFC8664<https://www.rfc-editor.org/info/rfc8664>] specifies extensions that 
allow PCEP to work with basic SR-TE 
paths.¶<https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-12#section-1-1>
s/specifies/specify

Sure, I can just use the RFC Number, instead of the full name.


PCEP Extensions for Establishing Relationships Between Sets of LSPs 
[RFC8697<https://www.rfc-editor.org/info/rfc8697>] introduces
s/introduces/introduce because of extensions?  or you only wanto to list the 
name of the RFC here? anyway, all are nits. Normally, we use RFC as the 
subject directly.

Sure, I can just use the RFC Number, instead of the full name.


5. again. Suggest to delete 'fully' in the last paragraph of Introduction.

Will do.


6.
SR Policy Association. PCEP ASSOCATION that describes the SR Policy. Can refer 
to the PCEP object or to the group of LSPs that belong to the Association. This 
should be clear from the 
context.¶<https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-12#section-2-2.4>

suggest to rephrase this description to be more formal? , too casual to me.

Sure, will rephrase. There was a prior comment about this as well.


7.When these rules are not satisfied, the PCE MUST send a PCErr message with 
Error-Type = 26 "Association Error", Error Value = TBD8

Only the PCE sends? do we have any case that a PCC may send this error?

True, it should be “PCEP speaker”, not “PCE”. Thanks.


8.

This Association Type is dynamic in nature, thus operator-configured 
Association Range MUST NOT be set for this Association type and MUST be 
ignored.¶<https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-12#section-4-2>

Sorry I do not understand this paragraph. What do you mean this association 
type is dynamic in nature?

It’s referring to this: https://www.rfc-editor.org/rfc/rfc8697.html#section-3.4 
. The text is basically saying that this Association Type is fully dynamic. I’m 
not sure if this is necessary to say, or if we can rephase it to be clearer? 
Any suggestions?


9.
·Association ID (16-bit): set to 
"1".¶<https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-12#section-4.1-3.3>
why the ID must be set as 1? do you mean a association is identified by 
association source, color, and endpoint in extended association ID TLV? so we 
do not need Association ID?
or you like to use This ID 1 to avoid the race case between multiple PCE?

Yes, the association is identified by , so this 16-bit 
field is not useful. We set it to “1” to avoid using “0”, which is a reserved 
value for that field. I can put a sentence to clarify this in the text.



10.

   0   1   2   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Type  | Length|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   |
  ~   SR Policy Name  ~
  |   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 
2<https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-12#figure-2>:
 The SRPOLICY-POL-NAME TLV 
format<https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-12#name-the-srpolicy-pol-name-tlv-f>

Though I can not image what may be added to this TLV now. But I think reserving 
0 bits for a new TLV is not a good decision.
same for "SRPOLICY-CPATH-NAME" TLV

It’s not r

Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

[Mike Koldychev (mkoldych)]

Hi Quan,

Thanks for your review! Comments inline with .

Thanks,
Mike.

From: Pce  On Behalf Of xiong.q...@zte.com.cn
Sent: Sunday, January 14, 2024 10:01 PM
To: d...@dhruvdhody.com; draft-ietf-pce-segment-routing-policy...@ietf.org
Cc: pce@ietf.org; pce-cha...@ietf.org
Subject: Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12




Hi PCE WG, Authors,

I have reviewed the latest version in details and I feel this draft is good 
written and I support the progression to RFC.

And I have two minor suggestions.

A，I noticed the [I-D.ietf-idr-segment-routing-te-policy] and 
[I-D.ietf-pce-multipath] are in the Normative References. I am not sure if the 
two drafts should be moved to Informative References when progess to RFC.

Good suggestion, thanks.


B, AS per [RFC9256] section 8.1, an SR policy is invalid when all candidate 
paths are invalid and the SR policy should  transit to invalid state including 
removing the SR Policy and BSID and so.

Maybe it is better to consider or clarify that in the PCEP SR policy. Thanks!

Sorry, what do you mean to clarify it? Isn’t it already clear from RFC9256?


Best Regards,

Quan



<https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/Please
 indicate your support or concern for this <<<___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

[Mike Koldychev (mkoldych)]

Hi Samuel,

IMO, it’s nice to have explicit and granular capability advertisement, so that 
the PCEP speakers are aware of what the other side supports. It’s not purely 
informational, some of these TLVs modify the PCC behavior, so the PCE may want 
to know in advance whether PCC will follow instructions or just ignore them.

Thanks,
Mike.

From: Samuel Sidor (ssidor) 
Sent: Friday, January 12, 2024 3:37 AM
To: Mike Koldychev (mkoldych) ; 
draft-ietf-pce-segment-routing-policy...@ietf.org
Cc: pce-chairs ; pce@ietf.org; Dhruv Dhody 

Subject: RE: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Thanks Mike,

Agreed. Just one response to capability part:

Do we even need flags in SR Policy Capability TLV for advertising support of 
those various TLVs then? Or is that purely for informational (with no impact on 
processing of actual TLV)? If it is pure informational, then maybe consider 
adding some simple statement specifying it explicitly.) Because my 
understanding is that purpose of rule for ignoring unknown TLVs by default is 
specifically to avoid unnecessary capabilities.

Regards,
Samuel

From: Mike Koldychev (mkoldych) mailto:mkold...@cisco.com>>
Sent: Thursday, January 11, 2024 7:22 PM
To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>; 
draft-ietf-pce-segment-routing-policy...@ietf.org<mailto:draft-ietf-pce-segment-routing-policy...@ietf.org>
Cc: pce-chairs mailto:pce-cha...@ietf.org>>; 
pce@ietf.org<mailto:pce@ietf.org>; Dhruv Dhody 
mailto:d...@dhruvdhody.com>>
Subject: RE: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi Samuel,

Thanks for the feedback! Comments inline with .

Thanks,
Mike.

From: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>
Sent: Wednesday, January 10, 2024 4:25 AM
To: 
draft-ietf-pce-segment-routing-policy...@ietf.org<mailto:draft-ietf-pce-segment-routing-policy...@ietf.org>
Cc: pce-chairs mailto:pce-cha...@ietf.org>>; 
pce@ietf.org<mailto:pce@ietf.org>; Dhruv Dhody 
mailto:d...@dhruvdhody.com>>
Subject: RE: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi all,

Thanks a lot, to authors for doing this work. It is really important for 
supporting SR policies in PCEP. I support progress of this document to RFC.

A few minor comments:


  *   For TLVs in association section, there is explicitly mentioned that those 
are “single instance” TLVs (single instance processed, other instances 
ignored), but I don’t see it mentioned for TLVs in Section 5. Are those “single 
instance” TLVs as well?

Yes they are, I will add that statement to Section 5 as well, thanks.



  *   “SR Policy Capability TLV” is defining capabilities for 
TLVs/functionality in Section 5. It may be good to specify how those 
capabilities should be handled – e.g. if P flag (indicates support for 
“COMPUTATION-PRIORITY TLV”) is not set in “SR Policy Capability TLV”, but PCEP 
peer received that TLV. Is PCEP peer supposed to reject it or it is still 
acceptable to use it? If it should be rejected, what should be the PCError to 
reject it (unknown TLVs should be ignored by default)?

I think generic PCEP behavior for treating unknown TLVs (ignore them) is 
correct when a PCEP speaker receives a TLV that it did not advertise capability 
for. Do we agree? If we agree, then I don’t see a need to add a statement 
re-iterating generic PCEP behavior.



  *   “SR Policy name” is defined as CP attribute in section “SR Policy 
Candidate Path Attributes”. Is there any reason for that? I would assume that 
it is policy attribute and not CP attribute. Can policy name be different for 
different candidate-path of same policy?

I think your question is answered in the SR Policy Architecture RFC: 
https://www.rfc-editor.org/rfc/rfc9256.html#section-2.1-6
“””
An implementation MAY allow the assignment of a symbolic name comprising 
printable ASCII [RFC0020] characters (i.e., 0x20 to 0x7E) to an SR Policy to 
serve as a user-friendly attribute for debugging and troubleshooting purposes. 
Such symbolic names may identify an SR Policy when the naming scheme ensures 
uniqueness. The SR Policy name MAY also be signaled along with a candidate path 
of the SR Policy (refer to Section 2.2). An SR Policy MAY have multiple names 
associated with it in the scenario where the headend receives different SR 
Policy names along with different candidate paths for the same SR Policy via 
the same or different sources.
“””
The unit of signaling in PCEP (and BGP-TE) is the Candidate Path. If we had 
another unit of signaling per-Association, then we could put the Policy Name 
there.



  *   Terminology section is defining abbreviation “SRPA” for SR Policy 
Association, but “SR Policy Association (SRPA)” or “SR Policy Association”is 
then used in a few places in the document. It may be better to replace it.

Thanks, I’ll update that.



  *   “SR-POLICY-CAPABLITY” -> “SR-POLICY-CAPABILITY” in section 5.1 (typo)

Thanks, I’ll fi

Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

[Mike Koldychev (mkoldych)]

Hi Gyan,

Thanks for your review! Comments inline with .

Thanks,
Mike.

From: Gyan Mishra 
Sent: Friday, January 12, 2024 1:31 AM
To: Dhruv Dhody 
Cc: draft-ietf-pce-segment-routing-policy...@ietf.org; pce@ietf.org; pce-chairs 

Subject: Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12


I support publication.

I have reviewed v12 and have a few minor comments.

At the end of the abstract section you could say forwarding planes of SR 
instead of dataplane.  As the data planes of SR would be MPLS and IPv6.

Old
The mechanism is applicable to all data planes of SR (MPLS, SRv6, etc.).

New

The mechanism is applicable to SR forwarding planes of SR (SR-MPLS SRv6, etc.).

OK thanks. I wasn’t aware of this terminology: data plane vs forwarding plane.



My understanding is that as RFC 8664 is the base PCEP extension for SR and this 
draft is an add on to the base SR PCEP extension to provide the CP support.

My thoughts was a more appropriate name for the draft as "PCEP extension for SR 
Policy Candidate paths" or "PCEP SR Extension for Candidate paths"


I think we can go with “PCEP Extensions for SR Policy Candidate Paths”, if 
nobody objects.


Kind Regards


[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com>

M 301 502-1347



On Mon, Jan 8, 2024 at 5:29 AM Dhruv Dhody 
mailto:d...@dhruvdhody.com>> wrote:
Hi WG,

This email starts a 2-weeks working group last call for 
draft-ietf-pce-segment-routing-policy-cp-12.

https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/

Please indicate your support or concern for this draft. If you are opposed to 
the progression of the draft to RFC, please articulate your concern. If you 
support it, please indicate that you have read the latest version and it is 
ready for publication in your opinion. As always, review comments and nits are 
most welcome.

The WG LC will end on Monday 22nd January 2024.

A general reminder to the WG to be more vocal during the last-call/adoption.

Thanks,
Dhruv & Julien


___
Pce mailing list
Pce@ietf.org<mailto: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] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

[Mike Koldychev (mkoldych)]

Hi Haomian,

Thanks for your review! Comments inline with .

Thanks,
Mike.

From: Zhenghaomian 
Sent: Thursday, January 11, 2024 10:57 PM
To: Dhruv Dhody ; pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-segment-routing-policy...@ietf.org
Subject: RE: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi WG,

I read the document and think it’s in good shape.

Two minor comments as follow:


1.  In section 4.2 there is a new Error-Value TBD6 “Missing Mandatory TLV” 
(which is also inconsistent with the name in section 6.3), however for existing 
Error-Value under Error-Type “Mandatory Object Missing”, the missed TLVs are 
explicitly specified, so probably we can rename it as “SR policy Cpath ID 
missing” or something similar.

I would like to name the error value as “Missing SR Policy Mandatory TLV”, so 
that we can use the same error value for any other TLVs that are missing, to 
avoid creating a lot of code-points. I’ll make the name consistent with the 
text, thanks.



2.  In section 5.1 there are a few flags defined, do we need to show the 
‘flags’ fonts in the TLV format in Fig. 6? I mean the following:
   0   1   2   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Type  | Length|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Flags|L|S|I|E|P|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Sure, I can add that. Thanks.


Best wishes,
Haomian

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody
Sent: Monday, January 8, 2024 6:29 PM
To: pce@ietf.org<mailto:pce@ietf.org>
Cc: pce-chairs mailto:pce-cha...@ietf.org>>; 
draft-ietf-pce-segment-routing-policy...@ietf.org<mailto:draft-ietf-pce-segment-routing-policy...@ietf.org>
Subject: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi WG,

This email starts a 2-weeks working group last call for 
draft-ietf-pce-segment-routing-policy-cp-12.

https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/

Please indicate your support or concern for this draft. If you are opposed to 
the progression of the draft to RFC, please articulate your concern. If you 
support it, please indicate that you have read the latest version and it is 
ready for publication in your opinion. As always, review comments and nits are 
most welcome.

The WG LC will end on Monday 22nd January 2024.

A general reminder to the WG to be more vocal during the last-call/adoption.

Thanks,
Dhruv & Julien

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

Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

[Cheng Li]

Hi WG,

I read the document and support the WGLC.
However, I also have some minor comments below.


1.
Abstract

A Segment Routing (SR) Policy 
[RFC9256<https://www.rfc-editor.org/info/rfc9256>] is a non-empty set of SR 
Candidate Paths, that share the same  tuple.
1.Nits: s/that/which.
2.share the same <> tuple?
3.This document extends [RFC8664<https://www.rfc-editor.org/info/rfc8664>] to 
fully support the SR Policy construct.
fully? suggest to remove this world. The SR policy is developing, so it can not 
be fully supported now I guess.

4.
Introduction

PCEP Extensions for Segment Routing 
[RFC8664<https://www.rfc-editor.org/info/rfc8664>] specifies extensions that 
allow PCEP to work with basic SR-TE 
paths.¶<https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-12#section-1-1>
s/specifies/specify

PCEP Extensions for Establishing Relationships Between Sets of LSPs 
[RFC8697<https://www.rfc-editor.org/info/rfc8697>] introduces
s/introduces/introduce because of extensions?  or you only wanto to list the 
name of the RFC here? anyway, all are nits. Normally, we use RFC as the 
subject directly.

5. again. Suggest to delete 'fully' in the last paragraph of Introduction.

6.
SR Policy Association. PCEP ASSOCATION that describes the SR Policy. Can refer 
to the PCEP object or to the group of LSPs that belong to the Association. This 
should be clear from the 
context.¶<https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-12#section-2-2.4>

suggest to rephrase this description to be more formal? , too casual to me.

7.When these rules are not satisfied, the PCE MUST send a PCErr message with 
Error-Type = 26 "Association Error", Error Value = TBD8

Only the PCE sends? do we have any case that a PCC may send this error?

8.

This Association Type is dynamic in nature, thus operator-configured 
Association Range MUST NOT be set for this Association type and MUST be 
ignored.¶<https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-12#section-4-2>

Sorry I do not understand this paragraph. What do you mean this association 
type is dynamic in nature?

9.
·Association ID (16-bit): set to 
"1".¶<https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-12#section-4.1-3.3>
why the ID must be set as 1? do you mean a association is identified by 
association source, color, and endpoint in extended association ID TLV? so we 
do not need Association ID?
or you like to use This ID 1 to avoid the race case between multiple PCE?

10.

   0   1   2   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Type  | Length|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   |
  ~   SR Policy Name  ~
  |   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 
2<https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-12#figure-2>:
 The SRPOLICY-POL-NAME TLV 
format<https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-12#name-the-srpolicy-pol-name-tlv-f>

Though I can not image what may be added to this TLV now. But I think reserving 
0 bits for a new TLV is not a good decision.
same for "SRPOLICY-CPATH-NAME" TLV

11. section 8

This document defines one new type for association, which do not add any new 
security concerns beyond those discussed
s/association/ASSOCIATION Object
s/do/does

Thanks,
Cheng



From: Pce  On Behalf Of Dhruv Dhody
Sent: Monday, January 8, 2024 11:29 AM
To: pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-segment-routing-policy...@ietf.org
Subject: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi WG,

This email starts a 2-weeks working group last call for 
draft-ietf-pce-segment-routing-policy-cp-12.

https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/

Please indicate your support or concern for this draft. If you are opposed to 
the progression of the draft to RFC, please articulate your concern. If you 
support it, please indicate that you have read the latest version and it is 
ready for publication in your opinion. As always, review comments and nits are 
most welcome.

The WG LC will end on Monday 22nd January 2024.

A general reminder to the WG to be more vocal during the last-call/adoption.

Thanks,
Dhruv & Julien


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

Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

[xiong.quan]

Hi PCE WG, Authors,I have reviewed the latest version in details and I feel 
this draft is good written and I support the progression to RFC.
And I have two minor suggestions.
A，I noticed the [I-D.ietf-idr-segment-routing-te-policy] and 
[I-D.ietf-pce-multipath] are in the Normative References. I am not sure if the 
two drafts should be moved to Informative References when progess to RFC.
B, AS per [RFC9256] section 8.1, an SR policy is invalid when all candidate 
paths are invalid and the SR policy should  transit to invalid state including 
removing the SR Policy and BSID and so.
Maybe it is better to consider or clarify that in the PCEP SR policy. Thanks!


Best Regards,
Quan

Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

[Samuel Sidor (ssidor)]

Thanks Mike,

Agreed. Just one response to capability part:

Do we even need flags in SR Policy Capability TLV for advertising support of 
those various TLVs then? Or is that purely for informational (with no impact on 
processing of actual TLV)? If it is pure informational, then maybe consider 
adding some simple statement specifying it explicitly.) Because my 
understanding is that purpose of rule for ignoring unknown TLVs by default is 
specifically to avoid unnecessary capabilities.

Regards,
Samuel

From: Mike Koldychev (mkoldych) 
Sent: Thursday, January 11, 2024 7:22 PM
To: Samuel Sidor (ssidor) ; 
draft-ietf-pce-segment-routing-policy...@ietf.org
Cc: pce-chairs ; pce@ietf.org; Dhruv Dhody 

Subject: RE: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi Samuel,

Thanks for the feedback! Comments inline with .

Thanks,
Mike.

From: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>
Sent: Wednesday, January 10, 2024 4:25 AM
To: 
draft-ietf-pce-segment-routing-policy...@ietf.org<mailto:draft-ietf-pce-segment-routing-policy...@ietf.org>
Cc: pce-chairs mailto:pce-cha...@ietf.org>>; 
pce@ietf.org<mailto:pce@ietf.org>; Dhruv Dhody 
mailto:d...@dhruvdhody.com>>
Subject: RE: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi all,

Thanks a lot, to authors for doing this work. It is really important for 
supporting SR policies in PCEP. I support progress of this document to RFC.

A few minor comments:


  *   For TLVs in association section, there is explicitly mentioned that those 
are “single instance” TLVs (single instance processed, other instances 
ignored), but I don’t see it mentioned for TLVs in Section 5. Are those “single 
instance” TLVs as well?

Yes they are, I will add that statement to Section 5 as well, thanks.



  *   “SR Policy Capability TLV” is defining capabilities for 
TLVs/functionality in Section 5. It may be good to specify how those 
capabilities should be handled – e.g. if P flag (indicates support for 
“COMPUTATION-PRIORITY TLV”) is not set in “SR Policy Capability TLV”, but PCEP 
peer received that TLV. Is PCEP peer supposed to reject it or it is still 
acceptable to use it? If it should be rejected, what should be the PCError to 
reject it (unknown TLVs should be ignored by default)?

I think generic PCEP behavior for treating unknown TLVs (ignore them) is 
correct when a PCEP speaker receives a TLV that it did not advertise capability 
for. Do we agree? If we agree, then I don’t see a need to add a statement 
re-iterating generic PCEP behavior.



  *   “SR Policy name” is defined as CP attribute in section “SR Policy 
Candidate Path Attributes”. Is there any reason for that? I would assume that 
it is policy attribute and not CP attribute. Can policy name be different for 
different candidate-path of same policy?

I think your question is answered in the SR Policy Architecture RFC: 
https://www.rfc-editor.org/rfc/rfc9256.html#section-2.1-6
“””
An implementation MAY allow the assignment of a symbolic name comprising 
printable ASCII [RFC0020] characters (i.e., 0x20 to 0x7E) to an SR Policy to 
serve as a user-friendly attribute for debugging and troubleshooting purposes. 
Such symbolic names may identify an SR Policy when the naming scheme ensures 
uniqueness. The SR Policy name MAY also be signaled along with a candidate path 
of the SR Policy (refer to Section 2.2). An SR Policy MAY have multiple names 
associated with it in the scenario where the headend receives different SR 
Policy names along with different candidate paths for the same SR Policy via 
the same or different sources.
“””
The unit of signaling in PCEP (and BGP-TE) is the Candidate Path. If we had 
another unit of signaling per-Association, then we could put the Policy Name 
there.



  *   Terminology section is defining abbreviation “SRPA” for SR Policy 
Association, but “SR Policy Association (SRPA)” or “SR Policy Association”is 
then used in a few places in the document. It may be better to replace it.

Thanks, I’ll update that.



  *   “SR-POLICY-CAPABLITY” -> “SR-POLICY-CAPABILITY” in section 5.1 (typo)

Thanks, I’ll fix that.


Thanks a lot,
Samuel

From: Pce mailto:pce-boun...@ietf.org>> On Behalf Of 
Dhruv Dhody
Sent: Monday, January 8, 2024 11:29 AM
To: pce@ietf.org<mailto:pce@ietf.org>
Cc: pce-chairs mailto:pce-cha...@ietf.org>>; 
draft-ietf-pce-segment-routing-policy...@ietf.org<mailto:draft-ietf-pce-segment-routing-policy...@ietf.org>
Subject: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi WG,

This email starts a 2-weeks working group last call for 
draft-ietf-pce-segment-routing-policy-cp-12.

https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/

Please indicate your support or concern for this draft. If you are opposed to 
the progression of the draft to RFC, please articulate your concern. If you 
support it, please indicate that you have read the latest version and it is 

Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

[Gyan Mishra]

I support publication.

I have reviewed v12 and have a few minor comments.

At the end of the abstract section you could say forwarding planes of SR
instead of dataplane.  As the data planes of SR would be MPLS and IPv6.

Old
The mechanism is applicable to all data planes of SR (MPLS, SRv6, etc.).

New

The mechanism is applicable to SR forwarding planes of SR (SR-MPLS SRv6,
etc.).

My understanding is that as RFC 8664 is the base PCEP extension for SR and
this draft is an add on to the base SR PCEP extension to provide the CP
support.

My thoughts was a more appropriate name for the draft as "PCEP extension
for SR Policy Candidate paths" or "PCEP SR Extension for Candidate paths"

Kind Regards



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*



On Mon, Jan 8, 2024 at 5:29 AM Dhruv Dhody  wrote:

> Hi WG,
>
> This email starts a 2-weeks working group last call for
> draft-ietf-pce-segment-routing-policy-cp-12.
>
> https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/
>
>
> Please indicate your support or concern for this draft. If you are opposed
> to the progression of the draft to RFC, please articulate your concern. If
> you support it, please indicate that you have read the latest version and
> it is ready for publication in your opinion. As always, review comments and
> nits are most welcome.
>
> The WG LC will end on Monday 22nd January 2024.
>
> A general reminder to the WG to be more vocal during the
> last-call/adoption.
>
> 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] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

[Zhenghaomian]

Hi WG,

I read the document and think it’s in good shape.

Two minor comments as follow:


1. In section 4.2 there is a new Error-Value TBD6 “Missing Mandatory TLV” 
(which is also inconsistent with the name in section 6.3), however for existing 
Error-Value under Error-Type “Mandatory Object Missing”, the missed TLVs are 
explicitly specified, so probably we can rename it as “SR policy Cpath ID 
missing” or something similar.

2. In section 5.1 there are a few flags defined, do we need to show the 
‘flags’ fonts in the TLV format in Fig. 6? I mean the following:
   0   1   2   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Type  | Length|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Flags|L|S|I|E|P|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Best wishes,
Haomian

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody
Sent: Monday, January 8, 2024 6:29 PM
To: pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-segment-routing-policy...@ietf.org
Subject: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi WG,

This email starts a 2-weeks working group last call for 
draft-ietf-pce-segment-routing-policy-cp-12.

https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/

Please indicate your support or concern for this draft. If you are opposed to 
the progression of the draft to RFC, please articulate your concern. If you 
support it, please indicate that you have read the latest version and it is 
ready for publication in your opinion. As always, review comments and nits are 
most welcome.

The WG LC will end on Monday 22nd January 2024.

A general reminder to the WG to be more vocal during the last-call/adoption.

Thanks,
Dhruv & Julien


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

Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

[Andrew Stone (Nokia)]

Hi Mike,

Using MUST sounds good to me to keep the interop behavior consistent. Agreed, 
especially since there may be an inability to resolve the SID destination (ex: 
bsid, interdomain etc..) that it’s likely best to just force the resolution to 
rely on Endpoint from SRPA.

Thanks
Andrew

From: "Mike Koldychev (mkoldych)" 
Date: Thursday, January 11, 2024 at 12:53 PM
To: "Andrew Stone (Nokia)" , Dhruv Dhody 
, "pce@ietf.org" 
Cc: pce-chairs , 
"draft-ietf-pce-segment-routing-policy...@ietf.org" 

Subject: RE: WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi Andrew,

Thanks for the feedback! Comments inline with .

Thanks,
Mike.

From: Andrew Stone (Nokia) 
Sent: Tuesday, January 9, 2024 2:05 PM
To: Dhruv Dhody ; pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-segment-routing-policy...@ietf.org
Subject: Re: WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi PCE WG, Authors,

I’ve read the latest version and it was a straight forward read and looks to be 
in good shape. In addition, comments I had during original adoption were also 
all addressed. I support progression of the document. Some minor 
comments/feedback below.

Thanks
Andrew



- Terminology section adjustment:

ORIGINAL
"Can refer to the PCEP object or to the group of LSPs that belong to the 
Association. This should be clear from the context.""

NEW
"Depending on discussion context, it refers to a PCEP object or to a group of 
LSPs that belong to the Association"


Good suggestion, thanks.



- At first I wondered why 'should' instead of must in the below text and 
wondered when would this occur. Realized PCC could determine destination from 
the ERO and occur with PcInit. Perhaps worth giving an example scenario?

ORIGINAL
"... PCEP speaker SHOULD extract the destination from the Endpoint field in the 
SRPA Extended Association ID TLV"

NEW
"... PCEP speaker SHOULD extract the destination from the Endpoint field in the 
SRPA Extended Association ID TLV. For example, a PcInit message does not carry 
LSP-IDENTIFIERS and may not carry an END-POINTS object[RFC8281], therefore PCC 
SHOULD use the destination from the Endpoint field. "


I was unsure about using SHOULD vs MUST in the absence of LSP-IDENTIFIERS and 
END-POINTS. But perhaps it would be better to change it to MUST use Endpoint 
field of SRPA in this case, just to avoid unexpected/divergent behavior in 
implementations. There should be no ambiguity about what the destination of the 
policy is. What do we think about this?

For PCInit, the text in RFC8281 about inferring the destination from the ERO 
refers specifically to RSVP-TE implementations, but in SR-TE it may be 
difficult/impossible to do that inference from the SIDs.



From: Dhruv Dhody mailto:d...@dhruvdhody.com>>
Date: Monday, January 8, 2024 at 5:29 AM
To: "pce@ietf.org<mailto:pce@ietf.org>" mailto:pce@ietf.org>>
Cc: pce-chairs mailto:pce-cha...@ietf.org>>, 
"draft-ietf-pce-segment-routing-policy...@ietf.org<mailto:draft-ietf-pce-segment-routing-policy...@ietf.org>"
 
mailto:draft-ietf-pce-segment-routing-policy...@ietf.org>>
Subject: WGLC for draft-ietf-pce-segment-routing-policy-cp-12
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: mailto:julien.meu...@orange.com>>, 
mailto:andrew.st...@nokia.com>>, 
mailto:d...@dhruvdhody.com>>
Resent-Date: Monday, January 8, 2024 at 5:29 AM


CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.


Hi WG,

This email starts a 2-weeks working group last call for 
draft-ietf-pce-segment-routing-policy-cp-12.

https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/

Please indicate your support or concern for this draft. If you are opposed to 
the progression of the draft to RFC, please articulate your concern. If you 
support it, please indicate that you have read the latest version and it is 
ready for publication in your opinion. As always, review comments and nits are 
most welcome.

The WG LC will end on Monday 22nd January 2024.

A general reminder to the WG to be more vocal during the last-call/adoption.

Thanks,
Dhruv & Julien

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

Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

[Mike Koldychev (mkoldych)]

Hi Huaimo,

Thanks for the feedback! Comments inline with .

Thanks,
Mike.

-Original Message-
From: Huaimo Chen  
Sent: Wednesday, January 10, 2024 11:12 AM
To: Dhruv Dhody ; pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-segment-routing-policy...@ietf.org
Subject: RE: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi Everyone,

I read through the document and have the following comments.

  1.  In Abstract, there are three references (one [RFC9256 ], two [RFC8664]s). 
It seems better to remove these references by rephrasing.
 
Sure, let me see if I can avoid references in the Abstract.


  2.  It seems that an SR Policy has one identifier which consists of Headend, 
color and endpoint.
 *   Should "SR Policy Identifiers uniquely identify the SR Policy within 
the network." in section 3.1 be changed to "An SR Policy Identifier uniquely 
identifies an SR Policy within the network. "?
 *   Should "SR Policy Identifiers consist of:" in section 3.1 be changed 
to "An SR Policy Identifier consists of:"?
 *   "Identifiers" in other sections may be changed accordingly.

Hmmm, I see your point. I guess "SR Policy Identifiers" can be misinterpreted 
to mean that each entry is a separate identifier on its own. 

Sure, I can change 'Identifiers" -> "Identifier" if nobody objects to it.



  1.  It seems that an SR Policy Candidate Path has one Identifier, which 
consists of  Protocol Origin, Originator and  Discriminator.
 *   Should "SR Policy Candidate Path Identifiers uniquely identify the SR 
Policy  Candidate Path within the context of an SR Policy." in section 3.2 be 
changed to "An SR Policy Candidate Path Identifier uniquely identifies an SR 
Policy  Candidate Path within the context of an SR Policy."?
 *   Should "SR Policy Candidate Path Identifiers consist of:" be changed 
to "An SR Policy Candidate Path Identifiers consists of:"?
 *   "Identifiers" in other sections (e.g., section 4.2.2) may be changed 
accordingly.

Sure, I can change 'Identifiers" -> "Identifier" if nobody objects to it.



  1.  In the second sentence of section 5.4, "streering" seems a typo.

Thanks, will fix.


Best Regards,
Huaimo
From: Pce  On Behalf Of Dhruv Dhody
Sent: Monday, January 8, 2024 5:29 AM
To: pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-segment-routing-policy...@ietf.org
Subject: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi WG,

This email starts a 2-weeks working group last call for 
draft-ietf-pce-segment-routing-policy-cp-12.

https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/

Please indicate your support or concern for this draft. If you are opposed to 
the progression of the draft to RFC, please articulate your concern. If you 
support it, please indicate that you have read the latest version and it is 
ready for publication in your opinion. As always, review comments and nits are 
most welcome.

The WG LC will end on Monday 22nd January 2024.

A general reminder to the WG to be more vocal during the last-call/adoption

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

Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

[Mike Koldychev (mkoldych)]

Hi Samuel,

Thanks for the feedback! Comments inline with .

Thanks,
Mike.

From: Samuel Sidor (ssidor) 
Sent: Wednesday, January 10, 2024 4:25 AM
To: draft-ietf-pce-segment-routing-policy...@ietf.org
Cc: pce-chairs ; pce@ietf.org; Dhruv Dhody 

Subject: RE: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi all,

Thanks a lot, to authors for doing this work. It is really important for 
supporting SR policies in PCEP. I support progress of this document to RFC.

A few minor comments:


  *   For TLVs in association section, there is explicitly mentioned that those 
are “single instance” TLVs (single instance processed, other instances 
ignored), but I don’t see it mentioned for TLVs in Section 5. Are those “single 
instance” TLVs as well?

Yes they are, I will add that statement to Section 5 as well, thanks.



  *   “SR Policy Capability TLV” is defining capabilities for 
TLVs/functionality in Section 5. It may be good to specify how those 
capabilities should be handled – e.g. if P flag (indicates support for 
“COMPUTATION-PRIORITY TLV”) is not set in “SR Policy Capability TLV”, but PCEP 
peer received that TLV. Is PCEP peer supposed to reject it or it is still 
acceptable to use it? If it should be rejected, what should be the PCError to 
reject it (unknown TLVs should be ignored by default)?

I think generic PCEP behavior for treating unknown TLVs (ignore them) is 
correct when a PCEP speaker receives a TLV that it did not advertise capability 
for. Do we agree? If we agree, then I don’t see a need to add a statement 
re-iterating generic PCEP behavior.



  *   “SR Policy name” is defined as CP attribute in section “SR Policy 
Candidate Path Attributes”. Is there any reason for that? I would assume that 
it is policy attribute and not CP attribute. Can policy name be different for 
different candidate-path of same policy?

I think your question is answered in the SR Policy Architecture RFC: 
https://www.rfc-editor.org/rfc/rfc9256.html#section-2.1-6
“””
An implementation MAY allow the assignment of a symbolic name comprising 
printable ASCII [RFC0020] characters (i.e., 0x20 to 0x7E) to an SR Policy to 
serve as a user-friendly attribute for debugging and troubleshooting purposes. 
Such symbolic names may identify an SR Policy when the naming scheme ensures 
uniqueness. The SR Policy name MAY also be signaled along with a candidate path 
of the SR Policy (refer to Section 2.2). An SR Policy MAY have multiple names 
associated with it in the scenario where the headend receives different SR 
Policy names along with different candidate paths for the same SR Policy via 
the same or different sources.
“””
The unit of signaling in PCEP (and BGP-TE) is the Candidate Path. If we had 
another unit of signaling per-Association, then we could put the Policy Name 
there.



  *   Terminology section is defining abbreviation “SRPA” for SR Policy 
Association, but “SR Policy Association (SRPA)” or “SR Policy Association”is 
then used in a few places in the document. It may be better to replace it.

Thanks, I’ll update that.



  *   “SR-POLICY-CAPABLITY” -> “SR-POLICY-CAPABILITY” in section 5.1 (typo)

Thanks, I’ll fix that.


Thanks a lot,
Samuel

From: Pce mailto:pce-boun...@ietf.org>> On Behalf Of 
Dhruv Dhody
Sent: Monday, January 8, 2024 11:29 AM
To: pce@ietf.org<mailto:pce@ietf.org>
Cc: pce-chairs mailto:pce-cha...@ietf.org>>; 
draft-ietf-pce-segment-routing-policy...@ietf.org<mailto:draft-ietf-pce-segment-routing-policy...@ietf.org>
Subject: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi WG,

This email starts a 2-weeks working group last call for 
draft-ietf-pce-segment-routing-policy-cp-12.

https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/

Please indicate your support or concern for this draft. If you are opposed to 
the progression of the draft to RFC, please articulate your concern. If you 
support it, please indicate that you have read the latest version and it is 
ready for publication in your opinion. As always, review comments and nits are 
most welcome.

The WG LC will end on Monday 22nd January 2024.

A general reminder to the WG to be more vocal during the last-call/adoption.

Thanks,
Dhruv & Julien

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

Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

[Mike Koldychev (mkoldych)]

Hi Andrew,

Thanks for the feedback! Comments inline with .

Thanks,
Mike.

From: Andrew Stone (Nokia) 
Sent: Tuesday, January 9, 2024 2:05 PM
To: Dhruv Dhody ; pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-segment-routing-policy...@ietf.org
Subject: Re: WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi PCE WG, Authors,

I’ve read the latest version and it was a straight forward read and looks to be 
in good shape. In addition, comments I had during original adoption were also 
all addressed. I support progression of the document. Some minor 
comments/feedback below.

Thanks
Andrew



- Terminology section adjustment:

ORIGINAL
"Can refer to the PCEP object or to the group of LSPs that belong to the 
Association. This should be clear from the context.""

NEW
"Depending on discussion context, it refers to a PCEP object or to a group of 
LSPs that belong to the Association"


Good suggestion, thanks.



- At first I wondered why 'should' instead of must in the below text and 
wondered when would this occur. Realized PCC could determine destination from 
the ERO and occur with PcInit. Perhaps worth giving an example scenario?

ORIGINAL
"... PCEP speaker SHOULD extract the destination from the Endpoint field in the 
SRPA Extended Association ID TLV"

NEW
"... PCEP speaker SHOULD extract the destination from the Endpoint field in the 
SRPA Extended Association ID TLV. For example, a PcInit message does not carry 
LSP-IDENTIFIERS and may not carry an END-POINTS object[RFC8281], therefore PCC 
SHOULD use the destination from the Endpoint field. "


I was unsure about using SHOULD vs MUST in the absence of LSP-IDENTIFIERS and 
END-POINTS. But perhaps it would be better to change it to MUST use Endpoint 
field of SRPA in this case, just to avoid unexpected/divergent behavior in 
implementations. There should be no ambiguity about what the destination of the 
policy is. What do we think about this?

For PCInit, the text in RFC8281 about inferring the destination from the ERO 
refers specifically to RSVP-TE implementations, but in SR-TE it may be 
difficult/impossible to do that inference from the SIDs.



From: Dhruv Dhody mailto:d...@dhruvdhody.com>>
Date: Monday, January 8, 2024 at 5:29 AM
To: "pce@ietf.org<mailto:pce@ietf.org>" mailto:pce@ietf.org>>
Cc: pce-chairs mailto:pce-cha...@ietf.org>>, 
"draft-ietf-pce-segment-routing-policy...@ietf.org<mailto:draft-ietf-pce-segment-routing-policy...@ietf.org>"
 
mailto:draft-ietf-pce-segment-routing-policy...@ietf.org>>
Subject: WGLC for draft-ietf-pce-segment-routing-policy-cp-12
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: mailto:julien.meu...@orange.com>>, 
mailto:andrew.st...@nokia.com>>, 
mailto:d...@dhruvdhody.com>>
Resent-Date: Monday, January 8, 2024 at 5:29 AM


CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.


Hi WG,

This email starts a 2-weeks working group last call for 
draft-ietf-pce-segment-routing-policy-cp-12.

https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/

Please indicate your support or concern for this draft. If you are opposed to 
the progression of the draft to RFC, please articulate your concern. If you 
support it, please indicate that you have read the latest version and it is 
ready for publication in your opinion. As always, review comments and nits are 
most welcome.

The WG LC will end on Monday 22nd January 2024.

A general reminder to the WG to be more vocal during the last-call/adoption.

Thanks,
Dhruv & Julien

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

Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

[Huaimo Chen]

Hi Everyone,

I read through the document and have the following comments.

  1.  In Abstract, there are three references (one [RFC9256 ], two [RFC8664]s). 
It seems better to remove these references by rephrasing.
  2.  It seems that an SR Policy has one identifier which consists of Headend, 
color and endpoint.
 *   Should "SR Policy Identifiers uniquely identify the SR Policy within 
the network." in section 3.1 be changed to "An SR Policy Identifier uniquely 
identifies an SR Policy within the network. "?
 *   Should "SR Policy Identifiers consist of:" in section 3.1 be changed 
to "An SR Policy Identifier consists of:"?
 *   "Identifiers" in other sections may be changed accordingly.



  1.  It seems that an SR Policy Candidate Path has one Identifier, which 
consists of  Protocol Origin, Originator and  Discriminator.
 *   Should "SR Policy Candidate Path Identifiers uniquely identify the SR 
Policy  Candidate Path within the context of an SR Policy." in section 3.2 be 
changed to "An SR Policy Candidate Path Identifier uniquely identifies an SR 
Policy  Candidate Path within the context of an SR Policy."?
 *   Should "SR Policy Candidate Path Identifiers consist of:" be changed 
to "An SR Policy Candidate Path Identifiers consists of:"?
 *   "Identifiers" in other sections (e.g., section 4.2.2) may be changed 
accordingly.



  1.  In the second sentence of section 5.4, "streering" seems a typo.

Best Regards,
Huaimo
From: Pce  On Behalf Of Dhruv Dhody
Sent: Monday, January 8, 2024 5:29 AM
To: pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-segment-routing-policy...@ietf.org
Subject: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi WG,

This email starts a 2-weeks working group last call for 
draft-ietf-pce-segment-routing-policy-cp-12.

https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/

Please indicate your support or concern for this draft. If you are opposed to 
the progression of the draft to RFC, please articulate your concern. If you 
support it, please indicate that you have read the latest version and it is 
ready for publication in your opinion. As always, review comments and nits are 
most welcome.

The WG LC will end on Monday 22nd January 2024.

A general reminder to the WG to be more vocal during the last-call/adoption.

Thanks,
Dhruv & Julien


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

Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

[Samuel Sidor (ssidor)]

Hi all,

Thanks a lot, to authors for doing this work. It is really important for 
supporting SR policies in PCEP. I support progress of this document to RFC.

A few minor comments:


  *   For TLVs in association section, there is explicitly mentioned that those 
are “single instance” TLVs (single instance processed, other instances 
ignored), but I don’t see it mentioned for TLVs in Section 5. Are those “single 
instance” TLVs as well?
  *   “SR Policy Capability TLV” is defining capabilities for 
TLVs/functionality in Section 5. It may be good to specify how those 
capabilities should be handled – e.g. if P flag (indicates support for 
“COMPUTATION-PRIORITY TLV”) is not set in “SR Policy Capability TLV”, but PCEP 
peer received that TLV. Is PCEP peer supposed to reject it or it is still 
acceptable to use it? If it should be rejected, what should be the PCError to 
reject it (unknown TLVs should be ignored by default)?
  *   “SR Policy name” is defined as CP attribute in section “SR Policy 
Candidate Path Attributes”. Is there any reason for that? I would assume that 
it is policy attribute and not CP attribute. Can policy name be different for 
different candidate-path of same policy?
  *   Terminology section is defining abbreviation “SRPA” for SR Policy 
Association, but “SR Policy Association (SRPA)” or “SR Policy Association”is 
then used in a few places in the document. It may be better to replace it.
  *   “SR-POLICY-CAPABLITY” -> “SR-POLICY-CAPABILITY” in section 5.1 (typo)

Thanks a lot,
Samuel

From: Pce  On Behalf Of Dhruv Dhody
Sent: Monday, January 8, 2024 11:29 AM
To: pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-segment-routing-policy...@ietf.org
Subject: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi WG,

This email starts a 2-weeks working group last call for 
draft-ietf-pce-segment-routing-policy-cp-12.

https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/

Please indicate your support or concern for this draft. If you are opposed to 
the progression of the draft to RFC, please articulate your concern. If you 
support it, please indicate that you have read the latest version and it is 
ready for publication in your opinion. As always, review comments and nits are 
most welcome.

The WG LC will end on Monday 22nd January 2024.

A general reminder to the WG to be more vocal during the last-call/adoption.

Thanks,
Dhruv & Julien


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

Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

[Andrew Stone (Nokia)]

Hi PCE WG, Authors,

I’ve read the latest version and it was a straight forward read and looks to be 
in good shape. In addition, comments I had during original adoption were also 
all addressed. I support progression of the document. Some minor 
comments/feedback below.

Thanks
Andrew



- Terminology section adjustment:

ORIGINAL
"Can refer to the PCEP object or to the group of LSPs that belong to the 
Association. This should be clear from the context.""

NEW
"Depending on discussion context, it refers to a PCEP object or to a group of 
LSPs that belong to the Association"



- At first I wondered why 'should' instead of must in the below text and 
wondered when would this occur. Realized PCC could determine destination from 
the ERO and occur with PcInit. Perhaps worth giving an example scenario?

ORIGINAL
"... PCEP speaker SHOULD extract the destination from the Endpoint field in the 
SRPA Extended Association ID TLV"

NEW
"... PCEP speaker SHOULD extract the destination from the Endpoint field in the 
SRPA Extended Association ID TLV. For example, a PcInit message does not carry 
LSP-IDENTIFIERS and may not carry an END-POINTS object[RFC8281], therefore PCC 
SHOULD use the destination from the Endpoint field. "



From: Dhruv Dhody 
Date: Monday, January 8, 2024 at 5:29 AM
To: "pce@ietf.org" 
Cc: pce-chairs , 
"draft-ietf-pce-segment-routing-policy...@ietf.org" 

Subject: WGLC for draft-ietf-pce-segment-routing-policy-cp-12
Resent-From: 
Resent-To: , , 

Resent-Date: Monday, January 8, 2024 at 5:29 AM


CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.


Hi WG,

This email starts a 2-weeks working group last call for 
draft-ietf-pce-segment-routing-policy-cp-12.

https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/

Please indicate your support or concern for this draft. If you are opposed to 
the progression of the draft to RFC, please articulate your concern. If you 
support it, please indicate that you have read the latest version and it is 
ready for publication in your opinion. As always, review comments and nits are 
most welcome.

The WG LC will end on Monday 22nd January 2024.

A general reminder to the WG to be more vocal during the last-call/adoption.

Thanks,
Dhruv & Julien


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

[Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

[Dhruv Dhody]

Hi WG,

This email starts a 2-weeks working group last call for
draft-ietf-pce-segment-routing-policy-cp-12.

https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/

Please indicate your support or concern for this draft. If you are opposed
to the progression of the draft to RFC, please articulate your concern. If
you support it, please indicate that you have read the latest version and
it is ready for publication in your opinion. As always, review comments and
nits are most welcome.

The WG LC will end on Monday 22nd January 2024.

A general reminder to the WG to be more vocal during the last-call/adoption.

Thanks,
Dhruv & Julien
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce