IETF Logo Mail Archive

Re: [Idr] Adoption call for draft-dunbar-idr-5g-edge-compute-app-meta-data-09.txt (7/29/2022 to 8/12/2022)

"gongxia@chinatelecom.cn" <gongxia@chinatelecom.cn> Mon, 22 August 2022 07:30 UTC

Return-Path: <gongxia@chinatelecom.cn>
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 2B78EC1526E1 for <idr@ietfa.amsl.com>; Mon, 22 Aug 2022 00:30:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1T9zpotpvEC for <idr@ietfa.amsl.com>; Mon, 22 Aug 2022 00:30:09 -0700 (PDT)
Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.223]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD24C1524B3 for <idr@ietf.org>; Mon, 22 Aug 2022 00:30:08 -0700 (PDT)
HMM_SOURCE_IP: 172.18.0.188:34300.1874070835
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_TYPE: SMTP
Received: from clientip-61.144.66.69 (unknown [172.18.0.188]) by chinatelecom.cn (HERMES) with SMTP id B73692800DF; Mon, 22 Aug 2022 15:30:02 +0800 (CST)
X-189-SAVE-TO-SEND: 71041897@chinatelecom.cn
Received: from ([172.18.0.188]) by app0023 with ESMTP id 0309625596d04d3cb5755b5f82e1b7f8 for shares@ndzh.com; Mon, 22 Aug 2022 15:30:03 CST
X-Transaction-ID: 0309625596d04d3cb5755b5f82e1b7f8
X-Real-From: gongxia@chinatelecom.cn
X-Receive-IP: 172.18.0.188
X-MEDUSA-Status: 0
Sender: gongxia@chinatelecom.cn
Date: Mon, 22 Aug 2022 15:30:01 +0800
From: "gongxia@chinatelecom.cn" <gongxia@chinatelecom.cn>
To: Susan Hares <shares@ndzh.com>, 'IDR List' <idr@ietf.org>
References: <BYAPR08MB4872CFF0336A359D8D1210D0B3999@BYAPR08MB4872.namprd08.prod.outlook.com>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7.2.18.95[cn]
Mime-Version: 1.0
Message-ID: <20220822153000954530116@chinatelecom.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart404033365488_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/gVfd5kNpV9JPVRA04G30QPbQpMA>
Subject: Re: [Idr] Adoption call for draft-dunbar-idr-5g-edge-compute-app-meta-data-09.txt (7/29/2022 to 8/12/2022)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
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, 22 Aug 2022 07:30:11 -0000

Hi IDR, 
I have read the document support the adoption. This draft defines a basic mechanism to distribute app metadata, it will be helpful in 5G EC scenarios. 



Xia Gong
Chinatelecom
 
From: Susan Hares
Date: 2022-07-29 18:23
To: idr@ietf.org
Subject: [Idr] Adoption call for draft-dunbar-idr-5g-edge-compute-app-meta-data-09.txt (7/29/2022 to 8/12/2022)
This begins a 3 week WG Adoption call for
draft-dunbar-idr-5g-edge-compute-app-meta-data-09.txt
https://datatracker.ietf.org/doc/draft-dunbar-idr-5g-edge-compute-app-meta-data/
 
This draft proposes a new SubTLV (AppMetaData)
for the BGP Tunnel Encapsulation Attribute [RFC9012]
that indicates the running status and environment of directly
attached 5G Edge Computing (EC) instances.
 
The AppMetaData can be used by routers in the
5G Local Data Network to make path selection
not only based on the routing distance but also the running
environment of the destinations. The goal is to improve
latency and performance for 5G EC services.
 
In your discussion of this adoption call, please consider
these questions:
 
1) The addition of this type of information to tunnels
is useful for inter-domain routing within 5G networks?
 
2) What type of additional load this data to
Basic Tunnel encapsulation [RFC9012]?
 
For example is the load placed by this draft equal or
Less than the SR routing additions from
such as draft-ietf-idr-segment-routing-te-policy?
 
3) Will the addition of this information aid
Routing in 5G networks?
 
Cheers, Sue Hares
 
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

v2.23.0 | Report a Bug | By Email