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

qinfengwei <qinfengwei@chinamobile.com> Sun, 02 January 2022 11:57 UTC

Return-Path: <qinfengwei@chinamobile.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 9EBBB3A2185 for <idr@ietfa.amsl.com>; Sun, 2 Jan 2022 03:57:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 RqU4dBg5E3dN for <idr@ietfa.amsl.com>; Sun, 2 Jan 2022 03:57:43 -0800 (PST)
Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with ESMTP id AB9A53A2182 for <idr@ietf.org>; Sun, 2 Jan 2022 03:57:41 -0800 (PST)
Received: from spf.mail.chinamobile.com (unknown[172.16.121.13]) by rmmx-syy-dmz-app02-12002 (RichMail) with SMTP id 2ee261d1933382b-21bb0; Sun, 02 Jan 2022 19:57:39 +0800 (CST)
X-RM-TRANSID: 2ee261d1933382b-21bb0
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from cmccPC (unknown[223.104.190.27]) by rmsmtp-syy-appsvr07-12007 (RichMail) with SMTP id 2ee761d19332782-7e209; Sun, 02 Jan 2022 19:57:39 +0800 (CST)
X-RM-TRANSID: 2ee761d19332782-7e209
From: qinfengwei <qinfengwei@chinamobile.com>
To: 'Susan Hares' <shares@ndzh.com>, idr@ietf.org
References: <009501d7f42c$e1bcbca0$a53635e0$@ndzh.com>
In-Reply-To: <009501d7f42c$e1bcbca0$a53635e0$@ndzh.com>
Date: Sun, 02 Jan 2022 19:57:44 +0800
Message-ID: <00b601d7ffcf$f46a0160$dd3e0420$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B7_01D80013.028D4160"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Adf0LKdg/oJBRVjuTwKwiojl83szGgLoxQyw
Content-Language: zh-cn
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/8_N25AV99KVRVbdXyYA5-Uv-eAk>
Subject: [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: Sun, 02 Jan 2022 11:57:49 -0000

Hi all,

 

I support the adoption of this document. It describes a useful mechanism for
distributing the information of virtual underlay networks to the network
controller. 

 

And here are my answers to the questions:

 

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

 

Yes.

 

2) Should IDR recommend the global VTN-ID? 

 

This document proposes to reuse MT-IDs, thus it does not rely on global
VTN-ID. The global ID based mechanism may be helpful in some other cases,
and the discussion can happen in TEAS WG first. 

 

 

 

 

Thanks & BR,

 

Fengwei Qin

 

 

发件人: Idr [mailto:idr-bounces@ietf.org] 代表 Susan Hares
发送时间: 2021年12月19日 00:33
收件人: idr@ietf.org
主题: [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