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

Tony Przygienda <tonysietf@gmail.com> Tue, 09 March 2021 20:24 UTC

Return-Path: <tonysietf@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 22C7B3A0AAF for <lsr@ietfa.amsl.com>; Tue, 9 Mar 2021 12:24:07 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 DF6fGHZk0YUv for <lsr@ietfa.amsl.com>; Tue, 9 Mar 2021 12:24:02 -0800 (PST)
Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 E60503A0A9F for <lsr@ietf.org>; Tue, 9 Mar 2021 12:24:01 -0800 (PST)
Received: by mail-il1-x134.google.com with SMTP id g9so13386442ilc.3 for <lsr@ietf.org>; Tue, 09 Mar 2021 12:24:01 -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=JDcp8/Fg3jRx+lFWfVDJKmWUcRx0jx2P/+LRTsF0B7A=; b=YU0oJXu3vitYtVXRD/k1etLIBQ9z9NsRkQpexHtSmyAy5jWwfOeCpomto52pmD6IIt ccewGV1qyWBJcQew8WTYd8/zY6eJ0pZ1/OVLAmSUfV390QKyjmcVM6ahANZ0U+zaKwbz th7TkztXCSwoptAVAIGWSLgQyRZ2Ku3/3S5gocuKeTxZVjnLuKMFdnaffm0NW9t4UAPn +J/0eglW5utBxU0HRK6rBXpyoXC4P3Y8X6RUTcWEdGOMQrwLmnc6FSb8yBp1J+j/8RF8 Bv7xdG5kU8b1TY80A/YQO2pqqzeON9gD7jodoKtTfPnloayYmF5pK03bCtG7P0Z/Ppdp NTmg==
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=JDcp8/Fg3jRx+lFWfVDJKmWUcRx0jx2P/+LRTsF0B7A=; b=Go4uIDkninE9rydWcvP0t1eHtKOxdZq9KC2JdcuIo3bE/wm5xy6dTq7UiS7cGJrMO+ aADG9Jppr+VwTKOzSD/nPTBgHmzWLuakHPuRS3GAK4R+x3neeQHOMGGC9BjNBGyIxFJ7 vvu69+NbT0jSHsB/q0twbNlviAvxfpE9zcrLKqWX/FMgn06c8g5tWjQxrD5vLzinLxAB 3v0PXX8zhuim1fqi9tIWw627K0mNzzAwl3IYmUiD3wghR8LzuxKkY+nOXsQFILn6Rfxw GJrJFKU4ZxiStYNlHIYz27HfXYmEvUf+wJnG7W8GIGJrNWJLF0wbyyoGryr8/QP3G+U7 WzoA==
X-Gm-Message-State: AOAM5323BrXOt01yL5wcg+ow4e4ixLBNtGFmCaH4SonhUvt/sftyGuNx FJn3Sxjb3MOMjAALFtAECHxUKmWsyqQnGq8HKUU=
X-Google-Smtp-Source: ABdhPJxcxzg3CSz3fUa+H8cPhLY4PGDfiSRHh9GyZjdmQFf+1Teuz0w7Qh0SL8WPDplfTz57DKzV783pEDEvkxWtnvM=
X-Received: by 2002:a05:6e02:180d:: with SMTP id a13mr25735230ilv.156.1615321441095; Tue, 09 Mar 2021 12:24:01 -0800 (PST)
MIME-Version: 1.0
References: <CAOj+MMHsDgfD8avbRtvthhd0=c-X25L9HBc0yQTby4vFQKECLQ@mail.gmail.com> <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> <ada0ec9f-a0b5-0f32-dee1-2ff4cfc70013@cisco.com> <CABNhwV2XCEi1A-KkNG7Sbd_gWfO_biuiCVRFRFaMvTo0Mayf6A@mail.gmail.com> <32e3d939-ce1b-ffaf-9ca8-ddbcfa903a9e@cisco.com> <CABNhwV0kH9E7LaZL6X=YVrDEifx1v8gsLt7n5JZ7tLmRL93kwQ@mail.gmail.com> <CA+wi2hO_fBZ-W9B72KEdibkhG8p_2PcigDzmR0MyHMB-PqPYGA@mail.gmail.com> <CA+wi2hOzqd0c84gy=4j3hoZvZKqwx0B+L+hEN4w_n+f6T+5WhQ@mail.gmail.com> <CABNhwV3v5p6Q2TJUAwH2bbrui2fKYUHWaOKLMMu1j-X-6HUWJA@mail.gmail.com>
In-Reply-To: <CABNhwV3v5p6Q2TJUAwH2bbrui2fKYUHWaOKLMMu1j-X-6HUWJA@mail.gmail.com>
From: Tony Przygienda <tonysietf@gmail.com>
Date: Tue, 9 Mar 2021 21:23:24 +0100
Message-ID: <CA+wi2hNRAuBr3OHG_Ei4ABUiM8okrDD-0npj=+LbM7o2iq8qPg@mail.gmail.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
Cc: Peter Psenak <ppsenak@cisco.com>, Robert Raszuk <robert@raszuk.net>, Huzhibo <huzhibo@huawei.com>, Aijun Wang <wangaj3@chinatelecom.cn>, Tony Li <tony.li@tony.li>, lsr <lsr@ietf.org>, Tianran Zhou <zhoutianran@huawei.com>, wangyali <wangyali11@huawei.com>
Content-Type: multipart/alternative; boundary="000000000000b1d2f405bd205466"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/AX7jlChrt9zpUBfHRRDFRHtspZU>
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: Tue, 09 Mar 2021 20:24:07 -0000

