Peter On Sun, Feb 28, 2021 at 7:23 AM Peter Psenak <ppse...@cisco.com> wrote:
> Gyan, > > On 26/02/2021 17:19, Gyan Mishra wrote: > > > > 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. > > I would not use the fle-algo analogy - all flex-algos operate on top of > a single LSDB, contrary to what is being proposed in MFI draft. Gyan>. Thanks for clarification > > > > > > 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. > > MFI draft proposes to keep the separate LSDB per MFI, so the above > analogy is not correct either. Gyan> Thanks for clarification > > > thanks, > Peter > > > > > > Gyan > > > > On Fri, Feb 26, 2021 at 7:10 AM Robert Raszuk <rob...@raszuk.net > > <mailto:rob...@raszuk.net>> 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 <wang...@chinatelecom.cn > > <mailto:wang...@chinatelecom.cn>> 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 <rob...@raszuk.net > >> <mailto:rob...@raszuk.net>> 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 > >> Lsr@ietf.org <mailto:Lsr@ietf.org> > >> https://www.ietf.org/mailman/listinfo/lsr > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org <mailto:Lsr@ietf.org> > > https://www.ietf.org/mailman/listinfo/lsr > > > > -- > > > > <http://www.verizon.com/> > > > > *Gyan Mishra* > > > > /Network Solutions A//rchitect / > > > > /M 301 502-1347 > > 13101 Columbia Pike > > /Silver Spring, MD > > > > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
