Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

[Cheng Li <[e-mail]>]

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) <[e-mail]>
Sent: Tuesday, March 12, 2024 11:00 PM
To: [e-mail]
Cc: pce-chairs <[e-mail]>; [e-mail]; Dhruv Dhody <[e-mail]>
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 over all parameters including this relaxation.


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?
[Cheng] This can be changed to SHOULD -> "An implementation supporting this document SHOULD allow configuration of the capability..."


Thanks a lot,
Samuel

From: Pce <[e-mail]<mailto:[e-mail]>> On Behalf Of Dhruv Dhody
Sent: Wednesday, February 21, 2024 10:33 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-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