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

Gyan Mishra <hayabusagsm@gmail.com> Fri, 05 March 2021 15:46 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 B7E483A2768 for <lsr@ietfa.amsl.com>; Fri, 5 Mar 2021 07:46:31 -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 9CvSTk621Lmo for <lsr@ietfa.amsl.com>; Fri, 5 Mar 2021 07:46:26 -0800 (PST)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 5F2233A2744 for <lsr@ietf.org>; Fri, 5 Mar 2021 07:46:21 -0800 (PST)
Received: by mail-pg1-x52f.google.com with SMTP id l2so1641610pgb.1 for <lsr@ietf.org>; Fri, 05 Mar 2021 07:46:21 -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=vcZr0ZBOP2LkDUyEDWoJrsSnmi1mCHte8GuGN3J16PA=; b=QP1+m7qfT098Rm6HeM4k/cTvSYnJGwGFVjgmXQYlfPn0+a5WzAGHH+/YrlXcvRBrYc t9fpABcqU8NzIOy5LxmN22suDaedIq5T2vVomBCLkMACQXrKxW5TaAU2xqrPh4IbHefb KlYMA9rVXP21Y67JXymL/4B+ONhw3l7atEx0uOdoZuA5AkahV1r0B41fkWu0b4Uc5WS4 H3EIWufoAxREa+HHwa0tQCpb+znCbIHYYpp2vh8V3TuIv3Osc9g6trCOm3EsBGP7sabv C3YA+IFoe0dCXZgsQketmAvMp5pubFCXlSKoPShPzmNLuHorXRSFLJiK5lTy5fAJnaZD NoWQ==
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=vcZr0ZBOP2LkDUyEDWoJrsSnmi1mCHte8GuGN3J16PA=; b=OfwK4zCKpEAGAEnJiJ7OzSYeOGQwtf4DwXS213ZVOiXu2KUtD3iqoDa54cI5ycAyfs VAP7VdKM/mrL8C7xWpsZrQgdP9hbzlGaKzvLxwoq/OBGOCqolh1A2VlmSqJe66//87n5 3J8KuOk5HZrxyU/jfGRI0hW+7VmBqM+uQxhW1VRnhRQw0aS3MNAvn5N3zSNnFOuN4ufh WfFEy2Bh1xutQ2xZQCpaiRL/Z8dzESLbFcO+N2IticeelwYLjFN+oZKoN7AcXiAikU8S uDtw+zcfdUqTo3W6ULngMuZSzQeMXU6jKhrFybVE+XIEC+E5ehqp+ziVSRb50LkKhgpk b7Ng==
X-Gm-Message-State: AOAM531BH0Wbq74Tvh8PA9ZdVFAsSdqgEKNQZuDuDXXLr3SNPxqApt6+ RGWYRuKk0zOUlJuXxNPaQtqr0boXYGyiaguxWtI=
X-Google-Smtp-Source: ABdhPJySFdbtOIaULZym88zWQBgH6d6HC7li7hKhjBBl0iATM6rELL1WX+BU5dEiuLj9hqhNgjbZXKY5yp16m7NFbyA=
X-Received: by 2002:a05:6a00:168d:b029:1ba:d500:1209 with SMTP id k13-20020a056a00168db02901bad5001209mr9556425pfc.4.1614959180180; Fri, 05 Mar 2021 07:46:20 -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> <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>
In-Reply-To: <ada0ec9f-a0b5-0f32-dee1-2ff4cfc70013@cisco.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Fri, 5 Mar 2021 10:46:09 -0500
Message-ID: <CABNhwV2XCEi1A-KkNG7Sbd_gWfO_biuiCVRFRFaMvTo0Mayf6A@mail.gmail.com>
To: Peter Psenak <ppsenak@cisco.com>
Cc: Aijun Wang <wangaj3@chinatelecom.cn>, Huzhibo <huzhibo@huawei.com>, Robert Raszuk <robert@raszuk.net>, Tianran Zhou <zhoutianran@huawei.com>, Tony Li <tony.li@tony.li>, lsr <lsr@ietf.org>, wangyali <wangyali11@huawei.com>
Content-Type: multipart/alternative; boundary="00000000000042f20105bccbfc43"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/4qSAWD-MiKMHWcajjEut8Hy6Ju8>
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:46:38 -0000

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.

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> 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]
> > 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
> <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>
> >>>>>>>              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
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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