Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

wangyali <> Mon, 01 March 2021 09:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1EF743A18E3 for <>; Mon, 1 Mar 2021 01:43:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 671AoYTakhxt for <>; Mon, 1 Mar 2021 01:43:11 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B8CC93A18E2 for <>; Mon, 1 Mar 2021 01:43:10 -0800 (PST)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4Dpw9K2TWHz67tq0; Mon, 1 Mar 2021 17:35:33 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 1 Mar 2021 10:43:08 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.2106.2 via Frontend Transport; Mon, 1 Mar 2021 10:43:07 +0100
Received: from ([]) by ([]) with mapi id 14.03.0509.000; Mon, 1 Mar 2021 17:42:51 +0800
From: wangyali <>
To: Gyan Mishra <>, Robert Raszuk <>
CC: Aijun Wang <>, Huzhibo <>, Tianran Zhou <>, Tony Li <>, lsr <>
Thread-Topic: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt
Date: Mon, 1 Mar 2021 09:42:52 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/related; boundary="_004_1520992FC97B944A9979C2FC1D7DB0F405242257dggeml524mbxchi_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 01 Mar 2021 09:43:13 -0000

Hi Robert,

Thanks for your comments. But one process N threads or N processes, which is indeed a implementation not a protocol. Hence, we do not discuss this problem in this draft.

I fully agree with Gyan. MFIs share a common adjacencies, and a single LSDB. And each MFI can have its own flooding sub topology and its customized flooding parameters.

Best regards,

From: Gyan Mishra []
Sent: Saturday, February 27, 2021 12:19 AM
To: Robert Raszuk <>
Cc: Aijun Wang <>cn>; Huzhibo <>om>; Tianran Zhou <>om>; Tony Li <>li>; lsr <>rg>; wangyali <>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

MFI seems more like flex algo with multiple sub topologies sharing a common links in a  topology where RFC 8202 MI is separated at the process level separate LSDB.  So completely different and of course different goals and use cases for MI versus MFI.

 MFI also seems to be a flood reduction mechanism by creating multiple sub topology instances within a common LSDB.  There are a number of flood reduction drafts and this seems to be another method of achieving the same.


On Fri, Feb 26, 2021 at 7:10 AM Robert Raszuk <<>> wrote:

How multi instance is implemented is at the discretion of a vendor. It can be one process N threads or N processes. It can be both and operator may choose.

MFI is just one process - by the spec - so it is inferior.


On Fri, Feb 26, 2021 at 12:44 PM Aijun Wang <<>> wrote:
Hi, Robert:

Separate into different protocol instances can accomplish the similar task, but it has some deployment overhead.
MFIs within one instance can avoid such cumbersome work, and doesn’t affect the basic routing calculation process.
Aijun Wang
China Telecom

On Feb 26, 2021, at 19:00, Robert Raszuk <<>> wrote:

Hi Yali,

If this was precise, then the existing multi-instance mechanism would be sufficient.
[Yali]: MFI is a different solution we recommend to solve this same and valuable issue.

Well the way I understand this proposal MFI is much weaker solution in terms of required separation.

In contrast RFC8202 allows to separate ISIS instances at the process level, but here MFIs as defined must be handled by the same ISIS process

   This document defines an extension to

   IS-IS to allow one standard instance of

   the protocol to support multiple update

   process operations.


Lsr mailing list<>
Lsr mailing list<>

[Image removed by sender.]<>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD