Re: [Pce] IPR Poll on draft-stone-pce-local-protection-enforcement-02

[Samuel Sidor (ssidor)]

Hi Hari,


I am not aware of any IPR applicable to this draft that should be disclosed

in accordance with IETF IPR rules.

Regards,
Samuel

From: Aissaoui, Mustapha (Nokia - CA/Ottawa) 
Sent: Wednesday, October 21, 2020 11:58 PM
To: Hariharan Ananthakrishnan ; Stone, Andrew (Nokia - 
CA/Ottawa) ; Samuel Sidor (ssidor) ; 
ssiva...@ciena.com
Cc: pce@ietf.org
Subject: RE: IPR Poll on draft-stone-pce-local-protection-enforcement-02

Hi Hari,

I am not aware of any IPR applicable to this draft that should be disclosed in 
accordance with IETF IPR rules.

Regards,
Mustapha.
From: Hariharan Ananthakrishnan mailto:h...@netflix.com>>
Sent: Wednesday, October 21, 2020 3:42 PM
To: Stone, Andrew (Nokia - CA/Ottawa) 
mailto:andrew.st...@nokia.com>>; Aissaoui, Mustapha 
(Nokia - CA/Ottawa) 
mailto:mustapha.aissa...@nokia.com>>; 
ssi...@cisco.com<mailto:ssi...@cisco.com>; 
ssiva...@ciena.com<mailto:ssiva...@ciena.com>
Cc: pce@ietf.org<mailto:pce@ietf.org>
Subject: IPR Poll on draft-stone-pce-local-protection-enforcement-02


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 the 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-stone-pce-local-protection-enforcement-02.

[Samuel Sidor (ssidor)]

Hi WG,

I support WG adoption of this draft (as co-author).

Regards,
Samuel

From: Pce  On Behalf Of Rakesh Gandhi
Sent: Wednesday, October 28, 2020 2:11 PM
Cc: pce@ietf.org
Subject: Re: [Pce] WG adoption poll for 
draft-stone-pce-local-protection-enforcement-02.

Hi WG,
I support the WG adoption of this draft.

Thanks,
Rakesh


On Wed, Oct 21, 2020 at 5:43 PM Mike Koldychev (mkoldych) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Hi,

I have read the latest version of this document and I support WG adoption. It's 
useful for finer control of TI-LFA protection for SR-TE Policy.

Thanks,
Mike.

-Original Message-
From: Pce mailto:pce-boun...@ietf.org>> On Behalf Of 
Dhruv Dhody
Sent: Wednesday, October 21, 2020 9:41 AM
To: pce@ietf.org
Subject: [Pce] WG adoption poll for 
draft-stone-pce-local-protection-enforcement-02.

Hi WG,

This email begins the WG adoption poll for 
draft-stone-pce-local-protection-enforcement-02.

https://datatracker.ietf.org/doc/html/draft-stone-pce-local-protection-enforcement-02

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 9th Nov 2020 (Monday).

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] Adoption of draft-xiong-pce-lsp-flag-03

[Samuel Sidor (ssidor)]

Hi Dhruv,

I support adoption of this draft.

Regards,
Samuel

From: Pce  On Behalf Of Dhruv Dhody
Sent: Tuesday, February 16, 2021 12:28 PM
To: pce@ietf.org
Subject: Re: [Pce] Adoption of draft-xiong-pce-lsp-flag-03

Hi WG,

We *need* to hear from more of you before taking a call on adoption. It is a 
straightforward "house-keeping" document, but we need to see explicit 
expressions of support (and comments).

We are extending the call till Friday, Feb 19th. Please respond with your 
support (or not) for this adoption.

Regards,
Dhruv & Julien

On Mon, Feb 1, 2021 at 11:17 PM Dhruv Dhody 
mailto:d...@dhruvdhody.com>> wrote:
Hi WG,

This email begins the WG adoption poll for draft-xiong-pce-lsp-flag-03.

https://datatracker.ietf.org/doc/html/draft-xiong-pce-lsp-flag-03

This is a small draft that extends the flags in the LSP Objects by
defining a new LSP-EXTENDED-FLAG TLV. Note that the existing
sub-registry "LSP Object Flag Field" is almost fully assigned.

https://www.iana.org/assignments/pcep/pcep.xhtml#lsp-object-flag-field

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.

Please respond by Monday 15th Feb.

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

Re: [Pce] [**EXTERNAL**] WG Adoption of draft-koldychev-pce-multipath-05

[Samuel Sidor (ssidor)]

Hi WG,

I support adoption of this draft.

Regards,
Samuel

From: Pce  On Behalf Of Yadav, Bhupendra
Sent: Wednesday, April 14, 2021 5:14 PM
To: Dhruv Dhody ; pce@ietf.org
Cc: draft-koldychev-pce-multip...@ietf.org
Subject: Re: [Pce] [**EXTERNAL**] WG Adoption of 
draft-koldychev-pce-multipath-05

Hi WG,

I support adoption of this draft by PCE WG. This draft provides a clean and 
logical mechanism for conveying multiple paths peers.
I am willing to work on this draft.

Thanks,
Bhupendra

From: Dhruv Dhody mailto:d...@dhruvdhody.com>>
Sent: April 14, 2021 10:52 AM
To: pce@ietf.org mailto:pce@ietf.org>>
Cc: 
draft-koldychev-pce-multip...@ietf.org
 
mailto:draft-koldychev-pce-multip...@ietf.org>>
Subject: [**EXTERNAL**] WG Adoption of draft-koldychev-pce-multipath-05

Hi WG,

This email begins the WG adoption poll for draft-koldychev-pce-multipath-05.

https://datatracker.ietf.org/doc/html/draft-koldychev-pce-multipath-05 
[datatracker.ietf.org]

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.

Please respond by Wednesday 28th April.

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

Re: [Pce] Request for Implementation info of PCEP SRv6 extension

[Samuel Sidor (ssidor)]

Hi Cheng,

Cisco has full implementation with experimental codepoints of this draft, 
something like this can be added:



   o  Organization: Cisco Systems, Inc.

   o  Implementation: IOS-XR PCE and PCC.

   o  Description: Implementation with experimental codepoints

   o  Maturity Level: Demo

   o  Coverage: Full

   o  Contact: ssi...@cisco.com

Regards,
Samuel

From: Pce  On Behalf Of Chengli (Cheng Li)
Sent: Monday, May 17, 2021 11:26 AM
To: pce@ietf.org
Cc: draft-ietf-pce-segment-routing-i...@ietf.org; pce-chairs 

Subject: [Pce] Request for Implementation info of PCEP SRv6 extension

Hi PCE,

We are going to update the PCEP SRv6 extension draft, and we would like to add 
the implementation information of it.

If you have any info, please reply to this email, we will add it the draft.

Many thanks,
Cheng

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

Re: [Pce] WG Adoption of draft-hsd-pce-sr-p2mp-policy-03

[Samuel Sidor (ssidor)]

I support.

Regards,
Samuel

From: Pce  On Behalf Of Zafar Ali (zali)
Sent: Tuesday, October 19, 2021 6:02 PM
To: Dhruv Dhody ; pce@ietf.org
Cc: draft-hsd-pce-sr-p2mp-pol...@ietf.org
Subject: Re: [Pce] WG Adoption of draft-hsd-pce-sr-p2mp-policy-03

Dear chairs and the WG

The draft covers the PECP aspects for the ongoing work on P2MP SR policies in 
Spring, Bess and Pim working groups
I support the adoption!

Thanks

Regards … Zafar


From: Pce mailto:pce-boun...@ietf.org>> on behalf of 
Dhruv Dhody mailto:d...@dhruvdhody.com>>
Date: Monday, October 18, 2021 at 8:34 AM
To: "pce@ietf.org" mailto:pce@ietf.org>>
Cc: 
"draft-hsd-pce-sr-p2mp-pol...@ietf.org"
 
mailto:draft-hsd-pce-sr-p2mp-pol...@ietf.org>>
Subject: [Pce] WG Adoption of draft-hsd-pce-sr-p2mp-policy-03

Hi WG,

This email begins the WG adoption poll for draft-hsd-pce-sr-p2mp-policy-03.
https://datatracker.ietf.org/doc/draft-hsd-pce-sr-p2mp-policy/

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.

Please respond by Monday 8th Nov.

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

Re: [Pce] IPR Poll for draft-tokar-pce-sid-algo

[Samuel Sidor (ssidor)]

Hi all,

I am not aware of any IPR applicable to this draft that should be disclosed in 
accordance with IETF rules.

Regards,
Samuel

-Original Message-
From: peng.sha...@zte.com.cn  
Sent: Saturday, February 5, 2022 4:04 AM
To: h...@netflix.com
Cc: Alex Tokar (atokar) ; msiva...@gmail.com; 
pengshup...@huawei.com; ts...@juniper.net; mahend.i...@gmail.com; pce@ietf.org; 
Samuel Sidor (ssidor) 
Subject: Re:IPR Poll for draft-tokar-pce-sid-algo

Hi WG,

I am not aware of any IPR applicable to this draft that should be disclosed in 
accordance with IETF rules.

Regards,
PSF


-- 原始邮件 --
发件人：HariharanAnanthakrishnan;
收件人：ssi...@cisco.com; 彭少富10053815; 
ato...@cisco.com; msiva...@gmail.com; 
pengshup...@huawei.com; 
ts...@juniper.net; Mahend Negi;
抄送人：pce@ietf.org;
日期：2022-02-05 01:58:26
主题：IPR Poll for draft-tokar-pce-sid-algo


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 the 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 of draft-tokar-pce-sid-algo-05

[Samuel Sidor (ssidor)]

Hi Ketan, Andrew,

Thanks a lot, for your comments.


  1.  There is already plan to add support for Adjacency SIDs. The draft will 
be extended (hopefully before IETF113 draft submission cut-off)
  2.  I will check that
  3.  (This is related to questions from Andrew) - Yes, this is coming from 
original definition of SR-ERO subobjects without having support for TLVs, so 
its extensibility is problematic. I like your suggestion about ordering of 
optional fields strictly following their bit positions.
  4.  “Loose” name is result of one of previous versions of this draft, where 
we had 2 different flags – “Fallback” and “Loose”, so names were chosen to 
point to difference between them. Then based on comments one of them was 
dropped, so now are free to modify that name if needed (feel free to suggest 
any alternative). I can add some section describing details for Adj SID 
handling.

Regards,
Samuel

From: Pce  On Behalf Of Ketan Talaulikar
Sent: Tuesday, February 8, 2022 6:38 PM
To: Dhruv Dhody 
Cc: draft-tokar-pce-sid-a...@ietf.org; pce@ietf.org
Subject: Re: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi All,

I support the adoption of this document and have the following comments (not 
blocking adoption) for the consideration of the authors & the WG.

1) While the algorithm was originally introduced for Prefix-SID in RFC8402, it 
has since been also extended to cover Adjacency SID. I hope the text in the 
draft can reflect that better. Also, some reference to IGP flex-algo would be 
helpful since that is perhaps one of the key drivers for this work.

2) I would suggest using the "A" flag in the capabilities for Algorithm than 
the currently used "S".

3) For the ERO encoding, we seem to be getting into problematic territory as 
also indicated by Andrew. I would suggest that the ordering of optional fields 
strictly follow the order in which flags are being introduced (i.e. their bit 
position). This way, we at least don't get into random scenarios. I am not sure 
if the ordering in the ASCII art is considered normative. In the future, it 
would be best if we follow pure TLV/sub-TLV based encoding at all times - i.e. 
always introduce capabilities for sub-TLVs even though there might be none 
foreseen at the time of defining a new TLV.

4) For the LSPA Object, I presume the L (loose) flag is actually indicating a 
"non-strict" adherence to the algo constraint. Somehow the "loose" term may 
give a different impression. There is the preference for an algo and then a 
strict requirement for an algo to be followed (e.g. for flex-algo). Also, some 
clarity on the use of Adj-SIDs that don't have an associated algo with them 
would be helpful.

Thanks,
Ketan



On Fri, Feb 4, 2022 at 10:45 PM Dhruv Dhody 
mailto:d...@dhruvdhody.com>> wrote:
Hi WG,

This email begins the WG adoption poll for draft-tokar-pce-sid-algo-05.

https://datatracker.ietf.org/doc/draft-tokar-pce-sid-algo/

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.

Please respond by Monday 21st Feb 2022.

Have a great weekend.

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] WG Adoption of draft-tokar-pce-sid-algo-05

[Samuel Sidor (ssidor)]

Hi Jie,

Combining responses for 1. and 2. as those are related:

Encoding of SID/ERO-subobject level was used, because of multiple reasons:

a)  We may need to signal SL, which is explicitly configured by user (not 
just computed by PCE) and in such case user can potentially mix SIDs with 
different algorithms (if user is accepting risk of loops or if user knows that 
it cannot happen for various reasons in that specific case).

b) Different algorithm ID != different algorithm. With flex-algo different 
ID can be used for identification of same algorithm (e.g. in different IGP 
domains). Mixing SIDs with different algorithm ID in such case is safe, but we 
would not be able to signal such path in PCEP.

c)  Also related to explicit SL – in some cases, user may configure SL 
explicitly on headend. Headend may not be able to resolve complete SL, so it 
may not be sure if algorithm of all SIDs is same.

3. We defined new types in older version of this draft – see:
https://datatracker.ietf.org/doc/html/draft-tokar-pce-sid-algo-03#section-6.1
but there were multiple comments indicating that it is resulting in too many 
new types (we need to extend draft for Adjacency SIDs as well) and it would be 
hard to maintain it for future – e.g. for cases where new NAI types are added. 
With this change we would have to double number of NAI types. Any extension 
like this in the future would double it again.

4. Makes sense. We will align it.

Regards,
Samuel

From: Dongjie (Jimmy) 
Sent: Friday, February 18, 2022 10:09 AM
To: Dhruv Dhody ; pce@ietf.org
Cc: draft-tokar-pce-sid-a...@ietf.org; Mahendra Negi 
Subject: RE: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi WG, chairs,

I just read the latest version of this document. In general incorporating 
Algorithm into PCEP could be useful. While I have the below questions on this 
version and it would be helpful if they can be resolved before adoption.


1.  This document introduces the algorithm constraint in the LSPA object, 
which means the algorithm needs to be considered in the computation of the 
path. IMO this is important for computing a loop-free path. While the draft 
also says that the “the PCE MAY insert prefix SIDs with a different Algorithm 
in order to successfully compute a path.” Mixing SIDs with different algorithms 
in a path has the risk of loops. It is suggested that the document provides 
some analysis about such risk, and the example of scenarios where mixing SIDs 
with different algorithms is safe and desired.


2.  This is related to the first question. If the analysis shows that using 
SIDs with different algorithms in a path is not a good idea, then it would be 
unnecessary to carry the algorithm ID in SERO subobjects, instead carrying it 
as a path attribute would be enough.



3.  Assuming the answer to question 2 is YES, the SR-ERO and SRv6-ERO 
subobjects were defined with a fixed format (do not support sub-TLVs), this 
document introduces an additional optional field to those sub-objects, and use 
a new flag to indicate the existence of the new optional field. To my 
understanding this is not a usual approach for protocol extension. Usually a 
new Type needs to be defined for a new format. It would be necessary to 
understand the implication of using flags to indicate the modification to the 
format of an existing object.



4.  The term “SID Algorithm” in this document is different from that is 
used in the RFCs of SR/SRv6 IGP/BGP extensions, where it is called 
“SR-Algorithm”. Suggest to make them consistent.

Best regards,
Jie

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody
Sent: Friday, February 18, 2022 12:08 PM
To: pce@ietf.org
Cc: 
draft-tokar-pce-sid-a...@ietf.org; 
Mahendra Negi mailto:mahen...@rtbrick.com>>
Subject: Re: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi WG,

A reminder to please respond to the WG adoption poll by Monday!

Please be more vocal. The silence makes it difficult to judge consensus.

Also, the IPR responses from Alex, Shuping, and Mahendra are missing still.

Thanks!
Dhruv & Julien

On Fri, Feb 4, 2022 at 10:44 PM Dhruv Dhody 
mailto:d...@dhruvdhody.com>> wrote:
Hi WG,

This email begins the WG adoption poll for draft-tokar-pce-sid-algo-05.

https://datatracker.ietf.org/doc/draft-tokar-pce-sid-algo/

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.

Please respond by Monday 21st Feb 2022.

Have a great weekend.

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

Re: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

[Samuel Sidor (ssidor)]

Hi Jie,

Thanks for your comments. Please see inline :

Regards,
Samuel

From: Dongjie (Jimmy) 
Sent: Monday, February 21, 2022 4:45 PM
To: Samuel Sidor (ssidor) 
Cc: draft-tokar-pce-sid-a...@ietf.org; Dhruv Dhody ; 
pce@ietf.org; Mahendra Negi 
Subject: RE: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi Samuel,

Thanks for your reply. Please see further inline:

From: Samuel Sidor (ssidor) [mailto:ssi...@cisco.com]
Sent: Friday, February 18, 2022 7:27 PM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>
Cc: 
draft-tokar-pce-sid-a...@ietf.org<mailto:draft-tokar-pce-sid-a...@ietf.org>; 
Dhruv Dhody mailto:d...@dhruvdhody.com>>; 
pce@ietf.org<mailto:pce@ietf.org>; Mahendra Negi 
mailto:mahen...@rtbrick.com>>
Subject: RE: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi Jie,

Combining responses for 1. and 2. as those are related:

Encoding of SID/ERO-subobject level was used, because of multiple reasons:

a)  We may need to signal SL, which is explicitly configured by user (not 
just computed by PCE) and in such case user can potentially mix SIDs with 
different algorithms (if user is accepting risk of loops or if user knows that 
it cannot happen for various reasons in that specific case).

[Jie] Do you mean using PCEP to signal a configured SID list which consists of 
SIDs with different algorithms? To avoid the risk of loop, normally user would 
prefer to configure either SID list with strict path, or SIDs with consistent 
algorithm. Even if it is known that there is no loop, different algorithms 
represent different requirements to the path, logically can a path built with 
different algorithms meet specific requirement?

Thus it would be helpful to describe the typical scenario(s) of configuring 
SIDs with different algorithms .

 In most of the cases, requirements == algo used, but there are cases, where 
it may not be possible. Some examples.

·case b) bellow (inter-domain)

·support for less capable nodes (e.g. some node/nodes without 
SSPF/Algo1 support, but user want to use SSPF SIDs wherever possible and where 
user knows that it is still safe to mix SIDs). Implementation (PCE/PCC) can 
have local policy (e.g. some configuration) to decide if potentially unsafe 
paths should be used or blocked.

As soon as we have at least possible use case (even if it is corner case), it 
may be bad idea to block it on protocol level. I agree that it may be good to 
describe use cases above in the draft.


b) Different algorithm ID != different algorithm. With flex-algo different 
ID can be used for identification of same algorithm (e.g. in different IGP 
domains). Mixing SIDs with different algorithm ID in such case is safe, but we 
would not be able to signal such path in PCEP.

[Jie] I agree in the inter-domain case, the same algorithm can be represented 
using different IDs, and SIDs associated with different algorithm IDs can be 
used to build an inter-domain path to meet certain requirement. I’d suggest to 
add some description about this case to the document, and it would be better to 
limit the usage of different algorithm IDs in the ERO to this inter-domain case 
only.

 I’m not sure if we can really have hard requirement for PCC or PCE to check 
it. E.g. in case of configured SID list on PCC - PCC may not have visibility to 
whole topology in case of inter-domain paths, so it may not be able to verify 
it. E.g. consider that user configured SID list like this:

1.  Label 26000 (algo 128)

2.  Label 26005 (algo 129)
PCC can just blindly report such path to PCE even if it does not know if both 
SIDs are in same area/domain or not. If we will strictly say that it is not 
valid, then user configured path can result in breaking protocol level 
limitations. Same applies to PCE, which can be potentially used only as a proxy.


c)  Also related to explicit SL – in some cases, user may configure SL 
explicitly on headend. Headend may not be able to resolve complete SL, so it 
may not be sure if algorithm of all SIDs is same.

[Jie] Understood.

3. We defined new types in older version of this draft – see:
https://datatracker.ietf.org/doc/html/draft-tokar-pce-sid-algo-03#section-6.1
but there were multiple comments indicating that it is resulting in too many 
new types (we need to extend draft for Adjacency SIDs as well) and it would be 
hard to maintain it for future – e.g. for cases where new NAI types are added. 
With this change we would have to double number of NAI types. Any extension 
like this in the future would double it again.

[Jie] Thanks for the pointer, I understand the cost of introducing new NAI 
types. While comparing to the format of SID types in BGP SR Policy, there is a 
fixed algorithm field and a A Flag is used to indicate whether this field 
carries an algorithm value or not. Perhaps another approach is to update the 
format of the existing NAI types to include the algorithm field. This could 
also better align 

Re: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

[Samuel Sidor (ssidor)]

Hi Jie,

Please see inline .

Regards,
Samuel

From: Dongjie (Jimmy) 
Sent: Monday, March 21, 2022 5:07 PM
To: Samuel Sidor (ssidor) 
Cc: draft-tokar-pce-sid-a...@ietf.org; Dhruv Dhody ; 
pce@ietf.org; Mahendra Negi 
Subject: RE: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi Samuel,

Sorry for the late reply.  It is good to see this document adopted, and please 
see some further replies inline with [Jie #2]:


From: Samuel Sidor (ssidor) [mailto:ssi...@cisco.com]
Sent: Tuesday, February 22, 2022 5:49 PM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>
Cc: 
draft-tokar-pce-sid-a...@ietf.org<mailto:draft-tokar-pce-sid-a...@ietf.org>; 
Dhruv Dhody mailto:d...@dhruvdhody.com>>; 
pce@ietf.org<mailto:pce@ietf.org>; Mahendra Negi 
mailto:mahen...@rtbrick.com>>
Subject: RE: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi Jie,

Thanks for your comments. Please see inline :

Regards,
Samuel

From: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>
Sent: Monday, February 21, 2022 4:45 PM
To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>
Cc: 
draft-tokar-pce-sid-a...@ietf.org<mailto:draft-tokar-pce-sid-a...@ietf.org>; 
Dhruv Dhody mailto:d...@dhruvdhody.com>>; 
pce@ietf.org<mailto:pce@ietf.org>; Mahendra Negi 
mailto:mahen...@rtbrick.com>>
Subject: RE: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi Samuel,

Thanks for your reply. Please see further inline:

From: Samuel Sidor (ssidor) [mailto:ssi...@cisco.com]
Sent: Friday, February 18, 2022 7:27 PM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>
Cc: 
draft-tokar-pce-sid-a...@ietf.org<mailto:draft-tokar-pce-sid-a...@ietf.org>; 
Dhruv Dhody mailto:d...@dhruvdhody.com>>; 
pce@ietf.org<mailto:pce@ietf.org>; Mahendra Negi 
mailto:mahen...@rtbrick.com>>
Subject: RE: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi Jie,

Combining responses for 1. and 2. as those are related:

Encoding of SID/ERO-subobject level was used, because of multiple reasons:

a)  We may need to signal SL, which is explicitly configured by user (not 
just computed by PCE) and in such case user can potentially mix SIDs with 
different algorithms (if user is accepting risk of loops or if user knows that 
it cannot happen for various reasons in that specific case).

[Jie] Do you mean using PCEP to signal a configured SID list which consists of 
SIDs with different algorithms? To avoid the risk of loop, normally user would 
prefer to configure either SID list with strict path, or SIDs with consistent 
algorithm. Even if it is known that there is no loop, different algorithms 
represent different requirements to the path, logically can a path built with 
different algorithms meet specific requirement?

Thus it would be helpful to describe the typical scenario(s) of configuring 
SIDs with different algorithms .

 In most of the cases, requirements == algo used, but there are cases, where 
it may not be possible. Some examples.

·case b) bellow (inter-domain)

·support for less capable nodes (e.g. some node/nodes without 
SSPF/Algo1 support, but user want to use SSPF SIDs wherever possible and where 
user knows that it is still safe to mix SIDs). Implementation (PCE/PCC) can 
have local policy (e.g. some configuration) to decide if potentially unsafe 
paths should be used or blocked.

As soon as we have at least possible use case (even if it is corner case), it 
may be bad idea to block it on protocol level. I agree that it may be good to 
describe use cases above in the draft.

[Jie #2] OK, I understand there can be cases of falling back from a specific 
Algorithm to the default algorithm, in such case the PCE may need to be 
responsible for determining whether the path with Mixed SID is safe or not, as 
the PCCs may not have enough information for such check.

 Ack. If PCE is doing path-computation, then it can be responsible for 
considering if path is safe or not. If it is explicitly configured SL on PCC, 
then PCC/operator are responsible. Anyway – I assume that we are in sync that 
algo per SID/hop may be needed.


b) Different algorithm ID != different algorithm. With flex-algo different 
ID can be used for identification of same algorithm (e.g. in different IGP 
domains). Mixing SIDs with different algorithm ID in such case is safe, but we 
would not be able to signal such path in PCEP.

[Jie] I agree in the inter-domain case, the same algorithm can be represented 
using different IDs, and SIDs associated with different algorithm IDs can be 
used to build an inter-domain path to meet certain requirement. I’d suggest to 
add some description about this case to the document, and it would be better to 
limit the usage of different algorithm IDs in the ERO to this inter-domain case 
only.

 I’m not sure if we can really have hard requirement for PCC or PCE to check 
it. E.g. in case of configured SID list on PCC - PCC may not have visibility to 
whole topo

Re: [Pce] IPR Poll for draft-ietf-pce-local-protection-enforcement-05

[Samuel Sidor (ssidor)]

I am not aware of any IPR applicable to this draft that should be disclosed in 
accordance with IETF IPR rules.

Thanks,
Samuel

From: Siva Sivabalan 
Sent: Tuesday, June 7, 2022 10:26 PM
To: Hariharan Ananthakrishnan 
Cc: Samuel Sidor (ssidor) ; mustapha.aissa...@nokia.com; 
ssiva...@ciena.com; Stone, Andrew (Nokia - CA/Ottawa) ; 
pce@ietf.org
Subject: Re: [Pce] IPR Poll for draft-ietf-pce-local-protection-enforcement-05


I am not aware of any IPR applicable to this draft that should be disclosed in 
accordance with IETF IPR rules.

Thanks,

Siva



On Tue, Jun 7, 2022 at 12:16 PM Hariharan Ananthakrishnan 
mailto:40netflix@dmarc.ietf.org>> wrote:

Hi Authors,

In preparation for WG last call 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 the 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<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] draft-sidor-pce-circuit-style-pcep-extensions-02

[Samuel Sidor (ssidor)]

Hi Dhruv,

Thanks a lot for your feedback.

For comments received during IETF113 – I checked notes:
https://notes.ietf.org/notes-ietf-113-pce?both

And it seems to me that those should be covered already in latest version 
(v02), which will be presented. To be more specific:


  *   Comment from Tarek about reducing number of flags to block specific 
trigger for re-optimization – TLV was renamed and we dropped original flags for 
triggering re-optimization (new flag was introduced to address comment from 
Andrew, but that is described bellow). Tarek also joined draft as co-author.
  *   Comments from Andrew – he joined draft as co-author and provided more 
comments – including those provided during last IETF presentation. Those 
comments should be addressed.
  *   Comment from Cheng Li – I responded to that comment during presentation.
  *   Comment from Fan Yang – It was about draft [0] and not about [1] (used 
references from your mail)

So only remaining comment I can see is from you about using policy association 
vs introducing new TLV for blocking re-computation – I discussed it with you 
before this draft was introduced and you know my opinion, so I’ll keep others 
from PCE WG to express their view. For now, feedback received from co-authors 
for introducing those TLVs is positive. We still have a plan to add capability 
(or other mechanism to handle backward compatibility) to check whether blocking 
re-computation is supported. Something like that would be harder (if possible) 
to do with associations.

For your new comments – please see inline.

Regards,
Samuel

From: Dhruv Dhody 
Sent: Friday, July 22, 2022 8:17 PM
To: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org
Cc: pce@ietf.org
Subject: draft-sidor-pce-circuit-style-pcep-extensions-02

Hi,

I am glad the companion document [0] is on the SPRING agenda. It is not clear 
if the plan is to move it to SPRING WG with a change in draft name and make it 
fully protocol agnostic by removing any details specific to PCE.

Please go over the minutes of 113 [1] and provide an update on the list. That 
would help in moving the discussion forward.

Few comments -

- I suggest removing figure 1 and do not assign bit positions (leave that for 
the IANA).  This is no longer aligned as a new document ahead in the 
publication queue can request flags (in this case the recent update of stateful 
GMPLS I-D did just that)
 Makes sense. I’ll do that.
-  Since PATH-RECOMPUTATION TLV is useful only for delegated LSP, encoding it 
in an LSP object might be a better option than LSPA (which is allowed for PCReq 
as well). It is also easier to check the delegate flag in the LSP object and 
add text to ignore the TLV if it is not set.
 TLV was moved to LSPA mostly based on discussion that logically it belongs 
more to LSPA as it represents LSP attributes/behavior, but I don’t think that 
there was any strong opinion against. I can see also some potential improvement 
in size of PCEP message as LSP object is always included (with TLV being 
included in LSP object), but LSPA is optional, so sometimes we would have to 
include LSPA object only because of this TLV. I would say that PCReq is not 
strong argument against (we can easily block usage of that TLV in this draft 
for stateless messages).

Hope this helps!

Thanks!
Dhruv

[0] https://datatracker.ietf.org/doc/draft-schmutzer-pce-cs-sr-policy/
[1] https://datatracker.ietf.org/doc/minutes-113-pce/
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] PCE SID-algo draft extension

[Samuel Sidor (ssidor)]

Hi all,

I would like to get feedback from PCE WG for one extension proposed for 
existing SID-algo 
draft
 (currently expired), which is trying to cover all existing algorithm types as 
defined in IGP - that includes SPF (algo 0), Strict-SPF (algo 1) and Flex-algo 
(algo 128-255)
It introduced SID-algo constraint, which currently can be used for filtering 
SIDs used in path computed by PCE.
To be able to compute inter-domain Flex-algo path, PCE Flex-algo 
path-computation must be aligned with path-computation done by IGP (Use ASLA 
attributes, honor FAD lookup priorities,...). This use-case is different one 
from SID filtering we need to use constraints/metric-type from Flex-algo 
definition that is bound to SID algo number specified in constraint.

Before we modify the draft, we would like to know if WG has any objection.

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

Re: [Pce] Question on draft-ietf-pce-local-protection-enforcement

[Samuel Sidor (ssidor)]

Hi Dhruv, Vishnu,

“I think we can differentiate between an implementation that supports this 
extension - that MUST use UNPROTECTED PREFERRED whereas a legacy implementation 
would handle it as per their understanding of RFC 5440 which could be 
UNPROTECTED PREFERRED or UNPROTECTED MANDATORY.”

Wouldn’t such change break backward compatibility?

Consider that there is vendor, with original behavior L=0 -> unprotected 
mandatory (on both PCC and PCE side) – as Dhruv mentioned, such implementation 
would be completely valid with original L flag definition. Same old PCC will 
connect to new PCE (with draft supported) and suddenly (unexpected) different 
path-computation result is provided, because behavior has changed.

PCE can still have a way to detect that it is talking to legacy PCCs and it can 
fallback to original behavior to do not break backward compatibility.

I’ll keep Andrew to comment as he is main author.

Regards,
Samuel

From: Pce  On Behalf Of Dhruv Dhody
Sent: Wednesday, January 11, 2023 9:29 AM
To: Vishnu Pavan Beeram 
Cc: pce@ietf.org
Subject: Re: [Pce] Question on draft-ietf-pce-local-protection-enforcement

Hi Pavan,


On Wed, Jan 11, 2023 at 12:46 PM Vishnu Pavan Beeram 
mailto:vishnupa...@gmail.com>> wrote:
Dhruv, Hi!

Thanks for the response! Please see inline..

Regards,
-Pavan

On Wed, Jan 11, 2023 at 12:03 PM Dhruv Dhody 
mailto:dhruv.i...@gmail.com>> wrote:
Hi Pavan,

On Wed, Jan 11, 2023 at 11:02 AM Vishnu Pavan Beeram 
mailto:vishnupa...@gmail.com>> wrote:
I would like to get some clarification on the text below (understand that a 
publication request has been made for the draft).

**
From Section 5:

   When L-flag is not set and E-flag is not set then PCE SHOULD consider

   the protection eligibility as UNPROTECTED PREFERRED but MAY consider

   protection eligibility as UNPROTECTED MANDATORY constraint.

   When L-flag is not set and E-flag is set then PCE MUST consider the

   protection eligibility as UNPROTECTED MANDATORY constraint.


**
For the scenario where both the L-flag and the E-flag are not set (first 
statement above), it seems okay to just say
that the "PCE MUST consider the protection eligibility as UNPROTECTED 
PREFERRED". Is there a good reason
for both the "SHOULD (UNPROTECTED PREFERRED)" and "MAY (UNPROTECTED MANDATORY)" 
clauses to
be included here (and keep things ambiguous)?


Dhruv: If I recall correctly (and the authors can confirm that), this was done 
for the sake of backward compatibility. I remember it being discussed on the 
mailing list as well.

[VPB] Thanks for the pointer to the mailing list thread (should have searched 
there first; apologies for re-opening the topic) -- it was useful! However, the 
backwards compatibility section (5.1) seems to be silent about this particular 
scenario.

If a PCEP speaker does not understand this document (and thus ignores the E 
flag) and L flag is set to 0, would behave as per RFC 5440 where the concept of 
enforcement is undefined and some implementation could understand it to be 
handled as UNPROTECTED MANDATORY instead of UNPROTECTED PREFERRED. And the text 
allows for it.

[VPB] I understand that there was ambiguity with how the (presence/absence of 
the) L-flag was interpreted prior to this draft. I was hoping that there would 
be no ambiguity left when this draft is implemented -- but that doesn't seem to 
be the case. Let's say a PCC implementation assumes [L 0, E 0] to mean 
"UNPROTECTED PREFERRED" (SHOULD clause), while the PCE implementation assumes 
it to mean "UNPROTECTED MANDATORY" (MAY clause) -- this may result in no path 
being returned (if only protected SIDs are available on some links along the 
viable paths). Do we need to retain this ambiguity?

Dhruv: You have a point. I think we can differentiate between an implementation 
that supports this extension - that MUST use UNPROTECTED PREFERRED whereas a 
legacy implementation would handle it as per their understanding of RFC 5440 
which could be UNPROTECTED PREFERRED or UNPROTECTED MANDATORY.

Let's see what the authors think about it.

Thanks!
Dhruv



Happy to get additional eyes and confirm if it still makes sense!

Thanks!
Dhruv


Regards,
-Pavan
___
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] PCE SID-algo draft extension

[Samuel Sidor (ssidor)]

Hi Dhruv,

Thanks for feedback. I completely agree – I would like to hear from WG if they 
can see added value in both (or they can specify even other) use-cases – using 
SID-algo constraint just for SID filtering and using it also for specification 
of constraints from FAD (I agree with Stephane here – computation based on in 
FAD seems to be even more important use-case to me and it is not covered in 
current version of that draft).

For constraint conflict solving – there are multiple possible solutions, but I 
would prefer to ignore metric-type from PCRpt (as metric-type would be 
retrieved from FAD) or reject PCEP Metric object completely (that may have 
potential issues with backward compatibility). Do not block usage of other 
constraints on top of SID-algo constraint explicitly in the draft – actual PCE 
implementation can still reject any combination of constraints, which PCE 
cannot handle (with PCUpdate with empty ERO or with some specific PCError) That 
would allow usage of some specific constraints like metric bounds on top of 
path computed with constraints from FAD. I would like to clearly specify in the 
draft that PCC is not supposed to reflect constraints from FAD in PCRpt as 
intended/requested attributes (only constraints, which should be used on top of 
FAD should be specified).

For SID-algo constraint signaling – can you please specify benefit of using 
association in this case? FAD with constraints is part of topology information 
received from IGP/BGP-LS, so we need to encode only algorithm number (and 
potentially source IGP, but that is separate story).

Thanks,
Samuel

From: slitkows.i...@gmail.com 
Sent: Tuesday, January 10, 2023 5:34 PM
To: 'Dhruv Dhody' ; Samuel Sidor (ssidor) 

Cc: pce@ietf.org; 'pce-chairs' 
Subject: RE: [Pce] PCE SID-algo draft extension

