On 05/07/2018 23:03, Acee Lindem (acee) wrote:
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.
If we want less bits on the wire, then adding support for a binary encoding (e.g. CBOR) to the existing YANG management protocols seems like a better path forwards to me since that seems to have the widest benefit.  CBOR encoded YANG (if using numerical "SIDs" rather than strings for the field names, draft-ietf-core-yang-cbor) is a pretty tight encoding, and is designed for IOT and constrained devices.  A CBOR encoding probably won't be quite as compact as custom TLVs, but I doubt that it would be significantly bigger either, and it has quite a few other benefits (code reuse, can be generically decoded).

Thanks,
Rob


Thanks,
Acee


On 7/5/18, 6:49 AM, "GROW on behalf of Lizhenbin" <grow-boun...@ietf.org on 
behalf of lizhen...@huawei.com> 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,
     Robin
-----Original Message-----
     From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
     Sent: Wednesday, July 04, 2018 5:15 AM
     To: Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org>; Lizhenbin 
<lizhen...@huawei.com>; g...@ietf.org; ops...@ietf.org
     Cc: lsr@ietf.org; rt...@ietf.org; Guyunan (Yunan Gu, IP Technology Research 
Dept. NW) <guyu...@huawei.com>
     Subject: Re: [Lsr] [GROW] FW: New Version Notification for 
draft-gu-network-mornitoring-protol-00.txt
Robin, 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) Thanks! Cheers,
     Jeff
On 7/3/18, 09:21, "Lsr on behalf of Acee Lindem (acee)" <lsr-boun...@ietf.org on behalf of acee=40cisco....@dmarc.ietf.org> 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.
         Thanks,
         Acee
On 7/3/18, 6:40 AM, "Lizhenbin" <lizhen...@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-boun...@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) 
<guyu...@huawei.com>; g...@ietf.org; ops...@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-boun...@ietf.org on behalf of guyu...@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-dra...@ietf.org 
[mailto:internet-dra...@ietf.org]
                 Sent: 2018年7月2日 20:07
                 To: Zhuangshunwan <zhuangshun...@huawei.com>; Lizhenbin 
<lizhen...@huawei.com>; Guyunan (Yunan Gu, IP Technology Research Dept. NW) 
<guyu...@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
                 g...@ietf.org
                 https://www.ietf.org/mailman/listinfo/grow
_______________________________________________
             OPSAWG mailing list
             ops...@ietf.org
             https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________
         Lsr mailing list
         Lsr@ietf.org
         https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
     GROW mailing list
     g...@ietf.org
     https://www.ietf.org/mailman/listinfo/grow
_______________________________________________
rtgwg mailing list
rt...@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to