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

Tony Li <tony.li@tony.li> Mon, 01 March 2021 18:01 UTC

Return-Path: <tony1athome@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDD73A2081 for <lsr@ietfa.amsl.com>; Mon, 1 Mar 2021 10:01:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3BEmnpfLAWx for <lsr@ietfa.amsl.com>; Mon, 1 Mar 2021 10:00:58 -0800 (PST)
Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BC2A3A203F for <lsr@ietf.org>; Mon, 1 Mar 2021 10:00:58 -0800 (PST)
Received: by mail-pg1-x534.google.com with SMTP id h4so12053797pgf.13 for <lsr@ietf.org>; Mon, 01 Mar 2021 10:00:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sEHCUcsdd+MTjaEMVVLx59WW5l0Q8k+AfsTctCA17RE=; b=jX2mt97j3IA0aqOK32YlJ4TmqZH9lbX+IGdrfDiyo27HhoDkvSM6otCoTTF9K77wUO bcH/rmgTuUNzpPsiKX56R57wB5EG+ob2lhnjUYuk/oEfTzGoIAXnM9gmZ0g1S4K+Mw8X EfLDrBjiw3SjhBUcQRLWmXhuOzzy1elXP4IdBqyUgZaq7jUbAhVWFRZsDz4ZqPJdaa45 HpsLOwbVzoZyhOP2IjdNpkbP34bPFFRBWi85+m+TrM4L9yRLFmfrvGl//gz12f7FUjKW sCQ7X7yCK+qGYW6i9OWPXqGMakJMKJu6Ly7ggiC5gUgq3Zo2eDOyZxKT8vurSxFBwUBa pLuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=sEHCUcsdd+MTjaEMVVLx59WW5l0Q8k+AfsTctCA17RE=; b=EWg9Crrb0AAdjPn4xhO/SsGT5dgoWIKrU8UOXB4XHDetDeaM3nuFsX9aOoLrgBubJs Hv4P3pRErf+cin/Qf8BtXSMwMXAJgobTfwSKtnH91i/yDOPETtAIvU0Q6Qt3DyfW99j9 csTlFhAptFBbRbuct+nvtYnWZfTDdhgyFChyUQvTPPkjko6HFxIMh2RAWvKDuTlfmHOc ue4CsDTpd5eDcwx+HZSx9e4jFFULF5oYd6J5BCY+X4uX+L2qGByOvp+RlW9C5whnCvtG 3ooCGmvvFIObSY1AtlWRuRpQSjpKJIzaAjD1w6ygFMex4RM6Y5ktIonuRK1twUo5TtEV OqOA==
X-Gm-Message-State: AOAM533+F6PwaD1zw06NCGnmtnfZ7xJmyrzbNKr/XG7sUZxkAKfZ0jKW ptk0gO7++7D5C2suRJjGDg4=
X-Google-Smtp-Source: ABdhPJwCRszL6Dq/Jc40Mq/q5b/Tdw60sTgWu5sW0Kr2YkQF3K6xnF/Spl85StzxizSu1cOSxxy0aQ==
X-Received: by 2002:a63:2254:: with SMTP id t20mr14548892pgm.230.1614621657742; Mon, 01 Mar 2021 10:00:57 -0800 (PST)
Received: from [192.168.4.41] (c-67-169-103-239.hsd1.ca.comcast.net. [67.169.103.239]) by smtp.gmail.com with ESMTPSA id r123sm18335007pfc.211.2021.03.01.10.00.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Mar 2021 10:00:57 -0800 (PST)
Sender: Tony Li <tony1athome@gmail.com>
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\))
From: Tony Li <tony.li@tony.li>
In-Reply-To: <1520992FC97B944A9979C2FC1D7DB0F405242205@dggeml524-mbx.china.huawei.com>
Date: Mon, 1 Mar 2021 10:00:55 -0800
Cc: "lsr@ietf.org" <lsr@ietf.org>, Huzhibo <huzhibo@huawei.com>, Aijun Wang <wangaj3@chinatelecom.cn>, Tianran Zhou <zhoutianran@huawei.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7AAFA2F0-3854-46F4-8DA5-B92F4D3137CD@tony.li>
References: <161395912869.30720.11972345048767444266@ietfa.amsl.com> <1520992FC97B944A9979C2FC1D7DB0F40523C170@dggeml524-mbx.china.huawei.com> <4A2A7EDC-8525-4317-972B-7D6CE98275F8@tony.li> <1520992FC97B944A9979C2FC1D7DB0F40523F0FD@dggeml524-mbx.china.huawei.com> <1520992FC97B944A9979C2FC1D7DB0F405242205@dggeml524-mbx.china.huawei.com>
To: wangyali <wangyali11@huawei.com>
X-Mailer: Apple Mail (2.3654.40.0.2.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/GnJdjg1m_cMDKvP_WBRus5fnQDc>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Mar 2021 18:01:01 -0000

Hi Yali,

Thank you for the clarification.  Yes, ok, that then suggests that MFI is simply a way to partition flooding.

I’m still missing out on the motivation for doing this.  What is the benefit of having some data take one flooding path and other data take another flooding path? Since all nodes are going to end up synchronized sooner or later, how is this better?

Tony




> On Mar 1, 2021, at 1:05 AM, wangyali <wangyali11@huawei.com> wrote:
> 
> Hi Tony,
> 
> First of all, I'm sorry I misunderstood your question in previous mail. My understanding of the 'subdivide the LSDB' in your question that ' Are there separate flooding topologies but a common LSDB? Or are you trying to subdivide the LSDB?' is subdividing a single LSDB for each MFI. 
> 
> Hence in the previous mail I said that '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.' Hence, I'm trying to say each Update process associated with a MFI operates on a logically subdivided LSDB.
> 
> Therefore I clarify that 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
> 
> -----Original Message-----
> From: wangyali 
> Sent: Thursday, February 25, 2021 1:24 PM
> To: Tony Li <tony.li@tony.li>
> Cc: lsr@ietf.org; Huzhibo <huzhibo@huawei.com>om>; Aijun Wang <wangaj3@chinatelecom.cn>cn>; Tianran Zhou <zhoutianran@huawei.com>
> Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt
> 
> Hi Tony,
> 
> Thanks for your questions and comments. Please see inline >>Yali.
> 
> Best regards,
> Yali
> 
> -----Original Message-----
> From: Tony Li [mailto:tony1athome@gmail.com] On Behalf Of Tony Li
> Sent: Wednesday, February 24, 2021 6:08 AM
> To: wangyali <wangyali11@huawei.com>
> Cc: lsr@ietf.org; Huzhibo <huzhibo@huawei.com>om>; Aijun Wang <wangaj3@chinatelecom.cn>cn>; Tianran Zhou <zhoutianran@huawei.com>
> Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt
> 
> 
> 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.
>>> 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.
> 
> 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?
>>> 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.
> 
> 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.
>>> Yali: As mentioned in draft, the each flooding instance support one update process operation on a LSDB.
> 
> What problem are you solving?
>>> 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
> 
> 
> 
>> On Feb 22, 2021, at 11:10 PM, wangyali <wangyali11@huawei.com> 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 https://datatracker.ietf.org/doc/draft-wang-lsr-isis-mfi/ .
>> 
>> Any questions and comments are welcome.
>> 
>> Thanks,
>> Yali
>> 
>> -----Original Message-----
>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>> Sent: Monday, February 22, 2021 9:59 AM
>> To: Aijun Wang <wangaj3@chinatelecom.cn>cn>; Tianran Zhou 
>> <zhoutianran@huawei.com>om>; wangyali <wangyali11@huawei.com>om>; Huzhibo 
>> <huzhibo@huawei.com>
>> 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
>> 
>> 
>> _______________________________________________
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>