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

Peter Psenak <ppsenak@cisco.com> Fri, 05 March 2021 15:28 UTC

Return-Path: <ppsenak@cisco.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 DDE363A26B6 for <lsr@ietfa.amsl.com>; Fri, 5 Mar 2021 07:28:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.902
X-Spam-Level:
X-Spam-Status: No, score=-11.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 XGuXkakmT-D0 for <lsr@ietfa.amsl.com>; Fri, 5 Mar 2021 07:28:32 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD2C63A26B5 for <lsr@ietf.org>; Fri, 5 Mar 2021 07:28:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10974; q=dns/txt; s=iport; t=1614958112; x=1616167712; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=0IQPEveA7UDJwZvhLYbsKkbee75IRJYl02VvGIgMmY8=; b=ejQl6QY041Ootg2DlHEfirFX28hfy0N/4obsY10K5N81m2iZzYqJAqZo QmR2KniTXwl+UOAzyI+HnnqRSxdrYkISCaavFxF+tmeand0Tsc8cIYTaZ 6Kkl6LJoWmEJ7Z/mqUErkdegeV8j+ZhwEsC05ddHkvw6e8L1vEP+WNXru c=;
X-IPAS-Result: =?us-ascii?q?A0C2AADhTEJg/xbLJq1fAxkBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QESAQEBAQEBAQEBAQEBQIFPgXaBK1YBJxIxhEGJBIgqLQOBBYkhhHeNMAsBA?= =?us-ascii?q?QEPHQsMBAEBhE0CgXsmOBMCAwEBAQMCAwEBAQEFAQEBAgEGBHGFYQ2GRAEBA?= =?us-ascii?q?QMBAQEhDwEFLwcJAgwECwcKBAEBAQICIwMCAiEGHwkIBgEMBgIBAReCVQGCV?= =?us-ascii?q?QMOIQ+tCnaBMoVYglgNYoFFgQ8qiAqBRoJDgS8WLIFJQoEQASeBdUk1PoIaQ?= =?us-ascii?q?gEBgTdKBSGCT4JfBIJGAWMEQw8BIC8MIAoTLAgRDBoPKCoQkAoEHjiCOYg7i?= =?us-ascii?q?0KRXFuDCIMvk0uCN4JpBQcDH4M5ilGFUo1Cgk6UXYILjDyPDgQPhG2BayOBV?= =?us-ascii?q?zMaCBsVO4JpCUcZDYhJiUWDRoFOhUZAAy84AgYBCQEBAwmMYoJEAQE?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,225,1610409600"; d="scan'208";a="31513148"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Mar 2021 15:28:29 +0000
Received: from [10.60.140.52] (ams-ppsenak-nitro3.cisco.com [10.60.140.52]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id 125FSSMm010564; Fri, 5 Mar 2021 15:28:29 GMT
To: wangyali <wangyali11@huawei.com>, Gyan Mishra <hayabusagsm@gmail.com>, Robert Raszuk <robert@raszuk.net>
Cc: Huzhibo <huzhibo@huawei.com>, Aijun Wang <wangaj3@chinatelecom.cn>, Tony Li <tony.li@tony.li>, lsr <lsr@ietf.org>, Tianran Zhou <zhoutianran@huawei.com>
References: <CAOj+MMHsDgfD8avbRtvthhd0=c-X25L9HBc0yQTby4vFQKECLQ@mail.gmail.com> <7D53A65F-7375-43BC-9C4E-2EDCF8E138C8@chinatelecom.cn> <CAOj+MMEAJdqvmhfpVEc+M+v_GJ92hmjggbDWr3=gSAM4y3HkYg@mail.gmail.com> <CABNhwV1EBsej6b-++Ne2OpwMb6DMb9dubjf=M1LrOEHjn4MWmA@mail.gmail.com> <57f50a96-4476-2dc7-ad11-93d5e418f774@cisco.com> <1520992FC97B944A9979C2FC1D7DB0F405242279@dggeml524-mbx.china.huawei.com> <26f29385-eedd-444b-ce02-17facf029bd2@cisco.com> <1520992FC97B944A9979C2FC1D7DB0F4052483BC@dggeml524-mbx.china.huawei.com> <9013a79f-0db9-5ec3-5bfd-8f1ab32644d3@cisco.com> <1520992FC97B944A9979C2FC1D7DB0F40525E441@DGGEML504-MBS.china.huawei.com> <e0bfca37-d9ca-2a06-4fe9-1e6fa3374f45@cisco.com> <1520992FC97B944A9979C2FC1D7DB0F40525E4FF@DGGEML504-MBS.china.huawei.com> <45db4eee-55cf-f09e-1db3-83c30e434213@cisco.com> <1520992FC97B944A9979C2FC1D7DB0F405262C4E@DGGEML504-MBS.china.huawei.com>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <ada0ec9f-a0b5-0f32-dee1-2ff4cfc70013@cisco.com>
Date: Fri, 5 Mar 2021 16:28:28 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <1520992FC97B944A9979C2FC1D7DB0F405262C4E@DGGEML504-MBS.china.huawei.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.60.140.52, ams-ppsenak-nitro3.cisco.com
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Uh2VTEkiz81GsaEcoKHDTYk7xiQ>
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: Fri, 05 Mar 2021 15:28:35 -0000

Hi Yali,

On 05/03/2021 15:31, wangyali wrote:
> Hi Peter,
> 
> Thanks for your question. Please see inline [yali3].
> 
> -----Original Message-----
> From: Peter Psenak [mailto:ppsenak@cisco.com]
> Sent: Thursday, March 4, 2021 11:20 PM
> To: wangyali <wangyali11@huawei.com>om>; Gyan Mishra <hayabusagsm@gmail.com>om>; Robert Raszuk <robert@raszuk.net>
> Cc: Huzhibo <huzhibo@huawei.com>om>; Aijun Wang <wangaj3@chinatelecom.cn>cn>; Tony Li <tony.li@tony.li>li>; lsr <lsr@ietf.org>rg>; Tianran Zhou <zhoutianran@huawei.com>
> Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt
> 
> Hi Yali,
> 
> On 04/03/2021 14:45, wangyali wrote:
>> Hi Peter,
>>
>> Please see inline [Yali2]. Thanks a lot.
>>
>> -----Original Message-----
>> From: Peter Psenak [mailto:ppsenak@cisco.com]
>> Sent: Thursday, March 4, 2021 6:50 PM
>> To: wangyali <wangyali11@huawei.com>om>; Gyan Mishra
>> <hayabusagsm@gmail.com>om>; Robert Raszuk <robert@raszuk.net>
>> Cc: Huzhibo <huzhibo@huawei.com>om>; Aijun Wang
>> <wangaj3@chinatelecom.cn>cn>; Tony Li <tony.li@tony.li>li>; lsr
>> <lsr@ietf.org>rg>; Tianran Zhou <zhoutianran@huawei.com>
>> Subject: Re: [Lsr] New Version Notification for
>> draft-wang-lsr-isis-mfi-00.txt
>>
>> Hi Yali,
>>
>> On 04/03/2021 11:42, wangyali wrote:
>>> Hi Peter,
>>>
>>> Please review follows tagged by [Yali].
>>>
>>>
>>> -----Original Message-----
>>> From: Peter Psenak [mailto:ppsenak@cisco.com]
>>> Sent: Wednesday, March 3, 2021 5:37 PM
>>> To: wangyali <wangyali11@huawei.com>om>; Gyan Mishra
>>> <hayabusagsm@gmail.com>om>; Robert Raszuk <robert@raszuk.net>
>>> Cc: Huzhibo <huzhibo@huawei.com>om>; Aijun Wang
>>> <wangaj3@chinatelecom.cn>cn>; Tony Li <tony.li@tony.li>li>; lsr
>>> <lsr@ietf.org>rg>; Tianran Zhou <zhoutianran@huawei.com>
>>> Subject: Re: [Lsr] New Version Notification for
>>> draft-wang-lsr-isis-mfi-00.txt
>>>
>>> Yali,
>>>
>>> On 03/03/2021 06:02, wangyali wrote:
>>>> Hi Peter,
>>>>
>>>> Thanks for your comments. Yes. I am improving this sentence. Please review the following update.
>>>>
>>>> OLD: " And Level 1/Level 2 PSNP and Level 1/Level 2 CSNP containing information about LSPs that transmitted in a specific MFI are generated to synchronize the LSDB corresponding to the specific MFI."
>>>>
>>>> NEW: "And Level 1/Level 2 PSNP and Level 1/Level 2 CSNP containing information about LSPs that transmitted in a specific MFI are generated to synchronize the MFI-specific sub-LSDB. Each MFI-specific sub-LSDB is subdivided from a single LSDB."
>>>
>>> please specify sub-LSDB.
>>> [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.

- 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


> 
> thanks,
> Peter
> 
> 
> 
> 
>>
>> thanks,
>> Peter
>>
>>>
>>> thanks,
>>> Peter
>>>
>>>
>>>>
>>>> Best,
>>>> Yali
>>>>
>>>> -----Original Message-----
>>>> From: Peter Psenak [mailto:ppsenak@cisco.com]
>>>> Sent: Tuesday, March 2, 2021 5:12 PM
>>>> To: wangyali <wangyali11@huawei.com>om>; Gyan Mishra
>>>> <hayabusagsm@gmail.com>om>; Robert Raszuk <robert@raszuk.net>
>>>> Cc: Huzhibo <huzhibo@huawei.com>om>; Aijun Wang
>>>> <wangaj3@chinatelecom.cn>cn>; Tony Li <tony.li@tony.li>li>; lsr
>>>> <lsr@ietf.org>rg>; Tianran Zhou <zhoutianran@huawei.com>
>>>> Subject: Re: [Lsr] New Version Notification for
>>>> draft-wang-lsr-isis-mfi-00.txt
>>>>
>>>> Yali,
>>>>
>>>> On 01/03/2021 10:49, wangyali wrote:
>>>>> Hi Peter,
>>>>>
>>>>> Many thanks for your feedback. First of all, I'm sorry for the confusion I had caused you from my previous misunderstanding.
>>>>>
>>>>> And I want to clarify that a single and common LSDB is shared by all MFIs.
>>>>
>>>> well, the draft says:
>>>>
>>>> "information about LSPs that transmitted in a
>>>>       specific MFI are generated to synchronize the LSDB corresponding to
>>>>       the specific MFI."
>>>>
>>>> If the above has changed, then please update the draft accordingly.
>>>>
>>>> thanks,
>>>> Peter
>>>>
>>>>
>>>>
>>>>>
>>>>> Best,
>>>>> Yali
>>>>>
>>>>> -----Original Message-----
>>>>> From: Peter Psenak [mailto:ppsenak@cisco.com]
>>>>> Sent: Sunday, February 28, 2021 8:23 PM
>>>>> To: Gyan Mishra <hayabusagsm@gmail.com>om>; Robert Raszuk
>>>>> <robert@raszuk.net>
>>>>> Cc: Huzhibo <huzhibo@huawei.com>om>; Aijun Wang
>>>>> <wangaj3@chinatelecom.cn>cn>; Tony Li <tony.li@tony.li>li>; lsr
>>>>> <lsr@ietf.org>rg>; Tianran Zhou <zhoutianran@huawei.com>om>; wangyali
>>>>> <wangyali11@huawei.com>
>>>>> Subject: Re: [Lsr] New Version Notification for
>>>>> draft-wang-lsr-isis-mfi-00.txt
>>>>>
>>>>> Gyan,
>>>>>
>>>>> On 26/02/2021 17:19, Gyan Mishra wrote:
>>>>>>
>>>>>> MFI seems more like flex algo with multiple sub topologies sharing
>>>>>> a common links in a  topology where RFC 8202 MI is separated at
>>>>>> the process level separate LSDB.  So completely different and of
>>>>>> course different goals and use cases for MI versus MFI.
>>>>>
>>>>> I would not use the fle-algo analogy - all flex-algos operate on top of a single LSDB, contrary to what is being proposed in MFI draft.
>>>>>
>>>>>>
>>>>>>        MFI also seems to be a flood reduction mechanism by creating
>>>>>> multiple sub topology instances within a common LSDB.  There are a
>>>>>> number of flood reduction drafts and this seems to be another
>>>>>> method of achieving the same.
>>>>>
>>>>> MFI draft proposes to keep the separate LSDB per MFI, so the above analogy is not correct either.
>>>>>
>>>>> thanks,
>>>>> Peter
>>>>>
>>>>>
>>>>>>
>>>>>> Gyan
>>>>>>
>>>>>> On Fri, Feb 26, 2021 at 7:10 AM Robert Raszuk <robert@raszuk.net
>>>>>> <mailto:robert@raszuk.net>> 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 <wangaj3@chinatelecom.cn
>>>>>>          <mailto:wangaj3@chinatelecom.cn>> 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 <robert@raszuk.net
>>>>>>>              <mailto:robert@raszuk.net>> 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
>>>>>>>              Lsr@ietf.org <mailto:Lsr@ietf.org>
>>>>>>>              https://www.ietf.org/mailman/listinfo/lsr
>>>>>>
>>>>>>          _______________________________________________
>>>>>>          Lsr mailing list
>>>>>>          Lsr@ietf.org <mailto:Lsr@ietf.org>
>>>>>>          https://www.ietf.org/mailman/listinfo/lsr
>>>>>>
>>>>>> --
>>>>>>
>>>>>> <http://www.verizon.com/>
>>>>>>
>>>>>> *Gyan Mishra*
>>>>>>
>>>>>> /Network Solutions A//rchitect /
>>>>>>
>>>>>> /M 301 502-1347
>>>>>> 13101 Columbia Pike
>>>>>> /Silver Spring, MD
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
> 
> 
>