[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
- [RTG-DIR]Rtgdir early review of draft-ietf-pce-pc… Matthew Bocci via Datatracker
- [RTG-DIR]Re: Rtgdir early review of draft-ietf-pc… Dhruv Dhody
- [RTG-DIR]Re: Rtgdir early review of draft-ietf-pc… Matthew Bocci (Nokia)