[Pce] 答复: Zaheduzzaman Sarker's No Objection on draft-ietf-pce-pcep-extension-native-ip-35: (with COMMENT)

Aijun Wang <wangaijun@tsinghua.org.cn> Fri, 23 August 2024 06:12 UTC

Return-Path: <wangaijun@tsinghua.org.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 93EB2C180B46; Thu, 22 Aug 2024 23:12:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 Ara_xVJhsyCf; Thu, 22 Aug 2024 23:12:29 -0700 (PDT)
Received: from mail-m24105.xmail.ntesmail.com (mail-m24105.xmail.ntesmail.com [45.195.24.105]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F9BEC151093; Thu, 22 Aug 2024 23:12:25 -0700 (PDT)
Received: from LAPTOP09T7970K (unknown [219.142.69.76]) by smtp.qiye.163.com (Hmail) with ESMTPA id 45C517E019C; Fri, 23 Aug 2024 14:12:15 +0800 (CST)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
To: 'Zaheduzzaman Sarker' <zahed.sarker.ietf@gmail.com>, 'The IESG' <iesg@ietf.org>
References: <172432868221.2528543.4214302657052122349@dt-datatracker-6df4c9dcf5-t2x2k>
In-Reply-To: <172432868221.2528543.4214302657052122349@dt-datatracker-6df4c9dcf5-t2x2k>
Date: Fri, 23 Aug 2024 14:12:14 +0800
Message-ID: <007301daf523$667c17c0$33744740$@tsinghua.org.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKZJjlL277uq+5ZbvHYuQqvb6Jqn7C39J8A
Content-Language: zh-cn
X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFKTEtLSjdXWS1ZQUlXWQ8JGhUIEh9ZQVkaSx9DVhhNHhpJS0tCSR0YQ1YeHw5VEwETFh oSFyQUDg9ZV1kYEgtZQVlJSkJVSk9JVU1CVUxNWVdZFhoPEhUdFFlBWU9LSFVKS0lPT09IVUpLS1 VKQktLWQY+
X-HM-Tid: 0a917ddd37fd03a2kunm45c517e019c
X-HM-MType: 10
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6PC46CBw4DjIrOCNLAT8TAU1M Ak5PCQxVSlVKTElPSEJITkhNSktJVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxNWVdZCAFZQU5OS0I3Bg++
Message-ID-Hash: DJ5G76UOTGH4XYNP7O7Z6BZM5TQTT2UI
X-Message-ID-Hash: DJ5G76UOTGH4XYNP7O7Z6BZM5TQTT2UI
X-MailFrom: wangaijun@tsinghua.org.cn
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-pce.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-pce-pcep-extension-native-ip@ietf.org, pce-chairs@ietf.org, pce@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Pce] 答复: Zaheduzzaman Sarker's No Objection on draft-ietf-pce-pcep-extension-native-ip-35: (with COMMENT)
List-Id: Path Computation Element <pce.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/AumM8c8blz2-cd7NEwDfeVJ4zAs>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Owner: <mailto:pce-owner@ietf.org>
List-Post: <mailto:pce@ietf.org>
List-Subscribe: <mailto:pce-join@ietf.org>
List-Unsubscribe: <mailto:pce-leave@ietf.org>

Hi, Zaheduzzaman:

Thanks for your review and comments.
Some detailed responses are inline below.
If you agree or have other suggestions, please let me know. I will update the document accordingly later to reflect our consensus.


Best Regards

Aijun Wang
China Telecom


-----邮件原件-----
发件人: forwardingalgorithm@ietf.org [mailto:forwardingalgorithm@ietf.org] 代表 Zaheduzzaman Sarker via Datatracker
发送时间: 2024年8月22日 20:11
收件人: The IESG <iesg@ietf.org>
抄送: draft-ietf-pce-pcep-extension-native-ip@ietf.org; pce-chairs@ietf.org; pce@ietf.org
主题: [Pce] Zaheduzzaman Sarker's No Objection on draft-ietf-pce-pcep-extension-native-ip-35: (with COMMENT)

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-pce-pcep-extension-native-ip-35: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for working on this document. I have not comments from transport
protocol points of view.

I have following comment/question though -

 - In section 6.1 it says -

              "The PCInitiate message SHOULD be sent to PCC which is acting as
              BGP router and/or RR."

   In Section 6.2 it says -

              "The PCInitiate message SHOULD be sent to every router on the
              path."

   To me it seems like there is not way to bypass those SHOULDs and get the
   route and session establishment procedure done. If that understanding is
   correct then what are the exceptionsthiking about to let the implementers
   skip that part? Also, if this understand is not true, then I would expect
   this document to give warnings on the effects of skiping the PCInitiate
   messages.
【WAJ】:For “SHOULD” in section 6.1 that you mentioned, the original considerations are that such PCInitiate message may be sent to PCCs only(in no-RR scenario); or be sent to PCC and RR(in RR scenario). If we use MUST, it will be not appropriate for the no-RR scenario. Then, we select the word "SHOULD". Or we change the text as below:
"The PCInitiate message MUST be sent to PCCs which are acting as BGP peer routers and exchange routes directly, or MUST be sent to PCC and RR respectively when two PCCs exchange the routes via the RR" 

For "SHOULD" in section 6.2, actually there are some situations that such PCInitiate messages doesn't need to be sent to every router. For example, if the links between two router are not congest, it is not necessary to control the forward path explicitly via the PCIniitiate message that includes EPR objects. The traffic can depend solely on the default path that calculated by the IGP algorithm to forward the traffic. This is the reason that we use the word "SHOULD", instead of "MUST".

Should we add such explanation into the context then?



_______________________________________________
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-leave@ietf.org