Re: [RTG-DIR] [Pce] Routing directorate early review of draft-ietf-pce-lsp-extended-flags
xiong.quan@zte.com.cn Fri, 09 September 2022 07:14 UTC
Return-Path: <xiong.quan@zte.com.cn>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65589C14CF05; Fri, 9 Sep 2022 00:14:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.905
X-Spam-Level:
X-Spam-Status: No, score=-6.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 JUl9vFMIPGAc; Fri, 9 Sep 2022 00:14:09 -0700 (PDT)
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 979EAC14CF01; Fri, 9 Sep 2022 00:14:07 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.251.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4MP6g20Rbzz8R03d; Fri, 9 Sep 2022 15:14:06 +0800 (CST)
Received: from mse-fl1.zte.com.cn (unknown [10.5.228.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxct.zte.com.cn (FangMail) with ESMTPS id 4MP6fR6xc5z4xq1l; Fri, 9 Sep 2022 15:13:35 +0800 (CST)
Received: from njxapp02.zte.com.cn ([10.41.132.201]) by mse-fl1.zte.com.cn with SMTP id 2897DLgP004920; Fri, 9 Sep 2022 15:13:21 +0800 (GMT-8) (envelope-from xiong.quan@zte.com.cn)
Received: from mapi (njxapp05[null]) by mapi (Zmail) with MAPI id mid201; Fri, 9 Sep 2022 15:13:21 +0800 (CST)
Date: Fri, 09 Sep 2022 15:13:21 +0800
X-Zmail-TransId: 2afd631ae791ffffffffce81f774
X-Mailer: Zmail v1.0
Message-ID: <202209091513210865386@zte.com.cn>
Mime-Version: 1.0
From: xiong.quan@zte.com.cn
To: jonhardwick@microsoft.com
Cc: pce-chairs@ietf.org, draft-ietf-pce-lsp-extended-flags.all@ietf.org, rtg-dir@ietf.org, pce@ietf.org
Content-Type: text/plain; charset="UTF-8"
X-MAIL: mse-fl1.zte.com.cn 2897DLgP004920
X-Fangmail-Gw-Spam-Type: 0
X-FangMail-Miltered: at cgslv5.04-192.168.250.137.novalocal with ID 631AE7BE.000 by FangMail milter!
X-FangMail-Envelope: 1662707646/4MP6g20Rbzz8R03d/631AE7BE.000/192.168.251.13/[192.168.251.13]/mxct.zte.com.cn/<xiong.quan@zte.com.cn>
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 631AE7BE.000/4MP6g20Rbzz8R03d
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/OuDYSZi4UoAswkRbQ4q1Hmq5r4I>
Subject: Re: [RTG-DIR] [Pce] Routing directorate early review of draft-ietf-pce-lsp-extended-flags
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Sep 2022 07:14:10 -0000
Hi Jon and chairs, Thanks for your review and comments! I will update a new version to modify the first text of Section 3.2 shown as following: "The LSP Extended Flags field is an array of units of 32 flags and to be allocated starting from the most significant bit. The bits of the LSP Extended Flags field will be assigned by future documents. This document does not define any flags. Unassigned flags MUST be set to zero on transmission and MUST be ignored on receipt. Implementations that do not understand any particular flag MUST ignore the flag. This flags should follow the specification as per RFC8786." What is your suggestion? Best Regards, Quan <<[Pce] Routing directorate early review of draft-ietf-pce-lsp-extended-flags Jon Hardwick <jonhardwick@microsoft.com> Thu, 08 September 2022 15:08 UTCShow header Hi there I have been selected to do a routing directorate "early" review of this draft. draft-ietf-pce-lsp-extended-flags-03 - Label Switched Path (LSP) Object Flag Extension of Stateful PCE<https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-extended-flags/03/>The routing directorate will, on request from the working group chair, perform an "early" review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft's lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached. As this document is already post working group last call, my focus for the review was to determine whether the document is ready to be published. For more information about the routing area directorate, please see RtgDir - Routing Area Wiki (ietf.org)<https://trac.ietf.org/trac/rtg/wiki/RtgDir>ir>. Summary I have some minor concerns about this document that I think should be resolved be fore the publication process begins. Comments Section 3.2 Please could you add explicit statements that unused flags should be set to zero on sending and ignored on receipt? I know we have RFC 8786 which covers this, but I think it does no harm to say it explicitly anyway. Probably worth adding a normative reference to RFC 8786 as well. Section 5.1.2 Please note in the instructions to IANA that bits 0-31 should initially be marked as "Unassigned" and that bits with a higher ordinal than 31 will be added to the registry in future documents if necessary.