Hi

Happy new year guys !

IMO, from a use case point of view, the SID filtering use case is far more 
limited and niche (e.g.: plane selection…) vs the interdomain FA path 
computation which is widely required. For large networks that are multidomain, 
there must be a PCE based solution for interdomain FA path computation.

Brgds,

Stephane

From: Pce mailto:pce-boun...@ietf.org>> On Behalf Of 
Dhruv Dhody
Sent: mardi 10 janvier 2023 14:00
To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>; pce-chairs 
mailto:pce-cha...@ietf.org>>
Subject: Re: [Pce] PCE SID-algo draft extension

Hi Samuel,

As a WG participant --- Assuming the WG agrees with the usecase, we need a 
clear way to signal when the Algo is a constraint along with others (current) 
v/s when Algo is a shorthand to refer to the constraints as per the IGP 
definition (proposed).

This could be a flag in the SID Algorithm TLV or could be a brand new mechanism 
(such as a new dynamic association type for FlexAlgo). More importantly, we 
need to be clear on how other PCEP constraints interact with the constraints 
referred in the IGP. The easiest thing would be to not allow other PCEP 
constraints to be encoded at all and rely only on IGP; or have flags to signal 
how to handle the complexity of combining them including mismatch! This needs 
to be handled with care!

Thanks!
Dhruv

On Tue, Jan 10, 2023 at 3:51 PM Samuel Sidor (ssidor) 
mailto:ssi...@cisco.com>> wrote:
Hi all,

I would like to get feedback from PCE WG for one extension proposed for 
existing SID-algo 
draft<https://datatracker.ietf.org/doc/html/draft-tokar-pce-sid-algo-05#name-sid-algorithm-constraint-2>
 (currently expired), which is trying to cover all existing algorithm types as 
defined in IGP – that includes SPF (algo 0), Strict-SPF (algo 1) and Flex-algo 
(algo 128-255)
It introduced SID-algo constraint, which currently can be used for filtering 
SIDs used in path computed by PCE.
To be able to compute inter-domain Flex-algo path, PCE Flex-algo 
path-computation must be aligned with path-computation done by IGP (Use ASLA 
attributes, honor FAD lookup priorities,…). This use-case is different one from 
SID filtering we need to use constraints/metric-type from Flex-algo definition 
that is bound to SID algo number specified in constraint.

Before we modify the draft, we would like to know if WG has any objection.

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

[Pce] LSP identifiers TLV optional for SR in RFC8664

[Samuel Sidor (ssidor)]

Hi PCE WG,

RFC8664 marked LSP identifiers TLV as optional:

"The LSP-IDENTIFIERS TLV MAY be present for the above PST type."

https://www.rfc-editor.org/rfc/rfc8664.html#name-the-rp-srp-object

But I don't see any clarification in that RFC, how SR policy endpoints/LSP-ID 
(may be needed for MBB) or any other field from that TLV is supposed to be 
encoded in PCRpt message.

I can imagine that SR policy endpoints can be retrieved from SR policy 
association 
(https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp#section-5.1),
 but that draft is still not supported by many implementations and it is not 
mentioned as MUST in RFC8664.

So now it seems to be completely valid based on RFC8664 to send PCRpt with no 
LSP identifiers and no SR Policy association => with missing endpoints. Is that 
intentional or am I missing any statement from RFC, which is clarifying it?

I found some older discussion in mail archive:
https://mailarchive.ietf.org/arch/msg/pce/rGVwtH6u3eUCMbRyR-gV1Cv2zDU/
Where almost similar topic was discussed and where it was requested to make it 
mandatory, but there were a few mails exchanged with no conclusion.

One more comment - even statement about LSP-identifiers in RFC8664 seems to be 
mentioned in wrong section - dedicated for RP/SRP object, which was never used 
for LSP identifiers TLV (that is supposed to be included in LSP object).

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

Re: [Pce] LSP identifiers TLV optional for SR in RFC8664

[Samuel Sidor (ssidor)]

Hi PCE-chairs,

Since there is no reasonable explanation provided in the mailing list - does 
that mean that RFC is "broken" and we need Errata to fix it? E.g. by making LSP 
identifiers TLV mandatory?

Thanks,
Samuel

From: Pce  On Behalf Of Samuel Sidor (ssidor)
Sent: Thursday, February 9, 2023 1:29 PM
To: pce@ietf.org
Subject: [Pce] LSP identifiers TLV optional for SR in RFC8664

Hi PCE WG,

RFC8664 marked LSP identifiers TLV as optional:

"The LSP-IDENTIFIERS TLV MAY be present for the above PST type."

https://www.rfc-editor.org/rfc/rfc8664.html#name-the-rp-srp-object

But I don't see any clarification in that RFC, how SR policy endpoints/LSP-ID 
(may be needed for MBB) or any other field from that TLV is supposed to be 
encoded in PCRpt message.

I can imagine that SR policy endpoints can be retrieved from SR policy 
association 
(https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp#section-5.1),
 but that draft is still not supported by many implementations and it is not 
mentioned as MUST in RFC8664.

So now it seems to be completely valid based on RFC8664 to send PCRpt with no 
LSP identifiers and no SR Policy association => with missing endpoints. Is that 
intentional or am I missing any statement from RFC, which is clarifying it?

I found some older discussion in mail archive:
https://mailarchive.ietf.org/arch/msg/pce/rGVwtH6u3eUCMbRyR-gV1Cv2zDU/
Where almost similar topic was discussed and where it was requested to make it 
mandatory, but there were a few mails exchanged with no conclusion.

One more comment - even statement about LSP-identifiers in RFC8664 seems to be 
mentioned in wrong section - dedicated for RP/SRP object, which was never used 
for LSP identifiers TLV (that is supposed to be included in LSP object).

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

Re: [Pce] LSP identifiers TLV optional for SR in RFC8664

[Samuel Sidor (ssidor)]

Hi Dhruv,

Thanks a lot, for your comments. Please see inline .

Regards,
Samuel

“allow SR paths to be set up with minimal information needed”  ->

“Specifically about endpoints, for PCC configured SR path you have it via local 
configuration and for the PCE-initiated, END-POINTS object could also be 
optionally included in PCInitiate message. ” ->



From: Dhruv Dhody 
Sent: Tuesday, February 14, 2023 12:29 PM
To: Samuel Sidor (ssidor) 
Cc: pce-chairs ; Samuel Sidor (ssidor) 
; pce@ietf.org
Subject: Re: LSP identifiers TLV optional for SR in RFC8664

Hi Samuel,

The feeling at the time was to get away from the RSVP-TE-thinking for SR (and 
allow SR paths to be set up with minimal information needed). If I recall 
correctly, the "MAY" was the "compromise" struck at the time to allow SR paths 
to be set up without it but when use cases require these the LSP-IDENTIFIER-TLV 
can be included.

 Problem here is that there are still many cases, when endpoints belong into 
category of “minimal information”, but at least I have context now – I was not 
able to find any discussion in mail archive about it.

On Tue, Feb 14, 2023 at 3:02 PM Samuel Sidor (ssidor) 
mailto:ssi...@cisco.com>> wrote:
Hi PCE-chairs,

Since there is no reasonable explanation provided in the mailing list – does 
that mean that RFC is “broken” and we need Errata to fix it? E.g. by making LSP 
identifiers TLV mandatory?


Errata would not be the right approach. See 
https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/

If the WG wants an explicit statement we would need to add this in an existing 
WG document or propose a new one.

  Reason for proposing Errata was because I personally considered it as a 
“bug” in that RFC and statement above is specifically describing it for such 
purpose:

“Errata are meant to fix "bugs" in the specification and should not be used to 
change what the community meant when it approved the RFC. Here are some things 
to consider when submitting an errata report:”

Thanks,
Samuel

From: Pce mailto:pce-boun...@ietf.org>> On Behalf Of 
Samuel Sidor (ssidor)
Sent: Thursday, February 9, 2023 1:29 PM
To: pce@ietf.org<mailto:pce@ietf.org>
Subject: [Pce] LSP identifiers TLV optional for SR in RFC8664

Hi PCE WG,

RFC8664 marked LSP identifiers TLV as optional:

“The LSP-IDENTIFIERS TLV MAY be present for the above PST type.”

https://www.rfc-editor.org/rfc/rfc8664.html#name-the-rp-srp-object

But I don’t see any clarification in that RFC, how SR policy endpoints/LSP-ID 
(may be needed for MBB) or any other field from that TLV is supposed to be 
encoded in PCRpt message.

I can imagine that SR policy endpoints can be retrieved from SR policy 
association 
(https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp#section-5.1),
 but that draft is still not supported by many implementations and it is not 
mentioned as MUST in RFC8664.


Specifically about endpoints, for PCC configured SR path you have it via local 
configuration and for the PCE-initiated, END-POINTS object could also be 
optionally included in PCInitiate message.

 For PCC configured – we have it in local configuration on headend/PCC, but 
PCE does not have it in case of delegation of path-computation to PCE and that 
is the important part (since we are talking about messages in PCEP). Consider 
for example LSP delegated in down state (empty ERO included) , in such case, it 
may be impossible to derive destination address. Also policy source address 
does not have to be same as PCEP peer address, so that can be missing as well.

In case of PCE initiated, again same thing – if I have multiple PCEs in the 
network, then PCE, which hasn’t created that policy will not see END-POINTS 
object included in original PCinitiate message, so sending report messages from 
PCC to other PCEs is useless without having another synchronization mechanism 
between PCEs.

So now it seems to be completely valid based on RFC8664 to send PCRpt with no 
LSP identifiers and no SR Policy association => with missing endpoints. Is that 
intentional or am I missing any statement from RFC, which is clarifying it?


IMHO It is intentional. See para 4 at 
https://www.rfc-editor.org/rfc/rfc8281.html#section-5.3 about endpoints (and it 
is valid for SR as well).

 That section seems to be related to the endpoints of PCE initiated LSPs 
only. I would expect at least similar explanation for PCRpt in RFC8664. It 
seems very dangerous to relax previously defined restrictions without 
describing what should happen if it is not satisfied. Such approach is always 
opening doors to various interpretation/implementations by different vendors & 
problems with interoperability.

I see following options -
- Do Nothing
- Clarify "when" the LSP-IDENTIFIER-TLV MUST be included (could be in the 
operational clarification draft)
 Seems reasonable to me.
- Update the text in RFC8664 to 

Re: [Pce] LSP identifiers TLV optional for SR in RFC8664

[Samuel Sidor (ssidor)]

(just small update – dropped some copy pasted statements from my response as I 
finally responded with inline comments)

Regards,
Samuel

From: Samuel Sidor (ssidor) 
Sent: Tuesday, February 14, 2023 1:27 PM
To: Dhruv Dhody 
Cc: pce-chairs ; Samuel Sidor (ssidor) ; 
pce@ietf.org
Subject: RE: LSP identifiers TLV optional for SR in RFC8664

Hi Dhruv,

Thanks a lot, for your comments. Please see inline .

Regards,
Samuel

From: Dhruv Dhody mailto:d...@dhruvdhody.com>>
Sent: Tuesday, February 14, 2023 12:29 PM
To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>
Cc: pce-chairs mailto:pce-cha...@ietf.org>>; Samuel Sidor 
(ssidor) 
mailto:ssidor=40cisco@dmarc.ietf.org>>; 
pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: LSP identifiers TLV optional for SR in RFC8664

Hi Samuel,

The feeling at the time was to get away from the RSVP-TE-thinking for SR (and 
allow SR paths to be set up with minimal information needed). If I recall 
correctly, the "MAY" was the "compromise" struck at the time to allow SR paths 
to be set up without it but when use cases require these the LSP-IDENTIFIER-TLV 
can be included.

 Problem here is that there are still many cases, when endpoints belong into 
category of “minimal information”, but at least I have context now – I was not 
able to find any discussion in mail archive about it.

On Tue, Feb 14, 2023 at 3:02 PM Samuel Sidor (ssidor) 
mailto:ssi...@cisco.com>> wrote:
Hi PCE-chairs,

Since there is no reasonable explanation provided in the mailing list – does 
that mean that RFC is “broken” and we need Errata to fix it? E.g. by making LSP 
identifiers TLV mandatory?


Errata would not be the right approach. See 
https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/

If the WG wants an explicit statement we would need to add this in an existing 
WG document or propose a new one.

  Reason for proposing Errata was because I personally considered it as a 
“bug” in that RFC and statement above is specifically describing it for such 
purpose:

“Errata are meant to fix "bugs" in the specification and should not be used to 
change what the community meant when it approved the RFC. Here are some things 
to consider when submitting an errata report:”

Thanks,
Samuel

From: Pce mailto:pce-boun...@ietf.org>> On Behalf Of 
Samuel Sidor (ssidor)
Sent: Thursday, February 9, 2023 1:29 PM
To: pce@ietf.org<mailto:pce@ietf.org>
Subject: [Pce] LSP identifiers TLV optional for SR in RFC8664

Hi PCE WG,

RFC8664 marked LSP identifiers TLV as optional:

“The LSP-IDENTIFIERS TLV MAY be present for the above PST type.”

https://www.rfc-editor.org/rfc/rfc8664.html#name-the-rp-srp-object

But I don’t see any clarification in that RFC, how SR policy endpoints/LSP-ID 
(may be needed for MBB) or any other field from that TLV is supposed to be 
encoded in PCRpt message.

I can imagine that SR policy endpoints can be retrieved from SR policy 
association 
(https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp#section-5.1),
 but that draft is still not supported by many implementations and it is not 
mentioned as MUST in RFC8664.


Specifically about endpoints, for PCC configured SR path you have it via local 
configuration and for the PCE-initiated, END-POINTS object could also be 
optionally included in PCInitiate message.

 For PCC configured – we have it in local configuration on headend/PCC, but 
PCE does not have it in case of delegation of path-computation to PCE and that 
is the important part (since we are talking about messages in PCEP). Consider 
for example LSP delegated in down state (empty ERO included) , in such case, it 
may be impossible to derive destination address. Also policy source address 
does not have to be same as PCEP peer address, so that can be missing as well.

In case of PCE initiated, again same thing – if I have multiple PCEs in the 
network, then PCE, which hasn’t created that policy will not see END-POINTS 
object included in original PCinitiate message, so sending report messages from 
PCC to other PCEs is useless without having another synchronization mechanism 
between PCEs.

So now it seems to be completely valid based on RFC8664 to send PCRpt with no 
LSP identifiers and no SR Policy association => with missing endpoints. Is that 
intentional or am I missing any statement from RFC, which is clarifying it?


IMHO It is intentional. See para 4 at 
https://www.rfc-editor.org/rfc/rfc8281.html#section-5.3 about endpoints (and it 
is valid for SR as well).

 That section seems to be related to the endpoints of PCE initiated LSPs 
only. I would expect at least similar explanation for PCRpt in RFC8664. It 
seems very dangerous to relax previously defined restrictions without 
describing what should happen if it is not satisfied. Such approach is always 
opening doors to various interpretation/implementations by different vendors & 
problems wi

Re: [Pce] PCE SID-algo draft extension

[Samuel Sidor (ssidor)]

Hi all,

Thanks all for discussion, which happened during PCE session and thanks for 
supporting this extension.

I think that we agreed that it is necessary to consider FAD in the 
path-computation on PCE side if SID-algo constraint was specified, but we were 
not able to finish discussion whether there is a need to introduce new flag, 
which will control whether original behavior (SID-algo filtering) or new 
behavior should be used, so re-opening this mail thread to finish that 
discussion.

I would say that there are really at least two usecases/behaviors for SID-algo 
constraint and we need new flag in SID-algorithm constraint to allow PCC to 
pick required behavior.


  1.  SID-filtering - already exists in the draft (valid for all algorithms)

  *   Path-computation should occur on the topology associated with specified 
SID-algo
  *   Computed path can have only SIDs of specified algo value (+ adjacency 
SIDs)
  *   PCE path-computation is done based on metric-type and constraints from 
PCRpt
  *   Flex-algo specific part:
 *   PCE still has to make sure that IGP path of FA SID is congruent with 
computed path

  1.  Path-computation based on FAD (only valid for Flex-algo)

  *   Metric-type and constraints are primarily retrieved from FAD
  *   Path-computation follow IGP Flex-algo path-computation logic
 *   Flex-algo participation, ASLA attributes,...
  *   Metric-type from FAD is overriding metric-type from PCRpt
  *   PCUpdate will use metric-type from FAD
  *   PCC can send metric-type in PCRpt and it does not have to be same as 
metric-type from FAD, but it is recommended to do not advertise any 
optimization metric
  *   Other constraints from PCRpt:
 *   PCE implementation can decide based on flags in PCEP object
 *   It is not recommended to specify constraints in PCRpt, which are 
already specified in FAD
 *   PCE is not supposed to include constraints from FAD in PCUpdate

Description here is slightly different then the proposal presented in original 
slides, but main idea is still same and more details is provided now. Please 
provide any comments.

Thanks,
Samuel

From: Pce  On Behalf Of Samuel Sidor (ssidor)
Sent: Thursday, January 12, 2023 10:12 AM
To: slitkows.i...@gmail.com; 'Dhruv Dhody' 
Cc: pce@ietf.org; 'pce-chairs' 
Subject: Re: [Pce] PCE SID-algo draft extension

Hi Dhruv,

Thanks for feedback. I completely agree – I would like to hear from WG if they 
can see added value in both (or they can specify even other) use-cases – using 
SID-algo constraint just for SID filtering and using it also for specification 
of constraints from FAD (I agree with Stephane here – computation based on in 
FAD seems to be even more important use-case to me and it is not covered in 
current version of that draft).

For constraint conflict solving – there are multiple possible solutions, but I 
would prefer to ignore metric-type from PCRpt (as metric-type would be 
retrieved from FAD) or reject PCEP Metric object completely (that may have 
potential issues with backward compatibility). Do not block usage of other 
constraints on top of SID-algo constraint explicitly in the draft – actual PCE 
implementation can still reject any combination of constraints, which PCE 
cannot handle (with PCUpdate with empty ERO or with some specific PCError) That 
would allow usage of some specific constraints like metric bounds on top of 
path computed with constraints from FAD. I would like to clearly specify in the 
draft that PCC is not supposed to reflect constraints from FAD in PCRpt as 
intended/requested attributes (only constraints, which should be used on top of 
FAD should be specified).

For SID-algo constraint signaling – can you please specify benefit of using 
association in this case? FAD with constraints is part of topology information 
received from IGP/BGP-LS, so we need to encode only algorithm number (and 
potentially source IGP, but that is separate story).

Thanks,
Samuel

From: slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com> 
mailto:slitkows.i...@gmail.com>>
Sent: Tuesday, January 10, 2023 5:34 PM
To: 'Dhruv Dhody' mailto:d...@dhruvdhody.com>>; Samuel 
Sidor (ssidor) mailto:ssi...@cisco.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>; 'pce-chairs' 
mailto:pce-cha...@ietf.org>>
Subject: RE: [Pce] PCE SID-algo draft extension

Hi

Happy new year guys !

IMO, from a use case point of view, the SID filtering use case is far more 
limited and niche (e.g.: plane selection…) vs the interdomain FA path 
computation which is widely required. For large networks that are multidomain, 
there must be a PCE based solution for interdomain FA path computation.

Brgds,

Stephane

From: Pce mailto:pce-boun...@ietf.org>> On Behalf Of 
Dhruv Dhody
Sent: mardi 10 janvier 2023 14:00
To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>; pce-chairs 
mai

Re: [Pce] PCE SID-algo draft extension

[Samuel Sidor (ssidor)]

Hi Andrew,

Thanks for good comment.

There are really 3 things – optionA, optionB and L flag.

Option A + option B:
Option A cannot be combined with Option B as main difference here is source of 
optimization metric/constraints and topology attributes, which are supposed to 
be used in the path-computation (ASLA vs legacy).

Option A + L flag:
I would say that option A can be combined with L flag as you are really doing 
path-computation based on “legacy” constraints specified in PCRpt. That will 
result in some path, which is translated into SID list and algo of those SIDs 
is not that important (if IGP path of those SIDs is congruent with computed 
path).

Option B + L flag:
Option B is implicitly restricting topology to only nodes/links with 
participation in that FA (PCE need to follow from path-computation what IGP is 
doing for that option). Constraints and metric-type in FAD are defining FA ASLA 
constraints, so even in the path-computation PCE is supposed to use FA ASLA 
link attributes. So if PCE would suddenly need to use links/nodes (if we would 
allow usage of non-FA topology for L=1), which does not advertise those 
attributes, then PCE would have to fallback into legacy (non-ASLA) link 
attributes and resulting path would have for example accumulated metric, which 
is combining ASLA latency of some links with non-ASLA latency of other links 
(it seems to me like mixing apples and oranges as it is not guaranteed that FA 
ASLA metric value for specific link is same as legacy metric value of same 
link). So I tend to say that topology should be restricted even with L=1 with 
option B.

I just described topology which must be used and not SIDs. I can still imagine 
that if L=1 is set, then PCE will use FA topology, but it can still fallback 
into Algo-0 Prefix SIDs (even if I think that there is higher change that adj 
SIDs + FA SIDs will be used) assuming that final computed path will still be 
shortest path of specified ASLA metric and it will satisfy ASLA constraints 
from FAD.

Btw for your other example with MSD – I assume that in most of the cases you 
will end up with smaller number of SIDs if you will use FA SIDs (as IGP 
forwarding will be more aligned with intended constraints in PCE 
path-computation) when compared with algo-0 SIDs.

I’ll think about it a little bit more, L flag is definitely introducing extra 
complexity into both cases, so maybe even dropping that flag may work (PCE can 
still compute path mix of FA and algo0 SIDs even without any constraint, so 
maybe added value of SID-algo constraint + L=1 is relatively small) or we can 
modify it to restrict it to combination of FA SIDs + adj SIDs.

Regards,
Samuel

From: Andrew Stone (Nokia) 
Sent: Wednesday, March 29, 2023 4:24 PM
To: peng.sha...@zte.com.cn; Samuel Sidor (ssidor) 
Cc: pce@ietf.org; pce-cha...@ietf.org; slitkows.i...@gmail.com; 
d...@dhruvdhody.com
Subject: Re: [Pce] PCE SID-algo draft extension

Hi Samuel, PCE WG

I think your comparison points cover the differences well. 
Comparing/contrasting the two scenarios and behaviors should probably be in the 
updated document, too.

It does seem a need to signal the different behavior intention in some form or 
another (whether flag or inclusion/exclusion of constructs). Something not 
remarked in (B), is PCE implicitly restricted to using only SIDs found from the 
Flex Algo Tree? Or is it still permitted to use any SID it wants (existing 
draft L=1) if the path is using resources respecting the FAD. As an example, 
Let's say PCE computes a path based on FAD constraints but needs to work around 
constraints defined outside of the algo, such as known planned maintenance or 
other impairments/rules. Due to MSD, maybe it can't encode this path within the 
confines of the Algo specified. However, if it used Algo-0 or another SIDs it 
can encode the path. I would assume this should be permitted, but Is there a 
need to prohibit this and restrict (B) to also use only the SIDs from the same 
algo? I think I’m looking to clarify, if (A) is filtering strictness and (B) 
metric/constraint, is the behavior needed actually A||B, or is it A=true/false, 
B=true/false?

Thanks
Andrew

From: "peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>" 
mailto:peng.sha...@zte.com.cn>>
Date: Wednesday, March 29, 2023 at 5:46 AM
To: "ssi...@cisco.com<mailto:ssi...@cisco.com>" 
mailto:ssi...@cisco.com>>
Cc: "pce@ietf.org<mailto:pce@ietf.org>" mailto:pce@ietf.org>>, 
"pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>" 
mailto:pce-cha...@ietf.org>>, 
"slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>" 
mailto:slitkows.i...@gmail.com>>, 
"d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>" 
mailto:d...@dhruvdhody.com>>, "Andrew Stone (Nokia)" 
mailto:andrew.st...@nokia.com>>
Subject: Re: [Pce] PCE SID-algo draft extension


CAUTION: T

Re: [Pce] PCE SID-algo draft extension

[Samuel Sidor (ssidor)]

Thanks Andrew,

One proposal for all about that L flag – what about really changing behavior of 
L flag to make it simple for both use-cases (option A and option B), so:
If L=0, then constraints have to be satisfied. If such path cannot be found, 
then empty path will be returned. (no change)
For L=1, if path cannot be found with that constraint, then constraint can be 
ignored and path can be recomputed without considering it at all (SID of that 
algo does not need to be preferred).

From draft perspective it is about modifying this part:

· L (Loose): If set to 1, the PCE MAY insert SIDs with a different 
Algorithm, but it MUST prefer the specified Algorithm whenever possible.

That way PCE can still use SIDs of specified algo, but constraint is not 
enforcing it, so PCE can still compute complete end-to-end path with just algo 
0 SIDs (of included SIDs of specified algo if it is considering it as safe). So 
there are no special requirements from topology pruning or SID filtering for L 
flag.

To me it seems that there would be really too many options/combinations if we 
will keep original definition of that flag and probably not all vendors will 
implement all of them and we will end-up with various interop issues, so would 
need extra capabilities as well to advertise what is supported and what is not.

Thanks,
Samuel

From: Andrew Stone (Nokia) 
Sent: Friday, March 31, 2023 5:18 AM
To: Samuel Sidor (ssidor) ; peng.sha...@zte.com.cn
Cc: pce@ietf.org; pce-cha...@ietf.org; slitkows.i...@gmail.com; 
d...@dhruvdhody.com
Subject: Re: [Pce] PCE SID-algo draft extension

Hi Samuel,

Replies inline below with [Andrew]

Thanks
Andrew

From: "Samuel Sidor (ssidor)" mailto:ssi...@cisco.com>>
Date: Thursday, March 30, 2023 at 8:22 AM
To: "Andrew Stone (Nokia)" 
mailto:andrew.st...@nokia.com>>, 
"peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>" 
mailto:peng.sha...@zte.com.cn>>
Cc: "pce@ietf.org<mailto:pce@ietf.org>" mailto:pce@ietf.org>>, 
"pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>" 
mailto:pce-cha...@ietf.org>>, 
"slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>" 
mailto:slitkows.i...@gmail.com>>, 
"d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>" 
mailto:d...@dhruvdhody.com>>
Subject: RE: [Pce] PCE SID-algo draft extension


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


Hi Andrew,

Thanks for good comment.

There are really 3 things – optionA, optionB and L flag.

Option A + option B:
Option A cannot be combined with Option B as main difference here is source of 
optimization metric/constraints and topology attributes, which are supposed to 
be used in the path-computation (ASLA vs legacy).

[Andrew] Agreed

Option A + L flag:
I would say that option A can be combined with L flag as you are really doing 
path-computation based on “legacy” constraints specified in PCRpt. That will 
result in some path, which is translated into SID list and algo of those SIDs 
is not that important (if IGP path of those SIDs is congruent with computed 
path).

[Andrew] Agreed. My interpretation for a use case on the original adoption was 
that if PCE is setting up a path, it would be more ideal to set it up following 
a given Algo, so that way any native IGP convergence or protection mechanisms 
will still respect a metric/constraints differing from algo-0, and if you fail 
to resolve a SID list using the algo be permitted to use any SIDs available.

Option B + L flag:
Option B is implicitly restricting topology to only nodes/links with 
participation in that FA (PCE need to follow from path-computation what IGP is 
doing for that option). Constraints and metric-type in FAD are defining FA ASLA 
constraints, so even in the path-computation PCE is supposed to use FA ASLA 
link attributes. So if PCE would suddenly need to use links/nodes (if we would 
allow usage of non-FA topology for L=1), which does not advertise those 
attributes, then PCE would have to fallback into legacy (non-ASLA) link 
attributes and resulting path would have for example accumulated metric, which 
is combining ASLA latency of some links with non-ASLA latency of other links 
(it seems to me like mixing apples and oranges as it is not guaranteed that FA 
ASLA metric value for specific link is same as legacy metric value of same 
link). So I tend to say that topology should be restricted even with L=1 with 
option B.

[Andrew] Yes, agree that topology(edges in the graph) should be restricted with 
L=1. Topology must be restricted to links matching the flex algo, and thus any 
path programmed must only be for links within that flex algo, and If a given 
resource violates the FAD it must be pruned. But I do think there’s two sides 
to it, topology filtering vs SID selection to encode the

Re: [Pce] PCE SID-algo draft extension

[Samuel Sidor (ssidor)]

Hi Andrew,

My proposal was really to use something like P/I flag from PCEP object. In this 
case, SID-algo constraint is TLV, so there is no way to enforce it using P 
flag), so yes – I meant “permitted to compute and program a path as if LSPA 
never contained the SID Algo TLV”.

If SID-algo constraint is not included, then PCE can use algo SIDs freely (even 
if there is no draft or no SID-algo constraint specified) – e.g. to decrease 
size of label stack. So same thing would apply to L=1. If PCE cannot fully 
satisfy constraint, then it can fallback into “no SID-algo constraint” behavior 
and it can still compute path with algo SIDs if needed, but there is no 
explicit preference to specific algo SIDs or anything like that.

For cases, where for example multi-domain path is needed, where some domains 
have FA support, but some domain does not support that FA, recommended approach 
can be still policy stitching.

I personally consider such approach as consistent with other constraints, which 
we have – e.g. for affinities we also does not have L flag to partially ignore 
it in part of the network, but still consider in other parts. And we have 
“Strict Disjointness” flag in diversity, which almost similar – allowing to 
fallback other disjoint types or non-disjoint path (but still constraint is 
applied to complete path and not only to some hops or some domain). Rules for 
path-computation are already more complex with other constraints (considering 
topology pruning, ASLA constraints, other constraints from PCRpt,…), so 
increasing complexity even more and allowing combination of algos in same 
segment-list, but still preferring some of them can be really too much.

Regards,
Samuel

From: Andrew Stone (Nokia) 
Sent: Tuesday, April 4, 2023 8:58 PM
To: Samuel Sidor (ssidor) ; peng.sha...@zte.com.cn
Cc: pce@ietf.org; pce-cha...@ietf.org; slitkows.i...@gmail.com; 
d...@dhruvdhody.com
Subject: Re: [Pce] PCE SID-algo draft extension

Hi Samuel,

To confirm what you’re suggesting - It reads to me like it says if L=1, then 
PCE is effectively permitted to compute and program a path as if LSPA never 
contained the SID Algo TLV. Or am I mistaken? Or is the suggestion that it’s 
really up to PCE to decide how ‘loose’ it wants to go in regards to 
‘constraint’ (path prune vs encoding) and it’s permitted to approach the 
problem as a form of relaxation as it sees fit to get the path up? I agree, the 
scope needs to be kept down and clear for relatively consistent interop for 
what the ‘intention’ is of the knobs. I see the standardization goal here about 
intention of the knobs/behavior and wire encoding, but permit implementation to 
decide how best to achieve the signalled intention.

Thanks
Andrew

From: "Samuel Sidor (ssidor)" mailto:ssi...@cisco.com>>
Date: Monday, April 3, 2023 at 9:31 AM
To: "Andrew Stone (Nokia)" 
mailto:andrew.st...@nokia.com>>, 
"peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>" 
mailto:peng.sha...@zte.com.cn>>
Cc: "pce@ietf.org<mailto:pce@ietf.org>" mailto:pce@ietf.org>>, 
"pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>" 
mailto:pce-cha...@ietf.org>>, 
"slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>" 
mailto:slitkows.i...@gmail.com>>, 
"d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>" 
mailto:d...@dhruvdhody.com>>
Subject: RE: [Pce] PCE SID-algo draft extension


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


Thanks Andrew,

One proposal for all about that L flag – what about really changing behavior of 
L flag to make it simple for both use-cases (option A and option B), so:
If L=0, then constraints have to be satisfied. If such path cannot be found, 
then empty path will be returned. (no change)
For L=1, if path cannot be found with that constraint, then constraint can be 
ignored and path can be recomputed without considering it at all (SID of that 
algo does not need to be preferred).

From draft perspective it is about modifying this part:

· L (Loose): If set to 1, the PCE MAY insert SIDs with a different 
Algorithm, but it MUST prefer the specified Algorithm whenever possible.

That way PCE can still use SIDs of specified algo, but constraint is not 
enforcing it, so PCE can still compute complete end-to-end path with just algo 
0 SIDs (of included SIDs of specified algo if it is considering it as safe). So 
there are no special requirements from topology pruning or SID filtering for L 
flag.

To me it seems that there would be really too many options/combinations if we 
will keep original definition of that flag and probably not all vendors will 
implement all of them and we will end-up with various interop issues, so would 
need extra capabilities as well to advertise what is supported and what is not.

Thanks,

Re: [Pce] PCE SID-algo draft extension

[Samuel Sidor (ssidor)]

Hi all,

Since nobody else (besides Andrew and Peng Shaofu) had any other 
opinions/proposals, I’ll proceed with draft update.

Regards,
Samuel

From: Andrew Stone (Nokia) 
Sent: Wednesday, April 5, 2023 4:50 PM
To: Samuel Sidor (ssidor) ; peng.sha...@zte.com.cn
Cc: pce@ietf.org; pce-cha...@ietf.org; slitkows.i...@gmail.com; 
d...@dhruvdhody.com
Subject: Re: [Pce] PCE SID-algo draft extension

Hi Samuel, ACK – rationale and comparisons sounds reasonable and good to me.

Thanks
Andrew

From: "Samuel Sidor (ssidor)" mailto:ssi...@cisco.com>>
Date: Wednesday, April 5, 2023 at 4:48 AM
To: "Andrew Stone (Nokia)" 
mailto:andrew.st...@nokia.com>>, 
"peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>" 
mailto:peng.sha...@zte.com.cn>>
Cc: "pce@ietf.org<mailto:pce@ietf.org>" mailto:pce@ietf.org>>, 
"pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>" 
mailto:pce-cha...@ietf.org>>, 
"slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>" 
mailto:slitkows.i...@gmail.com>>, 
"d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>" 
mailto:d...@dhruvdhody.com>>
Subject: RE: [Pce] PCE SID-algo draft extension


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


Hi Andrew,

My proposal was really to use something like P/I flag from PCEP object. In this 
case, SID-algo constraint is TLV, so there is no way to enforce it using P 
flag), so yes – I meant “permitted to compute and program a path as if LSPA 
never contained the SID Algo TLV”.

If SID-algo constraint is not included, then PCE can use algo SIDs freely (even 
if there is no draft or no SID-algo constraint specified) – e.g. to decrease 
size of label stack. So same thing would apply to L=1. If PCE cannot fully 
satisfy constraint, then it can fallback into “no SID-algo constraint” behavior 
and it can still compute path with algo SIDs if needed, but there is no 
explicit preference to specific algo SIDs or anything like that.

For cases, where for example multi-domain path is needed, where some domains 
have FA support, but some domain does not support that FA, recommended approach 
can be still policy stitching.

I personally consider such approach as consistent with other constraints, which 
we have – e.g. for affinities we also does not have L flag to partially ignore 
it in part of the network, but still consider in other parts. And we have 
“Strict Disjointness” flag in diversity, which almost similar – allowing to 
fallback other disjoint types or non-disjoint path (but still constraint is 
applied to complete path and not only to some hops or some domain). Rules for 
path-computation are already more complex with other constraints (considering 
topology pruning, ASLA constraints, other constraints from PCRpt,…), so 
increasing complexity even more and allowing combination of algos in same 
segment-list, but still preferring some of them can be really too much.

Regards,
Samuel

From: Andrew Stone (Nokia) 
mailto:andrew.st...@nokia.com>>
Sent: Tuesday, April 4, 2023 8:58 PM
To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>; 
peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>
Cc: pce@ietf.org<mailto:pce@ietf.org>; 
pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>; 
slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>; 
d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>
Subject: Re: [Pce] PCE SID-algo draft extension

Hi Samuel,

To confirm what you’re suggesting - It reads to me like it says if L=1, then 
PCE is effectively permitted to compute and program a path as if LSPA never 
contained the SID Algo TLV. Or am I mistaken? Or is the suggestion that it’s 
really up to PCE to decide how ‘loose’ it wants to go in regards to 
‘constraint’ (path prune vs encoding) and it’s permitted to approach the 
problem as a form of relaxation as it sees fit to get the path up? I agree, the 
scope needs to be kept down and clear for relatively consistent interop for 
what the ‘intention’ is of the knobs. I see the standardization goal here about 
intention of the knobs/behavior and wire encoding, but permit implementation to 
decide how best to achieve the signalled intention.

