Re: [Idr] draft-xie-idr-bgpls-sr-vtn-mt-03.txt - Call for WG adoption: 12/18/2021 to 1/7/2022

"Dongjie (Jimmy)" <jie.dong@huawei.com> Mon, 27 December 2021 02:08 UTC

Return-Path: <jie.dong@huawei.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B403A164D for <idr@ietfa.amsl.com>; Sun, 26 Dec 2021 18:08:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 qvxU5wJ8suSQ for <idr@ietfa.amsl.com>; Sun, 26 Dec 2021 18:08:20 -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 300F43A163B for <idr@ietf.org>; Sun, 26 Dec 2021 18:08:20 -0800 (PST)
Received: from fraeml745-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JMgtw6fNhz67J0f for <idr@ietf.org>; Mon, 27 Dec 2021 10:03:36 +0800 (CST)
Received: from dggeme704-chm.china.huawei.com (10.1.199.100) by fraeml745-chm.china.huawei.com (10.206.15.226) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2308.20; Mon, 27 Dec 2021 03:08:16 +0100
Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme704-chm.china.huawei.com (10.1.199.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.20; Mon, 27 Dec 2021 10:08:14 +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.2308.020; Mon, 27 Dec 2021 10:08:14 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: Haisheng Yu <hsyu@biigroup.cn>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] draft-xie-idr-bgpls-sr-vtn-mt-03.txt - Call for WG adoption: 12/18/2021 to 1/7/2022
Thread-Index: AQHX+K08YfBTw5DKREuMi39HGt9BAqxFmuPA
Date: Mon, 27 Dec 2021 02:08:14 +0000
Message-ID: <585ddb99a21445f68c8bb23e7d7428fa@huawei.com>
References: <E67A2E2B-42AB-4073-90C4-DE859CDF5F7C@biigroup.cn>+2FE854F3984159F8
In-Reply-To: <E67A2E2B-42AB-4073-90C4-DE859CDF5F7C@biigroup.cn>+2FE854F3984159F8
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.40.66]
Content-Type: multipart/related; boundary="_004_585ddb99a21445f68c8bb23e7d7428fahuaweicom_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/CInLfzDi5DIOE_i6cpTnw_wEX-A>
Subject: Re: [Idr] draft-xie-idr-bgpls-sr-vtn-mt-03.txt - Call for WG adoption: 12/18/2021 to 1/7/2022
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Dec 2021 02:08:34 -0000

Hi Haisheng,

Thanks for your support and comments.

In next version we will expand the acronym “NLRI” at its first appearance.

Best regards,
Jie

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Haisheng Yu
Sent: Friday, December 24, 2021 6:02 PM
To: idr@ietf.org
Subject: Re: [Idr] draft-xie-idr-bgpls-sr-vtn-mt-03.txt - Call for WG adoption: 12/18/2021 to 1/7/2022


Hi, all,
I support the adoption of this draft. In segment routing, the most important thing for a flow is to calculate the transmission path based on the network topology and the transmission requirements of the flow. The transmission requirements of the stream are known and determined, but how to obtain the network topology is still unknown and a very important process. Because only after the topology is known, the SR controller can calculate the SR path of the flow based on the input network topology and flow transmission requirements, that is, the segment list. So how to get the network topology in the network, this draft gives a great plan.

BTW, NLRI is mentioned many times in this draft, but no explanation is given.

Best regards.

[图像已被发件人删除。]

Haisheng Yu(Johnson)

hsyu@biigroup.cn





Hi, Sue and all:



I have read this draft and support its adoption.



Answers to the questions:

1) Yes, it is useful for meeting the requirement of the new services in 5G and other network scenarios.

2) Global VTN-ID is not required in this document, and can be discussed separately. IDR can follow the discussion about the global ID in TEAS.



Best Regards

Shunwan



From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares

Sent: Sunday, December 19, 2021 12:33 AM

To: idr@ietf.org<mailto:idr@ietf.org>

Subject: [Idr] draft-xie-idr-bgpls-sr-vtn-mt-03.txt - Call for WG adoption: 12/18/2021 to 1/7/2022



This begins a WG Adoption call for draft-xie-idr-bgpls-sr-vtn-mt-03.txt from 12/18 2021 to 1/7/2022.  The longer period is due to the Holiday/New Year time period.



The draft can be found at:

https://datatracker.ietf.org/doc/draft-xie-idr-bgpls-sr-vtn-mt/



While reviewing the document consider the following questions:



1)  Does this informational draft aid operation of 5G networks for new applications?



New 5G services require stringent  performance requirements for applications.  This information draft describes how to use existing segment routing (SR)

mechanisms to allow a centralized control to allocate a set of  virtual transport networks (VTNs) which are resource aware.  Isolation between resources for multi-AS transport may be necessary to protect the application.



Intra-domain:

a) Uses MT-ID which identifies 1 or more ISIS/OSPF topologies.

[drafts referenced:  draft-ietf-idr-rfc7752bis, draft-ietf-idr-bgp-ls-segment-routing-ext,  draft-ietf-idr-bgpls-srv6-ext]

b) New VTN-ID which specifies resources associated with each VTN

[draft referenced: draft-ietf-lsr-isis-sr-vtn-mt]



Inter-Domain mechanisms used include:

a) Isolation of certain VTNs to specific inter-domain links or BGP peers,

b) consistent use of MT-ID across multiple domains or use of VTN-ID TLV



VTN-ID TLV is a bgp-ls TLV that specifies unique set of resources per VTN.



[existing WG drafts referenced: draft-ietf-idr-bgpls-segment-routing-epe, draft-ietf-idr-bgpls-srv6-ext, draft-ietf-idr-rfc7752bis]

New drafts referenced: draft-dong-idr-bgpls-sr-enhanced-vpn-03.txt]



2) Should IDR recommend the global VTN-ID?



The MT-ID is not an IANA registered named space.  VTN-ID is proposed as a global name space, but does not have any proposed IANA registry text.  Should VTN-ID become a register global name space that identifies a set of MT-IDs and other resources?



Cheers, Sue