Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

[Dhruv Dhody]

Hi WG,

This WGLC has ended. Thanks to all those who responded and provided feedback.

The authors have published a new version (-22). Those who provided
substantial comments (such as Tom Petch), please check if your
comments are handled.

Thanks
Dhruv & Julien


On Wed, May 17, 2023 at 3:45 AM Dhruv Dhody  wrote:

> Hi WG,
>
> This email starts a 2-weeks working group last call for
> draft-ietf-pce-pcep-extension-native-ip-20 [1].
>
> 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 31st May 2023. We will also notify the
> IDR WG about this WGLC.
>
> A general reminder to the WG to be more vocal during the
> last-call/adoption and help us unclog our queues :)
>
> Thanks,
> Dhruv & Julien
>
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

[linchangwang]

Hi WG,

I have read the draft and I think that it is ready for WGLC.
I support the WGLC.
It is useful for PCEP extensions to set up TE paths in native IP networks.


Best Regards,
Changwang

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody
Sent: Tuesday, May 16, 2023 11:16 PM
To: pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-pcep-extension-native...@ietf.org
Subject: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

Hi WG,

This email starts a 2-weeks working group last call for 
draft-ietf-pce-pcep-extension-native-ip-20 [1].

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 31st May 2023. We will also notify the IDR WG 
about this WGLC.

A general reminder to the WG to be more vocal during the last-call/adoption and 
help us unclog our queues :)

Thanks,
Dhruv & Julien

[1] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/
-
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from New H3C, 
which is
intended only for the person or entity whose address is listed above. Any use 
of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender
by phone or email immediately and delete it!
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

[Aijun Wang]

Hi, Quan:

Thanks for your support and suggestions!

I have already updated the reference to RFC9050 as your suggestion.

Regarding to the recommendation of second point, if it will not arise again the 
obscure of its meaning, keeping it simple will be better.

If there is no more argument for this simplification, we will update document 
later accordingly.

Aijun Wang
China Telecom

> On May 31, 2023, at 11:15, xiong.q...@zte.com.cn wrote:
> 
> Dear Chairs and WG,
> 
> I have read the new version and I support the WGLC.
> Some editorial suggestions are as following shown.
> In section 5.1, "Where:   is as per   
> [I-D.ietf-pce-pcep-extension-for-pce-controller]." It may update to RFC9050.
> In section 5.1, "Further only one  and one kind of BPI, EPR, or PPA object 
> MUST be present." It is a little confused. Maybe that can be changed to "One 
> BPI, EPR, or PPA object MUST be present and others should be ignored."
> 
> Best Regards,
> Quan
> 
> 
> 
> 
> <<[Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20
> < Tue, 16 May 2023 22:16 UTCShow header
> Hi WG, This email starts a 2-weeks working group last call for 
> draft-ietf-pce-pcep-extension-native-ip-20 [1]. 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 31st May 2023. We will also notify the IDR WG about this 
> WGLC. A general reminder to the WG to be more vocal during the 
> last-call/adoption and help us unclog our queues :) Thanks, Dhruv & Julien 
> [1]https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/
> 
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce

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

Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

[Pengshuping (Peng Shuping)]

Hi,

I read through the document and I think that it is ready for WGLC.
I support the WGLC.

Best Regards,
Shuping

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody
Sent: Tuesday, May 16, 2023 11:16 PM
To: pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-pcep-extension-native...@ietf.org
Subject: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

Hi WG,

This email starts a 2-weeks working group last call for 
draft-ietf-pce-pcep-extension-native-ip-20 [1].

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 31st May 2023. We will also notify the IDR WG 
about this WGLC.

A general reminder to the WG to be more vocal during the last-call/adoption and 
help us unclog our queues :)

Thanks,
Dhruv & Julien

[1] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

[xiong.quan]

Dear Chairs and WG,

I have read the new version and I support the WGLC.
Some editorial suggestions are as following shown.
In section 5.1, "Where:   is as per   
[I-D.ietf-pce-pcep-extension-for-pce-controller]." It may update to RFC9050.
In section 5.1, "Further only one  and one kind of BPI, EPR, or PPA object MUST 
be present." It is a little confused. Maybe that can be changed to "One BPI, 
EPR, or PPA object MUST be present and others should be ignored."

Best Regards,
Quan




<<[Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20
< Tue, 16 May 2023 22:16 UTCShow header
Hi WG, This email starts a 2-weeks working group last call for 
draft-ietf-pce-pcep-extension-native-ip-20 [1]. 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 31st May 2023. We will also notify the IDR WG about this WGLC. 
A general reminder to the WG to be more vocal during the last-call/adoption and 
help us unclog our queues :) Thanks, Dhruv & Julien 
[1]https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/

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

Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

[Mengxiao.Chen]

I support the WGLC.
I read through the latest version of this document and I think it is useful to 
TE in native IP networks.

Thanks,
Mengxiao

From: Pce mailto:pce-boun...@ietf.org>> On Behalf Of 
Dhruv Dhody
Sent: Wednesday, May 17, 2023 6:16 AM
To: pce@ietf.org
Cc: pce-chairs mailto:pce-cha...@ietf.org>>; 
draft-ietf-pce-pcep-extension-native...@ietf.org
Subject: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

Hi WG,

This email starts a 2-weeks working group last call for 
draft-ietf-pce-pcep-extension-native-ip-20 [1].

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 31st May 2023. We will also notify the IDR WG 
about this WGLC.

A general reminder to the WG to be more vocal during the last-call/adoption and 
help us unclog our queues :)

Thanks,
Dhruv & Julien

[1] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/
-
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from New H3C, 
which is
intended only for the person or entity whose address is listed above. Any use 
of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender
by phone or email immediately and delete it!
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

[chen.ran]

Hi WG,







I have read the draft. I think it should be moved forward.






Best Regards,


Ran


-


From: Pce  On Behalf Of Dhruv DhodySent: Wednesday, May 
17, 2023 6:16 AMTo: pce@ietf.orgCc: pce-chairs ; 
draft-ietf-pce-pcep-extension-native-ip@ietf.orgSubject: [Pce] WGLC for 
draft-ietf-pce-pcep-extension-native-ip-20


 


Hi WG,This email starts a 2-weeks working group last call for 
draft-ietf-pce-pcep-extension-native-ip-20 [1].  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 31st May 2023. We will also notify the IDR WG about this 
WGLC.A general reminder to the WG to be more vocal during the 
last-call/adoption and help us unclog our queues :)  Thanks,Dhruv & Julien[1] 
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

[Boris Khasanov]

Hi Dhruv and all, I read the last -21 version and support the publication of this draft as co-author.It describes another option for practical implementation of PCECC architecture in Native IP networks. Obviously a lot of work ahead but  we need a basement: PCEP extensions and procedures to get it done. SY,Boris 17.05.2023, 01:16, "Dhruv Dhody" :Hi WG,This email starts a 2-weeks working group last call for draft-ietf-pce-pcep-extension-native-ip-20 [1].  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 31st May 2023. We will also notify the IDR WG about this WGLC.A general reminder to the WG to be more vocal during the last-call/adoption and help us unclog our queues :)  Thanks,Dhruv & Julien[1] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/,___Pce mailing listPce@ietf.orghttps://www.ietf.org/mailman/listinfo/pce___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

[Qiuyuanxiang]

Hi, All,
I have read the latest version of this draft 
[draft-ietf-pce-pcep-extension-native-ip-21].  I support it.
Based on the PCEP extension defined in the draft, E2E traffic assurance in 
native IP networks can be achieved under central control mode.

  Best Regards,
  Yuanxiang

From: Pce  On Behalf Of Dhruv Dhody
Sent: Wednesday, May 17, 2023 6:16 AM
To: pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-pcep-extension-native...@ietf.org
Subject: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

Hi WG,

