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

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

Hi Tim, Robert,

Thanks a lot for your comments. Regarding the idea of using BGP-LS for 
troubleshooting, we have also considered the possible pros and cons.

BGP-LS is initially proposed for carrying link state information using BGP, and 
is currently used for applications like topology visualization. However, I 
would not consider it as a strict “monitoring” protocol. NMP is intended for 
network troubleshooting, which monitors the protocol running status, exporting 
information more than just link state. For example, as also pointed out by Tim, 
in the NMP adjacency up/down event notification, possible reasons are included. 
Such non-link-state information is not defined in BGP-LS. It might be 
technically worktable for BGP-LS to carry the reason data by adding some 
“attribute” TLV, or to carry any other non-link-state data used for 
troubleshooting (e.g., PDU statistics), but it kind of deviates from the 
original intention of proposing BGP-LS.

In addition, whatever data conveyed by BGP-LS NLRI needs to be 
supported/encapsulated in the ISIS/OSPF PDUs. This bring scalability issue and 
extra IGP extension work whenever new information for new troubleshooting use 
cases is required. Besides, the extra data is to be flooded with ISIS/OSPF 
throughout the area/AS, which consumes extra bandwidth and is unwanted.

Another concern for BGP-LS is the lack of per-device feed. As we have stated in 
another email: The availability of real-time protocol PDUs collected from all 
monitored routers is necessary for troubleshooting analysis. As Tim pointed out 
that:
“BGP-LS also can be used to monitor EPE and direct/static routes, which is a 
bit of a stretch on putting that in BGP-LS, but nonetheless…”
 “Regarding requiring BGP-LS feeds from many or all nodes...  We need this 
