[RTG-DIR]Re: Rtgdir early review of draft-ietf-pce-pcep-yang-25

Dhruv Dhody <dd@dhruvdhody.com> Sat, 19 October 2024 11:31 UTC

Return-Path: <dd@dhruvdhody.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A12B9C180B40 for <rtg-dir@ietfa.amsl.com>; Sat, 19 Oct 2024 04:31:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dhruvdhody-com.20230601.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_wX84y1Lx6f for <rtg-dir@ietfa.amsl.com>; Sat, 19 Oct 2024 04:30:56 -0700 (PDT)
Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD605C18DB84 for <rtg-dir@ietf.org>; Sat, 19 Oct 2024 04:30:56 -0700 (PDT)
Received: by mail-ot1-x336.google.com with SMTP id 46e09a7af769-7180db718ecso68190a34.3 for <rtg-dir@ietf.org>; Sat, 19 Oct 2024 04:30:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dhruvdhody-com.20230601.gappssmtp.com; s=20230601; t=1729337456; x=1729942256; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=GqnxmFq0HrKoGL2EIfYqqzXeRGK+H1WwrGGU3xfGN8Y=; b=LIxlGe//i/suddfyQ595HC2BFOOziyZqbPrZYmP8Bam6gXBgIWg2VrnxaFFxOarKCa Mf6vyFP4V2tOLVnppjYRufJ3syJpEpq0bWbUW3uVaKEOSiSTqCaoxWAZ6BuvXP5ASkUV TOHCrCS8t0TDjsGHSLckOPcN6vK+4vJNgrsWh64OB9if33w4CqToerSgQa2kizPrGZBF mBMD+nP8v4Z8PCnsDhRkIP8KQUsLqdejchvGAmY4Jpywly05ngJgwdxAoRECaI5ZdX9S N56zqRveI0zrJxy62Or9zhKBIeYStIrizNRzA9tJUmz6FsVVr7mm7uSTbT3q3Q9fnWzN milg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729337456; x=1729942256; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GqnxmFq0HrKoGL2EIfYqqzXeRGK+H1WwrGGU3xfGN8Y=; b=B9M91bmDNNAUnf7mRoWGwsOpHMyoS4/swh5HeOjvPr6rlGdRR/3oW3Tv95kFkEtzxq Ii3fTvKFu42dIrgzIY9mdqeT10h+BGP6EprpKGemTB7SRQ8SQaEG9ZcuXA3ASRd0gVtZ gLsZsDHIMRe4hagQvykqzNFpDBmX2ZeIItpLzrseUwJCpO5cYIF1HjsBXUY/ZSe7489Z CIHLPQr7TS2vsLVNdPYBLdSd1CY1rh0dZi2Zu6mbubULctOWlg7XcWSZ4/06gaTy6qB6 PupVUTYWzZA7KhK884EA+HzFhznC3Ueoie/uC1BvqcSRoYHUzwJx+G8RIDhq+HAaHpve AsVw==
X-Gm-Message-State: AOJu0YypWcFlqCUH8I2FgYjMp2QuMLW8wtWr8gP7cWD3vo5zhFCBBCzk Fy8Zp53NIi5wZz/80xH/exP254sTBloagJjT+wDl00s1VhDQOg+jBs30WNKUEnvudoBX2hdGuwa txyVqF+tJTPBy8d0hES+EpvoM+wpPN4YbUUvpHw==
X-Google-Smtp-Source: AGHT+IHpkg7OwQ5RBYdcqNDPop889ldTZAsYb0KhPlqu7y25J0ACFLYeAI0hmowZ1Of/6D8eXlGHfLksaKh3MkNW9nM=
X-Received: by 2002:a05:6870:e2cb:b0:27c:dfa9:3cf3 with SMTP id 586e51a60fabf-2892bf07a2cmr1215007fac.0.1729337455659; Sat, 19 Oct 2024 04:30:55 -0700 (PDT)
MIME-Version: 1.0
References: <172899741008.1013253.9166432356869610013@dt-datatracker-78dc5ccf94-w8wgc>
In-Reply-To: <172899741008.1013253.9166432356869610013@dt-datatracker-78dc5ccf94-w8wgc>
From: Dhruv Dhody <dd@dhruvdhody.com>
Date: Sat, 19 Oct 2024 17:00:19 +0530
Message-ID: <CAP7zK5ZTWTNCqrEPhgGcZhwbA=rbskbL410DF1RfwMxeVNg3PA@mail.gmail.com>
To: Matthew Bocci <matthew.bocci@nokia.com>
Content-Type: multipart/alternative; boundary="000000000000bde8c60624d2c06f"
Message-ID-Hash: WZJWG5J54IPRDJGI6YR7KVU2MUKV7URK
X-Message-ID-Hash: WZJWG5J54IPRDJGI6YR7KVU2MUKV7URK
X-MailFrom: dd@dhruvdhody.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-rtg-dir.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: rtg-dir@ietf.org, draft-ietf-pce-pcep-yang.all@ietf.org, pce@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [RTG-DIR]Re: Rtgdir early review of draft-ietf-pce-pcep-yang-25
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/yhPKc0nAfZGzZLyFi8qmfPIZmM0>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Owner: <mailto:rtg-dir-owner@ietf.org>
List-Post: <mailto:rtg-dir@ietf.org>
List-Subscribe: <mailto:rtg-dir-join@ietf.org>
List-Unsubscribe: <mailto:rtg-dir-leave@ietf.org>

Hi Matthew,

Thanks for the feedback.

On Tue, Oct 15, 2024 at 6:33 PM Matthew Bocci via Datatracker <
noreply@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