@Matthew Bocci (Nokia)<mailto:matthew.bo...@nokia.com> Many thanks for the review
@Dhruv Dhody<mailto:d...@dhruvdhody.com>, authors, I’ve moved the document into IETF LC for further review withing the draft processing pipeline. Be well and many thanks for all the hard work G/ From: Matthew Bocci (Nokia) <matthew.bo...@nokia.com> Sent: Tuesday, October 22, 2024 1:04 PM To: Dhruv Dhody <d...@dhruvdhody.com> Cc: rtg-...@ietf.org; draft-ietf-pce-pcep-yang....@ietf.org; pce@ietf.org Subject: Re: Rtgdir early review of draft-ietf-pce-pcep-yang-25 Hi Dhruv Thanks. Looks good to me. Best regards Matthew From: Dhruv Dhody <d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>> Date: Saturday, 19 October 2024 at 12:31 To: Matthew Bocci (Nokia) <matthew.bo...@nokia.com<mailto:matthew.bo...@nokia.com>> Cc: rtg-...@ietf.org<mailto:rtg-...@ietf.org> <rtg-...@ietf.org<mailto:rtg-...@ietf.org>>, draft-ietf-pce-pcep-yang....@ietf.org<mailto:draft-ietf-pce-pcep-yang....@ietf.org> <draft-ietf-pce-pcep-yang....@ietf.org<mailto:draft-ietf-pce-pcep-yang....@ietf.org>>, pce@ietf.org<mailto:pce@ietf.org> <pce@ietf.org<mailto:pce@ietf.org>> Subject: Re: Rtgdir early review of draft-ietf-pce-pcep-yang-25 CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi Matthew, Thanks for the feedback. On Tue, Oct 15, 2024 at 6:33 PM Matthew Bocci via Datatracker <nore...@ietf.org<mailto: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
