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

Peter Psenak <ppsenak@cisco.com> Fri, 05 March 2021 15:56 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 942073A2723 for <lsr@ietfa.amsl.com>; Fri, 5 Mar 2021 07:56:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.602
X-Spam-Level:
X-Spam-Status: No, score=-9.602 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, 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 3QILG45BVX5G for <lsr@ietfa.amsl.com>; Fri, 5 Mar 2021 07:56:54 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D66FF3A2722 for <lsr@ietf.org>; Fri, 5 Mar 2021 07:56:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16149; q=dns/txt; s=iport; t=1614959814; x=1616169414; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=N9XURPsdhWW6hTZCPa/G4eBUk+aXdvb8WvU0v+93q88=; b=VfBNyz8WlUHiHWPLOsFPpytEDeDMwaQb+UeChE2pgk1lzAJE7GDtmRnI hAx42tbMV9MFW59TvAEwNNBpQAb2PEo07TMm1g/bvPlnaOEhMEmNFd85O fOXo6W+LwpqfhHG/gj5YJ9RewoUSN5L4N2dvwMRlUWAolr2Hutt/O/Bvi Y=;
X-IPAS-Result: =?us-ascii?q?A0BUAADqU0JglxbLJq1fAxoBAQEBAQEBAQEBAwEBAQESA?= =?us-ascii?q?QEBAQICAQEBAUCBT4MhVgEnEjGEQYkEiCotA4EFiSGEd4xZA1QLAQEBDx0NC?= =?us-ascii?q?gQBAYRNAoF7JjgTAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQEBAQEBAQGGNg2GR?= =?us-ascii?q?AEBAQMBAQEhDwEFLwcJAgwECQIHBwMEAQEBAgIjAwICIQYfCQgGDQYCAQEXg?= =?us-ascii?q?lUBglUDDiEPkXmbEXaBMoVYglgNYoFFgQ8qiAqECYEvFiyBSUKBEAEngXVJN?= =?us-ascii?q?T6CGkIBAQIXgR5KBSGCT4JfBIFlYQFjBEMPASACDSAMIAoTLAgNBAwaDygqE?= =?us-ascii?q?JAKBB44gjmIO4tCkVxbgwiDL41ihWmCN4JpBQcDH4M5ilGFUo1Cgk6WaIw8j?= =?us-ascii?q?w4ED4RtgWshOYEgMxoIGxU7gmkJRxkNiEmFb4NWg0aBToVGQAMvOAIGAQkBA?= =?us-ascii?q?QMJjGKCRAEB?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,225,1610409600"; d="scan'208";a="33887292"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Mar 2021 15:56:51 +0000
Received: from [10.60.140.52] (ams-ppsenak-nitro3.cisco.com [10.60.140.52]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id 125Fuoj1006899; Fri, 5 Mar 2021 15:56:51 GMT
To: Gyan Mishra <hayabusagsm@gmail.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>
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>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <32e3d939-ce1b-ffaf-9ca8-ddbcfa903a9e@cisco.com>
Date: Fri, 5 Mar 2021 16:56:50 +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: <CABNhwV2XCEi1A-KkNG7Sbd_gWfO_biuiCVRFRFaMvTo0Mayf6A@mail.gmail.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-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/0D7saw2zW8TE5NTKF2KNu129pok>
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:56:58 -0000

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


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