Re: [OPSAWG] RtgDir Early review: draft-ietf-opsawg-yang-vpn-service-pm
Dhruv Dhody <dd@dhruvdhody.com> Sat, 21 May 2022 11:15 UTC
Return-Path: <dd@dhruvdhody.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E10C185B1E for <opsawg@ietfa.amsl.com>; Sat, 21 May 2022 04:15:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.893
X-Spam-Level:
X-Spam-Status: No, score=-6.893 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, 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.20210112.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 zfG2lw9Fm1J7 for <opsawg@ietfa.amsl.com>; Sat, 21 May 2022 04:15:29 -0700 (PDT)
Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA7D6C185B24 for <opsawg@ietf.org>; Sat, 21 May 2022 04:15:29 -0700 (PDT)
Received: by mail-pj1-x102c.google.com with SMTP id nr2-20020a17090b240200b001df2b1bfc40so13484095pjb.5 for <opsawg@ietf.org>; Sat, 21 May 2022 04:15:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dhruvdhody-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nhr8M8frZt3GL/BmBNPnxKMwOCtrWmaYeLrHf9zf6ww=; b=KyrSYjEu1700tUp2kyDW34Ts4/JEvK/k8CWxHdHlnr03E6iWazMxdYCVWEx4CBtzYd ZwWZsZ/Ee1Ug+HUI2wag9PAfDE2fcJ+V5OUybujsWWWe62hHWgT/rEQRqHThVKurrlPs SMzBgwHGR7skZ6nX3IBuNf+PmMf8LxwcOO0xYxu5Tl3cfu1mBmr9PthZYxYM+FOQZsBl 49Koks3nv1rO4DKhpGpSgSuYTzGiN1OHUI/D0zcaQxlIhsJSx3+5QTT7h/bM9iK9StFy h1kORjOP6dZlzO+d0xXiWuLngD4TVyuf71QISd36aKbX1mCp9yxKKDHmIlKknBrIT/JE VA8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nhr8M8frZt3GL/BmBNPnxKMwOCtrWmaYeLrHf9zf6ww=; b=duDMJcMAe3s9p2YMqKjRMxLDLHT+cLKMC1r89/oi+qiQkMJsy6jjOzQ5tjiO1S/gV2 0zGWuMVf54jjCJI3xFrLYcJkduTpy76PxlbgFrE4r8UrHxE++7EyAvThIvxJuSpTawHg AgBP3OxH3NboxJ0mBStPpx1njbE2JObmLYohIwceTSjJ3TIVxEtxeDC5RlOA4/XQR7IP WPUibAyYr6kerORxOHQL5oTIw3NyJzxZ0sAtT/OyjCeYWNOfpikkjAb/GpYtfkcvo4lF DH/YiacO8SF8ZWmKHv2YdlnKXjrvy932Yxi6JOTs5BkxfoikzysS8pSz03//GeoPm07g eRPA==
X-Gm-Message-State: AOAM533ZCDZ8SRecsapXekPB38Nto1h7lXGOEWAYVwj4dTRWRVCpoW14 5Q0wdGzMZz/zBPQ05pLWnYZO7jvmaa72BJlx9cRC3w==
X-Google-Smtp-Source: ABdhPJw9cGBLZlYTxAthQSvi1HHleKEG3esLi7mZgHed2ioim1ZQamIEIR4mgqddxqCuMJv8gms9cJJzdrM8BIrXFM4=
X-Received: by 2002:a17:90a:688a:b0:1df:6940:e83e with SMTP id a10-20020a17090a688a00b001df6940e83emr15634354pjd.120.1653131728812; Sat, 21 May 2022 04:15:28 -0700 (PDT)
MIME-Version: 1.0
References: <CAP7zK5ZbZqC9VX3GW9tJK8p+QpM8m5Mm81oUPxpb-ipMfNTHVg@mail.gmail.com> <5610f5510ead4ffc8539ae2273c0f44e@huawei.com>
In-Reply-To: <5610f5510ead4ffc8539ae2273c0f44e@huawei.com>
From: Dhruv Dhody <dd@dhruvdhody.com>
Date: Sat, 21 May 2022 16:45:16 +0530
Message-ID: <CAP7zK5ZmaqAgt6z3PS9SadWwJsDj-eCigxAyoAYXgvDAg+A1bg@mail.gmail.com>
To: "Wubo (lana)" <lana.wubo@huawei.com>
Cc: "draft-ietf-opsawg-yang-vpn-service-pm.all@ietf.org" <draft-ietf-opsawg-yang-vpn-service-pm.all@ietf.org>, "opsawg-chairs@ietf.org" <opsawg-chairs@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007690ec05df83b9ca"
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/pJGqSQvtzcucSycv2wkT37iRIig>
X-Mailman-Approved-At: Sat, 21 May 2022 06:48:30 -0700
Subject: Re: [OPSAWG] RtgDir Early review: draft-ietf-opsawg-yang-vpn-service-pm
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 May 2022 11:15:30 -0000
Thanks Bo, the update looks great!! On Tue, 17 May 2022 at 3:31 PM, Wubo (lana) <lana.wubo@huawei.com> wrote: > *Hi Dhruv,* > > > > *Thanks for the helpful review. The rev-09 has submitted to resolve your > comments, please check whether you have further comments.* > > *https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-09 > <https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-09>* > > > > *Please also see inline for the replies..* > > > > *Thanks,* > > *Bo* > > > > *From:* Dhruv Dhody [mailto:dd@dhruvdhody.com] > *Sent:* Thursday, May 12, 2022 1:12 PM > *To:* draft-ietf-opsawg-yang-vpn-service-pm.all@ietf.org; > opsawg-chairs@ietf.org > *Cc:* opsawg@ietf.org; rtg-dir@ietf.org > *Subject:* RtgDir Early review: draft-ietf-opsawg-yang-vpn-service-pm > > > > Hello > > I have been selected to do a routing directorate “early” review of this > draft. > > The routing directorate will, on request from the working group chair, > perform an “early” review of a draft before it is submitted for publication > to the IESG. The early review can be performed at any time during the > draft’s lifetime as a working group document. The purpose of the early > review depends on the stage that the document has reached. > > As this document is post-working group last call, my focus for the review > was to determine whether the document is ready to be published. Please > consider my comments along with the other last call comments. > > For more information about the Routing Directorate, please see > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > > Document: draft-ietf-opsawg-yang-vpn-service-pm > Reviewer: Dhruv Dhody > Review Date: 2022-05-12 > IETF LC End Date: Unknown > Intended Status: Standards Track > > > *Summary: *I have some minor concerns about this document that I think > should be resolved before publication. > > > *Comments: *The document is easy to read. The YANG model seems to be > useful for VPN service assurance and is well-formatted. > > *Major Issues:* > > None > > > > *Minor Issues:* > > Earlier vpn-pm-type was a choice, it was changed in the -08 version and > now both inter-vpn-access-interface and underlay-tunnel can be configured > together. In the draft text, it states that "usually only one of the two > methods is used". But the YANG allows both of them to be configured at the > same time. > > > > +--rw vpn-pm-type > +--rw inter-vpn-access-interface > | +--rw inter-vpn-access-interface? empty > +--rw underlay-tunnel! > +--ro vpn-underlay-transport-type? identityref > > > > It is not clear to me how to interpret the measured PM delay value? Is it > the VPN access interface or for the underlay tunnel? Maybe you should allow > only one of them to be configured at a time? > > *[Bo Wu] We think both measurements are not conflicting and should allow. * > > *How about adding a new read-only leaf "pm-type", that tells if the > reported values are based on which pm-type. * > > > > > > > *Query:* > > The vpn-underlay-transport-type in underlay-tunnel identifies the type of > underlay tunnel between the PEs. But isn't it possible to have multiple > types of tunnels and even load balancing between them? Is the assumption > that each instance of underlay tunnel would have its own link? > > *[Bo Wu] The assumption is the latter case. How about adding some text to > clarify:* > > *“In the case of multiple types of tunnels between a single pair of VPN > nodes, a separate link for each type of tunnel can be created.”* > > > > *Nits:* > > - Expand on first use: LMAP > > - Section 1: s/to display the// > > - Section 3.1: s/VPN service assurance model/VPN Service Performance > Monitoring/ > > - Section 4.1: s/and node 3 (N3)5/and node 3 (N3)/ > > - Section 4.2: Is this text correct - "For network performance monitoring, > the container of "networks" in [RFC8345 > <https://www.ietf.org/archive/id/draft-ietf-opsawg-yang-vpn-service-pm-08.html#RFC8345>] does > not need to be extended."? Or is "not" there by mistake? > > *[Bo Wu] Thanks. All fixed.* > > > > > > *YANG Model:* > > 1) > > identity pe { > base node-type; > description > "Provider Edge (PE) node type. A PE is the name of the device > or set of devices at the edge of the provider network with the > functionality that is needed to interface with the customer."; > } > > > > What do you mean by "the name of the device"? > > *[Bo Wu] Thanks, will remove “the name of”.* > > > 2) In the grouping entry-summary, the description says it for "VPN or > network" but for all the leaves (maximum-routes, total-active-routes, > mac-num etc) it says VPN only! Please update to "VPN or network". > > *[Bo Wu] Thanks. Fixed.* > > > > > > 3) > > leaf packet-loss-count { > type yang:counter64; > description > "Total received packet drops count."; > } > > Not sure about the description, it reads as if a packet is received but > dropped, and I don't think that is what you mean? > > *[Bo Wu] How about “Total number of lost packets.”?* > > > > > > > > 4) > > leaf reference-time { > type yang:date-and-time; > config false; > description > "Indicates the time when the statistics are collected."; > > } > > I am not sure what collected means here. Do you mean when the current > counters were last updated? Or when it was last aggregated/filtered at the > controller? > > *[Bo Wu] It means the former. How about replace the name to > “last-updated”, and also the description “Indicates the time when the > statistics were last updated”* > > > > 5) > > leaf inbound-nunicast { > type yang:counter64; > description > "The total number of inbound non-unicast > (i.e., broadcast or multicast) packets."; > } > > > > suggest changing the name to inbound-non-unicast (check other instances as > well) > > *[Bo Wu] OK. Thanks.* > > > > > > 6) > > leaf network-access-id { > > type vpn-common:vpn-id; > > description > > "References to an identifier for the VPN network > > access, e.g. L3VPN or VPLS."; > > } > > The description of network-access-id is not clear. Is it name of VPN? or the site-network-access-id in LxSM? > > *[Bo Wu] OK. Will remove the **“**e.g. L3VPN or VPLS.”.* > > > > > Thanks! > Dhruv >
- [OPSAWG] RtgDir Early review: draft-ietf-opsawg-y… Dhruv Dhody
- Re: [OPSAWG] RtgDir Early review: draft-ietf-opsa… Wubo (lana)
- Re: [OPSAWG] RtgDir Early review: draft-ietf-opsa… Dhruv Dhody