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

wangyali <> Fri, 26 February 2021 10:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A07CB3A0FDF for <>; Fri, 26 Feb 2021 02:01:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2Tj6SCTOpDI8 for <>; Fri, 26 Feb 2021 02:01:31 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3CCE53A0FD3 for <>; Fri, 26 Feb 2021 02:01:31 -0800 (PST)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4Dn4nt57pBz67sgf for <>; Fri, 26 Feb 2021 17:57:22 +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; Fri, 26 Feb 2021 11:01:28 +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; Fri, 26 Feb 2021 11:01:28 +0100
Received: from ([]) by ([]) with mapi id 14.03.0509.000; Fri, 26 Feb 2021 18:01:19 +0800
From: wangyali <>
To: Tony Li <>
CC: "" <>, Huzhibo <>, Tianran Zhou <>, Aijun Wang <>
Thread-Topic: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt
Thread-Index: AQHXCjBTvOSvDlAmT0KIo+Iqe5eLAapoLAHQgABk14CAAYtOcA==
Date: Fri, 26 Feb 2021 10:01:18 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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: Fri, 26 Feb 2021 10:01:36 -0000

Hi Tony,

Glad to receive your more comments. Please see my reply inline [Yali].

-----Original Message-----
From: Tony Li [] On Behalf Of Tony Li
Sent: Friday, February 26, 2021 12:46 AM
To: wangyali <>
Cc:; Huzhibo <>om>; Tianran Zhou <>om>; Aijun Wang <>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Hi Yali,

Thank you for your reply. More comments...

> Given this, what is it that you’re trying to accomplish?  You’ve called this a ‘multi-flooding instance’, but it’s very unclear about what that means.  You say that multiple MFIs exist within a single IS-IS instance.
>>> Yali: The ‘multi-flooding instance' means that multiple Update process are allowed operating within the zero IS-IS instance. Each Update process is associated with a topology and a LSDB. Flooding parameters of each Update process can be different and customized based on different information needed to be advertised in the associated Flooding Instance. 
> Although each Flooding Instance has its own separate Update process, flooding topology and LSDB, these multiple flooding instances share a common adjacencies.

Again, I think that any comment about implementation internals is irrelevant, and thus the existence of a process is irrelevant.  If I’m understanding you, each MFI has an independent topology and LSDB. This is true with the current multi-instance document. Where you seem to differ is in having common adjacencies. To me, this implies that the topologies may overlap.  Is this correct?
[Yali]: Yes. If I understand the meaning of overlap you said. The flooding topology of MFI #0 and the flooding topology of MFI #1 may overlap. For example, as shown in the following simple topology, MFI #0 is reserved for the routing information flooding in a full topology which is used for routing calculation. And other MFI #1 is used for non-routing information flooding in a sub-topology (on the Link 1 and Link 2) or the full topology. 

                    Node A                                                                                      Node B
=====================                                           =====================            
|           IS-IS Instance 0          |                                           |         IS-IS Instance 0           |
|                                                    |                  Link 1             |                                                   |
|                  MFI #0                    |****************|                   MFI #0                  |
|                  MFI #1                    |                                           |                   MFI #1                 |
=====================                                            =====================
                                 *                                                                                          *
		    *                                                                                   *
		      *                                                                             *
	         Link 2    *                                                                        *  Link 3
		           *                                                                  *
	                              *                                                           *
                                                  *                  Node C                 *
                                                 |          IS-IS Instance 0           |
                                                 |                                                    |
                                                 |                  MFI #0                    |
			 |                  MFI #1                    |

Have you considered using link level partitioning (e.g., VLANs) and just using multi-instance?
[Yali]: From our consideration, MFIs specified in this document are not partitioned at link level. As shown in above figure, two MFIs can operate on the same link (e.g., Link 1) between two neighbors A and B. while the priority, flooding parameters and the flooding topology of each MFI can be customized. In this way, the deployment is simpler and cost of adjacencies maintenance is lower.

> What problem are you solving?
>>> Yali: The problem we are trying to solve is how to isolate application information flooding from the routing information flooding through multiple flooding instance.

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.