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

Yali

I agree with a Peter.

As for resource isolation and provisioning of a VTN I think you really need
separate LSDB instances provided by MT or MI as better suited for network
slicing.

To me it seems a common LSDB shared among network slices VTN underlay could
be problematic with network overlap issues.

Kind Regards

Gyan

On Fri, Mar 5, 2021 at 10:28 AM Peter Psenak <ppsenak@cisco.com> wrote:

> Hi Yali,
>
> On 05/03/2021 15:31, wangyali wrote:
> > Hi Peter,
> >
> > Thanks for your question. Please see inline [yali3].
> >
> > -----Original Message-----
> > From: Peter Psenak [mailto:ppsenak@cisco.com]
> > Sent: Thursday, March 4, 2021 11:20 PM
> > To: wangyali <wangyali11@huawei.com>; Gyan Mishra <hayabusagsm@gmail.com>;
> Robert Raszuk <robert@raszuk.net>
> > Cc: Huzhibo <huzhibo@huawei.com>; Aijun Wang <wangaj3@chinatelecom.cn>;
> Tony Li <tony.li@tony.li>; lsr <lsr@ietf.org>; Tianran Zhou <
> zhoutianran@huawei.com>
> > Subject: Re: [Lsr] New Version Notification for
> draft-wang-lsr-isis-mfi-00.txt
> >
> > Hi Yali,
> >
> > On 04/03/2021 14:45, wangyali wrote:
> >> Hi Peter,
> >>
> >> Please see inline [Yali2]. Thanks a lot.
> >>
> >> -----Original Message-----
> >> From: Peter Psenak [mailto:ppsenak@cisco.com]
> >> Sent: Thursday, March 4, 2021 6:50 PM
> >> To: wangyali <wangyali11@huawei.com>; Gyan Mishra
> >> <hayabusagsm@gmail.com>; Robert Raszuk <robert@raszuk.net>
> >> Cc: Huzhibo <huzhibo@huawei.com>; Aijun Wang
> >> <wangaj3@chinatelecom.cn>; Tony Li <tony.li@tony.li>; lsr
> >> <lsr@ietf.org>; Tianran Zhou <zhoutianran@huawei.com>
> >> Subject: Re: [Lsr] New Version Notification for
> >> draft-wang-lsr-isis-mfi-00.txt
> >>
> >> Hi Yali,
> >>
> >> On 04/03/2021 11:42, wangyali wrote:
> >>> Hi Peter,
> >>>
> >>> Please review follows tagged by [Yali].
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: Peter Psenak [mailto:ppsenak@cisco.com]
> >>> Sent: Wednesday, March 3, 2021 5:37 PM
> >>> To: wangyali <wangyali11@huawei.com>; Gyan Mishra
> >>> <hayabusagsm@gmail.com>; Robert Raszuk <robert@raszuk.net>
> >>> Cc: Huzhibo <huzhibo@huawei.com>; Aijun Wang
> >>> <wangaj3@chinatelecom.cn>; Tony Li <tony.li@tony.li>; lsr
> >>> <lsr@ietf.org>; Tianran Zhou <zhoutianran@huawei.com>
> >>> Subject: Re: [Lsr] New Version Notification for
> >>> draft-wang-lsr-isis-mfi-00.txt
> >>>
> >>> Yali,
> >>>
> >>> On 03/03/2021 06:02, wangyali wrote:
> >>>> Hi Peter,
> >>>>
> >>>> Thanks for your comments. Yes. I am improving this sentence. Please
> review the following update.
> >>>>
> >>>> OLD: " And Level 1/Level 2 PSNP and Level 1/Level 2 CSNP containing
> information about LSPs that transmitted in a specific MFI are generated to
> synchronize the LSDB corresponding to the specific MFI."
> >>>>
> >>>> NEW: "And Level 1/Level 2 PSNP and Level 1/Level 2 CSNP containing
> information about LSPs that transmitted in a specific MFI are generated to
> synchronize the MFI-specific sub-LSDB. Each MFI-specific sub-LSDB is
> subdivided from a single LSDB."
> >>>
> >>> please specify sub-LSDB.
> >>> [Yali] Thanks for your comment. But to avoid introducing a new term, I
> change to use "MFI-specific LSDB" instead of " MFI-specific sub-LSDB ".
> And we give the explanation that "Each MFI-specific LSDB is subdivided from
> a single LSDB."
> >>
> >> I wonder what is the difference between "MFI-specific LSDB subdivided
> from a single LSDB" versus the "MFI-specific LSDB".
> >> [Yali2]: Actually I am trying to optimize and accurately describe the
> key point that multiple Update processes associated with each MFI operate
> on a common LSDB within the zero IS-IS instance, and each Update process is
> isolated from each other and does not affect each other.
> >> So we say "MFI-specific LSDB subdivided from a single LSDB", which may
> explicitly indicate each MFI-specific LSDB shares a common LSDB but each
> Update process associated with a MFI is isolated. However, from your
> previous question and suggestions,  "MFI-specific LSDB" looks like unclear
> and misleading. Any good idea on improving the expression are welcome.
> >
> >
> > it's not the name that is as important. It's the concept that looks
> questionable - how well can you isolate the update processing if the data
> are part of the same LSDB and whether such update process separation would
> prove to be useful at all. I don't know, so far I have not seen any
> evidence.
> > [yali3] This draft defines a new TLV, i.e. MFI-ID TLV,  which may be
> included in each Level 1/Level 2 IS-IS LSPs and SNPs. Hence, each Level
> 1/Level 2 LSPs and SNPs associated with each Update Process can be uniquely
> identified by MFI-ID.
> > In this draft, each flooding instance has its own separated Update
> process, which isolates the impact of application information flooding on
> the IS-IS protocol operation. So each Level 1/Level 2 LSP associated with a
> specific MFI carries flooding information belonging to the specific MFI.
> And Level 1/Level 2 PSNP and Level 1/Level 2 CSNP containing information
> about LSPs that propagated in the specific MFI are generated to synchronize
> the MFI-specific LSDB.
>
> - by using the same LSDB to store the MFI specific information only a
> limited separation can be achieved. Multi-instance gives you better
> separation.
>
> - you carved the MFI specific LSP space from the common LSP space. This
> may result in the non routing apps consuming the space that would
> otherwise be required for regular routing information, compromising the
> basic functionality of the protocol. Multi-instance does not have that
> problem.
>
> my 2c,
> Peter
>
>
> >
> > thanks,
> > Peter
> >
> >
> >
> >
> >>
> >> thanks,
> >> Peter
> >>
> >>>
> >>> thanks,
> >>> Peter
> >>>
> >>>
> >>>>
> >>>> Best,
> >>>> Yali
> >>>>
> >>>> -----Original Message-----
> >>>> From: Peter Psenak [mailto:ppsenak@cisco.com]
> >>>> Sent: Tuesday, March 2, 2021 5:12 PM
> >>>> To: wangyali <wangyali11@huawei.com>; Gyan Mishra
> >>>> <hayabusagsm@gmail.com>; Robert Raszuk <robert@raszuk.net>
> >>>> Cc: Huzhibo <huzhibo@huawei.com>; Aijun Wang
> >>>> <wangaj3@chinatelecom.cn>; Tony Li <tony.li@tony.li>; lsr
> >>>> <lsr@ietf.org>; Tianran Zhou <zhoutianran@huawei.com>
> >>>> Subject: Re: [Lsr] New Version Notification for
> >>>> draft-wang-lsr-isis-mfi-00.txt
> >>>>
> >>>> Yali,
> >>>>
> >>>> On 01/03/2021 10:49, wangyali wrote:
> >>>>> 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.
> >>>>
> >>>> well, the draft says:
> >>>>
> >>>> "information about LSPs that transmitted in a
> >>>>       specific MFI are generated to synchronize the LSDB
> corresponding to
> >>>>       the specific MFI."
> >>>>
> >>>> If the above has changed, then please update the draft accordingly.
> >>>>
> >>>> thanks,
> >>>> Peter
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>> Best,
> >>>>> Yali
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: Peter Psenak [mailto:ppsenak@cisco.com]
> >>>>> Sent: Sunday, February 28, 2021 8:23 PM
> >>>>> To: Gyan Mishra <hayabusagsm@gmail.com>; Robert Raszuk
> >>>>> <robert@raszuk.net>
> >>>>> Cc: Huzhibo <huzhibo@huawei.com>; Aijun Wang
> >>>>> <wangaj3@chinatelecom.cn>; Tony Li <tony.li@tony.li>; lsr
> >>>>> <lsr@ietf.org>; Tianran Zhou <zhoutianran@huawei.com>; wangyali
> >>>>> <wangyali11@huawei.com>
> >>>>> 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 <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
> <https://www.google.com/maps/search/lution+we+recommend?entry=gmail&source=g>
> 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