Thanks
Andrew

From: "Samuel Sidor (ssidor)" mailto:ssi...@cisco.com>>
Date: Monday, April 3, 2023 at 9:31 AM
To: "Andrew Stone (Nokia)" 
mailto:andrew.st...@nokia.com>>, 
"peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>" 
mailto:peng.sha...@zte.com.cn>>
Cc: "pce@ietf.org<mailto:pce@ietf.org>" mailto:pce@ietf.org>>, 
"pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>" 
mailto:pce-cha...@ietf.org>>, 
"slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>" 
mailto:slitkows.i...@gmail.com>>, 
&

Re: [Pce] IPR Poll on draft-dhody-pce-stateful-pce-vendor

[Samuel Sidor (ssidor)]

Hi Julien,

I am not aware of any IPR applicable to this draft that should be disclosed in 
accordance with IETF IPR rules.

Regards,
Samuel

From: Pce  On Behalf Of julien.meu...@orange.com
Sent: Tuesday, June 20, 2023 9:52 AM
To: draft-dhody-pce-stateful-pce-ven...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] IPR Poll on draft-dhody-pce-stateful-pce-vendor

Hi Authors,

In preparation for WG adoption on this draft, we'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 the 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,

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

Re: [Pce] Mail regarding draft-ietf-pce-pcep

[Samuel Sidor (ssidor)]

Hi Pavan,

Is it possible to specify usecase a bit?

I’m not against allowing Vendor Info object in OPEN message, but I personally 
tend to agree with Dhruv’s explanation. In general, PCEP open message is 
supposed to exchange/negotiate various capabilities of PCEP peers, timer 
values, path-setup-types,… but all of them seems to be related to Open object, 
so vendor TLV seems to be sufficient for something like that.

In general, I can see benefit in using PCEP object over PCEP TLV (on top of 
logical association with underlaying object) in already defined flags in object 
header (P/I flags), which can help if you want to mark that object as 
mandatory/optional while TLV is always optional and can be ignored during 
parsing. In case of Vendor Info object, I don’t see good reason to mark it as 
mandatory, so flags are not adding any extra value. If you will mark vendor 
object as mandatory, then you will restrict processing of PCEP messages for 
specific LSPs to specific vendor only (logical assumption is that other vendors 
will not be able to process vendor object from other vendors), other vendors 
will have to reject it (if you want to do that, then you don’t need any 
standardization at all as you can use any private format).

So is there really any reason to use vendor info object instead of vendor TLV, 
which should be already allowed?

For argument about consistency – would it be really consistent even after that 
change? My understanding (but others can correct me) that TLVs can be included 
in a lot of PCEP objects (still probably not all as some objects are specifying 
explicitly that optional TLVs can be included, but some PCEP objects have fixed 
length) and all PCEP messages, where PCEP objects with optional TLVs can be 
included. But including any PCEP object MUST be explicitly allowed - including 
potential expected ordering of objects in that PCEP message (considering 
draft-dhody-pce-pcep-object-order).

Thanks,
Samuel

From: Vishnu Pavan Beeram 
Sent: Wednesday, August 2, 2023 7:01 PM
To: Dhruv Dhody 
Cc: Dhruv Dhody ; Marcel Reuter (External) 
; pce@ietf.org; 
draft-ietf-pce-stateful-pce-ven...@ietf.org
Subject: Re: [Pce] Mail regarding draft-ietf-pce-pcep

I'm asking for the usage of the VENDOR_INFORMATION object to be allowed in the 
OPEN message (and not in notification, close and any other message where it is 
not already included). I would let the WG decide if it needs to be part of 
draft-ietf-pce-stateful-pce-vendor (case can be made to include it) or be 
discussed separately.

Regards,
-Pavan

On Wed, Aug 2, 2023 at 9:45 PM Dhruv Dhody 
mailto:d...@dhruvdhody.com>> wrote:
Hi Pavan,

In my personal opinion, the vendor TLV makes sense when the TLV is associated 
with an existing PCEP Object (and it allows optional TLV) and the vendor Object 
for something new! I would mostly consider anything sent in Open message to be 
related to existing OPEN object :)

Just to be clear, do you want this for OPEN message only or ALL PCEP messages 
(that would additionally include notification and close message as well)? If we 
go this route, we may need to change the name of the draft as it is no longer 
just stateful!

Thanks!
Dhruv (no hats)






On Wed, Aug 2, 2023 at 10:19 AM Vishnu Pavan Beeram 
mailto:vishnupa...@gmail.com>> wrote:
Please see inline..

On Wed, Aug 2, 2023 at 7:19 PM Dhruv Dhody 
mailto:d...@dhruvdhody.com>> wrote:
Hi Pavan,

On Wed, Aug 2, 2023 at 8:39 AM Vishnu Pavan Beeram 
mailto:vishnupa...@gmail.com>> wrote:
Marcel, Hi!
Thanks for bringing this to the list! I interpret the text in RFC5440 regarding 
"one OPEN object" to just mean that the Open Message cannot carry more than one 
"OPEN" object.

Dhruv, Hi!
I would propose updating draft-ietf-pce-stateful-pce-vendor to explicitly allow 
the use of the "VENDOR-INFORMATION" object in the Open message. For example, 
implementations may choose to carry "versioning" information in this object 
during the Open message exchange (this information may or may not have any 
impact on the establishment of the PCEP session). As you mentioned, carrying 
the "VENDOR-INFORMATION" TLV in the Open Object is already allowed. I don't see 
any good reason to preclude the use of the "VENDOR-INFORMATION" object in the 
Open message.


Hmm, with that reasoning do we need to do that for all PCEP messages?
[VPB] It is hard to envision what proprietary use-case someone may come up 
with. But allowing the VENDOR-INFORMATION usage in Open message along with 
PCReq, PCReply, PCRpt, PCUpd and PCInitiate messages seems reasonable to me.

Also, is there anything that cannot be achieved via the TLV, and you would need 
the Object in the Open message case? Just wondering...
[VPB] You can achieve everything by using just the Object or just the TLV (this 
is true for other messages as well). I'm advocating a consistent semantic -- 
allow for the use of both VENDOR-INFORMATION object and TLV in all the 
aforementioned messages.


Thanks!
Dhruv



Regards,

Re: [Pce] Mail regarding draft-ietf-pce-pcep

[Samuel Sidor (ssidor)]

Hi Pavan,

Please see inline .

Regards,
Samuel

From: Vishnu Pavan Beeram 
Sent: Thursday, August 3, 2023 4:40 PM
To: Samuel Sidor (ssidor) 
Cc: Dhruv Dhody ; Dhruv Dhody ; 
Marcel Reuter (External) ; pce@ietf.org; 
draft-ietf-pce-stateful-pce-ven...@ietf.org
Subject: Re: [Pce] Mail regarding draft-ietf-pce-pcep

Samuel, Hi!

The requirement is to be able to carry "vendor specific information" in the 
OPEN message. Some of this information may be relevant for deciding whether the 
session should be established or not while some other information may become 
relevant only later when processing LSPs (and has no bearing on "opening" the 
session). An implementation should be able to use the VENDOR_INFO TLV in the 
OPEN object for the former and the VENDOR_INFO Object (marked optional like in 
any other message) for the latter. I don't understand why this 
usage/flexibility needs to be prohibited.

 I don’t think it was explicitly prohibited for vendor info object. It is 
inheriting default rules, which are applied for all PCEP objects. RC5440 
clearly stated that content of PCEP message is described in BNF – so all 
mandatory and optional objects, which can be included are explicitly listed. 
Each RFC, which is defining new PCEP object is explicitly specifying where that 
PCEP object can be included (PCEP message, ordering,…).

I assume that when RFC7470 introduced vendor info object, there was no valid 
use-case for including that PCEP object in Open message, so it was not 
explicitly added – same way like it was not added to other PCEP messages. If we 
want to allow it now, then logical questions are:

  *   What has changed since RFC7470? Is there really new use-case which cannot 
be covered with existing vendor TLV? If we will allow use only in Open message, 
how we will make sure that in 5 months somebody else will not need it in any 
other PCEP message?
  *   How to handle backward compatibility? E.g. what will happen if you will 
start including Vendor Info object in Open message, but existing 
implementations, which are complaint with all existing RFCs will reject those 
Open messages (you need to consider those with support for RFC7470, but also 
those without support)? If extension required is for other PCEP messages, then 
you we can have capability advertised in Open message to figure out, whether 
extension is supported, but since you need to extend PCEP Open message, you 
don’t have simple way to figure it out.
  *   Where such extension should be included? As Dhruv mentioned, logically it 
does not belong into stateful vendor info draft, so we have 2 options:

 *   New draft
 *   Re-working stateful draft to include this change, rename it,…

That said, if the WG concludes that the "vendor specific information" should 
ONLY exist in TLV form in the OPEN message, I would like it to be explicitly 
specified somewhere.

 As described above – for PCEP objects, it is always explicitly specified 
which PCEP object is allowed in which PCEP message. For TLV, RFC7470 is already 
saying:

https://www.rfc-editor.org/rfc/rfc7470.html#section-1

   This document also defines a new PCEP TLV, the VENDOR-INFORMATION-TLV
   that can be used to carry arbitrary information within any existing
   or future PCEP object that supports TLVs.
…

   -  Clarification that the TLV is available for use in any PCEP object

  (existing or future) that supports TLVs.

But maybe other WG members knows about some other statements, which can still 
block it for Open message.

Regards,
-Pavan

On Thu, Aug 3, 2023 at 1:45 PM Samuel Sidor (ssidor) 
mailto:ssi...@cisco.com>> wrote:
Hi Pavan,

Is it possible to specify usecase a bit?

I’m not against allowing Vendor Info object in OPEN message, but I personally 
tend to agree with Dhruv’s explanation. In general, PCEP open message is 
supposed to exchange/negotiate various capabilities of PCEP peers, timer 
values, path-setup-types,… but all of them seems to be related to Open object, 
so vendor TLV seems to be sufficient for something like that.

In general, I can see benefit in using PCEP object over PCEP TLV (on top of 
logical association with underlaying object) in already defined flags in object 
header (P/I flags), which can help if you want to mark that object as 
mandatory/optional while TLV is always optional and can be ignored during 
parsing. In case of Vendor Info object, I don’t see good reason to mark it as 
mandatory, so flags are not adding any extra value. If you will mark vendor 
object as mandatory, then you will restrict processing of PCEP messages for 
specific LSPs to specific vendor only (logical assumption is that other vendors 
will not be able to process vendor object from other vendors), other vendors 
will have to reject it (if you want to do that, then you don’t need any 
standardization at all as you can use any private format).

So is there really any reason to use vendor info object instead of ven

Re: [Pce] Mail regarding draft-ietf-pce-pcep

[Samuel Sidor (ssidor)]

Hi Pavan,

Ack, that is my interpretation as well – it should be possible to use TLV in 
OPEN object.

Regards,
Samuel

From: Vishnu Pavan Beeram 
Sent: Thursday, August 3, 2023 7:48 PM
To: Samuel Sidor (ssidor) 
Cc: Dhruv Dhody ; Dhruv Dhody ; 
Marcel Reuter (External) ; pce@ietf.org; 
draft-ietf-pce-stateful-pce-ven...@ietf.org
Subject: Re: [Pce] Mail regarding draft-ietf-pce-pcep

If we can conclude that the use of the VENDOR-INFORMATION-TLV in OPEN object is 
not precluded by any of the existing documents (and that seems to be what Dhruv 
is saying as well), that is good enough for me.

Regards,
-Pavan

On Thu, Aug 3, 2023 at 10:04 PM Samuel Sidor (ssidor) 
mailto:ssi...@cisco.com>> wrote:
Hi Pavan,

Please see inline .

Regards,
Samuel

From: Vishnu Pavan Beeram mailto:vishnupa...@gmail.com>>
Sent: Thursday, August 3, 2023 4:40 PM
To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>
Cc: Dhruv Dhody mailto:d...@dhruvdhody.com>>; Dhruv Dhody 
mailto:dhruv.i...@gmail.com>>; Marcel Reuter (External) 
mailto:marcel.reuter.exter...@telefonica.com>>;
 pce@ietf.org<mailto:pce@ietf.org>; 
draft-ietf-pce-stateful-pce-ven...@ietf.org<mailto:draft-ietf-pce-stateful-pce-ven...@ietf.org>
Subject: Re: [Pce] Mail regarding draft-ietf-pce-pcep

Samuel, Hi!

The requirement is to be able to carry "vendor specific information" in the 
OPEN message. Some of this information may be relevant for deciding whether the 
session should be established or not while some other information may become 
relevant only later when processing LSPs (and has no bearing on "opening" the 
session). An implementation should be able to use the VENDOR_INFO TLV in the 
OPEN object for the former and the VENDOR_INFO Object (marked optional like in 
any other message) for the latter. I don't understand why this 
usage/flexibility needs to be prohibited.

 I don’t think it was explicitly prohibited for vendor info object. It is 
inheriting default rules, which are applied for all PCEP objects. RC5440 
clearly stated that content of PCEP message is described in BNF – so all 
mandatory and optional objects, which can be included are explicitly listed. 
Each RFC, which is defining new PCEP object is explicitly specifying where that 
PCEP object can be included (PCEP message, ordering,…).

I assume that when RFC7470 introduced vendor info object, there was no valid 
use-case for including that PCEP object in Open message, so it was not 
explicitly added – same way like it was not added to other PCEP messages. If we 
want to allow it now, then logical questions are:

  *   What has changed since RFC7470? Is there really new use-case which cannot 
be covered with existing vendor TLV? If we will allow use only in Open message, 
how we will make sure that in 5 months somebody else will not need it in any 
other PCEP message?
  *   How to handle backward compatibility? E.g. what will happen if you will 
start including Vendor Info object in Open message, but existing 
implementations, which are complaint with all existing RFCs will reject those 
Open messages (you need to consider those with support for RFC7470, but also 
those without support)? If extension required is for other PCEP messages, then 
you we can have capability advertised in Open message to figure out, whether 
extension is supported, but since you need to extend PCEP Open message, you 
don’t have simple way to figure it out.
  *   Where such extension should be included? As Dhruv mentioned, logically it 
does not belong into stateful vendor info draft, so we have 2 options:

 *   New draft
 *   Re-working stateful draft to include this change, rename it,…

That said, if the WG concludes that the "vendor specific information" should 
ONLY exist in TLV form in the OPEN message, I would like it to be explicitly 
specified somewhere.

 As described above – for PCEP objects, it is always explicitly specified 
which PCEP object is allowed in which PCEP message. For TLV, RFC7470 is already 
saying:

https://www.rfc-editor.org/rfc/rfc7470.html#section-1

   This document also defines a new PCEP TLV, the VENDOR-INFORMATION-TLV
   that can be used to carry arbitrary information within any existing
   or future PCEP object that supports TLVs.
…

   -  Clarification that the TLV is available for use in any PCEP object

  (existing or future) that supports TLVs.

But maybe other WG members knows about some other statements, which can still 
block it for Open message.

Regards,
-Pavan

On Thu, Aug 3, 2023 at 1:45 PM Samuel Sidor (ssidor) 
mailto:ssi...@cisco.com>> wrote:
Hi Pavan,

Is it possible to specify usecase a bit?

I’m not against allowing Vendor Info object in OPEN message, but I personally 
tend to agree with Dhruv’s explanation. In general, PCEP open message is 
supposed to exchange/negotiate various capabilities of PCEP peers, timer 
values, path-setup-types,… but all of them seems to be r

Re: [Pce] [PCE]: Draft-ietf-pce-sid-algo: Prefer Intra vs Inter-domain

[Samuel Sidor (ssidor)]

Hi Dhruv,

In case of path-computation done by PCE based on content of FAD (probably vast 
majority of cases), optimization metric will be specified in FAD, so it will 
not be possible to optimize based on other metric type on top of that.

For original question:

I agree with PSF – it would be probably too complex to try to define such 
behavior in the draft. On top of that, such requirement can potentially come 
for non-Flex-algo paths as well.

I can still imagine achieving something like that for example with 2 
candidate-paths:

  *   1st CP (preferred) which will be limited to intra-domain paths using some 
constraints
  *   2nd CP which will not have any restrictions and which can be used in case 
of no intra-domain path

That can be achieved with metric bound of metric pointed out by Dhruv, 
affinity,… set for 1st CP. Theoretically same thing can be achieved by setting 
MSD bound in 1st CP as with Flex-algo path-computation will probably result in 
just one SID anyway (Flex-algo SID of destination) – at least if other 
constraints are not applied on top of that.

Regards,
Samuel

From: Pce  On Behalf Of Dhruv Dhody
Sent: Tuesday, September 19, 2023 5:48 AM
To: peng.sha...@zte.com.cn
Cc: pce@ietf.org
Subject: Re: [Pce] [PCE]: Draft-ietf-pce-sid-algo: Prefer Intra vs Inter-domain

Hi Marcel, PSF,

Speaking as a WG participant...

Note that we do have a metric type "T=20: Domain Count metric (number of 
domains crossed)."; we can simply use this metric type, asking the PCE to 
optimize based on this which should lead to preferring intra-domain paths. See 
https://www.rfc-editor.org/rfc/rfc8685.html#section-3.5

Thanks!
Dhruv

On Tue, Sep 19, 2023 at 9:04 AM 
mailto:peng.sha...@zte.com.cn>> wrote:



Hi Marcel,



May it be a local policy of PCE ?

For a given  that belongs to the same domain, it may be

the default policy for PCE to calculate a candidate path intra domain.

Otherwise, it may bring unnecessary complexity. For example, for a real 
inter-domain

path requirement of  that belongs to the different 
domain,

the intention is to split the path calculation requirements into multiple 
domains, e.g,

 for domain 1,  for domain 2, etc. Now, in this 
case,

does  itself again get a inter-domain path ? In theory, yes. 
But in

reality, it doesn't make sense.



Regards,

PSF


Original
From: MarcelReuter(External) 
mailto:marcel.reuter.exter...@telefonica.com>>
To: pce@ietf.org mailto:pce@ietf.org>>;
Date: 2023年09月15日 16:25
Subject: [Pce] [PCE]: Draft-ietf-pce-sid-algo: Prefer Intra vs Inter-domain
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
Aloha,
Dear colleagues,

I have a question regarding the PCE with SR Flex-algo and multiple IGP domains.

In my understanding in each IGP Domain the Flex-Algo is calculated 
independently of each other domain.
The PCE should have the view of all IGP domains, including IGP metrics and 
delay metrics.

So if the PCE calculate a path and ingress and egress PE are in the same IGP 
domain,
It would be preferable to choose an IGP intra domain vs using another IGP as 
transit.
Or at least have the possibility to choose or prefer an Intra-Domain path (with 
a flag maybe?)

Reason:
Especially in mobile operator RAN networks, there could be bandwidth 
limitations in RAN IGP domains, but still a lower delay path.

What’s your opinion about this?

Thanks
Marcel









Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede 
contener información privilegiada o confidencial y es para uso exclusivo de la 
persona o entidad de destino. Si no es usted. el destinatario indicado, queda 
notificado de que la lectura, utilización, divulgación y/o copia sin 
autorización puede estar prohibida en virtud de la legislación vigente. Si ha 
recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente 
por esta misma vía y proceda a su destrucción.

The information contained in this transmission is confidential and privileged 
information intended only for the use of the individual or entity named above. 
If the reader of this message is not the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this transmission in error, do not 
read it. Please immediately reply to the sender that you have received this 
communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode 
conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa 
ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica 
notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização 
pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem 
por erro, rogamos-lhe que nos o comunique imedi

Re: [Pce] WG Adoption of draft-chen-pce-bier-11

[Samuel Sidor (ssidor)]

Hi all,

I support adoption of this draft, but I have a few minor (non-blocking) 
comments:

2.  Terminology
“EROO” – ERO already means “Explicit Route Object”, so why we have “Explicit 
Route Object Object”. Same applies to RROO vs RRO.

I would just use ERO directly same way like it is done in other PCEP 
RFCs/drafts.

5.  PCEP Messages

“PCRep/PCRpt message so as to indicate the
   objective function that was used by the PCE during path computation”

So PCRpt is used to indicate OF which was used by PCE in the path-computation? 
Is that meant in case if PCE computed path using some OF, then used 
PCUpdate/PCRep to indicate OF to PCC and after that PCC is including it in 
PCRpt towards other PCEs in the network? Is OF supposed to included in PCUpd 
message as well?

6.2.  The LSP Object

“…SHOULD NOT be inclueded in a…” -> typo

Also consider re-ordering description of fields to follow structure of TLV – it 
would be easier to find description of specific field.

TLV structure has Tunnel-ID, BFR-prefix, BFR-ID, sub-domain, but description is 
starting with sub-domain and ending with BFR-prefix.

6.6.  ERO Object(EROO)

“The EROO is carried within a PCRep message
   to provide the computed TE LSP if the path computation was
   successful.”

I assume that this applies to other PCEP messages (e.g. PCUpd). Also we already 
defined “EROO” in terminology section, so I assume that we don’t need to repeat 
it title.

6.6.1.  BIER-TE-ERO Subobject

“BS Length” – is this explicit length field needed to indicate length of 
BItString or this can be derived from subobject length?

6.7.  RRO Object(RROO)

“The PCC reports
   an BIER-TE to a PCE by sending a PCRpt message with RROO.”

So if I understood it correctly, we known that RRO will be same as ERO, ERO is 
mandatory in PCRpt, so we will send duplicate info in PCRpt? Is new RRO 
subobject really needed?

7.1.  Exchanging the BIER-TE Capability

“…BIER-TE by including the BIET-TE-PCE-
   CAPABILITY sub-TLV…” -> typo

Maybe also consider if it worth mentioning what should happen if LSP with 
BIER-TE PST is received, but BIER-TE PST capability was not exchanged in PCOpen

7.2.  BIER-TE-ERO Processing

“If a PCC does not support the BIER-TE PCE Capability and thus cannot
  recognize the BIER-TE-ERO or BIER-TE-RRO subobjects,The ERO and BIER-
   TE-ERO subobject processing remains as per [RFC5440].”

Shouldn’t this be really based on PST of LSP? So if BIER-TE ERO/RRO is 
included, then PST of that LSP MUST be BIER-TE and I assume that BIER-TE PST 
can be used only if it is negotiated in PST capabilities. Or are we allowing to 
use BIER-TE subobjects in other cases as well?

8.  IANA Considerations

“IANA is requested to make the following allocation Ifor the protocol” -> typo

Regards,
Samuel

From: Pce  On Behalf Of Dhruv Dhody
Sent: Monday, September 25, 2023 6:49 PM
To: pce@ietf.org
Cc: draft-chen-pce-b...@ietf.org
Subject: [Pce] WG Adoption of draft-chen-pce-bier-11

Hi WG,

This email begins the WG adoption poll for draft-chen-pce-bier-11.

https://datatracker.ietf.org/doc/draft-chen-pce-bier/

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.

Please respond by Monday 9th Oct 2023.

Please be more vocal during WG polls!

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

Re: [Pce] Subject: Re: WG Adoption of draft-chen-pce-bier-11

[Samuel Sidor (ssidor)]

Hi Ran,

Thanks a lot for your responses. Please see inline responses marked with 
[Samuel]

Thanks,
Samuel

From: chen@zte.com.cn 
Sent: Sunday, October 8, 2023 11:28 AM
To: Samuel Sidor (ssidor) 
Cc: pce@ietf.org
Subject: Re: Subject: Re: [Pce] WG Adoption of draft-chen-pce-bier-11


Hi Samuel,



Many thanks for your support and helpful review.

Please find my notes below tagged [Ran]



Best Regards,

Ran

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


Hi all,



I support adoption of this draft, but I have a few minor (non-blocking) 
comments:



2.  Terminology

“EROO” – ERO already means “Explicit Route Object”, so why we have “Explicit 
Route Object Object”. Same applies to RROO vs RRO.



I would just use ERO directly same way like it is done in other PCEP 
RFCs/drafts.

[Ran]: Indeed, I added an extra object, so the abbreviation is EROO. We will 
update it. Thanks.



5.  PCEP Messages



“PCRep/PCRpt message so as to indicate the

   objective function that was used by the PCE during path computation”



So PCRpt is used to indicate OF which was used by PCE in the path-computation? 
Is that meant in case if PCE computed path using some OF, then used 
PCUpdate/PCRep to indicate OF to PCC and after that PCC is including it in 
PCRpt towards other PCEs in the network? Is OF supposed to included in PCUpd 
message as well?

[Ran]: Yes. The OF object is carried within a PCReq/PCRpt  to indicate the 
required/desired objective function to be applied by  a PCE, or in a PCRep/ 
PCUpd to indicate the objective function that was used for path computation. 
Will add it.





6.2.  The LSP Object



“…SHOULD NOT be inclueded in a…” -> typo



Also consider re-ordering description of fields to follow structure of TLV – it 
would be easier to find description of specific field.



TLV structure has Tunnel-ID, BFR-prefix, BFR-ID, sub-domain, but description is 
starting with sub-domain and ending with BFR-prefix.

 [Ran]: Sure.



6.6.  ERO Object(EROO)



“The EROO is carried within a PCRep message

   to provide the computed TE LSP if the path computation was

   successful.”



I assume that this applies to other PCEP messages (e.g. PCUpd). Also we already 
defined “EROO” in terminology section, so I assume that we don’t need to repeat 
it title.

 [Ran]:  Yes.  This description will be deleted.

6.6.1.  BIER-TE-ERO Subobject



“BS Length” – is this explicit length field needed to indicate length of 
BItString or this can be derived from subobject length?

 [Ran]:  Yes. It is explicit length field needed to indicate length of 
Bitstring, and this can't be derived from subobject length.
[Samuel]Is there any reason why it cannot be derived? I thought that only 
variable part of BIER ERO subobjects is BitString. If I know length of complete 
subobject (8+ bytes) and I have 1 field with variable length and rest of fields 
with fixed length (4 bytes), then it should not be hard to get length of 
Bitstring (Length – 4 bytes). Same way like you now defined, then value 1 means 
64 bits, then you can just say that 8 bytes long “Adjacency BitString” means 
64bits,… Anyway, I’m fine with explicit field, I just thought that it may be 
possible to optimize.

6.7.  RRO Object(RROO)



“The PCC reports

   an BIER-TE to a PCE by sending a PCRpt message with RROO.”



So if I understood it correctly, we known that RRO will be same as ERO, ERO is 
mandatory in PCRpt, so we will send duplicate info in PCRpt? Is new RRO 
subobject really needed?

[Ran]:  Yes. The format of the RRO subobject is the same as that of the ERO 
subobject, but without the L-Flag.

According to the definition in RFC8231:

The actual path, represented by the RRO object, SHOULD be included in  a PCRpt 
by the PCC when the path is up or active, but it MAY be omitted if the path is 
down due to a signaling error or another failure.

We can add the following description:

A PCC reports an BIER-TE to a PCE by sending a PCRpt message, per [RFC8231].  
The RRO on this message represents one or more adjacencies BitStrings that was 
applied by the PCC, that is, the actual path taken by the LSP.  The procedures 
of [RFC8231] with respect to the RRO apply equally to this specification 
without change.

[Samuel] I copied only part of the statement, but I was more talking about that 
section in general:
   For the integrity of the protocol, we define a new BIER-TE-RRO
   object, but its actual value is consistent with ERO.  The PCC reports
   an BIER-TE to a PCE by sending a PCRpt message with RROO.

And I was thinking about dropping definition of RRO subobject completely as it 
has no added value (it contains duplicate information in PCRpt based on this 
statement). But I agree that RFC8231 still requires RRO as “logical delimiter” 
between actual and requested attributes, so we cannot just skip that object and 
having some special behavior just for

Re: [Pce] Subject: Re: WG Adoption of draft-chen-pce-bier-11

[Samuel Sidor (ssidor)]

Hi Ran,

Thanks a lot, for responses. Agreed on all points.

For BS Length, if added value of that field is the use on other places (BIER 
header), maybe just consider mentioning that usage explicitly in the draft.

Regards,
Samuel

From: chen@zte.com.cn 
Sent: Tuesday, October 10, 2023 4:47 AM
To: Samuel Sidor (ssidor) 
Cc: pce@ietf.org
Subject: Re: Subject: Re: [Pce] WG Adoption of draft-chen-pce-bier-11


Hi Samuel，

Thank you very much for your quick reply. Please find my notes below tagged 
[Ran].



Best Regards,

Ran


Original
From: SamuelSidor(ssidor) mailto:ssi...@cisco.com>>
To: 陈然00080434;
Cc: pce@ietf.org<mailto:pce@ietf.org> mailto:pce@ietf.org>>;
Date: 2023年10月09日 16:46
Subject: RE: Subject: Re: [Pce] WG Adoption of draft-chen-pce-bier-11
Hi Ran,

Thanks a lot for your responses. Please see inline responses marked with 
[Samuel]

Thanks,
Samuel

From: chen@zte.com.cn<mailto:chen@zte.com.cn> 
mailto:chen@zte.com.cn>>
Sent: Sunday, October 8, 2023 11:28 AM
To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: Subject: Re: [Pce] WG Adoption of draft-chen-pce-bier-11


Hi Samuel,



Many thanks for your support and helpful review.

Please find my notes below tagged [Ran]



Best Regards,

Ran

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

Hi all,



I support adoption of this draft, but I have a few minor (non-blocking) 
comments:



2.  Terminology

“EROO” – ERO already means “Explicit Route Object”, so why we have “Explicit 
Route Object Object”. Same applies to RROO vs RRO.



I would just use ERO directly same way like it is done in other PCEP 
RFCs/drafts.

[Ran]: Indeed, I added an extra object, so the abbreviation is EROO. We will 
update it. Thanks.



5.  PCEP Messages



“PCRep/PCRpt message so as to indicate the

   objective function that was used by the PCE during path computation”



So PCRpt is used to indicate OF which was used by PCE in the path-computation? 
Is that meant in case if PCE computed path using some OF, then used 
PCUpdate/PCRep to indicate OF to PCC and after that PCC is including it in 
PCRpt towards other PCEs in the network? Is OF supposed to included in PCUpd 
message as well?

[Ran]: Yes. The OF object is carried within a PCReq/PCRpt  to indicate the 
required/desired objective function to be applied by  a PCE, or in a PCRep/ 
PCUpd to indicate the objective function that was used for path computation. 
Will add it.





6.2.  The LSP Object



“…SHOULD NOT be inclueded in a…” -> typo



Also consider re-ordering description of fields to follow structure of TLV – it 
would be easier to find description of specific field.



TLV structure has Tunnel-ID, BFR-prefix, BFR-ID, sub-domain, but description is 
starting with sub-domain and ending with BFR-prefix.

 [Ran]: Sure.



6.6.  ERO Object(EROO)



“The EROO is carried within a PCRep message

   to provide the computed TE LSP if the path computation was

   successful.”



I assume that this applies to other PCEP messages (e.g. PCUpd). Also we already 
defined “EROO” in terminology section, so I assume that we don’t need to repeat 
it title.

 [Ran]:  Yes.  This description will be deleted.

6.6.1.  BIER-TE-ERO Subobject



“BS Length” – is this explicit length field needed to indicate length of 
BItString or this can be derived from subobject length?

 [Ran]:  Yes. It is explicit length field needed to indicate length of 
Bitstring, and this can't be derived from subobject length.
[Samuel]Is there any reason why it cannot be derived? I thought that only 
variable part of BIER ERO subobjects is BitString. If I know length of complete 
subobject (8+ bytes) and I have 1 field with variable length and rest of fields 
with fixed length (4 bytes), then it should not be hard to get length of 
Bitstring (Length – 4 bytes). Same way like you now defined, then value 1 means 
64 bits, then you can just say that 8 bytes long “Adjacency BitString” means 
64bits,… Anyway, I’m fine with explicit field, I just thought that it may be 
possible to optimize.
[Ran]: Yes, I agree. In this way, we can deduce it. Another thing to consider 
is BSL is not only used to display bitstring length, BSL is important 
information for BIER. BSL is also used when encapsulating the BIER header.

6.7.  RRO Object(RROO)



“The PCC reports

   an BIER-TE to a PCE by sending a PCRpt message with RROO.”



So if I understood it correctly, we known that RRO will be same as ERO, ERO is 
mandatory in PCRpt, so we will send duplicate info in PCRpt? Is new RRO 
subobject really needed?

[Ran]:  Yes. The format of the RRO subobject is the same as that of the ERO 
subobject, but without the L-Flag.

According to the definition in RFC8231:

The actual path, represented by the RRO object, SHOULD be included in  a PCRpt 
by the PCC when the pa

[Pce] Implementations of draft-ietf-pce-sid-algo draft

[Samuel Sidor (ssidor)]

Hi all,

I asked PCE WG members during IETF 118 PCE session for sending me (or to draft 
mailing list) information about any existing implementation of this draft, so 
we can track them properly.

I'm sending it here as well as a reminder.

Thanks a lot,
Samuel
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] In prep for adoption call for draft-sidor-pce-circuit-style-pcep-extensions

[Samuel Sidor (ssidor)]

Hi Dhruv,

Please see inline .

Thanks a lot,
Samuel

From: Dhruv Dhody 
Sent: Saturday, November 25, 2023 6:23 AM
To: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org
Cc: pce-chairs ; pce@ietf.org
Subject: In prep for adoption call for 
draft-sidor-pce-circuit-style-pcep-extensions

Hi,

Can you please upload a new version of the I-D that tidies up the document in 
preparation for WG adoption call?

- Limit the number of authors to 5
 I’ll discuss with existing co-authors and I’ll move some of them to 
contributors.
- Add text to the security consideration section (add references to relevant 
rfcs if no new security threat is assumed)
 I’ll add pointers to security considerations from RFC5440, RFC8231, RFC8281 
and potential consideration for using best practices from RFC7525.
- Think about adding a mangebility consideration
 I’ll add it.
- Instead of saying that the applicability to RSVP-TE and SR-TE better yet say 
it is applicable to all path setup types!
 Makes sense, I’ll update it.
- I am confused by - "For example

   Adjacency SIDs MAY be used, but Prefix SIDs MUST NOT be used (even if
there is only one adjacency). the PCE MUST use Adjacency SIDs only."; are Adj 
SID "MAY" or "MUST"?? It should be MUST right?
 There was discussion between co-authors to allow adjacency SIDs, block 
prefix SIDs, but still maintain future compatibility for any other SID type if 
needed, so we wanted to avoid MUST statement. I’ll drop second statement.
- What is the way to indicate that a computed path no longer meets the original 
constraints when the recomputation is blocked? Isn't that something that is 
useful for operators to know?
 Operators are notified, but they are notified from PCE (northbound 
direction) – behavior also depends on flags set in that TLV:
- if P flag is cleared, PCE can still re-compute if constraints are not 
satisfied (I assume that you are not talking about this case)
- if P flag is set and F flag is cleared, then operators are notified on PCE 
and they may decide to trigger manual re-computation on PCE as described in CS 
SR policy 
draft
- if P flag is set and F flag is set, then there is no way to update LSP, so 
assumption is that operator does not want PCE to monitor validity of that path 
and it relies on liveness detection done by headend 
(reference),
 which is obviously not monitoring some set of constraints.
- When the P flag is cleared or the TLV is not present, we fall back to the 
existing scenario and in which one would assume PCE does the recomputation 
based on various triggers yet the draft uses "MAY recompute"... could this be a 
"SHOULD"?
 Even “SHOULD” is probably not ideal (but I agree that probably better than 
“MAY” in this case) – I’ll think about it a bit if I can re-phrase it.
- Add implementation Status if you have plans of implementations!
 Sure, I can add it.

Thanks!
Dhruv


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

Re: [Pce] In prep for adoption call for draft-sidor-pce-circuit-style-pcep-extensions

[Samuel Sidor (ssidor)]

Just to keep mail thread updated.

New version submitted (and thanks again for your comments Dhruv).

Regards,
Samuel

From: Samuel Sidor (ssidor) 
Sent: Monday, November 27, 2023 10:27 AM
To: Dhruv Dhody ; 
draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org
Cc: pce-chairs ; pce@ietf.org
Subject: RE: In prep for adoption call for 
draft-sidor-pce-circuit-style-pcep-extensions

Hi Dhruv,

Please see inline .

Thanks a lot,
Samuel

