Re: [OPSAWG] Comments for draft-song-opsawg-ifit-framework-05.txt

<daniel@olddog.co.uk> Mon, 14 October 2019 20:13 UTC

Return-Path: <dk@danielking.net>
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 9ECCE120871 for <opsawg@ietfa.amsl.com>; Mon, 14 Oct 2019 13:13:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.688
X-Spam-Level: *
X-Spam-Status: No, score=1.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=danielking-net.20150623.gappssmtp.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 RSkBYPUncM2b for <opsawg@ietfa.amsl.com>; Mon, 14 Oct 2019 13:13:15 -0700 (PDT)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 73EE01200F7 for <opsawg@ietf.org>; Mon, 14 Oct 2019 13:13:15 -0700 (PDT)
Received: by mail-wr1-x42e.google.com with SMTP id j11so21147937wrp.1 for <opsawg@ietf.org>; Mon, 14 Oct 2019 13:13:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielking-net.20150623.gappssmtp.com; s=20150623; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=pCm9xvKRXXpwHJosP2HxRjDj4ahmd7ytSB5Mtb+G7w4=; b=egBFzOl8lSBdFFc9p4gu9Vpbr0iQig4tRA5PEmUApQzEO3lf8h5Eobxb2uV+8qvQ5X 1Eq5eQNmdUMosHAj1ImvlpYAHGn5ZMGhvRwBXgI9CRR/MmsQLhhBDhWQKhR+imUFMWZy Xf4JixL7LJpUOiBgqoRDIOcpFn6GL5g1ZMQiRXY49UTjeWU7uBfwHDweajgoU8EWe/Io EzEG1KWha6fqQu/frDraWoXs70tQSVUkHrFy8Kzrzt22zEYQzjTcJO1WwEX3gSy5+cLP 0Qx45h/B0xPv+tEfrqHG5hVLw5Jxg3CEp0TVHIxn7JldSgnVVwb9XWx8ia0k0Ec1m2Je EZcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=pCm9xvKRXXpwHJosP2HxRjDj4ahmd7ytSB5Mtb+G7w4=; b=MaUrzONdnHs0coG0Jn+UaelqJ/COyFZOwzVY2gg1/SPiMaXZSqCn2WTFVjbDL3K8pw ksQAQeFllRaaxp/n3r68Tl7tiHzHs+bYUVU0bCryZJN4MJZSdxh+Ncd0u2NZ2jAcKJUp sv8CbHdQMyTGuaqtKNJCwz66yxv4dSneUWBZq56AfxlXYcxG1jpwwI5tEuNYsV1REu4i +5QPaOKP+gcWDmeDo+wQXSOmZpEoYUqHv4rJqhiya1IHxVl+ELyF5c4WkSHxODlAyUQI EFOAejR3sZoO2lkAGOei4flzndNEpCwkUVwowLqOmK/W2TX8OvuPjJlmrjf9L1eNyElk BDrA==
X-Gm-Message-State: APjAAAWdDgoluOuPP0Eiox69+BPjS9610HFMQbUNszjo6xQqJ4TSaRko oJpnc8kanZywZMUiWkcQTm9k5A==
X-Google-Smtp-Source: APXvYqwktQ88K5ZhpJGyTzycX0KD49ltu+/S4dVnwNwlPK2yssIsnhK5TCGVQzin6et4iTZ539I1LA==
X-Received: by 2002:adf:a48c:: with SMTP id g12mr6590036wrb.212.1571083993405; Mon, 14 Oct 2019 13:13:13 -0700 (PDT)
Received: from INARA ([89.101.16.218]) by smtp.gmail.com with ESMTPSA id t203sm22946518wmf.42.2019.10.14.13.13.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Oct 2019 13:13:11 -0700 (PDT)
Sender: Daniel King <dk@danielking.net>
X-Google-Original-Sender: "Daniel King" <dk@danielking.net>
From: daniel@olddog.co.uk
To: 'Tianran Zhou' <zhoutianran@huawei.com>, opsawg@ietf.org
Cc: draft-song-opsawg-ifit-framework.authors@ietf.org
References: <036b01d57dac$bcdc0380$36940a80$@olddog.co.uk> <BBA82579FD347748BEADC4C445EA0F21BF00D5A6@NKGEML515-MBX.china.huawei.com>
In-Reply-To: <BBA82579FD347748BEADC4C445EA0F21BF00D5A6@NKGEML515-MBX.china.huawei.com>
Date: Mon, 14 Oct 2019 21:13:51 +0100
Message-ID: <004301d582cb$e64c26e0$b2e474a0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHjJTimps/vAfsBZzZW49liTmtEcgH5ndYOpy9sqZA=
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/d6YJNrwk-dMfcgttJRspLcmWXj8>
Subject: Re: [OPSAWG] Comments for draft-song-opsawg-ifit-framework-05.txt
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: Mon, 14 Oct 2019 20:13:17 -0000

