Path Computation Element Communication Protocol (PCEP) Extensions for Native IP Networks
draft-ietf-pce-pcep-extension-native-ip-40

Thanks to Magnus Nystrom for his SecDir review.  And for the authors' prompt attention to his comments. 

I also think the paragraph on the experimental aspect of this is useful.  Thank you.

# Internet AD comments for draft-ietf-pce-pcep-extension-native-ip-34
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S6.4

* Why only IP-in-IP? Would it be possible/easy to cite the BGP Tunnel
  Encapsulation Attribute Tunnel Types IANA registry, plus whatever other
  mechanics/semantics that might go along with it?

  https://iana.org/assignments/bgp-tunnel-encapsulation/

# Gunter Van de Velde, RTG AD, comments for draft-ietf-pce-pcep-extension-native-ip-34

## Many thanks for writing this document. I found the text not easy to process, mostly due to the many many references used in the document. 

## I support Roman's discuss that applies to -34

#GENERIC COMMENTS
#================
## idnits spits up few message


#DETAILED COMMENTS
#=================
##classified as [minor] and [major]

17	Abstract
18
19	   This document defines the Path Computation Element Communication
20	   Protocol (PCEP) extension for Central Control Dynamic Routing (CCDR)
21	   based applications in Native IP networks.  It describes the key
22	   information that is transferred between the Path Computation Element
23	   (PCE) and the Path Computation Clients (PCC) to accomplish the End-
24	   to-End (E2E) traffic assurance in the Native IP network under PCE as
25	   a central controller (PCECC).

[minor]
an alternate proposal for abstract easier to digest and read for people with less PCEP awareness. Please use or ignore as you find useful

"
This document defines extensions to the Path Computation Element Communication Protocol (PCEP) to support the computation of paths for native IP traffic. The proposed extensions enable a Path Computation Element (PCE) to calculate and manage paths for native IP networks, enhancing the capabilities of PCEP beyond traditional MPLS and GMPLS networks. By introducing new PCEP objects and procedures, this document allows for the efficient use of IP network resources and supports the deployment of traffic engineering in native IP environments.
"

114	   Generally, Multiprotocol Label Switching Traffic Engineering (MPLS-
115	   TE) requires the corresponding network devices to support Resource
116	   ReSerVation Protocol (RSVP)/Label Distribution Protocol (LDP)
117	   protocols to ensure the End-to-End (E2E) traffic performance.  But in

[minor]
should there be no reference to rsvp and ldp RFCs?

199	   N (NATIVE-IP-TE-CAPABILITY - 1 bit - 30): If set to 1 by a PCEP
200	   speaker, it indicates that the PCEP speaker is capable of TE in a
201	   Native IP network as specified in this document.  The flag MUST be
202	   set by both the PCC and PCE to support this extension.

[minor]
What about the folowing proposed textblob?

"
N (NATIVE-IP-TE-CAPABILITY - 1 bit - 30): When set to 1 by a PCEP speaker, this flag indicates that the PCEP speaker is capable of TE in a Native IP network, as specified in this document. Both the PCC and PCE MUST set this flag to support this extension.
"

223	   If one or both speakers (PCE and PCC) have not indicated support and
224	   willingness to use the PCEP extensions for Native-IP, the PCEP
225	   extensions for the Native-IP MUST NOT be used.  If a Native-IP

[major]
earlier in the text i only saw the N flag, however this text seems to indicate two flags?
(1) support for Native-IP and (2) willingness to use Native-IP
Maybe i missunderstood how the willingness is signalled?

350	   The error handling for missing CCI objects is as per [RFC9050].
351	   Furthermore, one, and only one, object among BPI, EPR or PPA object
352	   MUST be present.

[minor]
Maybe this can be rewritten more normative? what about

"
Error handling for missing CCI objects MUST be performed as specified in [RFC9050]. Additionally, exactly one object among the BPI, EPR, or PPA objects MUST be present.
"

The SHOULD in Section 10 and the RECOMMENDED in Section 7.3 seem to be unsupported.  Why might an implementer choose not to do what they say?  What's the impact to interoperability?

I echo Roman's question about the document's status.

I support Roman's discuss, and note the mailing list suggestion from Dhruv that applies to -34

https://mailarchive.ietf.org/arch/msg/pce/j8b6_YwVZ4rzeewgnWVVzN2txzw/

It would be nice to see some definition around what a successful or failed experiment would look like in this context.

Thank you to Mallory Knodel for the GENART review.

Thank for addressing my COMMENT and DISCUSS feedback.

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

I have following comment/question though -

 - In section 6.1 it says - 

              "The PCInitiate message SHOULD be sent to PCC which is acting as BGP router and/or RR."
   
   In Section 6.2 it says -

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

   To me it seems like there is not way to bypass those SHOULDs and get the route and session establishment procedure done. If that understanding is correct then what are the exceptionsthiking about to let the implementers skip that part? Also, if this understand is not true, then I would expect this document to give warnings on the effects of skiping the PCInitiate messages.

# Éric Vyncke, INT AD, comments for draft-ietf-pce-pcep-extension-native-ip-34

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Dhruv Dhody for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


# COMMENTS (non-blocking)

## Abstract

s/This document describes/This document defines/ as this is an experimental document ?

## Section 1

`native IP` could be defined in a couple of words for readers not familiar to RFC 8735.

Should PCE & PCC be expanded on first use even if they are listed in https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list ? E.g., PCEP is expanded while it is on the list.

## Section 6.4

Please add a reference to `IPinIP tunnel` as there are various encapsulations defined by the IETF.

## Section 7.2

Should the local/peer addresses be qualified as unicast (as opposed to multicast) ? Can those addresses be link-local ? (possibly applicable to other sections)

## Section 7.4

Suggest making a specific "For IPv4" similar to the current "For IPv6" as opposed to common fields such as No of Prefixes, ...

## Section 12

I wonder whether an implementation section referring to implementation in preparation or simulations is really useful. See also RFC 7492.

## Section 14

Suggest adding the URI of the various registries to be super clear, e.g., https://www.iana.org/assignments/pcep/pcep.xhtml#pcep-path-setup-types

# NITS (non-blocking / cosmetic)

Sometimes "bytes" is written capitalized as "Bytes" without any reason.