This email starts a 2-weeks working group last call for 
draft-ietf-pce-pcep-extension-native-ip-20 [1].

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 31st May 2023. We will also notify the IDR WG 
about this WGLC.

A general reminder to the WG to be more vocal during the last-call/adoption and 
help us unclog our queues :)

Thanks,
Dhruv & Julien

[1] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/
-
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from New H3C, 
which is
intended only for the person or entity whose address is listed above. Any use 
of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender
by phone or email immediately and delete it!
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

[Aijun Wang]

Hi, Zhenqiang:Thanks for your support.Before we proposed and designed the solution that described in https://datatracker.ietf.org/doc/html/rfc8821, and also the PCEP extension that described this WGLC document, we have analyzed the characteristics and challenges of SRv6 based solutions.As indicated in https://datatracker.ietf.org/doc/html/rfc8821#name-introduction, we are trying to find the solution that can meet the following requirements:Same solution for native IPv4 and IPv6 traffic.Support for intra-domain and inter-domain scenarios.Achieve E2E traffic assurance, with determined QoS behavior, for traffic requiring a service assurance (prioritized traffic).No changes in a router's forwarding behavior.Based on centralized control through a distributed network control plane.Support different network requirements such as high traffic volume and prefix scaling.Ability to adjust the optimal path dynamically upon the changes of network status. No need for reserving resources for physical links in advance.Aijun WangChina TelecomOn May 29, 2023, at 10:19, li_zhenqi...@hotmail.com wrote:

Hi All,I support it, I have read the latest version and it is ready for publication in my opinion. Scenarios to be addressed is described in RFC8735. Based on the progress of SRv6, I think SRv6 is an alternative solution.

Best Regards,Zhenqiang Lili_zhenqi...@hotmail.com
 From: Dhruv DhodyDate: 2023-05-17 06:15To: pceCC: pce-chairs; draft-ietf-pce-pcep-extension-native-ipSubject: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20Hi WG, This email starts a 2-weeks working group last call for draft-ietf-pce-pcep-extension-native-ip-20 [1].  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 31st May 2023. We will also notify the IDR WG about this WGLC.A general reminder to the WG to be more vocal during the last-call/adoption and help us unclog our queues :)  Thanks,Dhruv & Julien[1] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/

___Pce mailing listPce@ietf.orghttps://www.ietf.org/mailman/listinfo/pce___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

[li_zhenqi...@hotmail.com]

Hi All,

I support it, I have read the latest version and it is ready for publication in 
my opinion. Scenarios to be addressed is described in RFC8735. Based on the 
progress of SRv6, I think SRv6 is an alternative solution.



Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com
 
From: Dhruv Dhody
Date: 2023-05-17 06:15
To: pce
CC: pce-chairs; draft-ietf-pce-pcep-extension-native-ip
Subject: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20
Hi WG, 

This email starts a 2-weeks working group last call for 
draft-ietf-pce-pcep-extension-native-ip-20 [1].  

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 31st May 2023. We will also notify the IDR WG 
about this WGLC.

A general reminder to the WG to be more vocal during the last-call/adoption and 
help us unclog our queues :)  

Thanks,
Dhruv & Julien

[1] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

[Huaimo Chen]

Hi Everyone,

I read through the document and support its WGLC.
The document specifies the PCEP extensions to set up TE paths in native IP 
networks and to provide information/parameters for creating BGP sessions and 
advertising prefixes. It is useful and ready.

Best Regards,
Huaimo

From: Pce  on behalf of Dhruv Dhody 
Sent: Tuesday, May 16, 2023 6:15 PM
To: pce@ietf.org 
Cc: pce-chairs ; 
draft-ietf-pce-pcep-extension-native...@ietf.org 

Subject: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

Hi WG,

This email starts a 2-weeks working group last call for 
draft-ietf-pce-pcep-extension-native-ip-20 [1].

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 31st May 2023. We will also notify the IDR WG 
about this WGLC.

A general reminder to the WG to be more vocal during the last-call/adoption and 
help us unclog our queues :)

Thanks,
Dhruv & Julien

[1] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

[tom petch]

.@ietf.org<mailto:pce-boun...@ietf.org> 
mailto:pce-boun...@ietf.org>> On Behalf Of tom petch
Sent: Monday, May 22, 2023 7:35 PM
To: Dhruv Dhody mailto:d...@dhruvdhody.com>>; 
pce@ietf.org<mailto:pce@ietf.org>
Cc: pce-chairs mailto:pce-cha...@ietf.org>>; 
draft-ietf-pce-pcep-extension-native...@ietf.org<mailto:draft-ietf-pce-pcep-extension-native...@ietf.org>
Subject: Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20



From: Pce 
mailto:pce-boun...@ietf.org><mailto:pce-boun...@ietf.org<mailto:pce-boun...@ietf.org>>>
 on behalf of Dhruv Dhody 
mailto:d...@dhruvdhody.com><mailto:d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>>>

Sent: 16 May 2023 23:15



This email starts a 2-weeks working group last call for 
draft-ietf-pce-pcep-extension-native-ip-20 [1].





I had a look and decided that it is mostly beyond me - I am not up to speed 
with all the 15 Normative References, in particular with RFC8821. I would 
prefer that this I-D provided a better bridge to the material in RFC8821.



I note that RFC8821 is an as yet unapproved downref which reinforces that view.



I note too that the Abstract references this and 8735 as anchors which 
Abstracts must not do.

[WAJ] Remove the anchors in the abstract.



The I-D uses the word 'draft' in many places. These must be changed.

[WAJ] Changed the "draft" to "document" within the entire document.



The I-D has a large number of TBDnnn with no note requesting that they are 
replaced; I find these easy to miss.

[WAJ] Do you have any suggestions that can't be "easy to miss"?



p.9 2)

seems to end mid-sentence.

[WAJ] Updated



The English is not quite in several places and could be confusing. Thus p.5 
"Further only one

of BPI, EPR, or PPA object MUST be present. "

I can interpret in two ways although subsequent text makes one the preferred 
one.

[WAJ] Change the phrase to "Further only one and one kind of BPI,EPR, or PPA 
object MUST be present", is it better?



I suspect that there are many potential interactions with BGP, especially when 
things are not going quite right, and that the I-D does not cover them all. The 
language used is not that of BGP (e.g. Established, speaker). The timing too of 
BGP can be quite slow, in setup and in shutdown and I wonder how a PCC copes 
with that.

[WAJ] Once the PCC receives the PCInitiate message that include BPI (BGP Peer 
Info) object, it will try to build the BGP session between the peers that 
indicates in the BPI object. Only when it establishes the BGP session 
successfully, it will report the PCE via the PCRpt message(as that described in 
section 
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip-21#section-6.1).
 Then the PCE can send other instruction to the PCCs. Actually, the procedures 
described in this document is asynchronous.





As I say, largely beyond me but the English needs some attention; using the 
terminology of BGP would help.



Tom Petch





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 31st May 2023. We will also notify the IDR WG 
about this WGLC.



A general reminder to the WG to be more vocal during the last-call/adoption and 
help us unclog our queues :)



Thanks,

Dhruv & Julien



[1] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/



___

Pce mailing list

Pce@ietf.org<mailto:Pce@ietf.org><mailto:Pce@ietf.org<mailto:Pce@ietf.org>>

https://www.ietf.org/mailman/listinfo/pce

___
Pce mailing list
Pce@ietf.org<mailto:Pce@ietf.org>
https://www.ietf.org/mailman/listinfo/pce
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

[Aijun Wang]


Hi, Tom:

I think two phases approach may be more appropriate. As I replied you also in 
the IDR list, we propose the following update later:

1) PCE sends the BPI object with PCInitiate message, then PCC  replies with 
“Ack, start BGP session”.  
2) PCC reports the successful results to PCE after the BGP session is 
established successfully. In case of any failure during the process, PCC can 
report the error information accordingly.

