Re: [Idr] [Lsr] [GROW] IGP Monitoring Protocol

Tianran Zhou <zhoutianran@huawei.com> Wed, 13 July 2022 09:55 UTC

Return-Path: <zhoutianran@huawei.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B30CAC157B55; Wed, 13 Jul 2022 02:55:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgvtCsWaF0A3; Wed, 13 Jul 2022 02:55:43 -0700 (PDT)
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 B868DC14F733; Wed, 13 Jul 2022 02:55:42 -0700 (PDT)
Received: from fraeml710-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4LjXv80zl2z6H7DM; Wed, 13 Jul 2022 17:51:16 +0800 (CST)
Received: from kwepemi500010.china.huawei.com (7.221.188.191) by fraeml710-chm.china.huawei.com (10.206.15.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 13 Jul 2022 11:55:38 +0200
Received: from kwepemi500009.china.huawei.com (7.221.188.199) by kwepemi500010.china.huawei.com (7.221.188.191) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 13 Jul 2022 17:55:36 +0800
Received: from kwepemi500009.china.huawei.com ([7.221.188.199]) by kwepemi500009.china.huawei.com ([7.221.188.199]) with mapi id 15.01.2375.024; Wed, 13 Jul 2022 17:55:36 +0800
From: Tianran Zhou <zhoutianran@huawei.com>
To: Jeffrey Haas <jhaas@pfrc.org>
CC: Robert Raszuk <robert@raszuk.net>, Yingzhen Qu <yingzhen.ietf@gmail.com>, idr <idr@ietf.org>, grow <grow@ietf.org>, lsr <lsr@ietf.org>
Thread-Topic: [Lsr] [Idr] [GROW] IGP Monitoring Protocol
Thread-Index: AQHYli9Nrb7fzoYS6E+UydX8EssokK18EDKA
Date: Wed, 13 Jul 2022 09:55:36 +0000
Message-ID: <3f9b701f8d4142ef83114e2864ae8668@huawei.com>
References: <CAOj+MMHN5knfMyuuGu6t9fXteyDgQ19H2K_VYhyZ-rmnCMNPsg@mail.gmail.com> <F8392B56-E825-4351-9A5B-77726F12ADA5@gmail.com> <BYAPR08MB487235B00D83D4C8ACDD7426B3859@BYAPR08MB4872.namprd08.prod.outlook.com> <CABNhwV397brAMP+x4Ve06xiYpRDy7V1_bmKT5_nuOmeEwofrgg@mail.gmail.com> <FA1C146F-38F0-4C8B-95A4-FD43578D76DC@gmail.com> <CAOj+MMFfcUazjih-zEPHvz2-cceYYg87Y2M3c=B0uC10PidCNg@mail.gmail.com> <704FD9FD-CFF7-4E1B-AE4A-3D0420E93270@cisco.com> <CAOj+MMHEKdYGNGzjvcN2-RaSniff3jcPDtvS5=dSoztG=DOpYQ@mail.gmail.com> <B5E09333-EF5A-4F24-BB4B-F251571EEB97@gmail.com> <CAOj+MMGzWUg2kRoL0GjRQ3C7q3+PtXPmhqaYoCjEu41SyO85tA@mail.gmail.com> <2ef07335ec534e0397aba43b22e2c422@huawei.com> <8E6735E8-1934-4F82-A396-8E6BE1BB3AC4@pfrc.org> <bfb908ce520b4c7fafbd7ef99e833314@huawei.com> <36964D15-FD1C-43CE-9E69-492856986319@pfrc.org>
In-Reply-To: <36964D15-FD1C-43CE-9E69-492856986319@pfrc.org>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.40.195]
Content-Type: multipart/alternative; boundary="_000_3f9b701f8d4142ef83114e2864ae8668huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/R3OyUkgGDoM1UoT-9qCUSA60IF0>
Subject: Re: [Idr] [Lsr] [GROW] IGP Monitoring Protocol
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jul 2022 09:55:46 -0000

Hi Jeff,

Thanks very much for your review and detailed comments.
All are reasonable to me.
We will work through the document and address your comments.

Thanks,
Tianran

From: Jeffrey Haas [mailto:jhaas@pfrc.org]
Sent: Wednesday, July 13, 2022 4:37 AM
To: Tianran Zhou <zhoutianran@huawei.com>
Cc: Robert Raszuk <robert@raszuk.net>; Yingzhen Qu <yingzhen.ietf@gmail.com>; idr <idr@ietf.org>; grow <grow@ietf.org>; lsr <lsr@ietf.org>
Subject: Re: [Lsr] [Idr] [GROW] IGP Monitoring Protocol

Tianran,

On Jul 11, 2022, at 10:42 PM, Tianran Zhou <zhoutianran=40huawei.com@dmarc.ietf.org<mailto:zhoutianran=40huawei.com@dmarc.ietf.org>> wrote:

Hi Jeff,

Our work is not to propose a new protocol.
https://datatracker.ietf.org/doc/html/draft-gu-opsawg-network-monitoring-igp-01
Our idea is to use BMP for IGP monitoring. We just choose BMP as the vehicle.

Thanks for the pointer to this document.  I had not previously read it.

The use case portion of the document is clear and well-written.

I don't pretend to be an expert in any of the IGPs, but here are a few observations from my read-through of the document:

- Should the per-adjacency header include something like ifIndex as part of its information?  This might help with troubleshooting misconfigured interfaces.
- In places where fields are Reserved, please use text in the form of "MUST be set to zero on transmission and SHOULD be ignored on reception".
- Your reason type and statistics type fields should get IANA sections and IANA allocation policy for allocating future code points.
- Your statistics TLV could probably be patterned more like that of the main BMP RFC.  That would permit more than one statistic to be attached at a time.
   + Statistic Value says that it is always 4 bytes of length.  If it's a fixed length, you may not require a length.  But I think you'll want this to be variably sized.  Some fields should be a 64-bit gauge; see BMP RFC for examples.
- The document should procedurally describe what happens when a session is first established.  For BGP BMP, the full RIB set is exchanged.  For this proposal, very likely the intent is that the LSDB is transmitted.  Given the incremental nature of IS-IS messages, it may be necessary to describe similar "end of rib" procedures that are in the BGP BMP specification in the context of your draft.  Afterwards, propagating the raw IS-IS PDUs in your messages will likely make sense.

-- Jeff