Gyan, all good except you find that once you have MFI thought through and
really working (implementations do wonder to understanding) with all kind
of frills like Les pointed out you'll build MT by another name again most
likely AFAIS.

If you want to flood everywhere and have some attribution on links you try
to put into computation you end up in flex algo corner pretty much (which
has been done pretty much already in a mild but extremely practical form in
RFC2676 but wasn't the hot cookie of the day then)

The sharing of FECs Tarek proposes seems like a clever optimization and
something bitsy new if that gives you the "slice" definition @ maximum
scale you look for.

-- tony

On Tue, Mar 9, 2021 at 3:47 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:

> Tony,
>
> In-line
>
> On Tue, Mar 9, 2021 at 5:55 AM Tony Przygienda <tonysietf@gmail.com>
> wrote:
>
>> and replying to myself, as was mentioned yesterday in LSR already, the
>> key questions is HOW MANY control plane slices and then FIB slices do you
>> really need in the technology to be built.  And how much of that needs to
>> be really in the core? Both will have large implication on solutions, you
>> cannot run 2000 IGP processes in a box but you could run 2K topologies on
>> IGP (cough, cough). IGP control plane will be limited by how many
>> computations you can crunch (unless you take that off box, bit risky but
>> thnkable) and then can you OAM & operate such a solution, especially if
>> topologies disjoin. FEC sharing tricks are proposed here and are worth
>> thinking through if they allow to squeeze #context in control plane into
>> less context in FIB but compression is a devil (think SR stack compression
>> today) since it often leads operationally to surprising effects. In
>> forwarding path all those things are trickier/more costly, on the edge we
>> run thousands of VPNs/EVIs in MP-BGP so it's thinkable, in the core, ehem,
>> well, you start to reinvent MPLS since about only thing that scales on
>> every core box is switching (if you want precise per box
>> accounting/control). You can 'fudge' things by the ancient loose source
>> routing, ehem, sorry, it's called SR now ;-) but this has a formidable set
>> of operational challenges since the ole Token Ring doing it.
>>
>> exec summary: figure out how many "slices" you need in control & data
>> plane & how tight they need to be in terms of SLAs and then swallow the
>> trade-offs. that may not be a single data point and multiple solutions may
>> be necessary.
>>
>>     Gyan> Agreed.  For draft "draft-xie-lsr-isis-sr-vtn-mt-03" VTN
> underpinning it makes sense with this draft to pick the design to use MT
> separate forwarding plane RIB/FIB topology resource isolation over MI -
> Separate control plane & forwarding plane resource isolation.  As you
> stated with TEAS NS there could be 1000s of slices and so you really need
> to pick your poison carefully as far as degree of resource isolation to
> provide optimized overall scalability. This draft is another way to skin
> the cat for VTN network slice as far as isolation and taking it another
> step further to provide lesser isolation then MT with isolating with MFI
> flood instance to provide greater scalability with slices.
>
>> --- tony
>>
>> On Tue, Mar 9, 2021 at 11:47 AM Tony Przygienda <tonysietf@gmail.com>
>> wrote:
>>
>>> Gyan, you are confusing RIB with LSDB. It is absolutely feasible and
>>> normal to generate multiple RIBs/FIBs from a single LSDB and that has been
>>> done for about forever
>>>
>>> problem with lots of those proposals and assertions here is that
>>> powerpoint and rfc text always compiles no matter what you put into it,
>>> silicon and real implementations force to face the world not as you imagine
>>> it but as you can actually make it work in practical terms. Akin to talking
>>> about pottery (*there is a value to it in itself) and making a real pot
>>> with clay. Making a real pot first gives you a much better chance to
>>> actually talk about pottery meaningfully albeit it does not teach you
>>> aesthetics of pottery or a complete new way to make pots possibly.
>>>
>>> 2c
>>>
>>> -- tony
>>>
>>> On Fri, Mar 5, 2021 at 5:11 PM Gyan Mishra <hayabusagsm@gmail.com>
>>> wrote:
>>>
>>>> Hi Peter
>>>>
>>>> On Fri, Mar 5, 2021 at 10:56 AM Peter Psenak <ppsenak@cisco.com> wrote:
>>>>
>>>>> Gyan,
>>>>>
>>>>> On 05/03/2021 16:46, Gyan Mishra wrote:
>>>>> > Yali
>>>>> >
>>>>> > I agree with a Peter.
>>>>> >
>>>>> > As for resource isolation and provisioning of a VTN I think you
>>>>> really
>>>>> > need separate LSDB instances provided by MT or MI as better suited
>>>>> for
>>>>> > network slicing.
>>>>>
>>>>> MT does not provide LSDB separation, only MI does.
>>>>>
>>>>> thanks,
>>>>> Peter
>>>>
>>>>
>>>>    I thought that each MT topology was a separate RIB meaning separate
>>>> LSDB.  The RFC is confusing.😄
>>>>
>>>> https://tools.ietf.org/html/rfc5120
>>>>
>>>> 6 <https://tools.ietf.org/html/rfc5120#section-6>.  MT SPF Computation
>>>>
>>>>    Each MT MUST run its own instance of the decision process.  The
>>>>    pseudo-node LSPs are used by all topologies during computation.  Each
>>>>    non-default topology MAY have its attached bit and overload bit set
>>>>    in the MT TLV.  A reverse-connectivity check within SPF MUST follow
>>>>    the according MT to assure the bi-directional reachability within the
>>>>    same MT.
>>>>
>>>>    The results of each computation SHOULD be stored in a separate
>>>>    Routing Information Base (RIB), in normal cases, otherwise
>>>>    overlapping addresses in different topologies could lead to
>>>>    undesirable routing behavior, such as forwarding loops.  The
>>>>    forwarding logic and configuration need to ensure the same MT is
>>>>    traversed from the source to the destination for packets.  The
>>>>    nexthops derived from the MT SPF MUST belong to the adjacencies
>>>>
>>>>
>>>> conforming to the same MT for correct forwarding.  It is recommended
>>>>    for the administrators to ensure consistent configuration of all
>>>>    routers in the domain to prevent undesirable forwarding behavior.
>>>>
>>>>    No attempt is made in this document to allow one topology to
>>>>    calculate routes using the routing information from another topology
>>>>    inside SPF.  Even though it is possible to redistribute and leak
>>>>    routes from another IS-IS topology or from external sources, the
>>>>    exact mechanism is beyond the scope of this document.
>>>>
>>>>
>>>>
>>>>>
>>>>> >
>>>>> > To me it seems a common LSDB shared among network slices VTN
>>>>> underlay
>>>>> > could be problematic with network overlap issues.
>>>>> >
>>>>> > Kind Regards
>>>>> >
>>>>> > Gyan
>>>>> >
>>>>> > On Fri, Mar 5, 2021 at 10:28 AM Peter Psenak <ppsenak@cisco.com
>>>>> > <mailto:ppsenak@cisco.com>> wrote:
>>>>> >
>>>>> >     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
>>>>> >     <mailto:ppsenak@cisco.com>]
>>>>> >      > Sent: Thursday, March 4, 2021 11:20 PM
>>>>> >      > To: wangyali <wangyali11@huawei.com
>>>>> >     <mailto:wangyali11@huawei.com>>; Gyan Mishra <
>>>>> hayabusagsm@gmail.com
>>>>> >     <mailto:hayabusagsm@gmail.com>>; Robert Raszuk <
>>>>> robert@raszuk.net
>>>>> >     <mailto:robert@raszuk.net>>
>>>>> >      > Cc: Huzhibo <huzhibo@huawei.com <mailto:huzhibo@huawei.com>>;
>>>>> >     Aijun Wang <wangaj3@chinatelecom.cn
>>>>> >     <mailto:wangaj3@chinatelecom.cn>>; Tony Li <tony.li@tony.li
>>>>> >     <mailto:tony.li@tony.li>>; lsr <lsr@ietf.org <mailto:
>>>>> lsr@ietf.org>>t;>;
>>>>> >     Tianran Zhou <zhoutianran@huawei.com <mailto:
>>>>> 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
>>>>> >     <mailto:ppsenak@cisco.com>]
>>>>> >      >> Sent: Thursday, March 4, 2021 6:50 PM
>>>>> >      >> To: wangyali <wangyali11@huawei.com
>>>>> >     <mailto:wangyali11@huawei.com>>; Gyan Mishra
>>>>> >      >> <hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com>>;
>>>>> Robert
>>>>> >     Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>
>>>>> >      >> Cc: Huzhibo <huzhibo@huawei.com <mailto:huzhibo@huawei.com
>>>>> >>;
>>>>> >     Aijun Wang
>>>>> >      >> <wangaj3@chinatelecom.cn <mailto:wangaj3@chinatelecom.cn>>;
>>>>> Tony
>>>>> >     Li <tony.li@tony.li <mailto:tony.li@tony.li>>; lsr
>>>>> >      >> <lsr@ietf.org <mailto:lsr@ietf.org>>; Tianran Zhou
>>>>> >     <zhoutianran@huawei.com <mailto: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
>>>>> >     <mailto:ppsenak@cisco.com>]
>>>>> >      >>> Sent: Wednesday, March 3, 2021 5:37 PM
>>>>> >      >>> To: wangyali <wangyali11@huawei.com
>>>>> >     <mailto:wangyali11@huawei.com>>; Gyan Mishra
>>>>> >      >>> <hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com>>;
>>>>> Robert
>>>>> >     Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>
>>>>> >      >>> Cc: Huzhibo <huzhibo@huawei.com <mailto:huzhibo@huawei.com
>>>>> >>;
>>>>> >     Aijun Wang
>>>>> >      >>> <wangaj3@chinatelecom.cn <mailto:wangaj3@chinatelecom.cn>>;
>>>>> >     Tony Li <tony.li@tony.li <mailto:tony.li@tony.li>>; lsr
>>>>> >      >>> <lsr@ietf.org <mailto:lsr@ietf.org>>; Tianran Zhou
>>>>> >     <zhoutianran@huawei.com <mailto: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
>>>>> >     <mailto:ppsenak@cisco.com>]
>>>>> >      >>>> Sent: Tuesday, March 2, 2021 5:12 PM
>>>>> >      >>>> To: wangyali <wangyali11@huawei.com
>>>>> >     <mailto:wangyali11@huawei.com>>; Gyan Mishra
>>>>> >      >>>> <hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com>>;
>>>>> Robert
>>>>> >     Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>
>>>>> >      >>>> Cc: Huzhibo <huzhibo@huawei.com <mailto:huzhibo@huawei.com
>>>>> >>;
>>>>> >     Aijun Wang
>>>>> >      >>>> <wangaj3@chinatelecom.cn <mailto:wangaj3@chinatelecom.cn
>>>>> >>;
>>>>> >     Tony Li <tony.li@tony.li <mailto:tony.li@tony.li>>; lsr
>>>>> >      >>>> <lsr@ietf.org <mailto:lsr@ietf.org>>; Tianran Zhou
>>>>> >     <zhoutianran@huawei.com <mailto: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
>>>>> >     <mailto:ppsenak@cisco.com>]
>>>>> >      >>>>> Sent: Sunday, February 28, 2021 8:23 PM
>>>>> >      >>>>> To: Gyan Mishra <hayabusagsm@gmail.com
>>>>> >     <mailto:hayabusagsm@gmail.com>>; Robert Raszuk
>>>>> >      >>>>> <robert@raszuk.net <mailto:robert@raszuk.net>>
>>>>> >      >>>>> Cc: Huzhibo <huzhibo@huawei.com <mailto:
>>>>> huzhibo@huawei.com>>t;>;
>>>>> >     Aijun Wang
>>>>> >      >>>>> <wangaj3@chinatelecom.cn <mailto:wangaj3@chinatelecom.cn
>>>>> >>;
>>>>> >     Tony Li <tony.li@tony.li <mailto:tony.li@tony.li>>; lsr
>>>>> >      >>>>> <lsr@ietf.org <mailto:lsr@ietf.org>>; Tianran Zhou
>>>>> >     <zhoutianran@huawei.com <mailto:zhoutianran@huawei.com>>;
>>>>> wangyali
>>>>> >      >>>>> <wangyali11@huawei.com <mailto: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>
>>>>> >      >>>>>> <mailto: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>
>>>>> >      >>>>>>          <mailto:wangaj3@chinatelecom.cn
>>>>> >     <mailto:wangaj3@chinatelecom.cn>>> wrote:
>>>>> >      >>>>>>
>>>>> >      >>>>>>              Hi, Robert:
>>>>> >      >>>>>>
>>>>> >      >>>>>>              Separate into different protocol instances
>>>>> can
>>>>> >     accomplish the
>>>>> >      >>>>>>              similar task, but it has
>>>>> <https://www.google.com/maps/search/ar+task,+but+it+has?entry=gmail&source=g>
>>>>> 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>
>>>>> >      >>>>>>>              <mailto: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
>>>>> >     <
>>>>> https://www.google.com/maps/search/lution+we+recommend?entry=gmail&source=g
>>>>> >
>>>>> >     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> <mailto:Lsr@ietf.org
>>>>> >     <mailto:Lsr@ietf.org>>
>>>>> >      >>>>>>> https://www.ietf.org/mailman/listinfo/lsr
>>>>> >      >>>>>>
>>>>> >      >>>>>>          _______________________________________________
>>>>> >      >>>>>>          Lsr mailing list
>>>>> >      >>>>>> Lsr@ietf.org <mailto:Lsr@ietf.org> <mailto: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
>>>>> >      >>>>>>
>>>>> >      >>>>>>
>>>>> >      >>>>>
>>>>> >      >>>>>
>>>>> >      >>>>>
>>>>> >      >>>>
>>>>> >      >>>>
>>>>> >      >>>>
>>>>> >      >>>
>>>>> >      >>>
>>>>> >      >>>
>>>>> >      >>
>>>>> >      >>
>>>>> >      >>
>>>>> >      >
>>>>> >      >
>>>>> >      >
>>>>> >
>>>>> > --
>>>>> >
>>>>> > <http://www.verizon.com/>
>>>>> >
>>>>> > *Gyan Mishra*
>>>>> >
>>>>> > /Network Solutions A//rchitect /
>>>>> >
>>>>> > /M 301 502-1347
>>>>> > 13101 Columbia Pike
>>>>> > /Silver Spring, MD
>>>>> >
>>>>> >
>>>>>
>>>>> --
>>>>
>>>> <http://www.verizon.com/>
>>>>
>>>> *Gyan Mishra*
>>>>
>>>> *Network Solutions A**rchitect *
>>>>
>>>>
>>>>
>>>> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>>>>
>>>> _______________________________________________
>>>> 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
>
>