[prev in list] [next in list] [prev in thread] [next in thread]
List: ms-ospf
Subject: Re: [Lsr] [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt
From: "Guyunan (Yunan Gu, IP Technology Research Dept. NW)" <guyunan () huawei ! com>
Date: 2018-07-12 6:36:23
Message-ID: C01B0098369B2D4391851938DA6700B7CA5CFD () DGGEMI524-MBS ! china ! huawei ! com
[Download RAW message or body]
[Attachment #2 (text/plain)]
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-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: 2018年7月11日 17:25
To: Tim Evens (tievens) <tievens=40cisco.com@dmarc.ietf.org>
Cc: Greg Skinner <gregskinner0=40icloud.com@dmarc.ietf.org>; GMO Crops \
<grow@ietf.org>; lsr@ietf.org; opsawg@ietf.org; rtgwg@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) \
<tievens=40cisco.com@dmarc.ietf.org<mailto:tievens=40cisco.com@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-bounces@ietf.org<mailto:grow-bounces@ietf.org> on behalf of \
gregskinner0=40icloud.com@dmarc.ietf.org<mailto:gregskinner0=40icloud.com@dmarc.ietf.org>> \
wrote:
Randy,
Is the OPS-NM Configuration Management Requirements (ops-nm) \
Bof<https://www.ietf.org/proceedings/52/176.htm> 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<https://www.snmpcenter.com/snmp-versus-other-protocols/> that \
culminated in RFC 3535<https://tools.ietf.org/html/rfc3535>.
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 <randy@psg.com<mailto:randy@psg.com>> 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."
_______________________________________________
GROW mailing list
GROW@ietf.org<mailto:GROW@ietf.org>
https://www.ietf.org/mailman/listinfo/grow
[Attachment #3 (text/html)]
<html xmlns:v="urn:schemas-microsoft-com:vml" \
xmlns:o="urn:schemas-microsoft-com:office:office" \
xmlns:w="urn:schemas-microsoft-com:office:word" \
xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" \
xmlns="http://www.w3.org/TR/REC-html40"> <head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:宋体;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@宋体";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;
font-weight:bold;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><b><span \
style="font-family:"Calibri",sans-serif;color:#1F497D">Hi Tim, \
Robert,<o:p></o:p></span></b></p> <p class="MsoNormal"><b><span \
style="font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></b></p>
<p class="MsoNormal"><b><span \
style="font-family:"Calibri",sans-serif;color:#1F497D">Thanks a lot for \
your comments. Regarding the idea of using BGP-LS for troubleshooting, we have also \
considered the possible pros and cons. <o:p></o:p></span></b></p>
<p class="MsoNormal"><b><span \
style="font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></b></p>
<p class="MsoNormal"><b><span \
style="font-family:"Calibri",sans-serif;color:#1F497D">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. <o:p></o:p></span></b></p>
<p class="MsoNormal"><b><span \
style="font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></b></p>
<p class="MsoNormal"><b><span \
style="font-family:"Calibri",sans-serif;color:#1F497D">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. <o:p></o:p></span></b></p>
<p class="MsoNormal"><b><span \
style="font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></b></p>
<p class="MsoNormal"><b><span \
style="font-family:"Calibri",sans-serif;color:#1F497D">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: \
<o:p></o:p></span></b></p> <p class="MsoNormal"><b><span lang="ZH-CN" \
style="font-family:宋体;color:#1F497D">"</span></b><b><span \
style="font-family:"Calibri",sans-serif;color:#1F497D">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…" <o:p></o:p></span></b></p> <p \
class="MsoNormal"><b><span \
style="font-family:"Calibri",sans-serif;color:#1F497D"> "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)."<o:p></o:p></span></b></p>
<p class="MsoNormal"><b><span \
style="font-family:"Calibri",sans-serif;color:#1F497D">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. \
<o:p></o:p></span></b></p> <p class="MsoNormal"><b><span \
style="font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></b></p>
<p class="MsoNormal"><b><span \
style="font-family:"Calibri",sans-serif;color:#1F497D">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. <o:p></o:p></span></b></p> <p class="MsoNormal"><b><span \
style="font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></b></p>
<p class="MsoNormal"><b><span \
style="font-family:"Calibri",sans-serif;color:#1F497D">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)." <o:p></o:p></span></b></p>
<p class="MsoNormal"><b><span \
style="font-family:"Calibri",sans-serif;color:#1F497D">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. \
<o:p></o:p></span></b></p> <p class="MsoNormal"><b><span \
style="font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></b></p>
<p class="MsoNormal"><b><span \
style="font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></b></p>
<p class="MsoNormal"><b><span \
style="font-family:"Calibri",sans-serif;color:#1F497D">BR,<o:p></o:p></span></b></p>
<p class="MsoNormal"><b><span \
style="font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></b></p>
<p class="MsoNormal"><b><span \
style="font-family:"Calibri",sans-serif;color:#1F497D">Yunan<o:p></o:p></span></b></p>
<p class="MsoNormal"><b><span \
style="font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></b></p>
<p class="MsoNormal"><b><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> GROW \
[mailto:grow-bounces@ietf.org] <b>On Behalf Of </b>Robert Raszuk<br>
<b>Sent:</b> 2018</span><span lang="ZH-CN" \
style="font-size:11.0pt;font-family:宋体">年</span><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif">7</span><span \
lang="ZH-CN" style="font-size:11.0pt;font-family:宋体">月</span><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif">11</span><span \
lang="ZH-CN" style="font-size:11.0pt;font-family:宋体">日</span><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> 17:25<br>
<b>To:</b> Tim Evens (tievens) <tievens=40cisco.com@dmarc.ietf.org><br>
<b>Cc:</b> Greg Skinner <gregskinner0=40icloud.com@dmarc.ietf.org>; GMO Crops \
<grow@ietf.org>; lsr@ietf.org; opsawg@ietf.org; rtgwg@ietf.org<br> \
<b>Subject:</b> Re: [GROW] [Lsr] FW: New Version Notification for \
draft-gu-network-mornitoring-protol-00.txt<o:p></o:p></span></p> <p \
class="MsoNormal"><o:p> </o:p></p> <div>
<div>
<p class="MsoNormal"><span \
style="font-family:"Arial",sans-serif">Tim,<o:p></o:p></span></p> </div>
<div>
<p class="MsoNormal"><span \
style="font-family:"Arial",sans-serif"><o:p> </o:p></span></p> </div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif">I already \
suggested use of BGP-LS *as-is* in this thread on Jul \
6th. <o:p></o:p></span></p> </div>
<div>
<p class="MsoNormal"><span \
style="font-family:"Arial",sans-serif"><o:p> </o:p></span></p> </div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif">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. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span \
style="font-family:"Arial",sans-serif"><o:p> </o:p></span></p> </div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif">Thx,<br>
R.<o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Wed, Jul 11, 2018 at 2:40 AM, Tim Evens (tievens) <<a \
href="mailto:tievens=40cisco.com@dmarc.ietf.org" \
target="_blank">tievens=40cisco.com@dmarc.ietf.org</a>> wrote:<o:p></o:p></p> \
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm \
6.0pt;margin-left:4.8pt;margin-right:0cm"> <div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Hi \
Robin, Yunan, Shunwan,<o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I'm a \
little late to this thread due to being preoccupied with a newborn. \
<o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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. <o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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. <o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">"Section \
3.1, ISIS Adjacency Issues"<o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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). <o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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.<o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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 <a \
href="https://tools.ietf.org/html/draft-ietf-grow-bmp-local-rib-01" target="_blank"> \
https://tools.ietf.org/html/draft-ietf-grow-bmp-local-rib-01</a>). Adding LINK/NODE \
withdrawal/down reason should not overstep into YANG/Netconf/Telemetry. \
<o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">"3.2. \
Forwarding Path Disconnection" <o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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. <o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">"3.3. ISIS LSP \
Synchronization Failure"<o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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.<o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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. <o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">"4. \
Extensions of NMP for ISIS" <o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Most of \
the new messages are redundant to the existing BGP-LS advertisements and \
withdrawals. Telemetry of course could also convey this… <o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">The \
initiation message could lead to overloading it with all kinds of device specific \
info. Some constraint is needed.<o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">The per \
peer (adjacency) header is missing multi-topology. BGP-LS includes the protocol \
type (e.g. CT) and MT (missing from this draft). <o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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. <o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Thanks,<o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Tim<o:p></o:p></p> <div>
<div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt"> On \
7/8/18, 8:59 PM, "GROW on behalf of Greg Skinner" <<a \
href="mailto:grow-bounces@ietf.org" target="_blank">grow-bounces@ietf.org</a> on \
behalf of <a href="mailto:gregskinner0=40icloud.com@dmarc.ietf.org" \
target="_blank">gregskinner0=40icloud.com@dmarc.ietf.org</a>> \
wrote:<o:p></o:p></p> </div>
</div>
<div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt"> \
<o:p></o:p></p> </div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt"> Randy, \
<o:p></o:p></p> <div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt"> \
<o:p></o:p></p> </div>
<div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt"> Is \
the <a href="https://www.ietf.org/proceedings/52/176.htm" target="_blank">OPS-NM \
Configuration Management Requirements (ops-nm) Bof</a> 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 <a \
href="https://www.snmpcenter.com/snmp-versus-other-protocols/" target="_blank">SNMP \
compared with CLI, Netconf, Netflow</a> that culminated in <a \
href="https://tools.ietf.org/html/rfc3535" target="_blank">RFC 3535</a>. \
<o:p></o:p></p> <div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt"> \
<o:p></o:p></p> </div>
<div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt"> \
Robin,<o:p></o:p></p> </div>
<div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt"> \
<o:p></o:p></p> </div>
<div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt"> \
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.<o:p></o:p></p> </div>
<div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt"> \
<o:p></o:p></p> </div>
<div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt"> \
Regards,<o:p></o:p></p> </div>
<div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt"> \
Greg<o:p></o:p></p> </div>
<div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt"> \
<o:p></o:p></p> <div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt"> On Jul \
7, 2018, at 8:25 PM, Randy Bush <<a href="mailto:randy@psg.com" \
target="_blank">randy@psg.com</a>> wrote:<o:p></o:p></p> </div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt"> \
<o:p></o:p></p> <div>
<div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;margin-bottom:12.0pt;margin-left:36.0pt"> robin,<br>
<br>
i am not ignoring you. i did not want to write unless i had something<br>
possibly useful to say; and that requires pretending to think, always<br>
difficult.<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt"> I \
would also like to propose following draft for your reference which<br> trigger us to \
move forward for better network maintenance with<br> multiple tools in which \
gRPC/NETCOF and NMP/BMP may play different<br>
roles: <a href="https://datatracker.ietf.org/doc/draft-song-ntf/" target="_blank">
https://datatracker.ietf.org/doc/draft-song-ntf/</a><o:p></o:p></p>
</blockquote>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;margin-bottom:12.0pt;margin-left:36.0pt"> <br>
[ warning: my memory is likely fuzzy, and the glass is dark ]<br>
<br>
at an ietf in the late '90s[0], there was a hastily called meeting of<br>
the snmp standards bearers and a bunch of operators. the snmp folk were<br>
shocked to learn that no operators used snmp for other than monitoring;<br>
no one had snmp write enabled on devices; ops configured with the<br>
cli[1]. from this was born netconf and the xml path. credit where \
due:<br> phil eng was already well down this path at the time of that meeting.<br>
<br>
but netconf/xml was a mechanism and lacked a model. snmp had models,<br>
whether we thought they were pretty or not. thus yang was born, and ,<br>
of course, a new generation wants to use the latest modern toys such as<br>
restconf, openconfig, json, ...<br>
<br>
draft-song-ntf yearns for an "architectural framework for network<br>
telemetry," a lofty and worthwhile goal not, a priori, a bad one. but \
a<br> few comments from a jaded old dog.<br>
<br>
for a new paradigm to gain traction, it must be *significantly* better<br>
than the old one, or the old paradigm must be clearly failing. in the<br>
story above, snmp was clearly failing, aside from using an unfashionable<br>
encoding. and yang clearly provided something needed and missing from<br>
netconf. note that this paradigm shift has taken over 20 years; and we<br>
dis the itu et alia.<br>
<br>
second, draft-song-ntf is an export-only model. while telemetry is<br>
extremely important, i will be very frustrated if i can only hear and<br>
may not speak. and the more it evolves to a really attractive paradigm<br>
and model, the more annoyed i will be that i can not use it for control.<br>
<br>
and lastly, to quote don knuth, "premature optimization is the root of<br>
all evil." do not get distracted by squeezing bits out of an encoding.<br>
focus on things such as simple, clear, securable, extensible ...<br>
<br>
randy<br>
<br>
---<br>
<br>
0 - i would love help pinning down which meeting<br>
<br>
1 - i still have the "it's the cli, stupid" tee shirt. an \
american<br> political slogan of the era was "it's the \
economy, stupid."<o:p></o:p></p> </div>
</div>
</blockquote>
</div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt"> \
<o:p></o:p></p> </div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
GROW mailing list<br>
<a href="mailto:GROW@ietf.org">GROW@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/grow" \
target="_blank">https://www.ietf.org/mailman/listinfo/grow</a><o:p></o:p></p> \
</blockquote> </div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
--===============8974447043880204398==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic