[Idr] Re: comments of draft-ietf-idr-5g-edge-service-metadata

Cheng Li <c.l@huawei.com> Thu, 20 June 2024 08:18 UTC

Return-Path: <c.l@huawei.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C2149C17C8A5; Thu, 20 Jun 2024 01:18:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.206
X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id yXnkTN5aH6ZO; Thu, 20 Jun 2024 01:18:23 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38CCCC14F6A7; Thu, 20 Jun 2024 01:18:23 -0700 (PDT)
Received: from mail.maildlp.com (unknown []) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4W4YJj2Nh4z6H7XL; Thu, 20 Jun 2024 16:17:57 +0800 (CST)
Received: from lhrpeml100002.china.huawei.com (unknown []) by mail.maildlp.com (Postfix) with ESMTPS id 043F9140B33; Thu, 20 Jun 2024 16:18:20 +0800 (CST)
Received: from kwepemf200012.china.huawei.com ( by lhrpeml100002.china.huawei.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Thu, 20 Jun 2024 09:18:18 +0100
Received: from dggpemf500009.china.huawei.com ( by kwepemf200012.china.huawei.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 20 Jun 2024 16:18:17 +0800
Received: from dggpemf500009.china.huawei.com ([]) by dggpemf500009.china.huawei.com ([]) with mapi id 15.02.1544.011; Thu, 20 Jun 2024 16:18:16 +0800
From: Cheng Li <c.l@huawei.com>
To: Linda Dunbar <linda.dunbar@futurewei.com>, Cheng Li <c.l=40huawei.com@dmarc.ietf.org>, "draft-ietf-idr-5g-edge-service-metadata@ietf.org" <draft-ietf-idr-5g-edge-service-metadata@ietf.org>
Thread-Topic: comments of draft-ietf-idr-5g-edge-service-metadata
Thread-Index: AdrAypgS46dfBq5UR1CXSBby8VH+7AAHh0UgAIASGGA=
Date: Thu, 20 Jun 2024 08:18:16 +0000
Message-ID: <88e805910fec43aba4b054571dddb0f6@huawei.com>
References: <a38aadd8b97a459e9880722bc2afdc78@huawei.com> <CO1PR13MB49206739F4B4E10EE055496C85CD2@CO1PR13MB4920.namprd13.prod.outlook.com>
In-Reply-To: <CO1PR13MB49206739F4B4E10EE055496C85CD2@CO1PR13MB4920.namprd13.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_88e805910fec43aba4b054571dddb0f6huaweicom_"
MIME-Version: 1.0
X-MailFrom: c.l@huawei.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-idr.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "idr@ietf.org" <idr@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Idr] Re: comments of draft-ietf-idr-5g-edge-service-metadata
List-Id: Inter-Domain Routing <idr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/fg0BLnwTBqkLD6Pnqg2B88uWQ3E>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Owner: <mailto:idr-owner@ietf.org>
List-Post: <mailto:idr@ietf.org>
List-Subscribe: <mailto:idr-join@ietf.org>
List-Unsubscribe: <mailto:idr-leave@ietf.org>

Hi Linda,

Thanks for your quick reply.
I am ok with the text related to A-flag(Deleted).

However, regarding the Resource ID, I think it should not be consistent among sites, and it should be a site local value. It can be used to identify the resource the service used, and it is allocated by the management platform. The value is 0 by default meaning that the ResourceID is not allocated. A management platform even can use the local IP address as the ResourceID 😊


From: Linda Dunbar <linda.dunbar@futurewei.com>
Sent: Monday, June 17, 2024 9:12 PM
To: Cheng Li <c.l=40huawei.com@dmarc.ietf.org>; draft-ietf-idr-5g-edge-service-metadata@ietf.org
Cc: idr@ietf.org
Subject: RE: comments of draft-ietf-idr-5g-edge-service-metadata


Thank you very much for the suggestions.
Here are the resolutions to your suggestions:

4.6.  Service-Oriented Capability Sub-TLV

   The service-oriented capability Sub-TLV is for distributing
   information regarding the capabilities of a specific service in a
   deployment environment.  Depending on the deployment, a deployment
   environment can be an edge site or other types of environments.  This
   information provides ingress routers or controllers with the
   available resources for the specific service in each deployment
   environment.  It enables them to make well-informed decisions for the
   optimal paths to the selected deployment environment.  Currently, the
   Sub-TLV only has an abstract value derived from various metrics,
   although the specifics of this derivation are beyond the scope of
   this document.  Importantly, this value is significant only when
   comparing multiple data center sites for the same service; it is not
   meaningful when comparing different services, meaning the capability
   value relevant to Service A cannot be directly compared with that for
   Service B.  Future enhancements may expand this sub-TLV to include
   more types of metrics or even raw data that represents direct
   metrics.  This information is important in 5G network environments
   where efficient resource utilization is crucial for enhancing
   performance and service quality.

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   | ServiceOriented Cap Sub-Type  |   Length      |   Reserved    |
   |            Resource Identifier                                |
   |  SO-CapValue  |            Reserved                           |

               Figure 6: Service-Oriented Capability Sub-TLV

   - ServiceOriented Cap:  (Service-Oriented Capability) Sub-type=5
      (specified in this document).

   - Resource Identifier :  a logical term used to represent various
      types of resources, such as compute, network, power, or others,
      within the site reachable by the NLRI.  This identifier is
      consistent across all edge DCs and is determined by the specific
      deployment.  The purpose of the Resource Identifier is to indicate
      that the Service Oriented Capability Value pertains specifically
      to the resource identified by the Resource Identifier, which is
      carried in the ServiceOriented Cap Sub-TLV.

If we don’t hear any objection from the IDR group, we can close your  GitHub issues.

Thanks, Linda

From: Cheng Li <c.l=40huawei.com@dmarc.ietf.org<mailto:c.l=40huawei.com@dmarc.ietf.org>>
Sent: Monday, June 17, 2024 8:29 AM
To: draft-ietf-idr-5g-edge-service-metadata@ietf.org<mailto:draft-ietf-idr-5g-edge-service-metadata@ietf.org>
Cc: idr@ietf.org<mailto:idr@ietf.org>
Subject: comments of draft-ietf-idr-5g-edge-service-metadata

Hi Authors,

When I reread the draft, I find out that we can make some enhancements of the drafts, especially about the part of service-oriented part.
My comments are recorded here:

1.      https://github.com/ietf-wg-idr/draft-ietf-idr-5g-edge-service-metadata-14/issues/23

2.      https://github.com/ietf-wg-idr/draft-ietf-idr-5g-edge-service-metadata-14/issues/24