regardless of this draft because of segment-routing/egress peer engineering.   
Due to EPE, we already recommend BGP-LS peering (feeds) from all EPE nodes 
(normally via a peering server) so that we can collect/monitor EPE (hopefully 
using https://tools.ietf.org/html/draft-ietf-grow-bmp-local-rib-01).”
Although BGP-LS might be extended for multiple feeds in the future for specific 
purposes, to me, it again deviates from its original intention. And if we 
insist on extending BGP-LS for the purpose of troubleshooting, it just becomes 
NMP.

Regarding the comparison with other telemetry approaches, specifically 
gRPC/YANG, we have stated our points in the other email. To avoid repeating in 
this thread, please kindly refer to our previous email.

We agree with Tim that “The initiation message could lead to overloading it 
with all kinds of device specific info. Some constraint is needed. The per peer 
(adjacency) header is missing multi-topology.  BGP-LS includes the protocol 
type (e.g. CT) and MT (missing from this draft).”
In fact, not only during the initiation phase of the NMP session, but also 
during some network failure, e.g., route flapping, massive PDUs and other data 
are reported to the server. We think enabling different working modes (e.g., 
PDU compress mode, normal mode) of NMP at the device side could be a workable 
solution. We can refine this idea in the next version, as well as adding MT 
into the per-adjacency header.


BR,

Yunan

From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: 2018年7月11日 17:25
To: Tim Evens (tievens) 
Cc: Greg Skinner ; GMO Crops 
; lsr@ietf.org; ops...@ietf.org; rt...@ietf.org
Subject: Re: [GROW] [Lsr] FW: New Version Notification for 
draft-gu-network-mornitoring-protol-00.txt

Tim,

I already suggested use of BGP-LS *as-is* in this thread on Jul 6th.

But I guess we all agree that this is not the best use of BGP protocol to be 
now a vehicle of NMS only because it is easy with BGP to establish a TCP 
session and to distribute "stuff" in a relatively loop free fashion.

Thx,
R.

On Wed, Jul 11, 2018 at 2:40 AM, Tim Evens (tievens) 
mailto:tievens=40cisco@dmarc.ietf.org>> 
wrote:
Hi Robin, Yunan, Shunwan,

I'm a little late to this thread due to being preoccupied with a newborn.

Below are my comments, which take into consideration the other comments… sans 
the YANG/telemetry debate.  Considering we do use BGP-LS extensively, I don't 
think YANG is the only solution to these link-state monitoring use-cases.

BMP doesn't change or limit what's available in BGP. It encapsulates and 
multiplexes BGP over a single stream for remote monitoring.   BGP-LS (RFC7752) 
can be used today to monitor link state protocols (ISIS, OSPF).  BGP-LS also 
can be used to monitor EPE and direct/static routes, which is a bit of a 
stretch on putting that in BGP-LS, but nonetheless…  BGP-LS is available via 
BMP.

"Section 3.1, ISIS Adjacency Issues"

As written, this is covered by BGP-LS LINK NLRI.  We see a LINK change 
(advertised verses withdrawn) when the adjacency changes.  If the router dies 
or the control-plane fails in some way, we still see the NLRI change from the 
other side of the 

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

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

Hi Greg, Jeff, Acee, Robert Wilton, Einar,

and anyone who has concern with NMP vs. gRPC/YANG, thanks for your interest in 
our draft and your valuable comments. Regarding this question, we’d like to 
state the following two points.


1.  Control plane (CP) and management plane (MP) information 
retrieval/manipulation decoupling:

As stated in the draft, we propose NMP to monitor the running status of routing 
protocols, which can be considered as a CP telemetry approach (so is BMP). MP 
telemetry approaches, such as SNMP, NETCONF and so on, have longer histories 
and are better developed than CP telemetry. However, there exists differences 
between the CP and MP data, and it’s not necessarily appropriate to reuse the 
existing MP approaches for CP monitoring.

First of all, MP data reflects information from the device viewpoint, including 
the device status information (e.g., CPU, interface, memory…) and configuration 
actions (e.g., set timer…), while CP data reflects information from the 
protocol viewpoint, e.g., protocol PDU (e.g., ISIS LSP/Hello) and protocol 
statistics. Specifically, the availability of real-time protocol PDUs collected 
from all monitored routers is necessary for NMP troubleshooting analysis. Such 
per-router PDU monitoring of NMP provides much more information than one LSDB 
collected from a single router in an area/AS using BGP-LS. For example, in the 
case an ISIS adjacency fails to set up due to mismatched authentications, 
analyzing the Hello statistics alone is not sufficient. Comparing the Hello 
PDUs sent from both devices can provide insight into authentication 
differences. Another example that in a route flapping case, caused by corrupted 
LSP remaining lifetime, a locally sent LSP and an LSP received at the remote 
device can be compared/analyzed to localize the corruption.

Secondly, MP telemetry mainly focuses on things like VPN configuration, tunnel 
configuration and so on, while NMP are proposed to facilitate protocol 
troubleshooting. Apparently, troubleshooting is more time-sensitive compared 
with things like VPN configuration. In addition, CP information, e.g., protocol 
PDUs, is updating continuously with time and thus needing real-time report. MP 
data are less dynamic compared to CP.

Thirdly, a key principle of CP telemetry is to keep the monitoring protocol 
independent from the monitored protocol. Thus a unidirectional monitoring 
protocol, just like BMP, could avoid any possible interference to the monitored 
protocol.

Thus, we believe it’s necessary to decouple the CP monitoring from the MP 
telemetry.


2.  Why not gRPC/YANG for CPT?

We agree that it’s technically workable to use gRPC/YANG to model and convey CP 
data, like Hello/LSP, however we think it’s simply not the best choice for CP 
monitoring.

First all, as the major component of CP monitoring data, the protocol PDUs are 
already in binary format, and are transmission-ready with nice performance. The 
protocol statistics can be easily encoded as TLVs and added to transmission. 
Thus, modeling CP data into YANG first and then encoding it as XML/protobuf for 
transmission is just extra work.

Secondly, in case of route flapping caused by timer issue (e.g., 100 times 
faster), the updates of LSP, Hello, and LSP purge could be in massive quantity, 
the modeling of all these PDUs into YANG may slow down the data export, thus 
delaying the troubleshooting process.

Thirdly, it might be not clear yet, but it could be possible that the YANG 
modeling process may affect the PDU data integrity in case when a bit-by-bit 
comparison of two PDUs is needed.

We also agree that information, like system ID/MTU, is more fit to be reported 
using gRPC/YANG. All in all, NMP is not meant to replace any existing OAM 
approach, but to work side by side with it and even data plane telemetry (e.g., 
iOAM) for better network troubleshooting.


BR,

Yunan


From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Greg Skinner
Sent: 2018年7月9日 11:59
To: Randy Bush ; Lizhenbin 
Cc: lsr@ietf.org; GMO Crops ; ops...@ietf.org; rt...@ietf.org
Subject: Re: [GROW] [Lsr] FW: New Version Notification for 
draft-gu-network-mornitoring-protol-00.txt

Randy,

Is the OPS-NM Configuration Management Requirements (ops-nm) 
Bof from IETF 52 (10 December 
2001) the meeting you were thinking of?  There are also references to an IAB 
meeting in 2002 about the lack of use of SNMP for network configuration in SNMP 
compared with CLI, Netconf, 
Netflow that 
culminated in RFC 3535.

Robin,

Regarding the draft in question, I generally agree with the concerns others 
have made that it doesn’t appear to provide anything that other technologies 
such as YANG provide.  Also, IMO, the draft needs considerable work to be more 
easily understood.  For example, there are many acronyms such as CSNP and PS

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

[Randy Bush]

> But I guess we all agree that this is not the best use of BGP protocol to
> be now a vehicle of NMS only because it is easy with BGP to establish a TCP
> session and to distribute "stuff" in a relatively loop free fashion.

now that dns over tcp/tls is being deployed, we can return to the other
overused protocol.  < emoji for drippinng sarcasm >

randy

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

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

[Robert Raszuk]

Tim,

I already suggested use of BGP-LS *as-is* in this thread on Jul 6th.

But I guess we all agree that this is not the best use of BGP protocol to
be now a vehicle of NMS only because it is easy with BGP to establish a TCP
session and to distribute "stuff" in a relatively loop free fashion.

Thx,
R.

On Wed, Jul 11, 2018 at 2:40 AM, Tim Evens (tievens) <
tievens=40cisco@dmarc.ietf.org> wrote:

> Hi Robin, Yunan, Shunwan,
>
>
>
> I'm a little late to this thread due to being preoccupied with a newborn.
>
>
>
> Below are my comments, which take into consideration the other comments…
> sans the YANG/telemetry debate.  Considering we do use BGP-LS extensively,
> I don't think YANG is the only solution to these link-state monitoring
> use-cases.
>
>
>
> BMP doesn't change or limit what's available in BGP. It encapsulates and
> multiplexes BGP over a single stream for remote monitoring.   BGP-LS
> (RFC7752) can be used today to monitor link state protocols (ISIS, OSPF).
> BGP-LS also can be used to monitor EPE and direct/static routes, which is a
> bit of a stretch on putting that in BGP-LS, but nonetheless…  BGP-LS is
> available via BMP.
>
>
>
> "Section 3.1, ISIS Adjacency Issues"
>
>
>
> As written, this is covered by BGP-LS LINK NLRI.  We see a LINK change
> (advertised verses withdrawn) when the adjacency changes.  If the router
> dies or the control-plane fails in some way, we still see the NLRI change
> from the other side of the adjacency (perspective).
>
>
>
> What we are missing is a BGP-LS "attribute" tlv (on local entries) for
> links/nodes that indicates the REASON why the LINK (also NODE) is
> withdrawn, but this is not available without changing the IGP protocol
> itself (e.g. new ISIS TLV) or by implementing a solution architecture that
> requires BGP-LS feeds from all ISIS/OSPF nodes.  As written, I see NMP
> (including Netconf/gNMI/telemetry) requiring sessions from all nodes since
> the targeted data is not available in ISIS TLV's today.   For example, the
> ISIS LSDB on node-A does not have any local (device specific) information
> from all the other nodes unless there are TLV's to convey that information.
>
>
>
> Regarding requiring BGP-LS feeds from many or all nodes...  We need this
> regardless of this draft because of segment-routing/egress peer
> engineering.   Due to EPE, we already recommend BGP-LS peering (feeds) from
> all EPE nodes (normally via a peering server) so that we can
> collect/monitor EPE (hopefully using https://tools.ietf.org/html/
> draft-ietf-grow-bmp-local-rib-01). Adding LINK/NODE withdrawal/down
> reason should not overstep into YANG/Netconf/Telemetry.
>
>
>
> "3.2.  Forwarding Path Disconnection"
>
>
>
> This seems to be more of a fit for telemetry with interface/link
> monitoring.  Although, if the link was working at some point and it goes
> down due to MTU or otherwise, the BGP-LS REASON attribute should be able to
> convey that.  BGP-LS wouldn't convey anything if the link was never
> established.  Currently, it's assumed that the link advertisement means
> it's established.  This could be changed if we added a LINK NLRI state
> TLV.   The LINK could be updated (advertised) multiple times, changing
> based on state.   If the LINK doesn't establish, the withdrawal could
> indicate the reason.
>
>
>
> "3.3.  ISIS LSP Synchronization Failure"
>
>
>
> If a new BGP-LS LINK attribute is used as mentioned above to convey LINK
> adv state, it should then be feasible to add a state to indicate
> inconsistency. If the link/adj changes to down, then the withdrawal LINK
> reason attribute could indicate the cause.
>
>
>
> The BGP-LS reason and state tlv's would only apply to the links/nodes that
> originate from the BGP-LS speaker.  Other node/link advertisements would
> not have the attribute/tlv.   This is why the solution would recommend
> enabling BGP-LS feeds from nodes that matter enough to get this level of
> local info.  This btw would solve a problem we have with BGP-LS today where
> optional TLV's are not present unless ISIS/OSPF have specific features
> enabled, such as traffic-engineering... even IPv4/IPv6 router ID's are not
> included unless enabled specifically (isis) per node.
>
>
>
> "4.  Extensions of NMP for ISIS"
>
>
>
> Most of the new messages are redundant to the existing BGP-LS
> advertisements and withdrawals.  Telemetry of course could also convey
> this…
>
>
>
> The initiation message could lead to overloading it with all kinds of
> device specific info.   Some constraint is needed.
>
>
>
> The per peer (adjacency) header is missing multi-topology.  BGP-LS
> includes the protocol type (e.g. CT) and MT (missing from this draft).
>
>
>
> All in all, I believe the use-cases described have merit and I think we
> can do this with BGP-LS, which doesn't require BMP but could be used.
>
>
>
> Thanks,
>
> Tim
>
>
>
>
>
> On 7/8/18, 8:59 PM, "GROW on behalf of Greg Skinner" <
> grow-boun...@ietf.org on behalf of gregskinner0=40icloud.com@
> d

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

[Tim Evens (tievens)]

Hi Robin, Yunan, Shunwan,

I'm a little late to this thread due to being preoccupied with a newborn.

Below are my comments, which take into consideration the other comments… sans 
the YANG/telemetry debate.  Considering we do use BGP-LS extensively, I don't 
think YANG is the only solution to these link-state monitoring use-cases.

BMP doesn't change or limit what's available in BGP. It encapsulates and 
multiplexes BGP over a single stream for remote monitoring.   BGP-LS (RFC7752) 
can be used today to monitor link state protocols (ISIS, OSPF).  BGP-LS also 
can be used to monitor EPE and direct/static routes, which is a bit of a 
stretch on putting that in BGP-LS, but nonetheless…  BGP-LS is available via 
BMP.

"Section 3.1, ISIS Adjacency Issues"

As written, this is covered by BGP-LS LINK NLRI.  We see a LINK change 
(advertised verses withdrawn) when the adjacency changes.  If the router dies 
or the control-plane fails in some way, we still see the NLRI change from the 
other side of the adjacency (perspective).

What we are missing is a BGP-LS "attribute" tlv (on local entries) for 
links/nodes that indicates the REASON why the LINK (also NODE) is withdrawn, 
but this is not available without changing the IGP protocol itself (e.g. 
new ISIS TLV) or by implementing a solution architecture that requires BGP-LS 
feeds from all ISIS/OSPF nodes.  As written, I see NMP (including 
Netconf/gNMI/telemetry) requiring sessions from all nodes since the targeted 
data is not available in ISIS TLV's today.   For example, the ISIS LSDB on 
node-A does not have any local (device specific) information from all the other 
nodes unless there are TLV's to convey that information.

Regarding requiring BGP-LS feeds from many or all nodes...  We need this 
regardless of this draft because of segment-routing/egress peer engineering.   
Due to EPE, we already recommend BGP-LS peering (feeds) from all EPE nodes 
(normally via a peering server) so that we can collect/monitor EPE (hopefully 
using https://tools.ietf.org/html/draft-ietf-grow-bmp-local-rib-01). Adding 
LINK/NODE withdrawal/down reason should not overstep into 
YANG/Netconf/Telemetry.

"3.2.  Forwarding Path Disconnection"

This seems to be more of a fit for telemetry with interface/link monitoring.  
Although, if the link was working at some point and it goes down due to MTU or 
otherwise, the BGP-LS REASON attribute should be able to convey that.  BGP-LS 
wouldn't convey anything if the link was never established.  Currently, it's 
assumed that the link advertisement means it's established.  This could be 
changed if we added a LINK NLRI state TLV.   The LINK could be updated 
(advertised) multiple times, changing based on state.   If the LINK doesn't 
establish, the withdrawal could indicate the reason.

"3.3.  ISIS LSP Synchronization Failure"

If a new BGP-LS LINK attribute is used as mentioned above to convey LINK adv 
state, it should then be feasible to add a state to indicate inconsistency. If 
the link/adj changes to down, then the withdrawal LINK reason attribute could 
indicate the cause.

The BGP-LS reason and state tlv's would only apply to the links/nodes that 
originate from the BGP-LS speaker.  Other node/link advertisements would not 
have the attribute/tlv.   This is why the solution would recommend enabling 
BGP-LS feeds from nodes that matter enough to get this level of local info.  
This btw would solve a problem we have with BGP-LS today where optional TLV's 
are not present unless ISIS/OSPF have specific features enabled, such as 
traffic-engineering... even IPv4/IPv6 router ID's are not included unless 
enabled specifically (isis) per node.

"4.  Extensions of NMP for ISIS"

Most of the new messages are redundant to the existing BGP-LS advertisements 
and withdrawals.  Telemetry of course could also convey this…

The initiation message could lead to overloading it with all kinds of device 
specific info.   Some constraint is needed.

The per peer (adjacency) header is missing multi-topology.  BGP-LS includes the 
protocol type (e.g. CT) and MT (missing from this draft).

All in all, I believe the use-cases described have merit and I think we can do 
this with BGP-LS, which doesn't require BMP but could be used.

Thanks,
Tim


On 7/8/18, 8:59 PM, "GROW on behalf of Greg Skinner" 
mailto:grow-boun...@ietf.org> on behalf of 
gregskinner0=40icloud@dmarc.ietf.org>
 wrote:

Randy,

Is the OPS-NM Configuration Management Requirements (ops-nm) 
Bof from IETF 52 (10 December 
2001) the meeting you were thinking of?  There are also references to an IAB 
meeting in 2002 about the lack of use of SNMP for network configuration in SNMP 
compared with CLI, Netconf, 
Netflow that 
culminated in RFC 3535.

Robin,

Regarding the draft in question, I generally a

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

[Greg Skinner]

Randy,

Is the OPS-NM Configuration Management Requirements (ops-nm) Bof 
 from IETF 52 (10 December 2001) 
the meeting you were thinking of?  There are also references to an IAB meeting 
in 2002 about the lack of use of SNMP for network configuration in SNMP 
compared with CLI, Netconf, Netflow 
 that culminated in 
RFC 3535 .

Robin,

Regarding the draft in question, I generally agree with the concerns others 
have made that it doesn’t appear to provide anything that other technologies 
such as YANG provide.  Also, IMO, the draft needs considerable work to be more 
easily understood.  For example, there are many acronyms such as CSNP and PSNP 
that are not defined, and may be misunderstood by readers not familiar with 
ISIS.  In the packet format sections, there are several uncapitalized uses of 
‘should’..  Do the authors consider these to be non-normative requirements?  
There are also statements such as "Network OAM statistics show that a 
relatively large part of the network issues are caused by the disfunction of 
various routing protocols and MPLS signalings” that are offered without 
citations.

Regards,
Greg

> On Jul 7, 2018, at 8:25 PM, Randy Bush  wrote:
> 
> 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."
> 

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

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

[Randy Bush]

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."

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

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

[Robert Wilton]

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"  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 
; 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 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)"  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"  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) 
; g...@ietf.org; ops...@ietf.org
 Subject: Re: [OPSAWG] [GR

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

[Lizhenbin]

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


Best Regards,
Robin





-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com] 
Sent: Friday, July 06, 2018 6:04 AM
To: Lizhenbin ; Jeff Tantsura ; 
Acee Lindem (acee) ; g...@ietf.org; 
ops...@ietf.org
Cc: lsr@ietf.org; rt...@ietf.org
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. 

