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

From: wangyali <[email-masked]>
Date: Tue, 23 Feb 2021 07:10:34 +0000

Hi all,

In order to separate multiple flooding instances for dissemination of routing information and other types of application-specific information to minimizes the impact of non-routing information flooding on the routing convergence and stability, We submitted a new IS-IS flooding mechanism implemented in the zero IS-IS instance, named as IS-IS Multi-flooding Instances (MFIs).

 An encoding format for IS-IS MFI-ID TLV and MFIs Update Process defined in this draft could be found in https://datatracker.ietf.org/doc/draft-wang-lsr-isis-mfi/ .

Any questions and comments are welcome.

Thanks,
Yali

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 22, 2021 9:59 AM
To: Aijun Wang <[email-masked]>; Tianran Zhou <[email-masked]>; wangyali <[email-masked]>; Huzhibo <[email-masked]>
Subject: New Version Notification for draft-wang-lsr-isis-mfi-00.txt

A new version of I-D, draft-wang-lsr-isis-mfi-00.txt has been successfully submitted by Yali Wang and posted to the IETF repository.

Name:		draft-wang-lsr-isis-mfi
Revision:	00
Title:		IS-IS Multi-Flooding Instances
Document date:	2021-02-20
Group:		Individual Submission
Pages:		7
URL:            https://www.ietf.org/archive/id/draft-wang-lsr-isis-mfi-00.txt
Status:         https://datatracker.ietf.org/doc/draft-wang-lsr-isis-mfi/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-wang-lsr-isis-mfi
Htmlized:       https://tools.ietf.org/html/draft-wang-lsr-isis-mfi-00

Abstract:
   This document proposes a new IS-IS flooding mechanism which separates
   multiple flooding instances for dissemination of routing information
   and other types of application-specific information to minimizes the
   impact of non-routing information flooding on the routing convergence
   and stability.  Due to different flooding information has different
   requirements on the flooding rate, these multi-flooding instances
   should be given various priorities and flooding parameters.  An
   encoding format for IS-IS Multi-Flooding Instance Identifier (MFI-ID)
   TLV and Update Process are specified in this document.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Tony Li <[email-masked]>
Date: Tue, 23 Feb 2021 14:07:39 -0800

Hi,

Thank you for contributing your draft. I’m writing because I’m having trouble understanding the motivation for this work.

First off, I do NOT want to argue about carrying unnecessary information in IS-IS. IMHO, it is unmitigated evil and an attempt to destroy the viability of the protocol by creating arbitrary complexity and scale. But never mind that, I’ll stipulate for this discussion that we want to do so.

Given this, what is it that you’re trying to accomplish?  You’ve called this a ‘multi-flooding instance’, but it’s very unclear about what that means.  You say that multiple MFIs exist within a single IS-IS instance.

You obviously want data flooded. So what is the difference between an LSP in MFI A and another LSP in MFI B? Are there separate flooding topologies but a common LSDB? Or are you trying to subdivide the LSDB?

You mention that there is only a single update process in an instance. AFAICT, that’s only a model, not a requirement. There’s no prohibition that I know of against an implementation using a process per interface if iit wanted to.

What problem are you solving?

Regards,
Tony

> On Feb 22, 2021, at 11:10 PM, wangyali <[email-masked]> wrote:
> 
> Hi all,
> 
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 24 Feb 2021 03:54:11 +0000

IMO there is no need for this draft to exist.

Before a need for such a draft can be established two things have to happen in the following order:

1)There has to be WG consensus that application info such as VTN should be advertised by the IGPs.
To date no such consensus exists and there has been significant resistance to doing so.

2)If such consensus is reached there is already a defined/implemented solution - RFC 8202. Therefore, the need for a different set of protocol extensions would first require WG consensus that there are significant shortcomings to the RFC 8202 solution.
No such consensus exists nor has any discussion on this point taken place.

If the authors of this new draft want to start by discussing point #1 on the list - fair enough. But the starting point for that discussion should NOT be this draft. Therefore, I will make no comment on the content of the draft.

Authors - if your response is to try to explain to me why this draft is needed, then you have not understood what I am saying.

   Les

