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

peng.shaofu@zte.com.cn Fri, 01 March 2024 06:55 UTC

Return-Path: <peng.shaofu@zte.com.cn>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEC9C14F6A2; Thu, 29 Feb 2024 22:55:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.904
X-Spam-Level:
X-Spam-Status: No, score=-6.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyXtA0wwxjl4; Thu, 29 Feb 2024 22:55:38 -0800 (PST)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CA97C14F6A8; Thu, 29 Feb 2024 22:55:36 -0800 (PST)
Received: from mse-fl2.zte.com.cn (unknown [10.5.228.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4TmJkr0V8Pz8XrRK; Fri, 1 Mar 2024 14:55:32 +0800 (CST)
Received: from njb2app05.zte.com.cn ([10.55.22.121]) by mse-fl2.zte.com.cn with SMTP id 4216sqCR087544; Fri, 1 Mar 2024 14:55:18 +0800 (+08) (envelope-from peng.shaofu@zte.com.cn)
Received: from mapi (njb2app05[null]) by mapi (Zmail) with MAPI id mid201; Fri, 1 Mar 2024 14:55:20 +0800 (CST)
Date: Fri, 01 Mar 2024 14:55:20 +0800
X-Zmail-TransId: 2afd65e17bd8479-df1c9
X-Mailer: Zmail v1.0
Message-ID: <202403011455207237485@zte.com.cn>
In-Reply-To: <CAP7zK5ZumRwX5HN2EMx2A9EBePd=X1s6BLhZYVv7cE9Hy6cmAw@mail.gmail.com>
References: CAP7zK5ZumRwX5HN2EMx2A9EBePd=X1s6BLhZYVv7cE9Hy6cmAw@mail.gmail.com
Mime-Version: 1.0
From: peng.shaofu@zte.com.cn
To: dd@dhruvdhody.com
Cc: pce@ietf.org, pce-chairs@ietf.org, draft-ietf-pce-stateful-pce-optional@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 4216sqCR087544
X-Fangmail-Gw-Spam-Type: 0
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 65E17BE4.000/4TmJkr0V8Pz8XrRK
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/8SCL85sa4T_7nqKxJYoXVBZ-XA0>
Subject: Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Mar 2024 06:55:40 -0000

Hi Chairs, WG,

I have read this document and find it is useful and support its forwarding.
Please see some comments as below:

[1]
In section 3.1. STATEFUL-PCE-CAPABILITY TLV, it said that 

"When the PCEP session is established, a PCC sends an Open message with an OPEN object that contains the STATEFUL-PCE-CAPABILITY TLV, as defined in [RFC8231]."

This mislead us to understand it is after the session established. May change to

"During the PCEP initialization phase, ..."

or change to 
"When the TCP connection is established, ..."

[2]
In section 3.1. STATEFUL-PCE-CAPABILITY TLV, it said that 

"R (RELAX bit - TBD1): If set to 1 by a PCEP Speaker, the R flag indicates that the PCEP Speaker is willing to send and receive PCEP objects with the P and I flags in the PCEP common object header for the stateful PCE messages."

This sentence is not clear because the P and I flags fields are already included in the PCEP objects. May change to

"R (RELAX bit - TBD1): If set to 1 by a PCEP Speaker, the R flag indicates that the PCEP Speaker is willing to handle the P and I flags in the PCEP common object header for the stateful PCE messages."

[3]
For seciton 3.2.1. The PCRpt Message, it emphasizes that the P flag of mandatory object must be set. It may be more meaningful to provide guidance on the setting of the P flag for each object in intended-attribute-list and actual-attribute-list, that actually contain the constraints (e.g, bandwidth, metric) used for path computation .

[4]
In 3.3.1. The PCUpd Message, it said that

"Note that when a PCE is unable to find the path that meets all the constraints as per the PCEP Object that cannot be ignored (i.e. P flag is set), the PCUpd message MAY optionally include the PCEP Objects that caused the path computation to fail along with the with the empty ERO."

"with the" in this paragraph is repeated. 
Do you think that this paragraph should be moved to section 3.2.1 The PCRpt Message ? It seems actually to describe the procesing of P flag in PCRpt. If so, may changed to 

"Note that when a PCE is unable to find the path that meets all the constraints as per the PCEP Object (carried in PCRpt message) that cannot be ignored (i.e. P flag is set), the subsequent PCUpd message MAY optionally include the PCEP Objects that caused the path computation to fail along with the with the empty ERO."


[5]
In 3.3.2. The PCRpt Message, it said that

"Note that when a PCC is unable to setup the path that meets all the parameters as per the PCEP Object that cannot be ignored (i.e. P flag is set), the PCRpt message MAY optionally include the PCEP Objects that caused the path setup to fail along with the LSP-ERROR-CODE TLV [RFC8231] indicating the reason for the failure."

Dos this paragraph also be moved to section 3.2.2. The PCUpd Message and the PCInitiate Message ? It seems actually to describe the procesing of P flag in PCUpd. If so, may changed to 

"Note that when a PCC is unable to setup the path that meets all the parameters as per the PCEP Object (carried in PCUpd message) that cannot be ignored (i.e. P flag is set), the subsequent PCRpt message MAY optionally include the PCEP Objects that caused the path setup to fail along with the LSP-ERROR-CODE TLV [RFC8231] indicating the reason for the failure."

[6]
In section 3.4. Delegation, it said that

"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 and mark some object as a must to process even when the PCC had not set the P flag during delegation."

I think this statement conflicts with the previous section 3.2 (which gives the impression that it is actually an active state of PCE mode, which naturally includes delegation). But this paragraph makes P flag no longer obeyed by PCE, which is confusing. Maybe I misunderstood.


Regards,
PSF



Original


From: DhruvDhody <dd@dhruvdhody.com>
To: pce@ietf.org <pce@ietf.org>;
Cc: pce-chairs <pce-chairs@ietf.org>;draft-ietf-pce-stateful-pce-optional@ietf.org <draft-ietf-pce-stateful-pce-optional@ietf.org>;
Date: 2024年02月21日 17:33
Subject: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

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




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