IETF Logo Mail Archive

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

Gyan Mishra <hayabusagsm@gmail.com> Fri, 26 February 2021 16:20 UTC

Return-Path: <hayabusagsm@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 A3F363A0ED3 for <lsr@ietfa.amsl.com>; Fri, 26 Feb 2021 08:20:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 psMH3hugDFQy for <lsr@ietfa.amsl.com>; Fri, 26 Feb 2021 08:20:08 -0800 (PST)
Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 BDF2E3A1173 for <lsr@ietf.org>; Fri, 26 Feb 2021 08:19:25 -0800 (PST)
Received: by mail-pg1-x52e.google.com with SMTP id h4so6461246pgf.13 for <lsr@ietf.org>; Fri, 26 Feb 2021 08:19:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T+MMq1FOv7nQG/FK/GC5fwkGpWQ5R7in+xN0DEdEuXs=; b=Ck5jPgCwAkqK7UUZvy7s6DT72umQ+8+DquaZHHtGZ8pYbgrKUKA3RNQYYV8415hU1x qF589G8Iyeg9U3LrnDuB/TQfN11KSUdCfO5AxuecwFL+0bJ/NdJMDV2uExBT4n2MLoHz n/rOabSq+9A95mjH6F3JY54vyds3P528as9vWSnxDBU8i19I9rab0JpIiUjJNHL53qJS wJWgOY65zA1CnWq2zYlmgNTf/cJy0viUTVBfNmmKW82G7A5s3J/BW4jlRHOvPZwyg7Ds V0X7xbbeUtz/Kv4dOgPwauXA81Got/AykFf0qY5qWCTGoffD0FyCgHonLFQTsO4ja+kj s1Dg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=T+MMq1FOv7nQG/FK/GC5fwkGpWQ5R7in+xN0DEdEuXs=; b=YCcQ1A8avh2OxkO0z29mjm2YoeMqUfWwWXi6FFeJ5v9qpHURn01rHl2bo9NFQZrR4s eiUdCT76jtVmFioB2clO6hBbEwyD3H9L8tlJBfZtWMi9UlLbNJ5yn00HGhodtUvb1lFV ajn6ktg/tryB0pd8615Vxu+zmU6kbO5YHOYSwiDUkjfQNEjKKONf+LdjZiOdwR/s+yjA jQpQLedhNYdGlCf8QDMjCka++fzoD02V1Qybd+k9YwrCJw8lDBHcuyc+h1KnesMwc0bL uJgZRYOop6ZcdtcC7wanK2bpbxtoNeedyoD25QgIyLvShjV/q2DuOLXSsJpGKqcId4GD ae2g==
X-Gm-Message-State: AOAM532wkXBwsPmvpUDDSzBBtUv+gri5zbnEG8SKQYebELgqFi4/JUzo teY85QG93Ypw6LgLqS+hsRxEygglotn1jXHtTDo=
X-Google-Smtp-Source: ABdhPJzdoJcQxqs5KuZ+hwJ9id5bmftTfkbv7fLg9RXEFHQjcCFx8M6N0KNy9880R5gZxK299ZsQfIRiYcNcRZAFBAE=
X-Received: by 2002:a65:62c7:: with SMTP id m7mr3560677pgv.50.1614356365033; Fri, 26 Feb 2021 08:19:25 -0800 (PST)
MIME-Version: 1.0
References: <CAOj+MMHsDgfD8avbRtvthhd0=c-X25L9HBc0yQTby4vFQKECLQ@mail.gmail.com> <7D53A65F-7375-43BC-9C4E-2EDCF8E138C8@chinatelecom.cn> <CAOj+MMEAJdqvmhfpVEc+M+v_GJ92hmjggbDWr3=gSAM4y3HkYg@mail.gmail.com>
In-Reply-To: <CAOj+MMEAJdqvmhfpVEc+M+v_GJ92hmjggbDWr3=gSAM4y3HkYg@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Fri, 26 Feb 2021 11:19:14 -0500
Message-ID: <CABNhwV1EBsej6b-++Ne2OpwMb6DMb9dubjf=M1LrOEHjn4MWmA@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: Aijun Wang <wangaj3@chinatelecom.cn>, Huzhibo <huzhibo@huawei.com>, Tianran Zhou <zhoutianran@huawei.com>, Tony Li <tony.li@tony.li>, lsr <lsr@ietf.org>, wangyali <wangyali11@huawei.com>
Content-Type: multipart/alternative; boundary="000000000000adc39005bc3fa1a0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/RQNOBJ9RwYD2SlceOKxPAtK-haE>
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, 26 Feb 2021 16:20:13 -0000

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 <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>
> 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> 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
>> https://www.ietf.org/mailman/listinfo/lsr
>>
>> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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

v2.23.0 | Report a Bug | By Email