Return-Path: 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 7F47CC14F6BA for ; Thu, 22 Aug 2024 23:48:27 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dhruvdhody-com.20230601.gappssmtp.com 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 iJIrnFOoNlaO for ; Thu, 22 Aug 2024 23:48:26 -0700 (PDT) Received: from mail-oa1-x36.google.com (mail-oa1-x36.google.com [IPv6:2001:4860:4864:20::36]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0944C151075 for ; Thu, 22 Aug 2024 23:48:26 -0700 (PDT) Received: by mail-oa1-x36.google.com with SMTP id 586e51a60fabf-2702920904bso248299fac.0 for ; Thu, 22 Aug 2024 23:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dhruvdhody-com.20230601.gappssmtp.com; s=20230601; t=1724395705; x=1725000505; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=qEA2F7hIoQ8pZMNRIO/9QW/T94LRYwPCwwlDDkGFHzo=; b=QkZx8Zy1hRDd/sA/FJJTqZFayQnHOCqpm+fuzwQ3mYAeZjZIZ68fhQmcY0RqvhiZEA opLdX207gDXC/2cyAkprzz23x5jy26WuYRAP8COPIntVhhHqYnKfoaCs1TZBYLHf5dBO 9xUEYWN0gkU4d7IqCGgUkKds9WV93DA9ojbvVGRqFLLgjKmIlY6BuwlGMyM0lEYpiVeO H61TEzB1lk139mcZzWFF+u5+vkotPh3HJ45YYbPYyCHWcarxJEp+yW8y1oLZzIejRMvb 1hNKcEqvUmFCYQJswF/yqJ5wxfPcos2Zvksc78fbgeOViizOTMw2ciErBeekKY5Et196 QfBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724395705; x=1725000505; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qEA2F7hIoQ8pZMNRIO/9QW/T94LRYwPCwwlDDkGFHzo=; b=X/1hpvrneP15Z0nALgwk2B62m+V8v6fFDc9r4bvescTqpMPgQqbV9vjuuGWkZracqW R2u9JPs8L31Ed6/7jKNAFbphopP0IHkQ2jcFfcyCb0ct6fH54h/SADNfHdD/YZ9mJQpp THgwV//QUtMaFqX7r/BmTcnH7Jxd7GbxeHUVYIlM5TLpj3QGUcaK9dalNW6MfqurSkEx vYeE5O3VgqOU8OEkVSpbe55fMBAdq45r9IQxjkdTgKmNLy+g3NTwe3wz3pbIEjpLGBF6 Ug9FMe+h9DV5bKw3q+QjauY/D2vRWH1Nmwm94AybkzwVavLmKC0UKVt0K7bJk5aeG+Fo L2Uw== X-Forwarded-Encrypted: i=1; AJvYcCUOwACmuqbHCg93jx4kqda59bPq17arvVRMi/Crx/j0h+67qTl8VD/xNzWSpgrbXf9bscA=@ietf.org X-Gm-Message-State: AOJu0YzSGIL+Ppy8Fm5DIJbao5fp/mOdxdSLrkBbXcm92TqdVf4vnyZY kznF6xvDuIhINHRuS8K0ZMiw8bDkSmmonuO34OmwNvlKq17AQplYnasxSG8BrswaKyeABAAvPCi EblYLhwhlImhheKzSmkRRSE/6b6SsiJsNlS3Dbw== X-Google-Smtp-Source: AGHT+IFciUu0I3sd986pzPJROrgAlNBlajjOr66SBQODrTDmIAQO9bLv8I6kxqrjabMv5cOtaF91aZXOquHNsgfNUNk= X-Received: by 2002:a05:6870:9a20:b0:270:184b:cce1 with SMTP id 586e51a60fabf-273e6699125mr694075fac.5.1724395705198; Thu, 22 Aug 2024 23:48:25 -0700 (PDT) MIME-Version: 1.0 References: <172432868221.2528543.4214302657052122349@dt-datatracker-6df4c9dcf5-t2x2k> <007301daf523$667c17c0$33744740$@tsinghua.org.cn> In-Reply-To: <007301daf523$667c17c0$33744740$@tsinghua.org.cn> From: Dhruv Dhody Date: Fri, 23 Aug 2024 12:17:49 +0530 Message-ID: To: Aijun Wang Content-Type: multipart/alternative; boundary="0000000000007604c706205429f1" Message-ID-Hash: 6EQFYA3DXJKQEHKMIMXASBXAJEVEDFW4 X-Message-ID-Hash: 6EQFYA3DXJKQEHKMIMXASBXAJEVEDFW4 X-MailFrom: dd@dhruvdhody.com 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: Zaheduzzaman Sarker , The IESG , 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: =?utf-8?q?=5BPce=5D_Re=3A_Zaheduzzaman_Sarker=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-pce-pcep-extension-native-ip-35=3A_=28with_COMMENT=29?= List-Id: Path Computation Element Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000007604c706205429f1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Aijun, Zahed, On Fri, Aug 23, 2024 at 11:42=E2=80=AFAM Aijun Wang wrote: > 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:forward= ingalgorithm@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 > =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 t= he > path." > > To me it seems like there is not way to bypass those SHOULDs and get t= he > 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 PCInitiat= e > 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 wo= rd > "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" > > Dhruv: Note that all routers including RR are acting as PCC. The use of "PCC and RR" gives an impression that RR is not a PCC. IMHO the use of normative text in this section is not helping. In version -34 this was lowercase should. My suggestion would be to change this to - "The PCInitiate message is sent to the BGP router and/or RR (which are acting as PCC)." > 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". > > This could be changed to - "For the purpose of explicit route addition, the PCInitiate message ought to be sent to every router on the explicit path." Do folks agree with this text change instead? Regards, Dhruv > 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 > > --0000000000007604c706205429f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Aijun, = Zahed,

On Fri, Aug 23, 2024 at 11= :42=E2=80=AFAM Aijun Wang <= wangaijun@tsinghua.org.cn> wrote:
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 t= he 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@iet= f.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-chai= rs@ietf.org; pce@ietf= .org
=E4=B8=BB=E9=A2=98: [Pce] Zaheduzzaman Sarker's No Objection on draft-i= etf-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 introduc= tory 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.or= g/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 -

=C2=A0- In section 6.1 it says -

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "The PCInitiate messa= ge SHOULD be sent to PCC which is acting as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BGP router and/or RR."= ;

=C2=A0 =C2=A0In Section 6.2 it says -

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "The PCInitiate messa= ge SHOULD be sent to every router on the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 path."

=C2=A0 =C2=A0To me it seems like there is not way to bypass those SHOULDs a= nd get the
=C2=A0 =C2=A0route and session establishment procedure done. If that unders= tanding is
=C2=A0 =C2=A0correct then what are the exceptionsthiking about to let the i= mplementers
=C2=A0 =C2=A0skip that part? Also, if this understand is not true, then I w= ould expect
=C2=A0 =C2=A0this document to give warnings on the effects of skiping the P= CInitiate
=C2=A0 =C2=A0messages.
=E3=80=90WAJ=E3=80=91=EF=BC=9AFor =E2=80=9CSHOULD=E2=80=9D in section 6.1 t= hat you mentioned, the original considerations are that such PCInitiate mes= sage 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 s= cenario. 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 p= eer routers and exchange routes directly, or MUST be sent to PCC and RR res= pectively when two PCCs exchange the routes via the RR"


Dhruv: = Note that all routers including RR are acting as PCC. The use of "PCC = and RR" gives an impression that RR is not a PCC.

IMHO the use of no= rmative text in this section is not helping. In version -34 this was lowerc= ase should.

My suggestion would be to change this to -=C2=A0=C2=A0
<= div class=3D"gmail_default" style=3D"font-family:"trebuchet ms",s= ans-serif;color:rgb(7,55,99)">
"The PCIni= tiate message is sent to the=C2=A0BGP=C2=A0router and/or RR (which are acti= ng as PCC)."=C2=A0

=C2=A0
For "SHOULD" in section 6.2, actually there are some situations t= hat such PCInitiate messages doesn't need to be sent to every router. F= or example, if the links between two router are not congest, it is not nece= ssary to control the forward path explicitly via the PCIniitiate message th= at 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 re= ason that we use the word "SHOULD", instead of "MUST".<= br>

This co= uld be changed to -=C2=A0

"For the purpose of=C2=A0explicit route=C2=A0addition,= the PCInitiate message ought to be sent to every router on the explicit pa= th."

Do folks agree with this text change instead?=C2=A0<= /div>

Dhruv


=C2=A0
Should we add such explanation into the context then?



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

--0000000000007604c706205429f1--