From: Dhruv Dhody mailto:d...@dhruvdhody.com>>
Sent: Saturday, November 25, 2023 6:23 AM
To: 
draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org<mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org>
Cc: pce-chairs mailto:pce-cha...@ietf.org>>; 
pce@ietf.org<mailto:pce@ietf.org>
Subject: In prep for adoption call for 
draft-sidor-pce-circuit-style-pcep-extensions

Hi,

Can you please upload a new version of the I-D that tidies up the document in 
preparation for WG adoption call?

- Limit the number of authors to 5
 I’ll discuss with existing co-authors and I’ll move some of them to 
contributors.
- Add text to the security consideration section (add references to relevant 
rfcs if no new security threat is assumed)
 I’ll add pointers to security considerations from RFC5440, RFC8231, RFC8281 
and potential consideration for using best practices from RFC7525.
- Think about adding a mangebility consideration
 I’ll add it.
- Instead of saying that the applicability to RSVP-TE and SR-TE better yet say 
it is applicable to all path setup types!
 Makes sense, I’ll update it.
- I am confused by - "For example

   Adjacency SIDs MAY be used, but Prefix SIDs MUST NOT be used (even if
there is only one adjacency). the PCE MUST use Adjacency SIDs only."; are Adj 
SID "MAY" or "MUST"?? It should be MUST right?
 There was discussion between co-authors to allow adjacency SIDs, block 
