Re: [Pce] IPR poll for draft-ietf-pce-segment-routing-policy-cp

[Hooman Bidgoli (Nokia)]

Hello

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

Thanks
Hooman
From: Andrew Stone (Nokia) 
Sent: Monday, January 8, 2024 1:28 PM
To: pce@ietf.org; draft-ietf-pce-segment-routing-policy...@ietf.org; Mike 
Koldychev (mkoldych) ; Sivabalan, Siva 
; cba...@juniper.net; pengshup...@huawei.com; Hooman 
Bidgoli (Nokia) ; Dhruv Dhody ; 
chengl...@huawei.com; Samuel Sidor (ssidor) 
Cc: pce-cha...@ietf.org
Subject: IPR poll for draft-ietf-pce-segment-routing-policy-cp

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
https://www.ietf.org/mailman/listinfo/pce

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

[tom petch]

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 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 regist

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 previous response, I confirmed that I should add explicit reference 
to registry itself. I originally added refere

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

[tom petch]

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 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, whic

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
Cc: pce-chairs mailto:pce-cha...@ietf.org>>; 
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
Cc: pce-chairs mailto:pce-cha...@ietf.org>>; 
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 comme