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

Chenshuanglong <chenshuanglong@huawei.com> Wed, 06 January 2021 08:41 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 127B33A11FF for <opsawg@ietfa.amsl.com>; Wed, 6 Jan 2021 00:41:18 -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 UVHcrUa8yKpg for <opsawg@ietfa.amsl.com>; Wed, 6 Jan 2021 00:41:16 -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 103853A11FB for <opsawg@ietf.org>; Wed, 6 Jan 2021 00:41:16 -0800 (PST)
Received: from fraeml739-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4D9jRN2tp3z67XsV for <opsawg@ietf.org>; Wed, 6 Jan 2021 16:37:36 +0800 (CST)
Received: from nkgeml708-chm.china.huawei.com (10.98.57.160) by fraeml739-chm.china.huawei.com (10.206.15.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 6 Jan 2021 09:41:13 +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; Wed, 6 Jan 2021 16:41:11 +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; Wed, 6 Jan 2021 16:41:11 +0800
From: Chenshuanglong <chenshuanglong@huawei.com>
To: "opsawg@ietf.org" <opsawg@ietf.org>, "rwilton@cisco.com" <rwilton@cisco.com>
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: AdbkBuVmTBoOfapHT22ByKGN9scnuw==
Date: Wed, 06 Jan 2021 08:41:11 +0000
Message-ID: <832f3bf3f83543aba80afa53e607d74c@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.52.204.98]
Content-Type: multipart/alternative; boundary="_000_832f3bf3f83543aba80afa53e607d74chuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/5Ph7D8LMH48NsOrKroJP9YLHPyo>
Subject: [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: Wed, 06 Jan 2021 08:41:18 -0000

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