Re: [OPSAWG] RtgDir Early review: draft-ietf-opsawg-yang-vpn-service-pm

"Wubo (lana)" <lana.wubo@huawei.com> Tue, 17 May 2022 10:01 UTC

Return-Path: <lana.wubo@huawei.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 98696C14F748; Tue, 17 May 2022 03:01:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.896
X-Spam-Level:
X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 GHMDBydYgLWb; Tue, 17 May 2022 03:01:27 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D95FFC14792F; Tue, 17 May 2022 03:00:32 -0700 (PDT)
Received: from fraeml739-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4L2Wkc6Tv5z6H7Y7; Tue, 17 May 2022 17:57:28 +0800 (CST)
Received: from kwepemi100014.china.huawei.com (7.221.188.106) by fraeml739-chm.china.huawei.com (10.206.15.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 17 May 2022 12:00:29 +0200
Received: from kwepemi500014.china.huawei.com (7.221.188.232) by kwepemi100014.china.huawei.com (7.221.188.106) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 17 May 2022 18:00:27 +0800
Received: from kwepemi500014.china.huawei.com ([7.221.188.232]) by kwepemi500014.china.huawei.com ([7.221.188.232]) with mapi id 15.01.2375.024; Tue, 17 May 2022 18:00:27 +0800
From: "Wubo (lana)" <lana.wubo@huawei.com>
To: Dhruv Dhody <dd@dhruvdhody.com>, "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>
CC: "opsawg@ietf.org" <opsawg@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>
Thread-Topic: RtgDir Early review: draft-ietf-opsawg-yang-vpn-service-pm
Thread-Index: AQHYZb8GMnTRk3TS6UanICvAc8ByuK0i1JQA
Date: Tue, 17 May 2022 10:00:27 +0000
Message-ID: <5610f5510ead4ffc8539ae2273c0f44e@huawei.com>
References: <CAP7zK5ZbZqC9VX3GW9tJK8p+QpM8m5Mm81oUPxpb-ipMfNTHVg@mail.gmail.com>
In-Reply-To: <CAP7zK5ZbZqC9VX3GW9tJK8p+QpM8m5Mm81oUPxpb-ipMfNTHVg@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.98.73]
Content-Type: multipart/alternative; boundary="_000_5610f5510ead4ffc8539ae2273c0f44ehuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/SrPo9ODtNb469A1GSVRnucvkPnM>
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: Tue, 17 May 2022 10:01:31 -0000

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

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