Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Peter

On Sun, Feb 28, 2021 at 7:23 AM Peter Psenak <ppsenak@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 <robert@raszuk.net
> > <mailto:robert@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 <wangaj3@chinatelecom.cn
> >     <mailto:wangaj3@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 <robert@raszuk.net
> >>         <mailto:robert@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