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

Dhruv Dhody <dhruv.ietf@gmail.com> Thu, 04 February 2021 10:13 UTC

Return-Path: <dhruv.ietf@gmail.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 347503A11AC for <opsawg@ietfa.amsl.com>; Thu, 4 Feb 2021 02:13:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 sRR63mfX50fe for <opsawg@ietfa.amsl.com>; Thu, 4 Feb 2021 02:13:26 -0800 (PST)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B2B73A11A8 for <opsawg@ietf.org>; Thu, 4 Feb 2021 02:13:26 -0800 (PST)
Received: by mail-io1-xd36.google.com with SMTP id u8so2523346ior.13 for <opsawg@ietf.org>; Thu, 04 Feb 2021 02:13:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YBz6KVdlpVbMJuy2MO5Az0Bl0BNOUrmGrYNZK7EA7gQ=; b=Fml5hHZtfWdBdjaGIQc3gWwE1z21juHwF9rEQOcWO4U4FuLtnspxjzE6aILuVLwncN E0Cmt66HkTLGW38Y1isKbElTOIAaQ+yBT52z2X41/HtUUpc0RDwahW+gXlR38ryKN8ee LqT3oxxYcjg1gKR8GDi7/jajAhdAcKppRWJ+R5+3cg8ix76JszSoIUXzXPtDuT7Rf56K Dn4tzeO7YBz2YKgqiYpyaXz8MMlbwJ42yn2ebpOeBWcLC8nIV+ELX8xuIgQA1e2qRXoA mY3uw7oLPnnneTkMJh4vSrFWgpNGSO2AQVjSD3erZZRLG1IUg5x4p8i3Fx8RSf2/uVbI OzLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YBz6KVdlpVbMJuy2MO5Az0Bl0BNOUrmGrYNZK7EA7gQ=; b=CH3E4ewCcdhXPKXSB901H2DwnZsrLvoGUcHUzS20I1fEwFuWnCyBBDMyl9w4v3Kfo4 FzfqUK0e1lkYM7YGpYZ0lC/s14usbctHeXn0uZ+Mu4ES3gIh/ckzthC4mB1e38PImInx mZ8/0V0J9EOC1FfdssdGAxetg5y+3BcUxo7StTnAk3FDJeW15TDAMgs/qbR0XyeDPu1z LrngAch8+N6NbUSOTMgqT3sA+ng4q7pMHsQjYdKqMycjsDZRa6caXlwo2t2ogbsl6goE 2HJ9mXkRVz2ZtxqA7qoVJyZJ7rbgWNCxxYgVYxdxIM4OtTj/bMQxipJULbMjTURWoZa7 JVeg==
X-Gm-Message-State: AOAM531hkfbTbzVPY9Fq03JEKf57UKdJc1ikgVdUnWa/rcDoNiaapriz OD6IZyxew4XraIruRwXPCr3CYLQVz1MLKqHruTq3kLfiI9b9Sw==
X-Google-Smtp-Source: ABdhPJwLSGrtWHjK+lPBnu1n/VZjwDe0yxYwt67Zx9141gjnbGwhWqMx7JT5X+R+VXsqUKXcWyT5x1SwHhAwozXLOGw=
X-Received: by 2002:a05:6638:14d5:: with SMTP id l21mr7342312jak.54.1612433605361; Thu, 04 Feb 2021 02:13:25 -0800 (PST)
MIME-Version: 1.0
References: <BN6PR11MB1667915097EED9DE1047100DB8B99@BN6PR11MB1667.namprd11.prod.outlook.com>
In-Reply-To: <BN6PR11MB1667915097EED9DE1047100DB8B99@BN6PR11MB1667.namprd11.prod.outlook.com>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Thu, 04 Feb 2021 15:42:49 +0530
Message-ID: <CAB75xn7GHu8oJAePj9K+3csXNCD6kke_wX8b_WjAvHVx4sk9jA@mail.gmail.com>
To: "Joe Clarke (jclarke)" <jclarke=40cisco.com@dmarc.ietf.org>
Cc: "opsawg@ietf.org" <opsawg@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004582cf05ba7ff4c3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/h2GSaWOm8FUNZakiT1JCDZFwtlE>
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: Thu, 04 Feb 2021 10:13:29 -0000

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.

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

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

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


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

(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


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

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

(c)

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

Shouldn't this be config false?


==

Suggestion:

Can we add an example of how percentile is used and reported in the
appendix?

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> 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
> https://www.ietf.org/mailman/listinfo/opsawg
>