Re: [Lsr] [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

"Acee Lindem (acee)" <acee@cisco.com> Tue, 03 July 2018 16:13 UTC

Return-Path: <acee@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F930130EAC; Tue, 3 Jul 2018 09:13:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.512
X-Spam-Level:
X-Spam-Status: No, score=-14.512 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 GnOWwK1K-JOJ; Tue, 3 Jul 2018 09:13:20 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E01D413103B; Tue, 3 Jul 2018 09:08:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8950; q=dns/txt; s=iport; t=1530634139; x=1531843739; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Lqt5av9D4ITVgkaw3bF/B7UuAcaIZYtt6Uho0BjJx/s=; b=VZKBNjtJZpyBBjzN49tZdaqGT9sAxBZEqgcIR7GVlYmma107VWjpvFDa qLz1RXA7kyDo7orn1/uQI1B9uHLleVp8hjusESv1pXLU6yIf6CK9GkniG 5wuBwp/pHawRarT7lUyBGYhd3lqv4MqjfQP2Ie9Zp7Le70cvAiW9V53Pq g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DLAACPnjtb/5JdJa1cGQEBAQEBAQEBAQEBAQcBAQEBAYMbLmJ/KAqDb4gEjD+CB5UoFIFmCxgNhAFGAheCAiE0GAECAQECAQECbRwMhTYBAQEBAwEBIRE6CQIMBAIBBgIRBAEBAwIjAwICAiULFAEICAIEAQ0FgyABgX8PjR+bSIIciE2BOoELh2KCFYEOASeCaIMYAQECAQGBJF6CWzGCJAKFVoFqhRGFFYdlCQKGBIVYg0GBQB4lg0mIC4d7gjqHLQIREwGBJB04gVJwFRohKgGCPgmCQ4hIhT5vAY9egRoBAQ
X-IronPort-AV: E=Sophos;i="5.51,304,1526342400"; d="scan'208";a="138110348"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jul 2018 16:08:58 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id w63G8vRe009298 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 Jul 2018 16:08:57 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 3 Jul 2018 12:08:56 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Tue, 3 Jul 2018 12:08:56 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Lizhenbin <lizhenbin@huawei.com>, "grow@ietf.org" <grow@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>
CC: "Guyunan (Yunan Gu, IP Technology Research Dept. NW)" <guyunan@huawei.com>, "lsr@ietf.org" <lsr@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Thread-Topic: [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt
Thread-Index: AQHUEgftvbjq5MWnD06UoPCF/D0SYKR9SGkQgABj0AA=
Date: Tue, 03 Jul 2018 16:08:56 +0000
Message-ID: <35FD4375-DF78-4E5B-A1A4-ACCC332A8E5E@cisco.com>
References: <E793174E-A65C-4E8D-89D7-DC602C5494E8@cisco.com> <5A5B4DE12C0DAC44AF501CD9A2B01A8D8F43F070@dggemm512-mbx.china.huawei.com>
In-Reply-To: <5A5B4DE12C0DAC44AF501CD9A2B01A8D8F43F070@dggemm512-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.202]
Content-Type: text/plain; charset="utf-8"
Content-ID: <DF22D73A985FB547B5E55CEA5C61AFA8@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/WOzYE5vtRLLTPYab4Mmsc6ai6Wg>
Subject: Re: [Lsr] [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Jul 2018 16:13:36 -0000

Hi Robin, 
I'm not arguing to deprecate BMP. What I am arguing is that the fact that BMP was created 15 years ago doesn't necessarily mean we should create an analogous IMP for IS-IS given the current IETF OPS technologies and the fact that faster link speeds and Moore's law facilitate deployment of these new OPS technologies. Anyway, I looked at the agenda and I will definitely attend GROW on Wednesday afternoon for the discussion. 
Thanks,
Acee 

On 7/3/18, 6:40 AM, "Lizhenbin" <lizhenbin@huawei.com> wrote:

    Hi Acee,
    Thank for your attention to the new draft. Please refer to my reply inline.
    
    Best Regards,
    Robin
    
    
    
    -----Original Message-----
    From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Acee Lindem (acee)
    Sent: Monday, July 02, 2018 9:24 PM
    To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) <guyunan@huawei.com>; grow@ietf.org; opsawg@ietf.org
    Subject: Re: [OPSAWG] [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt
    
    Hi Yunan, Shunwan, and Zhenbin, 
    
    What are the advantages of inventing a new protocol over just using YANG and NETCONF, RESTCONF, or gNMI? 
    [Robin] In the draft we simply mention the difference between NMP and protocols you mentioned for the management plane. Though there is maybe some overlap between the two types of protocols, the protocols you mentioned is not enough for monitoring the control protocol. For example, would we like to use YANG and NETCONF, RESTCONF, or gNMI to export the packets of control protocols such as update message of BGP and/or ISIS PDU, etc. for the purpose of monitoring?
    
    
    Operators and vendors are doing this anyway. A second alternative would be to listen passively in IS-IS (or OSPF for that matter). Why would anyone want this? 
    [Robin] In fact we tried the method you proposed. From our point of view, the basic design principle should be that the monitoring entity should be decoupled from the monitored entity. This is to avoid following cases:
    1. The failure of operation of the control protocol may affect the monitoring at the same time.
    2. The limitation of the control protocol will also have effect on the monitoring. For example, for the method of listening passively, if there are multiple hops between the listener and the network devices, it has to set up a tunnel as the virtual link for direct connection. But the TCP-based monitoring protocol need not care about it. 
    
    
    As far as where it belongs, we have a rather full agenda in LSR so I don't think we want to devote time to it there at IETF 102.  
    [Robin] Though the WG the draft should belong to is not determined yet, we think the work belongs to OPS area and send the notice to GROW WG and OPSAWG. We also applied for the presentation in the two WGs. We should have copied the notice to the related WGs of RTG area. So the LSR WG and RTGWG WG mailing list are added. More comments and suggestions are welcome.
    
    Thanks,
    Acee
    
    
    
    On 7/2/18, 8:20 AM, "GROW on behalf of Guyunan (Yunan Gu, IP Technology Research Dept. NW)" <grow-bounces@ietf.org on behalf of guyunan@huawei.com> wrote:
    
        Dear GROW & OPSAWG WGs,
        
        We have proposed a Network Monitoring Protocol (NMP) for the control plane OAM. NMP for ISIS is illustrated in this draft to showcase the benefit and operation of NMP. Yet, we haven't decided which WG it belongs to. 
    
       
        Comments and suggestions are very welcome! 
        
        Thank you!
        
        
        Yunan Gu
        Huawei Technologies Co. Ltd
        
        -----Original Message-----
        From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
        Sent: 2018年7月2日 20:07
        To: Zhuangshunwan <zhuangshunwan@huawei.com>; Lizhenbin <lizhenbin@huawei.com>; Guyunan (Yunan Gu, IP Technology Research Dept. NW) <guyunan@huawei.com>
        Subject: New Version Notification for draft-gu-network-mornitoring-protol-00.txt
        
        
        A new version of I-D, draft-gu-network-mornitoring-protol-00.txt
        has been successfully submitted by Yunan Gu and posted to the IETF repository.
        
        Name:		draft-gu-network-mornitoring-protol
        Revision:	00
        Title:		Network Monitoring Protocol (NMP)
        Document date:	2018-07-02
        Group:		Individual Submission
        Pages:		15
        URL:            https://www.ietf.org/internet-drafts/draft-gu-network-mornitoring-protol-00.txt
        Status:         https://datatracker.ietf.org/doc/draft-gu-network-mornitoring-protol/
        Htmlized:       https://tools.ietf.org/html/draft-gu-network-mornitoring-protol-00
        Htmlized:       https://datatracker.ietf.org/doc/html/draft-gu-network-mornitoring-protol
        
        
        Abstract:
           To enable automated network OAM (Operations, administration and
           management), the availability of network protocol running status
           information is a fundamental step.  In this document, a network
           monitoring protocol (NMP) is proposed to provision the information
           related to running status of IGP (Interior Gateway Protocol) and
           other control protocols.  It can facilitate the network
           troubleshooting of control protocols in a network domain.  Typical
           network issues are illustrated as the usecases of NMP for ISIS to
           showcase the necessity of NMP.  Then the operations and the message
           formats of NMP for ISIS are defined.  In this document ISIS is used
           as the illustration protocol, and the case of OSPF and other control
           protocols will be included in the future version.
        
        
                                                                                          
        
        
        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.
        
        The IETF Secretariat
        
        _______________________________________________
        GROW mailing list
        GROW@ietf.org
        https://www.ietf.org/mailman/listinfo/grow
        
    
    _______________________________________________
    OPSAWG mailing list
    OPSAWG@ietf.org
    https://www.ietf.org/mailman/listinfo/opsawg