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.
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
