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@ > 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 <ra...@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 > https://www.ietf.org/mailman/listinfo/grow > >
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
