Hi Peter, Please see inline [Yali2]. Thanks a lot.
-----Original Message----- From: Peter Psenak [mailto:[email protected]] Sent: Thursday, March 4, 2021 6:50 PM To: wangyali <[email protected]>; 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]> 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:[email protected]] > Sent: Wednesday, March 3, 2021 5:37 PM > To: wangyali <[email protected]>; 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]> > 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. thanks, Peter > > thanks, > Peter > > >> >> Best, >> Yali >> >> -----Original Message----- >> From: Peter Psenak [mailto:[email protected]] >> Sent: Tuesday, March 2, 2021 5:12 PM >> To: wangyali <[email protected]>; 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]> >> 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:[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
