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

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

Hi Andrew,

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

Thanks,
Mike.

From: Andrew Stone (Nokia) <[e-mail]>
Sent: Tuesday, January 9, 2024 2:05 PM
To: Dhruv Dhody <[e-mail]>; [e-mail]
Cc: pce-chairs <[e-mail]>; [e-mail]
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"

<MK>
Good suggestion, thanks.
</MK>


- 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. "

<MK>
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.
</MK>


From: Dhruv Dhody <[e-mail]<mailto:[e-mail]>>
Date: Monday, January 8, 2024 at 5:29 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: pce-chairs <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: WGLC for draft-ietf-pce-segment-routing-policy-cp-12
Resent-From: <[e-mail]<mailto:[e-mail]>>
Resent-To: <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>
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