[RTG-DIR] RtgDir Early review: draft-ietf-opsawg-yang-vpn-service-pm

Dhruv Dhody <dd@dhruvdhody.com> Thu, 12 May 2022 05:13 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 AB8C1C15EB27 for <rtg-dir@ietfa.amsl.com>; Wed, 11 May 2022 22:13:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 th9qg-J9GrKM for <rtg-dir@ietfa.amsl.com>; Wed, 11 May 2022 22:13:03 -0700 (PDT)
Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 F1911C159526 for <rtg-dir@ietf.org>; Wed, 11 May 2022 22:13:03 -0700 (PDT)
Received: by mail-pf1-x436.google.com with SMTP id x52so3771173pfu.11 for <rtg-dir@ietf.org>; Wed, 11 May 2022 22:13:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dhruvdhody-com.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to:cc; bh=1EAnUlZltclFVz1bQQ7b0k+5sMB59FyhF3L8lsd4wHM=; b=3CBHRB11MXcOkn7z1B0bVYmxO+SxyRKWDg/jWeGZQHS9ODsFtSMkgeY+9IWfvf7Bjn 6sDonYDJ0utgbdWJh23bcZUDkON7z9KyBc27QQExyL91AX6VKwKRMJuA9UZEf1DIwwlu Sp3Vnf0K0AF7IVq53NxRUJExsDGIJPwwYHh4nFVrpT/92/oBxlTjciiwQlF5FwJ7ae7Y jQy6p8EjdlP085uW/YiBaXbMo8/pYrRE4oRVAS0gOn0LUqPDMINXumQOBceWadqTDziQ gUZJwrtmcgMrZz9ddixVw//JAoc/YyEsMT2Okt/wpi5elCcqjmAu5kXLd7gYxq4ytugA tbAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=1EAnUlZltclFVz1bQQ7b0k+5sMB59FyhF3L8lsd4wHM=; b=kLVOGIxjA4mCUaEUECRxwzWqDW+HBR1zwiT5dj4UseVHSC+zFuGaAQRlV1ylD1W6Na aHCps+noSNZWV0FJHO66pXHu/dB3cvO2WsEQo1RMJmIo6PfitjM94+dMyV8SEjejoahS uDopfRMn+rFv14MEDCc6G+NNw0UuE/1fHrNvX6ZmxRkPGvGUbBnRtXSgaCe0vpNHzMZf MyVAXk/gwbcUSAGyzMIz/0HZVwKJpyYnbzVIBfmKjvOZvfHB58sDfATDc4TcLFIf/ybj uAYQJXqOss4cDWKJPIn9p8lDKKl1yh0X9W6u6IFSGvASEyp8VoIl4mLw2WhkP8+TYSbO ZWGg==
X-Gm-Message-State: AOAM530y4v8A0hom54rTRhWJNSAYO24SVPuN+7aMHA5WtmEUOvtnx2cO 17Xf9SR0CP+xHxhI0X2MDkmHD99JsXIpOFpNVV3MryguRVdlKdL6
X-Google-Smtp-Source: ABdhPJzNg1NAw67/WGinhkCOwe1OC+IWfBiLwZxNRlBxIQQKMOtp1I1cJ45fFsg0vd2IVH3LhDpjl815IMN8O+42E7s=
X-Received: by 2002:a63:1d13:0:b0:3c5:f9bb:cb6e with SMTP id d19-20020a631d13000000b003c5f9bbcb6emr23580627pgd.98.1652332382881; Wed, 11 May 2022 22:13:02 -0700 (PDT)
MIME-Version: 1.0
From: Dhruv Dhody <dd@dhruvdhody.com>
Date: Thu, 12 May 2022 10:42:26 +0530
Message-ID: <CAP7zK5ZbZqC9VX3GW9tJK8p+QpM8m5Mm81oUPxpb-ipMfNTHVg@mail.gmail.com>
To: draft-ietf-opsawg-yang-vpn-service-pm.all@ietf.org, opsawg-chairs@ietf.org
Cc: opsawg@ietf.org, rtg-dir@ietf.org
Content-Type: multipart/alternative; boundary="000000000000bb9f0e05dec99c4f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/RCN_abICmKUplPi4E7vU-LbA7ps>
X-Mailman-Approved-At: Fri, 13 May 2022 02:13:24 -0700
Subject: [RTG-DIR] RtgDir Early review: draft-ietf-opsawg-yang-vpn-service-pm
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 May 2022 05:13:05 -0000

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?

*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?

*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?

*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"?

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".

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?

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?

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)

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?


Thanks!
Dhruv