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 <ppse...@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:ppse...@cisco.com] > > Sent: Thursday, March 4, 2021 11:20 PM > > To: wangyali <wangyal...@huawei.com>; Gyan Mishra <hayabusa...@gmail.com>; > Robert Raszuk <rob...@raszuk.net> > > Cc: Huzhibo <huzh...@huawei.com>; Aijun Wang <wang...@chinatelecom.cn>; > Tony Li <tony...@tony.li>; lsr <lsr@ietf.org>; Tianran Zhou < > zhoutian...@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:ppse...@cisco.com] > >> Sent: Thursday, March 4, 2021 6:50 PM > >> To: wangyali <wangyal...@huawei.com>; Gyan Mishra > >> <hayabusa...@gmail.com>; Robert Raszuk <rob...@raszuk.net> > >> Cc: Huzhibo <huzh...@huawei.com>; Aijun Wang > >> <wang...@chinatelecom.cn>; Tony Li <tony...@tony.li>; lsr > >> <lsr@ietf.org>; Tianran Zhou <zhoutian...@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:ppse...@cisco.com] > >>> Sent: Wednesday, March 3, 2021 5:37 PM > >>> To: wangyali <wangyal...@huawei.com>; Gyan Mishra > >>> <hayabusa...@gmail.com>; Robert Raszuk <rob...@raszuk.net> > >>> Cc: Huzhibo <huzh...@huawei.com>; Aijun Wang > >>> <wang...@chinatelecom.cn>; Tony Li <tony...@tony.li>; lsr > >>> <lsr@ietf.org>; Tianran Zhou <zhoutian...@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:ppse...@cisco.com] > >>>> Sent: Tuesday, March 2, 2021 5:12 PM > >>>> To: wangyali <wangyal...@huawei.com>; Gyan Mishra > >>>> <hayabusa...@gmail.com>; Robert Raszuk <rob...@raszuk.net> > >>>> Cc: Huzhibo <huzh...@huawei.com>; Aijun Wang > >>>> <wang...@chinatelecom.cn>; Tony Li <tony...@tony.li>; lsr > >>>> <lsr@ietf.org>; Tianran Zhou <zhoutian...@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:ppse...@cisco.com] > >>>>> Sent: Sunday, February 28, 2021 8:23 PM > >>>>> To: Gyan Mishra <hayabusa...@gmail.com>; Robert Raszuk > >>>>> <rob...@raszuk.net> > >>>>> Cc: Huzhibo <huzh...@huawei.com>; Aijun Wang > >>>>> <wang...@chinatelecom.cn>; Tony Li <tony...@tony.li>; lsr > >>>>> <lsr@ietf.org>; Tianran Zhou <zhoutian...@huawei.com>; wangyali > >>>>> <wangyal...@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 <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 > <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
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
