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? Have you considered using link level partitioning (e.g., VLANs) and just using multi-instance? > 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. Tony _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