Thanks,
Acee 


On 7/5/18, 6:49 AM, "GROW on behalf of 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 
; 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 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)" 
 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"  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 Researc

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

[Randy Bush]

robin,

> It is not described clearly in the draft that reusing BMP is also a
> possible option for monitoring IGP. We will refine the draft.  

if i could also use bmp for monitoring dns, smtp, and ntp, i could
stop using nagios!

i think what acee is trying to say is that "B" in BMP does not stand
for Bypass.

randy

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

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

[Acee Lindem (acee)]

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. 

Thanks,
Acee 


On 7/5/18, 6:49 AM, "GROW on behalf of 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 
; 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 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)" 
 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"  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) 
; 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?

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

[Acee Lindem (acee)]

Hi Robin, 

On 7/5/18, 6:35 AM, "Lizhenbin"  wrote:

Hi Acee,
It is not described clearly in the draft that reusing BMP is also a 
possible option for monitoring IGP. We will refine the draft. 

It doesn't matter where you put it, it is still an alternate paradigm for IS-IS 
management. 

Expect to have more discussion with you in IETF 102.

I'm sure we will. I really don't think this meets the "stick to the wall" test 
for GROW. 

Thanks,
Acee 


Thanks,
Robin





-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com] 
Sent: Wednesday, July 04, 2018 12:09 AM
To: Lizhenbin ; g...@ietf.org; ops...@ietf.org
Cc: Guyunan (Yunan Gu, IP Technology Research Dept. NW) 
; lsr@ietf.org; rt...@ietf.org
Subject: Re: [GROW] FW: New Version Notification for 
draft-gu-network-mornitoring-protol-00.txt

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"  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) 
; 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)"  
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 ; Lizhenbin 
; Guyunan (Yunan Gu, IP Technology Research Dept. NW) 

Subject: New Version

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

[Lizhenbin]

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

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

[Lizhenbin]

Hi Acee,
It is not described clearly in the draft that reusing BMP is also a possible 
option for monitoring IGP. We will refine the draft. 
Expect to have more discussion with you in IETF 102.


Thanks,
Robin





-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com] 
Sent: Wednesday, July 04, 2018 12:09 AM
To: Lizhenbin ; g...@ietf.org; ops...@ietf.org
Cc: Guyunan (Yunan Gu, IP Technology Research Dept. NW) ; 
lsr@ietf.org; rt...@ietf.org
Subject: Re: [GROW] FW: New Version Notification for 
draft-gu-network-mornitoring-protol-00.txt

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"  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) 
; 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)"  
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 ; 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
URL:
https://www.ietf.org/internet-drafts/draft-gu-net

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

[Jeff Tantsura]

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)"  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"  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) 
; 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)"  
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 ; Lizhenbin 
; Guyunan (Yunan Gu, IP Technology Research Dept. NW) 

Subject: New Version Notification for 
draft-gu-network-mornitoring-protol-00.txt


A new version 

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

[Acee Lindem (acee)]

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

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

[Lizhenbin]

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