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
>