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. Gyan On Fri, Feb 26, 2021 at 7:10 AM Robert Raszuk <[email protected]> wrote: > Aijun, > > 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. > > Cheers, > R. > > > On Fri, Feb 26, 2021 at 12:44 PM Aijun Wang <[email protected]> > 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 <[email protected]> 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. >> >> >> Thx, >> R. >> >> _______________________________________________ >> Lsr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lsr >> >> _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
