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

Tony Li <> Tue, 23 February 2021 22:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F84A3A0D39 for <>; Tue, 23 Feb 2021 14:07:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3Lkd9sEQz4dP for <>; Tue, 23 Feb 2021 14:07:43 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1BA453A0D50 for <>; Tue, 23 Feb 2021 14:07:42 -0800 (PST)
Received: by with SMTP id z5so6529298pfe.3 for <>; Tue, 23 Feb 2021 14:07:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WVu4LPg9xlKmWTN49mNgGJdRSXJK0D7Ys209haKAscQ=; b=D78Kp+wQDkANA4NTkMYcGbO5sXuveSOezIA31ml/jXciYT8ellTJ8MZqcpYcRo68+U Y0IgXGeoHQGoyEPpYDVbGpG91aZdEPurLCTonKwStwralU3oA9c/rqBXzz6up5QuBCFf ty4ZesvvhZNqgS1NMCO4TUaQDUJ/H8ishd+mk0I53jrU7VrXPYxfHh9GrgIMzgB986VG QyWQYcTN7YGpj4VEqfZq+njQX0bt4FWo8abQPk5rfmQv7iGiJC7/5ATdW5/0B20i1rzM QsyAnKEgJX1fepa+k37RzEzFJmUUH0t9Xix9g7ciSA63Q+L60amVuCf2jbhr4mjpxtAC RXTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=WVu4LPg9xlKmWTN49mNgGJdRSXJK0D7Ys209haKAscQ=; b=XI4SHB52nBMAirYHE9rLUdAeLPzfKVMLw1p+N6ppxIm6W3R1YSaG8bGThcXKvThKvx pTEI3mGi6GzBLlAsDr2IzS/AykKqQ7t6Z3UlmzRdDtWEexDUXd8LN3tliZTMmZ47BX6N I5ZsyCCDwEkDkVbHtsEVIhKmxUe+sRV9qcXHMwiRXZ425wsu+wYWT+K6Igyem1kEjgoj BSQtCqk2bcuERKdhmUWxP20qD7rOEmKHa0WeOLBvZqmEhQNEyOLDuAgFTQItHwsaGXqa h+KAhyExXaf+pRnpJllcO6t9j0OOKEfwkk8DfpH0EkvtYvOesE6KHV9JgjGqZzBpathp 0cdA==
X-Gm-Message-State: AOAM531J9b5lPLab6MFB3mNg4Nttncz9/cqYB1b20eWmEf6UmFX9u1Sj 23dAzNhEd+64IUiPUrJ1M6kw1Fa4RWs=
X-Google-Smtp-Source: ABdhPJwWXZAgxt++6f09Rceptbdb3PEKJqSBLtY6SmKG6b4OOrG3klUiIGzNOL2j970K8cbxdr8oqA==
X-Received: by 2002:a63:d118:: with SMTP id k24mr7909386pgg.420.1614118062262; Tue, 23 Feb 2021 14:07:42 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id y68sm17333781pgy.5.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Feb 2021 14:07:41 -0800 (PST)
Sender: Tony Li <>
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Tony Li <>
In-Reply-To: <>
Date: Tue, 23 Feb 2021 14:07:39 -0800
Cc: "" <>, Huzhibo <>, Aijun Wang <>, Tianran Zhou <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: wangyali <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Feb 2021 22:07:45 -0000


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?


> On Feb 22, 2021, at 11:10 PM, wangyali <> wrote:
> 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 .
> Any questions and comments are welcome.
> Thanks,
> Yali
> -----Original Message-----
> From: [] 
> Sent: Monday, February 22, 2021 9:59 AM
> To: Aijun Wang <>cn>; Tianran Zhou <>om>; wangyali <>om>; Huzhibo <>
> 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:  
> Status:
> Htmlized:
> Htmlized:
> 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
> The IETF Secretariat
> _______________________________________________
> Lsr mailing list