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

["Mike Koldychev (mkoldych)" <[e-mail]>]

Hi Samuel,

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

Thanks,
Mike.

From: Samuel Sidor (ssidor) <[e-mail]>
Sent: Friday, January 12, 2024 3:37 AM
To: Mike Koldychev (mkoldych) <[e-mail]>; [e-mail]
Cc: pce-chairs <[e-mail]>; [e-mail]; Dhruv Dhody <[e-mail]>
Subject: RE: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Thanks Mike,

Agreed. Just one response to capability part:

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

Regards,
Samuel

From: Mike Koldychev (mkoldych) <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, January 11, 2024 7:22 PM
To: Samuel Sidor (ssidor) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: pce-chairs <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Dhruv Dhody <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi Samuel,

Thanks for the feedback! Comments inline with <MK></MK>.

Thanks,
Mike.

From: Samuel Sidor (ssidor) <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, January 10, 2024 4:25 AM
To: [e-mail]<mailto:[e-mail]>
Cc: pce-chairs <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Dhruv Dhody <[e-mail]<mailto:[e-mail]>>
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?
<MK>
Yes they are, I will add that statement to Section 5 as well, thanks.
</MK>


  *   “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)?
<MK>
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.
</MK>


  *   “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?
<MK>
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.
</MK>


  *   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.
<MK>
Thanks, I’ll update that.
</MK>


  *   “SR-POLICY-CAPABLITY” -> “SR-POLICY-CAPABILITY” in section 5.1 (typo)
<MK>
Thanks, I’ll fix that.
</MK>

Thanks a lot,
Samuel

From: Pce <[e-mail]<mailto:[e-mail]>> On Behalf Of Dhruv Dhody
Sent: Monday, January 8, 2024 11:29 AM
To: [e-mail]<mailto:[e-mail]>
Cc: pce-chairs <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
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