> From: Lsr <[email-masked]> On Behalf Of wangyali
> Sent: Monday, February 22, 2021 11:11 PM
> To: [email-masked]
> Cc: Huzhibo <[email-masked]>; Aijun Wang
> <[email-masked]>; Tianran Zhou <[email-masked]>
> Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt
> 
> Hi all,
> 
> In order to separate multiple flooding instances for dissemination of routing
> information and other types of application-specific information to minimizes
> the impact of non-routing information flooding on the routing convergence
> and stability, We submitted a new IS-IS flooding mechanism implemented in
> the zero IS-IS instance, named as IS-IS Multi-flooding Instances (MFIs).
> 
>  An encoding format for IS-IS MFI-ID TLV and MFIs Update Process defined in
> this draft could be found in https://datatracker.ietf.org/doc/draft-wang-lsr-
> isis-mfi/ .
> 
> To: Aijun Wang <[email-masked]>; Tianran Zhou
> <[email-masked]>; wangyali <[email-masked]>; Huzhibo
> <[email-masked]>
> A new version of I-D, draft-wang-lsr-isis-mfi-00.txt has been successfully
> submitted by Yali Wang and posted to the IETF repository.
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
>

---

From: wangyali <[email-masked]>
Date: Thu, 25 Feb 2021 05:24:19 +0000

Hi Tony,

Thanks for your questions and comments. Please see inline >>Yali.

Best regards,
Yali