Regarding to your worry about the “hundreds of clients” configuration, I think 
there may be some misunderstandings, or we should describe more clearly in the 
documentation to avoid such worry:

Actually, in such situation, only the two edge routers and RR need to be 
configured the new BGP session via the PCE, all other RR clients need not be 
configured again. The BGP prefixes advised by PPA(Peer Prefix Advertisement) 
Object via the PCInitiate message will be advertised via the existing BGP 
sessions between RR and its other clients.
If we take the scenario illustrated in Figure 1 as the example, we can notice 
that the PCInitiate message is sent only to R1/R7/R3(RR), not to the R5 and R6.

For the tolerance of BGP session establish duration, I think it should be 
determined by the PCE itself, because there is no guarantee way to assure the 
underlying establishment time lapse.

The PCE can determine when it should retry, and when it will give up and 
determine the failure itself if it can’t still receive the responses from the 
PCC.

Aijun Wang
China Telecom

> On May 24, 2023, at 23:45, tom petch  wrote:
> From: Aijun Wang 
> Sent: 24 May 2023 15:47
> 
> Hi, Tom:
> 
> As I explained in previous mail, the procedure of PCEP described in this 
> draft and the establishment of underlying BGP sessions that initiated by the 
> BPI object that included in the PCInitiate message is asynchronous.
> The PCC will report the successful information only after the specific BGP 
> session has been established. We think it’s unnecessary to expose the details 
> BGP FSM states to the PCE—-If there is no successful report from the PCC, the 
> PCE can consider the BGP session is still undergoing.
> 
> Does the above considerations solve your concerns? If necessary, we can 
> consider add some extra state reports from the PCC.
> 
> 
> 
> Not really.  The BGP session setup will fail until the peer is configured so 
> how long does the PCE wait for that, how often does it retry, when does it 
> give up and declare a failure?  If one PCE is impatient, another leisurely, 
> then we may not have interoperability.  I would expect some guidance on this.
> 
> The I-D talks of RR with hundreds of clients which makes me wonder what else 
> might happen, such as a DoS attack.
> 
> Tom Petch
> 
> Aijun Wang
> China Telecom
> 
>> On May 24, 2023, at 17:24, tom petch  wrote:
>> 
>> Adding a new concern about session setup
>> 
>> From: Pce  on behalf of tom petch 
>> Sent: 22 May 2023 12:35
>> From: Pce  on behalf of Dhruv Dhody 
>> 
>> Sent: 16 May 2023 23:15
>> 
>> 
>> I do not understand how this operates.  I would expect there to be two 
>> phases. first the boxes are configured with the information needed by BGP 
>> and then one or more is instructed to initiate the BGP session.  Here I see 
>> PCInitiate providing the configuration information and s.6.1  then says that 
>> the BGP session the operates in a normal fashion; but if the PCE immediately 
>> attempts to initiate a session, it will likely fail because the peer is not 
>> yet configured.  I assume it must then back off, wait and try again later 
>> and then report success or failure (after an extended period of time).  Such 
>> behaviour could be found in a number of protocols.
>> 
>> None of this seems to be catered for.
>> 
>> Tom Petch
>> 
>> 
>> This email starts a 2-weeks working group last call for 
>> draft-ietf-pce-pcep-extension-native-ip-20 [1].
>> 
>> 
>> I had a look and decided that it is mostly beyond me - I am not up to speed 
>> with all the 15 Normative References, in particular with RFC8821.  I would 
>> prefer that this I-D provided a better bridge to the material in RFC8821.
>> 
>> I note that RFC8821 is an as yet unapproved downref which reinforces that 
>> view.
>> 
>> I note too that the Abstract references this and 8735 as anchors which 
>> Abstracts must not do.
>> 
>> The I-D uses the word 'draft' in many places.  These must be changed.
>> 
>> The I-D has a large number of TBDnnn with no note requesting that they are 
>> replaced;  I find these easy to miss.
>> 
>> p.9 2)
>> seems to end mid-sentence.
>> 
>> The English is not quite in several places and could be confusing.  Thus p.5
>> "Further only one
>>  of BPI, EPR, or PPA object MUST be present.  "
>> I can interpret in two ways although subsequent text makes one the preferred 
>> one.
>> 
>> I suspect that there are many potential interactions with BGP, especially 
>> when things are not going quite right, and that the I-D does not cover them 
>> 

Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

[Aijun Wang]

