Re: [OPSAWG] IETF 109 - OPSAWG presentation https://tools.ietf.org/html/draft-gu-opsawg-network-monitoring-igp-00

Chenshuanglong <chenshuanglong@huawei.com> Thu, 07 January 2021 01:45 UTC

Return-Path: <chenshuanglong@huawei.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5803A12BB for <opsawg@ietfa.amsl.com>; Wed, 6 Jan 2021 17:45:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 bT0co4Oxbjn6 for <opsawg@ietfa.amsl.com>; Wed, 6 Jan 2021 17:45:54 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6CF03A126E for <opsawg@ietf.org>; Wed, 6 Jan 2021 17:45:53 -0800 (PST)
Received: from fraeml712-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4DB8BZ6NDdz67Xv5 for <opsawg@ietf.org>; Thu, 7 Jan 2021 09:43:02 +0800 (CST)
Received: from nkgeml708-chm.china.huawei.com (10.98.57.160) by fraeml712-chm.china.huawei.com (10.206.15.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 7 Jan 2021 02:45:51 +0100
Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml708-chm.china.huawei.com (10.98.57.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 7 Jan 2021 09:45:49 +0800
Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.2106.002; Thu, 7 Jan 2021 09:45:49 +0800
From: Chenshuanglong <chenshuanglong@huawei.com>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>, "opsawg@ietf.org" <opsawg@ietf.org>
CC: Lizhenbin <lizhenbin@huawei.com>, Guyunan <guyunan@huawei.com>, "chenhuanan@gsta.com" <chenhuanan@gsta.com>
Thread-Topic: IETF 109 - OPSAWG presentation https://tools.ietf.org/html/draft-gu-opsawg-network-monitoring-igp-00
Thread-Index: AdbkBuVmTBoOfapHT22ByKGN9scnuwAA6VMwACMETmA=
Date: Thu, 07 Jan 2021 01:45:49 +0000
Message-ID: <579e99dd8e18442c9a1ecfc2858b46bf@huawei.com>
References: <832f3bf3f83543aba80afa53e607d74c@huawei.com> <MN2PR11MB4366A7F9CDFE32E4ADAAD25BB5D00@MN2PR11MB4366.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB4366A7F9CDFE32E4ADAAD25BB5D00@MN2PR11MB4366.namprd11.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.164.34.220]
Content-Type: multipart/alternative; boundary="_000_579e99dd8e18442c9a1ecfc2858b46bfhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/5LiFq7PO9blp66bwLXJhPyjemvM>
Subject: Re: [OPSAWG] IETF 109 - OPSAWG presentation https://tools.ietf.org/html/draft-gu-opsawg-network-monitoring-igp-00
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jan 2021 01:45:57 -0000

Hi Rob,
Thank you very much for your suggestions. I will also discuss this in the LSVR or RTGWG workgroup.
As you mentioned, the draft is about IS-IS PDUs. This is why I am not inclined to continue to expand based on YANG.
In addition, draft-gray-sampled-streaming-03 is an very interesting solution. I'll think about these solutions.

Best Regards
Shuanglong

From: Rob Wilton (rwilton) [mailto:rwilton@cisco.com]
Sent: Wednesday, January 6, 2021 5:37 PM
To: Chenshuanglong <chenshuanglong@huawei.com>; opsawg@ietf.org
Cc: Lizhenbin <lizhenbin@huawei.com>; Guyunan <guyunan@huawei.com>; chenhuanan@gsta.com
Subject: RE: IETF 109 - OPSAWG presentation https://tools.ietf.org/html/draft-gu-opsawg-network-monitoring-igp-00

Hi Shuanglong,

[As a contributor]

I¡¯m not that familiar with BMP and I¡¯m not sure whether the BMP or routing experts are on the OPSAWG list.  If you have not already done so, then presenting this work in RTGWG and LSVR WGs may help see if there are more interested parties in those WGs, if you are not getting traction/interest within OPSAWG.

For me, I think the main question is what is the overlap between the information proposed by this draft to be exported via BMP extensions and what is already covered by the IS-IS YANG model (https://tools.ietf.org/html/draft-ietf-isis-yang-isis-cfg-42 ¨C which is already in the RFC editor queue)?  If there is useful state information missing from the YANG model then it might be more effective to extend the IS-IS YANG model than provide an alternative mechanism to provide the same information.  I expect that the LSVR WG would probably be the best place to discuss this.

The one possible exception is the IS-IS PDUs.  It may be that extending BMP to be able to report those PDUs might be better than putting them in a YANG model (although interestingly, my understanding was that the OpenConfig approach was to expose the IS-IS PDUs via YANG, although that information might be out of date).  It would also be worth considering whether https://tools.ietf.org/html/draft-gray-sampled-streaming-03 could also be an effective solution for exporting ISIS PDUs for debugging/monitoring purposes, if that was within the remit of its filtering capabilities.

Regards,
Rob


From: Chenshuanglong <chenshuanglong@huawei.com<mailto:chenshuanglong@huawei.com>>
Sent: 06 January 2021 08:41
To: opsawg@ietf.org<mailto:opsawg@ietf.org>; Rob Wilton (rwilton) <rwilton@cisco.com<mailto:rwilton@cisco.com>>
Cc: Lizhenbin <lizhenbin@huawei.com<mailto:lizhenbin@huawei.com>>; Guyunan <guyunan@huawei.com<mailto:guyunan@huawei.com>>; chenhuanan@gsta.com<mailto:chenhuanan@gsta.com>
Subject: IETF 109 - OPSAWG presentation https://tools.ietf.org/html/draft-gu-opsawg-network-monitoring-igp-00

hi all,

I presented network-monitoring-igp draft at IETF 109, see attached.  https://tools.ietf.org/html/draft-gu-opsawg-network-monitoring-igp-00
We suggest to use BMP to monitor IGPs to avoid setting too many monitoring protocols for different control plane protocols.
In addition, it describes the requirements for collecting IGP information, such as the use cases listed in the draft.

Use Case1£ºIS-IS Route Flapping
   The IS-IS Route Flapping refers to the situation that one or more routes appear and then disappear in the routing table repeatedly.
   Route flapping usually comes with massive PDUs interactions (e.g., LSP, LSP purge...), which consume excessive network bandwidth, and excessive CPU processing.
In addition, the impact is often network-wide.  The localizing of the flapping source and the identifying of root causes haven't been easy work due to various reasons.

Use Case2£º IS-IS LSDB Synchronization Failure
   During the IS-IS flooding, sometimes the LSP synchronization failure happens.  The synchronization failure causes can be generally classified into three cases£¬(1) the LSP is not correctly advertised£¬ (2) LSP transmission error, (3) the LSP is received but not correctly processed.

What do you think of these use cases and extended BMP protocols?

Kind Regards
Shuanglong Chen