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 <  pce-boun...@ietf.org> on behalf of
Dhruv Dhody <  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/

 

___

Pce mailing list

  Pce@ietf.org

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

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

[Pce] I-D Action: draft-ietf-pce-pcep-extension-native-ip-21.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Path Computation
Element (PCE) WG of the IETF.

   Title   : PCEP Extension for Native IP Network
   Authors : Aijun Wang
 Boris Khasanov
 Sheng Fang
 Ren Tan
 Chun Zhu
   Filename: draft-ietf-pce-pcep-extension-native-ip-21.txt
   Pages   : 29
   Date: 2023-05-22

Abstract:
   This document defines the Path Computation Element Communication
   Protocol (PCEP) extension for Central Control Dynamic Routing (CCDR)
   based application in Native IP network.  It describes the key
   information that is transferred between Path Computation Element
   (PCE) and Path Computation Clients (PCC) to accomplish the End to End
   (E2E) traffic assurance in Native IP network under central control
   mode.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip-21

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-pcep-extension-native-ip-21

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
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]

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