nds the command to PCC, it will collect the status of such command. Only when the previous command is executed successfully, then the next command can be issued. Section 6 cover the descriptions of main procedures.
 

  
 

 For your other comments, please see replies inline.
 

  
 

  
 

  
 

 Huaimo also gives us more valuable suggestions to refine the document offline. I have also incorporated them together in the updated version.
 

  
 

  
 

  
 

 Thanks all you together!
 

  
 

  
 

  
 

 Future reviews from other experts can be based on the updated version.
 

  
 

  
 

  
 

  
 

  
 

 Best Regards
 

  
 

  
 

  
 

 Aijun Wang
 

  
 

 China Telecom
 

  
 

  
 

  
 

 -Original Message-
 

 From: pce-boun...@ietf.org <pce-boun...@ietf.org> On Behalf Of tom petch
 

 Sent: Monday, May 22, 2023 7:35 PM
 

 To: Dhruv Dhody <d...@dhruvdhody.com>; pce@ietf.org
 

 Cc: pce-chairs <pce-cha...@ietf.org>; draft-ietf-pce-pcep-extension-native...@ietf.org
 

     Subject: Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20
 

  
 

  
 

  
 

 From: Pce <pce-boun...@ietf.orgpce-boun...@ietf.org>> on behalf of Dhruv Dhody <d...@dhruvdhody.comd...@dhruvdhody.com>>
 

  
 

 Sent: 16 May 2023 23:15
 

  
 

  
 

  
 

 This email starts a 2-weeks working group last call for draft-ietf-pce-pcep-extension-native-ip-20 [1].
 

  
 

  
 

  
 

 
 

  
 

 I had a look and decided that it is mostly beyond me - I am not up to speed with all the 15 Normative References, in particular with RFC8821. I would prefer that this I-D provided a better bridge to the material in RFC8821.
 

  
 

  
 

  
 

 I note that RFC8821 is an as yet unapproved downref which reinforces that view.
 

  
 

  
 

  
 

 I note too that the Abstract references this and 8735 as anchors which Abstracts must not do.
 

  
 

 [WAJ] Remove the anchors in the abstract.
 

  
 

  
 

  
 

 The I-D uses the word 'draft' in many places. These must be changed.
 

  
 

 [WAJ] Changed the "draft" to "document" within the entire document.
 

  
 

  
 

  
 

 The I-D has a large number of TBDnnn with no note requesting that they are replaced; I find these easy to miss.
 

  
 

 [WAJ] Do you have any suggestions that can't be "easy to miss"?
 

  
 

  
 

  
 

 p.9 2)
 

  
 

 seems to end mid-sentence.
 

  
 

 [WAJ] Updated
 

  
 

  
 

  
 

 The English is not quite in several places and could be confusing. Thus p.5 "Further only one
 

  
 

 of BPI, EPR, or PPA object MUST be present. "
 

  
 

 I can interpret in two ways although subsequent text makes one the preferred one.
 

  
 

 [WAJ] Change the phrase to "Further only one and one kind of BPI,EPR, or PPA object MUST be present", is it better?
 

  
 

  
 

  
 

 I suspect that there are many potential interactions with BGP, especially when things are not going quite right, and that the I-D does not cover them all. The language used is not that of BGP (e.g. Established, speaker). The timing too of BGP can be quite slow, in setup and in shutdown and I wonder how a PCC copes with that.
 

  
 

 [WAJ] Once the PCC receives the PCInitiate message that include BPI (BGP Peer Info) object, it will try to build the BGP session between the peers that indicates in the BPI object. Only when it establishes the BGP session successfully, it will report the PCE via the PCRpt message(as that described in section https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip-21#section-6.1). Then the PCE can send other instruction to the PCCs. Actually, the procedures described in this document is asynchronous.
 

  
 

  
 

  
 

  
   

Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

[Dhruv Dhody]

Hi Aijun,

If you have a need for an early allocation, please send an email to
pce-cha...@ietf.org and we will follow
https://datatracker.ietf.org/doc/html/rfc7120#section-3

But note that as per your Implementation Status [
https://www.ietf.org/archive/id/draft-ietf-pce-pcep-extension-native-ip-21.html#section-12],
there are no known implementations though!

Thanks!
Dhruv

On Wed, May 24, 2023 at 9:19 PM Adrian Farrel  wrote:

> In the past, I would have agreed with Tom on this.
>
> But we are routinely seeing a pause of more than 200 days between a WG
> issuing a Publication Request and the AD starting their review (which leads
> to updates and discussion before IETF last call). IANA don't do their
> provisional assignments until IETF last call.
>
> If there are implementations of what is presumably a stable draft, I think
> early assignment is reasonable. It shouldn't take more than 10 minutes of
> the chairs' and AD'S time.
>
> Cheers,
> Adrian
>
> On 24/05/2023 16:33 BST tom petch  wrote:
>
>
> From: Aijun Wang 
> Sent: 24 May 2023 16:02
>
> As I remember, it is the IANA first allocate the necessary values, then go
> to the RFCEditor.
>
> Can we ask the IANA to (early) allocate the value now?
>
> 
> At this stage in the process, I doubt if it is worth the extra work. Such
> a request goes via chairs and AD. I see it more when users want to
> implement and it may be some time before the I-D gets to the stage that
> this one is now at. And later reviews - Last Call, IESG - may come up with
> changes to the TBDnnn that then confuse the picture. I prefer the 'normal'
> process but with perhaps a bit more of a nudge to the RFC Editor to make
> sure that they pick up all the usages e.g. pointing out to the RFC Editor
> up front or in the IANA Considerations that there are many TBDnn in the
> body of the I-D.
>
> Thinking about it, I am a bit hazy on the normal process between IANA and
> RFC Editor. The e-mails that I see are when things go wrong and either the
> RFC Editor or IANA (or both) are unclear as to what is intended and need
> guidance from the WG
>
> Tom Petch
>
> Aijun Wang
> China Telecom
>
>
> On May 24, 2023, at 17:12, tom petch  wrote:
>
> From: Aijun Wang 
> Sent: 23 May 2023 07:59
>
> Hi, Tom:
>
> Thanks for your review.
>
> I have uploaded the new version to address your comments.
>
> I am trying to find some more convenient methods to describe the
> un-allocated "TBDnnn" from the IANA. Do you have any suggestions that can't
> be "too easy to miss"?
>
> My purpose is that once the IANA allocates the value to each of these
> values according to our requests (
> https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip-21#section-14)
>
>
> , I can replace them easily in the updated version.
>
> 
>
> Mmm I did look at other I-D for another way but think that this is unusual
> in the number of TBDnnn in the body of the I-D, not in the IANA
> Considerations. I did not see a request for early allocation so the values
> will not be assigned until the I-D is about to leave the RFC Editor Queue
> so it is the RFC Editor, not you, who has to find all the instances of
> TBDnnn and replace them. Common practice is to add a
> -- Note to the RFC Editor
> in each and every place where such action is needed outside the IANA
> Considerations. There are a lot of them; 44 I think. I think that at least
> there should be a Note to the RFC Editor in IANA Considerations to the
> effect that these values appear in many places and need editing.
>
> I will post separately a concern about BGP session setup.
>
> Tom Petch
>
>
> For the interaction between BGP and PCEP, we think the paces or procedures
> described in this document can be controlled by the PCE--Once the PCE
> sends the command to PCC, it will collect the status of such command. Only
> when the previous command is executed successfully, then the next command
> can be issued. Section 6 cover the descriptions of main procedures.
>
> For your other comments, please see replies inline.
>
>
>
> Huaimo also gives us more valuable suggestions to refine the document
> offline. I have also incorporated them together in the updated version.
>
>
>
> Thanks all you together!
>
>
>
> Future reviews from other experts can be based on the updated version.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> -Original Message-
> From: pce-boun...@ietf.org  On Behalf Of tom petch
> Sent: Monday, May 22, 2023 7:35 PM
> To: Dhruv Dhody ; pce@ietf.org
> Cc: pce-chairs ;
> draft-ietf-pce-pcep-extension-native...@ietf.org
&g

Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

[Adrian Farrel]

   

  
 

 Best Regards
 

  
 

  
 

  
 

 Aijun Wang
 

  
 

 China Telecom
 

  
 

  
 

  
 

 -Original Message-
 

 From: pce-boun...@ietf.org <pce-boun...@ietf.org> On Behalf Of tom petch
 

 Sent: Monday, May 22, 2023 7:35 PM
 

 To: Dhruv Dhody <d...@dhruvdhody.com>; pce@ietf.org
 

 Cc: pce-chairs <pce-cha...@ietf.org>; draft-ietf-pce-pcep-extension-native...@ietf.org
     

 Subject: Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20
 

  
 

  
 

  
 

 From: Pce <pce-boun...@ietf.orgpce-boun...@ietf.org>> on behalf of Dhruv Dhody <d...@dhruvdhody.comd...@dhruvdhody.com>>
 

  
 

 Sent: 16 May 2023 23:15
 

  
 

  
 

  
 

 This email starts a 2-weeks working group last call for draft-ietf-pce-pcep-extension-native-ip-20 [1].
 

  
 

  
 

  
 

 
 

  
 

 I had a look and decided that it is mostly beyond me - I am not up to speed with all the 15 Normative References, in particular with RFC8821. I would prefer that this I-D provided a better bridge to the material in RFC8821.
 

  
 

  
 

  
 

 I note that RFC8821 is an as yet unapproved downref which reinforces that view.
 

  
 

  
 

  
 

 I note too that the Abstract references this and 8735 as anchors which Abstracts must not do.
 

  
 

 [WAJ] Remove the anchors in the abstract.
 

  
 

  
 

  
 

 The I-D uses the word 'draft' in many places. These must be changed.
 

  
 

 [WAJ] Changed the "draft" to "document" within the entire document.
 

  
 

  
 

  
 

 The I-D has a large number of TBDnnn with no note requesting that they are replaced; I find these easy to miss.
 

  
 

 [WAJ] Do you have any suggestions that can't be "easy to miss"?
 

  
 

  
 

  
 

 p.9 2)
 

  
 

 seems to end mid-sentence.
 

  
 

 [WAJ] Updated
 

  
 

  
 

  
 

 The English is not quite in several places and could be confusing. Thus p.5 "Further only one
 

  
 

 of BPI, EPR, or PPA object MUST be present. "
 

  
 

 I can interpret in two ways although subsequent text makes one the preferred one.
 

  
 

 [WAJ] Change the phrase to "Further only one and one kind of BPI,EPR, or PPA object MUST be present", is it better?
 

  
 

  
 

  
 

 I suspect that there are many potential interactions with BGP, especially when things are not going quite right, and that the I-D does not cover them all. The language used is not that of BGP (e.g. Established, speaker). The timing too of BGP can be quite slow, in setup and in shutdown and I wonder how a PCC copes with that.
 

  
 

 [WAJ] Once the PCC receives the PCInitiate message that include BPI (BGP Peer Info) object, it will try to build the BGP session between the peers that indicates in the BPI object. Only when it establishes the BGP session successfully, it will report the PCE via the PCRpt message(as that described in section https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip-21#section-6.1). Then the PCE can send other instruction to the PCCs. Actually, the procedures described in this document is asynchronous.
 

  
 

  
 

  
 

  
 

  
 

 As I say, largely beyond me but the English needs some attention; using the terminology of BGP would help.
 

  
 

  
 

  
 

 Tom Petch
 

  
 

  
 

  
 

  
 

  
 

 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 31st May 2023. We will also notify the IDR WG about this WGLC.
 

  
 

  
 
   

Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

[tom petch]

From: Aijun Wang 
Sent: 24 May 2023 15:47

Hi, Tom:

As I explained in previous mail, the procedure of PCEP described in this draft 
and the establishment of underlying BGP sessions that initiated by the BPI 
object that included in the PCInitiate message is asynchronous.
The PCC will report the successful information only after the specific BGP 
session has been established. We think it’s unnecessary to expose the details 
BGP FSM states to the PCE—-If there is no successful report from the PCC, the 
PCE can consider the BGP session is still undergoing.

Does the above considerations solve your concerns? If necessary, we can 
consider add some extra state reports from the PCC.



Not really.  The BGP session setup will fail until the peer is configured so 
how long does the PCE wait for that, how often does it retry, when does it give 
up and declare a failure?  If one PCE is impatient, another leisurely, then we 
may not have interoperability.  I would expect some guidance on this.

The I-D talks of RR with hundreds of clients which makes me wonder what else 
might happen, such as a DoS attack.

Tom Petch

Aijun Wang
China Telecom

> On May 24, 2023, at 17:24, tom petch  wrote:
>
> Adding a new concern about session setup
>
> From: Pce  on behalf of tom petch 
> Sent: 22 May 2023 12:35
> From: Pce  on behalf of Dhruv Dhody 
> 
> Sent: 16 May 2023 23:15
>
> 
> I do not understand how this operates.  I would expect there to be two 
> phases. first the boxes are configured with the information needed by BGP and 
> then one or more is instructed to initiate the BGP session.  Here I see 
> PCInitiate providing the configuration information and s.6.1  then says that 
> the BGP session the operates in a normal fashion; but if the PCE immediately 
> attempts to initiate a session, it will likely fail because the peer is not 
> yet configured.  I assume it must then back off, wait and try again later and 
> then report success or failure (after an extended period of time).  Such 
> behaviour could be found in a number of protocols.
>
> None of this seems to be catered for.
>
> Tom Petch
>
>
> This email starts a 2-weeks working group last call for 
> draft-ietf-pce-pcep-extension-native-ip-20 [1].
>
> 
> I had a look and decided that it is mostly beyond me - I am not up to speed 
> with all the 15 Normative References, in particular with RFC8821.  I would 
> prefer that this I-D provided a better bridge to the material in RFC8821.
>
> I note that RFC8821 is an as yet unapproved downref which reinforces that 
> view.
>
> I note too that the Abstract references this and 8735 as anchors which 
> Abstracts must not do.
>
> The I-D uses the word 'draft' in many places.  These must be changed.
>
> The I-D has a large number of TBDnnn with no note requesting that they are 
> replaced;  I find these easy to miss.
>
> p.9 2)
> seems to end mid-sentence.
>
> The English is not quite in several places and could be confusing.  Thus p.5
> "Further only one
>   of BPI, EPR, or PPA object MUST be present.  "
> I can interpret in two ways although subsequent text makes one the preferred 
> one.
>
> I suspect that there are many potential interactions with BGP, especially 
> when things are not going quite right, and that the I-D does not cover them 
> all.  The language used is not that of BGP (e.g. Established, speaker).  The 
> timing too of BGP can be quite slow, in setup and in shutdown and I wonder 
> how a PCC copes with that.
>
> As I say, largely beyond me but the English needs some attention;  using the 
> terminology of BGP would help.
>
> Tom Petch
>
>
> 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 31st May 2023. We will also notify the IDR WG 
> about this WGLC.
>
> A general reminder to the WG to be more vocal during the last-call/adoption 
> and help us unclog our queues :)
>
> Thanks,
> Dhruv & Julien
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce

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

Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

[tom petch]

From: Aijun Wang 
Sent: 24 May 2023 16:02

As I remember, it is the IANA first allocate the necessary values, then go to 
the RFCEditor.

Can we ask the IANA to (early) allocate the value now?


At this stage in the process, I doubt if it is worth the extra work.  Such a 
request goes via chairs and AD.  I see it more when users want to implement and 
it may be some time before the I-D gets to the stage that this one is now at.  
And later reviews - Last Call, IESG - may come up with changes to the TBDnnn 
that then confuse the picture.  I prefer the 'normal' process but with perhaps 
a bit more of a nudge to the RFC Editor to make sure that they pick up all the 
usages e.g. pointing out to the RFC Editor up front or in the IANA 
Considerations that there are many TBDnn in the body of the I-D.

Thinking about it, I am a bit hazy on the normal process between IANA and RFC 
Editor.  The e-mails that I see are when things go wrong and either the RFC 
Editor or IANA (or both) are unclear as to what is intended and need guidance 
from the WG

Tom Petch 

Aijun Wang
China Telecom

> On May 24, 2023, at 17:12, tom petch  wrote:
>
> From: Aijun Wang 
> Sent: 23 May 2023 07:59
>
> Hi, Tom:
>
> Thanks for your review.
>
> I have uploaded the new version to address your comments.
>
> I am trying to find some more convenient methods to describe the un-allocated 
> "TBDnnn" from the IANA. Do you have any suggestions that can't be "too easy 
> to miss"?
>
> My purpose is that once the IANA allocates the value to each of these values 
> according to our requests 
> (https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip-21#section-14)
>
> , I can replace them easily in the updated version.
>
> 
>
> Mmm  I did look at other I-D for another way but think that this is unusual 
> in the number of TBDnnn in the body of the I-D, not in the IANA 
> Considerations.  I did not see a request for early allocation so the values 
> will not be assigned until the I-D is about to leave the RFC Editor Queue so 
> it is the RFC Editor, not you, who has to find all the instances of TBDnnn 
> and replace them.  Common practice is to add a
> -- Note to the RFC Editor
> in each and every place where such action is needed outside the IANA 
> Considerations.  There are a lot of them; 44 I think.  I think that at least 
> there should be a Note to the RFC Editor in IANA Considerations to the effect 
> that these values appear in many places and need editing.
>
> I will post separately a concern about BGP session setup.
>
> Tom Petch
>
>
> For the interaction between BGP and PCEP, we think the paces or procedures 
> described in this document can be controlled by the PCE--Once the PCE 
> sends the command to PCC, it will collect the status of such command. Only 
> when the previous command is executed successfully, then the next command can 
> be issued. Section 6 cover the descriptions of main procedures.
>
> For your other comments, please see replies inline.
>
>
>
> Huaimo  also gives us more valuable suggestions to refine the document 
> offline. I have also incorporated them together in the updated version.
>
>
>
> Thanks all you together!
>
>
>
> Future reviews from other experts can be based on the updated version.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> -----Original Message-----
> From: pce-boun...@ietf.org  On Behalf Of tom petch
> Sent: Monday, May 22, 2023 7:35 PM
> To: Dhruv Dhody ; pce@ietf.org
> Cc: pce-chairs ; 
> draft-ietf-pce-pcep-extension-native...@ietf.org
> Subject: Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20
>
>
>
> From: Pce mailto:pce-boun...@ietf.org>> on behalf of 
> Dhruv Dhody mailto:d...@dhruvdhody.com>>
>
> Sent: 16 May 2023 23:15
>
>
>
> This email starts a 2-weeks working group last call for 
> draft-ietf-pce-pcep-extension-native-ip-20 [1].
>
>
>
> 
>
> I had a look and decided that it is mostly beyond me - I am not up to speed 
> with all the 15 Normative References, in particular with RFC8821.  I would 
> prefer that this I-D provided a better bridge to the material in RFC8821.
>
>
>
> I note that RFC8821 is an as yet unapproved downref which reinforces that 
> view.
>
>
>
> I note too that the Abstract references this and 8735 as anchors which 
> Abstracts must not do.
>
> [WAJ] Remove the anchors in the abstract.
>
>
>
> The I-D uses the word 'draft' in many places.  These must be changed.
>
> [WAJ] Changed the "draft" to "document" within the entire document.
>
>
>
> The I-D has a large number of TBDnnn with no 

Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

[Aijun Wang]

As I remember, it is the IANA first allocate the necessary values, then go to 
the RFCEditor.

Can we ask the IANA to (early) allocate the value now? 

Aijun Wang
China Telecom

> On May 24, 2023, at 17:12, tom petch  wrote:
> 
> From: Aijun Wang 
> Sent: 23 May 2023 07:59
> 
> Hi, Tom:
> 
> Thanks for your review.
> 
> I have uploaded the new version to address your comments.
> 
> I am trying to find some more convenient methods to describe the un-allocated 
> "TBDnnn" from the IANA. Do you have any suggestions that can't be "too easy 
> to miss"?
> 
> My purpose is that once the IANA allocates the value to each of these values 
> according to our requests 
> (https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip-21#section-14)
> 
> , I can replace them easily in the updated version.
> 
> 
> 
> Mmm  I did look at other I-D for another way but think that this is unusual 
> in the number of TBDnnn in the body of the I-D, not in the IANA 
> Considerations.  I did not see a request for early allocation so the values 
> will not be assigned until the I-D is about to leave the RFC Editor Queue so 
> it is the RFC Editor, not you, who has to find all the instances of TBDnnn 
> and replace them.  Common practice is to add a 
> -- Note to the RFC Editor
> in each and every place where such action is needed outside the IANA 
> Considerations.  There are a lot of them; 44 I think.  I think that at least 
> there should be a Note to the RFC Editor in IANA Considerations to the effect 
> that these values appear in many places and need editing.
> 
> I will post separately a concern about BGP session setup.
> 
> Tom Petch
> 
> 
> For the interaction between BGP and PCEP, we think the paces or procedures 
> described in this document can be controlled by the PCE--Once the PCE 
> sends the command to PCC, it will collect the status of such command. Only 
> when the previous command is executed successfully, then the next command can 
> be issued. Section 6 cover the descriptions of main procedures.
> 
> For your other comments, please see replies inline.
> 
> 
> 
> Huaimo  also gives us more valuable suggestions to refine the document 
> offline. I have also incorporated them together in the updated version.
> 
> 
> 
> Thanks all you together!
> 
> 
> 
> Future reviews from other experts can be based on the updated version.
> 
> 
> 
> 
> 
> Best Regards
> 
> 
> 
> Aijun Wang
> 
> China Telecom
> 
> 
> 
> -----Original Message-----
> From: pce-boun...@ietf.org  On Behalf Of tom petch
> Sent: Monday, May 22, 2023 7:35 PM
> To: Dhruv Dhody ; pce@ietf.org
> Cc: pce-chairs ; 
> draft-ietf-pce-pcep-extension-native...@ietf.org
> Subject: Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20
> 
> 
> 
> From: Pce mailto:pce-boun...@ietf.org>> on behalf of 
> Dhruv Dhody mailto:d...@dhruvdhody.com>>
> 
> Sent: 16 May 2023 23:15
> 
> 
> 
> This email starts a 2-weeks working group last call for 
> draft-ietf-pce-pcep-extension-native-ip-20 [1].
> 
> 
> 
> 
> 
> I had a look and decided that it is mostly beyond me - I am not up to speed 
> with all the 15 Normative References, in particular with RFC8821.  I would 
> prefer that this I-D provided a better bridge to the material in RFC8821.
> 
> 
> 
> I note that RFC8821 is an as yet unapproved downref which reinforces that 
> view.
> 
> 
> 
> I note too that the Abstract references this and 8735 as anchors which 
> Abstracts must not do.
> 
> [WAJ] Remove the anchors in the abstract.
> 
> 
> 
> The I-D uses the word 'draft' in many places.  These must be changed.
> 
> [WAJ] Changed the "draft" to "document" within the entire document.
> 
> 
> 
> The I-D has a large number of TBDnnn with no note requesting that they are 
> replaced;  I find these easy to miss.
> 
> [WAJ] Do you have any suggestions that can't be "easy to miss"?
> 
> 
> 
> p.9 2)
> 
> seems to end mid-sentence.
> 
> [WAJ] Updated
> 
> 
> 
> The English is not quite in several places and could be confusing.  Thus p.5 
> "Further only one
> 
>   of BPI, EPR, or PPA object MUST be present.  "
> 
> I can interpret in two ways although subsequent text makes one the preferred 
> one.
> 
> [WAJ] Change the phrase to "Further only one and one kind of BPI,EPR, or PPA 
> object MUST be present", is it better?
> 
> 
> 
> I suspect that there are many potential interactions with BGP, especially 
> when things are not going quite right, and that the I-D do

Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

[Aijun Wang]

Hi, Tom:

As I explained in previous mail, the procedure of PCEP described in this draft 
and the establishment of underlying BGP sessions that initiated by the BPI 
object that included in the PCInitiate message is asynchronous. 
The PCC will report the successful information only after the specific BGP 
session has been established. We think it’s unnecessary to expose the details 
BGP FSM states to the PCE—-If there is no successful report from the PCC, the 
PCE can consider the BGP session is still undergoing.

Does the above considerations solve your concerns? If necessary, we can 
consider add some extra state reports from the PCC.

Aijun Wang
China Telecom

> On May 24, 2023, at 17:24, tom petch  wrote:
> 
> Adding a new concern about session setup
> 
> From: Pce  on behalf of tom petch 
> Sent: 22 May 2023 12:35
> From: Pce  on behalf of Dhruv Dhody 
> 
> Sent: 16 May 2023 23:15
> 
> 
> I do not understand how this operates.  I would expect there to be two 
> phases. first the boxes are configured with the information needed by BGP and 
> then one or more is instructed to initiate the BGP session.  Here I see 
> PCInitiate providing the configuration information and s.6.1  then says that 
> the BGP session the operates in a normal fashion; but if the PCE immediately 
> attempts to initiate a session, it will likely fail because the peer is not 
> yet configured.  I assume it must then back off, wait and try again later and 
> then report success or failure (after an extended period of time).  Such 
> behaviour could be found in a number of protocols.
> 
> None of this seems to be catered for.
> 
> Tom Petch
> 
> 
> This email starts a 2-weeks working group last call for 
> draft-ietf-pce-pcep-extension-native-ip-20 [1].
> 
> 
> I had a look and decided that it is mostly beyond me - I am not up to speed 
> with all the 15 Normative References, in particular with RFC8821.  I would 
> prefer that this I-D provided a better bridge to the material in RFC8821.
> 
> I note that RFC8821 is an as yet unapproved downref which reinforces that 
> view.
> 
> I note too that the Abstract references this and 8735 as anchors which 
> Abstracts must not do.
> 
> The I-D uses the word 'draft' in many places.  These must be changed.
> 
> The I-D has a large number of TBDnnn with no note requesting that they are 
> replaced;  I find these easy to miss.
> 
> p.9 2)
> seems to end mid-sentence.
> 
> The English is not quite in several places and could be confusing.  Thus p.5
> "Further only one
>   of BPI, EPR, or PPA object MUST be present.  "
> I can interpret in two ways although subsequent text makes one the preferred 
> one.
> 
> I suspect that there are many potential interactions with BGP, especially 
> when things are not going quite right, and that the I-D does not cover them 
> all.  The language used is not that of BGP (e.g. Established, speaker).  The 
> timing too of BGP can be quite slow, in setup and in shutdown and I wonder 
> how a PCC copes with that.
> 
> As I say, largely beyond me but the English needs some attention;  using the 
> terminology of BGP would help.
> 
> Tom Petch
> 
> 
> 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 31st May 2023. We will also notify the IDR WG 
> about this WGLC.
> 
> A general reminder to the WG to be more vocal during the last-call/adoption 
> and help us unclog our queues :)
> 
> Thanks,
> Dhruv & Julien
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/
> 
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
> 
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce

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

Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

