Hi Peter, Many thanks for your feedback. First of all, I'm sorry for the confusion I had caused you from my previous misunderstanding.
And I want to clarify that a single and common LSDB is shared by all MFIs. Best, Yali -----Original Message----- From: Peter Psenak [mailto:[email protected]] Sent: Sunday, February 28, 2021 8:23 PM To: Gyan Mishra <[email protected]>; Robert Raszuk <[email protected]> Cc: Huzhibo <[email protected]>; Aijun Wang <[email protected]>; Tony Li <[email protected]>; lsr <[email protected]>; Tianran Zhou <[email protected]>; wangyali <[email protected]> Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt 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. > > 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. thanks, Peter > > Gyan > > On Fri, Feb 26, 2021 at 7:10 AM Robert Raszuk <[email protected] > <mailto:[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] > <mailto:[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] >> <mailto:[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] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > [email protected] <mailto:[email protected]> > 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 > > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