-----Original Message-----
From: Tony Li [mailto:[email-masked]] On Behalf Of Tony Li
Sent: Wednesday, February 24, 2021 6:08 AM
To: wangyali <[email-masked]>
Cc: [email-masked]; Huzhibo <[email-masked]>; Aijun Wang <[email-masked]>; Tianran Zhou <[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Hi,

>>Yali: The ‘multi-flooding instance' means that multiple Update process are allowed operating within the zero IS-IS instance. Each Update process is associated with a topology and a LSDB. Flooding parameters of each Update process can be different and customized based on different information needed to be advertised in the associated Flooding Instance. 
Although each Flooding Instance has its own separate Update process, flooding topology and LSDB, these multiple flooding instances share a common adjacencies.

>>Yali: Because different information advertisements are categorized into different MFI, so an LSP in MFI A and another LSP in MFI B have different flooding topology, flooding parameters, and prioritization for processing LSP. 
Each flooding instance is associated with a MFI-specific LSDB, which is trying to subdivide the LSDB.

>>Yali: As mentioned in draft, the each flooding instance support one update process operation on a LSDB.

>>Yali: The problem we are trying to solve is how to isolate application information flooding from the routing information flooding through multiple flooding instance.

Regards,
Tony

---

From: wangyali <[email-masked]>
Date: Thu, 25 Feb 2021 06:39:25 +0000

Hi Les,

Many thanks for your reply. 
Please find inline >>Yali.

Best regards,
Yali

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Wednesday, February 24, 2021 11:54 AM
To: wangyali <[email-masked]>; [email-masked]
Cc: Huzhibo <[email-masked]>; Aijun Wang <[email-masked]>; Tianran Zhou <[email-masked]>
Subject: RE: New Version Notification for draft-wang-lsr-isis-mfi-00.txt

>>Yali: The advertisement of application information using IS-IS has been defined in RFC6823.  The MFI mechanism as specified in our draft can be applicable to the advertisement of both routing information and application information. Each MFI is associated with a Update process and a MFI-specific LSDB, which support isolation of application information flooding from the routing information flooding.

>>Yali: The purpose of RFC 8202 is to allow multiple IS-IS protocol instances operate on the same circuit, and each instance will form its own adjacency. While the MFI mechanism is to provide multiple separate update process within a single protocol instance, each Update process can be associated with a flooding topology and a LSDB, and the flooding parameters of each Update process can be different and customized based on different information needed to be advertised in the associated Flooding Instance.
These are significant differences to RFC8202 and RFC6823.

   Les

> In order to separate multiple flooding instances for dissemination of 
> routing information and other types of application-specific 
> information to minimizes the impact of non-routing information 
> flooding on the routing convergence and stability, We submitted a new 
> IS-IS flooding mechanism implemented in the zero IS-IS instance, named as IS-IS Multi-flooding Instances (MFIs).
> 
>  An encoding format for IS-IS MFI-ID TLV and MFIs Update Process 
> defined in this draft could be found in 
> https://datatracker.ietf.org/doc/draft-wang-lsr-
> isis-mfi/ .
> 
> A new version of I-D, draft-wang-lsr-isis-mfi-00.txt has been 
> successfully submitted by Yali Wang and posted to the IETF repository.
> 
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
>

---

From: Tony Li <[email-masked]>
Date: Thu, 25 Feb 2021 08:45:47 -0800

Hi Yali,

Thank you for your reply. More comments...

> Although each Flooding Instance has its own separate Update process, flooding topology and LSDB, these multiple flooding instances share a common adjacencies.

Again, I think that any comment about implementation internals is irrelevant, and thus the existence of a process is irrelevant.  If I’m understanding you, each MFI has an independent topology and LSDB. This is true with the current multi-instance document. Where you seem to differ is in having common adjacencies. To me, this implies that the topologies may overlap.  Is this correct?

Have you considered using link level partitioning (e.g., VLANs) and just using multi-instance?

>>> Yali: The problem we are trying to solve is how to isolate application information flooding from the routing information flooding through multiple flooding instance.

If this was precise, then the existing multi-instance mechanism would be sufficient.

Tony

---

From: wangyali <[email-masked]>
Date: Fri, 26 Feb 2021 10:01:18 +0000

Hi Tony,

Glad to receive your more comments. Please see my reply inline [Yali].

-----Original Message-----
From: Tony Li [mailto:[email-masked]] On Behalf Of Tony Li
Sent: Friday, February 26, 2021 12:46 AM
To: wangyali <[email-masked]>
Cc: [email-masked]; Huzhibo <[email-masked]>; Tianran Zhou <[email-masked]>; Aijun Wang <[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Hi Yali,

Again, I think that any comment about implementation internals is irrelevant, and thus the existence of a process is irrelevant.  If I’m understanding you, each MFI has an independent topology and LSDB. This is true with the current multi-instance document. Where you seem to differ is in having common adjacencies. To me, this implies that the topologies may overlap.  Is this correct?
[Yali]: Yes. If I understand the meaning of overlap you said. The flooding topology of MFI #0 and the flooding topology of MFI #1 may overlap. For example, as shown in the following simple topology, MFI #0 is reserved for the routing information flooding in a full topology which is used for routing calculation. And other MFI #1 is used for non-routing information flooding in a sub-topology (on the Link 1 and Link 2) or the full topology. 

                    Node A                                                                                      Node B
=====================                                           =====================            
|           IS-IS Instance 0          |                                           |         IS-IS Instance 0           |
|                                                    |                  Link 1             |                                                   |
|                  MFI #0                    |****************|                   MFI #0                  |
|                  MFI #1                    |                                           |                   MFI #1                 |
=====================                                            =====================
                                 *                                                                                          *
		    *                                                                                   *
		      *                                                                             *
	         Link 2    *                                                                        *  Link 3
		           *                                                                  *
	                              *                                                           *
                                                  *                  Node C                 *
                                                  =====================
                                                 |          IS-IS Instance 0           |
                                                 |                                                    |
                                                 |                  MFI #0                    |
			 |                  MFI #1                    |
			 =====================

Have you considered using link level partitioning (e.g., VLANs) and just using multi-instance?
[Yali]: From our consideration, MFIs specified in this document are not partitioned at link level. As shown in above figure, two MFIs can operate on the same link (e.g., Link 1) between two neighbors A and B. while the priority, flooding parameters and the flooding topology of each MFI can be customized. In this way, the deployment is simpler and cost of adjacencies maintenance is lower.

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. 

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 26 Feb 2021 11:59:57 +0100

Hi Yali,

> [Yali]: MFI is a different solution we recommend to solve this same and

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.

---

From: Aijun Wang <[email-masked]>
Date: Fri, 26 Feb 2021 19:44:14 +0800

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]> wrote:
> 
> 
> Hi Yali,
>  
> 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

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 26 Feb 2021 13:09:46 +0100

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

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 26 Feb 2021 11:19:14 -0500

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

-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

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

---

From: Peter Psenak <[email-masked]>
Date: Sun, 28 Feb 2021 13:23:26 +0100

Gyan,

On 26/02/2021 17:19, Gyan Mishra wrote:
> 
> MFI seems more like flex algo with multiple sub topologies sharing a 
> common links in a  topology where RFC 8202 MI is separated at the 
> process level separate LSDB.  So completely different and of course 
> different goals and use cases for MI versus MFI.

I would not use the fle-algo analogy - all flex-algos operate on top of 
a single LSDB, contrary to what is being proposed in MFI draft.

> 
>   MFI also seems to be a flood reduction mechanism by creating multiple 
> sub topology instances within a common LSDB.  There are a number of 
> flood reduction drafts and this seems to be another method of achieving 
> the same.

MFI draft proposes to keep the separate LSDB per MFI, so the above 
analogy is not correct either.

thanks,
Peter

> 
> Gyan
> 
> On Fri, Feb 26, 2021 at 7:10 AM Robert Raszuk <[email-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.
> 
>     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,
>>
>>         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]>
> /Network Solutions A//rchitect /
> 
> /M 301 502-1347
> 13101 Columbia Pike
> /Silver Spring, MD
> 
>

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 28 Feb 2021 09:44:12 -0500

Peter

> a single LSDB, contrary to what is being proposed in MFI draft.

   Gyan>. Thanks for clarification

> analogy is not correct either.

Gyan> Thanks for clarification

*Gyan Mishra*