[tom petch]

Adding a new concern about session setup

From: Pce  on behalf of tom petch 
Sent: 22 May 2023 12:35
From: Pce  on behalf of Dhruv Dhody 
Sent: 16 May 2023 23:15


I do not understand how this operates.  I would expect there to be two phases. 
first the boxes are configured with the information needed by BGP and then one 
or more is instructed to initiate the BGP session.  Here I see PCInitiate 
providing the configuration information and s.6.1  then says that the BGP 
session the operates in a normal fashion; but if the PCE immediately attempts 
to initiate a session, it will likely fail because the peer is not yet 
configured.  I assume it must then back off, wait and try again later and then 
report success or failure (after an extended period of time).  Such behaviour 
could be found in a number of protocols.

None of this seems to be catered for.

Tom Petch


This email starts a 2-weeks working group last call for 
draft-ietf-pce-pcep-extension-native-ip-20 [1].


I had a look and decided that it is mostly beyond me - I am not up to speed 
with all the 15 Normative References, in particular with RFC8821.  I would 
prefer that this I-D provided a better bridge to the material in RFC8821.

I note that RFC8821 is an as yet unapproved downref which reinforces that view.

I note too that the Abstract references this and 8735 as anchors which 
Abstracts must not do.

The I-D uses the word 'draft' in many places.  These must be changed.

