Hi Tony, Glad to receive your more comments. Please see my reply inline [Yali].
-----Original Message----- From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of Tony Li Sent: Friday, February 26, 2021 12:46 AM To: wangyali <wangyal...@huawei.com> Cc: lsr@ietf.org; Huzhibo <huzh...@huawei.com>; Tianran Zhou <zhoutian...@huawei.com>; Aijun Wang <wang...@chinatelecom.cn> 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. Tony _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