Hi Tianran,

Let me expand on the thought I was having. 

Is it possible, and useful, to develop a telemetry policy model that would
define a set of telemetry primitives that the iFIT application would send to
the iFIT controller? In other words, how might I automate the request from
an iFIT application by using some policy language that would scope the type
of analysis requested, constrain the telemetry mechanism applied and provide
potential success factors:
       
1. What to observe?
2. What to collect?
3. Where and which triggers to set?
4. Where to store?
5. How much data to store? 
6. When to stop collecting?

Taking the first insight ("What to observe?"), this could expand to
something like (not exhaustive):

+-What to observe?
   +-Anomalies
      +-Loops
      +-Congestion
      +-High Latency
      +-High Loss
      +-Unexpected Traffic Increase
      +-Etc.
   +-Events
      +-Low Link Utilisation
      +-Low Node Utilisation
      +-Unexpected Path 
      +-Path Performance Degradation
      +-Etc.
   +-Data Collection Filters
      +-Flow/Packet Sample Rate
      +-Interface/Port Info
      +-Queue Info
      +-Metadata Info
      +-Timestamps
      +-Drop Condition/Reason

Now to be clear, I am not advocating draft-song-opsawg-ifit-framework would
detail the model and parameters, just that it's a Framework I-D and if you
think this capability would be useful you might list this capability as
high-level requirement. Potentially existing IETF proposals/documents could
be used for the solution, I did have a search previously but could not find
anything specific that might be suitable. Perhaps a new document that refers
back to draft-song-opsawg-ifit-framework could be created if current no
suitable model/tree is found. 

Another aspect of the draft-song-opsawg-ifit-framework that I was thinking
about was security, and specifically how to manage what is set, when its
triggered and who and what has access/may consume to the iFIT data. It seems
a compromised iFIT platform could accomplish some pretty nasty DDOS on the
forwarding plane of the network, and the data collectors themselves. I could
draft some text for Security section if you think it's useful.

BR, Dan. 

-----Original Message-----
From: Tianran Zhou <zhoutianran@huawei.com> 
Sent: 09 October 2019 07:34
To: daniel@olddog.co.uk; opsawg@ietf.org
Cc: draft-song-opsawg-ifit-framework.authors@ietf.org
Subject: RE: [OPSAWG] Comments for draft-song-opsawg-ifit-framework-05.txt

Hi Dan,

Could you please help to clarify this?
> (3) Additional Challenge - Have you considered a model-driven 
> telemetry API from the iFIT framework that could expose network 
> performance to external applications? Maybe something along the lines of:
> 
> >>
>    o  C6: Development of simplified iFIT telemetry primitives and model,
>       including: telemetry data (e.g., nodes, links, ports, paths, flows,
>       timestamps) query primitives. These may be used by an API-based
>       telemetry service for external applications to iFIT, for
>       monitoring end-to-end latency measurement of
>       network paths and application latency calculation via the iFIT
>       framework.
> <<

What do you mean by model-driven telemetry API? What's the difference from
other APIs?
Do you actually mean to define information/data models?
So the IPFIX template, YANG model, or proto file.

Thanks,
Tianran



