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
Thread-Index: AQKZJjlL277uq+5ZbvHYuQqvb6Jqn7C39J8A
Content-Language: zh-cn
Message-ID-Hash: DJ5G76UOTGH4XYNP7O7Z6BZM5TQTT2UI
CC: draft-ietf-pce-pcep-extension-native-ip@ietf.org, pce-chairs@ietf.org,
 pce@ietf.org
Precedence: list
Subject: =?utf-8?q?=5BPce=5D_=E7=AD=94=E5=A4=8D=3A_Zaheduzzaman_Sarker=27s_No_Objecti?=
	=?utf-8?q?on_on_draft-ietf-pce-pcep-extension-native-ip-35=3A_=28with_COMME?=
	=?utf-8?q?NT=29?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/pce/AumM8c8blz2-cd7NEwDfeVJ4zAs>

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


-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: forwardingalgorithm@ietf.org =
[mailto:forwardingalgorithm@ietf.org] =E4=BB=A3=E8=A1=A8 Zaheduzzaman =
Sarker via Datatracker
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2024=E5=B9=B48=E6=9C=8822=E6=97=A5 =
20:11
=E6=94=B6=E4=BB=B6=E4=BA=BA: The IESG <iesg@ietf.org>
=E6=8A=84=E9=80=81: draft-ietf-pce-pcep-extension-native-ip@ietf.org; =
pce-chairs@ietf.org; pce@ietf.org
=E4=B8=BB=E9=A2=98: [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-positio=
ns/
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.
=E3=80=90WAJ=E3=80=91=EF=BC=9AFor =E2=80=9CSHOULD=E2=80=9D 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"=20

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