The I-D has a large number of TBDnnn with no note requesting that they are 
replaced;  I find these easy to miss.

p.9 2)
seems to end mid-sentence.

The English is not quite in several places and could be confusing.  Thus p.5
"Further only one
   of BPI, EPR, or PPA object MUST be present.  "
I can interpret in two ways although subsequent text makes one the preferred 
one.

I suspect that there are many potential interactions with BGP, especially when 
things are not going quite right, and that the I-D does not cover them all.  
The language used is not that of BGP (e.g. Established, speaker).  The timing 
too of BGP can be quite slow, in setup and in shutdown and I wonder how a PCC 
copes with that.

As I say, largely beyond me but the English needs some attention;  using the 
terminology of BGP would help.

Tom Petch


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 31st May 2023. We will also notify the IDR WG 
about this WGLC.

A general reminder to the WG to be more vocal during the last-call/adoption and 
help us unclog our queues :)

Thanks,
Dhruv & Julien

[1] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/

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

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

Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

[tom petch]

From: Aijun Wang 
Sent: 23 May 2023 07:59

Hi, Tom:

Thanks for your review.

I have uploaded the new version to address your comments.

I am trying to find some more convenient methods to describe the un-allocated 
"TBDnnn" from the IANA. Do you have any suggestions that can't be "too easy to 
miss"?

