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

[Haoyu song]

Hi Randy,

Thank you for comments on draft-song-ntf.
I'm not sure I understand your second point. Could you please clarify it?
Please note we didn't enforce any specific model on the telemetry yet. This doc 
only concerns the aspect on how to acquire data from networks. It does support 
the dynamic and interactive configuration for data acquirement. But control is 
out of scope of this document, although we confirm that telemetry plus control 
complete the closed control loop. Maybe I misunderstood your point.
Thanks!

Haoyu

-Original Message-
From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Randy Bush
Sent: Saturday, July 07, 2018 8:25 PM
To: Lizhenbin 
Cc: lsr@ietf.org; GMO Crops ; ops...@ietf.org; rt...@ietf.org
Subject: Re: [OPSAWG] [GROW] [Lsr] FW: New Version Notification for 
draft-gu-network-mornitoring-protol-00.txt

robin,

i am not ignoring you.  i did not want to write unless i had something possibly 
useful to say; and that requires pretending to think, always difficult.

> 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: https://datatracker.ietf.org/doc/draft-song-ntf/

[ warning: my memory is likely fuzzy, and the glass is dark ]

at an ietf in the late '90s[0], there was a hastily called meeting of the snmp 
standards bearers and a bunch of operators.  the snmp folk were shocked to 
learn that no operators used snmp for other than monitoring; no one had snmp 
write enabled on devices; ops configured with the cli[1].  from this was born 
netconf and the xml path.  credit where due:
phil eng was already well down this path at the time of that meeting.

but netconf/xml was a mechanism and lacked a model.  snmp had models, whether 
we thought they were pretty or not.  thus yang was born, and , of course, a new 
generation wants to use the latest modern toys such as restconf, openconfig, 
json, ...

draft-song-ntf yearns for an "architectural framework for network telemetry," a 
lofty and worthwhile goal not, a priori, a bad one.  but a few comments from a 
jaded old dog.

for a new paradigm to gain traction, it must be *significantly* better than the 
old one, or the old paradigm must be clearly failing.  in the story above, snmp 
was clearly failing, aside from using an unfashionable encoding.  and yang 
clearly provided something needed and missing from netconf.  note that this 
paradigm shift has taken over 20 years; and we dis the itu et alia.

second, draft-song-ntf is an export-only model.  while telemetry is extremely 
important, i will be very frustrated if i can only hear and may not speak.  and 
the more it evolves to a really attractive paradigm and model, the more annoyed 
i will be that i can not use it for control.

and lastly, to quote don knuth, "premature optimization is the root of all 
evil."  do not get distracted by squeezing bits out of an encoding.
focus on things such as simple, clear, securable, extensible ...

randy

---

0 - i would love help pinning down which meeting

1 - i still have the "it's the cli, stupid" tee shirt.  an american
political slogan of the era was "it's the economy, stupid."

___
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

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

[Jeff Tantsura]

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  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) ; 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) 
> 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 

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

[Acee Lindem (acee)]

> On Jul 6, 2018, at 8:59 AM, Randy Bush  wrote:
> 
>> ​Why anyone would need BMP wrapper to monitor IGP ?
> 
> probably similar reasons that folk seem to need bgp-ls to get the
> is-is/ospf databases.  is-is and ospf have decades of complexity
> layered on un-simple bases.  so we seek yet another layer of gunk
> through which to see them more 'simply.'
> 
> i would say an optimistic view might be that it will take a couple
> more decades to gunk up bgp-ls and bmp so that we want yet another
> layer.  but it would appear that my optimism is not warranted.


Those who forget the past are condemned to repeat it…

Acee



> 
> randy
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

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

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

[Randy Bush]

> ​Why anyone would need BMP wrapper to monitor IGP ?

probably similar reasons that folk seem to need bgp-ls to get the
is-is/ospf databases.  is-is and ospf have decades of complexity
layered on un-simple bases.  so we seek yet another layer of gunk
through which to see them more 'simply.'

i would say an optimistic view might be that it will take a couple
more decades to gunk up bgp-ls and bmp so that we want yet another
layer.  but it would appear that my optimism is not warranted.

randy

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

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

[Einar Nilsen-Nygaard (einarnn)]

+1

On 6 Jul 2018, at 10:46, Robert Wilton 
mailto:rwilton=40cisco@dmarc.ietf.org>> 
wrote:



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" 
mailto: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) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
Lizhenbin mailto:lizhen...@huawei.com>>; 
g...@ietf.org; ops...@ietf.org
Cc: lsr@ietf.org; 
rt...@ietf.org; Guyunan (Yunan Gu, IP Technology 
Research Dept. NW) mailto: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)" 
mailto: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" 
mailto:lizhen...@huawei.com>> wrote:
 Hi Acee,
Thank for your attention to the new draft. Please refer to my reply 
inline.
 Best Regards,
   

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

[Lizhenbin]

Hi Randy,
Since BMP is promoted in GROW WG, the work has much similarity with BMP. So we 
applied for the presentation here.

Best Regards,
Robin



-Original Message-
From: Randy Bush [mailto:ra...@psg.com] 
Sent: Wednesday, July 04, 2018 2:46 AM
To: Acee Lindem (acee) 
Cc: Lizhenbin ; g...@ietf.org; ops...@ietf.org; 
lsr@ietf.org; rt...@ietf.org
Subject: Re: [OPSAWG] [GROW] FW: New Version Notification for 
draft-gu-network-mornitoring-protol-00.txt

i am confused as why this is in grow.  it's protocol.

randy

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

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

[Randy Bush]

i am confused as why this is in grow.  it's protocol.

randy

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