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

[tom petch]

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.


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.

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


Thanks!
Dhruv


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

[tom petch]

Samuel

Thank you for the reply.  Dhruv made a similar response and I have responded to 
that.  I think that that response addresses the answers you give but let me 
know if there is something I hve not addressed.

Tom Petch


From: Samuel Sidor (ssidor) 
Sent: 10 January 2024 13:05
To: tom petch
Cc: pce@ietf.org; Samuel Sidor (ssidor)
Subject: RE: Any missed comments for draft-ietf-pce-sid-algo

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 
limit scope to Flexible Algorithms.

To summarize - changes

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

[Mike Koldychev (mkoldych)]

Hi Andrew,

Thanks for the feedback! Comments inline with .

Thanks,
Mike.

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

Hi PCE WG, Authors,

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

Thanks
Andrew



- Terminology section adjustment:

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

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


Good suggestion, thanks.



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

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

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


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

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



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


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


Hi WG,

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

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

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

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

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

Thanks,
Dhruv & Julien

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

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

[Mike Koldychev (mkoldych)]

Hi Samuel,

Thanks for the feedback! Comments inline with .

Thanks,
Mike.

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

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

Hi all,

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

A few minor comments:


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

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



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

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



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

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



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

Thanks, I’ll update that.



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

Thanks, I’ll fix that.


Thanks a lot,
Samuel

From: Pce mailto:pce-boun...@ietf.org>> On Behalf Of 
Dhruv Dhody
Sent: Monday, January 8, 2024 11:29 AM
To: pce@ietf.org
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 comments and nits are 
most welcome.

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

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

Thanks,
Dhruv & Julien

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

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

[Mike Koldychev (mkoldych)]

Hi Huaimo,

Thanks for the feedback! Comments inline with .

Thanks,
Mike.

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

Hi Everyone,

I read through the document and have the following comments.

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


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

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

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



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

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



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

Thanks, will fix.


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

Hi WG,

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

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

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

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

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

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

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

[Andrew Stone (Nokia)]

Hi Mike,

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

Thanks
Andrew

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

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

Hi Andrew,

Thanks for the feedback! Comments inline with .

Thanks,
Mike.

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

Hi PCE WG, Authors,

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

Thanks
Andrew



- Terminology section adjustment:

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

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


Good suggestion, thanks.



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

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

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


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

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



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


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


Hi WG,

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

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

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

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

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

Thanks,
Dhruv & Julien

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

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

[Zhenghaomian]

Hi WG,

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

Two minor comments as follow:


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

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



Best wishes,
Haomian

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

Hi WG,

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

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

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

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

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

Thanks,
Dhruv & Julien


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

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

[Gyan Mishra]

I support publication.

I have reviewed v12 and have a few minor comments.

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

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

New

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

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

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

Kind Regards



*Gyan Mishra*

*Network Solutions A**rchitect *

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



*M 301 502-1347*



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

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