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

From: wangyali <[email-masked]>
Date: Mon, 1 Mar 2021 09:42:52 +0000

Hi Robert,

Thanks for your comments. But one process N threads or N processes, which is indeed a implementation not a protocol. Hence, we do not discuss this problem in this draft.

I fully agree with Gyan. MFIs share a common adjacencies, and a single LSDB. And each MFI can have its own flooding sub topology and its customized flooding parameters.

Best regards,
Yali

From: Gyan Mishra [mailto:[email-masked]]
Sent: Saturday, February 27, 2021 12:19 AM
To: Robert Raszuk <[email-masked]>
Cc: Aijun Wang <[email-masked]>; Huzhibo <[email-masked]>; Tianran Zhou <[email-masked]>; Tony Li <[email-masked]>; lsr <[email-masked]>; wangyali <[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

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.

 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.

Gyan

On Fri, Feb 26, 2021 at 7:10 AM Robert Raszuk <[email-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr
--

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: wangyali <[email-masked]>
Date: Mon, 1 Mar 2021 09:49:40 +0000

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.

Best,
Yali

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: Sunday, February 28, 2021 8:23 PM
To: Gyan Mishra <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: Huzhibo <[email-masked]>; Aijun Wang <[email-masked]>; Tony Li <[email-masked]>; lsr <[email-masked]>; Tianran Zhou <[email-masked]>; wangyali <[email-masked]>
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

>     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.
> 
>         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
> 
>>         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
>>
>>             IS-IS to allow*one standard instance*  of
>>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> <http://www.verizon.com/>
> 
> *Gyan Mishra*
> 
> /Network Solutions A//rchitect /
> 
> /M 301 502-1347
> 13101 Columbia Pike
> /Silver Spring, MD
> 
>

---

From: Peter Psenak <[email-masked]>
Date: Tue, 2 Mar 2021 10:12:10 +0100

Yali,

> 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

---

From: wangyali <[email-masked]>
Date: Wed, 3 Mar 2021 05:02:45 +0000

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

Best,
Yali

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: Tuesday, March 2, 2021 5:12 PM
To: wangyali <[email-masked]>; Gyan Mishra <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: Huzhibo <[email-masked]>; Aijun Wang <[email-masked]>; Tony Li <[email-masked]>; lsr <[email-masked]>; Tianran Zhou <[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Yali,

well, the draft says:

thanks,
Peter

> Cc: Huzhibo <[email-masked]>; Aijun Wang 
> <[email-masked]>; Tony Li <[email-masked]>; lsr 
> <[email-masked]>; Tianran Zhou <[email-masked]>; wangyali 
> <[email-masked]>

---

From: Peter Psenak <[email-masked]>
Date: Wed, 3 Mar 2021 10:37:12 +0100

Yali,

> 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-specif…

please specify sub-LSDB.

thanks,
Peter

---

From: wangyali <[email-masked]>
Date: Thu, 4 Mar 2021 10:42:13 +0000

Hi Peter,

Please review follows tagged by [Yali].

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: Wednesday, March 3, 2021 5:37 PM
To: wangyali <[email-masked]>; Gyan Mishra <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: Huzhibo <[email-masked]>; Aijun Wang <[email-masked]>; Tony Li <[email-masked]>; lsr <[email-masked]>; Tianran Zhou <[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Yali,

On 03/03/2021 06:02, wangyali wrote:
> 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."

thanks,
Peter

> To: wangyali <[email-masked]>; Gyan Mishra 
> <[email-masked]>; Robert Raszuk <[email-masked]>
> <[email-masked]>; Tianran Zhou <[email-masked]>

---

From: Peter Psenak <[email-masked]>
Date: Thu, 4 Mar 2021 11:49:30 +0100

Hi Yali,

> [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 L…

I wonder what is the difference between "MFI-specific LSDB subdivided 
from a single LSDB" versus the "MFI-specific LSDB".

thanks,
Peter

---

From: wangyali <[email-masked]>
Date: Thu, 4 Mar 2021 13:45:11 +0000

Hi Peter,

Please see inline [Yali2]. Thanks a lot.

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: Thursday, March 4, 2021 6:50 PM
To: wangyali <[email-masked]>; Gyan Mishra <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: Huzhibo <[email-masked]>; Aijun Wang <[email-masked]>; Tony Li <[email-masked]>; lsr <[email-masked]>; Tianran Zhou <[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Hi Yali,

> [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 L…

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

>>>> 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 
>>>> number of flood reduction drafts and this seems to be another 
>>>> method of achieving the same.
>>>

---

From: Aijun Wang <[email-masked]>
Date: Thu, 4 Mar 2021 22:02:04 +0800

Hi, Yali and Peter:

How about using “MFI-specified context” in stead of “MFI-specified LSDB”?
“MFI-specified context” is subdivided from a single common LSDB within the zero IS-IS instance.

Aijun Wang
China Telecom

> On Mar 4, 2021, at 21:45, wangyali <[email-masked]> wrote:
> 
> Hi Peter,
>

---

From: Peter Psenak <[email-masked]>
Date: Thu, 4 Mar 2021 16:20:12 +0100

Hi Yali,

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

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.

thanks,
Peter

---

From: wangyali <[email-masked]>
Date: Fri, 5 Mar 2021 14:31:37 +0000

Hi Peter,

Thanks for your question. Please see inline [yali3].

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: Thursday, March 4, 2021 11:20 PM
To: wangyali <[email-masked]>; Gyan Mishra <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: Huzhibo <[email-masked]>; Aijun Wang <[email-masked]>; Tony Li <[email-masked]>; lsr <[email-masked]>; Tianran Zhou <[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Hi Yali,

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

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.

thanks,
Peter

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

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 5 Mar 2021 10:13:46 -0500

Hi Yali

As you have a common LSDB  base MT O and only the flooding mechanism is
broken up into discrete instances with the new MFI TLV, how is the physical
 sub topology mapped to the MFI instances if it’s a common LSDB.  The
flooding is done with separate MFI but that is just the flooding not the
physical topology.  So let’s say you have TEAS NS  network slices you are
provisioning for VPN+ Enhanced VPN and provisioning the underlay
underpinning to VPN+ overlay for a network slice.  How does the underlay
VTN which is a sub topology slice become realized as a slice of the common
LSDB with the MFI instances.

You may have seen this draft now under WG Adoption call using MT for VTN
provisioning.  I agree this would work for VTN provisioning but not sure
how MFI would work as the LSDB is common so the resources are really not
segregated between the network slices.

https://tools.ietf.org/html/draft-xie-lsr-isis-sr-vtn-mt-03

Kind Regards

Gyan

On Fri, Mar 5, 2021 at 9:31 AM wangyali <[email-masked]> wrote:

> Hi Pete
> To: wangyali <[email-masked]>; Gya Mishra <[email-masked]>;
> Robert Raszuk <[email-masked]>
> Cc: Huzhibo <[email-masked]>; Aijun Wang <[email-masked]>;
> Tony Li <[email-masked]>; lsr <[email-masked]>; Tianran Zhou <
> [email-masked]>
> >>> 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."
> >
> > [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.
>
>
> 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.
>
> thanks,
> Peter
>
>
>
>
> >
> > thanks,
> > Peter
> >
> >>
> >> thanks,
> >> Peter
> >>
> >>
> >>>
> >>> Best,
> >>> Yali
> >>>
> >>>> Many thanks for your feedback. First of all, I'm sorry for the
> confusion I had caused you from my previous misunderstanding.
> >>>>
> >>>> 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.
> >>>>
> >>>>>
> >>>>>         On Fri, Feb 26, 2021 at 12:44 PM Aijun Wang <
> [email-masked]
> >>>>>         <mailto:[email-masked]>> wrote:
> >>>>>
> >>>>>             Hi, Robert:
> >>>>>
> >>>>>>             On Feb 26, 2021, at 19:00, Robert Raszuk <
> [email-masked]
> >>>>>>             <mailto:[email-masked]>> 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.
> >>>>>>
> >>>>>>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Peter Psenak <[email-masked]>
Date: Fri, 5 Mar 2021 16:28:28 +0100

Hi Yali,

> 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 LS…

- 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

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 5 Mar 2021 10:46:09 -0500

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 <[email-masked]> wrote:

> >>>>>>>                  [Yali]: MFI is a different solution we recommend
> <https://www.google.com/maps/search/lution+we+recommend?entry=gmail&source=g>
> to solve

*Gyan Mishra*

---

From: Peter Psenak <[email-masked]>
Date: Fri, 5 Mar 2021 16:56:50 +0100

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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi Yali,
> 
>      > From: Peter Psenak [mailto:[email-masked]
>     <mailto:[email-masked]>]
>      > To: wangyali <[email-masked]
>     <mailto:[email-masked]>>; Gyan Mishra <[email-masked]
>     <mailto:[email-masked]>>; Robert Raszuk <[email-masked]
>     <mailto:[email-masked]>>
>      > Cc: Huzhibo <[email-masked] <mailto:[email-masked]>>;
>     Aijun Wang <[email-masked]
>     <mailto:[email-masked]>>; Tony Li <[email-masked]
>     <mailto:[email-masked]>>; lsr <[email-masked] <mailto:[email-masked]>>;
>     Tianran Zhou <[email-masked] <mailto:[email-masked]>>
>      >> From: Peter Psenak [mailto:[email-masked]
>     <mailto:[email-masked]>]
>      >> To: wangyali <[email-masked]
>     <mailto:[email-masked]>>; Gyan Mishra
>      >> <[email-masked] <mailto:[email-masked]>>; Robert
>     Raszuk <[email-masked] <mailto:[email-masked]>>
>      >> Cc: Huzhibo <[email-masked] <mailto:[email-masked]>>;
>     Aijun Wang
>      >> <[email-masked] <mailto:[email-masked]>>; Tony
>     Li <[email-masked] <mailto:[email-masked]>>; lsr
>      >> <[email-masked] <mailto:[email-masked]>>; Tianran Zhou
>     <[email-masked] <mailto:[email-masked]>>
>      >>> From: Peter Psenak [mailto:[email-masked]
>     <mailto:[email-masked]>]
>      >>> To: wangyali <[email-masked]
>     <mailto:[email-masked]>>; Gyan Mishra
>      >>> <[email-masked] <mailto:[email-masked]>>; Robert
>     Raszuk <[email-masked] <mailto:[email-masked]>>
>      >>> Cc: Huzhibo <[email-masked] <mailto:[email-masked]>>;
>     Aijun Wang
>      >>> <[email-masked] <mailto:[email-masked]>>;
>     Tony Li <[email-masked] <mailto:[email-masked]>>; lsr
>      >>> <[email-masked] <mailto:[email-masked]>>; Tianran Zhou
>     <[email-masked] <mailto:[email-masked]>>
>      >>>> 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.
> 
>      >>>> From: Peter Psenak [mailto:[email-masked]
>     <mailto:[email-masked]>]
>      >>>> To: wangyali <[email-masked]
>     <mailto:[email-masked]>>; Gyan Mishra
>      >>>> <[email-masked] <mailto:[email-masked]>>; Robert
>     Raszuk <[email-masked] <mailto:[email-masked]>>
>      >>>> Cc: Huzhibo <[email-masked] <mailto:[email-masked]>>;
>     Aijun Wang
>      >>>> <[email-masked] <mailto:[email-masked]>>;
>     Tony Li <[email-masked] <mailto:[email-masked]>>; lsr
>      >>>> <[email-masked] <mailto:[email-masked]>>; Tianran Zhou
>     <[email-masked] <mailto:[email-masked]>>
>      >>>>> Many thanks for your feedback. First of all, I'm sorry for
>     the confusion I had caused you from my previous misunderstanding.
>      >>>>>
>      >>>>> From: Peter Psenak [mailto:[email-masked]
>     <mailto:[email-masked]>]
>      >>>>> To: Gyan Mishra <[email-masked]
>     <mailto:[email-masked]>>; Robert Raszuk
>      >>>>> <[email-masked] <mailto:[email-masked]>>
>      >>>>> Cc: Huzhibo <[email-masked] <mailto:[email-masked]>>;
>     Aijun Wang
>      >>>>> <[email-masked] <mailto:[email-masked]>>;
>     Tony Li <[email-masked] <mailto:[email-masked]>>; lsr
>      >>>>> <[email-masked] <mailto:[email-masked]>>; Tianran Zhou
>     <[email-masked] <mailto:[email-masked]>>; wangyali
>      >>>>> <[email-masked] <mailto:[email-masked]>>
>      >>>>> 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.
>      >>>>>
>      >>>>>>
>      >>>>>> On Fri, Feb 26, 2021 at 7:10 AM Robert Raszuk
>     <[email-masked] <mailto:[email-masked]>
>      >>>>>> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >>>>>>
>      >>>>>>          Aijun,
>      >>>>>>
>      >>>>>>          On Fri, Feb 26, 2021 at 12:44 PM Aijun Wang
>     <[email-masked] <mailto:[email-masked]>
>      >>>>>>          <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >>>>>>
>      >>>>>>              Hi, Robert:
>      >>>>>>
>      >>>>>>>              On Feb 26, 2021, at 19:00, Robert Raszuk
>     <[email-masked] <mailto:[email-masked]>
>      >>>>>>>              <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >>>>>>>
>      >>>>>>>              Hi Yali,
>      >>>>>>>
>      >>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 5 Mar 2021 11:10:35 -0500

Hi Peter

> MT does not provide LSDB separation, only MI does.

   I thought that each MT topology was a separate RIB meaning separate
LSDB.  The RFC is confusing.😄

https://tools.ietf.org/html/rfc5120

6 <https://tools.ietf.org/html/rfc5120#section-6>.  MT SPF Computation

   Each MT MUST run its own instance of the decision process.  The
   pseudo-node LSPs are used by all topologies during computation.  Each
   non-default topology MAY have its attached bit and overload bit set
   in the MT TLV.  A reverse-connectivity check within SPF MUST follow
   the according MT to assure the bi-directional reachability within the
   same MT.

   The results of each computation SHOULD be stored in a separate
   Routing Information Base (RIB), in normal cases, otherwise
   overlapping addresses in different topologies could lead to
   undesirable routing behavior, such as forwarding loops.  The
   forwarding logic and configuration need to ensure the same MT is
   traversed from the source to the destination for packets.  The
   nexthops derived from the MT SPF MUST belong to the adjacencies

conforming to the same MT for correct forwarding.  It is recommended
   for the administrators to ensure consistent configuration of all
   routers in the domain to prevent undesirable forwarding behavior.

   No attempt is made in this document to allow one topology to
   calculate routes using the routing information from another topology
   inside SPF.  Even though it is possible to redistribute and leak
   routes from another IS-IS topology or from external sources, the
   exact mechanism is beyond the scope of this document.

> >     Tianran Zhou <[email-masked] <mailto:[email-masked]
> >>
> >      >>>>>>              similar task, but it has
> <https://www.google.com/maps/search/ar+task,+but+it+has?entry=gmail&source=g>
> some deployment overhead.
> >     <
> https://www.google.com/maps/search/lution+we+recommend?entry=gmail&source=g
> >
> >     to solve

*Gyan Mishra*

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 9 Mar 2021 03:14:39 +0000

Sooo, I have been reluctant to comment on the shortcomings of this draft because I feel there was no need for the draft to be written in the first place.
I had hoped that the authors would think about this a bit more and realize the flaws in the proposed solution – or – as Acee suggested during the WG meeting – they would attempt an implementation and discover what had not yet been realized. This then would end the time the WG is spending on this – which IMO is the right outcome.

As that has not yet happened, perhaps some comments can speed this process along.

The goal of the draft is to support per-MFI LSDBs in the standard instance of IS-IS.  Since it is not possible for a legacy node to differentiate LSP.xx-yy w MFI #1 from the same LSP with MFI #2 (or with no MFI at all), it is clear that an MFI LSP cannot be flooded to a legacy node EVER!!
In order to prevent this, a node has to know whether a given neighbor supports MFI or not. But since the draft defines no signaling in hellos, it cannot tell whether the neighbor supports MFI (not to mention which MFIs – which is important for avoiding flooding MFI LSPs to nodes that aren’t interested in that MFI) you are forced to rely on receiving LSPs (or SNPs) – which brings us to the chicken/egg problem. Neither I nor my neighbor can send an MFI LSP out of fear that the receiver does not support MFI. So MFI flooding is blocked.

This problem can be solved by including the MFI TLV in hellos (analogous to what MI(RFRC 8202) does). But this is not the end of your issues. If you have a LAN, you could have a mix of legacy routers and MFI routers – and again you cannot allow legacy routers to receive MFI LSPs as they will look just like legacy LSPs to the legacy nodes. This means you will have to find a way to avoid ever having MFI PDUs received by legacy nodes (RFC 8202 uses different MAC multicast addresses).

Sooo, once you have addressed both of these issues you will have repeated what RFC 8202 already does. No new benefits here.

This then leaves you with one possible use case: support a single LSDB for all MFIs in the standard IS-IS instance. But, this use case is already provided for (though strongly discouraged) by https://tools.ietf.org/html/rfc6823#section-5 .

I do understand that some folks want to advertise VTN info in IGPs and that the WG will be discussing this. I am not in favor of doing this – but I recognize it is a legitimate topic for discussion. And if the WG were to approve such functionality we have MI available to be used to provide separation.
(Note that MI has been implemented and successfully deployed by multiple vendors.)

draft-wang-lsr-isis-mfi is an unnecessary proposal, seriously flawed, and not achieving any of the goals stated in its introduction.
I ask that the authors abandon this proposal.

   Les

From: Lsr <[email-masked]> On Behalf Of Gyan Mishra
Sent: Friday, March 05, 2021 8:11 AM
To: Peter Psenak (ppsenak) <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; Huzhibo <[email-masked]>; Aijun Wang <[email-masked]>; Tony Li <[email-masked]>; lsr <[email-masked]>; Tianran Zhou <[email-masked]>; wangyali <[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Hi Peter

On Fri, Mar 5, 2021 at 10:56 AM Peter Psenak <[email-masked]<mailto:[email-masked]>> wrote:
Gyan,

thanks,
Peter

   I thought that each MT topology was a separate RIB meaning separate LSDB.  The RFC is confusing.😄

6<https://tools.ietf.org/html/rfc5120#section-6>.  MT SPF Computation

   same MT.

> On Fri, Mar 5, 2021 at 10:28 AM Peter Psenak <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     Hi Yali,
>
>      > From: Peter Psenak [mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>]
>      > To: wangyali <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>
>      > Cc: Huzhibo <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>;
>     Aijun Wang <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>; Tony Li <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>; lsr <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>;
>     Tianran Zhou <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>      >> From: Peter Psenak [mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>]
>      >> To: wangyali <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>; Gyan Mishra
>      >> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>; Robert
>     Raszuk <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>      >> Cc: Huzhibo <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>;
>     Aijun Wang
>      >> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>; Tony
>     Li <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>; lsr
>      >> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>; Tianran Zhou
>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>      >>> From: Peter Psenak [mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>]
>      >>> To: wangyali <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>; Gyan Mishra
>      >>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>; Robert
>     Raszuk <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>      >>> Cc: Huzhibo <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>;
>     Aijun Wang
>      >>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>;
>     Tony Li <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>; lsr
>      >>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>; Tianran Zhou
>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>      >>>> From: Peter Psenak [mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>]
>      >>>> To: wangyali <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>; Gyan Mishra
>      >>>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>; Robert
>     Raszuk <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>      >>>> Cc: Huzhibo <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>;
>     Aijun Wang
>      >>>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>;
>     Tony Li <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>; lsr
>      >>>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>; Tianran Zhou
>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>      >>>>> From: Peter Psenak [mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>]
>      >>>>> To: Gyan Mishra <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>; Robert Raszuk
>      >>>>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>      >>>>> Cc: Huzhibo <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>;
>     Aijun Wang
>      >>>>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>;
>     Tony Li <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>; lsr
>      >>>>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>; Tianran Zhou
>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>; wangyali
>      >>>>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>      >>>>>> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>> wrote:
>      >>>>>>
>      >>>>>>          Aijun,
>      >>>>>>
>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>      >>>>>>          <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>> wrote:
>      >>>>>>
>      >>>>>>              Hi, Robert:
>      >>>>>>
>      >>>>>>              similar task, but it has<https://www.google.com/maps/search/ar+task,+but+it+has?entry=gmail&source=g> some deployment overhead.
>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>      >>>>>>>              <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>> wrote:
>      >>>>>>>
>      >>>>>>>              Hi Yali,
>      >>>>>>>
>      >>>>>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>
>      >>>>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>
--

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 9 Mar 2021 11:47:49 +0100

Gyan, you are confusing RIB with LSDB. It is absolutely feasible and normal
to generate multiple RIBs/FIBs from a single LSDB and that has been done
for about forever

problem with lots of those proposals and assertions here is that powerpoint
and rfc text always compiles no matter what you put into it, silicon and
real implementations force to face the world not as you imagine it but as
you can actually make it work in practical terms. Akin to talking about
pottery (*there is a value to it in itself) and making a real pot with
clay. Making a real pot first gives you a much better chance to actually
talk about pottery meaningfully albeit it does not teach you aesthetics of
pottery or a complete new way to make pots possibly.

2c

-- tony

On Fri, Mar 5, 2021 at 5:11 PM Gyan Mishra <[email-masked]> wrote:

>> >     <mailto:[email-masked]>>; lsr <[email-masked] <mailto:[email-masked]
>> >>;
>> Tony
>> >      >>>>> Cc: Huzhibo <[email-masked] <mailto:[email-masked]
>> >>;
>> >     Aijun Wang
> [email-masked]

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 9 Mar 2021 11:54:42 +0100

and replying to myself, as was mentioned yesterday in LSR already, the key
questions is HOW MANY control plane slices and then FIB slices do you
really need in the technology to be built.  And how much of that needs to
be really in the core? Both will have large implication on solutions, you
cannot run 2000 IGP processes in a box but you could run 2K topologies on
IGP (cough, cough). IGP control plane will be limited by how many
computations you can crunch (unless you take that off box, bit risky but
thnkable) and then can you OAM & operate such a solution, especially if
topologies disjoin. FEC sharing tricks are proposed here and are worth
thinking through if they allow to squeeze #context in control plane into
less context in FIB but compression is a devil (think SR stack compression
today) since it often leads operationally to surprising effects. In
forwarding path all those things are trickier/more costly, on the edge we
run thousands of VPNs/EVIs in MP-BGP so it's thinkable, in the core, ehem,
well, you start to reinvent MPLS since about only thing that scales on
every core box is switching (if you want precise per box
accounting/control). You can 'fudge' things by the ancient loose source
routing, ehem, sorry, it's called SR now ;-) but this has a formidable set
of operational challenges since the ole Token Ring doing it.

exec summary: figure out how many "slices" you need in control & data plane
& how tight they need to be in terms of SLAs and then swallow the
trade-offs. that may not be a single data point and multiple solutions may
be necessary.

--- tony

On Tue, Mar 9, 2021 at 11:47 AM Tony Przygienda <[email-masked]> wrote:

> Gyan, you are confusing RIB with LSDB. It is absolutely feasible and
> normal to generate multiple RIBs/FIBs from a single LSDB and that has been
> done for about forever
>
> problem with lots of those proposals and assertions here is that
> powerpoint and rfc text always compiles no matter what you put into it,
> silicon and real implementations force to face the world not as you imagine
> it but as you can actually make it work in practical terms. Akin to talking
> about pottery (*there is a value to it in itself) and making a real pot
> with clay. Making a real pot first gives you a much better chance to
> actually talk about pottery meaningfully albeit it does not teach you
> aesthetics of pottery or a complete new way to make pots possibly.
>
> 2c
>
> -- tony
>
>>> >      >>>>> And I want to clarify that a single and common LSDB is
>>> shared
>>> >     by all MFIs.
>>> >      >>>>
>>> >      >>>> well, the draft says:
>>> >      >>>>
>>> >      >>>>>> multiple sub topology instances within a common LSDB.
>>> There
>>> >     are a
>>> >      >>>>>>>              Well the way I understand this proposal MFI
>>> is
>>> >     much weaker

---

From: wangyali <[email-masked]>
Date: Tue, 9 Mar 2021 14:21:54 +0000

Hi Les,
Glad to receive your email. Please see inline [Yali].

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Tuesday, March 9, 2021 11:15 AM
To: Gyan Mishra <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; Huzhibo <[email-masked]>; Aijun Wang <[email-masked]>; Tony Li <[email-masked]>; lsr <[email-masked]>; Tianran Zhou <[email-masked]>; wangyali <[email-masked]>
Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

The goal of the draft is to support per-MFI LSDBs in the standard instance of IS-IS.  Since it is not possible for a legacy node to differentiate LSP.xx-yy w MFI #1 from the same LSP with MFI #2 (or with no MFI at all), it is clear that an MFI LSP cannot be flooded to a legacy node EVER!!
[Yali]: In our proposal, we considered the scenario where some routers that do not support MFI, and recommended that all MFIs share one LSP Number space in the standard instance of IS-IS protocol. And if routers that do not support MFI but receive the LSPs and SNPs carrying MFI-ID TLV, then routers SHOULD ignore the MFI-ID TLV and continues processing other TLVs.

This problem can be solved by including the MFI TLV in hellos (analogous to what MI(RFRC 8202) does). But this is not the end of your issues. If you have a LAN, you could have a mix of legacy routers and MFI routers – and again you cannot allow legacy routers to receive MFI LSPs as they will look just like legacy LSPs to the legacy nodes. This means you will have to find a way to avoid ever having MFI PDUs received by legacy nodes (RFC 8202 uses different MAC multicast addresses).
[Yali]: Correctly. You’re right. There indeed be a signaling in Hellos. MFI-ID TLV can be included in IS-IS Hellos. Because we want to focus on extensions to Update process, we originally plan to implement this part in the second version.
We also have describe the Interoperability Considerations in the condition where some routers do not support MFI in the draft.

This then leaves you with one possible use case: support a single LSDB for all MFIs in the standard IS-IS instance. But, this use case is already provided for (though strongly discouraged) by https://tools.ietf.org/html/rfc6823#section-5 .
[Yali]: This proposal is used to solve the issue that how we can isolate the impacts of non-routing information flooding under the condition that there is only the standard instance of IS-IS protocol implemented in the network and no one router support Multi-instance. Sec.5 also mentioned the issue as follows.

‘’ Flooding of information not directly related
   to the use of the IS-IS protocol in support of routing degrades the
   operation of the protocol.  Degradation occurs because the frequency
   of LSP updates is increased and because the processing of non-routing
   information in each router consumes resources whose primary
   responsibility is to efficiently respond to reachability changes in
   the network. ‘’

So in this proposed draft, we give an optional solution by separate multiple Update processes for different kinds of information, such as following example shown in the Table (I presented in the yesterday meeting). Each Level 1/Level 2 LSPs associated with a specific MFI carries flooding information, such as routing topology, belonging to the specific MFI #0. And Level 1/Level 2 PSNPs and Level 1/Level 2 CSNP containing information about LSPs that transmitted in a specific MFI#0 are generated to synchronize the information propagated in the MFI #0 LSDB that is subdivided from a single LSDB within the standard instance of protocol.

As shown in table, different flooding information can be propagated in the unique Update process. In each MFI, priority and update parameters can be customized in dependent on the requirements on the flooding rate of different information. Hence, in our proposal, we also provide an optional solution that can be used in the standard instance to solve the issue also mentioned in section 5 as follows.

‘’ One of the most egregious oversights is a
   failure to appropriately dampen changes in the information to be
   advertised; this can lead to flooding storms. “

I do understand that some folks want to advertise VTN info in IGPs and that the WG will be discussing this. I am not in favor of doing this – but I recognize it is a legitimate topic for discussion. And if the WG were to approve such functionality we have MI available to be used to provide separation.
(Note that MI has been implemented and successfully deployed by multiple vendors.)
[Yali]: Well, then may I post a question (or maybe a Survey) here for folks from operators? The question is that when deploying thousands of slices, are you willing to implement thousands of IS-IS instances to flood thousands of slices topologies and so on? From our side, we can't imagine what a huge project it is.
We’re appreciate if you are willing to give us your answer or opinion.

   Les

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Gyan Mishra
Sent: Friday, March 05, 2021 8:11 AM
To: Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>
Cc: Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Huzhibo <[email-masked]<mailto:[email-masked]>>; Aijun Wang <[email-masked]<mailto:[email-masked]>>; Tony Li <[email-masked]<mailto:[email-masked]>>; lsr <[email-masked]<mailto:[email-masked]>>; Tianran Zhou <[email-masked]<mailto:[email-masked]>>; wangyali <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Hi Peter

thanks,
Peter

   same MT.

--

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 9 Mar 2021 07:37:46 -0500

Thanks Tony for the clarification on MI versus MT.  Peter set me straight
as well on the difference. There are use cases for either one and in this
particular case for VTN underpinning it makes sense as the authors pointed
out that the forwarding plane resources is what needs to be constrained &
isolated which makes MT the proper choice over MI which is overkill as it
provides control & forwarding plane resource isolation with separate LSDB.

Kind Regards

Gyan

-- 

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 9 Mar 2021 07:51:04 -0500

Tony,

In-line

On Tue, Mar 9, 2021 at 5:55 AM Tony Przygienda <[email-masked]> wrote:

> exec summary: figure out how many "slices" you need in control & data
> plane & how tight they need to be in terms of SLAs and then swallow the
>     Gyan> Agreed.  For draft "draft-xie-lsr-isis-sr-vtn-mt-03" VTN
underpinning it makes sense with this draft to pick the design to use MT
separate forwarding plane RIB/FIB topology resource isolation over MI -
Separate control plane & forwarding plane resource isolation.  As you
stated with TEAS NS there could be 1000s of slices and so you really need
to pick your poison carefully as far as degree of resource isolation to
provide optimized overall scalability. This draft is another way to skin
the cat for VTN network slice as far as isolation and taking it another
step further to provide lesser isolation then MT with isolating with MFI
flood instance to provide greater scalability with slices.

>>>> >      >>>>> <[email-masked] <mailto:[email-masked]
>>>> >>;
>>>> >      >>>>> MFI draft proposes to keep the separate LSDB per MFI, so
>>>> the
>>>> >     above analogy is not correct either.
>>>> >      >>>>>
>>>> >      >>>>> thanks,
>>>> >      >>>>> Peter
>>>> >      >>>>>
>>>> >      >>>>>
>>>> >      >>>>>>
>>>> >      >>>>>> Gyan
>>>> >      >>>>>>
>>>> >      >>>>>>          It can be one process N threads or N processes.
>>>> It
>>>> >     can be both and
>>>> >      >>>>>>          operator may choose.
>>>> >      >>>>>>
>>>> >      >>>>>>              Separate into different protocol instances
>>>> can
>>>> >     accomplish the
>>>> >      >>>>>>              similar task, but it has

-- 

*Gyan Mishra*

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 9 Mar 2021 21:23:24 +0100

Gyan, all good except you find that once you have MFI thought through and
really working (implementations do wonder to understanding) with all kind
of frills like Les pointed out you'll build MT by another name again most
likely AFAIS.

If you want to flood everywhere and have some attribution on links you try
to put into computation you end up in flex algo corner pretty much (which
has been done pretty much already in a mild but extremely practical form in
RFC2676 but wasn't the hot cookie of the day then)

The sharing of FECs Tarek proposes seems like a clever optimization and
something bitsy new if that gives you the "slice" definition @ maximum
scale you look for.

-- tony

On Tue, Mar 9, 2021 at 3:47 PM Gyan Mishra <[email-masked]> wrote:

>> and replying to myself, as was mentioned yesterday in LSR already, the
>> key questions is HOW MANY control plane slices and then FIB slices do you
>>>>> >      >>>> Thanks for your comments. Yes. I am improving this
>>>>> sentence.
>>>>> >     Please review the following update.
>>>>> >      >>>>
>>>>> >      >>>>>> MFI seems more like flex algo with multiple sub
>>>>> topologies
>>>>> >     sharing
>>>>> >      >>>>>>        MFI also seems to be a flood reduction mechanism
>>>>> by
>>>>> >     creating
>>>>> >      >>>>>>>              Well the way I understand this proposal
>>>>> MFI is
>>>>> >     much weaker
>>>>> >      >>>>>>>              process level, but here MFIs as defined
>>>>> must
>>>>> >     be handled by the
>>>>> >      >>>>>>>              same ISIS process
>>>>> >      >>>>>>>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 9 Mar 2021 20:24:39 +0000

Yali –

I find your responses not very helpful.
Please see inline.

From: wangyali <[email-masked]>
Sent: Tuesday, March 09, 2021 6:22 AM
To: Les Ginsberg (ginsberg) <[email-masked]>; Gyan Mishra <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; Huzhibo <[email-masked]>; Aijun Wang <[email-masked]>; Tony Li <[email-masked]>; lsr <[email-masked]>; Tianran Zhou <[email-masked]>
Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Hi Les,

To: Gyan Mishra <[email-masked]<mailto:[email-masked]>>; Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>

[Les:] Yes – I understand this. But, as I point out below, this case is already provided for by RFC 6823.  We do discourage doing this – as we discourage your proposed use of the standard instance. But it is already defined – so your draft adds no new functionality for this case.

[Les:] Glad you agree. But the point is – when you have finished your draft – you will simply end up with a variation of RFC 8202. So it won’t be simpler – which was one of your key goals.
This is one of many reasons why I see no need for your draft.

[Les:] If – as you seem to agree – you can only support a single LSDB, there is no need for any protocol extensions and no need for the new MFI TLV. You could advertise GENINFPO for multiple apps in the standard instance.

So your table below is irrelevant.

[Les:] This is not an appropriate response. No one – not you, not me, nor anyone else on this thread – has suggested that thousands of IS-IS instances would be required. For you to suggest this  induces uncalled for hysteria.
It is obvious that if you could send info for multiple applications in the standard instance you can do so in a single non-standard instance – but we would at least have separation from the routing instance. Certainly there is no need for thousands of instances.
Please do not compromise a meaningful dialogue with this misdirection.

If you read https://www.rfc-editor.org/rfc/rfc8202.html#section-4 there is a discussion of related issues. Section 4.3 is particularly relevant to your comment.

   Les

   Les

Hi Peter

thanks,
Peter

   same MT.

--

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 10 Mar 2021 14:13:36 +0800

Hi, Les:

Is there any deployment of Multi-Instance to transfer the application info as recommend in https://tools.ietf.org/html/rfc6823#section-5?

>From my POV, the transfer of the application information needs not even be flooded to all of the device’s participated circuits, as that does for the normal routing LSP.  

Such information needs only be reached to the IGP nodes, then they can follows the shortest path calculated by the base routing instance(reach the flooding reduction effect).

Thus, why not considering using the existing routing instance? It can certainly decrease the overhead of neighbor configurations/maintenances for the new routing instance.

And, https://datatracker.ietf.org/doc/html/draft-bowers-lsr-isis-gen-info-clarifications-00 describes the necessary for the correlation of app info and other info that advertised in different routing instances.

If we put them into the basic routing instance, and make their flooding does not influence the core routing calculation function, won’t be it more attractive?

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> 
Sent: Wednesday, March 10, 2021 4:25 AM
To: wangyali <[email-masked]>; Gyan Mishra <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; Huzhibo <[email-masked]>; Aijun Wang <[email-masked]>; Tony Li <[email-masked]>; lsr <[email-masked]>; Tianran Zhou <[email-masked]>
Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Yali –

Please see inline.

From: wangyali <[email-masked] <mailto:[email-masked]> > 
Sent: Tuesday, March 09, 2021 6:22 AM
To: Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]> >; Gyan Mishra <[email-masked] <mailto:[email-masked]> >; Peter Psenak (ppsenak) <[email-masked] <mailto:[email-masked]> >
Cc: Robert Raszuk <[email-masked] <mailto:[email-masked]> >; Huzhibo <[email-masked] <mailto:[email-masked]> >; Aijun Wang <[email-masked] <mailto:[email-masked]> >; Tony Li <[email-masked] <mailto:[email-masked]> >; lsr <[email-masked] <mailto:[email-masked]> >; Tianran Zhou <[email-masked] <mailto:[email-masked]> >
Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Hi Les,

From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Tuesday, March 9, 2021 11:15 AM
To: Gyan Mishra <[email-masked] <mailto:[email-masked]> >; Peter Psenak (ppsenak) <[email-masked] <mailto:[email-masked]> >
Cc: Robert Raszuk <[email-masked] <mailto:[email-masked]> >; Huzhibo <[email-masked] <mailto:[email-masked]> >; Aijun Wang <[email-masked] <mailto:[email-masked]> >; Tony Li <[email-masked] <mailto:[email-masked]> >; lsr <[email-masked] <mailto:[email-masked]> >; Tianran Zhou <[email-masked] <mailto:[email-masked]> >; wangyali <[email-masked] <mailto:[email-masked]> >
Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

 

   the network. ‘’

 

   Les

   Les

From: Lsr <[email-masked] <mailto:[email-masked]> > On Behalf Of Gyan Mishra
Sent: Friday, March 05, 2021 8:11 AM
To: Peter Psenak (ppsenak) <[email-masked] <mailto:[email-masked]> >
Cc: Robert Raszuk <[email-masked] <mailto:[email-masked]> >; Huzhibo <[email-masked] <mailto:[email-masked]> >; Aijun Wang <[email-masked] <mailto:[email-masked]> >; Tony Li <[email-masked] <mailto:[email-masked]> >; lsr <[email-masked] <mailto:[email-masked]> >; Tianran Zhou <[email-masked] <mailto:[email-masked]> >; wangyali <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Hi Peter

On Fri, Mar 5, 2021 at 10:56 AM Peter Psenak <[email-masked] <mailto:[email-masked]> > wrote:

Gyan,

thanks,
Peter

 <https://tools.ietf.org/html/rfc5120#section-6> 6.  MT SPF Computation

 

> On Fri, Mar 5, 2021 at 10:28 AM Peter Psenak <[email-masked] <mailto:[email-masked]>  
> <mailto:[email-masked] <mailto:[email-masked]> >> wrote:
> 
>     Hi Yali,
> 
>      > From: Peter Psenak [mailto:[email-masked] <mailto:[email-masked]> 
>     <mailto:[email-masked] <mailto:[email-masked]> >]
>      > To: wangyali <[email-masked] <mailto:[email-masked]> 
>     <mailto:[email-masked] <mailto:[email-masked]> >>; Gyan Mishra <[email-masked] <mailto:[email-masked]> 
>     <mailto:[email-masked] <mailto:[email-masked]> >>; Robert Raszuk <[email-masked] <mailto:[email-masked]> 
>     <mailto:[email-masked] <mailto:[email-masked]> >>
>      > Cc: Huzhibo <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>;
>     Aijun Wang <[email-masked] <mailto:[email-masked]> 
>     <mailto:[email-masked] <mailto:[email-masked]> >>; Tony Li <[email-masked] <mailto:[email-masked]> 
>     <mailto:[email-masked] <mailto:[email-masked]> >>; lsr <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>;
>     Tianran Zhou <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>
>      >> From: Peter Psenak [mailto:[email-masked] <mailto:[email-masked]> 
>     <mailto:[email-masked] <mailto:[email-masked]> >]
>      >> To: wangyali <[email-masked] <mailto:[email-masked]> 
>     <mailto:[email-masked] <mailto:[email-masked]> >>; Gyan Mishra
>      >> <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>; Robert
>     Raszuk <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>
>      >> Cc: Huzhibo <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>;
>     Aijun Wang
>      >> <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>; Tony
>     Li <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>; lsr
>      >> <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>; Tianran Zhou
>     <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>
>      >>> From: Peter Psenak [mailto:[email-masked] <mailto:[email-masked]> 
>     <mailto:[email-masked] <mailto:[email-masked]> >]
>      >>> To: wangyali <[email-masked] <mailto:[email-masked]> 
>     <mailto:[email-masked] <mailto:[email-masked]> >>; Gyan Mishra
>      >>> <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>; Robert
>     Raszuk <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>
>      >>> Cc: Huzhibo <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>;
>     Aijun Wang
>      >>> <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>;
>     Tony Li <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>; lsr
>      >>> <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>; Tianran Zhou
>     <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>
>      >>>> From: Peter Psenak [mailto:[email-masked] <mailto:[email-masked]> 
>     <mailto:[email-masked] <mailto:[email-masked]> >]
>      >>>> To: wangyali <[email-masked] <mailto:[email-masked]> 
>     <mailto:[email-masked] <mailto:[email-masked]> >>; Gyan Mishra
>      >>>> <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>; Robert
>     Raszuk <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>
>      >>>> Cc: Huzhibo <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>;
>     Aijun Wang
>      >>>> <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>;
>     Tony Li <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>; lsr
>      >>>> <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>; Tianran Zhou
>     <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>
>      >>>>> From: Peter Psenak [mailto:[email-masked] <mailto:[email-masked]> 
>     <mailto:[email-masked] <mailto:[email-masked]> >]
>      >>>>> To: Gyan Mishra <[email-masked] <mailto:[email-masked]> 
>     <mailto:[email-masked] <mailto:[email-masked]> >>; Robert Raszuk
>      >>>>> <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>
>      >>>>> Cc: Huzhibo <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>;
>     Aijun Wang
>      >>>>> <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>;
>     Tony Li <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>; lsr
>      >>>>> <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>; Tianran Zhou
>     <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>; wangyali
>      >>>>> <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>
>     <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >
>      >>>>>> <mailto:[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>> wrote:
>      >>>>>>
>      >>>>>>          Aijun,
>      >>>>>>
>     <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >
>      >>>>>>          <mailto:[email-masked] <mailto:[email-masked]> 
>     <mailto:[email-masked] <mailto:[email-masked]> >>> wrote:
>      >>>>>>
>      >>>>>>              Hi, Robert:
>      >>>>>>
>      >>>>>>              similar task, but it has <https://www.google.com/maps/search/ar+task,+but+it+has?entry=gmail&source=g>  some deployment overhead.
>     <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >
>      >>>>>>>              <mailto:[email-masked] <mailto:[email-masked]> 
>     <mailto:[email-masked] <mailto:[email-masked]> >>> wrote:
>      >>>>>>>
>      >>>>>>>              Hi Yali,
>      >>>>>>>
>     <https://www.google.com/maps/search/lution+we+recommend?entry=gmail <https://www.google.com/maps/search/lution+we+recommend?entry=gmail&source=g> &source=g>
>     to solve
>      >>>>>>> [email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> > <mailto:[email-masked] <mailto:[email-masked]> 
>     <mailto:[email-masked] <mailto:[email-masked]> >>
>      >>>>>> [email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> > <mailto:[email-masked] <mailto:[email-masked]> 
>     <mailto:[email-masked] <mailto:[email-masked]> >>

-- 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 10 Mar 2021 01:25:03 -0500

Les

This TEAS draft discusses the scalability of network slices and does
discuss that their could be network slices in the order of 1000s as each
slice represents a service but would be no more then the number of VPN
services that exist today.

See section 2 VPN+ scalability.

https://datatracker.ietf.org/doc/html/draft-dong-teas-enhanced-vpn-vtn-scalability-02

   2.  Network slicing can be used to provide isolated and customized
       virtual networks for tenants in different vertical industries.
       At the early stage of the vertical industrial service deployment,
       a few top tenants in some typical industries will begin to use
       network slicing to support their business, such as smart grid,
       manufacturing, public safety, on-line gaming, etc.  Considering
       the number of the vertical industries, and the number of top
       tenants in each industry, the number of network slices may
       increase to the order of 100.

3.  With the evolution of 5G, network slicing could be widely used by
       both vertical industrial tenants and enterprise tenants which
       require guaranteed or predictable service performance.  The total
       amount of network slices may increase to the order of 1000 or
       more.  However, it is expected that the number of network slices
       would still be less than the number of traditional VPN services
       in the network.

   In 3GPP [TS23501
<https://datatracker.ietf.org/doc/html/draft-dong-teas-enhanced-vpn-vtn-scalability-02#ref-TS23501>],
a 5G network slice is identified using Single
   Network Slice Selection Assistance Information (S-NSSAI), which is a
   32-bit identifier comprised of 8-bit Slice/Service Type (SST) and
   24-bit Slice Differentiator (SD).  This allows the mobile networks
   (RAN and CN) to provide a large number of network slices.  Although
   it is possible that multiple network slices in RAN and CN can be
   mapped to the same IETF network slice, the number of IETF network
   slices may still be comparable with the number of 5G network slices.
   Thus the scalability of IETF network slices needs to be taken into
   consideration.

Kind Regards

Gyan

On Tue, Mar 9, 2021 at 3:28 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> *From:* wangyali <[email-masked]>
> *Sent:* Tuesday, March 09, 2021 6:22 AM
> *To:* Les Ginsberg (ginsberg) <[email-masked]>; Gyan Mishra <
> [email-masked]>; Peter Psenak (ppsenak) <[email-masked]>
> *Cc:* Robert Raszuk <[email-masked]>; Huzhibo <[email-masked]>;
> Aijun Wang <[email-masked]>; Tony Li <[email-masked]>; lsr <
> [email-masked]>; Tianran Zhou <[email-masked]>
> *Subject:* RE: [Lsr] New Version Notification for
> draft-wang-lsr-isis-mfi-00.txt
>
>
>
> Hi Les,
>
> *From:* Les Ginsberg (ginsberg) [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Tuesday, March 9, 2021 11:15 AM
> *To:* Gyan Mishra <[email-masked]>; Peter Psenak (ppsenak) <
> [email-masked]>
> *Cc:* Robert Raszuk <[email-masked]>; Huzhibo <[email-masked]>;
> Aijun Wang <[email-masked]>; Tony Li <[email-masked]>; lsr <
> [email-masked]>; Tianran Zhou <[email-masked]>; wangyali <
> [email-masked]>
> *Subject:* RE: [Lsr] New Version Notification for
> draft-wang-lsr-isis-mfi-00.txt
>
>
>
> Sooo, I have been reluctant to comment on the shortcomings of this draft
> because I feel there was no need for the draft to be written in the first
> place.
>
> I had hoped that the authors would think about this a bit more and realize
> the flaws in the proposed solution – or – as Acee suggested during the WG
> meeting – they would attempt an implementation and discover what had not
> yet been realized. This then would end the time the WG is spending on this
> – which IMO is the right outcome.
>
>
>
> The goal of the draft is to support per-MFI LSDBs in the standard instance
> of IS-IS.  Since it is not possible for a legacy node to differentiate
> LSP.xx-yy w MFI #1 from the same LSP with MFI #2 (or with no MFI at all),
> it is clear that an MFI LSP cannot be flooded to a legacy node EVER!!
>
> [Yali]: In our proposal, we considered the scenario where some routers
> that do not support MFI, and recommended that all MFIs share one LSP Number
> space in the standard instance of IS-IS protocol. And if routers that do
> not support MFI but receive the LSPs and SNPs carrying MFI-ID TLV, then
> routers SHOULD ignore the MFI-ID TLV and continues processing other TLVs.
>
>
>
> *[Les:] Yes – I understand this. But, as I point out below, this case is
> already provided for by RFC 6823.  We do discourage doing this – as we
> discourage your proposed use of the standard instance. But it is already
> defined – so your draft adds no new functionality for this case.*
>
>
>
> In order to prevent this, a node has to know whether a given neighbor
> supports MFI or not. But since the draft defines no signaling in hellos, it
> cannot tell whether the neighbor supports MFI (not to mention which MFIs –
> which is important for avoiding flooding MFI LSPs to nodes that aren’t
> interested in that MFI) you are forced to rely on receiving LSPs (or SNPs)
> – which brings us to the chicken/egg problem. Neither I nor my neighbor can
> send an MFI LSP out of fear that the receiver does not support MFI. So MFI
> flooding is blocked.
>
>
>
> This problem can be solved by including the MFI TLV in hellos (analogous
> to what MI(RFRC 8202) does). But this is not the end of your issues. If you
> have a LAN, you could have a mix of legacy routers and MFI routers – and
> again you cannot allow legacy routers to receive MFI LSPs as they will look
> just like legacy LSPs to the legacy nodes. This means you will have to find
> a way to avoid ever having MFI PDUs received by legacy nodes (RFC 8202 uses
> different MAC multicast addresses).
>
> [Yali]: Correctly. You’re right. There indeed be a signaling in Hellos.
> MFI-ID TLV can be included in IS-IS Hellos. Because we want to focus on
> extensions to Update process, we originally plan to implement this part in
> the second version.
>
> We also have describe the Interoperability Considerations in the condition
> where some routers do not support MFI in the draft.
>
>
>
> *[Les:] Glad you agree. But the point is – when you have finished your
> draft – you will simply end up with a variation of RFC 8202. So it won’t be
> simpler – which was one of your key goals.*
>
> *This is one of many reasons why I see no need for your draft. *
>
>
>
> Sooo, once you have addressed both of these issues you will have repeated
> what RFC 8202 already does. No new benefits here.
>
>
>
> This then leaves you with one possible use case: support a single LSDB for
> all MFIs in the standard IS-IS instance. But, this use case is already
> provided for (though strongly discouraged) by
> https://tools.ietf.org/html/rfc6823#section-5 .
>
> [Yali]: This proposal is used to solve the issue that how we can isolate
> the impacts of non-routing information flooding under the condition that
> there is only the standard instance of IS-IS protocol implemented in the
> network and no one router support Multi-instance. Sec.5 also mentioned the
> issue as follows.
>
>
>
> *[Les:] If – as you seem to agree – you can only support a single LSDB, there is no need for any protocol extensions and no need for the new MFI TLV. You could advertise GENINFPO for multiple apps in the standard instance.*
>
> *So your table below is irrelevant.*
>
>
>
> So in this proposed draft, we give an optional solution by separate
> multiple Update processes for different kinds of information, such as
> following example shown in the Table (I presented in the yesterday
> meeting). Each Level 1/Level 2 LSPs associated with a specific MFI
> carries flooding information, such as routing topology, belonging to the
> specific MFI #0. And Level 1/Level 2 PSNPs and Level 1/Level 2 CSNP
> containing information about LSPs that transmitted in a specific MFI#0 are
> generated to synchronize the information propagated in the MFI #0 LSDB that
> is subdivided from a single LSDB within the standard instance of protocol.
>
>
>
>
>
> As shown in table, different flooding information can be propagated in
> the unique Update process. In each MFI, priority and update parameters can
> be customized in dependent on the requirements on the flooding rate of
> different information. Hence, in our proposal, we also provide an optional
> solution that can be used in the standard instance to solve the issue also
> mentioned in section 5 as follows.
>
> I do understand that some folks want to advertise VTN info in IGPs and
> that the WG will be discussing this. I am not in favor of doing this – but
> I recognize it is a legitimate topic for discussion. And if the WG were to
> approve such functionality we have MI available to be used to provide
> separation.
>
> [Yali]: Well, then may I post a question (or maybe a Survey) here for
> folks from operators? The question is that when deploying thousands of
> slices, are you willing to implement thousands of IS-IS instances to flood
> thousands of slices topologies and so on? From our side, we can't imagine
> what a huge project it is.
>
> *[Les:] This is not an appropriate response. No one – not you, not me, nor
> anyone else on this thread – has suggested that thousands of IS-IS
> instances would be required. For you to suggest this  induces uncalled for
> hysteria.*
>
> *It is obvious that if you could send info for multiple applications in
> the standard instance you can do so in a single non-standard instance – but
> we would at least have separation from the routing instance. Certainly
> there is no need for thousands of instances.*
>
> *Please do not compromise a meaningful dialogue with this misdirection.*
>
>
>
> *If you read https://www.rfc-editor.org/rfc/rfc8202.html#section-4
> <https://www.rfc-editor.org/rfc/rfc8202.html#section-4> there is a
> discussion of related issues. Section 4.3 is particularly relevant to your
> comment.*
>
>
>
> *   Les*
>
>
>
> draft-wang-lsr-isis-mfi is an unnecessary proposal, seriously flawed, and
> not achieving any of the goals stated in its introduction.
>
> *From:* Lsr <[email-masked]> *On Behalf Of *Gyan Mishra
> *Sent:* Friday, March 05, 2021 8:11 AM
> *To:* Peter Psenak (ppsenak) <[email-masked]>
> *Cc:* Robert Raszuk <[email-masked]>; Huzhibo <[email-masked]>;
> Aijun Wang <[email-masked]>; Tony Li <[email-masked]>; lsr <
> [email-masked]>; Tianran Zhou <[email-masked]>; wangyali <
> [email-masked]>
> *Subject:* Re: [Lsr] New Version Notification for
> draft-wang-lsr-isis-mfi-00.txt
>
>
>
> Hi Peter
>
>
>
> *6 <https://tools.ietf.org/html/rfc5120#section-6>**.  MT SPF Computation*
>
>
>
>
>
> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>
> >      >>>>>> /Silver Spring, MD
> >      >>>>>>
> >      >>>>>>
> >      >>>>>
> >      >>>>>
> >      >>>>>
> >      >>>>
> >      >>>>
> >      >>>>
> >      >>>
> >      >>>
> >      >>>
> >      >>
> >      >>
> >      >>
> >      >
> >      >
> >      >
> >
> > --
> >
> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>
> > /Silver Spring, MD
> >
> >
>
> --
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>
> *Silver Spring, MD
>
>
>
-- 

*Gyan Mishra*

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 10 Mar 2021 12:57:15 +0000

Aijun –

Inline.

From: [email-masked] <[email-masked]>
Sent: Tuesday, March 09, 2021 10:14 PM
To: Les Ginsberg (ginsberg) <[email-masked]>; 'wangyali' <[email-masked]>; 'Gyan Mishra' <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>
Cc: 'Robert Raszuk' <[email-masked]>; 'Huzhibo' <[email-masked]>; 'Tony Li' <[email-masked]>; 'lsr' <[email-masked]>; 'Tianran Zhou' <[email-masked]>
Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Hi, Les:

[Les:] Hmmm…I do not know what you mean by “IGP Nodes”. Given we are always talking about nodes which are running IS-IS I would assume all nodes are “IGP Nodes”. Apparently you have some other distinction in mind, but what it is I do not know.

If your concern is that when using MI it is still necessary to calculate an SPT in order to track the set of MI/ITID nodes which are currently reachable, I would remind you that https://tools.ietf.org/html/rfc8202#section-4 recommends minimizing the number of instances/flooding topologies. MI has never advocated  – nor required – that there be a 1-1 mapping between a flooding topology and an application. The idea that if there are thousands of MFIs (to borrow the term from your draft) it would be required to have thousands of IID/ITID pairs when using MI is incorrect. The number of flooding topologies should be minimized as per RFC 8202 Section 4.

I also point out that if it is your intent as part of your draft to have a separate flooding topology/MFI (which is what your text suggests),  you will have to build an MFI specific SPT in order to flood the MFI specific LSDB only to the nodes who ae interested in this MFI specific LSDB.
Your other alternative is to share a single flooding topology for multiple MFI specific LSDBs, in which case you can reduce the number of SPTs which need to be calculated but at the cost of potentially sending MFI specific information to nodes which are not interested in it. In this regard, the options available are identical to what MI offers.

The difference between MFI draft and RFC 8202 is that with the latter we have complete separation of the Update Process(es) used for distributing the application information from the operation of the Standard Instance. The scaling characteristics of the two solutions are identical, something which you seem to have misunderstood.

[Les:] I am aware of and have read this draft. I do not believe it has any relevance to this discussion. Here we are discussing whether there is a need for yet another definition of how to instantiate Update Process(es) used for sending Application information. Let’s please confine this thread to that discussion.
I believe it is only your confusion regarding the number of IID/ITID pairs that might be required when using RFC 8202 that suggests to you that this draft might be relevant. Hopefully I have corrected your misunderstanding.

    Les

Best Regards

Aijun Wang
China Telecom

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, March 10, 2021 4:25 AM
To: wangyali <[email-masked]<mailto:[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>; Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>
Cc: Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Huzhibo <[email-masked]<mailto:[email-masked]>>; Aijun Wang <[email-masked]<mailto:[email-masked]>>; Tony Li <[email-masked]<mailto:[email-masked]>>; lsr <[email-masked]<mailto:[email-masked]>>; Tianran Zhou <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Yali –

From: wangyali <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, March 09, 2021 6:22 AM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>; Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>
Cc: Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Huzhibo <[email-masked]<mailto:[email-masked]>>; Aijun Wang <[email-masked]<mailto:[email-masked]>>; Tony Li <[email-masked]<mailto:[email-masked]>>; lsr <[email-masked]<mailto:[email-masked]>>; Tianran Zhou <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Hi Les,

   Les

   Les

Hi Peter

thanks,
Peter

   same MT.

--

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 10 Mar 2021 13:06:48 +0000

Gyan –

Please read my recent reply to Aijun. I suspect it is relevant to your concern.

I also am very concerned about the amount of information associated with advertising VTN related information. It is one of the reasons that I and others prefer that IGPs not be used at all to advertise this information.
But this thread is discussing the need for definition of yet another way of supporting the Update process. This does not alter the scale characteristics of the solution as I have explained in my response to Aijun.

The number of bits which have to be flooded does not change significantly whether the Standard Instance is used of whether a non-zero MI instance is used. That is the key point to understand in the context of this thread.

   Les

From: Gyan Mishra <[email-masked]>
Sent: Tuesday, March 09, 2021 10:25 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Aijun Wang <[email-masked]>; Huzhibo <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>; Robert Raszuk <[email-masked]>; Tianran Zhou <[email-masked]>; Tony Li <[email-masked]>; lsr <[email-masked]>; wangyali <[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Les

This TEAS draft discusses the scalability of network slices and does discuss that their could be network slices in the order of 1000s as each slice represents a service but would be no more then the number of VPN services that exist today.

       in the network.

   In 3GPP [TS23501<https://datatracker.ietf.org/doc/html/draft-dong-teas-enhanced-vpn-vtn-scalability-02#ref-TS23501>], a 5G network slice is identified using Single

   consideration.

Kind Regards

Gyan

On Tue, Mar 9, 2021 at 3:28 PM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Yali –

Hi Les,

   Les

   Les

Hi Peter

thanks,
Peter

   same MT.

>      >>>>>> 13101 Columbia Pike<https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>
>      >>>>>> /Silver Spring, MD
>      >>>>>>
>      >>>>>>
>      >>>>>
>      >>>>>
>      >>>>>
>      >>>>
>      >>>>
>      >>>>
>      >>>
>      >>>
>      >>>
>      >>
>      >>
>      >>
>      >
>      >
>      >
>
> --
>
> 13101 Columbia Pike<https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>
> /Silver Spring, MD
>
>
--

Gyan Mishra

M 301 502-1347
13101 Columbia Pike<https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>
Silver Spring, MD

--

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 10 Mar 2021 14:08:48 +0100

I just add that SPT'ing the stuff to constrain the "flooding graphs" you
can create wonderful chains with choking points for flooding in the graph,
especially if you want to slosh lots info around that way. And in
particularly devious critical case ALL your topologies may end up flooding
through a single link as a choking point. RFC1925 (11) to which I should
write an errata with (ii) as "Tony's corollary" along the lines of "it is
often that the re-invention of the idea with a new name breaks it or makes
it more broken if it was broken before" and (iii) "if the re-invention is
broken the only remedy is often to force its implementation and attempt @
deployment" ;-)

-- tony

On Wed, Mar 10, 2021 at 1:58 PM Les Ginsberg (ginsberg) <ginsberg=
[email-masked]> wrote:

> Aijun –
>
>
>
> Inline.
>
>
>
> *From:* [email-masked] <[email-masked]>
> *Sent:* Tuesday, March 09, 2021 10:14 PM
> *To:* Les Ginsberg (ginsberg) <[email-masked]>; 'wangyali' <
> [email-masked]>; 'Gyan Mishra' <[email-masked]>; Peter
> Psenak (ppsenak) <[email-masked]>
> *Cc:* 'Robert Raszuk' <[email-masked]>; 'Huzhibo' <[email-masked]>;
> 'Tony Li' <[email-masked]>; 'lsr' <[email-masked]>; 'Tianran Zhou' <
> [email-masked]>
> Is there any deployment of Multi-Instance to transfer the application info
> as recommend in https://tools.ietf.org/html/rfc6823#section-5?
>
> From my POV, the transfer of the application information needs not even be
> flooded to all of the device’s participated circuits, as that does for
> the normal routing LSP.
>
> Such information needs only be reached to the IGP nodes, then they can
> follows the shortest path calculated by the base routing instance(reach the
> flooding reduction effect).
>
> Thus, why not considering using the existing routing instance? It can
> certainly decrease the overhead of neighbor configurations/maintenances for
> the new routing instance.
>
>
>
> *[Les:] Hmmm…I do not know what you mean by “IGP Nodes”. Given we are
> always talking about nodes which are running IS-IS I would assume all nodes
> are “IGP Nodes”. Apparently you have some other distinction in mind, but
> what it is I do not know.*
>
>
>
> *If your concern is that when using MI it is still necessary to calculate
> an SPT in order to track the set of MI/ITID nodes which are currently
> reachable, I would remind you that
> https://tools.ietf.org/html/rfc8202#section-4
> <https://tools.ietf.org/html/rfc8202#section-4> recommends minimizing the
> number of instances/flooding topologies. MI has never advocated  – nor
> required – that there be a 1-1 mapping between a flooding topology and an
> application. The idea that if there are thousands of MFIs (to borrow the
> term from your draft) it would be required to have thousands of IID/ITID
> pairs when using MI is incorrect. The number of flooding topologies should
> be minimized as per RFC 8202 Section 4. *
>
>
>
> *I also point out that if it is your intent as part of your draft to have
> a separate flooding topology/MFI (which is what your text suggests),  you
> will have to build an MFI specific SPT in order to flood the MFI specific
> LSDB only to the nodes who ae interested in this MFI specific LSDB. *
>
> *Your other alternative is to share a single flooding topology for
> multiple MFI specific LSDBs, in which case you can reduce the number of
> SPTs which need to be calculated but at the cost of potentially sending MFI
> specific information to nodes which are not interested in it. In this
> regard, the options available are identical to what MI offers.*
>
>
>
> *The difference between MFI draft and RFC 8202 is that with the latter we
> have complete separation of the Update Process(es) used for distributing
> the application information from the operation of the Standard Instance.
> The scaling characteristics of the two solutions are identical, something
> which you seem to have misunderstood.*
>
>
>
>
>
> And,
> https://datatracker.ietf.org/doc/html/draft-bowers-lsr-isis-gen-info-clarifications-00
> describes the necessary for the correlation of app info and other info that
> advertised in different routing instances.
>
> If we put them into the basic routing instance, and make their flooding
> does not influence the core routing calculation function, won’t be it
> more attractive?
>
>
>
> *[Les:] I am aware of and have read this draft. I do not believe it has
> any relevance to this discussion. Here we are discussing whether there is a
> need for yet another definition of how to instantiate Update Process(es)
> used for sending Application information. Let’s please confine this thread
> to that discussion.*
>
> *I believe it is only your confusion regarding the number of IID/ITID
> pairs that might be required when using RFC 8202 that suggests to you that
> this draft might be relevant. Hopefully I have corrected your
> misunderstanding.*
>
>
>
> *    Les*
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* [email-masked] <[email-masked]>
> *Sent:* Wednesday, March 10, 2021 4:25 AM
> *To:* wangyali <[email-masked]>; Gyan Mishra <[email-masked]>;
> Peter Psenak (ppsenak) <[email-masked]>
> *M 301 502-1347 13101 Columbia Pike  *Silver Spring, MD
>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 10 Mar 2021 14:40:15 +0000

The draft specifies a TLV to tag LSPs and immediately jumps to the conclusion that this is sufficient for implementations to provide separation  of routing and non-routing information. Now there are claims that this COULD imply flooding optimizations. Until the draft specifies how this separation is accomplished, it is a non-starter. I’m not encouraging the authors to do this as we already have multiple instances that provides a natural separation and we don’t need complex protocol extensions. If you do persist with this ill-advised draft, I’d ask you actually implement what you are proposing as a POC.

Thanks,
Acee

From: Lsr <[email-masked]> on behalf of Tony Przygienda <[email-masked]>
Date: Wednesday, March 10, 2021 at 8:11 AM
To: "Les Ginsberg (ginsberg)" <ginsberg=[email-masked]>
Cc: Tianran Zhou <[email-masked]>, Gyan Mishra <[email-masked]>, Robert Raszuk <[email-masked]>, Huzhibo <[email-masked]>, "[email-masked]" <[email-masked]>, Tony Li <[email-masked]>, lsr <[email-masked]>, wangyali <[email-masked]>, "Peter Psenak (ppsenak)" <[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

I just add that SPT'ing the stuff to constrain the "flooding graphs" you can create wonderful chains with choking points for flooding in the graph, especially if you want to slosh lots info around that way. And in particularly devious critical case ALL your topologies may end up flooding through a single link as a choking point. RFC1925 (11) to which I should write an errata with (ii) as "Tony's corollary" along the lines of "it is often that the re-invention of the idea with a new name breaks it or makes it more broken if it was broken before" and (iii) "if the re-invention is broken the only remedy is often to force its implementation and attempt @ deployment" ;-)

-- tony

On Wed, Mar 10, 2021 at 1:58 PM Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:[email-masked]>> wrote:
Aijun –

Inline.

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, March 09, 2021 10:14 PM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; 'wangyali' <[email-masked]<mailto:[email-masked]>>; 'Gyan Mishra' <[email-masked]<mailto:[email-masked]>>; Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>
Cc: 'Robert Raszuk' <[email-masked]<mailto:[email-masked]>>; 'Huzhibo' <[email-masked]<mailto:[email-masked]>>; 'Tony Li' <[email-masked]<mailto:[email-masked]>>; 'lsr' <[email-masked]<mailto:[email-masked]>>; 'Tianran Zhou' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Hi, Les:

    Les

Best Regards

Aijun Wang
China Telecom

Yali –

Hi Les,

   Les

   Les

Hi Peter

thanks,
Peter

   same MT.

--

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 10 Mar 2021 17:17:45 -0500

Hi Les

Understood.  As you mentioned that a lot of what is being proposed with MFI
that you and others have mentioned that MI is very scalable and without
having to reinvent the wheel with MFI.  As you mentioned the key point of
Standard zero instance versus Non zero instance as mentioned in RFC 8202
section 5 that care must be taken with 1-1 and with either standard or non
zero instance you have IID/ITID topology bits one to many that you can
subdivide app instances  topologies as needed within a single IID instance
without the need for more then one IID instance.

In RFa. 8202 section 4.2 many to one mapping

When multiple ITIDs are supported by aninstance, ITID #0 MUST NOT be supported.

How many bits of ITID  topologies are supported per MI IID instance?  Is it
16 bit per below so 65535 topologies?

Does each IID/ITID topology within the non zero instance have its own
dedicated LSDB or is it a shared LSDB with separate topology rib like MT?

The IID-TLV MAY include one or more ITIDs.  An ITID is a 16-bit
identifier where all values (0 - 65535) are valid.

How many MI instances maximum are supported?

I think the concern raised about MI was resource related and thus the MFI
approach to reinvent the wheel.

However you may be able to get the same scalability without the MI resource
concerns mentioned by the authors if you use a single non zero MI instance
with many  ITID topologies with one network slice per topology.

4.3 <https://tools.ietf.org/html/rfc8202#section-4.3>.  Considerations
for the Number of Instances

   The support of multiple topologies within the context of a single
   instance provides better scalability in support of multiple
   applications both in terms of the number of adjacencies that are
   required and in the flooding of topology-specific LSDB.  In many
   cases, the use of a single non-zero instance would be sufficient and
   optimal.  However, in cases where the set of topologies desired in
   support of a set of applications is largely disjoint from the set of
   topologies desired in support of a second set of applications, it
   could make sense to use multiple instances.

Kind Regards

Gyan

On Wed, Mar 10, 2021 at 8:07 AM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> I also am very concerned about the amount of information associated with
> advertising VTN related information. It is one of the reasons that I and
> others prefer that IGPs not be used at all to advertise this information.
>
> But this thread is discussing the need for definition of yet another way
> of supporting the Update process. This does not alter the scale
> characteristics of the solution as I have explained in my response to Aijun.
>
>
>
> The number of bits which have to be flooded does not change significantly
> whether the Standard Instance is used of whether a non-zero MI instance is
> used. That is the key point to understand in the context of this thread.
>
>
>
>    Les
>
>
>
> *From:* Gyan Mishra <[email-masked]>
> *Sent:* Tuesday, March 09, 2021 10:25 PM
> *To:* Les Ginsberg (ginsberg) <[email-masked]>
> *Cc:* Aijun Wang <[email-masked]>; Huzhibo <[email-masked]>;
> Peter Psenak (ppsenak) <[email-masked]>; Robert Raszuk <
> [email-masked]>; Tianran Zhou <[email-masked]>; Tony Li <
> [email-masked]>; lsr <[email-masked]>; wangyali <[email-masked]>
>    In 3GPP [TS23501 <https://datatracker.ietf.org/doc/html/draft-dong-teas-enhanced-vpn-vtn-scalability-02#ref-TS23501>], a 5G network slice is identified using Single
>
-- 

*Gyan Mishra*

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 10 Mar 2021 22:33:32 +0000

Gyan –

I believe you have already answered most of your own questions.
Some responses inline.

Sent: Wednesday, March 10, 2021 2:18 PM

Hi Les

Understood.  As you mentioned that a lot of what is being proposed with MFI that you and others have mentioned that MI is very scalable and without having to reinvent the wheel with MFI.  As you mentioned the key point of Standard zero instance versus Non zero instance as mentioned in RFC 8202 section 5 that care must be taken with 1-1 and with either standard or non zero instance you have IID/ITID topology bits one to many that you can subdivide app instances  topologies as needed within a single IID instance without the need for more then one IID instance.

How many bits of ITID  topologies are supported per MI IID instance?  Is it 16 bit per below so 65535 topologies?
[Les:] As you note below, ITID is a 16 bit value. All values are legal though ITID #0 is reserved for a special use case described in Section 5 of the document.

Does each IID/ITID topology within the non zero instance have its own dedicated LSDB or is it a shared LSDB with separate topology rib like MT?

The IID-TLV MAY include one or more ITIDs.  An ITID is a 16-bit identifier where all values (0 - 65535) are valid.

[Les:] Theoretically you could have 65535 instances – though such a number would be impractical to deploy.

I think the concern raised about MI was resource related and thus the MFI approach to reinvent the wheel.

However you may be able to get the same scalability without the MI resource concerns mentioned by the authors if you use a single non zero MI instance with many  ITID topologies with one network slice per topology.

[Les:] I would not recommend a separate flooding topology/slice given that you seem to be talking  up to 1000 slices. But this is getting ahead of ourselves. At least you seem now to understand that the same scale issues arise w MFI as with MI as such numbers – which is a good outcome for this thread.

   Les
4.3<https://tools.ietf.org/html/rfc8202#section-4.3>.  Considerations for the Number of Instances

Kind Regards

Gyan

On Wed, Mar 10, 2021 at 8:07 AM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Gyan –

   Les

From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, March 09, 2021 10:25 PM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: Aijun Wang <[email-masked]<mailto:[email-masked]>>; Huzhibo <[email-masked]<mailto:[email-masked]>>; Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Tianran Zhou <[email-masked]<mailto:[email-masked]>>; Tony Li <[email-masked]<mailto:[email-masked]>>; lsr <[email-masked]<mailto:[email-masked]>>; wangyali <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Les

       in the network.

   consideration.

Kind Regards

Gyan

Hi Les,

   Les

   Les

Hi Peter

thanks,
Peter

   same MT.

--

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 10 Mar 2021 23:39:50 +0100

Dear Authors,

Looking at the bigger picture here I have two simple questions.

Q1: Do you plan to submit draft-xxxxx-lsr-ospf-mfi-00.txt any time soon ?

Q2: If No - why not ?
       If Yes - how would you choose to use either
draft-xxxxx-lsr-ospf-mfi-00.txt or
https://tools.ietf.org/html/draft-ietf-ospf-transport-instance-11 for your
non
       routing application (opaque to routing) information flooding ?

Extra bonus question - It seems that the very same application (ifit) is
proposed to be distributed using BGP too (
https://tools.ietf.org/html/draft-wang-idr-bgp-ifit-capabilities-01). Can
you provide pros and cons comparison of using link state flooding vs p2mp
BGP model to distribute this type of data ?

Hint: Please do not respond .. Oh this is yet another way ... That is not a
valid answer.

Many thx,
Robert.

---

From: Lizhenbin <[email-masked]>
Date: Thu, 11 Mar 2021 07:31:21 +0000

Hi Acee,
Thanks for your suggestion. It should take more work for the solution proposed by the draft.

Best Regards,
Robin

From: Lsr [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, March 10, 2021 10:40 PM
To: Tony Przygienda <[email-masked]>; Les Ginsberg (ginsberg) <ginsberg=[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Robert Raszuk <[email-masked]>; Huzhibo <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>; [email-masked]; Tony Li <[email-masked]>; lsr <[email-masked]>; Tianran Zhou <[email-masked]>; wangyali <[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Thanks,
Acee

From: Lsr <[email-masked]<mailto:[email-masked]>> on behalf of Tony Przygienda <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 10, 2021 at 8:11 AM
To: "Les Ginsberg (ginsberg)" <ginsberg=[email-masked]<mailto:ginsberg=[email-masked]>>
Cc: Tianran Zhou <[email-masked]<mailto:[email-masked]>>, Gyan Mishra <[email-masked]<mailto:[email-masked]>>, Robert Raszuk <[email-masked]<mailto:[email-masked]>>, Huzhibo <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Tony Li <[email-masked]<mailto:[email-masked]>>, lsr <[email-masked]<mailto:[email-masked]>>, wangyali <[email-masked]<mailto:[email-masked]>>, "Peter Psenak (ppsenak)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

-- tony

Inline.

Hi, Les:

    Les

Best Regards

Aijun Wang
China Telecom

Yali –

Hi Les,

   Les

   Les

Hi Peter

thanks,
Peter

   same MT.

--

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Lizhenbin <[email-masked]>
Date: Thu, 11 Mar 2021 07:38:47 +0000

Hi Robert,
The draft tries to propose a lightweight isolated flooding solution capering the existing IGP multi-instance solutions. As the suggestion proposed by Acee, it should take more work. Now it focuses on ISIS firstly. Then OSPF may be taken into account depending on the research result of ISIS.

Best Regards,
Robin

From: Lsr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, March 11, 2021 6:40 AM
To: Aijun Wang <[email-masked]>; wangyali <[email-masked]>; Tianran Zhou <[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; Tony Li <[email-masked]>; Gyan Mishra <[email-masked]>; lsr <[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Dear Authors,

Q2: If No - why not ?
       If Yes - how would you choose to use either  draft-xxxxx-lsr-ospf-mfi-00.txt or https://tools.ietf.org/html/draft-ietf-ospf-transport-instance-11 for your non
       routing application (opaque to routing) information flooding ?

Extra bonus question - It seems that the very same application (ifit) is proposed to be distributed using BGP too (https://tools.ietf.org/html/draft-wang-idr-bgp-ifit-capabilities-01). Can you provide pros and cons comparison of using link state flooding vs p2mp BGP model to distribute this type of data ?

Hint: Please do not respond .. Oh this is yet another way ... That is not a valid answer.

Many thx,
Robert.

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 11 Mar 2021 16:48:48 +0800

Hi, Acee and Les:

Please see the responses inline [WAJ]

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> 
Sent: Wednesday, March 10, 2021 10:40 PM
To: Tony Przygienda <[email-masked]>; Les Ginsberg (ginsberg) <ginsberg=[email-masked]>
Cc: Tianran Zhou <[email-masked]>; Gyan Mishra <[email-masked]>; Robert Raszuk <[email-masked]>; Huzhibo <[email-masked]>; [email-masked]; Tony Li <[email-masked]>; lsr <[email-masked]>; wangyali <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

The draft specifies a TLV to tag LSPs and immediately jumps to the conclusion that this is sufficient for implementations to provide separation  of routing and non-routing information. 

[WAJ] Multi-topology solution takes the same way.

Now there are claims that this COULD imply flooding optimizations. 

[WAJ] Flooding optimizations is accomplished via the tune of MFI-specified timers. 

Until the draft specifies how this separation is accomplished, it is a non-starter. I’m not encouraging the authors to do this as we already have multiple instances that provides a natural separation and we don’t need complex protocol extensions. 

[WAJ] There are obvious benefits in deployment to transfer such non-routing information via the already existing flooding graph、flooding reduction graph or even SPT path. 

If you do persist with this ill-advised draft, I’d ask you actually implement what you are proposing as a POC. 

[WAJ] Before implementation or discussion, we should not make such assertion.

Thanks,

Acee

From: Lsr <[email-masked] <mailto:[email-masked]> > on behalf of Tony Przygienda <[email-masked] <mailto:[email-masked]> >
Date: Wednesday, March 10, 2021 at 8:11 AM
To: "Les Ginsberg (ginsberg)" <ginsberg=[email-masked] <mailto:ginsberg=[email-masked]> >
Cc: Tianran Zhou <[email-masked] <mailto:[email-masked]> >, Gyan Mishra <[email-masked] <mailto:[email-masked]> >, Robert Raszuk <[email-masked] <mailto:[email-masked]> >, Huzhibo <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >, Tony Li <[email-masked] <mailto:[email-masked]> >, lsr <[email-masked] <mailto:[email-masked]> >, wangyali <[email-masked] <mailto:[email-masked]> >, "Peter Psenak (ppsenak)" <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

-- tony 

On Wed, Mar 10, 2021 at 1:58 PM Les Ginsberg (ginsberg) <ginsberg=[email-masked] <mailto:[email-masked]> > wrote:

Aijun –

Inline.

From: [email-masked] <mailto:[email-masked]>  <[email-masked] <mailto:[email-masked]> > 
Sent: Tuesday, March 09, 2021 10:14 PM
To: Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]> >; 'wangyali' <[email-masked] <mailto:[email-masked]> >; 'Gyan Mishra' <[email-masked] <mailto:[email-masked]> >; Peter Psenak (ppsenak) <[email-masked] <mailto:[email-masked]> >
Cc: 'Robert Raszuk' <[email-masked] <mailto:[email-masked]> >; 'Huzhibo' <[email-masked] <mailto:[email-masked]> >; 'Tony Li' <[email-masked] <mailto:[email-masked]> >; 'lsr' <[email-masked] <mailto:[email-masked]> >; 'Tianran Zhou' <[email-masked] <mailto:[email-masked]> >
Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Hi, Les:

[WAJ] I had read this and known we need not 1-1 mapping for the MI and the MFI 

[WAJ] I think such SPT is not needed. The nodes that doesn’t interest in this MFI specific information can just ignore it.

[WAJ] I think the reason that we use IGP to flooding such non-routing information is to let the IS-IS nodes to synchronize such thing. Or else, we should rely other protocols to transfer such non-routing information. Can’t image in what situation some IS-IS nodes are interested in, but some not.  This is different from the MI, in which different instances may have different purposes and the connection topologies. 

[WAJ] Both solutions are scalable, but the MFI seems more lightweight in deployment. 

[WAJ] Don’t you think that using MFI can avoid such possible inconsistences?

    Les

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <mailto:[email-masked]>  <[email-masked] <mailto:[email-masked]> > 
Sent: Wednesday, March 10, 2021 4:25 AM
To: wangyali <[email-masked] <mailto:[email-masked]> >; Gyan Mishra <[email-masked] <mailto:[email-masked]> >; Peter Psenak (ppsenak) <[email-masked] <mailto:[email-masked]> >
Cc: Robert Raszuk <[email-masked] <mailto:[email-masked]> >; Huzhibo <[email-masked] <mailto:[email-masked]> >; Aijun Wang <[email-masked] <mailto:[email-masked]> >; Tony Li <[email-masked] <mailto:[email-masked]> >; lsr <[email-masked] <mailto:[email-masked]> >; Tianran Zhou <[email-masked] <mailto:[email-masked]> >
Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Yali –

Please see inline.

Hi Les,

 

   the network. ‘’

 

   Les

   Les

Hi Peter

Gyan,

thanks,
Peter

 

 

-- 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD