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

Lizhenbin <> Fri, 06 July 2018 07:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 897B6130E9E; Fri, 6 Jul 2018 00:41:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q5egr9ki_mUl; Fri, 6 Jul 2018 00:41:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 27E5B130E91; Fri, 6 Jul 2018 00:41:42 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 04F097D6AEB1E; Fri, 6 Jul 2018 08:41:39 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.382.0; Fri, 6 Jul 2018 08:41:39 +0100
Received: from ([]) by ([]) with mapi id 14.03.0382.000; Fri, 6 Jul 2018 15:41:33 +0800
From: Lizhenbin <>
To: "Acee Lindem (acee)" <>, Randy Bush <>, Jeff Tantsura <>, "Acee Lindem (acee)" <>, "" <>, "" <>
CC: "" <>, "" <>
Thread-Topic: [GROW] [Lsr] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt
Thread-Index: AQHUFKwNGJxmvGzFU0mBKic4v/AlZ6SBzPPA
Date: Fri, 06 Jul 2018 07:41:32 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [Lsr] [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 Jul 2018 07:41:46 -0000

Hi Acee and Randy,
We do not think NMP is a competitive solutions. We also do not think NMP can solve all issues. From these point of view we are same with you. Similarly I do not think Yang models can solve all issues.
I would also like to propose following draft for your reference which trigger us to move forward for better network maintenance with multiple tools in which gRPC/NETCOF and NMP/BMP may play different roles:

Best Regards,

-----Original Message-----
From: Acee Lindem (acee) [] 
Sent: Friday, July 06, 2018 6:04 AM
To: Lizhenbin <>; Jeff Tantsura <>; Acee Lindem (acee) <>;;
Subject: Re: [GROW] [Lsr] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

Hi Robin, 

I know for a fact that there have been applications written that do passive monitoring using IS-IS and simply advertising yourself in overload mode. Additionally, given that all routes in an area have the same LSDB, you don't really have the same requirements as BGP. 

With respect to scalability, I believe the advantage of the YANG models is more in terms of consumption and having a single network programmability paradigm rather unique per-protocol monitoring. Additionally, YANG, NETCONF, RESTCONF, gNMI, and streaming telemetry are happening now irrespective of your proposal. 

I agree that a custom protocol will result in fewer bits on the wire and potentially less processing on the network device. However, I certainly don't believe that this alone is a reason to do it. 


On 7/5/18, 6:49 AM, "GROW on behalf of Lizhenbin" < on behalf of> wrote:

    Hi Jeff,
    Before we propose the NMP idea, we carefully compared it with the existing NETCONF, gRPC and YANG models work:
    1. Based on my experience in the YANG model work, it may be not satisfactory for these models does not define config/oper of all features of specific protocol and these models have much relation with each other and it is difficult to stabilize the definition.
    2. For monitoring the control protocol, it is not enough based on the existing YANG models such as the packets of control protocol which should be monitored but not defined in YANG models. 
    3. Performance concern on the existing NETCONF.
    4. Standardization of the existing gRPC.
    We would like to define the NMP based on the usecases. That is, a specific set of parameters exported by NMP can satisfy the purpose of a specific usecase. Thus the protocol can be deployed incrementally.
    Best Regards,
    -----Original Message-----
    From: Jeff Tantsura [] 
    Sent: Wednesday, July 04, 2018 5:15 AM
    To: Acee Lindem (acee) <>; Lizhenbin <>;;
    Cc:;; Guyunan (Yunan Gu, IP Technology Research Dept. NW) <>
    Subject: Re: [Lsr] [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt
    Pretty much same comment as Acee - I'm not clear as to why...
    Protocol YANG models developed in the last years clearly provide much better and more scalable approach to what has been proposed in the draft, since we are talking is-is - look at notifications in draft-ietf-isis-yang-isis-cfg. How do you propose to corelate operational state to configuration?
    gRPC provides high performance RPC framework  to streaming the telemetry data that is structured, easy to consume and extend. 
    I'm not going to go into technical discussion, however would appreciate your response as to why NMP (please do not restate the points in the section 4 of the draft, they are quite incorrect) 
    On 7/3/18, 09:21, "Lsr on behalf of Acee Lindem (acee)" < on behalf of> wrote:
        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. 
        On 7/3/18, 6:40 AM, "Lizhenbin" <> wrote:
            Hi Acee,
            Thank for your attention to the new draft. Please refer to my reply inline.
            Best Regards,
            -----Original Message-----
            From: OPSAWG [] On Behalf Of Acee Lindem (acee)
            Sent: Monday, July 02, 2018 9:24 PM
            To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) <>;;
            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.
            On 7/2/18, 8:20 AM, "GROW on behalf of Guyunan (Yunan Gu, IP Technology Research Dept. NW)" < on behalf of> 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: [] 
                Sent: 2018年7月2日 20:07
                To: Zhuangshunwan <>; Lizhenbin <>; Guyunan (Yunan Gu, IP Technology Research Dept. NW) <>
                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
                   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
                The IETF Secretariat
                GROW mailing list
            OPSAWG mailing list
        Lsr mailing list
    GROW mailing list