> -----Original Message-----
> From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of 
> daniel@olddog.co.uk
> Sent: Tuesday, October 08, 2019 3:48 PM
> To: opsawg@ietf.org
> Cc: draft-song-opsawg-ifit-framework.authors@ietf.org
> Subject: [OPSAWG] Comments for draft-song-opsawg-ifit-framework-05.txt
> 
> Dear Authors,
> 
> Please find some comments, thoughts and suggestions for
> https://tools.ietf.org/html/draft-song-opsawg-ifit-framework-05
> 
> Overall, a really useful document and something I hope the WG can
progress.
> There are many in-band/in-situ OAM documents currently floating around 
> in at least four IETF WGs, so a document that helps coordinate the 
> discussion would be very valuable.
> 
> General Comments
> 
> (1) Abstract - The scope is clear, but the intention of this document 
> could be clarified. You might rephrase as:
> 
> >>
>    For efficient network operation, most operators rely on traditional
>    Operation, Administration and Maintenance (OAM) methods, which
>    include proactive and reactive techniques, running in active and
>    passive modes. As networks increase in scale they become more
>    susceptible to hardware and software failures, and misconfiguration
>    errors.
> 
>    With the advent of programmable data-plane emerging "on-path" OAM
>    techniques, such as flow telemetry,  provide unprecedented insight
>    and fast notification of network issues (e.g., jitter, increased
>    latency, packet loss, significant bit error variations, and unequal
>    load-balancing.
> 
>    In-situ Flow Information Telemetry (iFIT), would provide a method
>    for efficiently applying underlying on-path flow telemetry
>    techniques, applicable across various network environments.
> 
>    This document outlines an iFIT framework, which enumerates several
>    critical functional components and describes how these components
>    are assembled together to achieve a complete and closed-loop
>    working solution for on-path flow telemetry.
> <<
> 
> (2) Use of "Application-aware network" - We may need to be careful 
> with this the usage of this word. It already has a well-used meaning 
> in the context of Cloud and SDN. If you are happy with the general 
> description, we could continue to use "application-aware networking", 
> but we should add a definition, such as:
> 
> >>
>    Future networks must also support application-aware networking.
>    Application-aware networking is an emerging industry term and
>    typically used to describe the capacity of an intelligent network to
>    maintain current information about user and application connections
>    that use network resources and, as a result, the operator is able to
>    optimize the network resource usage and monitoring to ensure
>    application and traffic optimality.  <<
> 
> (3) Additional Challenge - Have you considered a model-driven 
> telemetry API from the iFIT framework that could expose network 
> performance to external applications? Maybe something along the lines of:
> 
> >>
>    o  C6: Development of simplified iFIT telemetry primitives and model,
>       including: telemetry data (e.g., nodes, links, ports, paths, flows,
>       timestamps) query primitives. These may be used by an API-based
>       telemetry service for external applications to iFIT, for
>       monitoring end-to-end latency measurement of
>       network paths and application latency calculation via the iFIT
>       framework.
> <<
> 
> (4) Security - I think this section requires significantly more text 
> as I can think of numerous issues that will need to be considered, or 
> at least highlighting  best practices and considerations discussed in 
> other documents. I started working on a much more comprehensive 
> security section, I will send this to the authors directly (or the 
> list if you prefer) over the next few days.
> 
> (5) Please find the edits, typos, NITs, suggested text in the attached
> documents:
> 
> o draft-song-opsawg-ifit-framework-05-review.txt - 
> https://github.com/danielkinguk/draft-song-opsawg-ifit-framework/blob/
> ma
> ster
> /draft-song-opsawg-ifit-framework-05-review.txt
> o draft-song-opsawg-ifit-framework-05-review-diff.html - 
> https://github.com/danielkinguk/draft-song-opsawg-ifit-framework/blob/
> ma
> ster
> /draft-song-opsawg-ifit-framework-05-review-diff.html
> 
> I hope this helps.
> BR, Dan.
> 
> -----Original Message-----
> From: I-D-Announce <i-d-announce-bounces@ietf.org> On Behalf Of 
> internet-drafts@ietf.org
> Sent: 26 September 2019 18:29
> To: i-d-announce@ietf.org
> Subject: I-D Action: draft-song-opsawg-ifit-framework-05.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
>         Title           : In-situ Flow Information Telemetry Framework
>         Authors         : Haoyu Song
>                           Zhenbin Li
>                           Tianran Zhou
>                           Fengwei Qin
>                           Huanan Chen
>                           Jaewhan Jin
>                           Jongyoon Shin
> 	Filename        : draft-song-opsawg-ifit-framework-05.txt
> 	Pages           : 16
> 	Date            : 2019-09-26
> 
> Abstract:
>    Unlike the existing active and passive OAM techniques, the emerging
>    on-path flow telemetry techniques provide unmatched visibility into
>    user traffic, showing great application potential not only for
>    today's network OAM but also for future's automatic network
>    operation.  Summarizing the current industry practices that addresses
>    the deployment challenges and application requirements, we provide a
>    closed-loop framework, named In-situ Flow Information Telemetry
>    (iFIT), for efficiently applying a family of underlying on-path flow
>    telemetry techniques in various network environments.  The framework
>    enumerates several key architectural components and describes how
>    these components are assembled together to achieve a complete and
>    closed-loop working solution for on-path flow telemetry.  Following
>    such a framework allows better scalability, fosters application
>    innovations, and promotes both vertical and horizontal
>    interoperability.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-song-opsawg-ifit-framework-05
> https://datatracker.ietf.org/doc/html/draft-song-opsawg-ifit-framework
> -0
> 5
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-song-opsawg-ifit-framework-05
> 
> 
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at
tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg