Re: [Idr] some comments about the draft-ietf-idr-5g-edge-service-metadata-02.txt
"duzongpeng@foxmail.com" <duzongpeng@foxmail.com> Sun, 11 June 2023 15:34 UTC
Return-Path: <duzongpeng@foxmail.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 8F38EC14CE2C for <idr@ietfa.amsl.com>; Sun, 11 Jun 2023 08:34:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.15
X-Spam-Level:
X-Spam-Status: No, score=-4.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HELO_DYNAMIC_IPADDR=1.951, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=foxmail.com
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 if7-L_cw3RDR for <idr@ietfa.amsl.com>; Sun, 11 Jun 2023 08:34:31 -0700 (PDT)
Received: from out203-205-221-236.mail.qq.com (out203-205-221-236.mail.qq.com [203.205.221.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 368C4C14CE25 for <idr@ietf.org>; Sun, 11 Jun 2023 08:34:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foxmail.com; s=s201512; t=1686497666; bh=0mkyqMEex/SQQ1JSDOpFxrY8nDEWlt+C6L/MFymmC9Y=; h=Date:From:To:Cc:Subject:References; b=FRwds7xjGSxuxtaKmHOMyScq/mLKFazXMyoP5yQrtEGSd3RKC0Tgo4vweDVVTt8Af df9LeHiSLolIgr+/9C56CGhHSvS3i4+xBj4zh2VOPbDprOpeDT2fD0UVVlmQdRjwZu SfrPIgz48NcYvf+BEUvuBVujPm0OAhlM5ELhBwWY=
Received: from cmcc-PC ([123.119.235.110]) by newxmesmtplogicsvrszb6-0.qq.com (NewEsmtp) with SMTP id 7090AEEE; Sun, 11 Jun 2023 23:28:09 +0800
X-QQ-mid: xmsmtpt1686497289t53x48xh6
Message-ID: <tencent_5094A8F17206A82A1F3C7608BEA136403507@qq.com>
X-QQ-XMAILINFO: MB5+LsFw85NouwZmhBwLTeqVvGK7KyiKXovw7hdVqhTmq1qKQFLR4qaT4MnHvR QUCX+ReOtjS+201go8OYYHoRtqB9vXrZVVjyZNO5bwrGBmVaIBpgO5xGOOliTBL+Jwgelz2Oigu9 R8eu87NdDeig62stJ8KfsmonsgJ7R8lBUbzGPm9ok9G5qChHaIpSeagOIv1CgoU23hIhKd0ti0WJ +am4kMI4aIqMU/8rXh0pH6Q8gEVDPWUca9uFi7ytilcpl+NruzHuFvo8F5G+N+VnSq5fuEdt+Kws yAOHw8n9cRXYyMFm0VUTOYePrpDO12NCe6BB5Z2xRLbenuf46DGWepwa1aK/V5qfGsQqeO4JCX1x 5ErUaZ2o7Io2R0KK7Q9x2kFa42lnTFmMxgTMelS3iaePKsgCQWnMiVLRtwGfS+Dp2lWFCFg3ObH3 mojsG9ZCHxl6D8Y2i01BARVt8i+a7PiHOzLbyH0kA2GTDZAB3W8ZA/T4ybf4HSQvXttsce1FHG96 wsO0p7l5ifom+rTX9xOysS9UnKcWgD4FpNlMmWpIEvRY/QdvNKCQVQh3osQJa/lHo/JpvuJu6y+i xMxCQ+FIFTYgZlif9EBBIeUZY/v7g2jjnZACCjQKqXd2HmqSCG0tDd/qN2h8HW1F2WlVsyrJjNSw /kR5aQ7+VBMmONBbHZ79MuRKr4VJUAIcId0q+0tGBbVkFo1RV8KuWxWhfj3MEfVGANnzcTCjvYQ8 ooj83ZIIYD3NVG2zFNOw+mb6CPTABlfGF53w9KRSKArfNHmgY3jl1BB2aG9O+rzzTN6okZi5x10b 9Wu+wcaqXcxKSHR7VN6OiHUyZB/loh2xBstFcCaeELvaW46hWjjRcXE4cXoRc+CBotSd3cS0h+bj N3ptc7vyKn2kaf1YCT+6dum36mnD8R3WxWoDyjEVXPGkqW7hGw1RnPR3eHdFNMngt57W2iWiZch0 Qnf0EjlEhVunPWoc5QyYQufJZwvCcYoDIx3PCw/UsBX/SJw5GjJhJOX7pHJbO42XS8MZg59BpM9V 1bTFAO4LHxRh8v1qKQ8AiaO2TMmnw=
Date: Sun, 11 Jun 2023 23:28:09 +0800
From: "duzongpeng@foxmail.com" <duzongpeng@foxmail.com>
To: Linda Dunbar <linda.dunbar@futurewei.com>, kmajumdar <kmajumdar@microsoft.com>, "rainsword.wang" <rainsword.wang@huawei.com>, "gyan.s.mishra" <gyan.s.mishra@verizon.com>
Cc: "idr@ietf. org" <idr@ietf.org>, Cheng Li <c.l@huawei.com>
References: <tencent_697D58D82DF942DA12D470A202CB25A02C09@qq.com>, <CO1PR13MB49208FE897682337B22DFDFC8550A@CO1PR13MB4920.namprd13.prod.outlook.com>, <tencent_4A991D804FABCD5A8D3FAAAE9C18AAC18705@qq.com>, <CO1PR13MB492001CE56F6986DA96630828551A@CO1PR13MB4920.namprd13.prod.outlook.com>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7.2.25.178[cn]
Mime-Version: 1.0
X-OQ-MSGID: <2023061123280870481710@foxmail.com>
Content-Type: multipart/alternative; boundary="----=_001_NextPart840147028545_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/0MW1Hr58pjb3j8Xzt6uT0_4Wj8o>
Subject: Re: [Idr] some comments about the draft-ietf-idr-5g-edge-service-metadata-02.txt
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: Sun, 11 Jun 2023 15:34:36 -0000
Hi, Linda: I agree with the Attr. Flags and the Svc-Metedata-T. However, I do not think we need to define the "The lower order flags" that haven’t been specified. We can define Flags fot the Svc-Metadata-Type after the "Length". It is used for the Svc-Metadata-type specific, not for all the PATH attribute. Best Regards Zongpeng Du duzongpeng@foxmail.com & duzongpeng@chinamobile.com From: Linda Dunbar Date: 2023-06-09 08:07 To: Zongpeng; kmajumdar; rainsword.wang; gyan.s.mishra CC: idr@ietf. org; c.l Subject: RE: Re:RE: [Idr] some comments about the draft-ietf-idr-5g-edge-service-metadata-02.txt ZongPeng, The Service Metadata Path Attribute is now defined as to conform with RFC4271. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attr. Flags |Svc-Metadata-T | Length (2 Octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Value (multiple Metadata sub-TLVs) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Edge Service Metadata Path Attribute Attr. Flags are defined as: The high-order bit (bit 0): set to 1. The second high-order bit (bit 1): set to 0 to indicate that the service-metadata is not transitive. Only intended for the receiving router. The third high-order bit (bit 2): same as specified by RFC4721. The fourth high-order bit (bit 3): set to 1 to indicate there are two octets for the Length field. The lower order flags haven’t been specified yet. Can we consider using the lower order flags to represent the categories of the service metadata carried by the TLV? Linda From: Zongpeng <duzongpeng@foxmail.com> Sent: Thursday, June 8, 2023 6:46 AM To: Linda Dunbar <linda.dunbar@futurewei.com>; kmajumdar <kmajumdar@microsoft.com>; rainsword.wang <rainsword.wang@huawei.com>; gyan.s.mishra <gyan.s.mishra@verizon.com> Cc: idr@ietf. org <idr@ietf.org>; c.l <c.l@huawei.com> Subject: Re:RE: [Idr] some comments about the draft-ietf-idr-5g-edge-service-metadata-02.txt Hi, Linda Thanks for the reply. Please see in line Best Regards Zongpeng Du ------------------ Original ------------------ From: "Linda Dunbar" <linda.dunbar@futurewei.com>; Date: Thu, Jun 8, 2023 08:44 AM To: "Zongpeng"<duzongpeng@foxmail.com>;"kmajumdar"<kmajumdar@microsoft.com>;"rainsword.wang"<rainsword.wang@huawei.com>;"gyan.s.mishra"<gyan.s.mishra@verizon.com>; Cc: "idr@ietf. org"<idr@ietf.org>;"c.l"<c.l@huawei.com>; Subject: RE: [Idr] some comments about the draft-ietf-idr-5g-edge-service-metadata-02.txt Zong Peng, Thanks for the suggestions. Comments and replies are inserted below From: duzongpeng@foxmail.com <duzongpeng@foxmail.com> Sent: Wednesday, June 7, 2023 10:50 AM To: Linda Dunbar <linda.dunbar@futurewei.com>; kmajumdar <kmajumdar@microsoft.com>; rainsword.wang <rainsword.wang@huawei.com>; gyan.s.mishra <gyan.s.mishra@verizon.com> Cc: idr@ietf. org <idr@ietf.org>; c.l <c.l@huawei.com> Subject: [Idr] some comments about the draft-ietf-idr-5g-edge-service-metadata-02.txt Hi, Linda, and the authors: Some comments about draft-ietf-idr-5g-edge-service-metadata-02.txt for your considerations. About the metric distribution, I think the BGP method is one of the important ways. And perhaps in CATS, we need to start from the simple cases. However, future extensions should be supported. IMHO, the way in this document should be supported in future versions of the CATS metric draft, for the scenario that the service instance does not support the direct notification of the computing information. For example, we can extend the format with more information to show it is extensible. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service-Metadata Type | Length (2 Octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | FormatID | AlgoID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Value (multiple Metadata sub-TLVs) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Edge Service Metadata Path Attribute o FormatID (1 octets): indicate a specific format, i.e., which set of TLVs would be included. o AlgoID (1 octets): the suggested algorithm to compare the cost to reach the service in different servers. [Linda] Does “FormatID” and “AlgoID” apply to all the sub-TLVs carried in the “Service-Metadata” Path attribute? What if the Service metadata carried have different “Formats”? • [zongpeng] What I mean here is a format type here. Perhaps we can change it to • o FormatID (1 octets): indicate a specific format, i.e., which set of TLVs would be included. • • For example, the formatID is set to 1, which indicates that we would include the TLVs defined in this document: • - The site Capacity Index, • - The Site Preference Index, • - The Load Measurement Index for the attached edge services. • If the formatID is set to 2, we would include other TLV set. • For example, Joel has suggested that we can only contain one TLV, i.e. the latency of processing the job. Thus, when the formatID=2, and the processing latency TLV will be included, and optionally a capability TLV can be included. • Of course, we can have other ways to show the design is evolvable, for a new scenario in future . Thus, we can define different FormatIDs for different scenarios. Another suggestion about the draft is about the migration of the computing information. You can consider whether it is valuable and acceptable. In the current CATS framework draft, as shown below, the granularity of the computing information can be per-service instance Or aggregated per-site. [Linda] Absolutely should allow metrics Aggregated per-site, per-address-family, or per instance. They are reflected by different sub-TLVs carried within the Metadata Path Attribute. • [zongpeng] I am not quite sure about how the address-family works here. Others are OK. Perhaps we can have a Flag bit to indicate whether the information is aggregated. Note that, depending on the design considerations and service requirements, per-service instance computing-related metrics or aggregated per-site computing related metrics (and a combination thereof) can be used by a C-PS. Using aggregated per-site computing related metrics appears as a privileged option scalability-wise, but relies on Egress CATS-Routers that connect to various service instances to select the proper service instance. [Linda] Agree However, IMHO, we can also merge the computing information in the per Egress Router granularity. The advantage is that we can merge again the computing information if more than one site connect to the Egress. However, more TLVs are needed here. [Linda] We should allow both of the following scenarios network & DC are under one administrative control. Application running status & environment can be measured and analyzed by DC & application controller (however still need some algorithms to aggregate them together for meaningful indication) network operator doesn’t have access to the application running status. Example of Aggregation Descriptions It is said that a cluster of servers serving the same Application behind a Layer 7 Load balancer can be considered as one merged Application server. In this case, the compute metrics from each server within the site will be merged at the site level. Optionally, if the Egress can do another round of load balancing among the local sites that connects directly to it, the Egress can merge again the compute metrics from the local sites. The advantage is that we can reduce the metric information that needs to be transferred in the network. But new TLVs need to be designed. [Linda] Agree. How about adding the following section? • [zongpeng] It is OK for me. 5.2 Service Delay Index For a deployment environment where the network and the Edge Data Centers are under one administrative control, e.g., a Mobile Service Provider, the application/service running status & environment metrics collected by DC & application controller are much more meaningful than the IP layer load measurement collected by the Edge routers as described in Section 4.4. However, it is not easy to predict which site has “the fastest processing time” or the shortest delay before the service request arrives because: - The given service instance shares the same physical infrastructure with many other applications & service instances. Service requests by other applications, UEs, or applications running behavior can impact the processing time for the given service instance. - The given service instance can be served by a cluster of servers behind a Load Balancer. To the network, the service is identified by one service ID. - The service complexity is different. One service may call many micro services, need to access multiple backend databases, need to go through sophisticated security scrubbing functions, etc. Another service can be responded with a few simple steps. Without application internal logic, it is difficult to estimate processing time Here are some metrics, which can be easily collected and measured. They are meaningful in predicting service processing time for a new service request: o CPU utilization for the server where the instance is instantiated o The network utilization for the links to the server where the instance is instantiated o The number of databases that the service instance will access o The memory utilization of the databases While out of scope, we assume there is an algorithm that can derive the Service Delay Index from all the measurements above. Thank you Linda Best Regards Zongpeng Du duzongpeng@foxmail.com & duzongpeng@chinamobile.com [Idr] I-D Action: draft-ietf-idr-5g-edge-service-metadata-02.txt internet-drafts@ietf.org Thu, 04 May 2023 23:17 UTCShow header A New Internet-Draft is available from the on-line Internet-Draftsdirectories. This Internet-Draft is a work item of the Inter-Domain Routing(IDR) WG of the IETF. Title : BGP Extension for 5G Edge Service Metadata Authors : Linda Dunbar Kausik Majumdar Haibo Wang Gyan Mishra Filename : draft-ietf-idr-5g-edge-service-metadata-02.txt Pages : 19 Date : 2023-05-04Abstract: This draft describes a new Metadata Path Attribute and some sub-TLVs for egress routers to advertise the Edge Service Metadata of the directly attached edge services (ES). The Edge Service Metadata can be used by the ingress routers in the 5G Local Data Network to make path selections not only based on the routing cost but also the running environment of the edge services. The goal is to improve latency and performance for 5G edge services. The extension enables an edge service at one specific location to be more preferred than the others with the same IP address (ANYCAST) to receive data flow from a specific source, like specific User Equipment (UE).The IETF datatracker status page for this Internet-Draft is:https://datatracker.ietf.org/doc/draft-ietf-idr-5g-edge-service-metadata/There is also an htmlized version available at:https://datatracker.ietf.org/doc/html/draft-ietf-idr-5g-edge-service-metadata-02A diff from the previous version is available at:https://author-tools.ietf.org/iddiff?url2=draft-ietf-idr-5g-edge-service-metadata-02
- [Idr] some comments about the draft-ietf-idr-5g-e… duzongpeng@foxmail.com
- Re: [Idr] some comments about the draft-ietf-idr-… Linda Dunbar
- Re: [Idr] some comments about the draft-ietf-idr-… Zongpeng
- Re: [Idr] some comments about the draft-ietf-idr-… Linda Dunbar
- Re: [Idr] some comments about the draft-ietf-idr-… Shihang(Vincent)
- Re: [Idr] some comments about the draft-ietf-idr-… Linda Dunbar
- Re: [Idr] some comments about the draft-ietf-idr-… duzongpeng@foxmail.com
- Re: [Idr] some comments about the draft-ietf-idr-… duzongpeng@foxmail.com