Re: [OPSAWG] CALL FOR ADOPTION: draft-www-opsawg-yang-vpn-service-pm

"Wubo (lana)" <lana.wubo@huawei.com> Fri, 05 February 2021 08:40 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 06D293A1D92 for <opsawg@ietfa.amsl.com>; Fri, 5 Feb 2021 00:40:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaFdC73LXQmx for <opsawg@ietfa.amsl.com>; Fri, 5 Feb 2021 00:40:31 -0800 (PST)
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 042B93A1D8E for <opsawg@ietf.org>; Fri, 5 Feb 2021 00:40:31 -0800 (PST)
Received: from fraeml739-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4DX7zN5J3mz67krJ; Fri, 5 Feb 2021 16:35:44 +0800 (CST)
Received: from dggeme704-chm.china.huawei.com (10.1.199.100) by fraeml739-chm.china.huawei.com (10.206.15.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2106.2; Fri, 5 Feb 2021 09:40:28 +0100
Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by dggeme704-chm.china.huawei.com (10.1.199.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Fri, 5 Feb 2021 16:40:26 +0800
Received: from dggeme752-chm.china.huawei.com ([10.6.80.76]) by dggeme752-chm.china.huawei.com ([10.6.80.76]) with mapi id 15.01.2106.006; Fri, 5 Feb 2021 16:40:26 +0800
From: "Wubo (lana)" <lana.wubo@huawei.com>
To: Dhruv Dhody <dhruv.ietf@gmail.com>, "Joe Clarke (jclarke)" <jclarke=40cisco.com@dmarc.ietf.org>
CC: "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: [OPSAWG] CALL FOR ADOPTION: draft-www-opsawg-yang-vpn-service-pm
Thread-Index: Adb7jfHTAGjeoE4ySVyaliqonMcFTA==
Date: Fri, 05 Feb 2021 08:40:26 +0000
Message-ID: <779448a421934b21ac35edf102989a2b@huawei.com>
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.99.137]
Content-Type: multipart/alternative; boundary="_000_779448a421934b21ac35edf102989a2bhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/2X2xbRqy7fTlIJCrlJlicwp5lQY>
Subject: Re: [OPSAWG] CALL FOR ADOPTION: draft-www-opsawg-yang-vpn-service-pm
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 05 Feb 2021 08:40:34 -0000

Hi Dhruv,

Thanks for the detailed review, please see inline.

Best regards,
Bo

发件人: OPSAWG [mailto:opsawg-bounces@ietf.org] 代表 Dhruv Dhody
发送时间: 2021年2月4日 18:13
收件人: Joe Clarke (jclarke) <jclarke=40cisco.com@dmarc.ietf.org>
抄送: opsawg@ietf.org
主题: Re: [OPSAWG] CALL FOR ADOPTION: draft-www-opsawg-yang-vpn-service-pm

Hi,

The work seems to be quite useful. I support adoption by the WG.

A few comments -

(1) If the model supports L2VPN, I think we need to add the L2-level counters in the vpn-summary-statistics. Currently we only have IPv4 and IPv6 routes.
[Bo] Thanks, will add MAC-address-limit counters for L2VPN.


(2) Section 3

   The performance monitoring information reflecting the quality of the
   Network or VPN service such as end to end network performance data
   between source node and destination node in the network or between
   VPN sites can be aggregated or calculated using, for example, PCEP
   solution [RFC8233] [RFC7471] [RFC8570] [RFC8571] or LMAP [RFC8194].

I suggest changing "PCEP" to more generic term "Traffic Engineering Database (TED)".
[Bo] OK, will update.


(3) Section 3.2

3.2.  On demand Retrieval via RPC Model

   To obtain a snapshot of a large amount of performance data from a
   network element (including network controllers), service-assurance
   applications may use polling-based methods such as RPC model to fetch
   performance data on demand.

Do you mean the usual Netconf <get>? Not sure about the term "RPC model". Maybe refer to it as just polling mechanism.
[Bo] Yes. Thanks for pointing this out, will fix this to refer to the polling mechanism.


(4) Section 4.1

I am not sure about the depiction of how PE map to CE and further map to Nodes in the underlying network in Figure 3.

In the YANG we have node-type that can be PE, CE, or P and this figure does not help. Its possible I might be seeing it wrong :)

