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

Gyan,

On 05/03/2021 16:46, Gyan Mishra wrote:
> 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.

MT does not provide LSDB separation, only MI does.

thanks,
Peter

> 
> 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 
> <mailto: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
>     <mailto:ppsenak@cisco.com>]
>      > Sent: Thursday, March 4, 2021 11:20 PM
>      > To: wangyali <wangyali11@huawei.com
>     <mailto:wangyali11@huawei.com>>; Gyan Mishra <hayabusagsm@gmail.com
>     <mailto:hayabusagsm@gmail.com>>; Robert Raszuk <robert@raszuk.net
>     <mailto:robert@raszuk.net>>
>      > Cc: Huzhibo <huzhibo@huawei.com <mailto:huzhibo@huawei.com>>;
>     Aijun Wang <wangaj3@chinatelecom.cn
>     <mailto:wangaj3@chinatelecom.cn>>; Tony Li <tony.li@tony.li
>     <mailto:tony.li@tony.li>>; lsr <lsr@ietf.org <mailto:lsr@ietf.org>>;
>     Tianran Zhou <zhoutianran@huawei.com <mailto: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
>     <mailto:ppsenak@cisco.com>]
>      >> Sent: Thursday, March 4, 2021 6:50 PM
>      >> To: wangyali <wangyali11@huawei.com
>     <mailto:wangyali11@huawei.com>>; Gyan Mishra
>      >> <hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com>>; Robert
>     Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>
>      >> Cc: Huzhibo <huzhibo@huawei.com <mailto:huzhibo@huawei.com>>;
>     Aijun Wang
>      >> <wangaj3@chinatelecom.cn <mailto:wangaj3@chinatelecom.cn>>; Tony
>     Li <tony.li@tony.li <mailto:tony.li@tony.li>>; lsr
>      >> <lsr@ietf.org <mailto:lsr@ietf.org>>; Tianran Zhou
>     <zhoutianran@huawei.com <mailto: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
>     <mailto:ppsenak@cisco.com>]
>      >>> Sent: Wednesday, March 3, 2021 5:37 PM
>      >>> To: wangyali <wangyali11@huawei.com
>     <mailto:wangyali11@huawei.com>>; Gyan Mishra
>      >>> <hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com>>; Robert
>     Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>
>      >>> Cc: Huzhibo <huzhibo@huawei.com <mailto:huzhibo@huawei.com>>;
>     Aijun Wang
>      >>> <wangaj3@chinatelecom.cn <mailto:wangaj3@chinatelecom.cn>>;
>     Tony Li <tony.li@tony.li <mailto:tony.li@tony.li>>; lsr
>      >>> <lsr@ietf.org <mailto:lsr@ietf.org>>; Tianran Zhou
>     <zhoutianran@huawei.com <mailto: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
>     <mailto:ppsenak@cisco.com>]
>      >>>> Sent: Tuesday, March 2, 2021 5:12 PM
>      >>>> To: wangyali <wangyali11@huawei.com
>     <mailto:wangyali11@huawei.com>>; Gyan Mishra
>      >>>> <hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com>>; Robert
>     Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>
>      >>>> Cc: Huzhibo <huzhibo@huawei.com <mailto:huzhibo@huawei.com>>;
>     Aijun Wang
>      >>>> <wangaj3@chinatelecom.cn <mailto:wangaj3@chinatelecom.cn>>;
>     Tony Li <tony.li@tony.li <mailto:tony.li@tony.li>>; lsr
>      >>>> <lsr@ietf.org <mailto:lsr@ietf.org>>; Tianran Zhou
>     <zhoutianran@huawei.com <mailto: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
>     <mailto:ppsenak@cisco.com>]
>      >>>>> Sent: Sunday, February 28, 2021 8:23 PM
>      >>>>> To: Gyan Mishra <hayabusagsm@gmail.com
>     <mailto:hayabusagsm@gmail.com>>; Robert Raszuk
>      >>>>> <robert@raszuk.net <mailto:robert@raszuk.net>>
>      >>>>> Cc: Huzhibo <huzhibo@huawei.com <mailto:huzhibo@huawei.com>>;
>     Aijun Wang
>      >>>>> <wangaj3@chinatelecom.cn <mailto:wangaj3@chinatelecom.cn>>;
>     Tony Li <tony.li@tony.li <mailto:tony.li@tony.li>>; lsr
>      >>>>> <lsr@ietf.org <mailto:lsr@ietf.org>>; Tianran Zhou
>     <zhoutianran@huawei.com <mailto:zhoutianran@huawei.com>>; wangyali
>      >>>>> <wangyali11@huawei.com <mailto: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>
>      >>>>>> <mailto: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>
>      >>>>>>          <mailto: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>
>      >>>>>>>              <mailto: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> <mailto:Lsr@ietf.org
>     <mailto:Lsr@ietf.org>>
>      >>>>>>> https://www.ietf.org/mailman/listinfo/lsr
>      >>>>>>
>      >>>>>>          _______________________________________________
>      >>>>>>          Lsr mailing list
>      >>>>>> Lsr@ietf.org <mailto:Lsr@ietf.org> <mailto: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-1347
> 13101 Columbia Pike
> /Silver Spring, MD
> 
> 