My purpose is that once the IANA allocates the value to each of these values 
according to our requests 
(https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip-21#section-14)

, I can replace them easily in the updated version.



Mmm  I did look at other I-D for another way but think that this is unusual in 
the number of TBDnnn in the body of the I-D, not in the IANA Considerations.  I 
did not see a request for early allocation so the values will not be assigned 
until the I-D is about to leave the RFC Editor Queue so it is the RFC Editor, 
not you, who has to find all the instances of TBDnnn and replace them.  Common 
practice is to add a 
-- Note to the RFC Editor
in each and every place where such action is needed outside the IANA 
Considerations.  There are a lot of them; 44 I think.  I think that at least 
there should be a Note to the RFC Editor in IANA Considerations to the effect 
that these values appear in many places and need editing.

I will post separately a concern about BGP session setup.

Tom Petch


For the interaction between BGP and PCEP, we think the paces or procedures 
described in this document can be controlled by the PCE--Once the PCE sends 
the command to PCC, it will collect the status of such command. Only when the 
previous command is executed successfully, then the next command can be issued. 
Section 6 cover the descriptions of main procedures.

For your other comments, please see replies inline.



Huaimo  also gives us more valuable suggestions to refine the document offline. 
I have also incorporated them together in the updated version.



Thanks all you together!



Future reviews from other experts can be based on the updated version.





Best Regards



Aijun Wang

China Telecom



-Original Message-
From: pce-boun...@ietf.org  On Behalf Of tom petch
Sent: Monday, May 22, 2023 7:35 PM
To: Dhruv Dhody ; pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-pcep-extension-native...@ietf.org
Subject: Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20



From: Pce mailto:pce-boun...@ietf.org>> on behalf of 
Dhruv Dhody mailto:d...@dhruvdhody.com>>

Sent: 16 May 2023 23:15



This email starts a 2-weeks working group last call for 
draft-ietf-pce-pcep-extension-native-ip-20 [1].





I had a look and decided that it is mostly beyond me - I am not up to speed 
with all the 15 Normative References, in particular with RFC8821.  I would 
prefer that this I-D provided a better bridge to the material in RFC8821.



I note that RFC8821 is an as yet unapproved downref which reinforces that view.



I note too that the Abstract references this and 8735 as anchors which 
Abstracts must not do.

[WAJ] Remove the anchors in the abstract.



The I-D uses the word 'draft' in many places.  These must be changed.

[WAJ] Changed the "draft" to "document" within the entire document.



The I-D has a large number of TBDnnn with no note requesting that they are 
replaced;  I find these easy to miss.

[WAJ] Do you have any suggestions that can't be "easy to miss"?



p.9 2)

seems to end mid-sentence.

[WAJ] Updated



The English is not quite in several places and could be confusing.  Thus p.5 
"Further only one

   of BPI, EPR, or PPA object MUST be present.  "

I can interpret in two ways although subsequent text makes one the preferred 
one.

[WAJ] Change the phrase to "Further only one and one kind of BPI,EPR, or PPA 
object MUST be present", is it better?



I suspect that there are many potential interactions with BGP, especially when 
things are not going quite right, and that the I-D does not cover them all.  
The language used is not that of BGP (e.g. Established, speaker).  The timing 
too of BGP can be quite slow, in setup and in shutdown and I wonder how a PCC 
copes with that.

[WAJ] Once the PCC receives the PCInitiate message that include BPI (BGP Peer 
Info) object, it will try to build the BGP session between the peers that 
indicates in the BPI object. Only when it establishes the BGP session 
successfully, it will report the PCE via the PCRpt message(as that described in 
section 
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip-21#section-6.1).
 Then the PCE can send other instruction to the PCCs.  Actually, the procedures 
described in this document is asynchronous.





As I say, largely beyond me but the English needs some attention;  using the 
terminology of BGP would help.



Tom Petch





Please indicate your support or concern for this draft. If you are opposed to 
the progression of the draft to RFC, plea

Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

[Cheng Li]

I support the WGLC. The draft has been adopted for a long time, it should move 
forward, and I do not have concerns of the draft.

Thanks,
Cheng


From: Pce  On Behalf Of Dhruv Dhody
Sent: Wednesday, May 17, 2023 6:16 AM
To: pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-pcep-extension-native...@ietf.org
Subject: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

Hi WG,

This email starts a 2-weeks working group last call for 
draft-ietf-pce-pcep-extension-native-ip-20 [1].

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 31st May 2023. We will also notify the IDR WG 
about this WGLC.

A general reminder to the WG to be more vocal during the last-call/adoption and 
help us unclog our queues :)