Also the mapping in the figure and the text for Node 3 and 4 don't match.

In "Site-2 A and B play the role of hub while Site-2 C plays the role of spoke.", did you intend to have 2 hub and 1 spoke?
[Bo] Thanks for catching this. Will fix the figure the text.



(5) Section 4.2

   For network performance monitoring, the attributes of "Network Level"
   that defined in [RFC8345] do not need to be extended.

[RFC8345] does not use the term "Network Level". I am wondering if we should use the full path /nw:networks/nw:network/ or container name instead...

Also applicable to 4.3

The "vpn-id" is just a string and would also depend on the network-service-type (L3VPN, L2VPN); IMHO some text to describe this is needed.

[Bo] Will update as you suggested.

(6) Section 4.3

Not clear on why node-type is marked as (Attribute) but site-id and site-role are (Constraint).

Can you expand on "site-id", is this matching with L3SM site-id or L3NM's vpn-network-access?

The type should be yang:counter32 instead of uint32 for -

       +--rw vpn-summary-statistics
          +--rw ipv4
          |  +--rw total-routes?          uint32
          |  +--rw total-active-routes?   uint32
          +--rw ipv6
             +--rw total-routes?          uint32
             +--rw total-active-routes?   uint32

[Bo] Thanks for catching the errors. “Constraint” will be corrected to ”Attribute“.

For the “site-id”, in most cases, it refers to L3NM's ne-id. In the case of provider-managed CE, it may refers to L3SM site-id.


(7) Section 7

(a)

  identity link-type {
    base vpn-common:protocol-type;
    description
      "Base identity for link type, e.g.,GRE, MPLS TE, VXLAN.";
  }

  identity VXLAN {
    base link-type;
    description
      "Base identity for VXLAN Tunnel.";
  }

  identity ip-in-ip {
    base link-type;
    description
      "Base identity for IP in IP Tunnel.";
  }

What is the benefit of creating link-type as an identity? Can VXLAN and ip-in-ip directly use vpn-common:protocol-type as a base?
[Bo] Thanks for the suggestion. We can directly use vpn-common:protocol-type as the tunnel encapsulation type.


(b)

    leaf outbound-qlen {
      type uint32;
      description
        " Length of the queue of the interface from where
          the packet is forwarded out.  The queue depth could
           be the current number of memory buffers used by the
          queue and a packet can consume one or more memory buffers
          thus constituting device-level information.";
    }
    description
      "Grouping for interface service telemetry.";
  }

Since these are abstract nodes how do we know this information?
[Bo] We will remove this. This is from the initial discussion on  rfc8532(Generic YANG Data Model for the Management of OAM Protocols That Use Connectionless Communications) . But the published RFC has removed this definition.


(c)

    leaf reference-time {
      type yang:date-and-time;
      description
        "The time that the current Measurement Interval started.";
    }

Shouldn't this be config false?
[Bo] Agree. Thanks, will update.



==

Suggestion:

Can we add an example of how percentile is used and reported in the appendix?
[Bo] Thanks. Will add the example.


Hope you find these comments useful.

Thanks!
Dhruv

On Fri, Jan 29, 2021 at 7:49 PM Joe Clarke (jclarke) <jclarke=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>> wrote:
Hello, WG.  The draft-www-opsawg-yang-vpn-service-pm (A YANG Model for
Network and VPN Service Performance Monitoring) work has been steadily
progressing with the other VPN network model work.  This was presented
last at IETF 109
(https://datatracker.ietf.org/doc/slides-109-opsawg-a-yang-model-for-network-and-vpn-service-performance-monitoring/),
and there has been some recent discussion on list that has been
addressed by the authors.  We would like to know if the working group
wants to formally adopt this work.

Please respond with your comments and thoughts on the draft.  We will
conduct a two week CFA, concluding on February 12, 2021.

Joe (on behalf of co-chairs)

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org<mailto:OPSAWG@ietf.org>
https://www.ietf.org/mailman/listinfo/opsawg