Hi Matthew,
Thanks for the feedback.
On Tue, Oct 15, 2024 at 6:33 PM Matthew Bocci via Datatracker <
nore...@ietf.org> wrote:
> Reviewer: Matthew Bocci
> Review result: Has Nits
>
> 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
>
>
Dhruv: Ack
> 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.
>
>
Dhruv: I think the original text with the references makes sense to talk
about MPLS as none of those RFC is thinking beyond MPLS. I have added a
sentence to talk about SR - "[RFC8664] and [RFC9603] extend PCEP to support
Segment Routing in MPLS and IPv6 respectively." and later in section 6
mentioned that SRv6 is covered in another document.
> [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.
>
>
Dhruv: RFC8664 allows MSD to be carried in PCEP independently and exchanged
during the PCEP session establishment in the open message as per -
https://www.rfc-editor.org/rfc/rfc8664.html#section-4.1.1; this is used
when the IGP MSD is somehow unknown at the PCE. But you are correct that
this should be marked read-only.
I have uploaded a -26 revision. See
https://author-tools.ietf.org/iddiff?url1=draft-ietf-pce-pcep-yang-25&url2=draft-ietf-pce-pcep-yang-26&difftype=--html
Thanks!
Dhruv
_______________________________________________
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org
