Early Review of draft-ietf-pce-pcep-yang-25
review-ietf-pce-pcep-yang-25-rtgdir-early-bocci-2024-10-15-00

Thanks for a clear an well written draft. I have reviewed this from the
perspective of my knowledge of PCEP and the way PCCs and PCEs generally work,
rather than going through the YANG with a fine-toothed comb, as I am not really
a YANG expert and I would hope that a YANG doctor's review would cover the
syntax and other correctness of the YANG. I have just a few nits/questions,
below, but otherwise I think the draft is ready for publication.

The line numbers are from the IDNits output.

[snip]
16      Abstract
18         This document defines a YANG data model for the management of Path

s / Path / the Path

19         Computation Element communications Protocol (PCEP) for communications

[snip]

91      1.  Introduction

93         The Path Computation Element (PCE) defined in [RFC4655] is an entity
94         that is capable of computing a network path or route based on a
95         network graph, and applying computational constraints.  A Path
96         Computation Client (PCC) may make requests to a PCE for paths to be
97         computed.

99         PCEP is the communication protocol between a PCC and PCE and is
100        defined in [RFC5440].  PCEP interactions include path computation
101        requests and path computation replies as well as notifications of
102        specific states related to the use of a PCE in the context of
103        Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
104        Traffic Engineering (TE).  [RFC8231] specifies extensions to PCEP to
105        enable stateful control of MPLS TE LSPs.

107        This document defines a YANG [RFC7950] data model for the management
108        of PCEP speakers.  It is important to establish a common data model
109        for how PCEP speakers are identified, configured, and monitored.  The
110        data model includes configuration data and state data.

112        This document contains a specification of the PCEP YANG module,
113        "ietf-pcep" which provides the PCEP [RFC5440] data model.  Further,
114        this document also includes the PCEP statistics YANG module "ietf-
115        pcep-stats" which provides statistics, counters and telemetry data.

117        The PCEP operational state is included in the same tree as the PCEP
118        configuration consistent with Network Management Datastore
119        Architecture (NMDA) [RFC8342].  The origin of the data is indicated
120        as per the origin metadata annotation.

MB> I take the above text to mean that this draft is a YANG model for PCEP when
the data plane is assumed to be MPLS. However, it doesn't quite say that. It
seems to imply that MPLS is the only valid data plane, when in fact SRv6 could
be used and there are drafts related to that. I would suggest rephrasing or
adding text to say the PCEP in general could be used with other data planes,
but we are only modelling MPLS here, or something along those lines. Just to
make it very clear what the scope of the model is.

[snip]
553              |  +--rw inter-layer?            boolean {inter-layer}?
554              |  +--rw h-pce {h-pce}?
555              |     +--rw enabled?    boolean
556              |     +--rw stateful?   boolean {stateful}?
557              |     +--rw role?       hpce-role
558              +--rw msd?                          uint8 {sr}?

MB> The model implies that a PCC could have a MSD configured that is different
from the MSD that is advertised in the IGP, for example. I thought MSD was
really a router/LER-wide property, determined by the underlying datapath
implementation, rather than something to configure, so should this not be YANG
state for the PCC (i.e. ro rather than rw )? This question is also applicable
to line 771 in the draft.