Thanks,
Dhruv & Julien

[1] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

[Aijun Wang]

Hi, Tom:

 

Thanks for your review.

I have uploaded the new version to address your comments.

I am trying to find some more convenient methods to describe the
un-allocated "TBDnnn" from the IANA. Do you have any suggestions that can't
be "too easy to miss"? 

My purpose is that once the IANA allocates the value to each of these values
according to our requests
(https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-
ip-21#section-14)

, I can replace them easily in the updated version.

 

For the interaction between BGP and PCEP, we think the paces or procedures
described in this document can be controlled by the PCE--Once the PCE
sends the command to PCC, it will collect the status of such command. Only
when the previous command is executed successfully, then the next command
can be issued. Section 6 cover the descriptions of main procedures.

 

For your other comments, please see replies inline.

 

Huaimo  also gives us more valuable suggestions to refine the document
offline. I have also incorporated them together in the updated version.

 

Thanks all you together!

 

Future reviews from other experts can be based on the updated version.

 

 

Best Regards

 

Aijun Wang

China Telecom

 

-Original Message-
From: pce-boun...@ietf.org  On Behalf Of tom petch
Sent: Monday, May 22, 2023 7:35 PM
To: Dhruv Dhody ; pce@ietf.org
Cc: pce-chairs ;
draft-ietf-pce-pcep-extension-native...@ietf.org
Subject: Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

 

From: Pce < <mailto:pce-boun...@ietf.org> pce-boun...@ietf.org> on behalf of
Dhruv Dhody < <mailto:d...@dhruvdhody.com> d...@dhruvdhody.com>

Sent: 16 May 2023 23:15

 

This email starts a 2-weeks working group last call for
draft-ietf-pce-pcep-extension-native-ip-20 [1].

 



I had a look and decided that it is mostly beyond me - I am not up to speed
with all the 15 Normative References, in particular with RFC8821.  I would
prefer that this I-D provided a better bridge to the material in RFC8821.

 

I note that RFC8821 is an as yet unapproved downref which reinforces that
view.

 

I note too that the Abstract references this and 8735 as anchors which
Abstracts must not do.

[WAJ] Remove the anchors in the abstract.

 

The I-D uses the word 'draft' in many places.  These must be changed.

[WAJ] Changed the "draft" to "document" within the entire document.

 

The I-D has a large number of TBDnnn with no note requesting that they are
replaced;  I find these easy to miss.

[WAJ] Do you have any suggestions that can't be "easy to miss"?

 

p.9 2)

seems to end mid-sentence.

[WAJ] Updated

 

The English is not quite in several places and could be confusing.  Thus p.5
"Further only one

   of BPI, EPR, or PPA object MUST be present.  "

I can interpret in two ways although subsequent text makes one the preferred
one.

[WAJ] Change the phrase to "Further only one and one kind of BPI,EPR, or PPA
object MUST be present", is it better?

 

I suspect that there are many potential interactions with BGP, especially
when things are not going quite right, and that the I-D does not cover them
all.  The language used is not that of BGP (e.g. Established, speaker).  The
timing too of BGP can be quite slow, in setup and in shutdown and I wonder
how a PCC copes with that.

[WAJ] Once the PCC receives the PCInitiate message that include BPI (BGP
Peer Info) object, it will try to build the BGP session between the peers
that indicates in the BPI object. Only when it establishes the BGP session
successfully, it will report the PCE via the PCRpt message(as that described
in section
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-i
p-21#section-6.1). Then the PCE can send other instruction to the PCCs.
Actually, the procedures described in this document is asynchronous. 

 

 

As I say, largely beyond me but the English needs some attention;  using the
terminology of BGP would help.

 

Tom Petch

 

 

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 31st May 2023. We will also notify the IDR
WG about this WGLC.

 

A general reminder to the WG to be more vocal during the last-call/adoption
and help us unclog our queues :)

 

Thanks,

Dhruv & Julien

 

[1]
<https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/>
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/

 

___

Pce mailing list

 <mailto:Pce@ietf.org> Pce@ietf.org

 <https://www.ietf.org/mailman/listinfo/pce>
https://ww

Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

[tom petch]

Not another comment but to report that I got a bounce message to my previous 
comment to the effect that it could not be delivered to

expand-draft-ietf-pce-pcep-extension-native...@virtual.ietf.org

Not an address that I am familiar with.

Tom Petch


From: Pce  on behalf of tom petch 
Sent: 22 May 2023 12:35
To: Dhruv Dhody; pce@ietf.org
Cc: pce-chairs; draft-ietf-pce-pcep-extension-native...@ietf.org
Subject: Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

From: Pce  on behalf of Dhruv Dhody 
Sent: 16 May 2023 23:15

This email starts a 2-weeks working group last call for 
draft-ietf-pce-pcep-extension-native-ip-20 [1].


I had a look and decided that it is mostly beyond me - I am not up to speed 
with all the 15 Normative References, in particular with RFC8821.  I would 
prefer that this I-D provided a better bridge to the material in RFC8821.

I note that RFC8821 is an as yet unapproved downref which reinforces that view.

I note too that the Abstract references this and 8735 as anchors which 
Abstracts must not do.

The I-D uses the word 'draft' in many places.  These must be changed.

The I-D has a large number of TBDnnn with no note requesting that they are 
replaced;  I find these easy to miss.

p.9 2)
seems to end mid-sentence.

The English is not quite in several places and could be confusing.  Thus p.5
"Further only one
   of BPI, EPR, or PPA object MUST be present.  "
I can interpret in two ways although subsequent text makes one the preferred 
one.

I suspect that there are many potential interactions with BGP, especially when 
things are not going quite right, and that the I-D does not cover them all.  
The language used is not that of BGP (e.g. Established, speaker).  The timing 
too of BGP can be quite slow, in setup and in shutdown and I wonder how a PCC 
copes with that.

As I say, largely beyond me but the English needs some attention;  using the 
terminology of BGP would help.

Tom Petch


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 31st May 2023. We will also notify the IDR WG 
about this WGLC.

A general reminder to the WG to be more vocal during the last-call/adoption and 
help us unclog our queues :)

Thanks,
Dhruv & Julien

[1] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/

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

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

Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

[tom petch]

From: Pce  on behalf of Dhruv Dhody 
Sent: 16 May 2023 23:15

This email starts a 2-weeks working group last call for 
draft-ietf-pce-pcep-extension-native-ip-20 [1].


I had a look and decided that it is mostly beyond me - I am not up to speed 
with all the 15 Normative References, in particular with RFC8821.  I would 
prefer that this I-D provided a better bridge to the material in RFC8821.

I note that RFC8821 is an as yet unapproved downref which reinforces that view.

I note too that the Abstract references this and 8735 as anchors which 
Abstracts must not do.

The I-D uses the word 'draft' in many places.  These must be changed.

The I-D has a large number of TBDnnn with no note requesting that they are 
replaced;  I find these easy to miss.

p.9 2)
seems to end mid-sentence.

The English is not quite in several places and could be confusing.  Thus p.5 
"Further only one
   of BPI, EPR, or PPA object MUST be present.  "
I can interpret in two ways although subsequent text makes one the preferred 
one.

I suspect that there are many potential interactions with BGP, especially when 
things are not going quite right, and that the I-D does not cover them all.  
The language used is not that of BGP (e.g. Established, speaker).  The timing 
too of BGP can be quite slow, in setup and in shutdown and I wonder how a PCC 
copes with that.

As I say, largely beyond me but the English needs some attention;  using the 
terminology of BGP would help.

Tom Petch


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 31st May 2023. We will also notify the IDR WG 
about this WGLC.

A general reminder to the WG to be more vocal during the last-call/adoption and 
help us unclog our queues :)

Thanks,
Dhruv & Julien

[1] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/

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