prefix SIDs, but still maintain future compatibility for any other SID type if 
needed, so we wanted to avoid MUST statement. I’ll drop second statement.
- What is the way to indicate that a computed path no longer meets the original 
constraints when the recomputation is blocked? Isn't that something that is 
useful for operators to know?
 Operators are notified, but they are notified from PCE (northbound 
direction) – behavior also depends on flags set in that TLV:
- if P flag is cleared, PCE can still re-compute if constraints are not 
satisfied (I assume that you are not talking about this case)
- if P flag is set and F flag is cleared, then operators are notified on PCE 
and they may decide to trigger manual re-computation on PCE as described in CS 
SR policy 
draft<https://www.ietf.org/archive/id/draft-ietf-spring-cs-sr-policy-01.html#name-candidate-path-re-computati>
- if P flag is set and F flag is set, then there is no way to update LSP, so 
assumption is that operator does not want PCE to monitor validity of that path 
and it relies on liveness detection done by headend 
(reference<https://www.ietf.org/archive/id/draft-ietf-spring-cs-sr-policy-01.html#name-connectivity-verification>),
 which is obviously not monitoring some set of constraints.
- When the P flag is cleared or the TLV is not present, we fall back to the 
existing scenario and in which one would assume PCE does the recomputation 
based on various triggers yet the draft uses "MAY recompute"... could this be a 
"SHOULD"?
 Even “SHOULD” is probably not ideal (but I agree that probably better than 
“MAY” in this case) – I’ll think about it a bit if I can re-phrase it.
- Add implementation Status if you have plans of implementations!
 Sure, I can add it.

Thanks!
Dhruv


--- Begin Message ---
A new version of Internet-Draft
draft-sidor-pce-circuit-style-pcep-extensions-05.txt has been successfully
submitted by Samuel Sidor and posted to the
IETF repository.

Name: draft-sidor-pce-circuit-style-pcep-extensions
Revision: 05
Title:PCEP extensions for Circuit Style Policies
Date: 2023-12-01
Group:Individual Submission
Pages:12
URL:  
https://www.ietf.org/archive/id/draft-sidor-pce-circuit-style-pcep-extensions-05.txt
Status:   
https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/
HTML: 
https://www.ietf.org/archive/id/draft-sidor-pce-circuit-style-pcep-extensions-05.html
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-sidor-pce-circuit-style-pcep-extensions
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-sidor-pce-circuit-style-pcep-extensions-05

Abstract:

   This document proposes a set of extensions for Path Computation
   Element Communication Protocol (PCEP) for Circuit Style Policies -
   Segment-Routing Policy designed to satisfy requirements for
   connection-oriented transport services.  New TLV is introduced to
   control path recomputation and new flag to add ability to request
   path with strict hops only.



The IETF Secretariat


--- End Message ---
___

Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05

[Samuel Sidor (ssidor)]

Hi WG,

I support adoption of this draft (co-author).

It provides useful extensions to PCEP for Circuit style policies, but those 
changes are potentially re-usable for other use cases,

There is draft in spring, which is defining CS policy and it was adopted 
already:
https://datatracker.ietf.org/doc/draft-ietf-spring-cs-sr-policy/ and changes in 
PCEP draft are needed to fully support it.

To comment “What needs to be fixed before or after adoption?” – just to keep WG 
informed – we (co-authors) plan to add capability advertisement after adoption.

Thanks a lot,
Samuel

From: Dhruv Dhody 
Sent: Friday, December 1, 2023 11:33 AM
To: pce@ietf.org
Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org
Subject: WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05

Hi WG,

This email begins the WG adoption poll for 
draft-sidor-pce-circuit-style-pcep-extensions-05.

https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/

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.

Please respond by Friday 15th Dec 2023.

Please be more vocal during WG polls!

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

Re: [Pce] IPR poll for draft-sidor-pce-circuit-style-pcep-extensions-05

[Samuel Sidor (ssidor)]

Hi all,

I am aware of the IPR applicable to this draft, and it has already been 
disclosed to the IETF.

Regards,
Samuel

From: Dhruv Dhody 
Sent: Friday, December 1, 2023 11:40 AM
To: Samuel Sidor (ssidor) ; praveen.maheshw...@airtel.com; 
Stone, Andrew (Nokia - CA/Ottawa) ; Jalil, Luay 
; Pengshuping (Peng Shuping) 
Cc: pce@ietf.org
Subject: IPR poll for draft-sidor-pce-circuit-style-pcep-extensions-05

Hi Authors,

In preparation for WG adoption on this draft, we'd like all authors 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 the 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,
Dhruv
--- Begin Message ---
Dear Samuel Sidor, Praveen Maheshwari, Andrew Stone, Luay Jalil, Shuping Peng:


An IPR disclosure that pertains to your Internet-Draft entitled "PCEP
extensions for Circuit Style Policies"
(draft-sidor-pce-circuit-style-pcep-extensions) was submitted to the IETF
Secretariat on 2023-12-06 and has been posted on the "IETF Page of
Intellectual Property Rights Disclosures"
(https://datatracker.ietf.org/ipr/6230/). The title of the IPR disclosure is
"Cisco Systems, Inc.'s Statement about IPR related to
draft-sidor-pce-circuit-style-pcep-extensions and
draft-ietf-spring-cs-sr-policy"


Thank you

IETF Secretariat


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

Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05

[Samuel Sidor (ssidor)]

Hi Quan,

Originally we explicitly listed

From: Pce  On Behalf Of xiong.q...@zte.com.cn
Sent: Thursday, December 14, 2023 7:53 AM
To: d...@dhruvdhody.com
Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org; pce@ietf.org
Subject: Re: [Pce] WG Adoption of 
draft-sidor-pce-circuit-style-pcep-extensions-05


Hi Dhruv,



I support the adoption of this draft. Thanks for the work from authors.

But I am confused about section 1 "PCEP extensions described in this document 
are applicable to all Path   Setup Types".

This draft mainly focus on the Circuit Style Policies and SR policy but path 
setup types include RSVP-TE,SR,PCECC,SRv6, Native IP TE path  and the newly 
adopted BIER-TE.

I suggest that it is better to provide clarification about other path setup 
types or remove this sentence.



Thanks,

Quan

Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05

[Samuel Sidor (ssidor)]

Hi Quan,

(sorry I sent it before finishing mail)

Originally we listed explicitly only RSVP-TE and SR-TE and then we modified 
based on comments from Dhruv to all setup types (attached mail).

Extensions covered in this draft were introduced to support required extensions 
for CS policies, but at least some of those extensions (if specific section is 
not describing something else) is potentially applicable to other setup types. 
E.g. extensions from section 3.2 for blocking re-computation.

We can still drop that specific statement and explicitly describe for each 
extension whether it is generic or applicable to specific setup type only. 
Would that work for you?

Thanks,
Samuel

From: Samuel Sidor (ssidor)
Sent: Thursday, December 14, 2023 9:24 AM
To: xiong.q...@zte.com.cn; d...@dhruvdhody.com
Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org; pce@ietf.org
Subject: RE: [Pce] WG Adoption of 
draft-sidor-pce-circuit-style-pcep-extensions-05

Hi Quan,

Originally we explicitly listed

From: Pce mailto:pce-boun...@ietf.org>> On Behalf Of 
xiong.q...@zte.com.cn<mailto:xiong.q...@zte.com.cn>
Sent: Thursday, December 14, 2023 7:53 AM
To: d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>
Cc: 
draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org<mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org>;
 pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: [Pce] WG Adoption of 
draft-sidor-pce-circuit-style-pcep-extensions-05


Hi Dhruv,



I support the adoption of this draft. Thanks for the work from authors.

But I am confused about section 1 "PCEP extensions described in this document 
are applicable to all Path   Setup Types".

This draft mainly focus on the Circuit Style Policies and SR policy but path 
setup types include RSVP-TE,SR,PCECC,SRv6, Native IP TE path  and the newly 
adopted BIER-TE.

I suggest that it is better to provide clarification about other path setup 
types or remove this sentence.



Thanks,

Quan



<https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/Should
 this draft be adopted by the PCE <--- Begin Message ---
Hi,

Can you please upload a new version of the I-D that tidies up the document in 
preparation for WG adoption call?

- Limit the number of authors to 5
- Add text to the security consideration section (add references to relevant 
rfcs if no new security threat is assumed)
- Think about adding a mangebility consideration
- Instead of saying that the applicability to RSVP-TE and SR-TE better yet say 
it is applicable to all path setup types!
- I am confused by - "For example
   Adjacency SIDs MAY be used, but Prefix SIDs MUST NOT be used (even if
there is only one adjacency). the PCE MUST use Adjacency SIDs only."; are Adj 
SID "MAY" or "MUST"?? It should be MUST right?
- What is the way to indicate that a computed path no longer meets the original 
constraints when the recomputation is blocked? Isn't that something that is 
useful for operators to know?
- When the P flag is cleared or the TLV is not present, we fall back to the 
existing scenario and in which one would assume PCE does the recomputation 
based on various triggers yet the draft uses "MAY recompute"... could this be a 
"SHOULD"?
- Add implementation Status if you have plans of implementations!

Thanks!
Dhruv


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

Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05

[Samuel Sidor (ssidor)]

Hi Ran,

Thanks for your comments.

Correct, we are just introducing new flag in existing TLV. Original title seems 
to be aligned with other drafts introducing new flags in that TLV, e.g.:

https://datatracker.ietf.org/doc/html/draft-peng-pce-entropy-label-position-10#name-the-lsp-extended-flag-tlv

but I can still rename it to follow your suggestion and it seems to be more 
accurate (“New Flag in the LSP-EXTENDED-FLAGS TLV”).

For “Type” and “Length” fields – those are based on older draft version of 
RFC9357 
(https://datatracker.ietf.org/doc/html/draft-ietf-pce-lsp-extended-flags-07 ). 
The plan was to introduce TLV format after assigning IANA codepoint for new 
flag allocated and as part of TLV format, we are usually describing content of 
individual fields in that TLV (including type and length). I can drop them for 
now, since codepoints were not allocated and TLV format is not included.

For “E-flag” – I agree, I can drop it as it does not make sense to list all 
flags already allocated in that TLV. Originally we mentioned that draft only to 
explicitly indicate that there are other drafts, which are trying to allocate 
fields in that TLV.

Regards,
Samuel

From: chen@zte.com.cn 
Sent: Thursday, December 14, 2023 8:59 AM
To: d...@dhruvdhody.com; pce@ietf.org; 
draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org
Subject: Re: [Pce] WG Adoption of 
draft-sidor-pce-circuit-style-pcep-extensions-05


Hi WG



I surport the adoption of this draft, it is very useful. but I have a few minor 
(non-blocking) comments:

3.1.  LSP-EXTENDED-FLAG TLV

The LSP object is defined in Section 7.3 of [RFC8231], and the new extended 
flags TLV is defined in [RFC9357]. This draft reuse the new extended flags TLV 
is defined in [RFC9357], and only defines a new flag,right? If so, it is 
recommended that the title be changed to "New Flag in the LSP-EXTENDED-FLAGS 
TLV" which is more appropriate.

I am confused when I see the description below in the draft:

[cid:image001.png@01DA2E70.4A875950]

In addition, Not only [I-D.peng-pce-entropy-label-position] has defined the 
E-flag, IANA has already assigned multiple LSP-EXTENDED-FLAG TLV Flag Field , 
see link: 
https://www.iana.org/assignments/pcep/pcep.xhtml#lsp-extended-flag-tlv-flags.   
It is recommended to delete the description of E-flag.

Best Regards,

Ran




Original
From: DhruvDhody mailto:d...@dhruvdhody.com>>
To: pce@ietf.org mailto:pce@ietf.org>>;
Cc: 
draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org
 
mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org>>;
Date: 2023年12月01日 18:33
Subject: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
Hi WG,

This email begins the WG adoption poll for 
draft-sidor-pce-circuit-style-pcep-extensions-05.

https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/

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.

Please respond by Friday 15th Dec 2023.

Please be more vocal during WG polls!

Thanks!
Dhruv & Julien


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

Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05

[Samuel Sidor (ssidor)]

Hi Guan,

By any chance, do you know about some specific reason why we would have to 
block for example path-recomputation TLV for BIER-TE or PCECC?

To me something like ability to block path re-computation on PCE for specific 
LSP is generic extension. Whether there is practical use for specific path 
setup type is different question, but we don’t need to block such extension 
because of that (we have a lot of PCEP objects/TLVs which are defined 
generically and just not usable for LSPs of specific setup type).

I personally consider having explicit list of supported path-setup types as 
less future proof (that’s why I modified based on comment from Dhruv to all 
setup types as I considered it as cleaner solution).

For Strict-path flag from section 3.1 – that is slightly more questionable, but 
in general we are again talking only about bringing up O flag from RP object 
from stateless messages (PCReq/PCRep) to stateful messages 
(PCRpt,PCUpd,PCinit). So something what was already supposed to be supported by 
all setup types.

So is there really something what needs to be explicitly blocked? I can rather 
imagine explicitly defining behavior for specific setup type (like BIER-TE or 
PCECC) for any of those extensions if we can see added value in using it, but 
behavior is not clear (that can be still done after adoption and discussion 
with PCE WG or authors of RFCs/drafts introducing those setup types).

Thanks,
Samuel

From: xiong.q...@zte.com.cn 
Sent: Thursday, December 14, 2023 10:22 AM
To: Samuel Sidor (ssidor) 
Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org; 
d...@dhruvdhody.com; pce@ietf.org
Subject: Re: [Pce] WG Adoption of 
draft-sidor-pce-circuit-style-pcep-extensions-05


Hi Samuel,



Thanks for your quick reply!

Yes, I agree with you. The extensions may be applicable for 
RSVP-TE,SR,SRv6,native IP, but I am not sure about it with BIER-TE and PCECC.

It works well for me to explicitly describe for each extension whether it is 
generic or applicable to specific setup type.

Thanks for your work!



Best Regards,

Quan






Original
From: SamuelSidor(ssidor) mailto:ssi...@cisco.com>>
To: 熊泉00091065;
Cc: 
draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org<mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org>
 
mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org>>;d...@dhruvdhody.com
 mailto:d...@dhruvdhody.com>>;pce@ietf.org 
mailto:pce@ietf.org>>;
Date: 2023年12月14日 16:27
Subject: RE: [Pce] WG Adoption of 
draft-sidor-pce-circuit-style-pcep-extensions-05
Hi Quan,

(sorry I sent it before finishing mail)

Originally we listed explicitly only RSVP-TE and SR-TE and then we modified 
based on comments from Dhruv to all setup types (attached mail).

Extensions covered in this draft were introduced to support required extensions 
for CS policies, but at least some of those extensions (if specific section is 
not describing something else) is potentially applicable to other setup types. 
E.g. extensions from section 3.2 for blocking re-computation.

We can still drop that specific statement and explicitly describe for each 
extension whether it is generic or applicable to specific setup type only. 
Would that work for you?

Thanks,
Samuel

From: Samuel Sidor (ssidor)
Sent: Thursday, December 14, 2023 9:24 AM
To: xiong.q...@zte.com.cn<mailto:xiong.q...@zte.com.cn>; 
d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>
Cc: 
draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org<mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org>;
 pce@ietf.org<mailto:pce@ietf.org>
Subject: RE: [Pce] WG Adoption of 
draft-sidor-pce-circuit-style-pcep-extensions-05

Hi Quan,

Originally we explicitly listed

From: Pce mailto:pce-boun...@ietf.org>> On Behalf Of 
xiong.q...@zte.com.cn<mailto:xiong.q...@zte.com.cn>
Sent: Thursday, December 14, 2023 7:53 AM
To: d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>
Cc: 
draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org<mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org>;
 pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: [Pce] WG Adoption of 
draft-sidor-pce-circuit-style-pcep-extensions-05


Hi Dhruv,



I support the adoption of this draft. Thanks for the work from authors.

But I am confused about section 1 "PCEP extensions described in this document 
are applicable to all Path   Setup Types".

This draft mainly focus on the Circuit Style Policies and SR policy but path 
setup types include RSVP-TE,SR,PCECC,SRv6, Native IP TE path  and the newly 
adopted BIER-TE.

I suggest that it is better to provide clarification about other path setup 
types or remove this sentence.



Thanks,

Quan



<https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/Should
 this draft be adopted by the PCE <___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05

[Samuel Sidor (ssidor)]

Hi Quan,

What about modifying that statement from:

“PCEP extensions described in this document are applicable to all Path Setup 
Types.”

To something like:

“PCEP extensions described in this document are not restricted to any specific 
Path Setup Type.”
Or
“PCEP extensions described in this document can be used with any Path Setup 
Type.”

That way we will not really say that it is applicable to all, but at the same 
time we will not block anybody from using it if required with any other setup 
type in the future?

(I would still prefer not going into route of excluding/including specific 
setup types).

Thanks a lot,
Samuel

From: xiong.q...@zte.com.cn 
Sent: Friday, December 15, 2023 7:09 AM
To: Samuel Sidor (ssidor) 
Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org; 
d...@dhruvdhody.com; pce@ietf.org
Subject: Re: [Pce] WG Adoption of 
draft-sidor-pce-circuit-style-pcep-extensions-05


Hi Samuel,



Thanks for your detailed explanation!

I am not sure either about the PCECC and BIER-TE. To me that I may recall, for 
example( maybe not right), the path-recomputation TLV is in the request message 
from PCC to PCE, but there is no request message in PCECC mode. And for 
BIER-TE, it may has no requirement for path recomputation.

I agree that a lot of PCEP objects/TLVs which are defined generically. But It 
may be not appropriate to state that they are applicable to all Path Setup 
Types. The extensions can be used when it is required in any of path setup type.

It looks both good to me if you keep or drop the sentence. Thanks!



Best Regards,

Quan




Original
From: SamuelSidor(ssidor) mailto:ssi...@cisco.com>>
To: 熊泉00091065;
Cc: 
draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org<mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org>
 
mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org>>;d...@dhruvdhody.com
 mailto:d...@dhruvdhody.com>>;pce@ietf.org 
mailto:pce@ietf.org>>;
Date: 2023年12月14日 18:16
Subject: RE: [Pce] WG Adoption of 
draft-sidor-pce-circuit-style-pcep-extensions-05
Hi Guan,

By any chance, do you know about some specific reason why we would have to 
block for example path-recomputation TLV for BIER-TE or PCECC?

To me something like ability to block path re-computation on PCE for specific 
LSP is generic extension. Whether there is practical use for specific path 
setup type is different question, but we don’t need to block such extension 
because of that (we have a lot of PCEP objects/TLVs which are defined 
generically and just not usable for LSPs of specific setup type).

I personally consider having explicit list of supported path-setup types as 
less future proof (that’s why I modified based on comment from Dhruv to all 
setup types as I considered it as cleaner solution).

For Strict-path flag from section 3.1 – that is slightly more questionable, but 
in general we are again talking only about bringing up O flag from RP object 
from stateless messages (PCReq/PCRep) to stateful messages 
(PCRpt,PCUpd,PCinit). So something what was already supposed to be supported by 
all setup types.

So is there really something what needs to be explicitly blocked? I can rather 
imagine explicitly defining behavior for specific setup type (like BIER-TE or 
PCECC) for any of those extensions if we can see added value in using it, but 
behavior is not clear (that can be still done after adoption and discussion 
with PCE WG or authors of RFCs/drafts introducing those setup types).

Thanks,
Samuel

From: xiong.q...@zte.com.cn<mailto:xiong.q...@zte.com.cn> 
mailto:xiong.q...@zte.com.cn>>
Sent: Thursday, December 14, 2023 10:22 AM
To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>
Cc: 
draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org<mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org>;
 d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>; 
pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: [Pce] WG Adoption of 
draft-sidor-pce-circuit-style-pcep-extensions-05


Hi Samuel,



Thanks for your quick reply!

Yes, I agree with you. The extensions may be applicable for 
RSVP-TE,SR,SRv6,native IP, but I am not sure about it with BIER-TE and PCECC.

It works well for me to explicitly describe for each extension whether it is 
generic or applicable to specific setup type.

Thanks for your work!



Best Regards,

Quan






Original
From: SamuelSidor(ssidor) mailto:ssi...@cisco.com>>
To: 熊泉00091065;
Cc: 
draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org<mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org>
 
mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org>>;d...@dhruvdhody.com
 mailto:d...@dhruvdhody.com>>;pce@ietf.org 
mailto:pce@ietf.org>>;
Date: 2023年12月14日 16:27
Subject: RE: [Pce] WG Adoption of 
draft-sidor-pce-circuit-style-pcep-extensions-05
Hi Quan,

(sorry I sent it before finishing mail)

Originally we listed explicitly only RSVP-T

Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05

[Samuel Sidor (ssidor)]

Thanks Quan,

Updated version 06 (which includes suggestions from Ran and from you) was 
submitted.

Regards,
Samuel

From: xiong.q...@zte.com.cn 
Sent: Friday, December 15, 2023 10:57 AM
To: Samuel Sidor (ssidor) 
Cc: d...@dhruvdhody.com; 
draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org; pce@ietf.org
Subject: Re: [Pce] WG Adoption of 
draft-sidor-pce-circuit-style-pcep-extensions-05




Hi Samuel,



Thanks for your work!

Yes, I agree with you. It seems good to me with “PCEP extensions described in 
this document can be used with any Path Setup Type.” LOL.



Best Regards,

Quan


Original
From: SamuelSidor(ssidor) mailto:ssi...@cisco.com>>
To: 熊泉00091065;d...@dhruvdhody.com 
mailto:d...@dhruvdhody.com>>;
Cc: 
draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org<mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org>
 
mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org>>;pce@ietf.org
 mailto:pce@ietf.org>>;
Date: 2023年12月15日 17:25
Subject: RE: [Pce] WG Adoption of 
draft-sidor-pce-circuit-style-pcep-extensions-05
Hi Quan,

What about modifying that statement from:

“PCEP extensions described in this document are applicable to all Path Setup 
Types.”

To something like:

“PCEP extensions described in this document are not restricted to any specific 
Path Setup Type.”
Or
“PCEP extensions described in this document can be used with any Path Setup 
Type.”

That way we will not really say that it is applicable to all, but at the same 
time we will not block anybody from using it if required with any other setup 
type in the future?

(I would still prefer not going into route of excluding/including specific 
setup types).

Thanks a lot,
Samuel

From: xiong.q...@zte.com.cn<mailto:xiong.q...@zte.com.cn> 
mailto:xiong.q...@zte.com.cn>>
Sent: Friday, December 15, 2023 7:09 AM
To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>
Cc: 
draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org<mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org>;
 d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>; 
pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: [Pce] WG Adoption of 
draft-sidor-pce-circuit-style-pcep-extensions-05


Hi Samuel,



Thanks for your detailed explanation!

I am not sure either about the PCECC and BIER-TE. To me that I may recall, for 
example( maybe not right), the path-recomputation TLV is in the request message 
from PCC to PCE, but there is no request message in PCECC mode. And for 
BIER-TE, it may has no requirement for path recomputation.

I agree that a lot of PCEP objects/TLVs which are defined generically. But It 
may be not appropriate to state that they are applicable to all Path Setup 
Types. The extensions can be used when it is required in any of path setup type.

It looks both good to me if you keep or drop the sentence. Thanks!



Best Regards,

Quan




Original
From: SamuelSidor(ssidor) mailto:ssi...@cisco.com>>
To: 熊泉00091065;
Cc: 
draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org<mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org>
 
mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org>>;d...@dhruvdhody.com
 mailto:d...@dhruvdhody.com>>;pce@ietf.org 
mailto:pce@ietf.org>>;
Date: 2023年12月14日 18:16
Subject: RE: [Pce] WG Adoption of 
draft-sidor-pce-circuit-style-pcep-extensions-05
Hi Guan,

By any chance, do you know about some specific reason why we would have to 
block for example path-recomputation TLV for BIER-TE or PCECC?

To me something like ability to block path re-computation on PCE for specific 
LSP is generic extension. Whether there is practical use for specific path 
setup type is different question, but we don’t need to block such extension 
because of that (we have a lot of PCEP objects/TLVs which are defined 
generically and just not usable for LSPs of specific setup type).

I personally consider having explicit list of supported path-setup types as 
less future proof (that’s why I modified based on comment from Dhruv to all 
setup types as I considered it as cleaner solution).

For Strict-path flag from section 3.1 – that is slightly more questionable, but 
in general we are again talking only about bringing up O flag from RP object 
from stateless messages (PCReq/PCRep) to stateful messages 
(PCRpt,PCUpd,PCinit). So something what was already supposed to be supported by 
all setup types.

So is there really something what needs to be explicitly blocked? I can rather 
imagine explicitly defining behavior for specific setup type (like BIER-TE or 
PCECC) for any of those extensions if we can see added value in using it, but 
behavior is not clear (that can be still done after adoption and discussion 
with PCE WG or authors of RFCs/drafts introducing those setup types).

Thanks,
Samuel

From: xiong.q...@zte.com.cn<mailto:xiong.q...@zte.com.cn> 
mailto:xiong.q...@zte.com.cn>>
Sent: Thursday, December 14, 2023 

Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05

[Samuel Sidor (ssidor)]

Hi PCE-chairs,

I submitted version 00 (which is aligned with 
draft-sidor-pce-circuit-style-pcep-extensions-05) – it is waiting for chairs 
approval.

I’ll upload 01 version with handled comments (from version 06) after approving 
submission of 00 version.

(Sorry for delay – I’m on PTO, so my responses may be delayed).

Thanks a lot,
Samuel

From: Dhruv Dhody 
Sent: Wednesday, December 20, 2023 12:58 PM
To: pce@ietf.org
Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org
Subject: Re: WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05

Hi WG,

The adoption call is concluded and we have a new WG I-D. Thanks to those who 
provided feedback and comments.

Authors,

Please post a -00 version with no content change. Please handle comments 
received in -01.

Thanks!
Dhruv & Julien

On Fri, Dec 1, 2023 at 4:02 PM Dhruv Dhody 
mailto:d...@dhruvdhody.com>> wrote:
Hi WG,

This email begins the WG adoption poll for 
draft-sidor-pce-circuit-style-pcep-extensions-05.

https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/

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.

Please respond by Friday 15th Dec 2023.

Please be more vocal during WG polls!

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

Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05

[Samuel Sidor (ssidor)]

Just small update:

01 version is posted now (It is addressing comments received during adoption 
poll, which I originally posted in in 
draft-sidor-pce-circuit-style-pcep-extensions-06).

Thanks for all valuable comments and for supporting this draft.

Regards
Samuel

From: Samuel Sidor (ssidor) 
Sent: Saturday, December 23, 2023 12:05 PM
To: Dhruv Dhody ; pce-chairs 
Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org; pce@ietf.org
Subject: RE: WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05

Hi PCE-chairs,

I submitted version 00 (which is aligned with 
draft-sidor-pce-circuit-style-pcep-extensions-05) – it is waiting for chairs 
approval.

I’ll upload 01 version with handled comments (from version 06) after approving 
submission of 00 version.

(Sorry for delay – I’m on PTO, so my responses may be delayed).

Thanks a lot,
Samuel

From: Dhruv Dhody mailto:d...@dhruvdhody.com>>
Sent: Wednesday, December 20, 2023 12:58 PM
To: pce@ietf.org<mailto:pce@ietf.org>
Cc: 
draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org<mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org>
Subject: Re: WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05

Hi WG,

The adoption call is concluded and we have a new WG I-D. Thanks to those who 
provided feedback and comments.

Authors,

Please post a -00 version with no content change. Please handle comments 
received in -01.

Thanks!
Dhruv & Julien

On Fri, Dec 1, 2023 at 4:02 PM Dhruv Dhody 
mailto:d...@dhruvdhody.com>> wrote:
Hi WG,

This email begins the WG adoption poll for 
draft-sidor-pce-circuit-style-pcep-extensions-05.

https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/

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.

Please respond by Friday 15th Dec 2023.

Please be more vocal during WG polls!

Thanks!
Dhruv & Julien
--- Begin Message ---
Internet-Draft draft-ietf-pce-circuit-style-pcep-extensions-01.txt is now
available. It is a work item of the Path Computation Element (PCE) WG of the
IETF.

   Title:   PCEP extensions for Circuit Style Policies
   Authors: Samuel Sidor
Praveen Maheshwari
Andrew Stone
Luay Jalil
Shuping Peng
   Name:draft-ietf-pce-circuit-style-pcep-extensions-01.txt
   Pages:   12
   Dates:   2024-01-05

Abstract:

   This document proposes a set of extensions for Path Computation
   Element Communication Protocol (PCEP) for Circuit Style Policies -
   Segment-Routing Policy designed to satisfy requirements for
   connection-oriented transport services.  New TLV is introduced to
   control path recomputation and new flag to add ability to request
   path with strict hops only.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-circuit-style-pcep-extensions/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-pce-circuit-style-pcep-extensions-01.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-circuit-style-pcep-extensions-01

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
--- End Message ---
___
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

[Pce] Any missed comments for draft-ietf-pce-sid-algo

[Samuel Sidor (ssidor)]

Hi PCE WG,

I would like to ask for WG LC for draft-ietf-pce-sid-algo on behalf of authors. 
Are there any remaining issues/comments/questions which I (or co-authors) 
missed and which are not handled yet?

URL: https://datatracker.ietf.org/doc/draft-ietf-pce-sid-algo/

Thanks a lot,
Samuel
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo

[Samuel Sidor (ssidor)]

Thanks a lot Tom for your comment.

Please see inline .

Regards,
Samuel

-Original Message-
From: Pce  On Behalf Of tom petch
Sent: Wednesday, January 10, 2024 12:01 PM
To: Samuel Sidor (ssidor) ; pce@ietf.org
Subject: Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo

From: Pce  on behalf of Samuel Sidor (ssidor) 

Sent: 10 January 2024 10:18

Hi PCE WG,

I would like to ask for WG LC for draft-ietf-pce-sid-algo on behalf of authors. 
Are there any remaining issues/comments/questions which I (or co-authors) 
missed and which are not handled yet?

URL: https://datatracker.ietf.org/doc/draft-ietf-pce-sid-algo/


Well new to the PCE list may be I fear but I have a basic problem about 
'algorithm'.

You reference RFC8665 and RFC 8667.  In those it is always SR-Algorithm so I 
think that that should be the spelling here.

 I'm calling it "SR Algorithm" in that draft, so I assume that you 
are pointing to missing "-". Sure, I can modify it. Thanks for pointing it out.


More fundamentally,  8665 sets up an IANA registry with two values, 0 and 1, 
which tells me that 8665 is out of date as soon as it is published and that all 
references should be to IANA and not the RFC. 

 Sorry, maybe I missed your point, but do you mean that a lot of 
other RFCs, e.g.
https://datatracker.ietf.org/doc/html/rfc5440#section-9.2
https://datatracker.ietf.org/doc/html/rfc9552#section-7.1.1
which are also pointing to itself, when new IANA registry is created are 
incorrect? I interpret it only as specification of initial set of values, which 
are supposed to be created in new registry and not complete list of values in 
that registry, which will be created there in the future.


The update policy is Standards Action.  ADs regard additions to IANA registries 
as not updating the RFC creating the registry so reading 8665 will not tell you 
that it is out of date unless you read between the lines of the IANA 
Considerations and go see what is current.

It gets more problematic.  The IANA registry was updated by RFC9350 which keeps 
the same update criteria  but splits the range into two 0-127 and 128-255, the 
latter being flexible.

s.4.2.1 talks of Flexible Algorithm with a Normative reference to RFC9350 which 
begs the question as to the relationship between SR Algorithm and Flexible 
Algorithm when used in this document. Either/or, Synonyms?

 s.3.4 is describing F flag. If flag is set, valid values for 
SR-Algorithm field in PCEP are 128-255, so those allocated for specific subset 
of SR-Algorithm values called "Flexible Algorithms" and s.4.2.1 is applicable 
only for such cases. That section may then refer to specific subset of values 
("Flexible Algorithms") instead of referring to complete set. 


Here and  now it may all be obvious but in years to come with multiple 
algorithms in use it will likely be unclear what you are referencing in s.3.2, 
s.3.3, s.3.4; is it the range 0-127 or 0-255 or 128-255 or...?

 In all other sections, we are talking about complete set of values 
so "SR-Algorithm". I agree that it would be better that this document does not 
have any reference to "IGP Algorithm":
https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types
I can add it for example to s.1 after references to RFC8665 and RF8667. Do you 
have any other suggestion how to improve it? 


Tom Petch



Thanks a lot,
Samuel

___
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] Any missed comments for draft-ietf-pce-sid-algo

[Samuel Sidor (ssidor)]

Hi Tom,

Since you responded to both mails (from me and from Dhruv) together, I'll 
respond here.

Please see inline .

Regards,
Samuel

-Original Message-
From: tom petch  
Sent: Thursday, January 11, 2024 1:25 PM
To: Dhruv Dhody 
Cc: Samuel Sidor (ssidor) ; pce@ietf.org
Subject: Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo

inline 


From: Dhruv Dhody 
Sent: 10 January 2024 13:06

Hi Tom, WG,

Speaking as a WG member...

On Wed, Jan 10, 2024 at 4:30 PM tom petch 
mailto:ie...@btconnect.com>> wrote:
Sent: 10 January 2024 10:18

Hi PCE WG,

I would like to ask for WG LC for draft-ietf-pce-sid-algo on behalf of authors. 
Are there any remaining issues/comments/questions which I (or co-authors) 
missed and which are not handled yet?

URL: https://datatracker.ietf.org/doc/draft-ietf-pce-sid-algo/


Well new to the PCE list may be I fear but I have a basic problem about 
'algorithm'.

You reference RFC8665 and RFC 8667.  In those it is always SR-Algorithm so I 
think that that should be the spelling here.


Dhruv: The container is SR-ERO and SRv6-ERO where the field "Algorithm" is 
being added. To me it is clear it is an SR-Algorithm. You will find the similar 
usage in other RFC i.e.the TLV is called SR-Algorithm TLV but the field inside 
is just Algorithm.


You miss my point. in the two RFC it is always SR-Algorithm and never SR 
Algorithm.  The I-D has 53 or so uses of SR Algorithm. I think that they all 
need changing to SR-Algorithm.  This is not grammar; this is being consistent 
in terminology across the IETF.

 Ack, in my previous mail I confirmed that I can change it. I'm for 
consistency here as well (and especially since it does not cost us anything 
now). 

More fundamentally,  8665 sets up an IANA registry with two values, 0 and 1, 
which tells me that 8665 is out of date as soon as it is published and that all 
references should be  to IANA and not the RFC.  The update policy is Standards 
Action.  ADs regard additions to IANA registries as not updating the RFC 
creating the registry so reading 8665 will not tell you that it is out of date 
unless you read between the lines of the IANA Considerations and go see what is 
current.


Dhruv: It is usual for one to reference the RFC that created the registry, it 
is evident there will be future RFCs or documents that add more codepoints; the 
reference to the original RFC that created the registry is still valid. I don't 
recall anyone asking to explicitly reference the registry. That said, there is 
no harm in adding an additional reference to IANA.


Well I have been around long enough to see multiple IETF WG get into a tangle 
over IANA registries and then spend a lot of effort trying to clear the 
confusion.  When this I-D is specifying the values that must appear in a 
protocol field from an IANA registry, e.g. s.3.2, then the reference  must be 
to the IANA registry.  The RFC setting up the registry will likeleyo contain 
additional information about the values and their uses so the RFC should be 
referenced, sometimes even after the RFC is obsoleted, but not for the protocol 
field; that way brings trouble in the future from those who are not thorough 
enough to spot the use of a IANA registry and understand the implications 
therof.

 In my previous response, I confirmed that I should add explicit reference 
to registry itself. I originally added reference to RFC8665/RFC8667 as those 
are describing purpose and details of SR-Algorithm, but I agree that finally 
any value from IANA registry can be used in PCEP as well, so we need to 
reference registry itself as well. 

It gets more problematic.  The IANA registry was updated by RFC9350 which keeps 
the same update criteria  but splits the range into two 0-127 and 128-255, the 
latter being flexible.

s.4.2.1 talks of Flexible Algorithm with a Normative reference to RFC9350 which 
begs the question as to the relationship between SR Algorithm and Flexible 
Algorithm when used in this document. Either/or, Synonyms?

Here and  now it may all be obvious but in years to come with multiple 
algorithms in use it will likely be unclear what you are referencing in s.3.2, 
s.3.3, s.3.4; is it the range 0-127 or 0-255 or 128-255 or...?


Dhruv: It is 0-255! Authors can make that explicit in the I-D.

Well yes and no.  I think but am not sure that Flexible Algorithm is values 
128-255 and s.3.4 supports that view, at least  implicitly.  I think that 4.2.1 
should be explicit e.g.
'When the value of fthe  Algorithm is in the range 128-255, i.e. Flexible 
Algorithm, ...'

Tom Petch

 This document is by default talking about complete SR-Algorithm range. 
Only exception is s.4.2.1, which is specified to 128-255 and that is already 
clarified in s.3.4 (which is explicitly excluding 0-127 and explicitly pointing 
to s.4.2.1). I can still add explicit statement to the beginning of s.4.2.1 to

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] Any missed comments for draft-ietf-pce-sid-algo

[Samuel Sidor (ssidor)]

Thanks Tom,

I'll send updated draft in this mail thread soon. 

By the way - there is already big mess in naming of that algorithm across 
multiple RFCs (I really don't want to cause headache to you 😊 ):

IGP RFCs are talking about "SR-Algorithm" (as we already discussed in this 
thread), e.g.
https://datatracker.ietf.org/doc/html/rfc8665#name-sr-algorithm-tlv

SR policy architecture RFC is talking about "SR Algorithm":
https://datatracker.ietf.org/doc/html/rfc9256#name-segment-types

SR architecture RFC is talking calling it "Prefix SID Algorithm":
https://datatracker.ietf.org/doc/html/rfc8402#section-3.1.1

And IANA registry is calling it "IGP Algorithm":
https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types

...and they are all talking about same thing.

I'll follow naming from IGP as we are relying a lot on those RFCs and we are 
inheriting already defined Flex-algo behavior from those as well, but it is 
hard to be correct now. I'll add pointers to SR policy architecture and SR 
architecture RFCs as well. 

Regards,
Samuel

-Original Message-
From: tom petch  
Sent: Friday, January 12, 2024 11:10 AM
To: Samuel Sidor (ssidor) ; Dhruv Dhody 
Cc: pce@ietf.org
Subject: Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo

Samuel

Yes the comments at the end work for me

Tom Petch

____
From: Samuel Sidor (ssidor) 
Sent: 11 January 2024 12:50
To: tom petch; Dhruv Dhody
Cc: pce@ietf.org
Subject: RE: [Pce] Any missed comments for draft-ietf-pce-sid-algo

Hi Tom,

Since you responded to both mails (from me and from Dhruv) together, I'll 
respond here.

Please see inline .

Regards,
Samuel

-Original Message-
From: tom petch 
Sent: Thursday, January 11, 2024 1:25 PM
To: Dhruv Dhody 
Cc: Samuel Sidor (ssidor) ; pce@ietf.org
Subject: Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo

inline 


From: Dhruv Dhody 
Sent: 10 January 2024 13:06

Hi Tom, WG,

Speaking as a WG member...

On Wed, Jan 10, 2024 at 4:30 PM tom petch 
mailto:ie...@btconnect.com>> wrote:
Sent: 10 January 2024 10:18

Hi PCE WG,

I would like to ask for WG LC for draft-ietf-pce-sid-algo on behalf of authors. 
Are there any remaining issues/comments/questions which I (or co-authors) 
missed and which are not handled yet?

URL: https://datatracker.ietf.org/doc/draft-ietf-pce-sid-algo/


Well new to the PCE list may be I fear but I have a basic problem about 
'algorithm'.

You reference RFC8665 and RFC 8667.  In those it is always SR-Algorithm so I 
think that that should be the spelling here.


Dhruv: The container is SR-ERO and SRv6-ERO where the field "Algorithm" is 
being added. To me it is clear it is an SR-Algorithm. You will find the similar 
usage in other RFC i.e.the TLV is called SR-Algorithm TLV but the field inside 
is just Algorithm.


You miss my point. in the two RFC it is always SR-Algorithm and never SR 
Algorithm.  The I-D has 53 or so uses of SR Algorithm. I think that they all 
need changing to SR-Algorithm.  This is not grammar; this is being consistent 
in terminology across the IETF.

 Ack, in my previous mail I confirmed that I can change it. I'm for 
consistency here as well (and especially since it does not cost us anything 
now).

More fundamentally,  8665 sets up an IANA registry with two values, 0 and 1, 
which tells me that 8665 is out of date as soon as it is published and that all 
references should be  to IANA and not the RFC.  The update policy is Standards 
Action.  ADs regard additions to IANA registries as not updating the RFC 
creating the registry so reading 8665 will not tell you that it is out of date 
unless you read between the lines of the IANA Considerations and go see what is 
current.


Dhruv: It is usual for one to reference the RFC that created the registry, it 
is evident there will be future RFCs or documents that add more codepoints; the 
reference to the original RFC that created the registry is still valid. I don't 
recall anyone asking to explicitly reference the registry. That said, there is 
no harm in adding an additional reference to IANA.


Well I have been around long enough to see multiple IETF WG get into a tangle 
over IANA registries and then spend a lot of effort trying to clear the 
confusion.  When this I-D is specifying the values that must appear in a 
protocol field from an IANA registry, e.g. s.3.2, then the reference  must be 
to the IANA registry.  The RFC setting up the registry will likeleyo contain 
additional information about the values and their uses so the RFC should be 
referenced, sometimes even after the RFC is obsoleted, but not for the protocol 
field; that way brings trouble in the future from those who are not thorough 
enough to spot the use of a IANA registry and understand the implications 
therof.

 In my previo

Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo

[Samuel Sidor (ssidor)]

Just small update - 07 version submitted now.

Regards,
Samuel

-Original Message-
From: Pce  On Behalf Of Samuel Sidor (ssidor)
Sent: Friday, January 12, 2024 1:43 PM
To: tom petch ; Dhruv Dhody 
Cc: pce@ietf.org
Subject: Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo

Hi Tom,

Attached updated document + diff. I'll submit it tomorrow in case of no further 
comments.

Regards,
Samuel

-Original Message-
From: tom petch  
Sent: Friday, January 12, 2024 12:33 PM
To: Samuel Sidor (ssidor) ; Dhruv Dhody 
Cc: pce@ietf.org
Subject: Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo

From: Samuel Sidor (ssidor) 
Sent: 12 January 2024 10:53

Thanks Tom,

I'll send updated draft in this mail thread soon.

By the way - there is already big mess in naming of that algorithm across 
multiple RFCs (I really don't want to cause headache to you 😊 ):


I know!  That is why I was keen to get it right in PCE.  Some WG are less 
responsive than others to outside comments so I leave them to get into whatever 
knots they want to:-(  I see LSR as the owner of the algorithm work, as least 
initially, so think that they should be followed.  That said, I think that 
RFC9350 culd have done more but that is water under the bridge.  Sometimes you 
have to say something along the lines of 'xxx whcih is referred to as zxyx in 
the Normative reference'

Tom Petch


IGP RFCs are talking about "SR-Algorithm" (as we already discussed in this 
thread), e.g.
https://datatracker.ietf.org/doc/html/rfc8665#name-sr-algorithm-tlv

SR policy architecture RFC is talking about "SR Algorithm":
https://datatracker.ietf.org/doc/html/rfc9256#name-segment-types

SR architecture RFC is talking calling it "Prefix SID Algorithm":
https://datatracker.ietf.org/doc/html/rfc8402#section-3.1.1

And IANA registry is calling it "IGP Algorithm":
https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types

...and they are all talking about same thing.

I'll follow naming from IGP as we are relying a lot on those RFCs and we are 
inheriting already defined Flex-algo behavior from those as well, but it is 
hard to be correct now. I'll add pointers to SR policy architecture and SR 
architecture RFCs as well.

Regards,
Samuel

-Original Message-
From: tom petch 
Sent: Friday, January 12, 2024 11:10 AM
To: Samuel Sidor (ssidor) ; Dhruv Dhody 
Cc: pce@ietf.org
Subject: Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo

Samuel

Yes the comments at the end work for me

Tom Petch


From: Samuel Sidor (ssidor) 
Sent: 11 January 2024 12:50
To: tom petch; Dhruv Dhody
Cc: pce@ietf.org
Subject: RE: [Pce] Any missed comments for draft-ietf-pce-sid-algo

Hi Tom,

Since you responded to both mails (from me and from Dhruv) together, I'll 
respond here.

Please see inline .

Regards,
Samuel

-Original Message-
From: tom petch 
Sent: Thursday, January 11, 2024 1:25 PM
To: Dhruv Dhody 
Cc: Samuel Sidor (ssidor) ; pce@ietf.org
Subject: Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo

inline 


From: Dhruv Dhody 
Sent: 10 January 2024 13:06

Hi Tom, WG,

Speaking as a WG member...

On Wed, Jan 10, 2024 at 4:30 PM tom petch 
mailto:ie...@btconnect.com>> wrote:
Sent: 10 January 2024 10:18

Hi PCE WG,

I would like to ask for WG LC for draft-ietf-pce-sid-algo on behalf of authors. 
Are there any remaining issues/comments/questions which I (or co-authors) 
missed and which are not handled yet?

URL: https://datatracker.ietf.org/doc/draft-ietf-pce-sid-algo/


Well new to the PCE list may be I fear but I have a basic problem about 
'algorithm'.

You reference RFC8665 and RFC 8667.  In those it is always SR-Algorithm so I 
think that that should be the spelling here.


Dhruv: The container is SR-ERO and SRv6-ERO where the field "Algorithm" is 
being added. To me it is clear it is an SR-Algorithm. You will find the similar 
usage in other RFC i.e.the TLV is called SR-Algorithm TLV but the field inside 
is just Algorithm.


You miss my point. in the two RFC it is always SR-Algorithm and never SR 
Algorithm.  The I-D has 53 or so uses of SR Algorithm. I think that they all 
need changing to SR-Algorithm.  This is not grammar; this is being consistent 
in terminology across the IETF.

 Ack, in my previous mail I confirmed that I can change it. I'm for 
consistency here as well (and especially since it does not cost us anything 
now).

More fundamentally,  8665 sets up an IANA registry with two values, 0 and 1, 
which tells me that 8665 is out of date as soon as it is published and that all 
references should be  to IANA and not the RFC.  The update policy is Standards 
Action.  ADs regard additions to IANA registries as not updating the RFC 
creating the registry so reading 8665 will not tell you that it is out of

Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo

[Samuel Sidor (ssidor)]

Hi PCE-chairs,

Since we haven't received any other comments for this draft, I would like to 
ask for WGLC for this draft:
https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-07.html

Thanks a lot,
Samuel

-Original Message-
From: Samuel Sidor (ssidor)  
Sent: Monday, January 15, 2024 1:11 PM
To: Samuel Sidor (ssidor) ; tom petch ; 
Dhruv Dhody 
Cc: pce@ietf.org
Subject: RE: [Pce] Any missed comments for draft-ietf-pce-sid-algo

Just small update - 07 version submitted now.

Regards,
Samuel

-Original Message-
From: Pce  On Behalf Of Samuel Sidor (ssidor)
Sent: Friday, January 12, 2024 1:43 PM
To: tom petch ; Dhruv Dhody 
Cc: pce@ietf.org
Subject: Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo

Hi Tom,

Attached updated document + diff. I'll submit it tomorrow in case of no further 
comments.

Regards,
Samuel

-Original Message-
From: tom petch  
Sent: Friday, January 12, 2024 12:33 PM
To: Samuel Sidor (ssidor) ; Dhruv Dhody 
Cc: pce@ietf.org
Subject: Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo

From: Samuel Sidor (ssidor) 
Sent: 12 January 2024 10:53

Thanks Tom,

I'll send updated draft in this mail thread soon.

By the way - there is already big mess in naming of that algorithm across 
multiple RFCs (I really don't want to cause headache to you 😊 ):


I know!  That is why I was keen to get it right in PCE.  Some WG are less 
responsive than others to outside comments so I leave them to get into whatever 
knots they want to:-(  I see LSR as the owner of the algorithm work, as least 
initially, so think that they should be followed.  That said, I think that 
RFC9350 culd have done more but that is water under the bridge.  Sometimes you 
have to say something along the lines of 'xxx whcih is referred to as zxyx in 
the Normative reference'

Tom Petch


IGP RFCs are talking about "SR-Algorithm" (as we already discussed in this 
thread), e.g.
https://datatracker.ietf.org/doc/html/rfc8665#name-sr-algorithm-tlv

SR policy architecture RFC is talking about "SR Algorithm":
https://datatracker.ietf.org/doc/html/rfc9256#name-segment-types

SR architecture RFC is talking calling it "Prefix SID Algorithm":
https://datatracker.ietf.org/doc/html/rfc8402#section-3.1.1

And IANA registry is calling it "IGP Algorithm":
https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types

...and they are all talking about same thing.

I'll follow naming from IGP as we are relying a lot on those RFCs and we are 
inheriting already defined Flex-algo behavior from those as well, but it is 
hard to be correct now. I'll add pointers to SR policy architecture and SR 
architecture RFCs as well.

Regards,
Samuel

-Original Message-
From: tom petch 
Sent: Friday, January 12, 2024 11:10 AM
To: Samuel Sidor (ssidor) ; Dhruv Dhody 
Cc: pce@ietf.org
Subject: Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo

Samuel

Yes the comments at the end work for me

Tom Petch


From: Samuel Sidor (ssidor) 
Sent: 11 January 2024 12:50
To: tom petch; Dhruv Dhody
Cc: pce@ietf.org
Subject: RE: [Pce] Any missed comments for draft-ietf-pce-sid-algo

Hi Tom,

Since you responded to both mails (from me and from Dhruv) together, I'll 
respond here.

Please see inline .

Regards,
Samuel

-Original Message-
From: tom petch 
Sent: Thursday, January 11, 2024 1:25 PM
To: Dhruv Dhody 
Cc: Samuel Sidor (ssidor) ; pce@ietf.org
Subject: Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo

inline 


From: Dhruv Dhody 
Sent: 10 January 2024 13:06

Hi Tom, WG,

Speaking as a WG member...

On Wed, Jan 10, 2024 at 4:30 PM tom petch 
mailto:ie...@btconnect.com>> wrote:
Sent: 10 January 2024 10:18

Hi PCE WG,

I would like to ask for WG LC for draft-ietf-pce-sid-algo on behalf of authors. 
Are there any remaining issues/comments/questions which I (or co-authors) 
missed and which are not handled yet?

URL: https://datatracker.ietf.org/doc/draft-ietf-pce-sid-algo/


Well new to the PCE list may be I fear but I have a basic problem about 
'algorithm'.

You reference RFC8665 and RFC 8667.  In those it is always SR-Algorithm so I 
think that that should be the spelling here.


Dhruv: The container is SR-ERO and SRv6-ERO where the field "Algorithm" is 
being added. To me it is clear it is an SR-Algorithm. You will find the similar 
usage in other RFC i.e.the TLV is called SR-Algorithm TLV but the field inside 
is just Algorithm.


You miss my point. in the two RFC it is always SR-Algorithm and never SR 
Algorithm.  The I-D has 53 or so uses of SR Algorithm. I think that they all 
need changing to SR-Algorithm.  This is not grammar; this is being consistent 
in terminology across the IETF.

 Ack, in my previous mail I confirmed that I can change it. I'm for 
consistency here a

Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo

[Samuel Sidor (ssidor)]

Hi Dhruv,

Thanks for reminding me Security consideration section, I was tracking it 
together with Manageability considerations and I missed it somehow (and it 
seems that WG was not missing it as well). I’ll try to submit new version with 
that change included by beginning of next week.

Regards,
Samuel

From: Dhruv Dhody 
Sent: Friday, January 26, 2024 2:46 PM
To: Samuel Sidor (ssidor) 
Cc: pce-chairs ; pce@ietf.org
Subject: Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo

Hi Samuel,

Noted!

One comment from my side -- PLease add some analysis in the security 
consideration, an empty security consideration is bound to raise eyebrows!

Thanks!
Dhruv

On Fri, Jan 26, 2024 at 7:01 PM Samuel Sidor (ssidor) 
mailto:ssi...@cisco.com>> wrote:
Hi PCE-chairs,

Since we haven't received any other comments for this draft, I would like to 
ask for WGLC for this draft:
https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-07.html

Thanks a lot,
Samuel

-Original Message-
From: Samuel Sidor (ssidor) 
mailto:40cisco@dmarc.ietf.org>>
Sent: Monday, January 15, 2024 1:11 PM
To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>; tom 
petch mailto:ie...@btconnect.com>>; Dhruv Dhody 
mailto:dhruv.i...@gmail.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>
Subject: RE: [Pce] Any missed comments for draft-ietf-pce-sid-algo

Just small update - 07 version submitted now.

Regards,
Samuel

-Original Message-
From: Pce mailto:pce-boun...@ietf.org>> On Behalf Of 
Samuel Sidor (ssidor)
Sent: Friday, January 12, 2024 1:43 PM
To: tom petch mailto:ie...@btconnect.com>>; Dhruv Dhody 
mailto:dhruv.i...@gmail.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo

Hi Tom,

Attached updated document + diff. I'll submit it tomorrow in case of no further 
comments.

Regards,
Samuel

-Original Message-
From: tom petch mailto:ie...@btconnect.com>>
Sent: Friday, January 12, 2024 12:33 PM
To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>; Dhruv 
Dhody mailto:dhruv.i...@gmail.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo

From: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>
Sent: 12 January 2024 10:53

Thanks Tom,

I'll send updated draft in this mail thread soon.

By the way - there is already big mess in naming of that algorithm across 
multiple RFCs (I really don't want to cause headache to you 😊 ):


I know!  That is why I was keen to get it right in PCE.  Some WG are less 
responsive than others to outside comments so I leave them to get into whatever 
knots they want to:-(  I see LSR as the owner of the algorithm work, as least 
initially, so think that they should be followed.  That said, I think that 
RFC9350 culd have done more but that is water under the bridge.  Sometimes you 
have to say something along the lines of 'xxx whcih is referred to as zxyx in 
the Normative reference'

Tom Petch


IGP RFCs are talking about "SR-Algorithm" (as we already discussed in this 
thread), e.g.
https://datatracker.ietf.org/doc/html/rfc8665#name-sr-algorithm-tlv

SR policy architecture RFC is talking about "SR Algorithm":
https://datatracker.ietf.org/doc/html/rfc9256#name-segment-types

SR architecture RFC is talking calling it "Prefix SID Algorithm":
https://datatracker.ietf.org/doc/html/rfc8402#section-3.1.1

And IANA registry is calling it "IGP Algorithm":
https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types

...and they are all talking about same thing.

I'll follow naming from IGP as we are relying a lot on those RFCs and we are 
inheriting already defined Flex-algo behavior from those as well, but it is 
hard to be correct now. I'll add pointers to SR policy architecture and SR 
architecture RFCs as well.

Regards,
Samuel

-Original Message-
From: tom petch mailto:ie...@btconnect.com>>
Sent: Friday, January 12, 2024 11:10 AM
To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>; Dhruv 
Dhody mailto:dhruv.i...@gmail.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo

Samuel

Yes the comments at the end work for me

Tom Petch


From: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>
Sent: 11 January 2024 12:50
To: tom petch; Dhruv Dhody
Cc: pce@ietf.org<mailto:pce@ietf.org>
Subject: RE: [Pce] Any missed comments for draft-ietf-pce-sid-algo

Hi Tom,

Since you responded to both mails (from me and from Dhruv) together, I'll 
respond here.

Please see inline .

Regards,
Samuel

-Original Message-
From: tom petch mailto:ie...@btconnect.com>>
Sent: Thursday, January 11, 2024 1:25 PM
To: Dhruv Dhody mailto:dhruv.i...@gmail.com>>

Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo

[Samuel Sidor (ssidor)]

Hi Dhruv,

Just FYI: Security and manageability considerations sections added in latest 
(v08) version of the draft.

Thanks,
Samuel

From: Pce  On Behalf Of Samuel Sidor (ssidor)
Sent: Friday, January 26, 2024 2:59 PM
To: Dhruv Dhody 
Cc: pce-chairs ; pce@ietf.org
Subject: Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo

Hi Dhruv,

Thanks for reminding me Security consideration section, I was tracking it 
together with Manageability considerations and I missed it somehow (and it 
seems that WG was not missing it as well). I’ll try to submit new version with 
that change included by beginning of next week.

Regards,
Samuel

From: Dhruv Dhody mailto:d...@dhruvdhody.com>>
Sent: Friday, January 26, 2024 2:46 PM
To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>
Cc: pce-chairs mailto:pce-cha...@ietf.org>>; 
pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo

Hi Samuel,

Noted!

One comment from my side -- PLease add some analysis in the security 
consideration, an empty security consideration is bound to raise eyebrows!

Thanks!
Dhruv

On Fri, Jan 26, 2024 at 7:01 PM Samuel Sidor (ssidor) 
mailto:ssi...@cisco.com>> wrote:
Hi PCE-chairs,

Since we haven't received any other comments for this draft, I would like to 
ask for WGLC for this draft:
https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-07.html

Thanks a lot,
Samuel

-Original Message-
From: Samuel Sidor (ssidor) 
mailto:40cisco@dmarc.ietf.org>>
Sent: Monday, January 15, 2024 1:11 PM
To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>; tom 
petch mailto:ie...@btconnect.com>>; Dhruv Dhody 
mailto:dhruv.i...@gmail.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>
Subject: RE: [Pce] Any missed comments for draft-ietf-pce-sid-algo

Just small update - 07 version submitted now.

Regards,
Samuel

-Original Message-----
From: Pce mailto:pce-boun...@ietf.org>> On Behalf Of 
Samuel Sidor (ssidor)
Sent: Friday, January 12, 2024 1:43 PM
To: tom petch mailto:ie...@btconnect.com>>; Dhruv Dhody 
mailto:dhruv.i...@gmail.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo

Hi Tom,

Attached updated document + diff. I'll submit it tomorrow in case of no further 
comments.

Regards,
Samuel

-Original Message-
From: tom petch mailto:ie...@btconnect.com>>
Sent: Friday, January 12, 2024 12:33 PM
To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>; Dhruv 
Dhody mailto:dhruv.i...@gmail.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo

From: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>
Sent: 12 January 2024 10:53

Thanks Tom,

I'll send updated draft in this mail thread soon.

By the way - there is already big mess in naming of that algorithm across 
multiple RFCs (I really don't want to cause headache to you 😊 ):


I know!  That is why I was keen to get it right in PCE.  Some WG are less 
responsive than others to outside comments so I leave them to get into whatever 
knots they want to:-(  I see LSR as the owner of the algorithm work, as least 
initially, so think that they should be followed.  That said, I think that 
RFC9350 culd have done more but that is water under the bridge.  Sometimes you 
have to say something along the lines of 'xxx whcih is referred to as zxyx in 
the Normative reference'

Tom Petch


IGP RFCs are talking about "SR-Algorithm" (as we already discussed in this 
thread), e.g.
https://datatracker.ietf.org/doc/html/rfc8665#name-sr-algorithm-tlv

SR policy architecture RFC is talking about "SR Algorithm":
https://datatracker.ietf.org/doc/html/rfc9256#name-segment-types

SR architecture RFC is talking calling it "Prefix SID Algorithm":
https://datatracker.ietf.org/doc/html/rfc8402#section-3.1.1

And IANA registry is calling it "IGP Algorithm":
https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types

...and they are all talking about same thing.

I'll follow naming from IGP as we are relying a lot on those RFCs and we are 
inheriting already defined Flex-algo behavior from those as well, but it is 
hard to be correct now. I'll add pointers to SR policy architecture and SR 
architecture RFCs as well.

Regards,
Samuel

-Original Message-
From: tom petch mailto:ie...@btconnect.com>>
Sent: Friday, January 12, 2024 11:10 AM
To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>; Dhruv 
Dhody mailto:dhruv.i...@gmail.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo

Samuel

Yes the comments at the end work for me

Tom Petch


From: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>
Sent: 11 January 20

Re: [Pce] I-D Action: draft-ietf-pce-circuit-style-pcep-extensions-02.txt

[Samuel Sidor (ssidor)]

Hi PCE WG members,

FYI - List of changes done in this version:
- Introduced capabilities to negotiate support for features introduced in this 
draft
- Added more restrictions for processing of PATH-RECOMPUTATION TLV 
- Added section for new IANA registry for flags in PATH-RECOMPUTATION TLV
- Some small cleanup in wording

Please let me know in case of any comments.

Thanks,
Samuel

-Original Message-
From: Pce  On Behalf Of internet-dra...@ietf.org
Sent: Monday, February 5, 2024 10:40 AM
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-circuit-style-pcep-extensions-02.txt

Internet-Draft draft-ietf-pce-circuit-style-pcep-extensions-02.txt is now 
available. It is a work item of the Path Computation Element (PCE) WG of the 
IETF.

   Title:   PCEP extensions for Circuit Style Policies
   Authors: Samuel Sidor
Praveen Maheshwari
Andrew Stone
Luay Jalil
Shuping Peng
   Name:draft-ietf-pce-circuit-style-pcep-extensions-02.txt
   Pages:   13
   Dates:   2024-02-05

Abstract:

   This document proposes a set of extensions for Path Computation
   Element Communication Protocol (PCEP) for Circuit Style Policies -
   Segment-Routing Policy designed to satisfy requirements for
   connection-oriented transport services.  New TLV is introduced to
   control path recomputation and new flag to add ability to request
   path with strict hops only.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-circuit-style-pcep-extensions/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-pce-circuit-style-pcep-extensions-02.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-circuit-style-pcep-extensions-02

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
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] WG Adoption of draft-peng-pce-entropy-label-position-10

[Samuel Sidor (ssidor)]

Hi Quan and PCE WG,

I support adoption of this draft with a few minor/not blocking comments (I 
reviewed v11 as a lot of comments were addressed, so to avoid commenting same 
thing again even if v10 is being adoption).

Abstract:
“…Label Indicator (ELI)/EL pairs SHOULD be inserted in the SR-MPLS label stack 
as per RFC8662…”.

Is it good to start using requirements in draft abstract like this (I consider 
it a bit non-standard looking into abstracts used in other RFCs)? I would use 
more generic wording to just say that RFC8662 is already explaining how Els how 
are supposed to be used in SR-MPLS label stack. Requirements language 
(including “SHOULD” is really defined in Section 2.2 only).

Introduction:
“[RFC5440]
 describes the Path Computation Element Computation Protocol (PCEP) which is …“

Do you need to expand “PCEP” acronym again even if you expanded it already in 
draft title and abstract? Same potentially applies to EL/ELI/ELP

“In some cases, the the controller(e.g. PCE)”

Double “the” and maybe add space after “controller”.

Terminology
You are just pointing to terminology in other RFCs, but in the same time you 
are introducing a lot of new acronyms and expanding them directly in the text. 
For example in section 3:
“The Entropy Readable Label Depth (ERLD) is defined as the number of labels 
which m…”
“… MSD (e.g. Base MPLS Imposition MSD (BMI-MSD) or ERLD-MSD) through Interior 
Gateway Protocol (IGP) and…”
Why not use this section to explain them?

Section 3:
“The PCEs could get the information of all nodes such as … through Interior 
Gateway Protocol (IGP)”
Isn’t it better to refer to BGP-LS as well? At least my understanding is that 
usage of BGP-LS as a source for topology for PCE is more standard than directly 
learning topology from IGP (but maybe that is me).

Section 4.1:
“…multiple ELI/EL pairs and and supports the results of SR path with ELP from 
PCE”

Double “and”. I also assume that PCC really “supports the results of SR 
path-computation”  or it “supports SR path with ELP received from PCE”.

Section 4.2:
“A PCE would also set this bit to 1 to indicate that the ELP information is 
included by PCE and encoded in the Path Computation Reply (PCRep) message as 
per 
[RFC5440].
 And in a stateful PCE model, it also can be carried in Path Computation Update 
Request (PCUpd) message as per 
[RFC8231]
 or LSP Initiate Request (PCInitiate) message as per 
[RFC8281].”

It seems that for stateless it is “MUST” requirement and for stateful, it is 
“CAN” requirement. Isn’t it better to explicitly indicate for both whether PCE 
MUST do it or it is just optional and PCE may decide to do not set that flag at 
all?

Section 4.3:
“E (ELP Configuration) : If this flag is set, the PCC SHOULD insert  
into the position after this SR-ERO subobject, otherwise it SHOULD not insert 
 after this segment.”

You are indicating what PCC should do if flag is set (so I assume that PCE 
should set it, but it may be better to be explicit and say if “If this flag is 
set by PCE,…”). I can see that you are explaining briefly in next section, but 
it is still better to be clear. Maybe explain also whether PCC can set it by 
itself (e.g. if it wants to report state of existing LSP).

Section 5:
“And the SR path can also be initiated by PCE with PCInitiate or PCUpd message 
in stateful PCE mode.”

It seems a bit misleading to say that SR path can be initiated by PCUpd.

“The SR path being received by PCC with SR-ERO segment list…”

Maybe “…received by PCC encoded in SR-ERO…” (without segment-list as you are 
already talking about SR path)

You defined 3 new flags, but what I’m missing a bit is any details about 
interaction between those flags. E.g. what will happen if capability was not 
advertised by E flag in LSP object is set? Is that allowed? Is it valid to 
include E flag in SR-ERO if it was not requested by PCC? If any of those will 
happen, should we have some PCError to reject them?

Is E flag from SR-ERO applicable to any SID type or are there cases, when it is 
not valid to include it (e.g. L2 Adj SID?) Should PCC just ignore that flag in 
such case?

Is E flag from SR-ERO applicable to RRO as well?

(I’m not pushing you to solve everything before adoption, just throwing ideas 
for improving 😊 )

Section 7:
You should explicitly mention registry name from which you want to allocate

Consider if you need to add “Manageability Considerations” Section.

Thanks,
Samuel

From: Pce  On Behalf Of Dhruv Dhody
Sent: Friday, January 26, 2024 5:49 PM
To: pce@ietf.org
Cc: pce-chairs ; 
draft-peng-pce-entropy-label-posit...@ietf.org
Subject: [Pce] WG Adoption of draft-peng-pce

Re: [Pce] WG Adoption of draft-peng-pce-entropy-label-position-10

[Samuel Sidor (ssidor)]

Thanks Quan,

Ack, I’m fine with your proposals + see inline  (I skipped most of them as 
you already responded and there was not much to discuss 😊 ).

Regards,
Samuel

From: xiong.q...@zte.com.cn 
Sent: Sunday, February 18, 2024 3:23 AM
To: Samuel Sidor (ssidor) 
Cc: pce-cha...@ietf.org; d...@dhruvdhody.com; 
draft-peng-pce-entropy-label-posit...@ietf.org; pce@ietf.org
Subject: Re: [Pce] WG Adoption of draft-peng-pce-entropy-label-position-10




Hi Samuel,



Thanks for your detailed review and comments! Sorry for the delay due to the 
holiday.LoL. Happy Chinese New Year!



Please see inline with [Quan].



Abstract:

“…Label Indicator (ELI)/EL pairs SHOULD be inserted in the SR-MPLS label stack 
as per RFC8662…”.



Is it good to start using requirements in draft abstract like this (I consider 
it a bit non-standard looking into abstracts used in other RFCs)? I would use 
more generic wording to just say that RFC8662 is already explaining how Els how 
are supposed to be used in SR-MPLS label stack. Requirements language 
(including “SHOULD” is really defined in Section 2.2 only).



[Quan]: Thanks for your remind. I checked the RFC8662 section 7.1, it mentioned 
"In order for the EL to occur within the ERLD of LSRs along the path 
corresponding to a SPRING label stack, multiple  pairs MAY be inserted 
in this label stack."  Would it be better to change it to "multiple Entropy 
Label Indicator (ELI)/EL pairs may be inserted in the SR-MPLS label stack. 
stack as per RFC8662." without using Requirements language?



 Sure, that should work.

Introduction:

“[RFC5440<https://www.ietf.org/archive/id/draft-peng-pce-entropy-label-position-11.html#RFC5440>]
 describes the Path Computation Element Computation Protocol (PCEP) which is …“



Do you need to expand “PCEP” acronym again even if you expanded it already in 
draft title and abstract? Same potentially applies to EL/ELI/ELP

[Quan]: I think this is required when processing RFC. (And I also checked the 
existing RFC.)



“In some cases, the the controller(e.g. PCE)”

Double “the” and maybe add space after “controller”.

[Quan]:Thanks, I will fix it in next version.



Section 4.2:

“A PCE would also set this bit to 1 to indicate that the ELP information is 
included by PCE and encoded in the Path Computation Reply (PCRep) message as 
per 
[RFC5440<https://www.ietf.org/archive/id/draft-peng-pce-entropy-label-position-11.html#RFC5440>].
 And in a stateful PCE model, it also can be carried in Path Computation Update 
Request (PCUpd) message as per 
[RFC8231<https://www.ietf.org/archive/id/draft-peng-pce-entropy-label-position-11.html#RFC8231>]
 or LSP Initiate Request (PCInitiate) message as per 
[RFC8281<https://www.ietf.org/archive/id/draft-peng-pce-entropy-label-position-11.html#RFC8281>].”



It seems that for stateless it is “MUST” requirement and for stateful, it is 
“CAN” requirement. Isn’t it better to explicitly indicate for both whether PCE 
MUST do it or it is just optional and PCE may decide to do not set that flag at 
all?

 [Quan]: Thanks for your comment. Would it be better to add that " The PCE 
SHOULD set this bit to 1 ... And in a stateful PCE model, it also CAN be 
carried in  "

 Is it just “SHOULD” requirement for stateful and not MUST same way like it 
is done for stateless?

Section 4.3:

“E (ELP Configuration) : If this flag is set, the PCC SHOULD insert  
into the position after this SR-ERO subobject, otherwise it SHOULD not insert 
 after this segment.”



You are indicating what PCC should do if flag is set (so I assume that PCE 
should set it, but it may be better to be explicit and say if “If this flag is 
set by PCE,…”). I can see that you are explaining briefly in next section, but 
it is still better to be clear. Maybe explain also whether PCC can set it by 
itself (e.g. if it wants to report state of existing LSP).

 [Quan]: Thanks for your comment. I think the ELP can only be computed by PCE, 
so the flag can only  be set by PCE.

 Ack, I was just pointing out that it may be better to add some explicit 
statement to clarify that.

Section 5:

“And the SR path can also be initiated by PCE with PCInitiate or PCUpd message 
in stateful PCE mode.”

It seems a bit misleading to say that SR path can be initiated by PCUpd.

“The SR path being received by PCC with SR-ERO segment list…”

Maybe “…received by PCC encoded in SR-ERO…” (without segment-list as you are 
already talking about SR path)

 [Quan]:Thanks, I will fix it in next version.



You defined 3 new flags, but what I’m missing a bit is any details about 
interaction between those flags. E.g. what will happen if capability was not 
advertised by E flag in LSP object is set? Is that allowed? Is it valid to 
include E flag in SR-ERO if it was not requested by PCC? If any of those will 
happen, should we have some PCError to reject them?

Is E flag from SR-ERO applicable to any SID type or are there cases, when it

Re: [Pce] WG Adoption of draft-peng-pce-entropy-label-position-10

[Samuel Sidor (ssidor)]

Thanks Quan,

Makes sense now, then please use version, which you proposed in your previous 
mail.

Regards,
Samuel

From: xiong.q...@zte.com.cn 
Sent: Tuesday, February 20, 2024 1:02 PM
To: Samuel Sidor (ssidor) 
Cc: pce-cha...@ietf.org; d...@dhruvdhody.com; 
draft-peng-pce-entropy-label-posit...@ietf.org; pce@ietf.org
Subject: Re: [Pce] WG Adoption of draft-peng-pce-entropy-label-position-10


Hi Samuel,



Thanks for your reply!

I am glad that most of your comments are addressed.

The reason why I use the "SHOULD" is that "MUST" may be too strong which 
mentioned by Andrew's comment.

I think it may be better to add PCErr message associated with "MUST" in case 
the PCE can not set it.

So I use the "SHOULD" and could change to "MUST" in the future with a PCErr 
code if necessary. Thanks!



Best Regards,

Quan




Original
From: SamuelSidor(ssidor) mailto:ssi...@cisco.com>>
To: 熊泉00091065;
Cc: pce-cha...@ietf.org<mailto:pce-cha...@ietf.org> 
mailto:pce-cha...@ietf.org>>;d...@dhruvdhody.com 
mailto:d...@dhruvdhody.com>>;draft-peng-pce-entropy-label-posit...@ietf.org
 
mailto:draft-peng-pce-entropy-label-posit...@ietf.org>>;pce@ietf.org
 mailto:pce@ietf.org>>;
Date: 2024年02月20日 17:08
Subject: RE: [Pce] WG Adoption of draft-peng-pce-entropy-label-position-10
Thanks Quan,

Ack, I’m fine with your proposals + see inline  (I skipped most of them as 
you already responded and there was not much to discuss 😊 ).

Regards,
Samuel

From: xiong.q...@zte.com.cn<mailto:xiong.q...@zte.com.cn> 
mailto:xiong.q...@zte.com.cn>>
Sent: Sunday, February 18, 2024 3:23 AM
To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>
Cc: pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>; 
d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>; 
draft-peng-pce-entropy-label-posit...@ietf.org<mailto:draft-peng-pce-entropy-label-posit...@ietf.org>;
 pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: [Pce] WG Adoption of draft-peng-pce-entropy-label-position-10




Hi Samuel,



Thanks for your detailed review and comments! Sorry for the delay due to the 
holiday.LoL. Happy Chinese New Year!



Please see inline with [Quan].



Abstract:

“…Label Indicator (ELI)/EL pairs SHOULD be inserted in the SR-MPLS label stack 
as per RFC8662…”.



Is it good to start using requirements in draft abstract like this (I consider 
it a bit non-standard looking into abstracts used in other RFCs)? I would use 
more generic wording to just say that RFC8662 is already explaining how Els how 
are supposed to be used in SR-MPLS label stack. Requirements language 
(including “SHOULD” is really defined in Section 2.2 only).



[Quan]: Thanks for your remind. I checked the RFC8662 section 7.1, it mentioned 
"In order for the EL to occur within the ERLD of LSRs along the path 
corresponding to a SPRING label stack, multiple  pairs MAY be inserted 
in this label stack."  Would it be better to change it to "multiple Entropy 
Label Indicator (ELI)/EL pairs may be inserted in the SR-MPLS label stack. 
stack as per RFC8662." without using Requirements language?



 Sure, that should work.

Introduction:

“[RFC5440<https://www.ietf.org/archive/id/draft-peng-pce-entropy-label-position-11.html#RFC5440>]
 describes the Path Computation Element Computation Protocol (PCEP) which is …“



Do you need to expand “PCEP” acronym again even if you expanded it already in 
draft title and abstract? Same potentially applies to EL/ELI/ELP

[Quan]: I think this is required when processing RFC. (And I also checked the 
existing RFC.)



“In some cases, the the controller(e.g. PCE)”

Double “the” and maybe add space after “controller”.

[Quan]:Thanks, I will fix it in next version.



Section 4.2:

“A PCE would also set this bit to 1 to indicate that the ELP information is 
included by PCE and encoded in the Path Computation Reply (PCRep) message as 
per 
[RFC5440<https://www.ietf.org/archive/id/draft-peng-pce-entropy-label-position-11.html#RFC5440>].
 And in a stateful PCE model, it also can be carried in Path Computation Update 
Request (PCUpd) message as per 
[RFC8231<https://www.ietf.org/archive/id/draft-peng-pce-entropy-label-position-11.html#RFC8231>]
 or LSP Initiate Request (PCInitiate) message as per 
[RFC8281<https://www.ietf.org/archive/id/draft-peng-pce-entropy-label-position-11.html#RFC8281>].”



It seems that for stateless it is “MUST” requirement and for stateful, it is 
“CAN” requirement. Isn’t it better to explicitly indicate for both whether PCE 
MUST do it or it is just optional and PCE may decide to do not set that flag at 
all?

 [Quan]: Thanks for your comment. Would it be better to add that " The PCE 
SHOULD set this bit to 1 ... And in a stateful PCE model, it also CAN be 
carried in  "

 Is it just “SHOULD” requirement for stateful and not MUST same way like it 
is done for statele

Re: [Pce] Early code point allocation for draft-ietf-pce-circuit-style-pcep-extensions-02

[Samuel Sidor (ssidor)]

Thanks, Dhruv.

“draft-ietf-pce-circuit-style-pcep-extensions-03” submitted, which fixed typo 
from previous mail.

Regards,
Samuel

From: Pce  On Behalf Of Dhruv Dhody
Sent: Thursday, February 22, 2024 5:43 AM
To: pce@ietf.org
Cc: draft-ietf-pce-circuit-style-pcep-extensi...@ietf.org
Subject: Re: [Pce] Early code point allocation for 
draft-ietf-pce-circuit-style-pcep-extensions-02

Hi WG,

We received no objections and thus will be going ahead with the early 
allocation process.

Authors,

Can you fix the following error and post a new version?  We would then trigger 
the allocation process...

OLD:

8.1.  STATEFUL-PCE-CAPABILITY



   [RFC8231] defines the LSP-EXTENDED-FLAG TLV.  IANA is requested to

   make the following assignment from the "STATEFUL-PCE-CAPABILITY TLV

   Flag Field" registry:

NEW:

8.1.  STATEFUL-PCE-CAPABILITY



   [RFC8231] defines the STATEFUL-PCE-CAPABILITY TLV.  IANA is requested to
   make the following assignment from the "STATEFUL-PCE-CAPABILITY TLV

   Flag Field" registry:

Thanks!
Dhruv & Julien

On Wed, Feb 7, 2024 at 7:29 PM Dhruv Dhody 
mailto:d...@dhruvdhody.com>> wrote:
Hi WG,

We have received a request from the authors of 
draft-ietf-pce-circuit-style-pcep-extensions for an early code point allocation 
for the codepoints listed in -

https://www.ietf.org/archive/id/draft-ietf-pce-circuit-style-pcep-extensions-02.html#section-8.1
 (TBD1-2)
https://www.ietf.org/archive/id/draft-ietf-pce-circuit-style-pcep-extensions-02.html#section-8.2
 (TBD3)
https://www.ietf.org/archive/id/draft-ietf-pce-circuit-style-pcep-extensions-02.html#section-8.3
 (TBD4)

RFC 7120 requires one to meet the following criteria to proceed:

b. The format, semantics, processing, and other rules related to
handling the protocol entities defined by the code points
(henceforth called "specifications") must be adequately described
in an Internet-Draft.

c. The specifications of these code points must be stable; i.e., if
there is a change, implementations based on the earlier and later
specifications must be seamlessly interoperable.

If anyone believes that the draft does not meet these criteria or believes that 
early allocation is not appropriate for any other reason, please send an email 
to the PCE mailing list explaining why. If the chairs hear no objections by 
Wednesday, Feb 21st, we will kick off the early allocation request.

Thanks!
Dhruv & Julien
--- Begin Message ---
A new version of Internet-Draft
draft-ietf-pce-circuit-style-pcep-extensions-03.txt has been successfully
submitted by Samuel Sidor and posted to the
IETF repository.

Name: draft-ietf-pce-circuit-style-pcep-extensions
Revision: 03
Title:PCEP extensions for Circuit Style Policies
Date: 2024-02-22
Group:pce
Pages:13
URL:  
https://www.ietf.org/archive/id/draft-ietf-pce-circuit-style-pcep-extensions-03.txt
Status:   
https://datatracker.ietf.org/doc/draft-ietf-pce-circuit-style-pcep-extensions/
HTML: 
https://www.ietf.org/archive/id/draft-ietf-pce-circuit-style-pcep-extensions-03.html
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-ietf-pce-circuit-style-pcep-extensions
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-circuit-style-pcep-extensions-03

Abstract:

   This document proposes a set of extensions for Path Computation
   Element Communication Protocol (PCEP) for Circuit Style Policies -
   Segment-Routing Policy designed to satisfy requirements for
   connection-oriented transport services.  New TLV is introduced to
   control path recomputation and new flag to add ability to request
   path with strict hops only.



The IETF Secretariat


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

Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

[Samuel Sidor (ssidor)]

Hi authors of this draft,

I support this draft, but I still have a few minor comments:

1.Introduction section:

  *   “Generalzied MPLS (GMPLS) tunnels.” -> typo
  *   “…allow a PCC to specify in a Path Computation Request (PCReq) message 
(sent to a PCE) whether the object must be taken into account by the PCE during 
path computation or is optional” -> do we even need to specify that PCReq is 
sent to PCE?
2.1 Usage Example section:

  *   Is really “Disjoint Association” good example as that constraint itself 
has T flag defined in 
https://www.rfc-editor.org/rfc/rfc8800.html#name-disjoint-tlvs, which is 
allowing relaxing disjointness constraint completely as well (so P=0 for 
association object is not really required for that specific case) Maybe 
consider using some other constraint as an example, why we need this.
3.1 STATEFUL-PCE-CAPABILITY TLV section

  *   “In case the bit is unset, it indicates that the PCEP Speaker would not 
handle the P and I flags in the PCEP common object header for stateful PCE 
messages” – At least “Introduction” section is saying that behavior was not 
defined before this draft was written for older PCEP objects in Stateful 
messages, so isn’t it actually required to fallback to original “undefined” 
behavior if flag is not set instead of doing fallback to “PCEP peer is not 
using them”? We should probably have some “backward compatibility” section as 
we don’t have simple way to figure out whether flag is explicitly cleared or 
just not supported.
3.2.2 The PCUpd Message and the PCInitiate Message

  *   Is it really required to assume P flag set to all PCEP objects in 
PCUpd/PCinit messages? Consider PCE including for example accumulated metric or 
constraints used in the path-computation for policies configured on PCC – why 
PCC would need to support all of those objects even if really just 
“SRP/LSP/ERO” is really required in most of the cases? I would say that even 
“SHOULD” may be too strong here.
3.4 Delegation

  *   “Note that for the delegated LSPs, the PCE can update and mark some 
objects as ignored even when the PCC had set the P flag during delegation. 
Similarly, the PCE can update…” – Is there valid use-case for this behavior? At 
least to me it seems that it actually opening doors for bugs/misinterpretation 
rather than really adding any value.
7.1 Control of Function and Policy

  *   “An operator MUST be allowed to configure the capability to support 
relaxation of constraints in the stateful PCEP message exchange.” – So any 
implementation which would decide to enable it by default in that PCEP session 
is not RFC complaint? Isn’t that too strict?

Thanks a lot,
Samuel

From: Pce  On Behalf Of Dhruv Dhody
Sent: Wednesday, February 21, 2024 10:33 AM
To: pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-stateful-pce-optio...@ietf.org
Subject: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

Hi WG,

This email starts a 3-weeks working group last call for 
draft-ietf-pce-stateful-pce-optional-07.

https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-optional-07.html

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 Wednesday 13 March 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-stateful-pce-optional-07

[Samuel Sidor (ssidor)]

Hi Cheng,

Thanks a lot for your responses. Ack for all of them, new proposed version 
looks fine to me.

For “3.1 STATEFUL-PCE-CAPABILITY TLV section” I was really talking about 
objects defined in RFC5440, but used in stateful messages. Isn’t that behavior 
really “undefined” (before this draft)? Because RFC8231 is really talking only 
about new objects defined in that RFC (SRP, LSP,…) and not about older objects 
re-used in new PCEP messages.

Thanks,
Samuel

From: Cheng Li 
Sent: Wednesday, March 13, 2024 4:46 AM
To: Samuel Sidor (ssidor) ; 
draft-ietf-pce-stateful-pce-optio...@ietf.org
Cc: pce-chairs ; pce@ietf.org; Dhruv Dhody 

Subject: RE: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

Hi Samuel,

Many thanks for your quick review and support,.
Please see our reply below.

BTW, we post the proposed update to address your comments and Shaofu’s comments 
in Github:  https://github.com/muzixing/draft-ietf-pce-stateful-pce-optional

Thanks,
Cheng


From: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>
Sent: Tuesday, March 12, 2024 11:00 PM
To: 
draft-ietf-pce-stateful-pce-optio...@ietf.org<mailto:draft-ietf-pce-stateful-pce-optio...@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-stateful-pce-optional-07

Hi authors of this draft,

I support this draft, but I still have a few minor comments:

1.Introduction section:

  *   “Generalzied MPLS (GMPLS) tunnels.” -> typo
[Cheng]Ack.

  *   “…allow a PCC to specify in a Path Computation Request (PCReq) message 
(sent to a PCE) whether the object must be taken into account by the PCE during 
path computation or is optional” -> do we even need to specify that PCReq is 
sent to PCE?
[Cheng] I don’t see any harm .


2.1 Usage Example section:

  *   Is really “Disjoint Association” good example as that constraint itself 
has T flag defined in 
https://www.rfc-editor.org/rfc/rfc8800.html#name-disjoint-tlvs, which is 
allowing relaxing disjointness constraint completely as well (so P=0 for 
association object is not really required for that specific case) Maybe 
consider using some other constraint as an example, why we need this.
[Cheng] A good point! I think we can remove the association example itself for 
simplicity's sake.


3.1 STATEFUL-PCE-CAPABILITY TLV section

  *   “In case the bit is unset, it indicates that the PCEP Speaker would not 
handle the P and I flags in the PCEP common object header for stateful PCE 
messages” – At least “Introduction” section is saying that behavior was not 
defined before this draft was written for older PCEP objects in Stateful 
messages, so isn’t it actually required to fallback to original “undefined” 
behavior if flag is not set instead of doing fallback to “PCEP peer is not 
using them”? We should probably have some “backward compatibility” section as 
we don’t have simple way to figure out whether flag is explicitly cleared or 
just not supported.

[Cheng]  No, the introduction says -
   Stateful PCE
   [RFC8231] specified that the P and I flags of the PCEP objects
   defined in [RFC8231] is to be set to zero on transmission and ignored
   on receipt, since they are exclusively related to path computation
   requests.

Maybe the word 'clarify' later on is misleading and I have changed that 
everywhere!

Since the behavior is not undefined any legacy implementation will always 
ignore it and with the help of this flag in capability exchange we can be sure 
that there is no backward compatibility issue.



3.2.2 The PCUpd Message and the PCInitiate Message

  *   Is it really required to assume P flag set to all PCEP objects in 
PCUpd/PCinit messages? Consider PCE including for example accumulated metric or 
constraints used in the path-computation for policies configured on PCC – why 
PCC would need to support all of those objects even if really just 
“SRP/LSP/ERO” is really required in most of the cases? I would say that even 
“SHOULD” may be too strong here.

[Cheng]  I can soften this to say - "On a PCEP session on which R bit was set 
by both peers, the PCE SHOULD set the P flag by default, unless a local 
configuration/policy indicates that some constraints (corresponding PCEP 
objects) can be marked as optional and could be ignored by the PCE or the 
object itself conveys informational parameters that can be safely ignored."


3.4 Delegation

  *   “Note that for the delegated LSPs, the PCE can update and mark some 
objects as ignored even when the PCC had set the P flag during delegation. 
Similarly, the PCE can update…” – Is there valid use-case for this behavior? At 
least to me it seems that it actually opening doors for bugs/misinterpretation 
rather than really adding any value.
[Cheng] There was feedback for this to keep it aligned with the definition of 
delegation in RFC 8231 where PCE ought to have control 

Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

[Samuel Sidor (ssidor)]

Hi Dhruv,

Yes, updated text is clear – thanks for providing it.

(and sorry for delay).

Regards,
Samuel

From: Dhruv Dhody 
Sent: Friday, March 15, 2024 7:06 AM
To: Samuel Sidor (ssidor) 
Cc: Cheng Li ; draft-ietf-pce-stateful-pce-optio...@ietf.org; 
pce-chairs ; pce@ietf.org
Subject: Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

Hi Samuel,

On Wed, Mar 13, 2024 at 6:44 PM Samuel Sidor (ssidor) 
mailto:ssi...@cisco.com>> wrote:
Hi Cheng,

Thanks a lot for your responses. Ack for all of them, new proposed version 
looks fine to me.

For “3.1 STATEFUL-PCE-CAPABILITY TLV section” I was really talking about 
objects defined in RFC5440, but used in stateful messages. Isn’t that behavior 
really “undefined” (before this draft)? Because RFC8231 is really talking only 
about new objects defined in that RFC (SRP, LSP,…) and not about older objects 
re-used in new PCEP messages.


Dhruv: You are correct - https://datatracker.ietf.org/doc/html/rfc8231#section-7

How about we extend the text like this -

   The R flag MUST be set by both a PCC and a PCE to indicate support
   for the handling of the P and I flag in the PCEP common object header
   to allow relaxing some constraints by marking objects as optional to
   process.  If the PCEP speaker did not set the R flag but receives
   PCEP objects with P or I bit set, it MUST behave as per the
   processing rule in [RFC8231].  Note that while [RFC8231] stated that
   P and I flags of the PCEP objects defined in [RFC8231] are set to 0
   on and ignored on receipt, it did not say anything about already
   existing PCEP objects and thus the behaviour remained undefined.  To
   safely use this future, both peers need to set the R flag.

Thanks!
Dhruv


Thanks,
Samuel

From: Cheng Li mailto:c...@huawei.com>>
Sent: Wednesday, March 13, 2024 4:46 AM
To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>; 
draft-ietf-pce-stateful-pce-optio...@ietf.org<mailto:draft-ietf-pce-stateful-pce-optio...@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-stateful-pce-optional-07

Hi Samuel,

Many thanks for your quick review and support,.
Please see our reply below.

BTW, we post the proposed update to address your comments and Shaofu’s comments 
in Github:  https://github.com/muzixing/draft-ietf-pce-stateful-pce-optional

Thanks,
Cheng


From: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>
Sent: Tuesday, March 12, 2024 11:00 PM
To: 
draft-ietf-pce-stateful-pce-optio...@ietf.org<mailto:draft-ietf-pce-stateful-pce-optio...@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-stateful-pce-optional-07

Hi authors of this draft,

I support this draft, but I still have a few minor comments:

1.Introduction section:

  *   “Generalzied MPLS (GMPLS) tunnels.” -> typo
[Cheng]Ack.

  *   “…allow a PCC to specify in a Path Computation Request (PCReq) message 
(sent to a PCE) whether the object must be taken into account by the PCE during 
path computation or is optional” -> do we even need to specify that PCReq is 
sent to PCE?
[Cheng] I don’t see any harm .


2.1 Usage Example section:

  *   Is really “Disjoint Association” good example as that constraint itself 
has T flag defined in 
https://www.rfc-editor.org/rfc/rfc8800.html#name-disjoint-tlvs, which is 
allowing relaxing disjointness constraint completely as well (so P=0 for 
association object is not really required for that specific case) Maybe 
consider using some other constraint as an example, why we need this.
[Cheng] A good point! I think we can remove the association example itself for 
simplicity's sake.


3.1 STATEFUL-PCE-CAPABILITY TLV section

  *   “In case the bit is unset, it indicates that the PCEP Speaker would not 
handle the P and I flags in the PCEP common object header for stateful PCE 
messages” – At least “Introduction” section is saying that behavior was not 
defined before this draft was written for older PCEP objects in Stateful 
messages, so isn’t it actually required to fallback to original “undefined” 
behavior if flag is not set instead of doing fallback to “PCEP peer is not 
using them”? We should probably have some “backward compatibility” section as 
we don’t have simple way to figure out whether flag is explicitly cleared or 
just not supported.

[Cheng]  No, the introduction says -
   Stateful PCE
   [RFC8231] specified that the P and I flags of the PCEP objects
   defined in [RFC8231] is to be set to zero on transmission and ignored
   on receipt, since they are exclusively related to path computation
   requests.

Maybe the word 'clarify' later on is misleading and I have changed that 
everywhere!

Since the behavior is not undefined any legacy imple

[Pce] Re: WG Adoption of draft-li-pce-controlled-id-space-16

[Samuel Sidor (ssidor)]

Hi authors,

I support adoption of this document.

A few comments/questions:

  *   Is there reason to limit applicability of that draft to SR-MPLS/SRv6 
(e.g. in Section 3.2)? I can imagine that for example BSID allocation may be 
applicable to RSVP-TE LSPs as well
  *   Is it really good idea to use TLVs in Open message to exchange ID space?
 *   There is no capability advertised before that TLV is included (and 
there is no way to do it since Open message is 1st message sent in that PCEP 
session), so when PCC is including it, it does not know whether PCE can support 
it or not. If PCE is responding with Keepalive message, it can mean 2 things 
with no simple way to figure out which of them occurred:
*   ID space control procedure was successful
*   PCE does not support that TLV and ignored it completely
 *   If any of those ranges has changed, then PCEP session flap will be 
required (I assume that those are changing often, so this may be acceptable). 
If any other PCEP message is used, which can be sent on already established 
PCEP session, then it can be modified without requiring PCEP session flap. 
Maybe consider using PCNtf or some completely new PCEP message and in such case 
you can even use explicit capability to indicate whether PCEP extensions from 
this draft are supported or not
  *   Does it make sense to define some sub-type of delegated space? For 
example, if PCC included 3 ranges in “LABEL-CONTROL-SPACE TLV”, then there can 
be some registry of types to specify that 1st range is for BSID, 2nd one for 
SRGB or SRLB,… How PCE should know which range is supposed to be used for what 
purpose? (I can imagine that for SRGB, SRLB, it can be derived from complete 
SRGB/SRLB range learned from IGP, but such approach probably cannot be used for 
all ranges).
  *   Maybe consider renaming “Block” field in “LABEL-CONTROL-SPACE TLV” to 
something like “Number of blocks” (see for example PST capability TLV in 
https://www.rfc-editor.org/rfc/rfc8408.html#section-3) or even potentially drop 
that field completely as number of ranges can be derived from TLV length
  *   In section 6, you pointed out that synchronization mechanism should be 
used if same label ranges were allocated for multiple PCEs, but it would be 
good to specify details how state-sync will solve synchronization issue (if PCC 
is connected to both PCEs, then both PCEs should see already allocated labels 
from PCRpt messages directly from PCC)
  *   One small type in section 1 “This documnet adds t…””

Thanks,
Samuel

From: Dhruv Dhody 
Sent: Friday, May 17, 2024 1:10 PM
To: pce@ietf.org
Cc: pce-chairs ; draft-li-pce-controlled-id-sp...@ietf.org
Subject: [Pce] WG Adoption of draft-li-pce-controlled-id-space-16

Hi WG,

This email begins the WG adoption poll for draft-li-pce-controlled-id-space-16

https://datatracker.ietf.org/doc/draft-li-pce-controlled-id-space/

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.

Please respond by Monday 3rd June 2024.

Please be more vocal during WG polls!

Thanks!
Dhruv & Julien
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: WG Adoption of draft-li-pce-controlled-id-space-16

[Samuel Sidor (ssidor)]

Hi Cheng,

Ack, thanks for keeping me informed.

(Small correction to my previous mail: “I assume that those are not changing 
often, so this may be acceptable”)

Regards,
Samuel

From: Cheng Li 
Sent: Friday, May 31, 2024 2:47 PM
To: Samuel Sidor (ssidor) ; 
draft-li-pce-controlled-id-sp...@ietf.org
Cc: pce-chairs ; Dhruv Dhody ; 
pce@ietf.org
Subject: RE: [Pce] WG Adoption of draft-li-pce-controlled-id-space-16

Thank you Samuel for your support and comments, we are working on the replies 
to address the comments received in the WG adoption call.
Will need some time, so please expect some delay.  The reply will be sent to 
our mail list next week 😊

Thanks,
Cheng


From: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>
Sent: Friday, May 31, 2024 2:16 PM
To: 
draft-li-pce-controlled-id-sp...@ietf.org<mailto:draft-li-pce-controlled-id-sp...@ietf.org>
Cc: pce-chairs mailto:pce-cha...@ietf.org>>; Dhruv Dhody 
mailto:d...@dhruvdhody.com>>; 
pce@ietf.org<mailto:pce@ietf.org>
Subject: RE: [Pce] WG Adoption of draft-li-pce-controlled-id-space-16

Hi authors,

I support adoption of this document.

A few comments/questions:

  *   Is there reason to limit applicability of that draft to SR-MPLS/SRv6 
(e.g. in Section 3.2)? I can imagine that for example BSID allocation may be 
applicable to RSVP-TE LSPs as well
  *   Is it really good idea to use TLVs in Open message to exchange ID space?
 *   There is no capability advertised before that TLV is included (and 
there is no way to do it since Open message is 1st message sent in that PCEP 
session), so when PCC is including it, it does not know whether PCE can support 
it or not. If PCE is responding with Keepalive message, it can mean 2 things 
with no simple way to figure out which of them occurred:
*   ID space control procedure was successful
*   PCE does not support that TLV and ignored it completely
 *   If any of those ranges has changed, then PCEP session flap will be 
required (I assume that those are changing often, so this may be acceptable). 
If any other PCEP message is used, which can be sent on already established 
PCEP session, then it can be modified without requiring PCEP session flap. 
Maybe consider using PCNtf or some completely new PCEP message and in such case 
you can even use explicit capability to indicate whether PCEP extensions from 
this draft are supported or not
  *   Does it make sense to define some sub-type of delegated space? For 
example, if PCC included 3 ranges in “LABEL-CONTROL-SPACE TLV”, then there can 
be some registry of types to specify that 1st range is for BSID, 2nd one for 
SRGB or SRLB,… How PCE should know which range is supposed to be used for what 
purpose? (I can imagine that for SRGB, SRLB, it can be derived from complete 
SRGB/SRLB range learned from IGP, but such approach probably cannot be used for 
all ranges).
  *   Maybe consider renaming “Block” field in “LABEL-CONTROL-SPACE TLV” to 
something like “Number of blocks” (see for example PST capability TLV in 
https://www.rfc-editor.org/rfc/rfc8408.html#section-3) or even potentially drop 
that field completely as number of ranges can be derived from TLV length
  *   In section 6, you pointed out that synchronization mechanism should be 
used if same label ranges were allocated for multiple PCEs, but it would be 
good to specify details how state-sync will solve synchronization issue (if PCC 
is connected to both PCEs, then both PCEs should see already allocated labels 
from PCRpt messages directly from PCC)
  *   One small type in section 1 “This documnet adds t…””

Thanks,
Samuel

From: Dhruv Dhody mailto:d...@dhruvdhody.com>>
Sent: Friday, May 17, 2024 1:10 PM
To: pce@ietf.org<mailto:pce@ietf.org>
Cc: pce-chairs mailto:pce-cha...@ietf.org>>; 
draft-li-pce-controlled-id-sp...@ietf.org<mailto:draft-li-pce-controlled-id-sp...@ietf.org>
Subject: [Pce] WG Adoption of draft-li-pce-controlled-id-space-16

Hi WG,

This email begins the WG adoption poll for draft-li-pce-controlled-id-space-16

https://datatracker.ietf.org/doc/draft-li-pce-controlled-id-space/

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.

Please respond by Monday 3rd June 2024.

Please be more vocal during WG polls!

Thanks!
Dhruv & Julien
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: I-D Action: draft-ietf-pce-sid-algo-09.txt

[Samuel Sidor (ssidor)]

Hi PCE WG,

FYI: Updated version introduced new PCEP metric types to be able to encode 
metric types introduced in IGP as part of:
https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/

Regards,
Samuel

-Original Message-
From: internet-dra...@ietf.org  
Sent: Friday, June 7, 2024 11:35 AM
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-sid-algo-09.txt

Internet-Draft draft-ietf-pce-sid-algo-09.txt is now available. It is a work 
item of the Path Computation Element (PCE) WG of the IETF.

   Title:   Carrying SR-Algorithm information in PCE-based Networks.
   Authors: Samuel Sidor
Alex Tokar
Shaofu Peng
Shuping Peng
Andrew Stone
   Name:draft-ietf-pce-sid-algo-09.txt
   Pages:   22
   Dates:   2024-06-07

Abstract:

   The SR-Algorithm associated with a Prefix Segment-ID (SID) defines
   the path computation algorithm used by Interior Gateway Protocols
   (IGPs).  This information is available to controllers such as the
   Path Computation Element (PCE) via topology learning.  This document
   proposes an approach for informing headend routers regarding the SR-
   Algorithm associated with each Prefix SID used in PCE-computed paths,
   as well as signalling a specific SR-Algorithm as a constraint to the
   PCE.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-sid-algo/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-pce-sid-algo-09

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-sid-algo-09

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: I-D Action: draft-ietf-pce-sid-algo-09.txt

[Samuel Sidor (ssidor)]

Hi PCE WG,

In latest version of the draft, 3 new metric types are introduced:
- P2P and P2MP Bandwidth metric type (2 separate metric types)
- User defined metric types

Since operator can use multiple "user-defined" metrics in the topology in IGP, 
each of them will use different metric type from range 128-255, which is 
allocated for such purposes. See proposed metric type values in IGP:
https://www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-12.html#name-igp-metric-type-registry

Since only simple way to map between user-defined IGP metric types and PCEP 
metric types is to use same metric type range and 1:1 mapping between them, we 
are allocating it in PCEP as well.

We have a plan to ask for early IANA codepoint allocation for those metric 
types soon (to avoid any potential conflicting allocation in PCEP metric types 
registry, which would complicate mapping in the future), so please check 
updated version of the draft and provide any feedback.

Thanks a lot,
Samuel

-Original Message-----
From: Samuel Sidor (ssidor)  
Sent: Friday, June 7, 2024 11:39 AM
To: pce@ietf.org
Subject: [Pce] Re: I-D Action: draft-ietf-pce-sid-algo-09.txt

Hi PCE WG,

FYI: Updated version introduced new PCEP metric types to be able to encode 
metric types introduced in IGP as part of:
https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/

Regards,
Samuel

-Original Message-
From: internet-dra...@ietf.org 
Sent: Friday, June 7, 2024 11:35 AM
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-sid-algo-09.txt

Internet-Draft draft-ietf-pce-sid-algo-09.txt is now available. It is a work 
item of the Path Computation Element (PCE) WG of the IETF.

   Title:   Carrying SR-Algorithm information in PCE-based Networks.
   Authors: Samuel Sidor
Alex Tokar
Shaofu Peng
Shuping Peng
Andrew Stone
   Name:draft-ietf-pce-sid-algo-09.txt
   Pages:   22
   Dates:   2024-06-07

Abstract:

   The SR-Algorithm associated with a Prefix Segment-ID (SID) defines
   the path computation algorithm used by Interior Gateway Protocols
   (IGPs).  This information is available to controllers such as the
   Path Computation Element (PCE) via topology learning.  This document
   proposes an approach for informing headend routers regarding the SR-
   Algorithm associated with each Prefix SID used in PCE-computed paths,
   as well as signalling a specific SR-Algorithm as a constraint to the
   PCE.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-sid-algo/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-pce-sid-algo-09

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-sid-algo-09

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org 
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: Early code point allocation for draft-ietf-pce-sid-algo-10

[Samuel Sidor (ssidor)]

Hi Tom,

We are trying to align range of 128-255 for user-defined metrics with range 
already allocated in IGP:
https://www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-12.html#name-igp-metric-type-registry
So we can do 1:1 mapping between both ranges. 

If we would like to keep value "255" reserved, then I can think of 3 possible 
solutions:
a) Reserve it in LSR draft as well
b) Allocate range of same size in PCEP, but shift values by some specific value 
(e.g. 128-255 in IGP -> 127-254 in PCEP), but I'm definitely not fan of this 
solution as I assume that it would be source of problems in the future
c) Explicitly allocate some experimental/vendor specific range of metric types 
(e.g. 120-127 to keep mapping simple)

Regards,
Samuel

-Original Message-
From: tom petch  
Sent: Saturday, June 22, 2024 1:26 PM
To: Dhruv Dhody ; pce@ietf.org
Cc: pce-chairs ; draft-ietf-pce-sid-a...@ietf.org
Subject: Re: [Pce] Early code point allocation for draft-ietf-pce-sid-algo-10

From: Dhruv Dhody 
Sent: 22 June 2024 09:41

Hi WG,

We have received a request from the authors of draft-ietf-pce-sid-algo for an 
early code point allocation for the codepoints listed in -

https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-10.html#table-7

These are the codepoints for the latest changes made to align with 
draft-ietf-lsr-flex-algo-bw-con as per - 
https://mailarchive.ietf.org/arch/msg/pce/U2AIec7Vk9LomZM-LlvhxGywQgA/

The chairs would like to know if there are any objections to adding these new 
metric types and keeping a range aside for user defined metrics.


Looking at what I think is the right table, I see that the value zero is 
reserved which I always think is a good start.  But this request allows the 
value of 255 as part of the range which I always think a bad idea.  I think 
that this, the maximum value, should be reserved e.g. lest the range is fully 
assigned and a value is needed to act as an escape.  For such purposes, I think 
one value is enough so I think that the range should end at 254 nd tnot 255

Tom Petch

Further, RFC 7120 requires one to meet the following criteria to proceed:

b. The format, semantics, processing, and other rules related to handling the 
protocol entities defined by the code points (henceforth called 
"specifications") must be adequately described in an Internet-Draft.

c. The specifications of these code points must be stable; i.e., if there is a 
change, implementations based on the earlier and later specifications must be 
seamlessly interoperable.

If anyone believes that the draft does not meet these criteria or believes that 
early allocation is not appropriate for any other reason, please send an email 
to the PCE mailing list explaining why. If the chairs hear no objections by 
Monday, July 8th, we will kick off the early allocation request.

Note that there was an earlier allocation request where some codepoints were 
already allocated by IANA - 
https://mailarchive.ietf.org/arch/msg/pce/8jv4slxI_K3p4qqUPRlAjSgScOA/

Thanks!
Dhruv & Julien

___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: Early code point allocation for draft-ietf-pce-sid-algo-10

[Samuel Sidor (ssidor)]

Hi Adrian,

I’m fine with renaming it, but in general, I don’t see same naming convention 
being followed often in PCEP.

See for example – IGP or TE metric in PCEP – those would be also called as 
“Summed Path IGP metric” or “Summed Path TE metric” if we want to follow same 
convention.
Same thing for “Worst Leaf Summed …” – see for example “P2MP Path Delay metric”:
https://www.rfc-editor.org/rfc/rfc8233.html#section-3.1.6.1
It is also computed as worst leaf cumulative cost of all paths, but such naming 
convention was not used. What about just adding word “Path” into Bandwidth 
metric name, so it is clear that it is not link BW metric?

So instead of currently used “Bandwidth Metric”, it would be “Path Bandwidth 
Metric”? That way name will be aligned with existing naming conventions in PCEP 
and name will be also indicating that it is not link BW.

(but I’m fine even with your proposal if you still prefer to explicitly 
indicate way to compute that metric in the name, maybe with just small 
modification and replacing “Summed” with “Cumulative”).

Thanks,
Samuel

From: Adrian Farrel 
Sent: Saturday, June 22, 2024 1:29 PM
To: 'Dhruv Dhody' ; pce@ietf.org
Cc: 'pce-chairs' ; draft-ietf-pce-sid-a...@ietf.org
Subject: RE: [Pce] Early code point allocation for draft-ietf-pce-sid-algo-10

Although, I might be slightly wrong about the second metric because it is even 
more than that.
Perhaps “Worst Leaf Summed Path Bandwidth”?

A

From: Adrian Farrel mailto:adr...@olddog.co.uk>>
Sent: 22 June 2024 12:13
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-sid-a...@ietf.org' 
mailto:draft-ietf-pce-sid-a...@ietf.org>>
Subject: RE: [Pce] Early code point allocation for draft-ietf-pce-sid-algo-10

No objection, Dhruv, although it might be helpful to distinguish between the 
Bandwidth metric advertised per link and the new PCEP metric type.
Perhaps call the new metrics “Summed Path Bandwidth” and “Summed P2PM Path 
Bandwidth” because it is more descriptive?

Cheers,
Adrian

From: Dhruv Dhody mailto:d...@dhruvdhody.com>>
Sent: 22 June 2024 09:41
To: pce@ietf.org
Cc: pce-chairs mailto:pce-cha...@ietf.org>>; 
draft-ietf-pce-sid-a...@ietf.org
Subject: [Pce] Early code point allocation for draft-ietf-pce-sid-algo-10

Hi WG,

We have received a request from the authors of draft-ietf-pce-sid-algo for an 
early code point allocation for the codepoints listed in -

https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-10.html#table-7

These are the codepoints for the latest changes made to align with 
draft-ietf-lsr-flex-algo-bw-con as per - 
https://mailarchive.ietf.org/arch/msg/pce/U2AIec7Vk9LomZM-LlvhxGywQgA/

The chairs would like to know if there are any objections to adding these new 
metric types and keeping a range aside for user defined metrics.

Further, RFC 7120 requires one to meet the following criteria to proceed:

b. The format, semantics, processing, and other rules related to
handling the protocol entities defined by the code points
(henceforth called "specifications") must be adequately described
in an Internet-Draft.

c. The specifications of these code points must be stable; i.e., if
there is a change, implementations based on the earlier and later
specifications must be seamlessly interoperable.

If anyone believes that the draft does not meet these criteria or believes that 
early allocation is not appropriate for any other reason, please send an email 
to the PCE mailing list explaining why. If the chairs hear no objections by 
Monday, July 8th, we will kick off the early allocation request.

Note that there was an earlier allocation request where some codepoints were 
already allocated by IANA - 
https://mailarchive.ietf.org/arch/msg/pce/8jv4slxI_K3p4qqUPRlAjSgScOA/

Thanks!
Dhruv & Julien
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: Where the Controlled ID info shuold be carried/encoded?

[Samuel Sidor (ssidor)]

Hi Cheng,

Sorry for delayed response.


  1.  PCOpen
I would personally prefer to decouple PCEP session from ID space advertisement 
as there is no logical connection between them, so to me this option seems to 
be least preferred one.

  1.  Use PCEP-LS encoding and make this a node attribute
I’m fine with using PCEP-LS encoding, but ideally without requiring full 
support of PCEP-LS draft as that dependency may be too big for vendors, which 
does not need to support it, but still want to exchange some specific ID space

  1.  New type of notification
  2.  New message/object
I’m fine with both options above, but completely new message type may be 
cleaner approach, ideally with some message type, which can be re-used in the 
future (not too specific for this usecase).

Thanks a lot,
Samuel

From: Cheng Li 
Sent: Thursday, June 27, 2024 5:09 PM
To: Cheng Li ; pce@ietf.org
Subject: [Pce] Re: Where the Controlled ID info shuold be carried/encoded?

Echo request 😊

Hope to have your valuable suggestions!

Thanks,
Cheng


From: Cheng Li 
mailto:c.l=40huawei@dmarc.ietf.org>>
Sent: Thursday, June 20, 2024 11:46 AM
To: pce@ietf.org
Subject: [Pce] Where the Controlled ID info shuold be carried/encoded?

Hi Guys，

Thank you so much for your helpful review and comments of our draft 
draft-ietf-pce-controlled-id-space.
In the WG adoption, I can summarize our discussion into the below bullets, hope 
they are correct,

  1.  The draft is useful, and the mechanism defined in the draft is needed, we 
should work on it. (Thanks!)
  2.  We need to discuss the where the info should be carried in the PCEP. Open 
Object seems not so good ☹
  3.  TLV encoding should be updated to be more generic or let's avoid the 
generic description and define specific sub-TLVs as needed.

I see the reasons why we decided to carry the info in PCEP Open Object, because 
it is a device-wide configuration info, which should not be modified in the 
running state. We may face a lot of trouble of removing some IDs and then 
modify the range in a running network. However, we may also need to handle the 
negotiation between PCC and PCE?  Therefore, I am also concerning about this.

I like to hear your voice on this, which object/msg is appropriate to carry the 
info? I am open with other options.

Possible options could be

l  Open message

l  Use PCEP-LS encoding and make this a node attribute

l  New type of notification

l  New message/object

Once we get the conclusion of this, we can go to the bullet 3, which is much 
easier that bullet 2. IMHO, I will prefer to define sub-TLVs one by one, this 
can decouple the relations between IDs, though we may need to delete the 
'generic' words.

Thoughts?
Cheng

___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Review of draft-ietf-pce-pcep-pmtu

[Samuel Sidor (ssidor)]

Hi pce-pcep-pmtu draft authors,

A few questions/comments:

  *   Since metric objects in PCEP are often defined in pairs - P2P and P2MP, 
do we need to define behavior for P2MP in this draft as well (or at least 
mention that it is out of scope if there is no plan to cover)?
  *   In Section 4.2, it is described that new metric object can be included in 
PCInitiate and PCUpdate to inform about metric computed, but I guess that it 
can be included when used as bound as well for PCE initiated LSPs
  *   In Section 4.3.1, multi-SL support is described as TBD - can't we just 
use per SL metric object as described in 
"https://datatracker.ietf.org/doc/html/draft-ietf-pce-multipath-10#name-sr-policy-candidate-path-wi";?

+ a few minor comments/typos/..., mostly grammar related, which is spotted 
while reading it:

Section 1:
Typo:
well as Generalzied MPLS (GMPLS)
...
A SR path can be derived from -> An SR path can be derived from
...
[I-D.peng-spring-pmtu-sr-policy] specifies the link maximum transmission unit 
(MTU)  (specify -> specifies)

Section 3:
...link MTU of all the links in a path between a... (on -> in)

Section 4.1:
Shouldn't this be uppercase MUST?
"...for the Path MTU metric that must not be exceeded for the..."

"...A path P of an LSP is a list..." ( a LSP -> an LSP)
"A PCC can also use this metric to request that the PCE optimize" (ask -> 
request that the)
"The error handling and processing of the METRIC object are as specified in 
[RFC5440]." (is -> are)

Section 4.4:
Maybe better to call it backup (same way like for example 
https://www.ietf.org/archive/id/draft-ietf-pce-multipath-11.html#name-two-primary-paths-protected):
"The path MTU metric can be used for both the primary and backup paths" 
(primary and protection path -> primary and backup paths)

Thanks a lot,
Samuel
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: IPR poll for draft-ietf-pce-stateful-pce-vendor

[Samuel Sidor (ssidor)]

I am not aware of any IPR applicable to this draft that should be disclosed in 
accordance with IETF IPR rules.

Regards,
Samuel

From: Cheng Li 
Sent: Friday, July 5, 2024 2:46 PM
To: Andrew Stone (Nokia) ; Zhenghaomian 
; msiva...@gmail.com; Samuel Sidor (ssidor) 
; Zafar Ali (zali) ; pce@ietf.org; 
pce-cha...@ietf.org
Subject: RE: IPR poll for draft-ietf-pce-stateful-pce-vendor

I am not aware of any IPR applicable to this draft that should be disclosed in 
accordance with IETF IPR rules.

Thanks,
Cheng


From: Andrew Stone (Nokia) 
mailto:andrew.st...@nokia.com>>
Sent: Thursday, July 4, 2024 7:09 PM
To: Cheng Li mailto:c...@huawei.com>>; Zhenghaomian 
mailto:zhenghaom...@huawei.com>>; 
msiva...@gmail.com<mailto:msiva...@gmail.com>; 
ssi...@cisco.com<mailto:ssi...@cisco.com>; 
z...@cisco.com<mailto:z...@cisco.com>; pce@ietf.org<mailto:pce@ietf.org>; 
pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>
Subject: IPR poll for draft-ietf-pce-stateful-pce-vendor

Hi Authors,

In preparation for WGLC on this draft, we'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 the 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,
Andrew
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: WGLC for draft-ietf-pce-stateful-pce-vendor-03

[Samuel Sidor (ssidor)]

Hi all,

I support LC of this draft (as co-author).

Regards,
Samuel

From: Dhruv Dhody 
Sent: Thursday, July 4, 2024 3:17 PM
To: pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-stateful-pce-ven...@ietf.org
Subject: WGLC for draft-ietf-pce-stateful-pce-vendor-03

Hi WG,

This email starts a 2-weeks working group last call for 
draft-ietf-pce-stateful-pce-vendor-03.

https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-vendor-03.html

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 Thursday 18 July 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
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: WGLC for draft-ietf-pce-stateful-pce-vendor-03

[Samuel Sidor (ssidor)]

Hi Boris,

At least my understanding is that:
1) As indicated later in that draft "Different instances of the object can have 
different Enterprise Numbers" - Enterprise ID can be different, but it can be 
same as well, so you can decide to include 2 vendor info objects with same 
Enterprise number if you want as well (e.g. if each of them represent some 
future standard object with not allocated codepoints and you want to simplify 
parsing). 

" if we have big/huge amount of LSPs in that PCRpt message, will we have Vendor 
Information Object per each object per each LSP?"

Correct. Let's use one example - you want to report per LSP statistics in PCEP 
- since there is no standard object, you can encode it into vendor specific 
object. If there is 3rd party PCE, then it will just ignore it (because 
Enterprise ID is not matching). 

2) Since format of vendor object/TLV used by each vendor is not 
published/standardized (this is answering you other question as well), then at 
least I'm really assuming that in vast majority of cases, vendor objects for 
multiple different vendors will not be advertised. E.g. Cisco PCC will use 
vendor info object with cisco enterprise number only. " 
https://www.rfc-editor.org/rfc/rfc7470.html#section-6.1"; is already even 
suggesting making advertisement of vendor object configurable, so it can be 
blocked if 3rd party PCE is used. See also 
https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-vendor-03.html#section-4
 - draft is already inheriting all manageability considerations from RFC7470.

3) Enterprise numbers are not PCEP specific. See:
https://www.iana.org/assignments/enterprise-numbers/

Regards,
Samuel

-Original Message-
From: Boris Hassanov  
Sent: Sunday, July 7, 2024 4:24 PM
To: pce@ietf.org; Dhruv Dhody 
Cc: pce-chairs ; 
draft-ietf-pce-stateful-pce-ven...@ietf.org
Subject: Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-vendor-03

Hi Dhruv and WG,

I read the latest version of draft.  Indeed It adds more flexibility  to 
provide vendor-specific information for  PCEs using different messages.
I support the further work on this draft. But I would like to see the following 
clarifications:

1) The draft says : "Multiple instances of the object MAY be used on a single 
PCRpt message.". Does it mean the  addition of different Vendor Information 
objects (with different Enterprise numbers) per each PCEP object in PCRpt ? If 
I got it correct. if we have big/huge amount of LSPs in that PCRpt message, 
will we have Vendor Information Object per each object per each LSP?
2) RFC 7470 has section 6.6 Impact on Network Operation which says: " On the 
other hand, the presence of additional vendor-specific information in PCEP 
messages may congest the operation of the protocol especially if the PCE does 
not support the information supplied by the PCC.  ".
I would like to see some analysis in the draft about potential impact of 
increasing the amount of Vendor Information objects on network operations too. 
IMO similar section as in RFC 7470 is needed.


3) RFC 7470 also says: "Enterprise Numbers are assigned by IANA and managed 
through an IANA registry ".  But they are absent so far (at least here: 
https://www.iana.org/assignments/pcep/pcep.xhtml  ).


How can customers which develop their own PCEs or open source PCEs can know the 
details of that vendor specific information into Vendor Information objects to 
consider that in their path calculation algos?
Will vendors disclose it somehow as their good will or it will be just sort of 
black box approach?


Thank you in advance.


SY,
Boris










On Thursday, July 4, 2024 at 04:18:29 PM GMT+3, Dhruv Dhody 
 wrote: 





Hi WG,This email starts a 2-weeks working group last call for 
draft-ietf-pce-stateful-pce-vendor-03.https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-vendor-03.htmlPlease
 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 Thursday 18 July 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
To unsubscribe send an email to pce-le...@ietf.org
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: Pending item for draft-ietf-pce-state-sync

[Samuel Sidor (ssidor)]

Hi Andrew, Dhruv,

Proposed text looks fine to me.

Do we also need to consider future result of discussion for controlled ID? E.g. 
if decision will be done to use Notification message for ID space 
advertisement, will we need to synchronize content of those on top of TLVs from 
Open object?

Thanks,
Samuel

From: Dhruv Dhody 
Sent: Tuesday, July 9, 2024 11:18 AM
To: Andrew Stone (Nokia) 
Cc: draft-ietf-pce-state-s...@ietf.org; pce@ietf.org; pce-chairs 

Subject: [Pce] Re: Pending item for draft-ietf-pce-state-sync

Hi Andrew,

On Mon, Jul 8, 2024 at 4:37 PM Andrew Stone (Nokia) 
mailto:40nokia@dmarc.ietf.org>> 
wrote:
Hi Dhruv, PCE WG

Thanks for bringing this up again. PcNotif object with an add/remove semantics 
is exactly what I was thinking about as well in terms of how to carry this. I 
think we could (later) expand this to PCC->PCE communication to permit 
on-the-fly updates/changes to PcOpen criteria to avoid requiring session flap 
should knobs be flipped. With that said, I do like the proposed scoping of this 
via notification type so that way delete mechanics can only be applied for 
state sync.

Minor recommendation to clarify the PcNtf should be sent before StateSync / 
PcRpt messages:

On session establishment with a state-sync PCE, the PCE MUST also exchange
notifications for each of the PCCs it already has a session
established prior to State Synchronization described in section 3.2.


Dhruv: I suggest adding this here ->

   *  Notification-value=1: Add PCC's Open Information.  On session
  establishment with a PCC, a PCE with state-sync capability MUST
  send this notification to other state-sync PCEs with the SPEAKER-
  ENTITY-ID TLV with values that identify the PCC and any other TLVs
  encoded in the OPEN object received from the PCC.  On session
  establishment with a state-sync PCE, the PCE MUST also exchange
  notifications for each of the PCCs it already has a session
  established.  The PCE MUST exchange this notification prior to the
  State Synchronization (described in Section 3.2).  Note that the
  PCNtf can be used to carry multiple NOTIFICATION objects, one for
  each PCC.  On receiving this notification, PCE adds the
  information to its database.


Overall text proposal looks good to me. I would assume this belongs in a 3.x 
section in the document.


I suggest that this could be a subsection "3.5.1.  Information Received via 
Open Message from PCC"

Thanks!
Dhruv


Only caveat I can see is there would be no mechanism to potentially carry flag 
values from the PcOpen object, however, there's currently no flags defined 
after all these years and I suspect if they ever were defined they likely may 
not be relevant for state sync anyways. Should it ever be required, it would be 
straight forward to define a new TLV for pce-state sync to carry that anyways. 
I do not think we need to handle this now.

Thanks!
Andrew

From: Dhruv Dhody mailto:d...@dhruvdhody.com>>
Date: Saturday, July 6, 2024 at 7:52 AM
To: 
draft-ietf-pce-state-s...@ietf.org 
mailto:draft-ietf-pce-state-s...@ietf.org>>,
 Andrew Stone (Nokia) mailto:andrew.st...@nokia.com>>
Cc: pce@ietf.org mailto:pce@ietf.org>>, 
pce-chairs mailto:pce-cha...@ietf.org>>
Subject: Pending item for draft-ietf-pce-state-sync

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,

There has been one pending item in draft-ietf-pce-state-sync. During IETF 119, 
we discussed adding support for the PCE to send the information it received in 
the PCC's open message to the other state-sync PCEs.

Here is my initial proposal of using a new notification type for this purpose. 
I have some initial text that authors and WG can consider. We can discuss this 
during IETF 120 as well if required.

---
3.5.1.  Information Received via Open Message from PCC

   To ensure uniform information across all PCEs, each PCE needs to
   relay the information it receives from the PCCs in the Open message
   to other PCEs via the state-sync session.  This includes various PCC
   capabilities and parameters such as Maximum Segment Identifier (SID)
   Depth (MSD).

   As per [RFC5440], the PCEP Notification message (PCNtf) can be sent
   by a PCEP speaker to notify its peer of a specific event.  A PCE
   should notify the other state-sync PCEs of the information it
   receives from the PCCs open message.  Section 7.14 of [RFC5440]
   specify the NOTIFICATION object.  This document adds a new
   Notification-type=TBD6 (Inter-PCE State-sync) and two Notification-
   values (Notification-value=1 (Add PCC's Open Information) and
   Notification-value=2 (Remove PCC's Open Information)).

   For Notification-type=TBD6, the NOTIFICATION object encodes the
   SPEAKER-ENTITY-ID TLV and any other TLV that can be carried inside
   the 

[Pce] Re: Pending item for draft-ietf-pce-state-sync

[Samuel Sidor (ssidor)]

Hi Dhruv,

Agreed, let’s skip it. Controlled-ID draft already mentioned state-sync I-D in 
Section 6, so it can also clarify way to exchange controlled ID ranges if 
needed (those will be synchronized automatically as part of “any other TLVs 
encoded in the OPEN object received from the PCC” if decision will be done to 
include them into Open object).

Regards,
Samuel

From: Dhruv Dhody 
Sent: Tuesday, July 9, 2024 1:43 PM
To: Samuel Sidor (ssidor) 
Cc: Dhruv Dhody ; Andrew Stone (Nokia) 
; draft-ietf-pce-state-s...@ietf.org; 
pce@ietf.org; pce-chairs 
Subject: Re: [Pce] Re: Pending item for draft-ietf-pce-state-sync

Hi Samuel,

On Tue, Jul 9, 2024 at 12:30 PM Samuel Sidor (ssidor) 
mailto:ssi...@cisco.com>> wrote:
Hi Andrew, Dhruv,

Proposed text looks fine to me.

Do we also need to consider future result of discussion for controlled ID? E.g. 
if decision will be done to use Notification message for ID space 
advertisement, will we need to synchronize content of those on top of TLVs from 
Open object?


Personally, I consider controlled ID (and PCECC) to be out of scope of the 
state-sync I-D. We can make that explicit in the I-D.
In future another specification can tackle it if there is a need and can use 
the technique that you suggest.

Thanks!
Dhruv

Thanks,
Samuel

From: Dhruv Dhody mailto:dhruv.i...@gmail.com>>
Sent: Tuesday, July 9, 2024 11:18 AM
To: Andrew Stone (Nokia) 
mailto:40nokia@dmarc.ietf.org>>
Cc: 
draft-ietf-pce-state-s...@ietf.org<mailto:draft-ietf-pce-state-s...@ietf.org>; 
pce@ietf.org<mailto:pce@ietf.org>; pce-chairs 
mailto:pce-cha...@ietf.org>>
Subject: [Pce] Re: Pending item for draft-ietf-pce-state-sync

Hi Andrew,

On Mon, Jul 8, 2024 at 4:37 PM Andrew Stone (Nokia) 
mailto:40nokia@dmarc.ietf.org>> 
wrote:
Hi Dhruv, PCE WG

Thanks for bringing this up again. PcNotif object with an add/remove semantics 
is exactly what I was thinking about as well in terms of how to carry this. I 
think we could (later) expand this to PCC->PCE communication to permit 
on-the-fly updates/changes to PcOpen criteria to avoid requiring session flap 
should knobs be flipped. With that said, I do like the proposed scoping of this 
via notification type so that way delete mechanics can only be applied for 
state sync.

Minor recommendation to clarify the PcNtf should be sent before StateSync / 
PcRpt messages:

On session establishment with a state-sync PCE, the PCE MUST also exchange
notifications for each of the PCCs it already has a session
established prior to State Synchronization described in section 3.2.


Dhruv: I suggest adding this here ->

   *  Notification-value=1: Add PCC's Open Information.  On session
  establishment with a PCC, a PCE with state-sync capability MUST
  send this notification to other state-sync PCEs with the SPEAKER-
  ENTITY-ID TLV with values that identify the PCC and any other TLVs
  encoded in the OPEN object received from the PCC.  On session
  establishment with a state-sync PCE, the PCE MUST also exchange
  notifications for each of the PCCs it already has a session
  established.  The PCE MUST exchange this notification prior to the
  State Synchronization (described in Section 3.2).  Note that the
  PCNtf can be used to carry multiple NOTIFICATION objects, one for
  each PCC.  On receiving this notification, PCE adds the
  information to its database.


Overall text proposal looks good to me. I would assume this belongs in a 3.x 
section in the document.


I suggest that this could be a subsection "3.5.1.  Information Received via 
Open Message from PCC"

Thanks!
Dhruv


Only caveat I can see is there would be no mechanism to potentially carry flag 
values from the PcOpen object, however, there's currently no flags defined 
after all these years and I suspect if they ever were defined they likely may 
not be relevant for state sync anyways. Should it ever be required, it would be 
straight forward to define a new TLV for pce-state sync to carry that anyways. 
I do not think we need to handle this now.

Thanks!
Andrew

From: Dhruv Dhody mailto:d...@dhruvdhody.com>>
Date: Saturday, July 6, 2024 at 7:52 AM
To: 
draft-ietf-pce-state-s...@ietf.org<mailto:draft-ietf-pce-state-s...@ietf.org> 
mailto:draft-ietf-pce-state-s...@ietf.org>>,
 Andrew Stone (Nokia) mailto:andrew.st...@nokia.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org> mailto:pce@ietf.org>>, 
pce-chairs mailto:pce-cha...@ietf.org>>
Subject: Pending item for draft-ietf-pce-state-sync

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


Hi,

There has been one pending item in draft-ietf-pce-state-sync. During IETF 119, 
we discussed adding support for the PCE to send the information it received in 
the PCC's open mess

[Pce] Re: WGLC for draft-ietf-pce-stateful-pce-vendor-03

[Samuel Sidor (ssidor)]

Hi all,

I agree that clear reference to list of enterprise IDs would be better. 
Statement proposed by Andrew looks good enough to me (I guess that we don't 
need to update RFC7470 even if that would be cleaner approach as that gap was 
initially introduced in that RFC).

Regards,
Samuel

From: Andrew Stone (Nokia) 
Sent: Tuesday, July 9, 2024 10:35 PM
To: Samuel Sidor (ssidor) ; Boris Hassanov 
; pce@ietf.org; Dhruv Dhody 
Cc: pce-chairs ; 
draft-ietf-pce-stateful-pce-ven...@ietf.org
Subject: Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-vendor-03

. or maybe in this document we can have text that simply says:

"RFC 7470 defines the Enterprise Numbers are allocated by IANA and managed 
through an IANA registry [RFC2578]. This document further clarifies that the 
IANA registry described is the Private Enterprise Numbers (PEN), in which 
registrations and the registration location are further described by RFC 9371"

From: Andrew Stone (Nokia) 
mailto:andrew.st...@nokia.com>>
Date: Tuesday, July 9, 2024 at 4:31 PM
To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>, Boris 
Hassanov mailto:bhassa...@yahoo.com>>, 
pce@ietf.org<mailto:pce@ietf.org> mailto:pce@ietf.org>>, Dhruv 
Dhody mailto:d...@dhruvdhody.com>>
Cc: pce-chairs mailto:pce-cha...@ietf.org>>, 
draft-ietf-pce-stateful-pce-ven...@ietf.org<mailto:draft-ietf-pce-stateful-pce-ven...@ietf.org>
 
mailto:draft-ietf-pce-stateful-pce-ven...@ietf.org>>
Subject: Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-vendor-03
Hi all,

I've read the latest version and support it's progression. The text is a clear 
read.

Share similar comment of Boris' about Enterprise number - inherited from RFC 
7470 -> points to RFC 2578 -> then pointers drop unless you read between the 
lines that it's effectively the SNMP OID PEN. Maybe it's worth having a bit 
more text for this just to say it's from the IANA "Private Enterprise Numbers" 
registry? or a reference to RFC9371? Although an update for RFC7470 to clarify 
this (can that be a BIS?) is likely better than embedding it in this extension 
draft.

Thanks
Andrew


From: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>
Date: Monday, July 8, 2024 at 5:30 AM
To: Boris Hassanov mailto:bhassa...@yahoo.com>>, 
pce@ietf.org<mailto:pce@ietf.org> mailto:pce@ietf.org>>, Dhruv 
Dhody mailto:d...@dhruvdhody.com>>
Cc: pce-chairs mailto:pce-cha...@ietf.org>>, 
draft-ietf-pce-stateful-pce-ven...@ietf.org<mailto:draft-ietf-pce-stateful-pce-ven...@ietf.org>
 
mailto:draft-ietf-pce-stateful-pce-ven...@ietf.org>>
Subject: RE: [Pce] WGLC for draft-ietf-pce-stateful-pce-vendor-03

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 Boris,

At least my understanding is that:
1) As indicated later in that draft "Different instances of the object can have 
different Enterprise Numbers" - Enterprise ID can be different, but it can be 
same as well, so you can decide to include 2 vendor info objects with same 
Enterprise number if you want as well (e.g. if each of them represent some 
future standard object with not allocated codepoints and you want to simplify 
parsing).

" if we have big/huge amount of LSPs in that PCRpt message, will we have Vendor 
Information Object per each object per each LSP?"

Correct. Let's use one example - you want to report per LSP statistics in PCEP 
- since there is no standard object, you can encode it into vendor specific 
object. If there is 3rd party PCE, then it will just ignore it (because 
Enterprise ID is not matching).

2) Since format of vendor object/TLV used by each vendor is not 
published/standardized (this is answering you other question as well), then at 
least I'm really assuming that in vast majority of cases, vendor objects for 
multiple different vendors will not be advertised. E.g. Cisco PCC will use 
vendor info object with cisco enterprise number only. " 
https://www.rfc-editor.org/rfc/rfc7470.html#section-6.1"; is already even 
suggesting making advertisement of vendor object configurable, so it can be 
blocked if 3rd party PCE is used. See also 
https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-vendor-03.html#section-4
 - draft is already inheriting all manageability considerations from RFC7470.

3) Enterprise numbers are not PCEP specific. See:
https://www.iana.org/assignments/enterprise-numbers/

Regards,
Samuel

-Original Message-
From: Boris Hassanov mailto:bhassa...@yahoo.com>>
Sent: Sunday, July 7, 2024 4:24 PM
To: pce@ietf.org<mailto:pce@ietf.org>; Dhruv Dhody 
mailto:d...@dhruvdhody.com>>
Cc: pce-chairs mailto:pce-cha...@ietf.org>>; 
draft-ietf-pce-stateful-pce-ven...@ietf.org<mailto:draft-ietf-pce-stateful-pce-ven...@ietf.org&

[Pce] Re: WGLC for draft-ietf-pce-stateful-pce-vendor-03

[Samuel Sidor (ssidor)]

Hi Boris,

We can discuss that optimization with other co-authors, but I personally don’t 
see good reason for doing it specifically for vendor information object.

If that object is used for encoding operational state (like example with LSP 
statistics, which I mentioned in my last mail), then there is no way to 
optimize it as content of Vendor Information object is (or at least may be) 
different for each LSP.

If it is used for constraints, optimization metric,…, then there is no 
difference, when compared with existing constraints, which are also repeated 
for every LSP (e.g. if I have 2k LSPs with same affinity, then PCC will encode 
same LSPA object 2k times – separately in each PCRpt). If size of 
encoded/repeated objects in PCEP message is really concern, then existing 
policy association (link<https://datatracker.ietf.org/doc/html/rfc9005>) can be 
used to group LSPs together, encode association group only and translate it to 
configuration on other PCEP peer, but even that really makes sense if size of 
encoded Vendor Information object is higher than size of Association object 
itself.

For your second concern – yes, that can happen, but same thing can happen even 
without having Vendor Info object. Anybody can use experimental 
range<https://www.rfc-editor.org/rfc/rfc8356.html> for PCEP objects or even 
completely non-standard codepoints and disable/enable advertisement of that 
object based on local configuration or based on some capability.

Regards,
Samuel

From: Boris Hassanov 
Sent: Saturday, July 13, 2024 8:07 AM
To: pce@ietf.org; Dhruv Dhody ; Samuel Sidor (ssidor) 

Cc: pce-chairs ; 
draft-ietf-pce-stateful-pce-ven...@ietf.org
Subject: Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-vendor-03

Hi Samuel,

I got your points and clarifications.

I would only think can we somehow optimize the quantity of Vendor Information 
Objects, to reduce the signaling overhead, may be use the same one for N LSPs 
etc.?

Secondly, I just afraid "ships in the night" situation when we could have 
several parallel universes: one per each vendor in the network, where each 
vendor will encode as much info as he can into Vendor Information Object 
(because it is faster) and common PCEP with lack of additional info (so less 
optimal calculations for example).

Thank you.

SY,
Boris



On Monday, July 8, 2024 at 12:30:00 PM GMT+3, Samuel Sidor (ssidor) 
mailto:ssi...@cisco.com>> wrote:


Hi Boris,

At least my understanding is that:
1) As indicated later in that draft "Different instances of the object can have 
different Enterprise Numbers" - Enterprise ID can be different, but it can be 
same as well, so you can decide to include 2 vendor info objects with same 
Enterprise number if you want as well (e.g. if each of them represent some 
future standard object with not allocated codepoints and you want to simplify 
parsing).

" if we have big/huge amount of LSPs in that PCRpt message, will we have Vendor 
Information Object per each object per each LSP?"

Correct. Let's use one example - you want to report per LSP statistics in PCEP 
- since there is no standard object, you can encode it into vendor specific 
object. If there is 3rd party PCE, then it will just ignore it (because 
Enterprise ID is not matching).

2) Since format of vendor object/TLV used by each vendor is not 
published/standardized (this is answering you other question as well), then at 
least I'm really assuming that in vast majority of cases, vendor objects for 
multiple different vendors will not be advertised. E.g. Cisco PCC will use 
vendor info object with cisco enterprise number only. " 
https://www.rfc-editor.org/rfc/rfc7470.html#section-6.1"; is already even 
suggesting making advertisement of vendor object configurable, so it can be 
blocked if 3rd party PCE is used. See also 
https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-vendor-03.html#section-4
 - draft is already inheriting all manageability considerations from RFC7470.

3) Enterprise numbers are not PCEP specific. See:
https://www.iana.org/assignments/enterprise-numbers/

Regards,
Samuel

-Original Message-
From: Boris Hassanov mailto:bhassa...@yahoo.com>>
Sent: Sunday, July 7, 2024 4:24 PM
To: pce@ietf.org<mailto:pce@ietf.org>; Dhruv Dhody 
mailto:d...@dhruvdhody.com>>
Cc: pce-chairs mailto:pce-cha...@ietf.org>>; 
draft-ietf-pce-stateful-pce-ven...@ietf.org<mailto:draft-ietf-pce-stateful-pce-ven...@ietf.org>
Subject: Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-vendor-03

Hi Dhruv and WG,

I read the latest version of draft.  Indeed It adds more flexibility  to 
provide vendor-specific information for  PCEs using different messages.
I support the further work on this draft. But I would like to see the following 
clarifications:

1) The draft says : "Multiple instances of the object MAY be used on a single 
PCRpt message.". Does it mean the  a

[Pce] Re: Experimental Error-Types and Error-values

[Samuel Sidor (ssidor)]

Hi Adrian, Dhruv,

I also see added value in doing it. Ideally we should really have some reserved 
range wherever possible to avoid using completely non-standard objects…

Thanks,
Samuel

From: Dhruv Dhody 
Sent: Tuesday, July 23, 2024 4:03 AM
To: adr...@olddog.co.uk
Cc: pce@ietf.org
Subject: [Pce] Re: Experimental Error-Types and Error-values

Hi Adrian,

As a WG participant...

On Wed, Jul 3, 2024 at 3:45 AM Adrian Farrel 
mailto:adr...@olddog.co.uk>> wrote:
Hi working group,

I just refreshed draft-farrel-pce-experimental-errors and cleaned up a couple 
of nits.

It tweaks the scope of the IANA registry to carve out a few Error-Types to be 
for Experimental Use. It also describes how to experiment with Error-Types and 
Error-values

BIG QUESTION

Does the working group want to pursue this?

IMHO it might be worth doing this. Can those who have used experimental 
codepoints for messages, objects and TLV comment on the need for them for 
error-types? Could this have helped you in your experiments?

If we go down in this direction, I also wonder if we should reserve some space 
for error-values for each of the error-types as it is common practice to assign 
new errors under the error-type!

Thanks!
Dhruv


If so: chairs, can we consider adoption?
If not: I can get a little peace by dropping the draft

Cheers,
Adrian

-Original Message-
From: internet-dra...@ietf.org 
mailto:internet-dra...@ietf.org>>
Sent: 03 July 2024 11:34
To: Adrian Farrel mailto:adr...@olddog.co.uk>>; Haomian 
Zheng mailto:zhenghaom...@huawei.com>>
Subject: New Version Notification for 
draft-farrel-pce-experimental-errors-02.txt

A new version of Internet-Draft draft-farrel-pce-experimental-errors-02.txt
has been successfully submitted by Adrian Farrel and posted to the
IETF repository.

Name: draft-farrel-pce-experimental-errors
Revision: 02
Title:Allowing Experimental Error Codes in the Path Computation Element 
Protocol
Date: 2024-07-03
Group:Individual Submission
Pages:7
URL:  
https://www.ietf.org/archive/id/draft-farrel-pce-experimental-errors-02.txt
Status:   https://datatracker.ietf.org/doc/draft-farrel-pce-experimental-errors/
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-farrel-pce-experimental-errors
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-farrel-pce-experimental-errors-02

Abstract:

   Experimental RFCs are often considered beneficial approaches to
   developing new protocol features.  To that end, sub-ranges of code
   point registries are often designated as for experimental use.

   IANA assigns values to the Path Computation Element Communication
   Protocol (PCEP) parameters (messages, objects, TLVs).  According to
   RFC 5440 as updated by RFC 8356, the allocation policies for the
   registries for PCEP messages, objects, and TLV types are IETF Review
   with some sub-ranges of these registries being assigned for
   Experimental Use.  However, the registry of PCEP Error-Types and
   Error-values has only the IETF Review assignment policy meaning that
   experimentation is somewhat limited.

   This document updates RFC 5440 by designating a range of PCEP Error-
   Types for Experimental Use.

___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: Early code point allocation for draft-ietf-pce-sid-algo-10

[Samuel Sidor (ssidor)]

Hi all,

Version 12 submitted (please see attached mail).

Changes included:

  1.  Addressed feedback from IANA
  2.  Addressed comments from Peng Shaofu (Thanks for review).

Renaming of Bandwidth metric addressed in version 11 and as Dhruv stated in his 
previous message – reserving 255 value may require wider discussion.

Thanks a lot for comments to Adrian and Tom as well.

Regards,
Samuel

From: Dhruv Dhody 
Sent: Tuesday, July 23, 2024 4:02 PM
To: pce@ietf.org
Cc: pce-chairs ; draft-ietf-pce-sid-a...@ietf.org
Subject: Re: Early code point allocation for draft-ietf-pce-sid-algo-10

Hi WG,

We will be going ahead with the early allocation. Authors have posted the -11 
version - https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-11.html

The authors are planning to make another update based on the feedback from IANA.

A point was made to mark 255 as reserved but this practice needs broader 
discussion and preferably a consistent approach across registries.

Thanks!
Dhruv & Julien

On Sat, Jun 22, 2024 at 1:41 AM Dhruv Dhody 
mailto:d...@dhruvdhody.com>> wrote:
Hi WG,

We have received a request from the authors of draft-ietf-pce-sid-algo for an 
early code point allocation for the codepoints listed in -

https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-10.html#table-7

These are the codepoints for the latest changes made to align with 
draft-ietf-lsr-flex-algo-bw-con as per - 
https://mailarchive.ietf.org/arch/msg/pce/U2AIec7Vk9LomZM-LlvhxGywQgA/

The chairs would like to know if there are any objections to adding these new 
metric types and keeping a range aside for user defined metrics.

Further, RFC 7120 requires one to meet the following criteria to proceed:

b. The format, semantics, processing, and other rules related to
handling the protocol entities defined by the code points
(henceforth called "specifications") must be adequately described
in an Internet-Draft.

c. The specifications of these code points must be stable; i.e., if
there is a change, implementations based on the earlier and later
specifications must be seamlessly interoperable.

If anyone believes that the draft does not meet these criteria or believes that 
early allocation is not appropriate for any other reason, please send an email 
to the PCE mailing list explaining why. If the chairs hear no objections by 
Monday, July 8th, we will kick off the early allocation request.

Note that there was an earlier allocation request where some codepoints were 
already allocated by IANA - 
https://mailarchive.ietf.org/arch/msg/pce/8jv4slxI_K3p4qqUPRlAjSgScOA/

Thanks!
Dhruv & Julien
--- Begin Message ---
A new version of Internet-Draft draft-ietf-pce-sid-algo-12.txt has been
successfully submitted by Samuel Sidor and posted to the
IETF repository.

Name: draft-ietf-pce-sid-algo
Revision: 12
Title:Carrying SR-Algorithm information in PCE-based Networks.
Date: 2024-07-23
Group:pce
Pages:22
URL:  https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-12.txt
Status:   https://datatracker.ietf.org/doc/draft-ietf-pce-sid-algo/
HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-pce-sid-algo
Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-sid-algo-12

Abstract:

   The SR-Algorithm associated with a Segment-ID (SID) defines the path
   computation algorithm used by Interior Gateway Protocols (IGPs).
   This information is available to controllers such as the Path
   Computation Element (PCE) via topology learning.  This document
   proposes an approach for informing headend routers regarding the SR-
   Algorithm associated with each SID used in PCE-computed paths, as
   well as signalling a specific SR-Algorithm as a constraint to the
   PCE.



The IETF Secretariat


--- End Message ---
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: WGLC for draft-ietf-pce-stateful-pce-vendor-03

[Samuel Sidor (ssidor)]

Hi WG,

Submitted updated version (attached mail). Please let me know if any specific 
comment was missed (Thanks for all comments received).

There is still separate mail thread for discussion about optimization for 
encoding of Vendor Information object, but so far it seems that if some change 
will be done, then it will be generic enhancement – applied to other PCEP 
objects as well, so out of scope of this draft.

Thanks a lot,
Samuel

From: Dhruv Dhody 
Sent: Tuesday, July 23, 2024 2:16 PM
To: pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-stateful-pce-ven...@ietf.org
Subject: Re: WGLC for draft-ietf-pce-stateful-pce-vendor-03

Hi WG,

The WGLC is closed. Thanks for everyone's comments and feedback.

The authors should update the draft based on the comment received and we will 
take the draft forward.

Thanks!
Dhruv & Julien


On Thu, Jul 4, 2024 at 6:17 AM Dhruv Dhody 
mailto:d...@dhruvdhody.com>> wrote:
Hi WG,

This email starts a 2-weeks working group last call for 
draft-ietf-pce-stateful-pce-vendor-03.

https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-vendor-03.html

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 Thursday 18 July 2024.

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

Thanks,
Dhruv & Julien
--- Begin Message ---
A new version of Internet-Draft draft-ietf-pce-stateful-pce-vendor-04.txt has
been successfully submitted by Samuel Sidor and posted to the
IETF repository.

Name: draft-ietf-pce-stateful-pce-vendor
Revision: 04
Title:Conveying Vendor-Specific Information in the Path Computation Element 
(PCE) Communication Protocol (PCEP) extensions for Stateful PCE.
Date: 2024-07-25
Group:pce
Pages:12
URL:  
https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-vendor-04.txt
Status:   https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-vendor/
HTML: 
https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-vendor-04.html
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-pce-vendor
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-stateful-pce-vendor-04

Abstract:

   A Stateful Path Computation Element (PCE) maintains information on
   the current network state, including computed Label Switched Path
   (LSPs), reserved resources within the network, and the pending path
   computation requests.  This information may then be considered when
   computing new traffic engineered LSPs, and for any associated and
   dependent LSPs, received from a Path Computation Client (PCC).

   RFC 7470 defines a facility to carry vendor-specific information in
   stateless Path Computation Element Communication Protocol (PCEP).

   This document extends this capability for the Stateful PCEP messages.



The IETF Secretariat


--- End Message ---
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: 答复: New draft to update IANA registration policy

[Samuel Sidor (ssidor)]

Hi Dhruv,

I support change itself.

One comment for note/question in the draft:

Question to the WG: The current document updates all
the registries. Should we keep "Standards Action" for
some of them such as flag fields with limited bits?

I’m personally not worried about that. We should be able to use same approach 
as used for LSP object flags.

One exception, which I can think of are fixed size objects, which may not be 
allowing TLVs currently (I’m not sure if there is any specific example in the 
list of registries). Do we have any specific plan for those?

Thanks,
Samuel

From: Aijun Wang 
Sent: Thursday, July 25, 2024 10:17 AM
To: 'Dhruv Dhody' ; pce@ietf.org
Subject: [Pce] 答复: New draft to update IANA registration policy

Hi, Dhruv:

Thanks for your quick draft. I think IETF review is enough because the required 
RFCs needs to be passed all the same stages
Although there maybe some different criteria, the related RFCs can assure the 
interoperability of protocol from different vendors.

The document is written clearly. If there is no objection, we can move it 
faster to be published.

Best Regards

Aijun Wang
China Telecom

发件人: forwardingalgori...@ietf.org 
[mailto:forwardingalgori...@ietf.org] 代表 Dhruv Dhody
发送时间: 2024年7月23日 5:19
收件人: pce@ietf.org
主题: [Pce] New draft to update IANA registration policy

Hi,

I have written a small draft to update the registration policy for all 
"standards action" to "IETF review" for PCEP registry.

https://datatracker.ietf.org/doc/draft-dhody-pce-iana-update/

The approach that the draft currently takes is to make a blanket change to 
IETF-review for all "standards action" registry to allow experimental track 
documents to request allocation. There are some registries where the space is 
tight but IMHO IETF-review is fine -- our WG and LC process should be enough to 
handle the case of less bits which ideally require creating a new 
field/registry as we did in the past for LSP object flags!

Thoughts?

It might be a good idea to move this quickly as John suggested in his AD review 
of Native-IP draft [1].

Thanks!
Dhruv

[1] https://mailarchive.ietf.org/arch/msg/pce/xBn2_9E9vy6h5AnYEMMf3I9vbqM/
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: 答复: New draft to update IANA registration policy

[Samuel Sidor (ssidor)]

Hi Dhruv,

Agreed – I know that some of them are already “IETF Review” – my question was 
mostly about future in general (not directly related to change introduced in 
this draft).

I was originally thinking about cases like flag field in Metric Object, but 
even in that case we have 16b reserved field, so no risk there.

Regards,
Samuel

From: Dhruv Dhody 
Sent: Thursday, July 25, 2024 2:50 PM
To: Samuel Sidor (ssidor) 
Cc: pce@ietf.org; Aijun Wang 
Subject: Re: [Pce] 答复: New draft to update IANA registration policy

Hi Samuel,

On Thu, Jul 25, 2024 at 1:28 AM Samuel Sidor (ssidor) 
mailto:ssi...@cisco.com>> wrote:
Hi Dhruv,

I support change itself.

One comment for note/question in the draft:

Question to the WG: The current document updates all
the registries. Should we keep "Standards Action" for
some of them such as flag fields with limited bits?

I’m personally not worried about that. We should be able to use same approach 
as used for LSP object flags.

One exception, which I can think of are fixed size objects, which may not be 
allowing TLVs currently (I’m not sure if there is any specific example in the 
list of registries). Do we have any specific plan for those?


I did a quick manual check. We mostly dont have this problem with one exception 
of flag fields in sub-objects.

Things to note -
- there are already some subobjects flag field that are IETF review
- some of these have reserved fields that can be easily used
- we could extend by creating a new sub-object type if needed

Thanks!
Dhruv


Thanks,
Samuel

From: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Sent: Thursday, July 25, 2024 10:17 AM
To: 'Dhruv Dhody' mailto:d...@dhruvdhody.com>>; 
pce@ietf.org<mailto:pce@ietf.org>
Subject: [Pce] 答复: New draft to update IANA registration policy

Hi, Dhruv:

Thanks for your quick draft. I think IETF review is enough because the required 
RFCs needs to be passed all the same stages
Although there maybe some different criteria, the related RFCs can assure the 
interoperability of protocol from different vendors.

The document is written clearly. If there is no objection, we can move it 
faster to be published.

Best Regards

Aijun Wang
China Telecom

发件人: forwardingalgori...@ietf.org<mailto:forwardingalgori...@ietf.org> 
[mailto:forwardingalgori...@ietf.org] 代表 Dhruv Dhody
发送时间: 2024年7月23日 5:19
收件人: pce@ietf.org<mailto:pce@ietf.org>
主题: [Pce] New draft to update IANA registration policy

Hi,

I have written a small draft to update the registration policy for all 
"standards action" to "IETF review" for PCEP registry.

https://datatracker.ietf.org/doc/draft-dhody-pce-iana-update/

The approach that the draft currently takes is to make a blanket change to 
IETF-review for all "standards action" registry to allow experimental track 
documents to request allocation. There are some registries where the space is 
tight but IMHO IETF-review is fine -- our WG and LC process should be enough to 
handle the case of less bits which ideally require creating a new 
field/registry as we did in the past for LSP object flags!

Thoughts?

It might be a good idea to move this quickly as John suggested in his AD review 
of Native-IP draft [1].

Thanks!
Dhruv

[1] https://mailarchive.ietf.org/arch/msg/pce/xBn2_9E9vy6h5AnYEMMf3I9vbqM/
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: Where the Controlled ID info shuold be carried/encoded?

[Samuel Sidor (ssidor)]

Hi all,

I’m fine with option 1 based on discussion which happened during presentation.

Does it make sense to explicitly mentioned in the draft that updating ranges 
dynamically was considered, but is considered out of scope and can be 
introduced later as separate draft if frequent range updates are needed?

Thanks,
Samuel

From: Dhruv Dhody 
Sent: Tuesday, July 30, 2024 11:46 AM
To: Andrew Stone (Nokia) 
Cc: Cheng Li ; pce@ietf.org; pce-chairs 
; Samuel Sidor (ssidor) 
Subject: Re: [Pce] Where the Controlled ID info shuold be carried/encoded?

Hi All,

During the IETF 120 discussion, the conclusion was to choose option 1, which 
involves continuing to use the Open message to encode the ID space controlled 
by the PCE. It was suggested that a generic Notification mechanism could be 
developed to update the parameters exchanged during the Open message, outside 
of this I-D.

Please respond here if you disagree with your reasoning.

Thanks!
Dhruv


On Tue, Jul 9, 2024 at 12:51 PM Andrew Stone (Nokia) 
mailto:andrew.st...@nokia.com>> wrote:
Hi all,

I like the PcOpen + PcNotify idea, mainly because I hope we can generically 
define a pattern of PcOpen content refresh without the need for a session flap. 
 Using PcOpen+PcNotify also becomes a bit more consistent in approach with the 
similar state synchronization proposal for add/delete PcOpen between PCE’s. I 
do not think we should add (even partial) dependency on PCEP-LS to solve that 
generalized problem. I also do not think we should overload PcRpt since the use 
of PcRpt is well understood to be about LSP state, and mucking with it to fit 
other content feels like it's being overloaded.

Therefore I think it comes down to a new message (PcOpenRefresh?) or leveraging 
PcNotify. I currently don't see a block on using PcNotify for this.

To keep it simple I think the TLVs in the PcNotify should be a snapshot equal 
to the same content as if this was PcOpen upon connect (i.e don't send diff).  
In other words as an example with draft-ietf-pce-controlled-id-space, if 
someone adds a new range to the PCC, the PcNotify would carry a 
LABEL-CONTROLS-SPACE-TLV which contains both existing and new ranges and not 
build in add/remove/diff semantics inside of the TLV itself.

Thanks
Andrew

From: Cheng Li 
mailto:40huawei@dmarc.ietf.org>>
Date: Tuesday, July 9, 2024 at 6:28 AM
To: Dhruv Dhody mailto:d...@dhruvdhody.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org> mailto:pce@ietf.org>>, 
pce-chairs mailto:pce-cha...@ietf.org>>, Samuel Sidor 
(ssidor) mailto:ssi...@cisco.com>>
Subject: RE: [Pce] Where the Controlled ID info shuold be carried/encoded?

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


Yes, I also think this combination is better.
Option 1 Open msg can be used for initial report, and the rest update can be 
reported by the Notification msg.

Already recorded this in the slide.

Cheng


From: Dhruv Dhody mailto:d...@dhruvdhody.com>>
Sent: Tuesday, July 9, 2024 11:34 AM
To: Cheng Li mailto:c...@huawei.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>; pce-chairs 
mailto:pce-cha...@ietf.org>>; Samuel Sidor (ssidor) 
mailto:ssi...@cisco.com>>
Subject: Re: [Pce] Where the Controlled ID info shuold be carried/encoded?

Hi,

Samuel made a suggestion to combine the options of using Open and Notification 
together, I have now captured that in the notes page - 
https://notes.ietf.org/draft-ietf-pce-controlled-id-space?view

Feel free to add to the discussion here or on the notes page.

Thanks!
Dhruv

On Sat, Jul 6, 2024 at 2:53 PM Dhruv Dhody 
mailto:d...@dhruvdhody.com>> wrote:
Hi Cheng,

To facilitate this discussion I have created a notes page - 
https://notes.ietf.org/draft-ietf-pce-controlled-id-space?view that documents 
the various options.

WG,

Feel free to add things there but add your name for easy tracking.
You can also add your preference for a solution and with reasoning at the 
bottom or simply reply on this thread and I can keep the notes page updated.

Hope the WG finds this useful and it helps in converging on a way forward...

Thanks!
Dhruv

On Thu, Jun 20, 2024 at 10:46 AM Cheng Li 
mailto:40huawei@dmarc.ietf.org>> wrote:
Hi Guys，

Thank you so much for your helpful review and comments of our draft 
draft-ietf-pce-controlled-id-space.
In the WG adoption, I can summarize our discussion into the below bullets, hope 
they are correct,

  1.  The draft is useful, and the mechanism defined in the draft is needed, we 
should work on it. (Thanks!)
  2.  We need to discuss the where the info should be carried in the PCEP. Open 
Object seems not so good ☹
  3.  TLV encoding should be updated to be more generic or let's avoid the 
generic description and define specific sub-TLVs as needed.

I see the reasons why we decid

[Pce] Re: Adoption Poll of draft-dhody-pce-iana-update

[Samuel Sidor (ssidor)]

Hi PCE WG,

I supported adoption of this draft.

Regards,
Samuel

From: Andrew Stone (Nokia) 
Sent: Tuesday, July 30, 2024 4:58 PM
To: julien.meu...@orange.com; pce@ietf.org
Subject: [Pce] Re: Adoption Poll of draft-dhody-pce-iana-update

Hi PCE WG,

It seems sensible to me to blanket the registries with this change. As 
mentioned during the IETF 120 session, and indicated in the document, the 
existing procedures with IETF review will still ensure that registries with 
small number of bits are still handled with care and concern.

Support adoption and progressing this administrative change through.

Thanks
Andrew

From: julien.meu...@orange.com 
mailto:julien.meu...@orange.com>>
Date: Tuesday, July 30, 2024 at 4:37 AM
To: pce@ietf.org mailto:pce@ietf.org>>
Subject: [Pce] Adoption Poll of draft-dhody-pce-iana-update
Hi all,

In his review of the "native IP" draft, John suggested to consider
adjusting to "IETF Review" the allocation policy of some of the PCEP
registries currently using "Standards Action". Dhruv has submitted
draft-dhody-pce-iana-update to quickly resolve this concern and bring
higher consistency among PCEP registries.

As a result, does the WG support the adoption of
draft-dhody-pce-iana-update [1] as a WG item? Please, share your
feedback using the PCE mailing list and include your rationale in case
you're opposed.

Thanks,

Julien


[1] 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dhody-pce-iana-update%2F&data=05%7C02%7Candrew.stone%40nokia.com%7C6c5b236f940647a56c2f08dcb072d92b%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638579254546743357%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=jXFzFnmqzO9g9A%2Bvj17o0rM3f651yv3lQVH5PxImvmI%3D&reserved=0


Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: Opsdir early review of draft-ietf-pce-stateful-pce-vendor-04

[Samuel Sidor (ssidor)]

Thanks a lot Xiao for review and comments.

We are discussing changes required to the draft with co-authors. We will get 
back to you soon.

Regards,
Samuel

-Original Message-
From: Xiao Min via Datatracker  
Sent: Tuesday, August 6, 2024 9:42 AM
To: ops-...@ietf.org
Cc: draft-ietf-pce-stateful-pce-vendor@ietf.org; pce@ietf.org
Subject: Opsdir early review of draft-ietf-pce-stateful-pce-vendor-04

Reviewer: Xiao Min
Review result: Has Issues

Summary: I've reviewed this document and I believe this document is on the 
right track. I have no major concern but several minor ones. Besides, there are 
a number of nits and ungrammatical sentences, I'm also not good at this, so 
just to name a few.

Major issues: None.

Minor issues: As below.
Section 2, it says "Different instances of the object can have different 
Enterprise Numbers". I believe a normative language is more suitable than 
*can*, MUST or MAY? It's supposed to be MAY. Section 3, my first feeling is 
that this section should list all Stateful PCEP objects in which the Vendor 
Information TLV may be contained, however after checking Section 3 of RFC 7470, 
I found it says "Further specifications are needed to define the position and 
meaning of the Vendor Information TLV for specific PCEP objects". Then I think 
this section should either define the Vendor Information TLV for each Stateful 
PCEP object or state something like what's said in Section 3 of RFC 7470.
Section 4.2, it says "Any standard YANG module will not include details of 
vendor-specific information", and then it provides  a suggestion on how the 
standard YANG module MAY be extended. I assume the mentioned extension applies 
only to a proprietary YANG module, if that's the case, then I don't see much 
value to mention the extension. Section 4.6, compared to what's said in Section
6.6 of RFC 7470, it seems what's said here is a little bit too simple.
Considering that multiple Vendor Information Objects/TLVs of multiple LSPs can 
be carried in the Stateful PCEP messages, it can be imagined that in some cases 
the amount of Vendor Information would become too huge to be processed by the 
receiver timely. In other words, some kind of congestion may happen due to the 
added Vendor Information. So it's helpful to the reader/implementer if some 
mitigation method can be provided here.

Nits/editorial comments: As below.
Abstract Section, s/may then be/may be then.
Section 1, s/(LSP-DB)/(LSP-DB)); s/added new messages in PCEP/add new messages 
to PCEP; s/[RFC7470] defined/[RFC7470] defines; s/It also defined/It also 
defines; s/to also include/to include. Section 2, s/be used on a single PCRpt 
message/be contained in a single PCRpt message. Section 3, SRP needs expansion 
in first use; s/All the procedures as per/All the procedures are as per; 
s/defines the Enterprise Numbers are allocated by IANA/defines the Enterprise 
Numbers allocated by IANA; s/clarifies that the IANA registry described 
is/clarifies that what the IANA registry describes is. Section 4.4, s/Verify 
Correct Operations/Verifying Correct Operations. Section 7, s/PCEP also 
support/PCEP also supports.


___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: Opsdir early review of draft-ietf-pce-stateful-pce-vendor-04

[Samuel Sidor (ssidor)]

Hi Xiao,

Would adding text like this at then end of section 4.6 address your remaining 
comments?

“Section 6.6 of RFC7470 describes congestion mitigation methods for a PCC for 
Stateless PCEP messages. A similar approach SHOULD be considered for Stateful 
PCEP messages and for a PCE.

Encoding optimization for the Vendor Information Object, for example, in case 
of the object with the same content encoded for multiple LSPs, is considered 
out of the scope of this document and may be proposed in the future as a 
separate document applicable to other PCEP objects.”

Would that work for you?

Thanks,
Samuel

From: xiao.m...@zte.com.cn 
Sent: Tuesday, August 13, 2024 9:38 AM
To: Samuel Sidor (ssidor) 
Cc: draft-ietf-pce-stateful-pce-vendor@ietf.org; pce@ietf.org; 
ops-...@ietf.org
Subject: Re: Opsdir early review of draft-ietf-pce-stateful-pce-vendor-04


Hi Samuel,



Thanks for the new version and the clear responses.

Please see inline.
Original
From: SamuelSidor(ssidor) mailto:ssi...@cisco.com>>
To: 肖敏10093570;
Cc: 
draft-ietf-pce-stateful-pce-vendor@ietf.org<mailto:draft-ietf-pce-stateful-pce-vendor@ietf.org>
 
mailto:draft-ietf-pce-stateful-pce-vendor@ietf.org>>;pce@ietf.org
 mailto:pce@ietf.org>>;ops-...@ietf.org 
mailto:ops-...@ietf.org>>;
Date: 2024年08月12日 15:41
Subject: RE: Opsdir early review of draft-ietf-pce-stateful-pce-vendor-04

Hi Xiao,



Sorry for delay, most of issues/comments should be fixed in attached version. 
Please see responses for remaining issues/comments:



Your comment:

" Section 3, my first feeling is that this section should list all Stateful 
PCEP objects in which the Vendor Information TLV may be contained, however 
after checking Section 3 of RFC 7470, I found it says "Further specifications 
are needed to define the position and meaning of the Vendor Information TLV for 
specific PCEP objects". Then I think this section should either define the 
Vendor Information TLV for each Stateful PCEP object or state something like 
what's said in Section 3 of RFC 7470"



Response:

This draft is only about carrying the  object in stateful 
PCEP messages, it does not make any changes to VENDOR-INFORMATION-TLV 
processing, where RFC 7470 continues to apply. The draft is even explicitly 
inheriting all rules from Section 3 of RFC 7470 (see: "All the procedures are 
as per section 3 of [RFC7470].")

[XM]>>> OK, that's fine.



Your comment:

" Section 4.6, compared to what's said in Section 6.6 of RFC 7470, it seems 
what's said here is a little bit too simple."



Response:

Based on Section 4 of this draft, all manageability requirements and 
considerations are inherited from RFC7470 (and from other RFCs), including that 
longer text from Section 6.6. Are you missing any specific recommendation?

[XM]>>> In Section 6.6 of RFC 7470, it seems that the provided mitigation 
method covers only the direction from PCC to PCE, then how about from PCE to 
PCC?



Your comment:

"Considering that multiple Vendor Information Objects/TLVs of multiple LSPs can 
be carried in the Stateful PCEP messages, it can be imagined that in some cases 
the amount of Vendor Information would become too huge to be processed by the 
receiver timely. In other words, some kind of congestion may happen due to the 
added Vendor Information. So it's helpful to the reader/implementer if some 
mitigation method can be provided here."



Response:

There is no change against RFC7470, where multiple requests with Vendor 
Information object could be also included in single PCReq message. Individual 
vendors are not exposing structure of their Vendor Information Objects, so it 
is not expected (or it will really rare) that some specific implementation will 
include Vendor Information Object from different vendor. Section 6.1 of RFC7470 
(which is inherited by this draft) is also proposing that inclusion of vendor 
specific information may be configurable, so it can be disabled if not really 
needed (e.g. if vendor of PCC and PCE are not same and including vendor 
specific information is useless). There was also recent discussion about 
potentially optimizing encoding of Vendor Information object, but conclusion 
seems to be that if any optimization needs to be done, then it should be 
generic optimization applicable to other PCEP objects, which is out of scope of 
this draft.

[XM]>>> Thank you for the detailed explanation. If appropriate, some text on 
potential out-of-scope optimization can be added here, it's up to you. :-)



Cheers,

Xiao Min



Thanks a lot,

Samuel

From: xiao.m...@zte.com.cn<mailto:xiao.m...@zte.com.cn> 
mailto:xiao.m...@zte.com.cn>>
Sent: Monday, August 12, 2024 8:51 AM
To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>
Cc: 
draft-ietf-pce-stateful-pce-vendor@ietf.org<mailto:draft-ietf-pce-stateful-pce-vendor@i

[Pce] Re: Opsdir early review of draft-ietf-pce-stateful-pce-vendor-04

[Samuel Sidor (ssidor)]

Thanks a lot Xiao for review and great comments.

Updated version submitted.

Regards,
Samuel

From: xiao.m...@zte.com.cn 
Sent: Wednesday, August 14, 2024 3:21 AM
To: Samuel Sidor (ssidor) 
Cc: draft-ietf-pce-stateful-pce-vendor@ietf.org; pce@ietf.org; 
ops-...@ietf.org
Subject: Re: Opsdir early review of draft-ietf-pce-stateful-pce-vendor-04


HI Samuel,

Yes, the new text you proposed looks good to me.

Thank you for addressing all my comments.



Cheers,

Xiao Min
Original
From: SamuelSidor(ssidor) mailto:ssi...@cisco.com>>
To: 肖敏10093570;
Cc: 
draft-ietf-pce-stateful-pce-vendor@ietf.org<mailto:draft-ietf-pce-stateful-pce-vendor@ietf.org>
 
mailto:draft-ietf-pce-stateful-pce-vendor@ietf.org>>;pce@ietf.org
 mailto:pce@ietf.org>>;ops-...@ietf.org 
mailto:ops-...@ietf.org>>;
Date: 2024年08月13日 19:40
Subject: RE: Opsdir early review of draft-ietf-pce-stateful-pce-vendor-04
Hi Xiao,

Would adding text like this at then end of section 4.6 address your remaining 
comments?

“Section 6.6 of RFC7470 describes congestion mitigation methods for a PCC for 
Stateless PCEP messages. A similar approach SHOULD be considered for Stateful 
PCEP messages and for a PCE.

Encoding optimization for the Vendor Information Object, for example, in case 
of the object with the same content encoded for multiple LSPs, is considered 
out of the scope of this document and may be proposed in the future as a 
separate document applicable to other PCEP objects.”

Would that work for you?

Thanks,
Samuel

From: xiao.m...@zte.com.cn<mailto:xiao.m...@zte.com.cn> 
mailto:xiao.m...@zte.com.cn>>
Sent: Tuesday, August 13, 2024 9:38 AM
To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>
Cc: 
draft-ietf-pce-stateful-pce-vendor@ietf.org<mailto:draft-ietf-pce-stateful-pce-vendor@ietf.org>;
 pce@ietf.org<mailto:pce@ietf.org>; ops-...@ietf.org<mailto:ops-...@ietf.org>
Subject: Re: Opsdir early review of draft-ietf-pce-stateful-pce-vendor-04


Hi Samuel,



Thanks for the new version and the clear responses.

Please see inline.
Original
From: SamuelSidor(ssidor) mailto:ssi...@cisco.com>>
To: 肖敏10093570;
Cc: 
draft-ietf-pce-stateful-pce-vendor@ietf.org<mailto:draft-ietf-pce-stateful-pce-vendor@ietf.org>
 
mailto:draft-ietf-pce-stateful-pce-vendor@ietf.org>>;pce@ietf.org
 mailto:pce@ietf.org>>;ops-...@ietf.org 
mailto:ops-...@ietf.org>>;
Date: 2024年08月12日 15:41
Subject: RE: Opsdir early review of draft-ietf-pce-stateful-pce-vendor-04

Hi Xiao,



Sorry for delay, most of issues/comments should be fixed in attached version. 
Please see responses for remaining issues/comments:



Your comment:

" Section 3, my first feeling is that this section should list all Stateful 
PCEP objects in which the Vendor Information TLV may be contained, however 
after checking Section 3 of RFC 7470, I found it says "Further specifications 
are needed to define the position and meaning of the Vendor Information TLV for 
specific PCEP objects". Then I think this section should either define the 
Vendor Information TLV for each Stateful PCEP object or state something like 
what's said in Section 3 of RFC 7470"



Response:

This draft is only about carrying the  object in stateful 
PCEP messages, it does not make any changes to VENDOR-INFORMATION-TLV 
processing, where RFC 7470 continues to apply. The draft is even explicitly 
inheriting all rules from Section 3 of RFC 7470 (see: "All the procedures are 
as per section 3 of [RFC7470].")

[XM]>>> OK, that's fine.



Your comment:

" Section 4.6, compared to what's said in Section 6.6 of RFC 7470, it seems 
what's said here is a little bit too simple."



Response:

Based on Section 4 of this draft, all manageability requirements and 
considerations are inherited from RFC7470 (and from other RFCs), including that 
longer text from Section 6.6. Are you missing any specific recommendation?

[XM]>>> In Section 6.6 of RFC 7470, it seems that the provided mitigation 
method covers only the direction from PCC to PCE, then how about from PCE to 
PCC?



Your comment:

"Considering that multiple Vendor Information Objects/TLVs of multiple LSPs can 
be carried in the Stateful PCEP messages, it can be imagined that in some cases 
the amount of Vendor Information would become too huge to be processed by the 
receiver timely. In other words, some kind of congestion may happen due to the 
added Vendor Information. So it's helpful to the reader/implementer if some 
mitigation method can be provided here."



Response:

There is no change against RFC7470, where multiple requests with Vendor 
Information object could be also included in single PCReq message. Individual 
vendors are not exposing structure of their Vendor Information Objects, so it 
is not expected (or it will really rare) that some specific implementati

[Pce] Re: Rtgdir early review of draft-ietf-pce-stateful-pce-vendor-05

[Samuel Sidor (ssidor)]

Just to keep mail thread updated - new version submitted based on comment from 
Mike.

Regards,
Samuel

-Original Message-
From: Samuel Sidor (ssidor)  
Sent: Monday, August 26, 2024 6:57 PM
To: Mike McBride 
Cc: draft-ietf-pce-stateful-pce-vendor@ietf.org; pce@ietf.org; 
rtg-...@ietf.org
Subject: RE: Rtgdir early review of draft-ietf-pce-stateful-pce-vendor-05

Hi Mike,

Thanks a lot for your review and for comment/suggestion raised. I agree that it 
is cleaner to move IANA related statement to IANA Considerations section, so I 
moved it and modified a bit (I would still prefer to keep reference to RFC9371 
as that contains direct location to PEN registry.

Can you please check if it is addressing your comment? I can submit it then.

Regards,
Samuel

-Original Message-
From: Mike McBride via Datatracker  
Sent: Tuesday, August 20, 2024 12:07 AM
To: rtg-...@ietf.org
Cc: draft-ietf-pce-stateful-pce-vendor@ietf.org; pce@ietf.org
Subject: Rtgdir early review of draft-ietf-pce-stateful-pce-vendor-05

Reviewer: Mike McBride
Review result: Ready

Succinct and well written draft. It's ready. My only suggestion is adding a 
little more into the iana considerations section. Something like:

"There are no IANA actions in this document, only a clarification. [RFC7470] 
defines the Enterprise Numbers allocated by IANA and managed through an IANA 
registry [RFC2578]. This document clarifies the Private Enterprise Numbers
(PEN) as described in the IANA registry."

And/or re-word the iana description up in section 3. That second sentence "This 
document further clarifies that what the IANA registry described is the Private 
Enterprise Numbers (PEN), in which registrations and the registration location 
are further described by [RFC9371]." is awkward to me. Would this say the same
thing?:

"This document clarifies the Private Enterprise Numbers (PEN), as described in 
the IANA registry. The registrations, and the registration location, are 
further described by [RFC9371]."



--- Begin Message ---
A new version of Internet-Draft draft-ietf-pce-stateful-pce-vendor-06.txt has
been successfully submitted by Samuel Sidor and posted to the
IETF repository.

Name: draft-ietf-pce-stateful-pce-vendor
Revision: 06
Title:Conveying Vendor-Specific Information in the Path Computation Element 
(PCE) Communication Protocol (PCEP) extensions for Stateful PCE.
Date: 2024-08-28
Group:pce
Pages:12
URL:  
https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-vendor-06.txt
Status:   https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-vendor/
HTML: 
https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-vendor-06.html
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-pce-vendor
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-stateful-pce-vendor-06

Abstract:

   A Stateful Path Computation Element (PCE) maintains information on
   the current network state, including computed Label Switched Path
   (LSPs), reserved resources within the network, and the pending path
   computation requests.  This information may then be considered when
   computing new traffic engineered LSPs, and for any associated and
   dependent LSPs, received from a Path Computation Client (PCC).

   RFC 7470 defines a facility to carry vendor-specific information in
   stateless Path Computation Element Communication Protocol (PCEP).

   This document extends this capability for the Stateful PCEP messages.



The IETF Secretariat


--- End Message ---
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: Opsdir early review of draft-ietf-pce-sid-algo-13

[Samuel Sidor (ssidor)]

Hi Nagendra,

Sorry for delayed response - I completely missed this mail somehow.

Please see my responses inline 

Thanks a lot,
Samuel

-Original Message-
From: Nagendra Nainar via Datatracker  
Sent: Thursday, August 22, 2024 7:56 PM
To: ops-...@ietf.org
Cc: draft-ietf-pce-sid-algo@ietf.org; pce@ietf.org
Subject: Opsdir early review of draft-ietf-pce-sid-algo-13

Reviewer: Nagendra Nainar
Review result: Has Issues

Hi,

I have reviewed this document as part of the Operational directorate's ongoing 
effort to review all IETF documents being processed by the IESG.  These 
comments were written with the intent of improving the operational aspects of 
the IETF drafts per guidelines in RFC5706.

Comments that are not addressed in last call may be included in AD reviews 
during the IESG review.  Document editors and WG chairs should treat these 
comments just like any other last call comments.

Overall Summary:

This draft is a standard track proposing the capability/metrics and machinery 
to include SR-Algo details in the PCEP protocol.

Based on my reading (version-13), there are a few gaps that needs to be 
clarified or addressed from the operational aspects. I am marking it as "Has 
issues" to get some clarification on the below:

  *  S (Strict): If set, the PCE MUST fail the path computation if
 specified SR-Algorithm constraint cannot be satisfied.  If
 unset, the PCE MAY ignore specified algorithm constraint.

 If the flag is unset, the intent is to completely ignore the 
algorithm or to try other algorithms if a path cannot be computed based on the 
mentioned algorithm?. If the intent is the former, it is equivalent to not 
include the TLV at all. If the intent is the latter, it is better to clarify 
that.

 It was supposed to be "...to try other algorithms if a path cannot be 
computed based on the mentioned algorithm.". Can you please confirm if 
extending existing section to following will work for you?

  *  S (Strict): If set, the PCE MUST fail the path computation if
 specified SR-Algorithm constraint cannot be satisfied.  If
 unset, the PCE SHOULD try to compute path with SR-algorithm
 constraint specified. If such computation is not successful, then
a path that that does not satisfy the specified SR-algorithm constraint
   can be computed.

   Algorithm:  SR-Algorithm the PCE MUST take into acount while
  computing a path for the LSP.

 This normative MUST appears to be contradicting with the earlier 
statement. I think that this is a MUST only if the S flag is set. Can this be 
rephrased to clarify?

 I can change to: " SR-Algorithm to be used during path computation.". As 
you mentioned, rules about using/not-using SR-algorithm constraint are already 
described in other places, so normative MUST is not required.

Section 4 describes when to (and when not to) use the machinery defined in 
section 3.2 to 3.5 based on the capability signaling. I think this section will 
also require to explain the implication of the new flag S on the other fields 
in the capability TLV. For example, a PCC with different topology may have 
different interfaces associated to SR-algo and so (possibly) different MSD.
This might be a less probable scenario but not unrealistic. What happens in 
such scenario?

 PCC is just advertising support for algo constraint and not support for 
individual algorithms (that still needs to be derived by PCE based on 
information already learned from IGP/BGP-LS (or other sources of topology). So 
if PCC/headend algo participation has changed or some new interfaces 
association with specific SR-algo are added to the topology, there is no impact 
on capabilities advertised. Please let me know if I'm missing anything specific.

The SR-Algorithm constraint acts as a filter, restricting which SIDs
   may be used as a result of the path computation function.  Path
   computation is done based on optimization metric type and constraints
   specified in PCEP message received from PCC.

 I am not sure I understand what this section/statement mean. Is this 
a restatement (or the outcome) of what is described in Section 4.2 and section 
4.2.1?.

 That section is just explaining difference between 2 modes specified in 
sections 4.2.1 and 4.2.2, which is picked based on F flag as described in 
section 3.4. 

If F flag is set, then Flex-algo path-computation is done, so for example 
optimization metric and constraints are retrieved from Flex-algo definition. If 
there is any optimization metric specified in PCRpt from PCC/headend, then that 
is ignored. (End-to-end path is optimized based on metric type from FAD) 

If F flag is unset (section 4.2.2), then PCE should compute path based on 
optimization metric specified in PCRpt and only restriction is to use SIDs of 
specified algo. (e.g. you can decide to compute end-to-end path, which is 
optimal from IGP metric, but which still consists of FA SIDs with FAD with 
latenc