Re: [Lsr] [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt
Robert Raszuk <robert@raszuk.net> Wed, 11 July 2018 09:24 UTC
Return-Path: <rraszuk@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B960130E20; Wed, 11 Jul 2018 02:24:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vv-4c4swfOW; Wed, 11 Jul 2018 02:24:54 -0700 (PDT)
Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6634B130DDA; Wed, 11 Jul 2018 02:24:54 -0700 (PDT)
Received: by mail-pf0-x22a.google.com with SMTP id l123-v6so18020331pfl.13; Wed, 11 Jul 2018 02:24:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=9jB9WPDOdvCB8R4igLhyI6eY+mkFf/VM6CMOGN7ZBPU=; b=lcfVDcgO10INtCWk6EllfBKvmc5nzi8GYF3aVhyp2HRbwr4Yomxu/ygC/MMW93kHEX 1wPeqJJjmM+ud/TUB26+76NDjfu7AYRRqP7R0oXfU7Pu7OlbQMVmhKJ+KH01Wv65/tsg J2DQDOlI6nd452cbaHQNy0UxuK1MO1/iv/CkK4Uum4bkOUXrtiEQlhjMOrH06JzvWkMQ 0+8PFnsbq83IUf1+IpWr1sFK/1JyJkH3iWrvNxFJmmtZ1qz6KIvQNKq9FvcNxNHVCt4s 4UfgsQolq5Afy+lcM4WIA8SxEv7pUh6kO1OAR4A4ovZQUo/Rt7vrv74KvlVNfK+HiDFU URVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=9jB9WPDOdvCB8R4igLhyI6eY+mkFf/VM6CMOGN7ZBPU=; b=b7AVy82cllVEPg+7EmcVUVUWe4VOALDRbcUgLa5lvtGvVRfPXI2DT2mWUtuU0J6g5i HTrGA6z5EFyH2jeVXVrGXHeq1yEjEmt04LAo5NUUDW3FXwCQ+6WHoS8sk/125JQHCBxP bHPAERKypPgU4QHJrJHb3Xa2GbHqUW0wGiiUnzbbEr+K6KuCkxxxTykLgRjwXZNgwKeM /rDTKRdOx0S7oBAmDHAuXfn9wqj35BkMe2ujllgWuJL3jI7H78I8iMK8hBBcaKaulPoc +9C0QW1e9Iz8/ItjrAJq+gqIpi9NqwTczgy+MCu1Iqdiv30UYrjEGNXzVe9KGPNw+MvR OSRQ==
X-Gm-Message-State: APt69E13UWnItkA54ZquhCxXAhzko+bzVVDodFt0etnZWV3RxjMIk8d9 J0hx30jPs9q8NL2y7/T15XXuVhzcMtjXT6PoCBolxw==
X-Google-Smtp-Source: AAOMgpdzkf608LiKusXPwRoVymgi5a3b0RMAZVs5to7o4fdOQ0rSeQ6KRF6IKC6A2NwU3PgnFwTiEMEBKkVUzGjpIiM=
X-Received: by 2002:a65:4005:: with SMTP id f5-v6mr24846483pgp.302.1531301093636; Wed, 11 Jul 2018 02:24:53 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 2002:a17:90a:c303:0:0:0:0 with HTTP; Wed, 11 Jul 2018 02:24:52 -0700 (PDT)
In-Reply-To: <646634D0-AB75-4715-AB1C-8BB378F2ADF6@cisco.com>
References: <624FB76E-1588-4D6E-8DD6-A666C77A9201@gmail.com> <5A5B4DE12C0DAC44AF501CD9A2B01A8D8F43FE44@dggemm512-mbx.china.huawei.com> <B8E2C2E6-BE62-4624-A2AD-E54647ED8EF1@cisco.com> <5A5B4DE12C0DAC44AF501CD9A2B01A8D8F4403E7@dggemm512-mbx.china.huawei.com> <m236wu8l40.wl-randy@psg.com> <14AE5E1F-CE52-4061-A1B5-F34FCA8E461F@icloud.com> <646634D0-AB75-4715-AB1C-8BB378F2ADF6@cisco.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 11 Jul 2018 11:24:52 +0200
X-Google-Sender-Auth: Gwg86mTRT5CNPtJVbEcnyyUwEH4
Message-ID: <CA+b+ERkC3F3B676Wmmv6QGE7_cR-xyOzLCbZEK3M3EVm8vwcSQ@mail.gmail.com>
To: "Tim Evens (tievens)" <tievens=40cisco.com@dmarc.ietf.org>
Cc: Greg Skinner <gregskinner0=40icloud.com@dmarc.ietf.org>, Randy Bush <randy@psg.com>, "lizhenbin@huawei.com" <lizhenbin@huawei.com>, "lsr@ietf.org" <lsr@ietf.org>, GMO Crops <grow@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000baff480570b5d146"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/aJRsgx-AA1gME0yfZEiNi14urXU>
Subject: Re: [Lsr] [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Jul 2018 09:24:57 -0000
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> 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 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 <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 > https://www.ietf.org/mailman/listinfo/grow > >
- Re: [Lsr] [OPSAWG] [GROW] FW: New Version Notific… Acee Lindem (acee)
- Re: [Lsr] [OPSAWG] [GROW] FW: New Version Notific… Haoyu song
- Re: [Lsr] [OPSAWG] [GROW] FW: New Version Notific… Jeff Tantsura
- Re: [Lsr] [GROW] FW: New Version Notification for… Greg Skinner
- Re: [Lsr] [GROW] FW: New Version Notification for… Randy Bush
- Re: [Lsr] [OPSAWG] [GROW] FW: New Version Notific… Randy Bush
- Re: [Lsr] [GROW] FW: New Version Notification for… Lizhenbin
- Re: [Lsr] [GROW] FW: New Version Notification for… Acee Lindem (acee)
- Re: [Lsr] [OPSAWG] [GROW] FW: New Version Notific… Randy Bush
- Re: [Lsr] [GROW] FW: New Version Notification for… Jeff Tantsura
- Re: [Lsr] [OPSAWG] [GROW] FW: New Version Notific… Lizhenbin
- Re: [Lsr] [OPSAWG] [GROW] FW: New Version Notific… Einar Nilsen-Nygaard (einarnn)
- Re: [Lsr] [GROW] FW: New Version Notification for… Lizhenbin
- Re: [Lsr] [GROW] FW: New Version Notification for… Lizhenbin
- Re: [Lsr] [GROW] FW: New Version Notification for… Acee Lindem (acee)
- Re: [Lsr] [GROW] FW: New Version Notification for… Acee Lindem (acee)
- Re: [Lsr] [GROW] FW: New Version Notification for… Randy Bush
- Re: [Lsr] [OPSAWG] [GROW] FW: New Version Notific… Einar Nilsen-Nygaard (einarnn)
- Re: [Lsr] [GROW] FW: New Version Notification for… Robert Wilton
- Re: [Lsr] [OPSAWG] [GROW] FW: New Version Notific… Robert Raszuk
- Re: [Lsr] [GROW] FW: New Version Notification for… Lizhenbin
- Re: [Lsr] [GROW] FW: New Version Notification for… Tim Evens (tievens)
- Re: [Lsr] [GROW] FW: New Version Notification for… Robert Raszuk
- Re: [Lsr] [GROW] FW: New Version Notification for… Randy Bush
- Re: [Lsr] [GROW] FW: New Version Notification for… Guyunan (Yunan Gu, IP Technology Research Dept. NW)
- Re: [Lsr] [GROW] FW: New Version Notification for… Guyunan (Yunan Gu, IP Technology Research Dept. NW)