Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

"Dongjie (Jimmy)" <jie.dong@huawei.com> Mon, 08 March 2021 14:29 UTC

Return-Path: <jie.dong@huawei.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 3D4C53A2B7C for <lsr@ietfa.amsl.com>; Mon, 8 Mar 2021 06:29:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 LHfwBSX9bw1D for <lsr@ietfa.amsl.com>; Mon, 8 Mar 2021 06:29:16 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC6763A2B41 for <lsr@ietf.org>; Mon, 8 Mar 2021 06:29:15 -0800 (PST)
Received: from fraeml705-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4DvKrx52V6z67x2v; Mon, 8 Mar 2021 22:06:41 +0800 (CST)
Received: from dggeme751-chm.china.huawei.com (10.3.19.97) by fraeml705-chm.china.huawei.com (10.206.15.54) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Mon, 8 Mar 2021 15:11:01 +0100
Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme751-chm.china.huawei.com (10.3.19.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Mon, 8 Mar 2021 22:11:00 +0800
Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.2106.013; Mon, 8 Mar 2021 22:11:00 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: Gyan Mishra <hayabusagsm@gmail.com>, Tony Przygienda <tonysietf@gmail.com>
CC: "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>, Chongfeng Xie <chongfeng.xie@foxmail.com>, "Acee Lindem (acee)" <acee@cisco.com>, Robert Raszuk <robert@raszuk.net>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03
Thread-Index: AQHXD7ulQBxlBtLDvEWWPb5pr3NBAKpzKTuAgAClJqf//6/tgIACzqUAgAHcDICAAIS1gIABWHig
Date: Mon, 08 Mar 2021 14:11:00 +0000
Message-ID: <cce9bf49158e439f8e6ae868cf16ec0f@huawei.com>
References: <6413094C-F1D8-4DBF-B365-E943473FDDE4@cisco.com> <BY5PR11MB433727F6D0A365B26896625DC1979@BY5PR11MB4337.namprd11.prod.outlook.com> <2021030421033728661450@foxmail.com> <BY5PR11MB43378320E0607268CA22A900C1979@BY5PR11MB4337.namprd11.prod.outlook.com> <CAOj+MMHL4ritC6x_STU4YqaXCqaWPnOZqAS8XSXiDzEGjfb35w@mail.gmail.com> <CA+wi2hOcWh0UFJB4BMta6X9_Kv9c0Dpu3ZUbGQV324p5UYu7oA@mail.gmail.com> <CABNhwV2MJoJdS8VKSfQXb5t6BNs19DOPpWF_y70kw1UP+Kk+NA@mail.gmail.com>
In-Reply-To: <CABNhwV2MJoJdS8VKSfQXb5t6BNs19DOPpWF_y70kw1UP+Kk+NA@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.186.34]
Content-Type: multipart/related; boundary="_004_cce9bf49158e439f8e6ae868cf16ec0fhuaweicom_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/TnOSWfLOBig78moXhTEBYU4kJcg>
Subject: Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03
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: Mon, 08 Mar 2021 14:29:20 -0000

Hi Gyan,

Thanks for your comments.

As you mentioned, both MT and MI can provide separate topologies and the topology based computation, and MI can provide separate LSDBs at some additional cost (separate adjacencies, etc.). In this document, the resource of VTN mainly refers to the forwarding plane resources, thus MT is chosen as it can provide the required functionality with less overhead.

Hope this helps.

Best regards,
Jie

From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Gyan Mishra
Sent: Monday, March 8, 2021 7:29 AM
To: Tony Przygienda <tonysietf@gmail.com>
Cc: Les Ginsberg (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org>; Chongfeng Xie <chongfeng.xie@foxmail.com>; Acee Lindem (acee) <acee@cisco.com>; Robert Raszuk <robert@raszuk.net>; lsr@ietf.org
Subject: Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03


Dear Authors

Why was MT chosen and not MI for VTN underlay network slice underpinning.  MT instances has separate topology but not separate LSDB where MI Multi instance RFC 6822 has a separate LSDB for resources isolation and I think would be a better fit for VTN underlay provisioning.

MI
https://tools.ietf.org/html/rfc6822

Thanks

Gyan

On Sun, Mar 7, 2021 at 10:34 AM Tony Przygienda <tonysietf@gmail.com<mailto:tonysietf@gmail.com>> wrote:

Robert ruminated:

That said I think perhaps we are indeed missing LROW WG (Local Routing Operations WG) where just like in GROW WG where mainly (Global) BGP operational aspects are discussed there could be good place to discuss operational aspects of link state protocols deployment and use cases. In fact perhaps it would also free some LSR bandwidth to really focus on protocol extensions.


+1

IGPs grew a zoo of horns and bells by now and no'one tells the operators which spines are poisonous ;-)

--- tony
_______________________________________________
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 Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD