Robin, Einar pointed exactly right points, very little to add. Let’s keep is-is (narrow) scope. 1. There’s operational state of the protocol - I don’t really see what’s missing in IETF/OpenConfig YANG models that would nessesarily require new work? Please be specific in your answers
2. What’s in LSDB - to my understanding you are not looking at that? Reading your draft - it only concerns operational state, not the content, so BMP is not really a comparable solution either... Wrt gRPC and some other work being done by OpenConfig/open source community - besides Einar’s points - we have got great working relationship with the team working on these technologies, there are gRPC and gNMI drafts in RTGWG that would be updated when the need arise. Wrt performance - there’s significant amount of research/testing and comparisons of gRPC vs most of other RPC solutions, at scale, we in networking won’t reach in quite some time, I’d advice to look it up. We could discuss other advantages of running on top of HTTPv2 separately. Please note - I’m not judging your proposal, but trying to understand why, we as the community should be spending time and effort on it, so far you you didn’t manage to convince me. Looking forward to your reply. Thanks, Jeff On Thu, Jul 5, 2018 at 04:45 Einar Nilsen-Nygaard (einarnn) < eina...@cisco.com> wrote: > Robin, > > With respect to your points below: > > > - #1 – The draft ISIS model doesn’t seem to have many lateral > dependencies as far as I can see. And if it is incomplete from the > perspective of monitoring the health of ISIS, then it should be extended. > I’m not sure why it would be difficult to stabilise the definition? > - #2 – This seems to be the same issue of an incomplete model. Can you > clearly articulate any data that you think should be available that *cannot > be modelled in YANG*? > - #3 – Agreed that exporting high volume, low latency telemetry one > the baseline transport suggested in ietf-netconf-yang-push would > perhaps have issues. This is one of the reasons why transport extensibility > is an explicit part of the draft. > - #4 – IMO, as long as the encoding for data is clearly defined in an > "open" way, then this is not really an issue yet. I still think we need to > experiment with encodings, but I do not think an entirely new protocol will > serve network operators. > > > I’d also like to add to the last point and say that I do not think adding > new protocols and new encodings will serve network operators well. Over the > last few years operators have been making it clear that they want to > simplify their interactions with the network, and not have more things they > need to understand thrown at them. Acee isn’t suggesting deprecating BMP, > and neither am I, but in at least two discussions with operators I have > attended, when introduced to BMP, their initial reaction could be > summarised as "this looks interesting, but why have you introduced > *another* protocol for this?" > > I completely support identifying the use cases you have, but would really > like to see us focus on rectifying any deficiencies we can identify with > existing proposals, rather than dilute our efforts. > > Cheers, > > Einar > > On 5 Jul 2018, at 11:48, Lizhenbin <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 > <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 > <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 > <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 > > > > _______________________________________________ > 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
